On Thu, 5 Nov 2020 09:05:55 GMT, Aleksey Shipilev <sh...@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. > > src/java.base/share/classes/jdk/internal/reflect/NativeMethodAccessorImpl.java > line 66: > >> 64: && !method.getDeclaringClass().isHidden() >> 65: && >> !ReflectUtil.isVMAnonymousClass(method.getDeclaringClass()) >> 66: && ACCESSOR_GENERATED.compareAndSet(this, false, true)) { > > As the micro-optimization, checking that `accessor_generated` is `false` > before attempting a (potentially contended) CAS might fit better. (See > https://en.wikipedia.org/wiki/Test_and_test-and-set). Agree this could benefit performance. Grep jdk codes (grep -R compareAndSet *), not found codes with test and test-and-set pattern. compareAndSet is intrinsic and maybe it's better let runtime/compiler generate Test_and_test-and-set code sequence to solve all compareAndSet operations. ------------- PR: https://git.openjdk.java.net/jdk/pull/1070
