Java 、Idea、Android Studio 用户请暂缓升级到 macOS 14.4

@Rorysky 合理了.
不用担保的 API 或特性去产生的任何行为都不应该被视为可靠的, 利用这种特性去做的程序本身也是不可靠的, 只不过这个不可靠性取决于上游 (也就是 Apple).
大家都用 **不等于** 这么用正确.

不过 Apple 在 Dev 不改甚至 RC 不改, 却在正式版改, 太激进了, 这样的发布策略并不合理.

即, 未担保的方法/接口 显然是可以改动的, 但在改动之前, 应该先进行小范围/大范围测试, 而不是直接推到正式版上, 利用这种未担保特性显然是程序本身的问题, 但如果这种未担保特性的影响特别广泛, 那么测试有助于提前解决问题.

@daveh 我不知道你是在哪里得来的这个结论
https://bugs.java.com/bugdatabase/view_bug?bug_id=8320317
是这个吗？确实删除了一个对 SafeFetch 的调用，可问题是是在这里吗，后文不也提及了
JDK-8320317 removes this specific call to SafeFetch. We could probably still still hit similar issues with other calls to SafeFetch

我重新看了看这个文档:
These crashes are **most often** identified by the EXC_BAD_ACCESS (SIGSEGV) or EXC_BAD_ACCESS (SIGBUS) exceptions in the **crash report**
所以 Apple 并不保证这个信号一定是两者中的其中之一, 但又说的很隐晦...

@lslqtz 你看的是 https://developer.apple.com/documentation/xcode/investigating-memory-access-crashes 这个吧，问题是这并不是同一个问题，它是“调查因内存问题而崩溃的方法”

@daveh 请问这个测试版的 JBR 应该去哪里下载，没有找到

找到了，我试试这个
https://youtrack.jetbrains.com/issue/JBR-6802/Crash-EXCBADINSTRUCTION-from-ObjectMonitorTrySpin-on-macOS-14.4

@bghtyu #86
这个：
https://github.com/JetBrains/JetBrainsRuntime/releases
Release 17.0.10b1207.12

@codehz #83 问题就在这里。

首先，要明白不是说调用 SafeFetch 就有问题，是传无效或受保护地址才有问题。
删掉的屎山代码可能会传 0 地址，所以必然出问题。
至于其他地方是否乱用，让子弹飞一会吧。

导致问题的屎山代码删掉后，据说 JRE 性能都提高了一些😂。

所以说 macOS 这个新行为，反而督促了 JDK 去优化改进，去发现问题。

@codehz #78 JDK 的改动不是 workaround ，建议你追加更新一下实际原因，不要误导。

@daveh SafeFetch 整个函数的意义就是访问非法地址的时候能检测到结果，你是不明白这个 fetch 的含义吗。。。
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/safefetch.hpp#L31-L32

@daveh https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/safefetch_sigjmp.cpp 在 posix 下的实现就是 sigsetjmp 保存跳转地址，然后在异常处理代码里检测 SIGSEGV 和 SIGBUS 来跳转到返回 false 的分支

java 配不上金子内存，自己滚吧

这种特性不是病毒最喜欢用的么。Java 也用啊。

@daveh 幸好苹果的客户主要是普通消费者。我上班做 toB 的项目，要是公司的项目像苹果这样做，免不了要赔偿，还得加班给客户处理好所有问题。

@codehz #92 你代码都引用错了，macOS/bsd 、Linux 都不用这个代码，让我该说什么好呢？

而且非法地址检测现在也能。

@daveh 没错是改成 static 了，但还是用信号的啊 https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/safefetch_static_posix.cpp
只不过把 safefetch 本身的代码用汇编写成直接一个 mov 或者 ldr
https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_aarch64/safefetch_bsd_aarch64.S
不是很懂为啥要杠这一点

@daveh
这个修改也只是另一个性能优化 https://bugs.openjdk.org/browse/JDK-8283326

SafeFetch is important - mostly when writing hs-err reports, but it is also used in low level utility functions like `os::print_hex_dump()` and `os::is_readable_pointer()`. It is also used (JDK-8282306) as part of call stack printing. At the moment it is implemented via dynamically generated stub routines

我们公司每次有个专门 team 先把开发环境先全测了没问题才允许全公司升级，以前觉得小题大做，这次完美避过了