RFR(M): 8227680: FastJNIAccessors: Check for JVMTI field access event requests at runtime

[Erik Osterlund]

Hi Martin,

Okay, looks good in that case.

Thanks,
/Erik

> 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,
> Martin
> 
> 
>> -----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
>> enabled?
>> 
>> Advantages:
>> 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.
>> 
>> Thanks,
>> /Erik
>> 
>> 
>>> On 16 Jul 2019, at 15:31, Doerr, Martin <martin.doerr at sap.com> wrote:
>>> 
>>> Hi,
>>> 
>>> 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:
>>> test-
>> support/jtreg_test_hotspot_jtreg_runtime_jni_FastGetField/runtime/jni/Fa
>> stGetField/FastGetField.jtr
>>> 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.
>>> 
>>> Webrev:
>>> 
>> http://cr.openjdk.java.net/~mdoerr/8227680_FastJNIAccessors/webrev.00/
>>> 
>>> 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,
>>> Martin
>>> 
>