ruby-trunk-changes r63710 - r63723

今日は RubyVM::MJIT.pause, resume メソッドの追加、Mutex の deadlock の恐れがあった不具合修正、endless range に対する Range#to_a, #size, #max, #min などのメソッドの挙動変更などがありました。

k0kubun: r63710 2018-06-21 23:04:05 +0900

RubyVM::MJIT.pause と RubyVM::MJIT.resume というメソッドを追加しています。 MJIT の worker を起動する pthread を止めたり再開したりするコントロールができるようになっています。チケットをみると、これは MJIT が JIT コンパイル用に gcc などのコンパイラを動かすのがベンチマークのノイズになるので、必要なコンパイルが終わった時点でそれ以上のコンパイルが走るのを止めたいというもののようです。 [ruby-core:87428] [Feature #14830]

normal: r63711 2018-06-22 11:32:30 +0900

Mutex の実装で RUBY_VM_CHECK_INTS_BLOCKING() で割り込みチェックするとその時点で mutex->th が書き変わっている恐れがあるのを見落していいて deadlock する可能性があった不具合を修正しているようです。じーっと睨んでなんとなくわかった気がするけどちゃんとした再現シナリオはよくわかってない。 たぶん r58604 で Mutex の実装に直接 pthread_mutex_t などを使うのをやめて linked list を使った実装に変えた時の影響なのではないかと思いますが、normal によれば 2.4 以前からあったんじゃないかってことで backport が REQUIRED に設定されてます。うーん、そうなのかな? 少なくともこの差分そのまま backport は無理そうだと思うけど。 [ruby-core:87467] [Bug #14841]

svn: r63712 2018-06-22 11:32:32 +0900

version.h の日付更新。

normal: r63713 2018-06-22 11:43:51 +0900

rb_vm_t::sleeper の宣言から volatile を外しています。 さっきの deadlock 修正のチケットの中でついでに normal が気がついたようです。 [ruby-core:87467] [Bug #14841]

mame: r63714 2018-06-22 11:58:37 +0900

終端が nil の Range いわゆる endless range に Range#to_a が呼ばれたらすぐに RangeError 例外を発生させるようにしています。まああきらかに止まらなくなる(というかメモリ食いつぶして NoMemoryError?) からそれよりは例外になって欲しいですよね。 [ruby-dev:50568] [Bug #14845]

mame: r63715 2018-06-22 11:58:39 +0900

終端が nil の Range いわゆる endless range に Range#size が呼ばれたら Float::INFINITY を返すようにしています。修正前は例外になりそうな感じなので、それよりはましな気がしますが、うーん、そうか Float::INFINITY か……。 [ruby-core:86612] [Bug #14699]

mame: r63716 2018-06-22 11:58:40 +0900

終端が nil の Range いわゆる endless range に Range#last や Range#max を呼んだ時も RangeError 例外を発生させるようにしています。 last はそうだよなあ。Range#max は終端のオブジェクトを得るので、終端はないので…… Float::INFINITY はあくまで収束先だから……みたいなこう ruby の禅を感じる一連の仕様定義でした。 [ruby-core:86612] [Bug #14699]

mame: r63717 2018-06-22 12:07:24 +0900

見落としてましたが r63716 で endless range にブロック付きで Range#min を呼ばれた時にも RangeError を発生させるようにしていて、そのテストを追加しています。 [ruby-core:86612] [Bug #14699]

nobu: r63718 2018-06-22 13:13:02 +0900

configure 時に config.h に DISABLE_RUBYGEMS の定義を出力するのをやめて、かわりに USE_RUBYGEMS という変数を管理してこれが no の時に $CPPFLAGS にコマンドラインオプションで -DDISABLE_RUBYGEMS=1 を追加するようにしています。コミットログを読む感じだと、たぶんデバッグ(?)とかでこのオプションを切り替えてビルドしなおす時に config.h が更新されて全体再ビルドになるのが辛いので、みたいな感じに読めます。configure しなおしたらどのみち再ビルドになるんじゃないのかな?

normal: r63719 2018-06-22 15:17:15 +0900

thread.c の sleep_timespec() で spurious wakeup のチェックの前にタイマーの更新をしていたのでチェックの後にずらしています。

normal: r63720 2018-06-22 17:47:12 +0900

dir.c で O_CLOEXEC がない環境では 0 に定義するマクロを追加しておくようにしています。 SuSE 10 には O_CLOEXEC がないためビルドエラーになってたそうで。 O_CLOEXEC ってそんなに新しめのものだっけ? と思ったら SuSE 10 ってもう 10年くらい前のバージョンみたいですね。若干ヤケクソ気味の対応でした。 [ruby-core:87591] [Bug #14864]

naruse: r63721 2018-06-22 19:53:03 +0900

Travis CI で r63598 の Windows で Net::HTTP の write_timeout のテストが失敗するようで、assertion のメッセージに systcl net.ipv4.tcp_wmem の出力を含めるようにしています。

naruse: r63722 2018-06-22 20:10:56 +0900

r63721 の続きで今度は sysctl net.core.wmem_default と sysctl net.core.wmem_default をメッセージに含めるようにしています。

naruse: r63723 2018-06-22 20:57:06 +0900

r63721 および r63721 のテストのデバッグ用のメッセージ追加を消しています。