On Thu, 26 Nov 2020 21:23:16 GMT, Vladimir Ivanov <vliva...@openjdk.org> wrote:
> Concurrent updates may lead to redundant LambdaForms created and unnecessary > class loading when those are compiled. > > Most notably, it severely affects MethodHandle customization: when a > MethodHandle is called from multiple threads, every thread starts > customization which takes enough time for other threads to join, but only one > of those customizations will be picked. > > Coordination between threads requesting the updates and letting a single > thread proceed avoids the aforementioned problem. Moreover, there's no need > to wait until the update in-flight is over: all other threads (except the one > performing the update) can just proceed with the invocation using the > existing MH.form. > > Testing: > - manually monitored the behavior on a stress test from > [JDK-8252049](https://bugs.openjdk.java.net/browse/JDK-8252049) > - tier1-4 Looks good to me! A couple of trivial nits inline.. src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 459: > 457: // asTypeCache is not private so that invokers can easily fetch it > 458: > 459: /*non-public*/ Remove `/*non-public*/` src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1769: > 1767: */ > 1768: /*non-public*/ > 1769: void updateForm(Function<LambdaForm,LambdaForm> updater) { `Function<LambdaForm, LambdaForm>` src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1754: > 1752: updateForm(new Function<>() { > 1753: public LambdaForm apply(LambdaForm oldForm) { > 1754: return oldForm.customize(mh); I think you can drop line 1751 and write this as `return oldForm.customize(MethodHandle.this);`. Simpler and might avoid an additional, implicit capture. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1472
