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

[Doerr, Martin]

Hi David and Erik,

thank you for looking at my proposal.

> If you try to use fast field accessors when you have to post the field
> access event then how can you safely go off into a JVM TI event callback ??

We speculatively load the field and check afterwards if we can use this loaded value.
It is safe to use it if there was no safepoint and no JVMTI event was requested.
Otherwise, we simply discard the (possibly) loaded value and load it again in the slow path where we do all the synchronization and event posting.

@Erik:
Thanks for your proposal to change the function pointers. I'll look into that.

Best regards,
Martin


> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Donnerstag, 18. Juli 2019 06:39
> To: Doerr, Martin <martin.doerr at sap.com>; 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,
> 
> I need to think about this some more. A critical property of the fast
> field accessors are that they are trivial and completely safe. They are
> complicated by the need to check if a GC may have happened while we
> directly read the field.
> 
> If you try to use fast field accessors when you have to post the field
> access event then how can you safely go off into a JVM TI event callback ??
> 
> Thanks,
> David
> 
> On 16/07/2019 11:31 pm, Doerr, Martin 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
> >