[foreign-abi] RFR: JDK-8243669: Improve library loading for Panama libraries

[Maurizio Cimadamore]

On 05/05/2020 23:56, Samuel Audet wrote:
> you're not even using the same API for memory layouts and library 
> loading! In other words, why not make it (even) easier to implement 
> for *any* type of resources? What are the roadblocks that we should 
> start to look at? 

I think we're going in circles. The PR summary explains why we can't use 
the same mechanism for segment deallocation (not layouts, as you say, 
which have no such needs) and native libraries. It all goes back to 
confinement.

Even with the API I proposed like this:

Pointer p ....
p.withHandle(PointerHandle ph -> {
       ph.get(...)
       ph.set(...)
});
p.deallocate() // will fail if there are any pending handles


There is a big caveat; this idiom only guarantees 100% safety is the 
pointer handle you obtain is unusable from other threads. This 
restriction might be fine for memory access - after all, a thread might 
get a pointer to some struct, might want to read/write contents, and do 
that in a lexically scoped way. That's the principle behind scopes.

But I simply don't buy that what works for memory works for libraries. 
If you keep pulling on this string that means that, to be able to use a 
native library, each thread would have to create its own private version 
of the library method it wants to use, which seems overkill.

I'm all for unification and minimizing abstractions... where it makes 
sense. In this case I just don't see it. If we come across another 
abstraction which shares similar aspects to the way in which memory 
segments are handled (and as I noted, Project Loom is exploring _a lot_ 
of this stuff), we might provide some common abstraction in that 
direction, but I can say with certainty that it won't look like a 
ref-counting API abstraction (which is what you asked for at the 
beginning of this thread).

Maurizio