Updated VM-bridges document

[Remi Forax]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 11 Avril 2019 21:52:23
> Objet: Re: Updated VM-bridges document

> This was received through a side channel:

>> From: [ mailto:sebastian.sickelmann at gmx.de | sebastian.sickelmann at gmx.de ]
>> Subject: Re: Updated VM-bridges document

>> Hi,
>> i have a question regarding the discussed forwarding schema for fields.

>> Should it be possible to forward field access to methods, so that
>> we can safely remove public fields from the jdk in a binary compatible
>> way? Some time ago I experimented[1] with such a feature but unfortunatly
>> i haven't the time to continue on this.

>> There are some other things to solve when we map field access to method-calls.
>> One example is that we need a bootstraping-result for the put and the get I
>> think.
>> It would be nice if "forwarders for fields" could solve thie issue of public
>> fields
>> in jdk-api in future.

>> --
>> Sebastian

>> [0] [ http://mail.openjdk.java.net/pipermail/discuss/2015-December/003863.html |
>> http://mail.openjdk.java.net/pipermail/discuss/2015-December/003863.html ]
>> (last link to multple short threads)

> While the mechanism could surely be used for this (and more), I would prefer not
> to. The two main challenges for which we need field forwarders _at all_ are for
> access to fields through the wildcard type, and for migrating fields from
> value-based classes to value types. An example for wildcards:

> class Foo<T> {
> T t;
> }

> The specialized type `Foo<int>` will have a `t : int` field, but the wildcard
> type `Foo<?>` must be seen to have a `t : Object` field. But in reality, there
> needs to be one field. This is the main challenge for which we need field
> forwarder support.

> Migrating from fields to methods is an attractive target, but with it comes a
> great risk for abuse: "lookie, here's properties." And the reason I don't want
> to support this is that field access `t.f` has a known cost model (field access
> is fast) and known error model (throws few exceptions.) The more that arbitrary
> code could be run at field access time, the more we undermine that. So I want
> to restrict field bridges to:

> - Bridges for an _actual field only_
> - Limited set of adaptations: cast/null-check only

> This is enough to support the wildcard case and the L->Q migration case. I would
> strongly prefer to stop there.
Also i don't see how you can support the VarHandle API if a field is actually forwarded to methods, or forwarded to methods means that you have to re-implement all the VarHandle API (at least, get_volatile, set_volatile and CAS) when you want to forward a field ? 

Rémi 

>> #### Forwarders for fields

>> The forwarding strategy can be applied to fields as well.  In this
>> case, the forwardee descriptor is that of a field descriptor, and the
>> behavior has the same semantics as adapting a target field accessor
>> method handle to the type of the bridge descriptor.  (If the forwarder
>> field is static, then the field should be static too.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20190411/127f6423/attachment.html>