V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
codehz
V2EX  ›  Apple

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

  •  4
     
  •   codehz · 64 天前 · 10041 次点击
    这是一个创建于 64 天前的主题,其中的信息可能已经有所发展或是发生改变。
    https://blogs.oracle.com/java/post/java-on-macos-14-4
    省流:果子改了受保护页面的默认处理方式,之前是发 sigsegv 现在直接 sigkill ,而 java 从很早的版本(已知 8 )开始就在滥用这个特性来将 null 检测改为捕获 sigsegv 信号,包括用户主动写的 if == null 也会在 jit 的帮助下被转换,这在新版本 mac 里会直接触发错误。
    建议有 java 需求或依赖基于 java 的 ide 的 mac 用户暂缓升级
    第 1 条附言  ·  52 天前

    经过测试,mac 14.4.1 已经正式修复了这个 BUG,通过测试代码可知,不是给java专门打的补丁

    #include <pthread.h>
    
    int main() {
      pthread_jit_write_protect_np(0);
      return *((int *)NULL);
    }
    

    <- 先前14.4是SIGKILL,现在正确SIGSEGV

    109 条回复    2024-03-29 11:04:21 +08:00
    1  2  
    codehz
        1
    codehz  
    OP
       64 天前 via iPhone
    补充一下,这个需要刚好在 jit 运行的时候(也就是线程正处于 write 的模式)才会触发的 sigkill 其他时候依然是正常流程,因此 grallvm 等直接生成 binary 的不受影响
    ly841000
        2
    ly841000  
       64 天前   ❤️ 4
    这种关键特性也能改??????
    rainbowmolly
        3
    rainbowmolly  
       64 天前   ❤️ 2
    “access memory in protected memory regions” 这个行为为什么是“As a normal part of the just-in-time compile and execute cycle” 常规操作?这种即使在果子自己的 oc 中应该是 bad access 直接就 crash 掉吧
    meloyang05
        4
    meloyang05  
       64 天前 via iPhone   ❤️ 15
    实在不理解苹果为什么要在一个小版本更新里进行这么重要的内核更改,完全没有充分的时间来验证更改后所可能引发的一系列后果。这已经是第三个 14.4 更新后所带来的问题了,前两个是显示器 usb 外设失灵,usb 打印机失灵。看得出 14.4 在内核上做了很多改动,然而这些改动没有经过充分测试和验证就能以正式版本推送给用户,实在让人对现在苹果的软件质量不敢恭维
    codehz
        5
    codehz  
    OP
       64 天前
    @rainbowmolly 以前的说法是,通过检测 segsigv 的方式,在 happy path (也就是没异常)的时候性能比较好,甚至于在特定情况(比如 jit 发现某个参数几乎没有 null 过)省略用户主动写的 null 判断更快
    Focus9
        6
    Focus9  
       64 天前   ❤️ 1
    怪不得 idea 偶尔闪退
    meloyang05
        7
    meloyang05  
       64 天前   ❤️ 1
    感觉像这种程度的内核改动,至少应该放在 macOS 15 这种大版本更新中,来给开发者一些时间解决兼容性问题,而不是像现在这样不声不响地推送到一个小版本中,给用户带来本不必要的困扰
    codehz
        8
    codehz  
    OP
       64 天前
    @meloyang05 我的个人猜测应该是苹果发现了什么影响安全性的严重 bug ,可能是已经有在野利用了
    neochen13
        9
    neochen13  
       64 天前 via Android
    请问有没有办法降级系统额
    ysc3839
        10
    ysc3839  
       64 天前 via Android   ❤️ 1
    @codehz 我感觉只是一个信号不至于牵扯到安全漏洞。如果真的无法解决,那也只能说明苹果技术差,隔壁一堆 Unix 都没改呢。
    tanrenye
        11
    tanrenye  
       64 天前
    我已经升级了一段时间,还没有发现有什么问题,是不是 zulu 的 sdk 不受影响?
    ly841000
        12
    ly841000  
       64 天前
    @meloyang05 #7 标准的做法应该是在可执行文件里加一个标记, 指明可以支持这个特征, 在新版本编译器中默认启用支持, 只有检测到标记, 系统才启用这个功能
    ysc3839
        13
    ysc3839  
       64 天前 via Android
    另外我也不觉得这是“滥用这个特性”,这应该就是 SIGSEGV 的正当用法吧?不然为什么要加这个信号?
    codehz
        14
    codehz  
    OP
       64 天前
    @tanrenye 触发条件看脸,得刚好在 jit 的时候触发被 jit 优化的空异常处理代码
    EastLord
        15
    EastLord  
       64 天前
    糟了,出了系统更新 我都是无脑升级
    ychost
        16
    ychost  
       64 天前   ❤️ 1
    @meloyang05 #4 ε=(´ο`*)))唉,我现在显示器外设 USB 还是偶发失灵,必须要重新插拔一次
    bghtyu
        17
    bghtyu  
       64 天前 via iPhone   ❤️ 2
    怪不得最近 idea 闪退了几次
    owen666
        18
    owen666  
       64 天前
    @neochen13 时光机可以降级。
    lslqtz
        19
    lslqtz  
       64 天前
    访问受保护的内存区域, 应用可以收到通知, 这意味着可以探测保护的内存区域块?
    felixlong
        20
    felixlong  
       64 天前
    映像里面几乎所有支持 JIT 需要检测空指针/数组越界访问异常的都会利用这个特性啊! NodeJS 没影响嘛? Apple 在搞啥。
    codehz
        21
    codehz  
    OP
       64 天前
    @lslqtz 我怀疑可能是有什么延迟上的差异导致泄露信息🤔
    codehz
        22
    codehz  
    OP
       64 天前
    @felixlong 目前据我所知只有 java 在广泛使用这个技巧,其他 jit 都没这么做
    不过数组越界肯定不会用这个方法,总不能一个数组刚好吃一个 4k 页面(apple silicon 好像是 16k),然后上下两侧摆 guard page ,这也太奢侈了
    至于空指针,支持 jit 的语言里有空指针暴露给用户的就挺少的了 js 肯定不是,go 和 net 据我所知也没人说有做类似优化
    Evrins
        23
    Evrins  
       64 天前
    14.4 一发布就升级了
    Goland RustRover DataGrip 都用的好好的
    eailfly
        24
    eailfly  
       64 天前
    只影响 Apple silicon 版本,还在用 Intel 2019 的一下子就放心了
    a66243766
        25
    a66243766  
       64 天前
    我就说我的 goland 最近一直崩溃
    neiltroyer849
        26
    neiltroyer849  
       64 天前
    似乎应该是与 Apple Silicon 自 A11 开始引入的 Fast Permission Restrictions 有关系。原来是在 iOS 上的,后来 Mac 上了 AS 因而 macOS 也支持了这种 per thread 的权限限制?
    iseki
        27
    iseki  
       64 天前 via Android   ❤️ 1
    这有点坑啊,这种重大变更怎么能无预警直接推呢,至少也应该保留一个逃生门。
    iseki
        28
    iseki  
       64 天前 via Android
    @rainbowmolly 触发段错误信号的行为是良定义+可保证的,如果能用来提升性能为啥不能用。你说的直接退出只是因为没有好好处理段错误信号吧。
    iseki
        29
    iseki  
       64 天前 via Android
    @codehz Go 写的程序可能也受影响,它的空指针访问也是可以在程序内部捕获的,而且好像也是通过段错误信号兜住的(只观察过 Linux/Windows 平台)
    codehz
        30
    codehz  
    OP
       64 天前
    @iseki 啊,写错了,是要有 jit ,还得刚好处于 write 的状态触发
    jay2049
        31
    jay2049  
       64 天前
    感谢楼主提醒
    coang
        32
    coang  
       64 天前
    优秀的系统,垃圾的 JDK,居然能影响这么多个版本 Java 怎么做的兼容性测试!!(狗头
    ipcjs
        33
    ipcjs  
       64 天前   ❤️ 2
    Windows 用的 beta 版都从来没问题,macOS 升一次一堆软件出问题,老早把那个傻 diao 自动升级关掉了💩
    ShadowPower
        34
    ShadowPower  
       64 天前   ❤️ 3
    上星期已经被坑了,感觉 mac 做开发的体验真的不如 Windows 了……
    Windows 的稳定版我都随意更新
    codehz
        35
    codehz  
    OP
       64 天前   ❤️ 1
    找到了一个问题复现的代码
    #include <stdio.h>
    #include <sys/mman.h>
    #include <pthread.h>

    int main() {
    pthread_jit_write_protect_np(0);

    char* mem = (char*)mmap(0, 16 * 1024, 0, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0);
    fprintf(stderr, "addr = %p\n", mem);

    char value = *mem;
    fprintf(stderr, "value = %c\n", value);

    return 0;
    }
    ,在之前版本里是 sigbus ,可以捕获,14.4 就直接 sigkill 了
    原来这个 write 模式是指这玩意
    stinkytofu
        36
    stinkytofu  
       64 天前   ❤️ 1
    MAC 现在确实不敢随意更新版本, 说不定什么刚需软件就工作不正常了, 很难受。
    tt0411
        37
    tt0411  
       64 天前   ❤️ 1
    怪不得 clion 时不时 crash...
    iseki
        38
    iseki  
       64 天前   ❤️ 1
    @codehz 还行,看了下只要他们切换下保护就没事了

    > We discovered that if we switch the jit protection mode to EXEC rather than WRITE, then these page faults again raise the expected SIGBUS not a SIGKILL. Note the faulting accesses are predominantly reads and have nothing at all to do with accessing a MAP_JIT memory region.
    > We have been working on a patch that switches the jit protection mode to EXEC around these potential faulting memory accesses. It has been a bit of an exercise in whack-a-mole finding them all, and testing is still in progress.
    iseki
        39
    iseki  
       64 天前   ❤️ 1
    不过这种破环兼容性的做法真是一言难尽
    leonshaw
        40
    leonshaw  
       64 天前 via Android
    这么说哪天 CPU 也可以不给 page
    leonshaw
        41
    leonshaw  
       64 天前 via Android
    这么说哪天 CPU 也可以不给 page fault 了,直接 halt 麻烦你内核重新适配一下。
    Solael
        42
    Solael  
       64 天前   ❤️ 2
    呵呵苹果一贯操作,你不像 windows 一样先前兼容也就罢了,测试恐怕也是阿三随便点几下就完事了,连编译程序都不测试是吧。
    noahlias
        43
    noahlias  
       64 天前
    还好没更新 14.4
    DigitalG
        44
    DigitalG  
       64 天前
    看了一下,这个是不影响用户使用 java 程序是吧?只影响做 java 开发的用户,或者开发时用了基于 java 的 IDE 程序?
    codehz
        45
    codehz  
    OP
       64 天前   ❤️ 2
    @DigitalG 只是不影响用 graalvm 这样直接 aot 的,其他 java 程序全都受到影响
    OneMan
        46
    OneMan  
       64 天前
    还好不升级
    Rorysky
        47
    Rorysky  
       64 天前
    @meloyang05 #4 都是访问被保护区域了,java jit 还要依赖这个内核行为,这不是奇技淫巧的优化是什么?
    parthenon2007
        48
    parthenon2007  
       64 天前   ❤️ 2
    难怪这几天 IDEA 莫名其妙崩了。
    Rorysky
        49
    Rorysky  
       64 天前   ❤️ 4
    @meloyang05 #4

    苹果开发这个开发文档明确说了,访问受保护区域属于预期外的行为,这能怪谁?
    "A crash due to a memory access issue occurs when an app uses memory in **an unexpected way**"

    https://developer.apple.com/documentation/xcode/investigating-memory-access-crashes
    iseki
        50
    iseki  
       64 天前 via Android
    @Rorysky 一大票设施利用这个段错误和总线错误信号来做兜底呢,这要是可以随便改大家程序都不要写了。好在这次水果只是改了一个特例而已。
    预期外的行为,它也是良定义的,看看你引用的这句话的下一句。
    iseki
        51
    iseki  
       64 天前 via Android   ❤️ 1
    注意下 unexpected 不等于 undefined 也不等于 unspecified
    felixlong
        52
    felixlong  
       64 天前   ❤️ 2
    @Rorysky 这也洗,你没看 Oracle 的人说吗,Mac 14.4 最后一个 RC 版本行为都没改,最后正式版本突然改了。这让人家怎么来的及修?
    Rorysky
        53
    Rorysky  
       64 天前
    @iseki #50 不要随便迁移概念, 你说的良定义猜测就是 well-defined 吧,这是描述语言标准本身的可移植性(或者说语意不依赖于运行环境,只要支持语言标准就能保证一致性输出),这和系统内核行为有什么关系,旧版本的信号量是来提示程序 bad access 的,它不是一个特性,java 不应该利用来实现功能。

    普通的程序运行中 bad access ,系统认为进程有问题了,直接杀掉是激进了,但估计是为了安全的原因。

    就像人犯罪了,监管机构是口头教育,还是 逮捕教育,还是就地正法,那是监管机构决定的,你不能说我利用这个机会去接受某些信息/更快的见到某些人
    Rorysky
        54
    Rorysky  
       64 天前
    @felixlong #52 本来就是错误的设计,啥时候都是错误的(我并不知道 jit 怎么利用这个非法行为去加速执行
    iseki
        55
    iseki  
       64 天前 via Android   ❤️ 1
    @Rorysky 信号量怎么就不是一个特性了?这都是写在文档上的,就因为它预期中不常见,所以就不是个特性从而可以随便更改了?既然承诺了它所产生的效果和副作用,怎么就不能用于优化了?实际上因为这个动作的延迟相对较高,JVM 的 JIT 也是用来做非预期分支去优化判定的。
    一个东西既然承诺了效果,那就不该去干涉使用者怎么用,除非你有合理的理由,提前注明。
    iseki
        56
    iseki  
       64 天前 via Android
    @Rorysky
    > Null checks are cheap. They usually fold straight into a related memory access instruction, and use the CPU bus logic to catch nulls. (Deoptimization follows, with regenerated code containing an explicit check.)
    iseki
        57
    iseki  
       64 天前 via Android   ❤️ 1
    @Rorysky 如果利用捕获 sigsegv 去做某些事是错误的,那设计这个信号量又是为了什么?如果你说有些事可以做有些事不能做,那就得讲明白哪些事不能做,有什么合理的理由。
    BeiChuanAlex
        58
    BeiChuanAlex  
       64 天前
    吓死我了,还我写 rust
    cubecube
        59
    cubecube  
       64 天前
    only apple can do
    felixlong
        60
    felixlong  
       64 天前   ❤️ 3
    @Rorysky 呵呵,我打赌 Apple 会把这个改回去。你信不信?
    iseki
        61
    iseki  
       64 天前 via Android
    @felixlong apple 这个只是一个很 corner case 的场景,到不好说会不会改回去,也许就让大家吃了。
    CFM880
        62
    CFM880  
       64 天前
    @ShadowPower windows Android Studio 也有 bug ,一个陈年老 bug https://issuetracker.google.com/issues/167701947 ,特别恶心,我基本新加一个包,再新建包下面新建一个类文件,必出这个 bug
    wpei
        63
    wpei  
       63 天前
    @meloyang05
    @ychost
    我一直以为是我的 usb hub 坏了,没想到是苹果的问题...
    seanxx
        64
    seanxx  
       63 天前   ❤️ 2
    mac 已经不是原本的 mac 了,充斥着烂臭咖喱味,能用就不会升级
    ShadowPower
        65
    ShadowPower  
       63 天前
    @CFM880 好吧,我已经 3 年没有做 Android/iOS 相关的工作了……
    2kCS5c0b0ITXE5k2
        66
    2kCS5c0b0ITXE5k2  
       63 天前   ❤️ 1
    @Rorysky java8 就开始用了. 苹果为什么突然修改? 而且问题是 rc 版都没问题. 正式版就修改 那测试版是来用干什么的?
    felixlong
        67
    felixlong  
       63 天前
    @codehz 应该不是你说的那个检测 NullPointerException 的优化导致的。那个行为影响太大了,而且那是 Posix 的标准行为,Apple 应该没有改变。
    好像与 Mac 在 M 系列处理器引入的新的 pthread_jit_write_protect_np 有关系。Apple 确实只说了用 MAP_JIT mmap 出来的 region 要么只能 write ,要么只能 executable ,从来没提过 read 会发生什么事情,以前是在 write protect on/off 都发送 SIG_BUS, 14.4 改成了 write protect on 的时候发 SIG_BUS ,write protect off 的时候发 SIG_KILL,真是迷惑行为。不知道为啥 JDK 生成的 jit code 需要 read 自己?
    codehz
        68
    codehz  
    OP
       63 天前
    @felixlong 上面我发了复现代码了,可能确实不是 0 页面的访问,但 mmap 只是去申请了一个权限为 0 的页面,然后去访问,正常情况只会触发 sigbus ,但 14.4 结合 write protection 后会直接 sigkill
    这里不涉及任何真正的 jit 只是单纯的开一个页面当做 guard page
    ShadowPower
        69
    ShadowPower  
       63 天前
    @codehz 这是不是意味着 macOS 已经破坏了 POSIX 兼容
    Jirajine
        70
    Jirajine  
       63 天前
    这是依赖 UB 的特性,也不是关键特性,当然可以 break 。为使用 UB 特性、未定义接口的程序做兼容才是万恶之源。
    这里的问题是依赖这个 UB 的程序( jvm )被广泛部署,而这项改动在推送前没有充分测试。
    fredweili
        71
    fredweili  
       63 天前
    升级过了,还没遇到问题
    codehz
        72
    codehz  
    OP
       63 天前
    @Jirajine 首先这不是 ub ,是标准允许的做法,其次虽然可能不是 null 的那个问题,但另一个 guard page 更是这个 api 的原本目的,不然为何提供 mmap PROT NONE 这个选项
    parthenon2007
        73
    parthenon2007  
       63 天前   ❤️ 2
    @seanxx #64 说得对,苹果总是犯一些低级错误。我甚至怀疑他们内部程序员为了刷 KPI ,喜欢把之前的功能反复拿出来重构。苹果通过破坏兼容性得以抛弃的历史包袱并没有能提升他们的代码质量。
    codehz
        74
    codehz  
    OP
       63 天前
    @felixlong
    测试了一下,访问 null 也真的会导致 sigkill (去掉 pthread_jit_write_protect_np(0)这句就 SIGSEGV)
    #include <pthread.h>

    int main() {
    pthread_jit_write_protect_np(0);
    return *((int *)NULL);
    }
    fantaxi
        75
    fantaxi  
       63 天前
    Only apple can do !
    felixlong
        76
    felixlong  
       63 天前
    @codehz 哈哈,估计 Apple 认为在 write_protect disable 模式下这个线程就只应该运行生成 JIT 代码的代码,不能干其它的事。也许 Apple 认为生成 JIT 代码的代码本身不会有这些骚操作。
    daveh
        77
    daveh  
       63 天前 via iPhone   ❤️ 2
    @codehz OpenJDK 已经改了,JRE 自己屎山代码的问题,为之前 Solaris 做的一个优化,还需要 Solaris 专有 API 配合才行,然后 Solaris 死了十几年了,这个却作为垃圾代码一直残留下来。
    直到在最新 macOS 下帮发现了问题,OP 自己去看下 OpenJDK 的修改记录,不要在这瞎猜。

    JB 已经有测试 JBR 发布,可以自己临时规避一下。

    Apple 可改可不改,如果是安全原因不一定会改,但老版 JRE 使用也挺多,问题报多了可能也会改回去。
    codehz
        78
    codehz  
    OP
       63 天前   ❤️ 1
    @daveh 这个问题就是苹果的错误,就算 JRE 触发是一个意外,也不能改变它就是苹果的错误,因为这个行为( pthread_jit_write_protect_np 0 的时候 SIGSEGV 和 SIGBUS 变为 SIGKILL )没有任何文档提及,也没在更新日志里包含,乃至专门介绍安全性的更新内容( https://support.apple.com/zh-cn/HT214084 )的文档也没有说有这个变更
    OpenJRE 自己去 workaround 这个问题,和苹果意外搞出的错误没有任何关系
    codehz
        79
    codehz  
    OP
       63 天前   ❤️ 1
    @daveh 此外 pthread_jit_write_protect_np 是只有 macOS 给 apple sillicon 提供的功能,solaris 根本就没这个 api ,何来的十几年的垃圾代码
    daveh
        80
    daveh  
       63 天前 via iPhone
    @codehz #79 都说了你去看 OpenJDK 的修改,删了一拖屎山。不要在这瞎猜,如果你真对这个问题感兴趣的话。
    lslqtz
        81
    lslqtz  
       63 天前   ❤️ 2
    @Rorysky 合理了.
    不用担保的 API 或特性去产生的任何行为都不应该被视为可靠的, 利用这种特性去做的程序本身也是不可靠的, 只不过这个不可靠性取决于上游 (也就是 Apple).
    大家都用 **不等于** 这么用正确.

    不过 Apple 在 Dev 不改甚至 RC 不改, 却在正式版改, 太激进了, 这样的发布策略并不合理.
    lslqtz
        82
    lslqtz  
       63 天前
    即, 未担保的方法/接口 显然是可以改动的, 但在改动之前, 应该先进行小范围/大范围测试, 而不是直接推到正式版上, 利用这种未担保特性显然是程序本身的问题, 但如果这种未担保特性的影响特别广泛, 那么测试有助于提前解决问题.
    codehz
        83
    codehz  
    OP
       63 天前   ❤️ 1
    @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
    lslqtz
        84
    lslqtz  
       63 天前
    我重新看了看这个文档:
    These crashes are **most often** identified by the EXC_BAD_ACCESS (SIGSEGV) or EXC_BAD_ACCESS (SIGBUS) exceptions in the **crash report**
    所以 Apple 并不保证这个信号一定是两者中的其中之一, 但又说的很隐晦...
    codehz
        85
    codehz  
    OP
       63 天前   ❤️ 1
    @lslqtz 你看的是 https://developer.apple.com/documentation/xcode/investigating-memory-access-crashes 这个吧,问题是这并不是同一个问题,它是“调查因内存问题而崩溃的方法”
    bghtyu
        86
    bghtyu  
       63 天前
    @daveh 请问这个测试版的 JBR 应该去哪里下载,没有找到
    daveh
        88
    daveh  
       63 天前 via iPhone   ❤️ 1
    daveh
        89
    daveh  
       63 天前 via iPhone
    @codehz #83 问题就在这里。

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

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

    所以说 macOS 这个新行为,反而督促了 JDK 去优化改进,去发现问题。
    daveh
        90
    daveh  
       63 天前 via iPhone
    @codehz #78 JDK 的改动不是 workaround ,建议你追加更新一下实际原因,不要误导。
    codehz
        91
    codehz  
    OP
       63 天前
    @daveh SafeFetch 整个函数的意义就是访问非法地址的时候能检测到结果,你是不明白这个 fetch 的含义吗。。。
    https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/safefetch.hpp#L31-L32
    codehz
        92
    codehz  
    OP
       63 天前
    @daveh https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/safefetch_sigjmp.cpp 在 posix 下的实现就是 sigsetjmp 保存跳转地址,然后在异常处理代码里检测 SIGSEGV 和 SIGBUS 来跳转到返回 false 的分支
    MrKrabs
        93
    MrKrabs  
       63 天前
    java 配不上金子内存,自己滚吧
    huijiewei
        94
    huijiewei  
       63 天前   ❤️ 1
    这种特性不是病毒最喜欢用的么。Java 也用啊。
    ShadowPower
        95
    ShadowPower  
       63 天前 via Android   ❤️ 1
    @daveh 幸好苹果的客户主要是普通消费者。我上班做 toB 的项目,要是公司的项目像苹果这样做,免不了要赔偿,还得加班给客户处理好所有问题。
    daveh
        96
    daveh  
       63 天前 via iPhone
    @codehz #92 你代码都引用错了,macOS/bsd 、Linux 都不用这个代码,让我该说什么好呢?

    而且非法地址检测现在也能。
    codehz
        97
    codehz  
    OP
       63 天前   ❤️ 1
    @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
    不是很懂为啥要杠这一点
    codehz
        98
    codehz  
    OP
       63 天前
    @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
    tanranran
        99
    tanranran  
       62 天前
    houshuu
        100
    houshuu  
       62 天前 via iPhone
    我们公司每次有个专门 team 先把开发环境先全测了没问题才允许全公司升级,以前觉得小题大做,这次完美避过了
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1120 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 18:45 · PVG 02:45 · LAX 11:45 · JFK 14:45
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.