review (L) for 7017732: move static fields into Class to prepare for perm gen removal

[Y. S. Ramakrishna]

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

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 
> before
> 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 
> parallel
> 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.
>>
>> tom