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

[Maurizio Cimadamore]

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> 
>>
>>