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

[Aleksey Shipilev]

And I disagree, because:

 * The change is simple, non-intrusive, obviously correct, and has no
impact on the default operation of the VM.

 * We are expecting larger testing, including the testing outside Oracle
for JMM-related VM changes. Keeping them easily accessible for hardware
vendors, Porters, and other non-JVM-developing people significantly
broadens the testing surface.

 * The empirical testing is, among other things, what we are after in
the course of JMM work to get the decision right. Handicapping the
access to experimental feature like this means less testing, and in
turn, the potential introduction of un-fixable spec mistake which will
haunt us for years to pass.

 * The overhead of maintaining the sandbox repository for the simple
change, syncing it up with master, doing the builds is considerably
large. It is further complicated by the presence of Porters who maintain
their own forks out of master for the alternative hardware platforms of
interest. That makes already hard JMM work even harder.

Given all that, the advantages of having the (simple) experimental
features for JMM work in the mainline greatly outweigh the (virtual)
disadvantages.

Thanks,
-Aleksey.

On 02/13/2014 03:13 AM, Christian Tornqvist wrote:
> 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 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
> 
>