[GR-38671] allow native-images to be directly called by C/C++ code, better cinterop

[revintec]

according to the docs(https://www.graalvm.org/22.1/reference-manual/native-image/#build-a-shared-library https://www.graalvm.org/22.1/reference-manual/native-image/ImplementingNativeMethodsInJavaWithSVM/), native-images can export symbols to be used by C/C++ code, however an isolate parameter is required, thus making it impossible for C/C++ code to call transparently(i.e. without knowing that it was implemented by native-image), e.g. using only dlopen and alike.

having to detour around C/C++ complicates the build process, for example when writing plugins like a pam module(https://en.wikipedia.org/wiki/Linux_PAM https://en.wikipedia.org/wiki/Pluggable_authentication_module). one should be able to do so purely relying on Graal VM techs, but now have to also write a C/C++ wrapper so that wraps the native-image lib.

I purpose the following: add an argument to @CEntryPoint, e.g. named isolate, that is a enum. currently supporting two values: GLOBAL and ONE_SHOT, and remove the need for a required isolate parameter on method signature. GLOBAL means all invocation of such methods share a single global isolate, while ONE_SHOT means the isolate is created just before the invocation and destroyed immediately after a return value is obtained.

these two modes may have performance implications, but user is explicitly opting in using @CEntryPoint(isolate=...) so it should be fine.

---

another usability improvement would be to always make a shared object executable(aka make a binary that is loadable), thus eliminating the -shared build parameter. it is at least possible in ELF(https://unix.stackexchange.com/questions/223385/why-and-how-are-some-shared-libraries-runnable-as-though-they-are-executables) and PE format. this way users don't have to build two versions of a potentially very large release one for shared object(linux .so) and one for direct running/easier testing(binary executable), for every platform.

if no main methods is found, the build should continue but a warning may be shown.

---

thanks for considering

[oubidar-Abderrahim]

Thank you for your suggestion, we will take a look into this and get back to you. Tracked internally on GR--38671

[revintec]

@oubidar-Abderrahim Hi, is there any update? thx

[revintec]

@oubidar-Abderrahim please update this issue as oracle internal issues are not publicly visible, thanks

[wirthi]

We treat this as interesting idea, but have no resources currently working on this.