🚀 go-pugleaf

JD wrote:

> Re-read Alan's posts to me.

Actually that was me :)

I've carried out some research this morning on Win2K and it has
produced some definitive and interesting results.

If you use new[] to ask for up to 80% of memory then:

  1.Until you populate that memory nothing much happens.
  Windows is using lazy allocation as I expected. The VM (Virtual
Memory) size increases but that's all. No physical RAM is consumed.

  2.As you write to the array physical RAM is consumed to back the VM
store.
  This is very important because of the next point;

  3.You will only be given physical RAM up to the 80% limit of what's
available as/when you access your address space.
  Actually you do get a bit more but it's temporary and rapidly gets
reclaimed.

  4.You get to keep whatever physical RAM you were given.
  As long as you *don't minimize your application* you get to keep the
physical RAM being used to back your single allocation.

What does this mean for the Deniel?

It means that you want to have something like this at program startup:

  DWORD arraySize=physRAMAvail*0.8;
  BYTE * wibble=new BYTE[ arraySize ];

  memset( wibble, arraySize, 0 );

This will give you what you want - 'physRAMAvail' bytes locked into
memory without disk swapping.

An important point however:If your application is minimized all bets
are off and from my tests Windows will /severely/ trim your working set
and page stuff out to disk.

Some points:
1.'80%' is our guess. We didn't bother calculating it exactly.
2.I'm not sure what happens to the RAM you are given in scenario (3). I
don't know if you get to keep 'the most you can be given' or if Windows
stops trying to help you out.

Basic conclusion:The Windows memory manager is actually trying to
cooperate with Deniel's scenario. It has a pretty good idea what you
are trying to do and as long as you make your intention clear from the
start you stand a good chance of achieving what you want.

I'd like to know how Linux handles this myself. It implies Windows
Memory Manager has some intelligence but I still have a gut feeling
that the older Unix strategy of taking RAM purely on demand is better.
-- 
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html