RFR: 8220606: Move ScavengeNMethods unlinking to unregister_nmethod

[Stefan Karlsson]

Hi Per,

On 2019-03-14 09:59, Per Liden wrote:
> Looks good,

Thanks.

  but it looks like we could remove
> ScavengableNMethods::flush_nmethod() completely now. Don't need a new 
> webrev if you decide to do that.

As discussed offline.

My intention with the code was to view ScavengableNMethods as the 
implementation of the "virtual" interface needed to deal with nmethods 
from a GC's point-of-view. The GCs using ScavengableNMethods would 
simply delegate to this implementation, and not have to know if it 
needed to call flush (or any of the other functions) or not.

Your proposal changes ScavengableNMethods from being _the_ 
implementation of nmethod handling for GenCollectedHeap and 
ParallelScavengeHeap, and conceptually change it to be a utility class 
used by these GCs to implement their handling of nmethods.

I prefer my interpretation of this, but I also see that we already 
decide to skip implementing verify_nmethods in ZCollectedHeap instead of 
delegating to ZNMethod. So, there's already a precedence in that code. :)

Updated with your proposal:
  http://cr.openjdk.java.net/~stefank/8220606/webrev.02.delta
  http://cr.openjdk.java.net/~stefank/8220606/webrev.02

StefanK


> 
> /Per
> 
> On 3/14/19 9:33 AM, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review this patch to move the removal of non-alive nmethods 
>> from the scavengable nmethods list from the flush/purge phase into the 
>> unregister_nmethod call.
>>
>> This will prevent the GCs from scavenging dead nmethods.
>>
>> http://cr.openjdk.java.net/~stefank/8220606/webrev.01/
>> https://bugs.openjdk.java.net/browse/JDK-8220606
>>
>> Tested with tier1-3.
>>
>> Thanks,
>> StefanK