review (L) for 7017732: move static fields into Class to prepare for perm gen removal
Y. S. Ramakrishna
y.s.ramakrishna at oracle.com
Wed Mar 16 17:10:57 PDT 2011
Never mind that remark. I see that in the case of the parallel
collectors, this does get done in parallel and is
in fact MT-safe.
Sorry for my confusion.
On 03/16/11 17:05, Y. S. Ramakrishna wrote:
> Hi Tom --
> ah, now that i went and looked at the code and the bug you filed (thanks!)
> i understand the problem, and your fix. I agree that there was a race
> and that your moving the fix_oop_relocations() into that epilogue method
> effectively fixes that by delaying the latter until the scavenge is
> effectively complete.
> -- ramki
> PS: Ideally i'd like this to some day get integrated into a subsequent
> weak oops phase of the GC infrastructure so that it can be done MT once
> weak oops processing is made entirely parallel, and also since it feels
> like the kind of work that's done for weak roots.
> I am guessing the lack of parallelism in this phase is nothing to lose
> one's sleep over at the moment (and may be never, but still FWIW).
> On 03/16/11 15:13, Tom Rodriguez wrote:
>> Hopefully this is the final version of this webrev. I found and fixed
>> a preexisting bug with ScavengeRootsInCode that boiled down to a race
>> between updating the oops in the nmethod and rewriting the oops in the
>> instruction stream. The fix is to call fix_oop_relocations after all
>> the nmethods have been visited by the scavenger. That changes
>> nmethod.cpp and codeCache.cpp which you can see in the updated version
>> of the webrev. I plan on pushing this to hotspot-gc once the weekly
>> sync and promotion has been done. Thanks for all the reviews.
More information about the hotspot-dev