今日はインスタンス変数の管理の実装の変更や GC 中にマシンスタックオーバーフローが起きた時の対応の変更などがありました。
[0d17cdd0ac] Alan Wu 2020-10-15 18:51:30 UTC
GC 処理中に machine stack のオーバーフローを検知した時に例外発生をあきらめて rb_bug() で異常終了させるようにしています。コミットログによれば拡張ライブラリで mark 関数内でスタックオーバーフローを起こされた場合 GC 途中で ruby レベルに戻せない状態で発生する可能性があるのでその後不正な状態になるのであきらめるとのこと。
[ac803ab55d] Yusuke Endoh 2020-10-16 15:07:35 UTC
de5e8d0e3bc3cc39487ffc9d9c15642b6881cd54 の続きで標準添付ライブラリ rinda のテストでのタイムアウト調査のため Rinda::RingServer#do_reply にモンキーパッチをあてて例外発生時のデバッグ出力を加えています。
[26e8db6b93] git 2020-10-16 15:08:33 UTC
version.h の日付更新
[ff9dc10966] Aaron Patterson 2020-09-17 16:43:32 UTC
TracePoint の C API 用のテストの拡張ライブラリで Proc オブジェクトを Module のインスタンス変数に保持してたのをやめています。ちょっとよくわからないのですが GC.compact 絡みでこの拡張ライブラリの実装方法はよくなかったということみたいですね。そのかわりに呼び出す ruby スクリプトのほうでローカル変数に Proc オブジェクトを格納しておくようにしています。しかしこれダメなのかな。
[91ec5f9e39] Koichi Sasada 2020-10-14 07:59:31 UTC
rb_obj_iv_index_tbl() というインスタンス変数テーブルを得る C API を削除しています。公開 API ですが rubygems に登録されているものを検索した限りだと使われてなさそうで、内部構造を変更したいので、ということみたいです。
[f6661f5085] Koichi Sasada 2020-10-16 06:20:40 UTC
ということで 91ec5f9e39cf54dd7a157addb778293853571f13 で書いてたインスタンス変数の保持についての内部構造の変更。インスタンス変数の名前(ID)とテーブルのインデックスの対応として保持していたのを、IDから struct rb_iv_index_tbl_entry という構造体の対応を保持するようにして、インスタンス変数参照の inline cache も導入しています。インスタンス変数は Ractor 間で同期されている必要があるのでロック取得する必要があり、そのパフォーマンス劣化を補うために inline cache も導入した、ということかな。
[5c003b4bcd] Yusuke Endoh 2020-10-17 06:17:55 UTC
de5e8d0e3bc3cc39487ffc9d9c15642b6881cd54 および ac803ab55db50ef891e3680680620d01f28a759b でデバッグしてた標準添付ライブラリ rinda のテストでのエラーの修正。 DRb::DRbObject.new の引数に渡してる変数と同じ変数に DRb::DRbObject を格納して上書きしていたため、元のオブジェクトの参照がなくなって GC で解放されてしまう可能性があったために起きてたようです。変数名を変更して元のオブジェクトも参照が残るように修正しています。
[6a9e09824b] Yusuke Endoh 2020-10-17 06:32:19 UTC
5c003b4bcd70b03012f6d2e322bd175efd226528 で修正した rinda のテストのデバッグのための ac803ab55db50ef891e3680680620d01f28a759b を revert。
[09dd9d8e5d] Yusuke Endoh 2020-10-17 06:32:40 UTC
5c003b4bcd70b03012f6d2e322bd175efd226528 で修正した rinda のテストのデバッグのための de5e8d0e3bc3cc39487ffc9d9c15642b6881cd54 を revert。
