RFR: 8262894: [macos_aarch64] SIGBUS in Assembler::ld_st2

[David Holmes]

On 30/03/2021 5:18 am, Anton Kozlov wrote:
> On Mon, 29 Mar 2021 13:44:18 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Please review a fix for compiler/debug/VerifyAdapterSharing.java failure on macos/aarch64 platform. The root cause is in missing W^X switch in JNI DestroyJavaVM.
>>>
>>> I reviewed the rest of the JNI Invoke Interface functions. DetachCurrentThread needs a similar change, although nothing fails immediately. So DetachCurrentThread is changed as a precaution.
>>
>> Hi Anton,
>>
>> In so much as I understand the fact transitions are missing the introduction of those transitions seems fine - but can be simplified due to an existing code quirk (see comments below).
>>
>> My main concern with this W^X stuff is that I don't see a clear way to know exactly where a transition needs to be placed. The missing cases here suggest it should be handled in the thread-state transition code, but you've previously written:
>>
>> " when we execute JVM code (owned by libjvm.so, starting from JVM entry function), we switch to Write state. When we leave JVM to execute generated or JNI code, we switch to Executable state. I would like to highlight that JVM code does not mean the VM state of the java thread"
>>
>> so I'm unclear exactly how we identify the points where these transitions must occur? What kind of "VM code" must be guarded this way? I don't see this documented in the code anywhere.
>>
>> Thanks,
>> David
> 
> Hi David,
> 
> Thank you for the review.
> 
>> so I'm unclear exactly how we identify the points where these transitions must occur? What kind of "VM code" must be guarded this way? I don't see this documented in the code anywhere.
> 
> For usual JNI function implementation we switch to WXWrite in JNI_ENTRY (JNI_ENTRY_NO_PRESERVE to be precise), so xxx_ENTRY style macro defines a border between JVM and the rest of the code. JNI Invocation functions are also called directly from native code, so they should have W^X transition. But since they are implementing something rather special, they don't use any special ENTRY macro, which makes them less evident to be JVM entry points. Here and in other cases, when we do W^X in an apparently random function, it is because the function is called directly from the interpreter or native or generated code, but the function is not defined with ENTRY macro. Hope it clarifies the logic a bit.

I get the gist of where you have placed the transitions around the 
various "entry" points to VM code, but I don't understand what kind of 
VM code actually requires these transitions. For example a LEAF function 
doesn't have the transition so the code called from there can't require 
it - but what is the characteristic of code that can require it?

> I've checked `Threads::destroy_vm`, you're right! But I'd consider missing handling after possible `false` as a bug. If you don't mind, I prefer the extra code in the existing else clause. But I agree the whole clause can be cleaned up. Thanks for pointing!

I'll clean this part up under JDK-8264372.

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3241
>