Live data from Hacker News

macOS Sonoma 14.4 might break Java on your machine

appleinsider.com

41–50 of 271 posts

Re: macOS Sonoma 14.4 might break Java on your machine

#41
post #21

> 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…

Which other JITs behave like this? AFAIK neither V8 nor Spidermonkey nor LuaJIT rely on segfaults as a normal part of their operation?

Re: macOS Sonoma 14.4 might break Java on your machine

#42
post #34
post #28

Been 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?

[deleted]

Re: macOS Sonoma 14.4 might break Java on your machine

#44
post #28

Been 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…

It's not a psyop, people are just having different experiences to you. I've had endless problems on Windows and Linux machines, and never had a serious or even annoying issue on a mac

Re: macOS Sonoma 14.4 might break Java on your machine

#45
post #28

Been 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…

As of recently, Docker on MacOS has improved and AFAICT the performance penalty is gone.

Is the problematic corporate Mac an M-series Mac or Intel?

M-series have been great in my experience. I did used to get random full system crashes on Intel Macs which haven't happened in a few years on M1/M2.

Re: macOS Sonoma 14.4 might break Java on your machine

#46

Maybe the Oracle blog post [1] would be a better link than the Apple Insider article, which says "The problem does not affect most typical Mac users, as Java was deprecated for the Mac back in 2012." [1] https://blogs.oracle.com/java/post/java-on-macos-14-4

I can't find that quote in your link. I can't find any mention of the word "deprecated" or "2012". Did you send the wrong link?

Re: macOS Sonoma 14.4 might break Java on your machine

#47

Maybe the Oracle blog post [1] would be a better link than the Apple Insider article, which says "The problem does not affect most typical Mac users, as Java was deprecated for the Mac back in 2012." [1] https://blogs.oracle.com/java/post/java-on-macos-14-4

I think they're confusing the Java plugin for websites with the normal Java runtime.

Exactly. We shouldn't promote such poor quality journalism.

Re: macOS Sonoma 14.4 might break Java on your machine

#48
I'm on 14.4 and using Jetbrain's IDE. So -this- is the reason my IDE randomly crashes. I'd been chalking it up to 14.4 but didn't have any specifics.

It's mostly fine, though. The crashes are rare, and since everything auto-saves, you're not really losing anything. It's just an "oh, okay." moment.

Obviously it'll be good when it's fixed, but on my personal list of impactful bugs, this doesn't crack the top 10.

Re: macOS Sonoma 14.4 might break Java on your machine

#49
post #36

Earlier quoted context omitted.

Despite what the other commenters are saying, it is bizarre. 1. There is very little you can safely do in a signal handler. For a threaded application, that pretty much boils entirely down to setting a bit and leaving it at that. If they did anything more, the behavior is undefined. 2. The memory state that a program receiving a SIGSEGV in is often undefined/garbage, and attempting to execute further at this point is…

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/29397d29baac3b29083b1b... On current CPUs and operat…

The "safe fetch" code relies on a signal handler (either here https://github.com/openjdk/jdk/blob/48717d63cc58f693f0917e61... or here https://github.com/openjdk/jdk/blob/3c70f26b2f3fa9bc143e2506...), which is considered asynchronous delivery (i.e., delivered mid-execution, see `man 7 signal`) - which is why the `async-signal-safe` manpage simply states that it is functions that can safely be called within a signal handler.

This is opposed to calling `sigwait` or similar to actively suspend and wait for a signal, which is not possible to do here.

Granted, it may be that the stars align and their implementation works in practice, but that does not make it any less bizarre.

Re: macOS Sonoma 14.4 might break Java on your machine

#50
I 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 good idea, why not do it in one of the pre-releases or betas??? Doesn’t look like the kind of thing you’d want to do in a last minute change.

The real problem in my opinion is the fact that you cannot go back after a macOS upgrade. So if something like this happens, you literally have no option but waiting for Apple to release a fix, if they want to do it at all.

Post reply on HN