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