review request (S) 6866585 debug code in ciObjectFactory too slow
Thomas.Rodriguez at Sun.COM
Thu Aug 6 12:24:16 PDT 2009
On Aug 6, 2009, at 12:02 PM, Y.S.Ramakrishna at Sun.COM wrote:
> (Please take my comments with the requisite dose of salt because
> i know little about these CIObjects, so i may be talking nonsense
> in this context :-)
> How big could the (unified) table get? (Clearly in the case of the
> test that
> brought forth the problem it must become quite large, but perhaps
> an extreme case.) Still, I'd be wary of anything that
> requires a large table re-sort at each full gc, let alone at each
> (BTW, what do you do with non-perm stuff today where order is not
> across GCs? why not do that for all objects rather than rely on
> for the perm subset?) Of course, if the table is small, may be my
> concern is moot.
Size isn't the only determining factor. It would only have to re-sort
if get was called and it might only resort if it fails the binary
search lookup and a GC has happened since the last sort since it's
likely that a GC doesn't change the order. The tables aren't huge,
10-100 elements normally I would guess. Anyway it seems manageable if
we want it to be.
> -- ramki
> On 08/06/09 11:36, 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.
>>> -- ramki
>>>> -- John
More information about the hotspot-compiler-dev