Updated VM-bridges document

[Brian Goetz]

This was received through a side channel:

> From: 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   (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.




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