RFR(M): 8227680: FastJNIAccessors: Check for JVMTI field access event requests at runtime
erik.osterlund at oracle.com
Thu Jul 18 13:52:56 UTC 2019
Okay, looks good in that case.
> On 18 Jul 2019, at 14:51, Doerr, Martin <martin.doerr at sap.com> wrote:
> Hi Erik,
> I like the idea, but it seems to be difficult.
> JNI function table can get copied and redirected at runtime (e.g. SetJNIFunctionTable).
> We'd have to synchronize with that to avoid messing it up.
> Also, I think the function pointers should better be made volatile if we change them concurrently.
> I have to think more about all of that, but I guess this approach will be more complicated than my initial proposal.
> Best regards,
>> -----Original Message-----
>> From: Erik Osterlund <erik.osterlund at oracle.com>
>> Sent: Donnerstag, 18. Juli 2019 08:43
>> To: Doerr, Martin <martin.doerr at sap.com>
>> Cc: hotspot-runtime-dev at openjdk.java.net; serviceability-
>> dev at openjdk.java.net
>> Subject: Re: RFR(M): 8227680: FastJNIAccessors: Check for JVMTI field access
>> event requests at runtime
>> Hi Martin,
>> Since the JNI calls go through function pointers in the JNI env that go either
>> to the fast or slow version, could one option be to go through the JNI envs
>> and change the function pointers to the slow one when this JVMTI feature is
>> 1) No need to change the platform specific code that seems to surprisingly
>> work right now.
>> 2) No need for the fast path to check that condition.
>> Just an idea.
>>> On 16 Jul 2019, at 15:31, Doerr, Martin <martin.doerr at sap.com> wrote:
>>> the current implementation of FastJNIAccessors ignores the flag -
>> XX:+UseFastJNIAccessors when the JVMTI capability
>> "can_post_field_access" is enabled.
>>> This is an unnecessary restriction which makes field accesses
>> (Get<Type>Field) from native code slower when a JVMTI agent is attached
>> which enables this capability.
>>> A better implementation would check at runtime if an agent actually wants
>> to receive field access events.
>>> Note that the bytecode interpreter already uses this better
>> implementation by checking if field access watch events were requested
>> (JvmtiExport::_field_access_count != 0).
>>> I have implemented such a runtime check on all platforms which currently
>> support FastJNIAccessors.
>>> My new jtreg test runtime/jni/FastGetField/FastGetField.java contains a
>> micro benchmark:
>>> shows the duration of 10000 iterations with and without
>> UseFastJNIAccessors (JVMTI agent gets attached in both runs).
>>> My Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz needed 4.7ms with
>> FastJNIAccessors and 11.2ms without it.
>>> We have run the test on 64 bit x86 platforms, SPARC and aarch64.
>>> (FastJNIAccessors are not yet available on PPC64 and s390. I'll contribute
>> them later.)
>>> My webrev contains 32 bit implementations for x86 and arm, but
>> completely untested. It'd be great if somebody could volunteer to review
>> and test these platforms.
>>> Please review.
>>> Best regards,
More information about the hotspot-runtime-dev