[Vm-dev] 32bit clean VM work.

David T. Lewis lewis at mail.msen.com
Tue Jun 12 11:15:46 UTC 2007

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.


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

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.


More information about the Vm-dev mailing list