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

Christian Thalinger christian.thalinger at oracle.com
Tue Feb 18 17:37:33 PST 2014

I withdraw my objection.

On Feb 14, 2014, at 4:48 AM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:

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