Re: [Jikesrvm-core] Major performance issue?

[Chris H. <hof...@cs...>]

Steve Blackburn wrote:

> In the mean time I added a flag that allows reference processing
> to be turned off at GC time, but I was not sure how to turn it off
> more properly.  Reference processing as currently implemented uses
> traceObject() to get a forwarding address, which is not right.  In
> the case of a mark-sweep collector it will set the mark bit, and in
> the case of the reference counter, will generate a decrement.

Yeah, traceObject() is not a good way to get the forwarding address, but
so far there didn't seem to be any other way to get it, at least at the
generic level that the reference processor works at -- it's the same
approach Perry took when implementing finalization, for instance. It's
definitely wrong for reference counting, but for semispace and
mark-sweep I think it's only a performance issue, if it turns out the
tracing duplicates a lot of work for an object that had previously been
traced.

Another issue with the Plan interface came up with Naren's collector. He
runs through his from-space in several iterations, so Plan.isAlive()
actually needs to return three values: yes, no, and don't know yet. For
his collector, the reference and finalization implementations could
really use a method in BasePlan that is something like
semiSpace/Plan.java's isSemiSpaceObject() method, i.e. a method that
would report whether *anything* definitive can be said about the given
address at this point in the processing. 

If I remember, we solved his problem with references and finalization by
having his Plan.isAlive() return false if it couldn't determine anything
about the address, but semantically that's ugly, as the address often
was alive, we just couldn't say for sure in the current iteration.

Chris

-- 
Chris Hoffmann -- Dept. of Computer Science/UMass at Amherst
http://www-ali.cs.umass.edu/~hoffmann