On Thu, 20 Jul 2023 13:38:14 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>>> The Unsafe-based writing will be used by `Integer.toString` and >>> `Long.toString` as well; in those cases, will creating a ByteBuffer wrapper >>> be overkill? >> >> Integer/Long are very core classes so I assume they can use Unsafe if >> needed, they probably want as few dependences as possible. > >> in those cases, will creating a ByteBuffer wrapper be overkill? > > Perhaps - but do we have any benchmark to back up that claim (or backing up > the fact that Integer.toString would benefit from using ByteArray in the > first place) ? It is likely that in code that is compiled and inlined, this > will make no difference at all, as an object that is created, and then > disposed of will be routinely scalarized (since there's no meaningful control > flow). > > If in some cases we have reason to believe that we need more performance, we > could always fall back and use Unsafe directly. > > I guess in general I'm a bit skeptical re. creating a class that wraps an > array and exposes get/setXYZ that are implemented by Unsafe, adding some > bound checks on top. That's 99.99% of what an heap buffer does. I've > benchmarked BB quite a extensively given my work on Panama and I can assure > that, if accessed using the right API (e.g. absolute addressing scheme, which > takes an offset) and the right endianness (ByteOrder::NATIVE_ORDER), the > performance of BB access is very very very close to Unsafe (esp. here, given > that ByteArray also introduces some kind of bound check). Also... `Integer::toString` seems to be `@IntrinsicCandidate` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269488090
