[foreign-jextract] RFR: 8263018: Improve API for lifecycle of native resources [v2]

[Maurizio Cimadamore]

On Wed, 24 Mar 2021 13:58:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Uhm.. in the new generated code this is not a problem - e.g. this is not what RuntimeHelper looks like in the new world. This is mostly a way to get libclang up and running. We could of course do what you suggest, I was unsure whether now is the time to do it (e.g. won't we regenerated libclang anyway?)
>
> Ah, ok. That makes sense.

This seems to be a list of "problematic" functions in a relatively simple jextract call:
at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getTranslationUnitCursor(Index_h.java:3525)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getCursorLocation(Index_h.java:4452)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getNullLocation(Index_h.java:821)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getFileName(Index_h.java:538)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getCursorType(Index_h.java:4934)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getTypeSpelling(Index_h.java:4945)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getCursorSpelling(Index_h.java:7181)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getTypeDeclaration(Index_h.java:5604)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getCursorDefinition(Index_h.java:7559)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_Cursor_getArgument(Index_h.java:5122)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getArgType(Index_h.java:5868)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getResultType(Index_h.java:5751)

at jdk.incubator.jextract/jdk.internal.clang.libclang.Index_h.clang_getCanonicalType(Index_h.java:5310)

Now, all of these seem ok. When we create a new Cursor, or a new Type, we always wrap a segment, so the segment is kept alive. Same is true for SourceLocation. For CXString, we have a method that takes a CXString and gives us back a j.l.String, so again, the string segment will be alive at least until it's converted to a java String, after which we no longer care.

Honestly, in some (all?) of these cases it's not super clear to me that _deallocation_ was happening in the previous code?

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

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