OpenSSL and panama-foreign

[Maurizio Cimadamore]

On 07/12/2021 14:40, Rémy Maucherat wrote:
> My problem is already described by
> https://bugs.openjdk.java.net/browse/JDK-8254693

Ok - but that's about passing heap memory directly to native code, which 
is quite an advanced use case; from your description it sounded like an 
issue with direct buffer and segments.

Passing heap memory to native code requires heap pinning. Not all GC 
take pinning well - it is relatively trivial to do in the API - but 
outcome will vary depending on which GC you happen to run on.

AFAIK, most implementation end up blocking the whole GC:

https://tschatzl.github.io/2021/06/28/evacuation-failure.html

Shenandoah seems to differ, at least according to this:

https://shipilev.net/jvm/anatomy-quarks/9-jni-critical-gclocker/

This means that, unless you are using Shenandoah, even if we did provide 
an API to pin heap segments, you will end up with more troubles than the 
ones you started with.

That said, this is an area we're monitoring. As soon as GC impl will 
catch up (and G1 seems to be moving in the right direction), we will add 
some support.


>
>>> - Could there be some opportunities for stronger typing with the code
>>> that jextract generates ? I (not very surprisingly) experienced a few
>>> bugs caused by the wrong address being passed to a call. Example:
>>> could there be a Pointer<TYPE> as a "fake" type for a MemorySegment,
>>> but providing strong typing ?
>> We remain on the outlook for such opportunities - at the moment,
>> introducing these types is not possible w/o a significant cost in terms
>> of instances being created and/or additional overhead on memory
>> dereference (or both). Some future language/VM features (Valhalla) might
>> significantly change the peformance trade off, iin which case we will
>> obviously reconsider.
> Ok ! As of right now, I was not hoping for real Java types, you seem
> to imply that's what you would like to have (if that's doable
> eventually, this would be waaaaay beyond my wildest expectations !).
> Instead, for now, I was only thinking about empty marker types, just
> to give a compiler hint and produce errors (mostly when using the
> wrong pointer type for a downcall) without really doing anything more.
> Just a dumb code generation trick, essentially ...
> For example: jextract generates an "SSL" empty class (which I filter
> out since it's not actually useful). Instead of doing nothing with it,
> this marker type could be matched to the native code signatures and
> used in the generated code as a generic to a type that extends
> MemoryAddress/Segment.

We could definitively generate wrappers for structs - but that would 
mean that when reading/writing more allocation will occur (as you will 
have to allocate a struct which is a view of a segment/address). 
Moreover, this will only work if what you have is a struct - if you work 
with an int*, there will be no wrapper generated for that.

So, while I'm all for sprinkling useful info, it is not very clear to me 
what we can sprinkle on top of what we have to make it more useful (w/o 
resorting to a full blown higher-level pointer/struct API).

Maurizio