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

Doerr, Martin martin.doerr at sap.com
Fri Jul 26 13:59:37 UTC 2019


Hi Boris,

thank you very much for testing.

Unfortunately, arm 32 was also affected by the issue Erik has found for aarch64:
We need a little stronger memory barriers to support accessing volatile fields with correct ordering semantics.

I've updated that in the current webrev already:
http://cr.openjdk.java.net/~mdoerr/8227680_FastJNIAccessors/webrev.02/

I'm using membar(MacroAssembler::Membar_mask_bits(MacroAssembler::LoadLoad | MacroAssembler::LoadStore), Rtmp2), now.
I've already used a cross build to check that it compiles, but I haven't run it.
I believe this membar doesn't have a significant performance impact.

Would be great if you could take a look and test that, too.

Thanks and best regards,
Martin


> -----Original Message-----
> From: Boris Ulasevich <boris.ulasevich at bell-sw.com>
> Sent: Freitag, 26. Juli 2019 12:50
> 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,
> 
> Your change works Ok on arm32 with the minor correction. See the patch
> attached.
> 
> thanks,
> Boris
> 
> On 16.07.2019 16:31, 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
> >


More information about the hotspot-runtime-dev mailing list