[squeak-dev] To a terabyte and... beyond

John McIntosh johnmci at smalltalkconsulting.com
Fri Oct 29 23:55:30 UTC 2010


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 at 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
>
>
>


-- 
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================



More information about the Squeak-dev mailing list