[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