Live data from Hacker News

macOS Sonoma 14.4 might break Java on your machine

appleinsider.com

111–120 of 271 posts

Re: macOS Sonoma 14.4 might break Java on your machine

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

The reputation was well earned when Linux on the Desktop wasn’t as easy or friendly as it is today and was severely lacking good quality GUI applications. Windows was a virus laden mess and was not useful for running Linux apps. And besides the flaws of the other OS’es, OS X had some of the nicest window management features (Expose from the Snow Leopard is still my favorite window switcher), was a UNIX and had a thri…

Here are few particular things that I like about development in my mac:

1. Terminal is very usable, compared to Windows cmd. Modern Gnome Terminal is good, though.

2. Cmnd+C for copy, Ctrl+C for SIGINT.

3. Touch ID instead of root password, which works with Bluetooth keyboard as well, and that's with absolutely minimal configuration, uncommenting single line.

Re: macOS Sonoma 14.4 might break Java on your machine

#112

Earlier quoted context omitted.

I cannot believe that, on macOS, high cpu usage leads to audio buffer underruns and popping, like something from the 90s but on today's premium hardware. It's inexcusable. On a platform that is constantly touted as the best for audio work, DAWs etc no less.

Wow, I thought I'm the only one as when asked in my Team no one agreed to facing these issues - but I faced it on multiple new Macbook Pros.

I experienced it, but I'm not sure if it relates to high CPU. My guess it's something about kernel locks.

Re: macOS Sonoma 14.4 might break Java on your machine

#113
post #36

Earlier quoted context omitted.

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

It's not "bizarre" at all. It's a direct translation of hardware CPU traps to userspace API. That's what signal handers are: virtualized interrupts! There's nothing wrong with using signals to achieve performance levels otherwise not possible.

Re: macOS Sonoma 14.4 might break Java on your machine

#114
post #74

Earlier quoted context omitted.

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

Yes, this is irking me too. You really need a high density display to enjoy macOS, it shouldn't be like that. I guess they like to leave the baggage behind.

The worst part is you can't even throw money at the problem without still compromising somewhere - third party 6K/8K monitors which meet Apples PPI standard do exist, but those are currently limited to 60hz, so if you want a fast refresh rate you have to settle for 4K at a lesser PPI.

Re: macOS Sonoma 14.4 might break Java on your machine

#115
post #59

Earlier quoted context omitted.

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.

I mean the performance penalty is just inherent to how Docker on Mac works. Instead of being a container like on Linux, it’s a virtual machine, which will necessarily be slower.

The difference is absolutely marginal. The main slowdown sources is mounting huge volumes from the host, that's definitely works better with Linux. And emulating x86_64, if your container does not have arm64 build. But if you don't need it, I'd argue that M1 performance will yield faster containers compared to average Intel laptop.

Re: macOS Sonoma 14.4 might break Java on your machine

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

Not saying you're wrong, but what else is there that just works and is usable instantly when you open the lid? While my work Windows laptop might be faster, it's certainly not the one I'm going to pick in a pinch or when I want to travel with just one laptop. The best mobile configuration I know right now is a Macbook Pro + Parallels. Even with all of its deficiencies. Are there any good Linux laptops with similar ex…

You could always install Linux on your Macbook Pro. Personally I prefer MacOS though.

Re: macOS Sonoma 14.4 might break Java on your machine

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

Funny, I have the same feelings about Linux. So many bugs and glitches that it really feels like nobody actually tests anything. And Windows, while I don't remember any weird glitches, just has so many ads that it makes me feel like I'm browsing some sort of yellow newspaper. Almost every update of Windows brings with it new installed apps like Candy Crush or Amazon Prime Video that I never opted into.

Re: macOS Sonoma 14.4 might break Java on your machine

#118
post #61

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

>> As a normal part of the just-in-time compile and execute cycle This means a workaround is running java with -Djava.compiler=NONE, no?

A better choice would be -Xrs which keeps optimizations enabled, but disables use of SEGV.

Re: macOS Sonoma 14.4 might break Java on your machine

#119

Earlier quoted context omitted.

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

It's not "bizarre" at all. It's a direct translation of hardware CPU traps to userspace API. That's what signal handers are : virtualized interrupts! There's nothing wrong with using signals to achieve performance levels otherwise not possible.

But this also means that signal handlers are running in what's effectively a separate thread of execution - even in otherwise single-threaded code! So the things you're allowed to do safely in your signal handler are very limited, they boil down to atomically tweaking some lightweight data structure (or even just setting a flag) that the main code will look at later and behave accordingly.
Post reply on HN