RFR (S): 8033380: Experimental VM flag to enforce access atomicity (original) (raw)

Christian Tornqvist christian.tornqvist at oracle.com
Wed Feb 12 15:13:46 PST 2014

I agree, this (and any related experimental features) should be in a sandbox repo somewhere until we're sure that they're needed and tested sufficiently.

Thanks, Christian

-----Original Message----- From: hotspot-compiler-dev-bounces at openjdk.java.net [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Christian Thalinger Sent: Wednesday, February 12, 2014 6:06 PM To: Aleksey Shipilev Cc: hotspot compiler Subject: Re: RFR (S): 8033380: Experimental VM flag to enforce access atomicity

On Feb 11, 2014, at 3:02 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

Hi,

I understand we are still closed for integration? Please review this small feature meanwhile: https://bugs.openjdk.java.net/browse/JDK-8033380 http://cr.openjdk.java.net/~shade/8033380/webrev.02/ TL;DR: JMM 9 may need to extend the access atomicity over longs and doubles. Luckily, our logic in emitting the relevant access-atomic instructions is decoupled from memory barriers logic, and so we can "just" unconditionally go through needsatomicaccess where appropriate.

I'm not sure we should push this upstream. You say JMM 9 "may need" this feature. This feels premature to have it as an experimental feature in the JVM then. Experimental to me means it's a feature that might be useful to customers and they can try it if they want. That doesn't apply to this proposed "feature"; it's only useful for your testing purposes.

Testing: - full cycle JPRT - targeted microbenchmarks on x86/ARM/PPC Thanks, -Aleksey

More information about the hotspot-compiler-dev mailing list