[Vm-dev] gcc -Wall -pedantic (was: sweep failed to find exact end of memory)

David T. Lewis lewis at mail.msen.com
Wed Apr 25 02:22:09 UTC 2007

On Sat, Mar 17, 2007 at 02:54:52PM -0700, Andreas Raab wrote:
> David T. Lewis wrote:
> >Actually, I would not mind putting some time into this if there
> >was a way to organize the work such that any changes I identified
> >could be properly vetted. 
> If you can keep the changes in reasonably small chunks, I think this 
> would be doable. Just try to avoid the one-size-fixes-all approach of 
> throwing several hundred changed methods at a single point in time.

I have worked though ObjectMemory and Interpreter to identify
and fix the methods that do oop comparisons (#>, #>=, #<, #<=)
with signed integer (sqInt) operands. These takes the form of
either explicit type declarations of variables to usqInt, or
type casts for the comparison operands. The type casts are all
done within four new methods to minimize clutter and document
the intent of the casts. These methods are inlined by the slang
generator, and none of the changes prevent inlining of methods
that currently are inlined. There is also a related change to
pointerForOop() in sqMemoryAccess.h, which was doing an unintended
sign extension when converting 4 byte sqInt oop values to 8 byte
machine addresses on 64 bit host/32 bit image.

I do not have a machine that exhibits the problem of object memory
addresses with negative integer values, reported on some newer Linux
machines. For that reason, I cannot confirm that my changes actually
resolve that problem. However, I could not spot any issues in the
VM other than the typing and oop comparison ones, so I think there
is a reasonable chance that these updates will make that problem
go away.

Any preferences as to how and where to make these updates available?
I can put them into about a half dozen change sets, or provide MCZ
files, or stick them on Mantis, or all of the above. Possibly the
easiest thing is to just send the change sets to this list?


More information about the Vm-dev mailing list