[foreign-jextract] RFR: 8244172: jextract should generate upcall stub creating helper in the functional interface class

[Maurizio Cimadamore]

On Thu, 30 Apr 2020 10:14:51 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> * moved the upcall stub creating utility method as static method of functional interface
> * added free upcall stub utility to RuntimeHelper
> * added a simple test for function pointer callback

src/jdk.incubator.jextract/share/classes/jdk/incubator/jextract/tool/HeaderBuilder.java line 114:

> 113:         indent();
> 114:         sb.append(PUB_MODS + "MemoryAddress $make(" + className + " fi) {\n");
> 115:         incrAlign();

I'd call this "allocate" for similarity with other constructs.

src/jdk.incubator.jextract/share/classes/jdk/incubator/jextract/tool/resources/RuntimeHelper.java.template line 81:

> 80:     public static void freeUpcallStub(MemoryAddress addr) {
> 81:         ABI.freeUpcallStub(addr);
> 82:     }

Perhaps we could register the returned MemoryAddress with a cleaner and then let the GC pick it up and call the
`freeUpcallStub` ? Note that either way we're unsafe - e.g. a client might call this `freeUpcallStub` method while some
native code is accessing it (which causes a crash). Or the memory address might become unrecheable while some native
code is accessing the upcall. So, either way, some discipline is required.

What I like more about the cleaner approach is that, like with libraries, code is typically longer-lived than
allocations, so, IMHO it makes sense to leave that one to the GC, so that the user code doesn't have to worry about
deallocating that.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/138