I would like to amplify this point — undermining Java’s integrity is a big deal. Every time we use unsafe mechanisms within the JDK we risk doing that. The more complex such code is the harder it is reason about whether overall it is safe [*]. We need to balance reasoning about code, quality, and maintenance of against narrowly measured performance benefits that increase the risk of some integrity violation.
Paul. [*] And even if it is not so complex, others may not be aware of the subtleties when refactoring. Unsafe allocation that does not zero memory is particular worrisome in this regard. > On Feb 7, 2025, at 7:42 AM, Archie Cobbs <archie.co...@gmail.com> wrote: > Good point, but frankly, an irrelevant one. The key issue here is that if > plain, ordinary, non-native-invoking Java bytecode can corrupt memory and/or > crash the JVM, then that's a Big Problem™️. It doesn't matter how contrived > the code that makes it happen is. > > -Archie > > -- > Archie L. Cobbs
