[Vm-dev] 32bit clean VM work.

[David T. Lewis]

OK, I can now confirm that the changes work on 32-bit Linux also.
After applying the changes, then forcing the heap to this:
#define SQBASE (0x7FFFFFFF - 2000000)

I can run Squeak without the crash, allocating 300MB of strings in
the image, freeing them and doing a GC, all without problems:

lewis at dtlewis:/data3/lewis/squeak/sq/Squeak3.9> squeak withfixes
uxAllocateMemory: heap requested at 7fe17b7f, allocated at 7fe18000

So everything looks good on both 32-bit and 64-bit Linux. I have
not tried any 64-bit images, but would not expect any problem
there either.

Dave

On Tue, Jun 12, 2007 at 07:15:46AM -0400, David T. Lewis wrote:
>  
> 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