[Vm-dev] 32bit clean VM work.

David T. Lewis lewis at mail.msen.com
Sat Jul 14 21:40:20 UTC 2007


John,

No, I did not test the 0x7FFFFFFFFFFFFFFF boundary at all. Is it important
to do so? If so, I'll see if I can set up a test based on Ian's tip.

Ian, are you referring to the SQ_FAKE_MEMORY_OFFSET macro? It looks like
that would do what you are suggesting.

Avi, have you been running the VM with these changes in any production
situations? If so, any feedback you might be able to provide would be
appreciated. Thanks!

Dave

On Sat, Jul 14, 2007 at 11:39:26AM -0700, Ian Piumarta wrote:
> >>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:
> >
> >I was just reviewing these emails for michael and I don't think I  
> >commented on this
> >allocating at 0xfff00000000 would be fine to test the squeak oops  
> >space over the 0x8000000000000000 boundary.
> >
> >It wasn't clear if you were able to allocate below the  
> >0x7FFFFFFFFFFFFFFF  boundary to test allocating over
> >that boundary.   Also I've never heard if any one has been able to  
> >run a Squeak image at say at or near 4GB
> 
> Dave: if you look in sqUnixMemory.c you'll see a facility in the  
> memory allocator to artificially skew all oops by a certain amount.   
> If you calculate the amount after the allocation you can place the  
> apparent start of memory at any address you like.  There is (or was)  
> some corresponding code in sqMemory.h to allow unskew all oops  
> accordingly to bring them back into the allocated memory, but I've no  
> idea if anyone removed that since (or even if it didn't make it out  
> of the 64-bit prototype sources and into the final repository  
> version).  This would seem by far the easiest way to force oops (as  
> seen by the Interpreter) to occupy interesting borderline address  
> ranges.
> 
> Cheers,
> Ian
> 


More information about the Vm-dev mailing list