Author Topic: ArcaOS kernel 202 and Firefox  (Read 570 times)

Neil Waldhauer

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 50
  • Posts: 630
  • Karma: +1/-0
    • View Profile
    • Blonde Guy
ArcaOS kernel 202 and Firefox
« on: November 21, 2020, 09:19:46 pm »
Arca Noae has released a new kernel, probably to support the new web browser.

Is it possible that the new kernel fix makes it unnecessary to run FFTurbo, because memory is now released on exit?
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

Roderick Klein

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 23
  • Posts: 365
  • Karma: +2/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #1 on: November 21, 2020, 09:47:00 pm »
100% true you can load DLL's high and unload them and the memory is released so mozturbo for that purpose is no longer needed.

Roderick

Gordon Snider

  • Newbie
  • *
  • Thank You
  • -Given: 3
  • -Receive: 0
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #2 on: November 21, 2020, 09:54:25 pm »
The AN announcement says not to install the new kernel if our computer is running ACPI.PSD 3.23.14 or lower.  How do we check what version of ACPI.PSD we are running?

Roderick Klein

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 23
  • Posts: 365
  • Karma: +2/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #3 on: November 21, 2020, 10:01:31 pm »
You need the new ACPI.PSD 03.23.15.

Roderick

Andreas Schnellbacher

  • Hero Member
  • *****
  • Thank You
  • -Given: 1
  • -Receive: 32
  • Posts: 592
  • Karma: +1/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #4 on: November 21, 2020, 10:32:42 pm »
How do we check what version of ACPI.PSD we are running?
The Kernel install script executes acpistat for that.

Roderick, thanks for the info that now unloading of these DLLs should be finally fixed. The docs don't say it that clearly, but let one rather suppose that it was somehow improved.

David Graser

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 69
  • Posts: 621
  • Karma: +2/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #5 on: November 21, 2020, 10:34:51 pm »
The AN announcement says not to install the new kernel if our computer is running ACPI.PSD 3.23.14 or lower.  How do we check what version of ACPI.PSD we are running?

use bldlevel.  see attached.

Download the new ACPI from the ARCA NOAE web site. Install and reboot. Then install the new kernel.  The kernel installer checks for the latest ACPI.  That is why it is necessary to reboot after installing the new ACPI.
« Last Edit: November 21, 2020, 10:47:14 pm by David Graser »

Neil Waldhauer

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 50
  • Posts: 630
  • Karma: +1/-0
    • View Profile
    • Blonde Guy
Re: ArcaOS kernel 202 and Firefox
« Reply #6 on: November 22, 2020, 12:32:05 am »
100% true you can load DLL's high and unload them and the memory is released so mozturbo for that purpose is no longer needed.

Roderick

So I still will need to mark the Mozilla DLLs to load high, but I no longer need mozturbo or anturbo. I hope this helps. Managing all the turbos was difficult if running two versions of Firefox, for example.
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 195
  • Posts: 2720
  • Karma: +16/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #7 on: November 22, 2020, 02:02:01 am »
100% true you can load DLL's high and unload them and the memory is released so mozturbo for that purpose is no longer needed.

Roderick

So I still will need to mark the Mozilla DLLs to load high, but I no longer need mozturbo or anturbo. I hope this helps. Managing all the turbos was difficult if running two versions of Firefox, for example.

There's still a problem with memory fragmentation, especially with the stock VIRTUALADDRESSLIMIT. which is conservatively low in the interest of system stability.
The fragmentation issue mostly happens if you open and close multiple memory intensive programs.
Personally, I'm going to keep using the mozturbo programs as I do run multiple Mozilla apps and leave the computer running.
For most use cases it probably doesn't matter too much.

Rich Walsh

  • Full Member
  • ***
  • Thank You
  • -Given: 1
  • -Receive: 13
  • Posts: 132
  • Karma: +1/-0
  • ONU! (OS/2 is NOT Unix!)
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #8 on: November 22, 2020, 05:50:08 am »
So I still will need to mark the Mozilla DLLs to load high, but I no longer need mozturbo or anturbo. I hope this helps. Managing all the turbos was difficult if running two versions of Firefox, for example.

ANTurbo ('TurboSetup.cmd') is still useful since it knows which DLLs to load high and can tell you their current status. After using it, delete the turbo object(s) in your Startup folder if you don't want to preload the DLLs. Here's what the setup script reports after doing so:

Code: [Select]
Status:  Partially installed
  - 18 of 18 DLLs are marked for high memory
  - SMTurbo startup object not found
  - SMTurbo.exe is not running

One of these days I'll rewrite it to eliminate the turbo stuff, but for now this workaround should suffice.

David McKenna

  • Sr. Member
  • ****
  • Thank You
  • -Given: 10
  • -Receive: 16
  • Posts: 277
  • Karma: +1/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #9 on: November 23, 2020, 11:16:04 pm »
 With this new kernel, wouldn't it make sense to load ALL 32 bit dll's high? In order to leave low shared memory to the WPS. I've so far loaded all dll's in \MPTN\DLL, \TCPIP\DLL, \MMOS2\DLL, \sys\dll, \usr\dll (except libc*.dll, pth*.dll, winmm.dll and user32.dll) and many programs (SeaMonkey, FireFox, XWPS, Drag Text) and everything seems stable and there is more lower shared memory than before. Would it be possible to create a script that checks every DLL on a system to determine if it can be loaded high, and do it if possible? Just thinkin' out loud...

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 195
  • Posts: 2720
  • Karma: +16/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #10 on: November 24, 2020, 12:02:28 am »
Have to be careful as only pure 32 bit DLLs will consistently work loaded high. 16 bit code just can't access memory above 1GB or so, it's the reason for the 512MB process space (plus 512 MB kernel) to begin with. So if that 32bit DLL calls a 16 bit function...

David McKenna

  • Sr. Member
  • ****
  • Thank You
  • -Given: 10
  • -Receive: 16
  • Posts: 277
  • Karma: +1/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #11 on: November 24, 2020, 01:09:34 am »
 Dave,

 Right... but can't that be determined programmatically?...

Regards,

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 195
  • Posts: 2720
  • Karma: +16/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #12 on: November 24, 2020, 04:28:37 am »
In theory, sure. In practice I think the first 90% or so would be easy and the rest would be trial and error due to undocumented API's, code that dynamically links and such.
Then there may be 16 bit programs that call 32 bit DLL's. You're likely to run into that having marked \MPTN\DLL, \TCPIP\DLL, \MMOS2\DLL to load high. For example, if you fire up telnet, it is likely a 16 bit program and may not be happy calling a DLL in high memory.
A real example is os2safe.h, which is used to avoid allocating high memory for 16 bit functions. It had a similar problem as above as for years it had new functions added to fix crashes caused by passing high memory pointers, buffers and such to 16 bit API's. If you have the libc-dev headers installed, you can look at what is actually a fairly short list of APIs in os2safe.h.

It is possible I'm making a wrong assumption somewhere so if someone else knows better, be interested.

Roderick Klein

  • Sr. Member
  • ****
  • Thank You
  • -Given: 0
  • -Receive: 23
  • Posts: 365
  • Karma: +2/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #13 on: November 24, 2020, 09:46:54 pm »
With this new kernel, wouldn't it make sense to load ALL 32 bit dll's high? In order to leave low shared memory to the WPS. I've so far loaded all dll's in \MPTN\DLL, \TCPIP\DLL, \MMOS2\DLL, \sys\dll, \usr\dll (except libc*.dll, pth*.dll, winmm.dll and user32.dll) and many programs (SeaMonkey, FireFox, XWPS, Drag Text) and everything seems stable and there is more lower shared memory than before. Would it be possible to create a script that checks every DLL on a system to determine if it can be loaded high, and do it if possible? Just thinkin' out loud...

To any user wanting todo the above, do not do this. It can lead to al sorts of the unknown and strange issues by marking OS/2 DLL to load high.
Soo any DLL's from IBM such as MPTN\DLL \TCPIP\DLL \MMOS2\DLL \OS2\DLL do not mark these DLL's high. Also not DLL's like Xworkplace.
Dave Yeo described why you should not do this.

Loading DLL's high you should keep track which DLL's you load high and keep track if you load the data segment and/or the code segment high.
The real DLL's you should experiment with are DLL's with GCC compiled applications. Such as with Open Office, Mozilla Sweet and QT.
In the end OS/2 VOICE and BWW want to test which big DLL's can be loaded high and incorporate this in RPM install scripts.

Roderick Klein
President OS/2 VOICE

David McKenna

  • Sr. Member
  • ****
  • Thank You
  • -Given: 10
  • -Receive: 16
  • Posts: 277
  • Karma: +1/-0
    • View Profile
Re: ArcaOS kernel 202 and Firefox
« Reply #14 on: November 24, 2020, 10:37:37 pm »
 @Dave,

  Thanks for the insights, hadn't thought about 16 bit calling 32 bit (who does that?) or undocumented API's - definitely complicates things.

 @Roderick

  Sorry, not trying to corrupt the morals of OS/2 users ;-) just testing the limits of the new kernel. I haven't seen any issues yet, but it is early days and believe me I do keep track of these changes. I understand the dangers of changing the original OS/2 DLL's, but why XWPS? Isn't that compiled with a recent GCC? And glad to hear this may be incorporated into RPM's - thanks for all you do for OS/2!