[Vm-dev] gcc -Wall -pedantic (was: sweep failed to find exact
end of memory)
andreas.raab at gmx.de
Wed Apr 25 02:29:39 UTC 2007
Wow. Nice work. I can't speak for the others but since we have the
problem very practically at Qwaq I'd be willing to test drive these
changes for a while and see if they fix the problems. The best way to do
this would probably be to post change sets to this list (this allows me
to go over them method by method more easily).
Thanks for all the work!
David T. Lewis wrote:
> 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