On Fri, 1 Feb 2002, John M McIntosh wrote:

> >
> >(If anyone wants to brainstorm ideas, continue on this thread.)
> >

I am more referring to the in-memory object format, ObjectMemory, not
really how it interfaces with the VM. Stuff like header words, new header
bits, better GC, etc.

>
> Well there are two problems.
>
> a) Squeak only works within the 0-2GB address range. This should be fixed so
> that Squeak can live with 0-4GB.
>
> b) I've seen notes that imply darwin (os-x) will only allocate 1.7GB
> contiguous (that might get fixed) But you need to fix (a) first
> anyways.
>
>
> c) Ha, I must say I go away for a few hours to see a movie with the
> kids, and lo about 20 notes are generated on "Dynamic system memory
> use" so let me say
>
> a) I'm only looking for an optimal solution under os-x, other OS VM
> subsystems are considerations of others. I'm surprised no-one
> mentioned OS/2, once I allocated 512MB to VisualAge on a 24MB box, we
> survived.

I think that dynamicly increasing RAM is a bad idea, one flawed program,
and now you're taking down the machine instead of just

IMHO, go for simplicity.. I think the current scheme is good. It means you
may lose out a little, but you can run everywhere. IMHO, have two RAM
limits, a soft and a hard.

If you ever hit the soft limit, do an incrGC or fullGC (using the
current logic). If, after a fullGC, the amount of RAM left is under
X, bump the soft limit to X. Initialize  soft=min(hard,imagesize+2X)

If your machine has overcommit, you can set set soft and hard to whatever
you want. If your machine doesn't, you make soft == hard, and you'll
always be safe. And, as you don't touch the higher pages they won't be
used, (ideally).

Everyone gets what they want. :)

One problem would be if someone has a non-overcommit machine, but wants
dynamic image increasing, but even in this case, they at least should want
some fixed limit. And, if their OS isn't broken, the machine will just
reserve swap space for the unused pages, it won't consume physical ram if
it doesn't touch them.


Don't deal with shrinking. Its probaly non-portable. Just use the 'user
solution', 'if you want to reduce memory usage after nuking a lot
of stuff, you must restart squeak.'

The current ObjectMemory/GC scheme is somewhat non-intuitive with tuning..

> b) While my back was turned people are installing 1 or 2 GB in their
> laptops/desktops
>
> c) I'm sure if I have 50GB of disk space I could give 10GB to the
> swapper, or even that 30GB I'm not using quite yet.
>
> Given (b) and (c) there is expectations from the herd that blindly
> manipulating GB objects is well just something that should happen and
> of course since Squeak can only deal with < 2GB they've already
> outrun our ability to keep them happy.

I'd say that this is irrelevant.

To handle >2gb images requires some sort of a swizzling scheme and
external storage. I am not proposing that.... Now, with a 64 bit VM, sure,
but I'm not willing at least to work on it.

Also, any image that large would be full of binary literals that could be
ImageSegment'ed out, keeping the in-memory usage to the maximum
addressible of 4gb.


Scott