> De: "Brian Goetz" <brian.go...@oracle.com> > À: "valhalla-spec-experts" <valhalla-spec-experts@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.sickelm...@gmx.de | sebastian.sickelm...@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.)