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

[Tom Rodriguez]

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  
> 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.

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.

tom

>
> -- 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
>>>
>