Finalization and dead references: another proposal

[Vitaly Davidovich]

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

>
>
> On 12/07/2017 06:46 PM, Vitaly Davidovich wrote:
>
> 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.
>
>
> I would say that for JNI "there’s performance overhead XOR nothing
> guarantees that the referent is kept alive", because the overhead is caused
> by reference parameter management that guarantees that the referents are
> kept alive while the native method executes and may access them. Can we
> live with such overhead? I don't know. Would have to measure if it really
> presents a problem.
>
I'd say the bigger overhead is in JNI argument marshaling.  But JNI is
already costly so I don't know.

>
> The magic would have to be performed by intrinsified method(s) (Unsafe for
> example), but they are just few and developed by select group of developers.
>
> The main problem I think is not the overhead of passing referents together
> with addresses to JNI functions and their overheads, but lack of
> enforcement for this to be performed consistently. It's just too easy to
> split the native resource from the referent that keeps it into two parts
> with each having separate lifetime. API with value types could enforce such
> pairs (address, referent) to be kept together until they hit the final leaf
> operation which is typically a native method where the referent(s) are
> either automatically kept alive or would have to be manually, but such
> methods are in minority.
>
I agree that the main problem is how to not "detach" these things by
accident.  To that end, you want to bundle them together as tightly as
possible, and prevent de-encapsulation by the users (or at least make it
harder and more explicit).  This is why I threw value types out there since
I think they might provide a better solution than an annotation, which I
suspect will be very easy to accidentally circumvent.

But ultimately, you really want the JVM to understand about "foreign
resources/pointers" in a 1st class/principled manner, which suggests a type
based approach (I'm assuming a language approach is off the table :)).
Since this type would be requesting special handling by the JVM, it's hard
to make it library/API only.  Or rather, it would be hard, if not
impossible, to make it library/API only but then not suffer performance
consequences.  You also don't want to accidentally omit or put the
reachabilityFence() in the wrong place or on the wrong object, both things
possible with one careless refactoring (gone wrong).

>
> Regards, Peter
>
>