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

[John M McIntosh]

On May 30, 2007, at 8:22 PM, Chris Muller wrote:

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

This issue is if the oops value becomes negative. A image is located  
in memory at point X, if image size + X > 2GB, you'll die. The direct  
object reference pointer *IS* a memory address, all references are  
swizzled at image load time so that the object reference value  
becomes the memory address. It's still a object reference, don't  
forget, however at some point people
do compares on it, and signed versus unsigned compares have different  
meanings.

There should be no problem with memory in the 2GB to 4GB range for  
32bits. images once the fix is done, tested, and given the VM good  
housekeeping seal of approval.

For 64bit images right now you have no problems with the range  
0-2^63  which is a lot.... Can you even assemble a disk farm that  
will provide that backing store?

The fix will double that to 2^64.

Note of course you can't get *all* the address space, most operating  
system maps out large chunks for memory mapped devices, ROM, etc etc.

The number of squeak images you can  run is limited by the combined  
total of memory and Virtual Memory swapping store. Some operating system
take an optimistic viewpoint (BSD) and just pretend to give you the  
memory, and you pretend to use it. If you do and exceed all nooks and  
crannies of
the storage system, then some Process will die...



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