JEP 193: Enhanced Volatiles (original) (raw)

David M. Lloyd david.lloyd at redhat.com
Thu Mar 6 15:38:35 UTC 2014

On 03/06/2014 09:25 AM, Florian Weimer wrote:

On 03/05/2014 01:05 AM, Doug Lea wrote:

On 03/04/2014 05:12 PM, Florian Weimer wrote:

On 03/04/2014 01:05 PM, Doug Lea wrote:

On 03/04/2014 02:41 AM, Jeroen Frijters wrote:

I understand pass-by-reference is an expensive feature, but IMNSHO poluting Java with this proposal will prove to be more expensive in the long run. It's like erased generics all over again.

The expensive version of pass-by-reference is already supported using java.lang.reflect.Field. And per the statistics posted in <http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025531.html>, the slightly faster pointer-to-field-member support is one of the prevalent use cases for sun.misc.Unsafe. That's why I share Jeroen's puzzlement. Sorry, I'm not sure what usages you have in mind, or what constructions and implementable JVM mechanics could be used to deal with them? If we had lightweight pointer-to-fields, things like compare-and-swap could be implemented as regular intrinsics. It would require less magic syntax, and make it clear that the operations only work with non-static fields and not on local variables etc. It would be possible to write functions that apply a complex sequence of updates to a field, which is impossible under the current proposal. (One aspect I like about Java is that is fairly uniform, e.g., that you can take a subexpression and turn it into a function, or that you can store intermediate results, something that is often impossible in Ada or C++). Pointer-to-fields could be as lightweight as a single integer (they are in C++ and with sun.misc.Unsafe), assuming that the VM enforces type safety. Whether it is a good idea to add another generic type at the VM level before the arrival of reified generics, is a different matter.

The proposed interface types could be used as such a "pointer", with the caveats I've given in another branch, that we'd really want the object "allocation" to be free or cheap in most cases.

It's one construct that is effectively missing from JUC today. There is a "updater for field X on any object" and "updater for otherwise inaccessible field X on object Y" but there's no "updater for field X on object Y". The "foo.volatile" syntax could provide that, though this does run counter to the JEP which indicates that a raw "foo.volatile" is not by itself a valid expression.

But the optimizability of the construct is really the key decision axis as far as I can see; specifically it would have to be able to optimize "foo.volatile.xxx()" constructs directly to the minimal set of instructions while still allowing "foo.volatile" to return a real object that can be fiddled with by others. In particular it would be really annoying if you had to manually maintain another field to hold this hypothetical value of "foo.volatile" to avoid creating a new one every time (though I think it's perfectly reasonable for the JVM to create a "hidden" field which does this in the case where this value escapes the stack).

--

More information about the core-libs-dev mailing list