RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4]

[Maurizio Cimadamore]

On Tue, 24 Nov 2020 10:30:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use the Unimplemented() macro instead of hlt()
>
> I have a few minor comments, in addition to what David is saying about `JNI_ENTRY_CPP_NOENV`.

> Glad you mentioned ExceptionMark! Exactly what is the design philosophy
> with respect to exceptions from the called Java method in this API? At
> present they are simply ignored. If the thread were then to make JNI
> calls that could break rules about not being able to call most JNI
> methods with a pending exception. If it makes another upcall does that
> immediately "abort" with the pending exception? If we have a case where
> the thread auto-detaches what happens then? Will it trigger the Thread
> uncaughtExceptionHandler?

This is a very good point David - if an exception is issued during an upcall, there's not a lot we can do on native side to recover. We have plans here (Jorn suggested to just wrap the upcall method handle in a "catch-all" which catches all exceptions and then just exits the VM). But, at the same time, I'd like to "steer" the discussion in this PR towards the stated goal of the PR - namely, fix build issues in x86.

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

PR: https://git.openjdk.java.net/jdk/pull/1266