review request (S) 6866585 debug code in ciObjectFactory too slow

[Y.S.Ramakrishna at Sun.COM]

(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 that's
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 scavenge...
(BTW, what do you do with non-perm stuff today where order is not preserved
across GCs? why not do that for all objects rather than rely on ordering
for the perm subset?) Of course, if the table is small, may be my concern is moot.

-- 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.
> 
> tom
> 
>>
>> -- ramki
>>
>>> -- John
>>
>