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.
--
Florian Weimer / Red Hat Product Security Team
