Re: RFR: 8330171: Lazy W^X switch implementation
On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin wrote: > An alternative for preemptively switching the W^X thread mode on macOS with > an AArch64 CPU. This implementation triggers the switch in response to the > SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this > approach, it is now feasible to eliminate all WX guards and avoid potentially > costly operations. However, no significant improvement or degradation in > performance has been observed. Additionally, considering the issue with > AsyncGetCallTrace, the patched JVM has been successfully operated with > [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and > [async-profiler](https://github.com/async-profiler/async-profiler). > > Additional testing: > - [x] MacOS AArch64 server fastdebug *gtets* > - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4* > - [ ] Benchmarking > > @apangin and @parttimenerd could you please check the patch on your > scenarios?? This can be left as an addition to existing mechanism. Disabled by default and can be enabled with a special (DEVELOP) option. So this can't be enabled on production builds, but can be useful to debug w^x issues on debug builds - PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2051984322
Re: RFR: 8330171: Lazy W^X swtich implementation
On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin wrote: > An alternative for preemptively switching the W^X thread mode on macOS with > an AArch64 CPU. This implementation triggers the switch in response to the > SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this > approach, it is now feasible to eliminate all WX guards and avoid potentially > costly operations. However, no significant improvement or degradation in > performance has been observed. Additionally, considering the issue with > AsyncGetCallTrace, the patched JVM has been successfully operated with > [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and > [async-profiler](https://github.com/async-profiler/async-profiler). > > Additional testing: > - [x] MacOS AArch64 server fastdebug *gtets* > - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4* > - [ ] Benchmarking > > @apangin and @parttimenerd could you please check the patch on your > scenarios?? Hello Sergey. W^X mode was initially forced by Apple to prevent writing to executable memory, as a security feature. This change just eliminates this security feature at all, doesn't it ? Basically: "want to write to Executable memory ? ok, here you go" - PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2051910824
Re: RFR: 8314117: RISC-V: Incorrect VMReg encoding in RISCV64Frame.java
On Thu, 10 Aug 2023 14:01:25 GMT, Feilong Jiang wrote: > Hi, inspired by [JDK-8247351](https://bugs.openjdk.org/browse/JDK-8247351), > this patch fixes a VMReg encoding issue in `RISCV64Frame.java`. As the VMReg > has two slots in a 64-bit VM, the encoding of `fp` should be `8 << 1` instead > of `8`. > > Testing: > - [x] tier1 with release build > - [x] tier2 with release build > - [x] tier3 with release build > - [x] hotspot:tier4 with release build Please consider backporting this to 21u/17u if they are affected - PR Comment: https://git.openjdk.org/jdk/pull/15226#issuecomment-1677025806
Changing granularity of jvmtis DynamicCodeGenerated for interpreter
Hello
I’ve found a need to change the granularity of JVMTI’s DynamicCodeGenerated for
interpreter’s generated code.
Currently it shows just one big interpreter area, probably because of this code:
JvmtiExport::post_dynamic_code_generated("Interpreter",
AbstractInterpreter::code()->code_start(),
AbstractInterpreter::code()->code_end());
However for template interpreter it’s possible to generate such entry for every
bytecode instruction code generated ( e.g. one for sipush, etc). Just like
-XX:+PrintInterpreter does.
What would be the ideal place to insert detailed
JvmtiExport::post_dynamic_code_generated() calls then ?
Thanks in advance, Vladimir
