EuRuKo 2019 で発表してきました

技術部でフルタイム Ruby コミッタをしている遠藤（@mametter）です。フルタイムで Ruby を開発しています。

先日、オランダのロッテルダムで開催された EuRuKo 2019 で発表してきたので、簡単にレポートします。

EuRuKo とは

EuRuKo は、毎年ヨーロッパのどこかで開催されている Ruby のカンファレンスです。

シングルセッション

世界の Ruby カンファレンスといえば、アメリカの RubyConf 、ヨーロッパの EuRuKo 、日本の RubyKaigi だと勝手に思っていますが、この中で EuRuKo の特徴というと、シングルセッションなことです*1。つまり、発表を聞く会議室は 1 つだけです。どれを聞くか迷わなくていいですね。

必然的に、発表の数は少ないです。YouTube の動画の数を見てみると、RubyConf 2018 は 70 件、RubyKaigi 2019 は 65 件ですが、今回の EuRuKo 2019 の発表は 15 件、LT を含めても 20 件でした。発表したい人からすると、採択されるのが最難です（たぶん採択率 1 桁）。

city pitch

また、次回の開催地が会期中に投票で決められるのも特徴です。立候補した街の人が city pitch（街の宣伝）を行い、会場の拍手喝采の大きさで決められていました。

オーストラリアのメルボルンが立候補してるのが話題でしたが、来年はヘルシンキになりました。

EuRuKo 2019 の様子

オランダのロッテルダムにある、ss Rotterdam っていう退役したクルーズ船が会場でした。現在は岸に固定されてホテルになってます。

EuRuKo 発表の傾向としては、Ruby コア開発の話よりは Ruby を使う話が中心です。そういう意味で、RubyKaigi よりは RubyConf に似ています。

その中でも印象に残った話を 3 つほど簡単に紹介します。

Functional (Future) Ruby - Yukihiro Matsumoto

matz のキーノート。動画がすでに上がっています。

ざっと内容を紹介します。まずは Ruby 3 の 3 つのゴールである Static analysis 、Performance 、Concurrency の進捗が説明されました。詳細はいろいろなところで見つかるので、主にキーワードだけ挙げておきます。

Static analysis は、公式型シグネチャフォーマットとなる予定の ruby-signature、型シグネチャのない Ruby プログラムをゆるく型検証し型シグネチャを推定する type profiler、型シグネチャを前提として、型シグネチャとコードの対応を検証する Sorbetや Steepなどが登場してきたことがダイジェストで紹介されました。 Performance は、オブジェクトを並べ替えてメモリのフラグメンテーションを軽減する Object compactionによってメモリボトルネックなアプリの効率を上げ、また JIT コンパイラである MJIT や MIR によって CPU ボトルネックなアプリの実行効率を上げることが述べられました。 Concurrency については、並列実行向けには Guilds（仮称）が計画されており、大規模並行処理向けには AutoFiber（仮称）が検討されていることが触れられました。

それから、関数型プログラミングっぽい他言語からインスパイアされた検討中の機能が紹介されました。

• ブロックの無名引数

@1で引数を暗黙的に参照できます。

3.times { p @1 }
# 3.times {|i,| p i } と同じ

@2だと 2 番目の引数、@3だと 3 番目の引数を参照できます。しかし現実的には複数の引数を参照仕分けるユースケースは稀なので、引数 1 つに特化し、別の記号（@、Kotlin や Grooby 風の it、Scheme の <>）などにするか検討中とのこと。他人事のように言ってますが、itを提案しているのは遠藤です（Feature #15897）。

• パターンマッチング。

データ構造が想定パターンになっているか調べて、その要素を変数に束縛することができます。

case JSON.parse(json, symbolize_names: true)
in {name: "Alice", children: [name: "Bob", age: age]}
  p age
in _
  p "no Alice"
end

典型的には、JSON の処理に便利そうです。

• パイプライン演算子

パイプライン演算子が試験的に Ruby に取り込まれました。

1..100
  |> map {|x| rand(x)}
  |> sort
  |> reverse
  |> take 5
  |> display

「パイプライン演算子はプライマリの引数を呼び出しにわたすもの」「Ruby ではプライマリの引数はレシーバ」ということで、実質的にメソッド呼び出し演算子（.）と同じものになっています（このへんの詳細は遠藤のブログを参照ください）。しかし非常に controversial であり、名称・記号を変更するか、キャンセルするか（まだリリース前なので互換性の問題なく取り消せる）、現在も悩んでいるとのことです。

というように、様々な意見はありつつも Ruby はまだまだ新しい機能を取り入れて進化していってます。

What causes Ruby memory bloat? - Hongli Lai

Ruby プロセスのメモリ肥大化の原因を調査した報告です。発表者の Hongli Lai は Passenger や Ruby Enterprise Edition の作者です。この発表はだいたい次のブログで発表済みだった内容ですが、今回の EuRuKo で一番テクニカルで、個人的には一番おもしろい発表でした。

www.joyfulbikeshedding.com

Ruby のメモリ肥大化と言えば、「Ruby: mallocでマルチスレッドプログラムのメモリが倍増する理由（翻訳）」という記事が有名です。端的に言えば「jemalloc を使え、もしくは環境変数 MALLOC_ARENA_MAX=2 を設定しろ」というやつで、見たことがある人も多いのではないでしょうか。しかし Hongli Lai はこの記事を疑い、再調査したところ、メモリ肥大化の本当の原因は別にあったということです。

かいつまんで説明します。Ruby がメモリを使うのは 2 種類あります。

• (1) Ruby オブジェクトのヒープ
• (2) Ruby オブジェクト以外のヒープ（主に文字列や配列など）

(1) については、あるアプリケーションでオブジェクトのヒープサイズを測定したところ、全使用メモリ 230 MB に対して 7 MB だったので、肥大化の原因としては無視できます。

(2) についてはちょっとややこしいのですが、malloc したメモリが一部だけ生き残って断片化が起きるという前提で、glibc の malloc はスレッドごとにメモリアリーナを確保するので問題がひどくなるというのが元記事の主張で、そのために MALLOC_ARENA_MAX=2を設定すればアリーナの数が高々 2 に抑えられるので問題が軽減するとされています。

しかし Hongli Lai は「malloc 領域の中で断片化は本当に起きているのか？」と疑問を持ち、可視化機能付き malloc ラッパを書いて確かめたそうです（すごい）。その結果がこれ。

赤い領域は使用中、灰色は free 済み（すでに使用されていない）だが OS に返却されていない領域、白は返却済みの領域です。赤い領域が飛び飛びにあるので断片化は多少起きているものの、完全に灰色のところも多いことがわかります。つまり、断片化はそれほどひどくなく、むしろ OS に領域を返却できていないことが問題です。 使用済みだが OS に返却されていないのは、こまめに返却すると実行効率が下がることがあるためだと思われます。malloc_trimという関数を使えば使用済み領域を明示的に OS に返却できる *2ということで、Ruby にパッチをあてて再実験した結果がこちら。

めでたく、白い部分が増えました。これにより、使用メモリ 230 MB だったところが 60 MB 減ったということです。MALLOC_ARENA_MAX=2を指定したら 53 MB なので、効果としてはほぼ同じとのこと。

また、Fullstaq Rubyという Ruby のディストリビューションを始めたということが発表されていました。今回の調査結果を含むということです。

The Past, Present, and Future of Rails at GitHub - Eileen M. Uchitelle

GitHub で働く Rails コミッターである Eileen の発表。Rails わかんないのでさらっと紹介です。

なんと、GitHub では、Rails をフォークして使っていたそうです。

しかし、先端の Rails にどんどん置いてかれて開発もメンテナンスも辛くなり、採用やセキュリティ対応も厳しくなってきたので、がんばってフォークを卒業した、ということでした。

ということで、「フォークをしても良いことないよ」「ちゃんと Rails の最新版を使っていこうね」ということが何度も語られていました。

がんばってフォークを卒業するまでに相当がんばったのではないかと思われるのですが、あんまりその辺の苦労は語られていなかったのが若干心残りです。しかし、Eileen は Rails 6 に GitHub で必要な機能（Multi-DB とか）を入れまくった人なので、その背景が想像される感じで面白かったです。独自フォークを無くすためには、フォークを公式にすればいいわけです。*3

A Plan towards Ruby 3 Types - Yusuke Endoh

ついでに自分の発表です。発表資料はこちら。

発表内容は大筋で Ruby 3 の静的解析の計画と、その中で自分が作っている型プロファイラの進捗報告でした。おおよそは RubyKaigi と同じなので、クックパッド開発者ブログで書いた遠藤の過去記事をご覧ください。

進捗としては、解析速度に難があった（型プロファイラ自身のプロファイルに 10 分、optcarrotに 3 分）だったので、解析アプローチを大幅に見直して、精度を少し犠牲にしつつ高速化をしたところ、それぞれ 2.5 秒・6 秒になった、というところです。とはいえまだまだ未実装な機能だらけなので、引き続きがんばってます。

おまけ：発表者の特典

前述のとおり EuRuKo は採択率が非常に低いのですが、そのためか発表者のおもてなしがなんかすごかったです。

• 旅費・宿泊費支給（いろいろあって遠藤は旅費をクックパッドに、宿泊費を EuRuKo に出してもらいました）
• 空港からの送迎
• 水上タクシーでの周辺観光
• 現地の Rails Girls イベントへの招待
• スピーカディナーへの招待（発表者と運営だけが参加できるディナー）

#EuRuKo2019 Speaker Dinner at Hotel New York 🍽🍹 pic.twitter.com/qV2Q4msjiE

— EuRuKo (@euruko) 2019年6月20日

• スピーカラウンジ（発表準備したり、議論したり、ゲームで遊んだりできるスペース）
• 記念品（会場だった ss Rotterdam の模型）

まとめ

EuRuKo 2019 のダイジェスト紹介でした。

ちなみに今回の日本人参加者は matz と自分の 2 名だけでした（たぶん）。海外の Ruby カンファレンスと言うとアメリカの RubyConf が注目されがちですが、EuRuKo も行ってみるといいのではないでしょうか。来年はフィンランドのヘルシンキです。