[Vm-dev] linux 64bit vm running a 32 bit images - networking vm crash

Chris Muller asqueaker at gmail.com
Thu May 31 03:22:38 UTC 2007


Cool, I think you're saying, once the signed oop is fixed, there
should be no problem with memory locations beyond 4GB.  Curious
though, why the signed-oop bug also affects where images *start* in
memory instead of only how large they could be..  Given (theoretical)
unlimited memory, then, does the signed-oop fix allow an unlimited
number of running Squeak images?

I wasn't sure because of the image being referred as "direct-pointer";
thought that might mean hard-referenced memory locations limited to 32
bits.

thanks.

On 5/30/07, John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
>
>
> On May 30, 2007, at 6:17 PM, Chris Muller wrote:
>
> > I don't want a 4GB image, but I may want a lot of normal-sized Squeak
> > images running on a piece of "big-iron".  But I guess the current VM's
> > have some problem where the oop was defined as signed, so images
> > cannot even *reside* above 1GB (or whatever it is).
>
> 2GB, and lurking are changes to fix that issue, but someone has to
> buckle down
> and do testing, then mmm say oh yes should be fixed. But how would
> you know?
>
> >
> > So even if that was fixed, that would take 32-bit Squeak up to 4GB
> > boundary, only if all 32-bits were for the oop.
> >
> > ... I saw this ad on the back of InfoRag earlier today.  Some IBM
> > blade, multi-Xeon-multi-core, up to 48GB high-speed RAM, "starting" at
> > $2K.  Cool, this could probably run a lot of images simultaneously,
> > but how far could you go with 32-bit Squeak on this?
>
> Depends on the image footprint, 3GB images then what 15 or so
> Plus then one cpu needed for each Squeak VM, plus a couple of spares
> to do
> operating system I/O, housekeeping etc. etc.
>
> --
> ========================================================================
> ===
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ========================================================================
> ===
>
>
>


More information about the Vm-dev mailing list