https://blogs.oracle.com/java/post/java-on-macos-14-4
Why does this affect only Java? It seems any jit should be affected, and surely people would notice.
[deleted]
macOS Sonoma 14.4 might break Java on your machine
71–80 of 271 posts
Re: macOS Sonoma 14.4 might break Java on your machine
#72I find it difficult to imagine how a change like this (sending a SIGKILL to the process instead of SIGSEGV on a page fault) can be done in the final release and not in one of the EA releases or betas. It is clearly a breaking change with no easy workaround (since SIGKILL cannot be caught), for a behaviour which is well defined by POSIX. Even if you momentarily ignore the reasons why someone thought this could be a go…
It sounds like the kind of half-baked change a junior dev might come up with, but lord knows how it made it through code review and into a release.
hypothetical excerpt from the commit message:
code review: self-reviewed
test plan: this change is so obvious no tests are neededRe: macOS Sonoma 14.4 might break Java on your machine
#73Earlier quoted context omitted.
It sounds like the kind of half-baked change a junior dev might come up with, but lord knows how it made it through code review and into a release.
That's easy to guess The good kernel engineers are working on iPhone or Vision Pro, not on MacOS
Don't they all use the same kernel?
Re: macOS Sonoma 14.4 might break Java on your machine
#74Been saying this for as long as I’ve been using macOS: it is not a developer friendly OS and am close to the conclusion that this reputation is a psy-op. Yeah it’s pretty, it mostly works when the box is first turned on and the hardware is unmatched but macOS itself is actually subpar. QA seems second tier, things you’d except from other OSes like, I don’t know, using a third party second display are just bad experie…
Strange. I've got the complete opposite experience. Most displays work fine. It helps if you stick with models that advertise at least a bit of macOS support (like some Dells or Samsungs). Docker sucks, but there's Orbstack. I don't care for posix, but most of my *nix tools are available in Homebrew. Network is steady and more bulletproof than wireless on Linux. Is your experience based on a recent mac?
The problem with third party displays on the Mac is the system has some deeply held assumptions that all monitors are as pixel-dense as the ones which Apple ships with their machines. 100% DPI scaling for classic ~100ppi monitors is a poor experience since macOS no longer supports subpixel font rendering, and DPI scales higher than 100% but less than 200% are really just 200% in a trenchcoat because the system renders everything at 200% then uses non-integer resampling to squish it onto the display. That works well enough on the ~220ppi panels that Apple uses but isn't ideal on common 4K displays which are usually around 140-160ppi.
It's not unusable if you at least have one of those medium density 4K monitors, but it feels like a step backwards if you're used to Windows which still (mostly) supports subpixel font rendering for crisp text at 100% scale, and can render natively at 125/150/175% scales.
Re: macOS Sonoma 14.4 might break Java on your machine
#75> As a normal part of the just-in-time compile and execute cycle, processes running on macOS may access memory in protected memory regions. Prior to the macOS 14.4 update, in certain circumstances, the macOS kernel would respond to these protected memory accesses by sending a signal, SIGBUS or SIGSEGV, to the process. > With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected m…
That's actually a pretty normal way to do things. Optimization for JITting, let the CPU hardware to do the heavy lifting instead of putting conditional jumps everywhere. It's useful for other things as well. I've used SIGSEGV to emulate hardware interrupts. Normal execution wouldn't trap and there's no need for tests + branches (= normally no slowdown), but when an interrupt occurs a specific often accessed page is m…
That you can doesn't necessarily mean that you should.
Re: macOS Sonoma 14.4 might break Java on your machine
#76I find it difficult to imagine how a change like this (sending a SIGKILL to the process instead of SIGSEGV on a page fault) can be done in the final release and not in one of the EA releases or betas. It is clearly a breaking change with no easy workaround (since SIGKILL cannot be caught), for a behaviour which is well defined by POSIX. Even if you momentarily ignore the reasons why someone thought this could be a go…
It sounds like the kind of half-baked change a junior dev might come up with, but lord knows how it made it through code review and into a release.
I think someone changed the SIGSEV to a SIGKILL to debug something and forgot to revert it before merging (boo reviewer boo !)
Re: macOS Sonoma 14.4 might break Java on your machine
#77> As a normal part of the just-in-time compile and execute cycle, processes running on macOS may access memory in protected memory regions. Prior to the macOS 14.4 update, in certain circumstances, the macOS kernel would respond to these protected memory accesses by sending a signal, SIGBUS or SIGSEGV, to the process. > With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected m…
It's documented and part of the interface for POSIX: > Write attempts to memory that was mapped without write access, or any access to > memory mapped PROT_NONE, shall result in a SIGSEGV signal. > > References to unmapped addresses shall result in a SIGSEGV signal. How a SIGSEGV can be handled by the program to continue execution normally need some OS specific code. For Linux there's also userfaultfd to suit this ne…
> How a SIGSEGV can be handled by the program to continue execution normally need some OS specific code
A JVM's use of SIGSEGV might include platform-dependent details for recovery. But for simple application usages (e.g. eliding inlined bounds checks in a performance critical loop operating on an array) longjmp can suffice for recovery. POSIX very carefully defines async-safety and longjmp to permit jumping out of a signal handler and resuming normal execution, provided certain constraints are met, such as that the signal did not interrupt a non-async-signal-safe function.
Re: macOS Sonoma 14.4 might break Java on your machine
#78Been saying this for as long as I’ve been using macOS: it is not a developer friendly OS and am close to the conclusion that this reputation is a psy-op. Yeah it’s pretty, it mostly works when the box is first turned on and the hardware is unmatched but macOS itself is actually subpar. QA seems second tier, things you’d except from other OSes like, I don’t know, using a third party second display are just bad experie…
> posix compatibility is technically there but isn’t really useful
It's been a long time since I ran a Macbook, but this was my biggest problem. The weird uncanny valley where its almost the same but then not.
WSL has problems but there's a very clear line in the sand between Linux and Windows and you know what you're getting.
Re: macOS Sonoma 14.4 might break Java on your machine
#79Earlier quoted context omitted.
That's actually a pretty normal way to do things. Optimization for JITting, let the CPU hardware to do the heavy lifting instead of putting conditional jumps everywhere. It's useful for other things as well. I've used SIGSEGV to emulate hardware interrupts. Normal execution wouldn't trap and there's no need for tests + branches (= normally no slowdown), but when an interrupt occurs a specific often accessed page is m…
Which other JITs behave like this? AFAIK neither V8 nor Spidermonkey nor LuaJIT rely on segfaults as a normal part of their operation?
Personally I'd expect this would affect the GC more than the JIT.
But I'm not surprised that the JVM uses every trick for speed.
Re: macOS Sonoma 14.4 might break Java on your machine
#80Been saying this for as long as I’ve been using macOS: it is not a developer friendly OS and am close to the conclusion that this reputation is a psy-op. Yeah it’s pretty, it mostly works when the box is first turned on and the hardware is unmatched but macOS itself is actually subpar. QA seems second tier, things you’d except from other OSes like, I don’t know, using a third party second display are just bad experie…
Completely agree. Have been using a MBP for almost three years now at work (after using Windows machines for a couple of decades), and I can see how laughable many of the design decisions in macOS are (though I highly doubt they were deliberate 'decisions' at all), and I still fail to understand why people use them over Windows or Linux (sure, great hardware, mostly). It's probably fine as a consumer device, but for…
[dead]