On Wed, 11 Nov 2020 05:38:08 GMT, Hui Shi <h...@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
