RFR 8209624: [JVMCI] Invalidate nmethods instead of directly unloading them when the InstalledCode is dropped

[Tom Rodriguez]

The NoSafepointVerifier in make_not_entrant_or_zombie is unhappy because 
we're in the middle of a GC.  I think it's fine to call it in that case. 
  We just don't want a new one starting in the middle of that code so 
I'm going to relax the GC part of the assert.

   // This can be called while the system is already at a safepoint 
which is ok
   NoSafepointVerifier nsv(true, !SafepointSynchronize::is_at_safepoint());

I'll send out an email if the next run is clean.

tom

Vladimir Kozlov wrote on 8/17/18 12:24 PM:
> Tom, you have tests failed.
> 
> Vladimir
> 
> On 8/17/18 11:52 AM, Tom Rodriguez wrote:
>> http://cr.openjdk.java.net/~never/8209624/webrev
>> https://bugs.openjdk.java.net/browse/JDK-8209624
>>
>> When the lifetime of an InstalledCode instance is used to control the 
>> lifetime of the corresponding nmethod it's possible for the nmethod 
>> still have live activations when the nmethod is unloaded.  This is 
>> because the weak semantics of the installed_code means it isn't 
>> visited in the nmethod::oops_do phase.  We would have to sometimes 
>> maintain a second strong reference which was visited in 
>> nmethod::oops_do to make that work.  Instead simply invalidate the 
>> nmethod and let the sweeper unload the nmethod once it no longer has 
>> activations.  Note that this issue doesn't affect normal compiles 
>> requested the CompilerBroker since the InstalledCode reference is weak 
>> in that case.  The fix was tested with a Truffle program that 
>> originally exposed the issue.  mach5 runs are in progress.
>>
>> tom