Finalization and dead references: another proposal (original) (raw)

Peter Levart peter.levart at gmail.com
Thu Dec 7 17:28:50 UTC 2017

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.

Regards, Peter

More information about the core-libs-dev mailing list