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

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.


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

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

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