OpenSSL and panama-foreign

[Maurizio Cimadamore]

Just to be clear - can you see the cleaner working with your current 
implementation?

After thinking about your use case some more, I'm not convinced that 
what you do is enough to prevent reachability issues.

That is - the MH is kept alive by the CLinker runtime (at least until 
the scope is closed). But, with `bindTo`, the MH also keeps `this` alive.

It follows that, unless the scope is closed, `this` will never become 
unreachable. Which seems to defeat the point of registering `this` 
against a cleaner on construction?

Maurizio

P.S.

I did some experiments with your panama-foreign branch, and it seems 
like, when running the `ab` test, all calls to the cleaner action comes 
from the shutdown method, which invokes the cleaner's cloneable 
manually. If I remove the call to Cleanable::clean in shutdown, then I 
don't see any call to the cleanup action being executed for the entire 
duration of the benchmark.


On 11/11/2021 15:26, Maurizio Cimadamore wrote:
> I'm not sure I follow your point entirely.
>
> But yes, if you do a bindTo(this), then using an implicit scope is not 
> very useful as long as the scope is reachable from `this`.
>
> We might be able to refine the implementation and improve this in the 
> future, but for now I think that's something we have to live with.
>
> Thanks
> Maurizio
>
>
> On 11/11/2021 14:41, Rémy Maucherat wrote:
>> Unless I missed something the API has a side effect with upcalls. I
>> understand after reading the javadoc where the suggestion comes from,
>> as it makes memory management very much like Java. This is of course
>> excellent. However, I use upcalls (as you know) and many of them are
>> bound to an instance (since this makes state tracking very very nice).
>> This however creates a reference that never goes away and an implicit
>> scope is never going to get GCed and closed (I saw that with visualvm)
>> and memory leaks. Initially I was planning to use a static Map<Long,
>> State> for my state (OpenSSL allows passing references and getting
>> them in callbacks, but this is a lot handier in C and doesn't make a
>> lot of sense in Java), then I found MethodHandle.bindTo actually
>> worked and this is quite magical.
>>
>> So with that in mind, what is the recommendation ? Should the API
>> provide a way to remove the MethodHandle upcall ? Or should I avoid
>> using bindTo instead ?