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

Y.S.Ramakrishna at Sun.COM Y.S.Ramakrishna at Sun.COM
Thu Aug 6 11:27:09 PDT 2009

On 08/06/09 11:13, John Rose wrote:
> On Aug 6, 2009, at 11:07 AM, Y.S.Ramakrishna at Sun.COM wrote:
>> Current GCs in hotspot will never reorder perm gen objects.
> And that's been true in all the years since we wrote the paranoid CI 
> code.  It's just waiting for that day when all its fears are 
> justtified!  :-)

Right; and the debug mode check should i think be sufficient to catch that; but yes
who knows about how frequently that would happen in testing/debug mode,
so perhaps having a diagnostic mode check would be OK, too. I yield :-)

>> Of course having the check at every full gc seems fine in debug
>> mode. The diagnostic mode may be paranoid given our current GC's,
>> but is fine to have if you feel that would still be worthwhile.
> 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.

-- ramki

> -- John

More information about the hotspot-compiler-dev mailing list