On Saturday, February 2, 2002, at 01:43 , Andreas Raab wrote:

> Let's get back to square one here. First of all, early versions of the
> Windows VM used _exactly_ the scheme you were describing. So I've been
> there and done that.

The point was that while more sophisticated mechanisms are possible (and 
they definitely are), the very simple version does everything you'd want 
in virtually all realistic circumstances.

>  The reason why I don't like it is that
> a) without backing store you can never be sure that the memory is really
> available

The only time this can happen on OS X is if you're completely out of 
disk-space, including the 10% reserve for root.  The question I have 
is:  what exactly would you do to recover from this?  If you're into the 
10% reserve, you won't even be able to save the image.  Hmmm...

> b) with backing store you waste huge amount of resources

Exactly.

> c) you are unable to give memory back to the OS

Not true.  The VM subsystem will take memory from your process as it 
sees fit.  Memory that isn't used (but dirty) will simply be paged out 
and not be a bother afterwards.  If you *know* you're done with it, you 
can simply vm_zero() it and the address-space will revert to being 
zero-filled.  You can still just malloc() the entire chunk beforehand, 
keeping track of the 'allocated' amount simply by updating a simple 
'size' variable.

> All of the above are real problems; I have encountered every single
> problem I've been mentioning (in practice a little more complicated than
> the one I cited but in spirit they were very similar).

VM policy and mechanisms tend to be rather subtly tuned to real-world 
problems instead of contrived or 'similar' ones.

>  Or why else would
> I have bothered actually adding the growth/shrink mechanism in the first
> place?! ;-)

I am sure you had your reasons.  Just don't assume that others don't 
have *their* reasons.

> BTW, for me this issue is not about "what OS is better or worse" or
> "which memory subsystem is better". I don't give a damn about that;

Then you should tone down your language a bit and not criticize what you 
obviously don't understand.

>  in the end all of of them are nothing but hardware abstractions for 
> Squeak.

Agreed.

> This issue is about stability of Squeak and while it may be fine that a
> generic Unix app just coredumps if it has no more memory I don't quite
> think that just because some user typed "Array new: SmallInteger maxVal"
> Squeak should do the same. I'm sure you'll agree on that.

Yet another contrived example that would, it seems to me, fail by 
running out of address space.  Are we protected against that?  
Unreasonable requests crash Squeak.

Anyway, the question is what reasonable alternatives are and what you're 
actually gaining with a specific mechanism, in a specific context.  What 
may seem reasonable for Windows may not make much sense elsewhere.

For example, the parameters that are relevant here are (a) the real 
memory available (b) the working set of the Squeak VM and other running 
applications (dynamic use) and (c) disk space availalble.  I still don't 
see how your approach manages to compute (b), which is the only case 
where it would offer an advantage over the fixed scheme (a+c) that you 
found so utterly ridicuolous.  As far as I can see, you don't even take 
(a+c) into account.

If you're going to be sophisticated about customizing VM usage, use an 
external pager.  This will let you actually interact with the VM 
subsystem.  If you're not going to be sophisticated, just allocate and 
let the VM take care of it.  This will typically be good enough.  
Mucking around without actually understanding how this *particular* VM 
subsystem works, though it is probably fun, is unlikely to improve 
matters in any useful way, while adding hard-to understand code and 
possible introducing serious bugs.

Marcel