Short feedback on the linker (CLinker)

[Maurizio Cimadamore]

On 21/12/2020 13:08, Johannes Kuhn wrote:
> No objections to making it restricted.
> There is just a few things to consider:
> * The handle might have a long lifetime - possibly until the 
> application exits.
> * Tcl provides an upcall to "free" the data. In C, a function pointer 
> to free is a good implementation (if the pointer came from malloc). 
> This mode should be supported.
>
> (This mode would be surprisingly easy to implement using JNI - with 
> NewGlobalRef & DeleteGlobalRef.) 

As I was thinking more about this - it occurred to me that we are 
talking about related, but distinct functionalities. The pinning 
functionality I was referring to would allow to pass Java arrays to 
native code w/o copying. This typically means using an heap-based memory 
segment.

If you want to obtain a pointer for _any_ Java object, then you need to 
make the scope of the heap support a lot bigger than what we have 
currently - which is not impossible, but also harder to see how it can 
work reliably (while the layout of array elements in the Java heap is 
more or less standard, layout of fields inside instances is most 
definitively not - which seems like a risky dependency to have?).

Also, when doing any of this activity we need to take into account the 
security implications: the library loading machinery has been relaxed in 
Panama to allow for something that users have been asking for: being 
able to load library for multiple classloaders. This is possible only 
because Panama doesn't really pass Java objects "as is" into native 
functions. Of course, creating handles to instances and passing those 
handles around creates extra dependencies between the environment which 
created the handle, and the environment consuming it - again, not saying 
it's an impossible problem to solve, but more thinking is definitively 
required before we cross that particular bridge.

> Rarely structs. Mostly ordinary pointers.
> Just to provide a type-safe, object oriented interface.
> They have a few methods - they usually just call a MethodHandle with 
> this.base as first argument. (And the usual allocation stuff for 
> CStrings, out parameters, and error checking...)
What do you do for exposing type safe pointers? Do you use a single 
Pointer<X> class, or do you have a specialized pointer class for each 
pointee type? If you do the former (which IMHO is the one which leads to 
nicer API), how do you reconcile usability with performances? E.g. if 
you can create a Pointer<X> for _any_ X (e.g. given a layout), then it 
is very likely that the VarHandle needed to extract X is not a 
compiler-time constant, and that the pointer performances would take a 
pretty big hit compared to a plain var handle access.

Maurizio