RFR (S): 8033380: Experimental VM flag to enforce access atomicity
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.
From: hotspot-compiler-dev-bounces at openjdk.java.net
[mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of
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>
> I understand we are still closed for integration?
> Please review this small feature meanwhile:
> 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.
> - full cycle JPRT
> - targeted microbenchmarks on x86/ARM/PPC
More information about the hotspot-compiler-dev