Some of you might know that David T. Lewis has been working on
changes to the VM source to make it work fully within 32 or 64 bit
address spaces.
As we know the Squeak VM treated memory address which are unsigned
values as signed integer values. This wrong usage of signed math in
compare statments or do loops which would cause the VM to make an
incorrect decision resulting in corrupted memory and causing the VM
to crash.
This issue would usually occur if you wanted to use 1GB of memory for
your VM and the host operating system would then allocate memory for
you above the 2GB boundary, or at say the 1.5GB boundary. Resulting
either in an instant crash, or a crash much later when your memory
needs caused the VM to grow over the 2GB boundary.
Some fixes were done in the past to make the VM mostly run when fully
over the 2GB boundary but at best they were insufficient patches.
Over the last couple of days I reviewed David Lewis' changes, plus
made some fixes, and revised the macintosh os-x support files, plus
worked up some general test cases to see what happens when you run
the macro bench marks below the 2GB boundary, crossing the 2GB
boundary, and when the image is allocated at the 3GB boundary.
This afternoon I'm pleased to say the VM passed all runs of my
trivial test cases, so I have check in the Mac OS carbon source code
changes and David's changes to the Mac OS source tree for further
review.
People wanting to build a VM should review the Mac OS build
instructions to build a Mac OS carbon VM, or review the required
changes to VMMaker as per the Carbon VM build readme to build a 32bit
clean VM.
I have not:
(a) build a 64 bit VM and tested it.
VM developers should consider the mmap call in the memory allocation
routine, you can specify a suggested starting position. On OS-X I was
able to chose 1GB, 1.5GB, 2GB and 3GB. I have not tested 64bit VMs
at the 0x8000000000000000 boundary. I suspect you could allocate at
the 0x7FFFFFFFF0000000 Then ask for 600MB of memory for the image.
That would set the end of memory at 0x8000000015800000, 344MB over
the negative sign boundary.
(b) I have not tested or reviewed any of the external plugins for
improper use of usqInt.
(c) I have not confirmed the changes work with the Unix VM, or the
Windows VM, I have no plans to do so.
--
========================================================================
===
John M. McIntosh <
[hidden email]>
Corporate Smalltalk Consulting Ltd.
http://www.smalltalkconsulting.com========================================================================
===