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

[Tom Rodriguez]

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?

tom

>
> --
> - Keith