RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

Anton Kozlov akozlov at openjdk.java.net
Wed Feb 3 20:11:53 UTC 2021


On Tue, 2 Feb 2021 23:03:45 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   support macos_aarch64 in hsdis
>
> src/hotspot/share/runtime/thread.cpp line 3991:
> 
>> 3989:       JavaThread* thread = JavaThread::current();
>> 3990:       ThreadToNativeFromVM ttn(thread);
>> 3991:       Thread::WXExecFromWriteSetter wx_exec;
> 
> I saw somewhere in this review a comment about why this new
> WXExecFromWriteSetter helper isn't folded into ThreadToNativeFromVM
> and I understand that not every current ThreadToNativeFromVM needs
> the new helper. If the vast majority of the ThreadToNativeFromVM
> locations need WXExecFromWriteSetter, then perhaps those locations
> that currently have a ThreadToNativeFromVM followed by the new
> WXExecFromWriteSetter should use a new helper:
> 
>     ThreadToNativeWithWXExecFromVM
> 
> so we'll see changes from:
> 
>     ThreadToNativeFromVM -> ThreadToNativeWithWXExecFromVM
> 
> where we need them and hopefully a short comment can be added
> at the same time to explain the need for WXExec. This will allow us
> to easily distinguish ThreadToNativeFromVM locations that DO NOT
> need WXExec from those that DO need it.

With a small overhead for tracking the current W^X state, I avoided WXExecFromWriteSetter near ThreadToNativeFromVM at all. New ThreadWXEnable(WXExec) is used only to call a generated function. More common ThreadWXEnable(WXWrite) is tied to JVM entry functions. I added comments for functions that are not clear to be entries, although they are. Thank you for the suggestion!

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

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



More information about the security-dev mailing list