2 ms·

The JVM has worked fine on macOS and Apple Silicon for years. It's not violating W^X. The problem is an undocumented/unannounced and probably unintended change

The JVM has worked fine on macOS and Apple Silicon for years. It's not violating W^X. The problem is an undocumented/unannounced and probably unintended change in kernel behavior.

dylan604 3y ago
Shouldn't this help zero in on where the issue is located? If it did not occur in the last released beta but it now exists in the released update, doesn't that significantly reduce the footprint of where to search for changes?
- shagie 3y ago
  From a discussion on it previously : https://news.ycombinator.com/item?id=39741517 https://news.ycombinator.com/item?id=39741517 by fweimer > The signal comes from a safe fetch, which is just a read that allows ignoring the fault as if it never happened. Such a signal is deliver synchronously, so the usual restrictions for asynchronous signal handlers do not apply. > The code in question takes into account that the value read might be garbage. See the big comment here: https://github.com/openjdk/jdk/commit/29397d29baac3b29083b1b5d6b2cb06e456af0c3 https://github.com/openjdk/jdk/commit/29397d29baac3b29083b1b... > On current CPUs and operating systems, this is not an optimization, so the code was removed earlier this year: https://bugs.openjdk.org/browse/JDK-8320317 https://bugs.openjdk.org/browse/JDK-8320317 (there's a lot more comments further down that are worth reading) It is known where this is causing a problem and the code was removed a few months ago in the code for Java 23.