RFR: 8262894: [macos_aarch64] SIGBUS in Assembler::ld_st2
Anton Kozlov
akozlov at openjdk.java.net
Tue Mar 30 11:12:41 UTC 2021
On Tue, 30 Mar 2021 08:47:40 GMT, Andrew Haley <aph at openjdk.org> wrote:
> > I assume any VM entry code should have W^X transitions.
>
> That sounds very extreme to me. I guess it all depends on the cost of doing the transition.
It is made for simplicity and robustness. I did a few iterations fixing various issues until this scheme came up, which I pretty confident now in correctness. Yes, it depends on the transition to be fast enough. To get the sense of "fast" I did https://github.com/openjdk/jdk/pull/2200#issuecomment-773382787. But this approach can be and probably should be optimized.
> I'm curious why the W^X transition isn't done only when accessing the code cache.
There are a lot of places where we need or potentially need the transition. Every deoptimization may want to write to codecache. Adding explicit transitions is rather tedious and error-prone. I've tried this and it takes significant time to get to `java -version` working, without guarantees it will work to something bigger.
Another approach is to do a lazy transition to WXWrite on segfault after we try to write to codecache in VM and to ensure WXExec during exit from VM. Is it beneficial or not depends on a ratio between entries into runtime and ones actually need WXWrite.
This raises a question about a realistic workload to measure effects after various W^X approaches. I used the first iteration of macro benchmarks like Renaissance and SPECjvm2008 with zero warm-up, in the assumption that the most number of runtime calls and deoptimization happens there. Is there a better workload for this purpose?
-------------
PR: https://git.openjdk.java.net/jdk/pull/3241
More information about the hotspot-dev
mailing list