RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod… [v5]

[Alan Bateman]

On Wed, 11 Nov 2020 05:38:08 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> …AccessorImpl object
>> 
>> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>> 
>> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
>> 
>> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.
>
> Hui Shi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 44:

> 42:     private DelegatingConstructorAccessorImpl parent;
> 43:     private int numInvocations;
> 44:     private int generated;

What is the reason for using an int? I remember there was a suggestion for three states but two states seems okay so curious why it was changed from boolean to int.
The restoring to 0 in the event of failure should probably be a volatile-write. Might be clearer to declare it as a volatile.

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

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