AW: Dynamic system memory use
Marcel Weiher
marcel at metaobject.com
Sat Feb 2 01:54:52 UTC 2002
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
More information about the Squeak-dev
mailing list
|