[softwarelist] Re: OvPro 2.77 memory

In message <DnDI7WALIgWFFwcl@xxxxxxxxxxxxxxxxxxx>
          David Pilling <flist@xxxxxxxxxxxxxxxxxxx> wrote:

> In message <1d46a8854e.jaycee@xxxxxxxxxxxxxxxxxxxx>, JayCee
> <jaygcee@xxxxxxxxxxxx> writes
>>> Back to the dynamic area saga, there are utilities around that limit the
>>> max size to prevent the address problems - so if you've used one of
>>> those it may explain things.
>>I am not using anything like that as far as I am aware
> 
> I'd be inclined to think about that kind of thing - I don't know off
> hand what the final position was - there was talk about some sort of
> patch that limited all dynamic areas, unless configured otherwise.

Yes. The full story is as follows: On 26-bit versions of RISC OS and 
on ROL's 32-bit version, i.e., on anything except RISC OS 5, the 
application slot is limited to 28MB, so each application can only 
claim 28MB and that is it.

Therefore, various applications have adopted the use of dynamic areas 
to allow users to use more memory than the OS limit. Unfortunately, 
this solution has a catch: Either, the application limits the size of 
the dynamic area when it creates it, but then it cannot use the whole 
of available RAM, which somehow defeats the purpose of using a dynamic 
area to start with. Or, it creates a maximum size dynamic area (size 
of all available RAM), but then, there is a huge problem with logical 
address space becoming exhausted.

Please note that a dynamic area, once created, does not take away any 
actual memory, it just takes away a range of addresses reserved for 
the area, and the overall address range is just under 3.5GB, which 
seems a lot, but on a machine with 512MB (and this is what JayCee's 
memory figures imply) only 6 maximum size dynamic areas can be 
created, and some application create several areas! There is an 
additional problem with many applications and modules creating maximum 
size dynamic areas because the author was too lazy to set a limit. 
Some of these applications maybe only ever use 100k, but they would 
hog a massive 512MB of logical address space to do that. Clearly, this 
situation could be tolerated, so there had to be a fix (see below).

As an aside: This whole problem does not happen with application 
memory where all applications share a common address space, which is 
precisely why applications should really use application memory. This 
is the reason why the increased application slot size of 512MB is such 
an important feature of RISC OS 5 (and the reason why ROL's 32-bit 
RISC OS is disappointing because in keeping the old 28MB limit it does 
not exploit one of the biggest benefits of going 32-bit).

So, it turned out that on machines with large amounts of RAM, the 
dynamic area system was rendered almost useless, which is why the 
dynamic area clamp was invented. It allows the amount of memory given 
to "maximum size" areas to be limited to a specific value. There is 
another clamp that limits the size of dynamic areas created with 
explicit sizes, but this is less important because one can assume that 
applications quoting an explicit maximum size know what they are 
doing.

So, JayCee, if your machine has 512MB and it does something useful at 
all, then it is highly likely that a dynamic area clamp is set up. You 
can read its value by typing the following in a TaskWindow:
*Basic
SYS "OS_DynamicArea",8,0,0,0 TO ,R1,R2,R3
PRINT R1/(1024*1024)
PRINT R2/(1024*1024)

The first figure it prints is probably 128, which means that the limit 
for maximum size areas is 128MB. So, if OvationPro creates a maximum 
size area (which I believe it does), then it can only ever use 128MB, 
no matter how much RAM is free. OvationPro could use more RAM if it 
created an area with an explicit size greater than 128MB, unless of 
course, the other clamp is set, too, which is the second figure 
displayed above (-1 means there is no limit set).

Martin
-- 
---------------------------------------------------------------------
Martin Wuerthner          MW Software          martin@xxxxxxxxxxxxxxx
---------------------------------------------------------------------

Other related posts: