review request (S) 6866585 debug code in ciObjectFactory too slow
Thomas.Rodriguez at Sun.COM
Thu Aug 6 11:53:53 PDT 2009
On Aug 6, 2009, at 11:46 AM, Keith McGuigan wrote:
> Tom Rodriguez wrote:
>>>>> Would it be possible to put the check into the GC epilogue?
>>>>> Probably not, since ciEnv guys are not statically allocated and
>>>>> not easy to enumerate (one per active compile-thread task). I
>>>>> guess I do like the idea of checking a GC tick counter from the
>>>>> CI, to throttle the paranoid check. Best of all would be to
>>>>> have some explicit linkage from the GC epilogue code to the CI,
>>>>> which somehow documents and enforces the order invariance. You
>>>>> can see why this is awkward: It is an invariant shared by the
>>>>> CI and the GC.
>>> Yes, i agree, if it's one per active compile task, may be it's
>>> best to use
>>> yr strategy of eliding the check unless the full gc count changes.
>> John, couldn't this strategy allow us to reunify the handling of
>> oops into a single table instead of needing the NonPermOop stuff?
>> If we simply re-sort the table when needed that code becomes simple
>> again. It also makes us impervious to reordering concerns.
> Would that also be a step towards getting some of the stuff (namely
> symbols) out of perm gen? There's more to it than that, of course,
> but the ordering constraint by the compiler was one of the reasons
> for keeping them in perm gen.
I don't think the compiler was the main constraint for where symbols
live and whether they can be reordered. I thought symbol and method
lookup in the core of the VM relied on the ordering as well? See
symbolOopDesc::fast_compare. Why would moving the symbols out of perm
be a good idea?
> - Keith
More information about the hotspot-compiler-dev