[GR-39182] Provide `@CEntryPoint`s to instantiate, pin, and unpin objects

[fniephaus]

To further improve the debugging experience of native executables, we need three @CEntryPoints:

• An entry point for allocating an object given a certain class/type, and
• two entry points to pin and unpin an object to ensure that a GC neither collects nor moves them at debugging time.

Potentially, we might want to allow allocating an object that is already pinned if the operation needs to be atomic.

[christianhaeubl]

The @CEntryPoints that we currently provide in the class DebugHelper are carefully designed in a way that they can be called from arbitrary native threads. Allocating Java objects and pinning Java objects is high-level functionality that can't be directly executed by arbitrary native threads because allocating a Java object may require a GC (and therefore a VM safepoint) or throw an exception.

Another issue is that gdb may pause Java threads at arbitrary code locations, for example in VM-internal code where it is not possible to allocate Java heap memory. At the moment, I think that it is only possible to execute high-level functionality if all application threads are at a safepoint (i.e., we would need to unpause the application threads and let them continue executing until they reach a safepoint).

In that case, it is probably easier to just use JNI instead of custom @CEntryPoint methods because there we already have all the functionality that is needed (FindClass, NewObject, JNI handles, exception handling). There would also be no need for object pinning because the JNI handles abstract the low-level details.

[olpaw]

@christianhaeubl I agree. That would be one possibility to provide everything that is needed without implementing a single line of code :grin:

The disadvantage of leveraging JNI for that is that to make the debugger have the ability instantiate any class or call any method that is in the image via JNI, the image would need to be build with an all-including JNI registration configuration. This might be seen as too intrusive for a debugger interface.

But if we would add a variant of GetMethodID that instead of taking a string takes the address of a method then we might be able to work around that. Makes sense?

[fniephaus]

@vvlevchenko has started to work on this and might provide an initial implementation for this soon.

[peter-hofer]

See #5184 for the current design of the advanced debugging API using JNI, addressing the issues of #4723. I have been busy with the 22.3 release up until now and there are quite a few issues that still need to be addressed. @vvlevchenko

[fniephaus]

We don't have plans to move this any further. Instead, we are currently working on #5648 and hopefully have something to show soon.