On Thu, 5 Nov 2020 09:07:13 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. > > I do wonder if it makes sense to handle triple-state `int` here: "not yet > generated", "generated", "in error"? So that we don't try to generate the > accessor over and over again when it is in error? If we are changing NativeMethodAccessorImpl.invoke then we should probably do NativeConstructorAccessorImpl.newInstance at the same time. Also wondering if we should, while in the area, add "return acc.invoke(obj, args)" after setting the delegate so that it invokes the newly generated accessor. Are there resource or other cases that you have observed where generateMethod fails and then succeeds in a subsequent call? @cl4es Do you know of any startup tests that might be sensitive to the eager creating of a VarHandle? I agree with @shipilev to test before the CAS. ------------- PR: https://git.openjdk.java.net/jdk/pull/1070
