Finalization and dead references: another proposal

Vitaly Davidovich vitalyd at gmail.com
Thu Dec 7 17:46:41 UTC 2017


On Thu, Dec 7, 2017 at 12:28 PM Peter Levart <peter.levart at gmail.com> wrote:

> Hi,
>
> On 12/07/2017 03:27 AM, Vitaly Davidovich wrote:
> > So kind of the opposite of WeakReference - a SuperStrongReference :).
> >
> > Kidding aside, it seems like the way you’d want to encapsulate this at
> the
> > language level is via a type that the JVM intrinsically knows about; in
> > this way it’s similar to the reference types today.
> >
> > An annotation probably does the trick when the value doesn’t escape from
> > the enclosing instance but I’ve no idea if that assumption covers enough
> > code to warrant this approach.  AFAICT, if the value escapes into an
> > instance of another type that doesn’t annotate its field then all bets
> are
> > off.
> >
> > Having a wrapper type would at least make it harder to leak the  native
> > handle vs the annotation approach.  But of course the wrapper comes with
> > footprint and indirection costs.  Maybe Valhalla could allow exposing
> some
> > magic value type that’s a zero-cost wrapper but preserves the type
> > information the JIT can track?
>
> There is a middle-ground. By (ab)using value types only and no special
> JIT magic.
>
> DirectBuffer(s) for example, could return the address not in a long, but
> in a value type like the following (using valhalla MVT speak):
>
> public __ByValue final class Address {
>      private final long address;
>      private final Object referent;
>
>      public _ValueFactory static Address create(long address, Object
> referent) {
>          Address a = __MakeDefault Address();
>          a.address = address;
>          a.referent = referent;
>          return a;
>      }
> }
>
>
> DirectByteBuffer for example, would have the following address() method:
>
> private long address;
>
> public Address address() {
>      return Address.create(address, this);
> }
>
> Notice that 'address' field of Address value is encapsulated, so Java
> code can't access it directly nor it needs to. Native / Unsafe methods
> would be taking Address values instead of long(s), making sure the
> embedded referent is kept reachable.
>
> This is equivalent to passing the DirectBuffer reference to the native
> method(s) together with the address value, but enforced by the API so
> the programmer can not make a mistake. There's a lot of arithmetic going
> on with addresses, inside and outside of DirectBuffer implementations.
> Such arithmetic would have to be performed by the Address value type
> itself, making sure the results of operations on Address values are
> Address values that maintain the same referent. For example:
>
> public __ByValue final class Address {
> ...
>      public _ValueFactory Address plus(long offset) {
>          Address a = __MakeDefault Address();
>          a.address = address + offset;
>          a.referent = referent;
>          return a;
>      }
> ...
>
> So no magic here. Just API.

This is an API version of Hans’s #3 approach.  As he said, there’s
performance overhead and nothing guarantees that the referent is kept alive
- that’s an implementation artifact.

I think without the VM knowing about these things intrinsically it’s not a
100% reliable solution because it’s not concretely requesting a certain
behavior.

>
>
> Regards, Peter
>
>
> --
Sent from my phone


More information about the core-libs-dev mailing list