今日は alloca() の利用を減らす修正など内部的な変更が主でした。
nobu: r44477 2014-01-01 22:11:24 +0900
r44462 で追加したダミーエンコーディングでの String#encode のテストで assert_nothing_raised にメッセージの引数を追加して、ついでに未使用変数の警告も除去しています。
glass: r44478 2014-01-02 00:19:23 +0900
rb_hash_keys() という C API を static 関数に変更しています。rb_hash_keys() はもともと static 関数だったのを r43194 で Array#| などの実装で利用するために internal.h でインタプリタ内部では利用可能にしていたのですが、r43969 で array.c から利用しなくなったため static 関数に戻しています。 [ruby-core:59449] [Feature #9336]
svn: r44479 2014-01-02 00:19:28 +0900
version.h の日付更新。
glass: r44480 2014-01-02 00:55:51 +0900
Array#zip の実装で一時的に利用するバッファを ALLOCA_N() を使って確保していたのを ALLOCV_N() を使ってスタックが巻き戻った時には GC で回収されるようにしています。 ALLOCA_N() は alloca(3) でマシンスタック上にバッファを確保するので大きなサイズが必要な時にスタックオーバフローしやすくなっていました。
glass: r44481 2014-01-02 01:40:11 +0900
vm_eval.c の method_missing() でも ALLOCV_N() を使うようにしています。が、ここはサイズによって ALLOCA_N() か rb_ary_tmp_new() による確保(ALLOCV_N() とほぼ同様の方法)で分岐していて、頻繁に使われる可能性があるので多分小さいバッファの時はオブジェクトを確保しなくていいように軽い ALLOCA_N() を使うようにしていたんじゃないかという気がします。 method_missing を多用しているケースのベンチマークへの影響はどうでしょうか。
[追記]コメントを頂いたように ALLOCV_N() は alloca() が利用できる環境では確保するサイズをみて自動的に allca() と rb_alloc_tmp_buffer() を切り替えているので同様に(64bit 環境ではしきい値に違いがあるかもしれませんが)通常は alloca() を使うようになっていました。[/追記]
nobu: r44482 2014-01-02 03:43:13 +0900
拡張ライブラリ dbm の DBM#fetch でブロックつきの呼び出しの時にブロックパラメータに渡すキーの値を新規に作っていたのを dup + taint で作ってバッファが共有されるようにしています。ついでに未初期化変数の警告も除去。
nobu: r44483 2014-01-02 04:15:29 +0900
eval.c での rb_longjmp() の宣言の第3引数の volatile 修飾子を削除しています。実際の宣言と食い違っていたようです。 r44473 の変更で入ったもので Visual Studio でビルドエラーになっていたとのこと。 [ruby-core:59451] [Bug #9338]
nobu: r44484 2014-01-02 11:41:06 +0900
tool/mkrunnable.rb というビルドディレクトリのバイナリをそのまま実行可能にする準備をするためのスクリプトで Windows 環境では DLL が実行形式ファイルと同じディレクトリにないといけないそうなのでリンクをはるようにしています。
glass: r44485 2014-01-02 16:29:13 +0900
r44471 の追加修正。 IO の write 系メソッドでエンコーディング変換されない時だけ新規に freeze された文字列を作るようにしていましたが、変換された時も freeze はしておくようにしています。
