RFR: 8268052: [JVMCI] non-default installed code must be marked as in_use

[Tom Rodriguez]

On Tue, 1 Jun 2021 19:43:06 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciRuntime.cpp line 1789:
>> 
>>> 1787:               method->set_code(method, nm);
>>> 1788:             } else {
>>> 1789:               result = JVMCI::nmethod_reclaimed;
>> 
>> Is it really possible for the make_in_use call to fail if the nmethod is nmethodLocker'ed?  The copy of this logic in ciEnv.cpp doesn't treat a failure of this call to be a compilation failure but it certainly seems like it should.  It would be better if it weren't possible for this call to fail.
>
> The issue is that the nmethod is published to Method code pointers before it is made in_use. That means a concurrent JavaThread may enter it and make the nmethod not_entrant, before it is made in_use. Making it in_use after it became not_entrant would cause a non-monotonic state transition which isn't great and comes with problems.
> I agree it feels like there is room for improvement here, but at least that is the reason why make_in_use can fail; to prevent non-monotonic state transitions in this race.

Ok.  I see the intent. In that case it seems like the reordering of the in_use and set_code calls was the important part of JDK-8226705.  It can't actually fail here since it hasn't been published until the following line, right?  Or is there some other way the nmethod is published?  Why couldn't the in_use state be set at the end of the nmethod factory method?

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

PR: https://git.openjdk.java.net/jdk/pull/4283