RFR: 8257189: Handle concurrent updates of MH.form better [v2]

[Peter Levart]

On Wed, 2 Dec 2020 11:37:07 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> I mean, is it possible that some threads that concurrently use the old uncustomized form while one thread is customizing it, trigger JIT compilation and because `form` field is trusted final, the JITed code will be using the uncustomized form for ever. Even after the customization thread plants the new form... This was possible before, but maybe the probability is greater after this change.
>
> Thanks for the review, Peter.
> The contract of `updateForm` clearly states that there are no guarantees provided about visibility:
>     /**
>      * Replace the old lambda form of this method handle with a new one.
>      * The new one must be functionally equivalent to the old one.
>      * Threads may continue running the old form indefinitely,
>      * but it is likely that the new one will be preferred for new executions.
>      * Use with discretion.
>      */
> It is used solely for performance reasons: install a faster LambdaForm variant and hope more users catch it.
> 
> Regarding `finally`, the intention of `updateInProgress` is to signal that there's a thread already preparing an updated form. Once it is done, the flag should be set back to `false` to allow more updates in the future. Indeed, there's a small window when another thread may succeed in acquiring the flag and performing the very same update, but (1) it's benign (it's still a performance optimization, so the more threads avoid redundant update the better);  and (2) there are fast-path checks in place (like `customized == mh` in `MH.customize()` or 'oldForm != newForm`) to detect such cases and don't waste resources.
> 
> Does it resolve your concerns?

I see. So a MH.form may be updated several times in succession.
I was just concerned that optimization in one part (less resources consumed updating the form) would increase the probability of JIT-ed code using the old form indefinitely - therefore causing regression in top performance. If you think that in spite of MH.form being trusted final field, such probability stays low, then my concern is unfounded.
Before the patch, each thread that saw opportunity to update form, started updating form immediately, therefore preventing JIT to kick-in before at least one of updated forms was installed on MH.form. Now, while one thread is updating the form, other threads freely execute the old form, so there is more opportunity for JIT to kick-in during that time and compile a constant-folded old form.
I wonder if it is possible to construct a concurrent test to provoke that. WDYT?

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

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