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
