Javaのレコードをネイティブメモリへ爆速マッピング！新ライブラリのご紹介

Javaのレコード（records）をネイティブメモリに高速かつ効率的にマッピングするためのライブラリです。パフォーマンスを極限まで追求したい開発者の方に最適なソリューションです。

これは興味深いね。Javaには、高パフォーマンスなアリーナ上で型安全なシュガーとして機能するstructの配列がどうしても必要だけど、これを使おうとするような局面ってゼロアロケーションを目指すような場所でしょ。このライブラリのオフヒープのコストや、getter/setterでのオブジェクトアロケーションを考えると、多くのユースケースでメリットが打ち消されてしまいそう。

いいね。APIがすごくすっきりしてる。

なんでGraalを使わないの？

これの立ち位置は何で、どう動くものなの？SBEとの比較があると嬉しいかも。

LayoutやMemorySegmentを使うのが冗長だという問題はわかるけど、自分がそれらを使っているのは、オフヒープメモリを利用してオブジェクトのアロケーションを回避するような、パフォーマンス重視のソフトウェアを開発するためなんだよね。

「Javaのrecord型をネイティブメモリにマッピングする」って具体的にどういう意味？Javaのrecordを何らかの方法でフライウェイトに変換しているのか、それとも Point point = points.get(0); はオフヒープメモリから読み取ったデータを使ってrecordのインスタンスを生成しているだけなのか？もしリフレクションを使った動的なマッピングライブラリだとしたらクールだけど、それだと多くのJavaオフヒープ利用におけるパフォーマンス目標を台無しにしてしまわないかな？

これは、パフォーマンスがそれほど重要じゃない場面で、データを通常のJavaヒープ領域に引き出すためのオフヒープからヒープへのブリッジという扱いなの？

パッと見、C#のSpan<T>を思い出すな。

数年前に似たようなことをやったことがあるよ。宣言へのアプローチを少し変えて、インターフェースを使ってstructのレイアウトを定義するようにしたんだ。ミューテーションは（当時の）標準的なJavaBeansのレイアウトを使ってsetterを公開することでオプトインにして、アノテーションプロセッサが実装クラスのコード生成を担当する仕組み。これを使えば、オフヒープ構造体のヒープ内ボックスが必要な場所で利用できた。

このアプローチの利点の一つは、インターフェースを型として使うことでフライウェイトパターンをかなり簡単にサポートでき、大規模なオフヒープコレクションを扱う際のGC負荷を減らせることだった。ステートレスなインターフェースとオフヒープ構造体の類似性も、なかなかいい感じだったよ。

Unsafeなどよりもモダンな技術を使って、似たような試みをもっと見てみたいね。

これってSBEのエンコーダー/デコーダーが生のメモリに対して行うフライウェイトとかなり似てないか？違いは何？

Apache Arrowでも同じ目的を果たせないのかな？