[Vm-dev] linux 64bit vm running a 32 bit images - networking vm
crash
John M McIntosh
johnmci at smalltalkconsulting.com
Thu May 31 04:38:36 UTC 2007
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
========================================================================
===
More information about the Vm-dev
mailing list