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).
--
- DML
