RFR (S) 8043070: nmethod::verify_interrupt_point() shouldn't enter safepoint

[dean.long at oracle.com]

Hi Igor.  The changes look good.  Thanks for not changing the values for 
the other states.  It would have broken AOT :-)

Are there any situations where make_in_use() might need a 
compiler/memory barrier?

I was thinking about an alternative approach, at least for this case.  
We could have NoSafepointVerififer always set 
_thread->_allow_safepoint_count (right now it doesn't for product 
builds), then verify_interrupt_point() could check that flag before 
taking the path that can safepoint.  Or how about just using 
nmethodLocker as suggested in 8028001?  Or does having a new state help 
solve other problems?

dl


On 11/16/17 11:08 AM, Igor Veresov wrote:
> The problems here is that the sweeper can transition a newly created nmethod to not_entrant state before it’s installed. This breaks the logic in nmethod::verify_interrupt_point() called at the end of the installation process. As a result locks might be taken in that can safepoint and safepoints are forbidden during the method install.
>
> The solution is to introduce an new nmethod state: not_installed. The goal is to be able to prevent certain things like sweeping or parts of the verification happening during the nmethod installation.
>
> The change passed the failing test and the internal mach5 pre-intergration testing.
>
> Webrev: http://cr.openjdk.java.net/~iveresov/8043070/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8043070
>
> Note, this also fixes: https://bugs.openjdk.java.net/browse/JDK-8028001
>
> Thanks!
> igor