On Thu, Dec 7, 2017 at 12:28 PM Peter Levart <peter.lev...@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