OS/2, eCS & ArcaOS - Technical > Storage

PMSHELL

<< < (3/4) > >>

Dariusz Piatkowski:

--- Quote from: Roderick Klein on July 29, 2018, 11:32:39 pm ---...The real killer is the size of the large DLL's that get loaded this can fixed by using a tool to mark the code segments to load high. Do this for Firefox DLL's, THunderbird AND Open Office.  Do not mark the datasegments high of the DLL...

--- End quote ---

Help me out with this particular concept from the statement above: so what problem is caused by attempting to load BOTH code and data segments?

I always thought that if the application is written in such a way as to support this mode of operation, it would be the best possible scenario to load both to upper memory.

Is that a wrong assumption?

I just checked my OpenOffice413 install, all DLLs are marked as BOTH. What that means on my machine (VIRTUALADDRESSLIMIT=3072) is that even when my total RAM drops to 1.5Gig (PU Monitor) and shmemon shows only 80.5M left I am still able to open up any document OO I wish. Granted, I did not try any other highmem combos, so I can not tell if there is a difference there or not?

Dave Yeo:

--- Quote from: Dariusz Piatkowski on August 02, 2018, 03:10:09 am ---
--- Quote from: Roderick Klein on July 29, 2018, 11:32:39 pm ---...The real killer is the size of the large DLL's that get loaded this can fixed by using a tool to mark the code segments to load high. Do this for Firefox DLL's, THunderbird AND Open Office.  Do not mark the datasegments high of the DLL...

--- End quote ---

Help me out with this particular concept from the statement above: so what problem is caused by attempting to load BOTH code and data segments?

--- End quote ---

Older kernels (and perhaps the current one though it has fixes for this) had problems when loading both high. With Mozilla, I've found sometimes it works fine and sometimes introduces instability, especially when closing the app. Best to experiment but I usually advice to load the code high as it is safer.

Lars:
Whenever you have data in a data segment that is marked to load high you will get in deep shit trouble if that data needs to be passed for access by a 16-bit DLL (either directly or indirectly via intermediate DLLs).
That's because the standard way to thunk a 32-bit address to a 16-bit address will miserably fail for data in the high memory area but thunking is necessary so that 16-bit code can access data in a 32-bit data segment.

It should be obvious that it is almost impossible to know if data will eventually be accessed by 16-bit code and therefore it is a bad idea in general to mark data segments to load high.

Marking code segments to load in high memory is less risky. Only if some 16-bit code needs the address for a piece of code loaded in high memory this will miserably fail. But this happens not very often, compared to the "data case".

And then there is dynamically allocated (data) memory, that is, (data) memory allocated by an application during the runtime of the application. Here you can only rely on the programmer to make the correct decisions as you cannot influence this as a user.
It is the programmer's job to investigate if that memory is going to be used by 16-bit code or not. If yes, there are also means to generate a memory alias in low memory so that the address can be properly thunked for use by 16-bit code. But again, it's the programmers' job to do it right.

Remy:
Has it something to do with PMSHELL ?

When I open bigicons from ArcaOS and did a fast slide down and up, following by a close, 30MB are used in the shared storage. After folder close, only 1Mo is freed.... Do it again and a new 30MB are used in shared strage and 1MB released after close...
I did test with other applications and the amount of taken shared storage is release at end of session...
Strange...
If some of you could test to check if this happens for others too...

Lars:
That much sounds like a memory leak either in some WPS class (which is likely, given its lousy stability) or even in the memory subsystem (which is rather unlikely, compared to option 1).

But this memory leakage problem is not related to the question of low/high memory arena. It is likely a problem of dynamically allocated memory that is not properly freed when no longer in use. Since every WPS class remains loaded for as long as PMSHELL is executing, that memory will be leaked until you shut down the system or do a WPS restart.

As a test: if you observe this leakage, just do a WPS restart (via XWorkplace/eWorkplace) and see if that brings back the lost memory.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version