JVM crashes when trying to resolve a "new" method from within an upcall

[Sebastian Stenzel]

Thanks for replying that fast (again), I can confirm the flag works! Looking forward to a fix. :-)

> On 14. Jun 2021, at 13:01, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Hi,
> it seems a problem with upcall optimization not working correctly when upcall is called from a "fresh" thread created in native code.
> 
> We'll work on a fix (Jorn tells me that JNI already correctly handles these cases), in the meanwhile, you can obtain the "old" behavior by disabling upcall optimizations, by passing the following flag:
> 
> -Djdk.internal.foreign.ProgrammableUpcallHandler.USE_INTRINSICS=false
> 
> Cheers
> Maurizio
> 
> On 14/06/2021 10:53, Maurizio Cimadamore wrote:
>> This is odd, our jextract is using the API and it is regularly doing things like the one you describe (e.g. calling CLinker methods inside upcalls).
>> 
>> That said, toJavaString is a restricted method, so there might well be something in the support for restricted method that doesn't play well with upcalls (but that's also odd, given there should be a caller class in there somewhere).
>> 
>> We'll look more into this.
>> 
>> Thanks
>> Maurizio
>> 
>> On 13/06/2021 20:04, Sebastian Stenzel wrote:
>>> I experience a weird error which might be a regression, as it used to work on a previous EA build (before the introduction of ResourceScopes):
>>> 
>>> I'm still experimenting with a FUSE binding for Java, which involves a lot of upcalls. During these experiments, I noticed that when CLinker.toJavaString() gets called for the _first_ time during an upcall, the JVM crashes (seems to be some kind of NoSuchMethodError, see [1]).
>>> 
>>> However, if the first invocation happens in my "regular" Java context [2], any subsequent invocations [3] succeed as well. Apparently there is no longer any need to look up the method (that's my only explanation so far).
>>> 
>>> The same problems occurs for _any_ method that is used for the first time during an upcall. It is not always possible to do some "dummy invocations" beforehand.
>>> 
>>> Is there anything I need to know about reduced JVM capabilities during upcalls? Or is this a bug? You can reproduce the issue with my project by simply commenting out [2] and then run `HelloPanamaFileSystem.main()`. The first getattr()-call will reliably crash the JVM unless you add [2] back in again.
>>> 
>>> [1] hs_err_pidxyz.log: https://gist.github.com/overheadhunter/320e89c69b48ab6a446c0bfb391ae5d0 <https://gist.github.com/overheadhunter/320e89c69b48ab6a446c0bfb391ae5d0> 
>>> [2] fuseMain() invoked on main thread: https://github.com/skymatic/fuse-panama/blob/17369e82ac8ccfadaa068daa3d97635eaf53a9cc/src/main/java/de/skymatic/fusepanama/Fuse.java#L103 <https://github.com/skymatic/fuse-panama/blob/17369e82ac8ccfadaa068daa3d97635eaf53a9cc/src/main/java/de/skymatic/fusepanama/Fuse.java#L103> 
>>> [3] e.g. during getAttr() invoked on FUSE worker thread: https://github.com/skymatic/fuse-panama/blob/update-panama/src/main/java/de/skymatic/fusepanama/Fuse.java#L71 <https://github.com/skymatic/fuse-panama/blob/update-panama/src/main/java/de/skymatic/fusepanama/Fuse.java#L71> 
>>>