RFR: Add flag to prevent multiple deopts on the same nmethod. [v4]

[Coleen Phillimore]

On Wed, 10 Nov 2021 14:23:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I added a flag to prevent the same nmethod from being optimized multiple times.  It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state.  Advice welcome.
>> I also don't know why the sweeper is so slow to get rid of these entries.
>> This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CodeCache::mark_all_nmethods_for_deoptimization does try to make the state go backwards.

Reopening.  This might be the simplest fix for the multiple deopt problem for loom running make_deoptimized() on nmethods more than once.  Alternative implementations need architectural changes to code cache walking and my other change depends on not needing the CompiledIC_lock for nop patching in the nmethods, which is semi-safe but may or may not interact with the oopmap patching for these nops.  ie. that needs more investigation but fix number 2 is a big less provably correct.

ctw is still really slow. Takes about 70 minutes on loom and 10 on mainline.

-------------

PR: https://git.openjdk.java.net/loom/pull/81