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 johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===