Well I think there are two interesting factors if not more here.

(a) when you ask for the 1gb I believe the logic zeros the memory chunk. Without specialized virual memory manager aware code this could take a long Long time. Specialized code could ask the VM to provide zero pages from the operating systems queue of zero pages it has on hand.

(b) I'm not sure where this will end up, old space or new space. A big hurdle here is that on the compaction it's going to move GB of memory just possibly a few kilobytes in distance.

It is of course viable to adjust the gc prams to avoid a full gc cycle at all cost, which is what i do for wikiserver on the iPhone

Frankly to avoid the two points above squeak needs the notion of large space or fixed space. I thought Eliot mentioned he was thinking/planning that?

Oh got funding? I have hours looking for a person to pay for...

Lastly the vm logic isn't setup right to handle the remember table, allocate a 1gb array and the vm might just iterate over the 1 gb elements looking for a root.

These three item will bring things to a crawl in my opinion

On 10/29/10, David T. Lewis lewis@mail.msen.com wrote:

On Fri, Oct 29, 2010 at 09:48:11AM +0200, Bert Freudenberg wrote:

...

On 29.10.2010, at 06:25, Dan Ingalls wrote:

...

Hi Guys ;-)

Anyone have experience with running super huge Squeaks? I have the chance to use an absurdly big machine. I'd appreciate advice (offline unless you think it would be generally useful) regarding the relative stability of, say, linux and windoze builds of 64-bit Squeaks known (or thought) to run with over a terabyte of objects, and also where there may be some pre-built 64-bit images (sorry if this is in an obvious place). Finally (since I've mainly used a Mac for Squeak) I guess I'll have to know how to tell it how big to be, or would it grow gracefully if I just said "(String new: 1000000000000) size" in a normal image?

Thanks

• Dan

Dave Lewis has been working on 64 bit stuff, he surely will respond (and please keep responses on list, this is rather interesting). A recent image is here:

http://squeakvm.org/squeak64/sq64-dtl.zip

I think there isn't even much experience with a Gigabyte-sized image ...

Hi Dan,

The image that Bert mentions is an updated version of your original 64-bit image, suitable for running on a current Squeak VM. I have not tried tracing the latest Squeak trunk image (sounds like a good project for this weekend though :)

The quickest way to get a VM running is to start with an up to date Squeak image, load latest VMMaker from www.squeaksource.com/VMMaker and platform sources from Subversion. The "64-bit VM" button is gone from the VMMaker tool, all that is needed to build the 64 bit version is to set a macro either in ./build/config.h or in ./src/vm/interp.h:

#define SQ_VI_BYTES_PER_WORD 4

I use Linux for running this stuff, so I can't speak to Windows or OS X. On a unix platform, if you evaluate "(String new: 1000000000000) size" in sq64-dtl.image, you will get a low space notifier. I remember adding some checks to the VM to prevent address overflows for allocations that are "unreasonably large), and I think this notifier reflects hitting that limit (sorry I can't recall the details, I'll check later). It would be fun to see how big "unreasonably large" could be though :)

A gigabyte is no problem though. The following succeeds on a 64-bit image:

(String new: 1000000000) size ==> 1000000000

For allocation requests that are within the current VM limits, what you can expect to see on a unix box is that your VM will cheerfully keep allocating memory from the OS until your system starts swapping pages to disk, at which point everything on the system slows to a crawl. It will be interesting to see what happens on a really big box with lots of memory.

Dave