[Vm-dev] I think I've found a bug in the 64-bit Squeak VM memory compactor

David T. Lewis lewis at mail.msen.com
Wed Jun 16 10:37:24 UTC 2010


Updated on Mantis http://bugs.squeak.org/view.php?id=7549

On Tue, Jun 15, 2010 at 08:56:18PM -0700, John M McIntosh wrote:
>  
> Oops, didn't see this, but had just sent a note to David Lewis saying I think there is another change needed. 
> 
> On 2010-06-15, at 8:52 PM, David T. Lewis wrote:
> 
> > 
> > On Tue, Jun 15, 2010 at 11:17:48AM -0700, ungar at mac.com wrote:
> >> 
> >> On Jun 15, 2010, at 1:02 AM, John M McIntosh wrote:
> >>> 
> >>> PS the reason why David thundered into this is because  
> >>> 
> >>> (a) on a 32bit system with 32bit image the oops start address is never zero, base is constant 0
> >>> (b) on a 64bit system with 64bit image the oops start address is never zero, base is zero
> >>> (c) on a 64bit system with 32bit image the oops start address is zero, offset by the mmap as the base
> >>> (d) on a 32bit system with 64bit image the oops start address is never zero (and the image size would be less than the 32bit address range), base is constant zero
> >>> 
> >> 
> >> Exactly!
> > 
> > John,
> > 
> > Change set attached to the Mantis report, hopefully implementing the
> > change as you proposed. I think all that is needed is to use the
> > value -1 to represent an invalid object memory pointer, rather than 0.
> > This should work for 32-bit and 64-bit object word size.  It limits
> > 32 bit address range to 32 bits, but this restriction exists already
> > in many places and should cause no additional problems here.
> > 
> > Dave
> > 
> 
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
> 
> 
> 
> 





More information about the Vm-dev mailing list