RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod…

[Hui Shi]

On Thu, 5 Nov 2020 09:05:55 GMT, Aleksey Shipilev <shade 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.
>
> 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