今日は主にオブジェクトの slot のところに追加のメモリを確保するための機構の実装変更(デフォルトでは無効ですが)や Ractor 間で Hash を共有した時の不具合修正などがありました。
[c08d4067be] Peter Zhu 2021-08-24 17:14:14 UTC
オブジェクト内の追加のメモリ領域を普通の(malloc(3) などで確保する)ヒープに確保するかわりにオブジェクト(struct RVALUE) を確保する slot に確保するために 8bbd3198068f5e8335ab01f0b29cdae225b25b5b で追加された T_PAYLOAD というオブジェクトの種別を削除しています。 48ff7a9f3e47bffb3e4d067a12ba9b936261caa0 のリトライ、というかこのコミットについてはほぼ完全に同じですね。 [ruby-core:104684] [Feature #18045]
[62bc4a9420] Peter Zhu 2021-08-24 17:14:23 UTC
c08d4067be83d03a6fcd173ffd2d206a01d09c90 の続きでオブジェクト用の slot を通常のメモリ確保のかわりに使うための機構として T_PAYLOAD のかわりとして、そもそも slot のサイズが異なる(x1 から x4まで) page を用意して、追加の領域が必要なオブジェクトの確保時には要求するサイズが収まる page を使うようにしているようです。そもそもこのメモリ領域は rb_classext_t みたいにオブジェクトの struct RVALUE に収まらないためそこからポインタで参照している領域に使うためなのでそのオブジェクト用の slot に連続して確保したいので、最初からそのぶん大きく確保できるならそのほうが効率的ということでしょうか。こうなるとポインタで参照しているのも無駄なので構造体のレイアウト自体を大きくできるようにしようとかいうことになるかもしれませんけど、それは拡張ライブラリの互換性が壊れちゃうかな。かなり大規模な変更ですが USE_RVARGC マクロが定義されてないとデフォルトでは有効になっていなくて従来の slot サイズの page しか作らないようにしています。
b2e2cf2dedd104acad8610721db5e4d341f135ef のリトライで、どうやら全体的に intptr_t のかわりに uintptr_t を使うように変更しています。なるほど、これをデバッグしていて 6648b411f7350711417936865331cf5066ef35aa の修正が出てきたんですね。 [ruby-core:104684] [Feature #18045]
[f4b88959d5] Kevin Newton 2021-08-25 13:32:10 UTC
sample/exyacc.rb というサンプルスクリプトで置換ルールが間違っていたのを修正しています。.y ファイルからルールを抜き出すものみたいですね。
[27410eaeb2] git 2021-08-26 01:24:21 UTC
version.h の日付更新
[a2ad0cb7b4] Sutou Kouhei 2021-08-24 02:22:00 UTC
Ractor で共有した Hash に Hash#each などのイテレーターとして動くメソッドが競合することがあるという不具合の対応のため、freeze した Hash の処理中に each 内で hash_iter_lev_inc() を呼ぶのをやめるようにしています。freeze されてるということは更新されない(削除もされない)ので不要とのこと。iter_lev って Hash#each 中に要素の追加/削除などしないようにするためのものでしたっけ確か。
[9c0582704f] Lars Kanis 2021-08-25 10:03:35 UTC
blocking Fiber のテスト用の Scheduler の run メソッド実装で、@readable と @writable のインスタンス変数から取り出した読み書き可能な fiber がそれぞれ反対の writable/readable にも入ってたらそっちを削るようにしています。読み書き同時にできるようになるまで待たないといけないから? けど反対のを削ると待たなくなっちゃいそうな気がするけど、ちょっとよくわからないです。また writable のほうの処理で nil チェックが漏れてたところも修正しています。そしてテスト用の Scheduler 実装の修正の確認のためのテストも Fiber のテストに追加されています。テスト用の Scheduler の実装のテストか〜。まあ他に書く場所もないのでしかたないですね。
[5e65f31b5a] Kazuhiro NISHIYAMA 2021-08-25 02:11:03 UTC
GitHub Actions の Windows 版のビルドに Windows Server 2022 と Visual Studio 2022 を追加しています。
[b1f58d3e91] Kazuhiro NISHIYAMA 2021-08-25 02:51:45 UTC
5e65f31b5ad7b2143f3905863649e43f2c238281 の続きで GitHub Actions の Windows 版で Visual Studio のバージョンは matrix に直接入れずに Windows のバージョンにあわせて VCVARS 変数を変更することで対応するバージョンを使うようにしています。
[d96ba8c5c3] Kazuhiro NISHIYAMA 2021-08-25 06:57:02 UTC
さらに続きで GitHub Actions の Windows 版での configure に Windows のバージョンに応じて Windows Server 2022 では --enable-bundled-libffi オプションを消すようにしています。
[69615251f9] Kazuhiro NISHIYAMA 2021-08-25 08:34:35 UTC
GitHub Actions の Windows 版で make test-all と make test-spec のエラーを Windows Server 2022 版のほうでは無視するようにしています。
[5550c2719a] Kazuhiro NISHIYAMA 2021-08-26 02:06:55 UTC
GitHub Actions の Windows 版で msys2/setup-msys2 という提供されてるアクションを利用して MSYS2 で patch コマンドをインストールするようにしています。
[79a3e89dae] Kazuhiro NISHIYAMA 2021-08-26 05:05:34 UTC
GitHub Actions の Windows 版で Windows Server 2022 の時は libffi をインストールしてみるようにしてましたが、やっぱりどちらも同梱されている libffi を使うようにしています。VC 2022 でもだめだったのかな。
[ef10e8a1eb] Kazuhiro NISHIYAMA 2021-08-26 06:11:48 UTC
GitHub Actions の Windows 版で MSYS2 でインストールした patch コマンドのパスが変化してたみたいで PATCH 変数に設定しているパスを変更しています。
