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

[Marcus Lagergren]

Even though I am generally against pushing experimental stuff into the JVM, I think given the relative brevity/loose coupling of the change and the release schedule for JDK9, that we won’t hurt much for getting it in. If it simplifies the JMM work as Aleksey says before, it might be worth it.

/M

On 13 Feb 2014, at 00:45, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

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