RFR (S): 8143571: [JVMCI] Double unregistering of nmethod during unloading

[Tom Rodriguez]

Thanks for the reviews.

tom

> On Dec 4, 2015, at 4:09 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> Yes, seems good.
> 
>> On Dec 4, 2015, at 11:02 AM, Tom Rodriguez <tom.rodriguez at oracle.com <mailto:tom.rodriguez at oracle.com>> wrote:
>> 
>> http://cr.openjdk.java.net/~never/8143571/webrev.00/ <http://cr.openjdk.java.net/~never/8143571/webrev.00/>
>> 
>> This is a follow on fix for 8142436 which introduced some assertion failures when running with G1.  They were benign in practice but it indicated that more careful updating of those field was required.  In the end the idea is that we never clear the _installed_code field using the barrier logic except during the do_unloading methods.  The other places we want to clear the installed code is when becoming unloaded or zombie and those are explicitly unregistered anyway.  We explicitly clear _installed_code after the unregister for clarity instead.
>> 
>> It also became clear that we needed to ensure that updates to the installed code were performed under a lock to make sure it had a consistent state.  Since part of the updates were already being done under the Patching_lock because they were part of make_not_entrant_or_zombie, I used the Patching_lock in other places to protect updates.  This has been in our graal repo with nightly fastdebug testing for the last few weeks without issue.
>> 
>> tom
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151207/48b86387/attachment.html>