博士

やっほー、ロボ子！今日のITニュースはRactorの並列処理改善についてじゃ。

ロボ子

博士、こんにちは。Ractorの並列処理ですか。グローバルロックがボトルネックになっているという話ですね。

博士

そうそう！Ruby VMのグローバルロックのせいで、Ractorが力を発揮できないのじゃ。でも、`fstring_table`のロックフリー化でJSONベンチマークがシングルスレッド版の2倍になったらしいぞ。

ロボ子

それはすごいですね！でも、記事によると`object_id`メソッドが新たな競合ポイントとして浮上しているとか。

博士

`object_id`か。Ruby 2.6以前はオブジェクトのアドレスを基に生成してたけど、2.7でGC compaction導入でハッシュテーブル管理になったんじゃ。

ロボ子

ハッシュテーブル管理は、メモリ使用量とCPUコストが増加する原因になっているんですね。

博士

その通り！複数のRactorが同時にハッシュテーブルにアクセスすると競合が起きる。`Object#hash`メソッドも`object_id`に依存してるから、同じ問題が起きるんじゃ。

ロボ子

なるほど。それで、`object_id`の最適化に向けた試みとして、`ObjectSpace._id2ref`の遅延初期化が行われたんですね。

博士

そうじゃ。メモリ使用量とGCの負荷を減らすためじゃ。さらに、オブジェクトの形状(shape)を利用して、`object_id`をオブジェクト内にインラインで格納する方式も検討されているらしい。

ロボ子

インラインストレージですか。でも、形状の子の検索・作成にはVMの同期が必要で、Ractor間で共有されるオブジェクトにはロックが必要になるんですね。

博士

`T_OBJECT`や`T_CLASS/T_MODULE`以外のオブジェクトでは、別のハッシュテーブルが必要になるという課題もあるぞ。

ロボ子

今後の課題は、"generic"オブジェクトの最適な処理方法の検討や、シンボルテーブルやメソッドテーブルなど、他の内部テーブルの改善ですね。

博士

その通り！道のりは長いけど、Ractorの並列処理が改善されれば、Rubyのパフォーマンスはもっと上がるはずじゃ！

ロボ子

そうですね。博士、今日は色々と勉強になりました。

博士

ところでロボ子、`object_id`って、オブジェクトの魂みたいなものだと思わない？

ロボ子

魂、ですか？

博士

だって、オブジェクトが消えても、`object_id`は永遠に残る…かもしれないじゃん？

ロボ子

それはちょっと違うと思います…博士。

博士

ま、いっか！それじゃ、またね！