Hi Martin, Okay, looks good in that case.
Thanks, /Erik > On 18 Jul 2019, at 14:51, Doerr, Martin <martin.do...@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.osterl...@oracle.com> >> Sent: Donnerstag, 18. Juli 2019 08:43 >> To: Doerr, Martin <martin.do...@sap.com> >> Cc: hotspot-runtime-...@openjdk.java.net; serviceability- >> d...@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.do...@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 >>> >
