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