Finalization and dead references: another proposal

[Peter Levart]

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.

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.

Regards, Peter