131–140 of 160 posts
Earlier quoted context omitted.
That’s how MS works which leads to compatibility, but less stability. Historically with Apple, it’s their way or the highway. Less compatibility, but the OS is more stable.
Does not seems stable, when all Java based applications are crashing.
Earlier quoted context omitted.
https://youtrack.jetbrains.com/issue/JBR-6802 The JetBrains team has already figured it out as well.
Reading the comments from David Wartell in that thread is enough internet for me today. This guy is CTO of some company and is just harassing the thread for a fix ETA without understanding the problem at all.
"The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update." I wonder if Oracle really didn't know beforehand. Apple has long been telling people (writing JITs) that to write to executable memory, they need the correct entitlements (com.apple.security.cs.allow-jit, allow-unsigned--executable-memory, and or/ .disable-executable-page-protection). I…
The whole truth is that the Apple kernel team broke user space.
Wait, they write to protected memory, and get killed. :tripplefacepalm: Somebody hire some engineers at Oracle.
> macOS on Apple silicon processors (M1, M2, and M3) includes a feature which controls how and when dynamically generated code can be either produced (written) or executed on a per-thread basis. […] With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected memory region is attempted, macOS will send the signal SIGKILL instead. This isn’t just any old thread triggering SIGKILL, i…
Because explicit checks on every memory access (pointer dereference) makes Java significantly slower, even with compiler optimisations to remove redundant checks[1]. Memory protection is a fundamental, very useful, hardware feature and it's perfectly reasonable for user space language runtimes to take advantage of it.
Or, to put it another way, SIGSEGV has been a part of Unix-family OSes for decades. It works perfectly fine on Linux and Windows and there's no reason it shouldn't work on macOS.
[1] (Many years ago I worked on a cross-platform implementation of the Java runtime and wrote much of the threads and signal handling code. We had an option to enable explicit memory checks, which got us up and running faster on new platforms where the SIGSEGV handlers hadn't been written yet. From memory this made everything something like 30-50% slower, so it was definitely worthwhile to implement SIGSEGV handling. In our case SIGSEGV handlers were used both as part of the garbage collector/memory management and to implement Java's NullPointerException)
"The issue was not present in the early access releases for macOS 14.4, so it was discovered only after Apple released the update." I wonder if Oracle really didn't know beforehand. Apple has long been telling people (writing JITs) that to write to executable memory, they need the correct entitlements (com.apple.security.cs.allow-jit, allow-unsigned--executable-memory, and or/ .disable-executable-page-protection). I…
> Apple has long been telling people (writing JITs) that to write to executable memory, they need the correct entitlements (com.apple.security.cs.allow-jit, allow-unsigned--executable-memory, and or/ .disable-executable-page-protection). I wonder if Oracle has been ignoring them, satisfied with the signal-handler workaround, and Apple finally enforced their policy. As far as I understand, that’s not the issue, the JI…
Earlier quoted context omitted.
Does not seems stable, when all Java based applications are crashing.
Only Java is unstable because it’s not following Apple’s rules. Everything else, including the apps that follow the rules, are stable. That’s how it’s always been for the Apple ecosystem.
Earlier quoted context omitted.
That’s how MS works which leads to compatibility, but less stability. Historically with Apple, it’s their way or the highway. Less compatibility, but the OS is more stable.
Does not seems stable, when all Java based applications are crashing.
That probably needs to be qualified with "Oracle JVM Java applications" because I've had many hours of running Minecraft on macOS 14.4 under Zulu's JVM (a pre-14.4 release which means it doesn't have any workarounds) without any issues.
Earlier quoted context omitted.
As Linus famously said: Shut. Up. Don’t break userspace and then blame the user. https://lkml.org/lkml/2012/12/23/75
Linux did break adobe flash when it used memmove like memcopy after fixing a kernel bug. Can't think of any other examples though.