On Tue, Jun 12, 2007 at 12:12:16AM -0700, John M McIntosh wrote:
The good news is that everything works fine on both platforms, even when I set the base of heap memory to just below 2MB as John suggested for testing.
Well I assume you mean 2GB for 32bit systems, but for 64bit you need to get up to the 0x8000000000000000 boundary.
On the 64-bit system, it's not allowing me to use anything that high in the address space. I can request a mmap to 0xfff00000000 and the request will be honored:
uxAllocateMemory: heap requested at fff00000000, allocated at fff00000000
But if I request a higher location, it decides that I am being unreasonable and uses its own assignment:
uxAllocateMemory: heap requested at ffff00000000, allocated at 2aca47532000
Thus I cannot say if there would be any issues at the 0x800000000000000 boundary, but I can say that this does not appear to be a possible failure mode on current Linux implementations.
The bad news is that I cannot get it to fail. My 32-bit system is an older 2.4 Linux kernel, which refuses to mmap things at the requested locations and therefore does not have a problem.
In all the crash cases we see the stack context go over the 2gb boundary expressed as negative values in the the VM stack traces. Since we know the for() loop in incCompMove trashs memory when you walk an object move over the 2GB boundary what you really need is to confirm the image works fine when it starts under 2gb, and ends over 2gb.
Right.
But I was too hasty. I saw that my mmap request did not work at 0x7FFFFFFF and assumed that my older Linux system did not honor this, but I just tried again with: #define SQBASE (0x7FFFFFFF - 2000000)
And this *did* work. Better yet, I can now reproduce the problem reliably:
uxAllocateMemory: heap requested at 7fe17b7f, allocated at 7fe18000
sweep failed to find exact end of memory
-2126938800 SystemDictionary>garbageCollect
I will re-apply our fixes and see what happens. I'm late for work though, so it may not be done this morning.
Dave