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

[Doerr, Martin]

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
> >