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

[sundararajan.athijegannathan at oracle.com]

Thanks for the review.

I'll rename "$make" as "allocate". As for non-explicit cleanup, I'll 
revisit by another issue (as discussed offline)

-Sundar

On 30/04/20 4:05 pm, Maurizio Cimadamore wrote:
> 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