OpenSSL and panama-foreign

[Jorn Vernee]

>> - It seems bound upcalls will always leak memory, there's no way to
>> release them. Is a functional fix possible in the future ?
>
> In this case, the issue is that if you use implicit scope with an 
> upcall, and the upcall has a strong reference (via its method handle) 
> back to the scope, there is an (unavoidable, I think) issue: the 
> method handle is stored somewhere (as a global JNI handle) in the VM 
> stub. This is enough to keep the MH alive (which we need to), but 
> also, indirectly (as the scope is attached to the MH in your case), to 
> keep the scope alive. If we create a weak handle on the VM stub side, 
> that would solve the issue in terms of the stub not keeping the 
> reachability on the scope - but it will create other issue (e.g. an 
> upcall crashing because the MH it refers to has disappeared). Jorn and 
> I have thought about this case a bit - at the moment we don't have any 
> clever ideas - I think using bound MHs with VM upcalls is something to 
> be used with care, given implications on reachability.
>
> But we'll keep thinking of course.


After our last discussion I thought some more about this. Essentially, a 
cleaner's cleanup action can not (directly or indirectly) reference the 
object being cleaned up. If we were able to do that, we could 
potentially resurrect the object being cleaned up, and any other object 
that it references as well, which might also already be dead (no 
guarantee on the order in which objects are cleaned).

This applies to implicit scopes as well: a scope cleanup action can not 
reference the scope. We register the upcall stub on a scope with a 
cleaup action, so the method handle can not reference the scope either. 
I don't think there's a way around that, even if we dropped the use of a 
global JNI handle, there's still a need for the stub to reference the 
method handle, and keep it alive.

I think for cases where a cycle is an absolute requirement, where the 
method handle of an upcall stub references the scope the upcall stub is 
registered against, the solution is to have an 'outside observer' 
object, which isn't a part of the cycle itself, and register a cleanup 
action on that object instead:

     observer -\
                      scope -> ... -> upcall stub -> ... -> scope

The scope would be a shared scope instead of an implicit scope, and a 
cleanup action would be registered on the observer object which would 
close the scope. When the cleaner runs, the entire cycle would be 
released at the same time.

Jorn