【ITニュース解説】libui and Garbage Collection - Challenges in Creating Ruby and Crystal Bindings

システムエンジニアを目指す皆さんへ、今回は、GUIライブラリ「libui」と、プログラミング言語の「ガベージコレクション（GC）」という仕組みを組み合わせる際に生じる、メモリ管理の難しさについて解説する。

まず「libui」とは何かから説明しよう。これは、Windows、macOS、Linuxという主要な三つのオペレーティングシステム（OS）で動作するアプリケーションの見た目（ボタンやウィンドウなど）を作るためのライブラリだ。内部的には、それぞれのOSが持つ「ネイティブAPI」と呼ばれる、OS固有の機能を呼び出す仕組みを持っており、これらを「ui.h」という一つの統一されたインターフェースで使えるようにしている。このため、どのOSでも同じような見た目のアプリケーションを開発できるのが特徴だ。また、「FFI（Foreign Function Interface）」という技術を使うことで、C言語以外のRubyやCrystalといった様々なプログラミング言語からも簡単に利用できる。最近は開発の勢いが少し落ちているものの、このような特徴を持つライブラリは少なく、独自の価値を持ち続けている。

さて、このlibuiをRubyやCrystalといった言語から使うための「バインディング」と呼ばれる仕組みを開発する際、予期せぬ大きな課題に直面したという。それは、libuiのメモリ管理の考え方と、RubyやCrystalが採用している「ガベージコレクション（GC）」というメモリ管理の仕組みが、うまくかみ合わないという問題だ。

ここで、ガベージコレクションについて簡単に触れておこう。RubyやCrystalのような多くの現代的なプログラミング言語では、プログラムが使用するメモリ（データを一時的に保存する場所）の管理を自動的に行ってくれる。具体的には、もう使われなくなったメモリ領域を自動的に判断し、それを解放して再利用できるようにする仕組みがGCだ。開発者は、どのメモリをいつ解放するかといった細かいことを気にせずにプログラミングに集中できるため、非常に便利な機能である。

しかし、libuiのようなC言語で書かれたライブラリとGC言語を組み合わせると、この便利なGCが思わぬ問題を引き起こすことがある。具体的には、アプリケーションを実行していると、画面上のボタンやテキスト入力欄といった「コントロール」が突然消えてしまったり、それらのコントロールが特定の操作（ボタンが押されるなど）に応じて実行する「コールバック関数」が機能しなくなったりする、という現象が発生するのだ。そして、これらは最終的に「メモリアクセス違反」というエラーにつながる。なぜこのようなことが起こるのかというと、GUIアプリケーションの裏側では、OSが常に画面の状態を監視し、ユーザーの操作を待ち続ける「GUIメインループ」という処理が動いている。このメインループは、画面に表示されているコントロールや、それに関連付けられたコールバック関数が「今後も使われ続ける」ことを前提としている。しかし、GCは、RubyやCrystalのプログラム内でこれらのコントロールやコールバックへの「参照」（メモリの場所を指し示す情報）がなくなると、「もう使われないメモリ」だと判断して勝手に解放してしまうのだ。その結果、GUIメインループが「ここにコントロールがあるはずだ」と期待している場所にメモリが存在せず、エラーが発生する。

GC言語では、メモリがいつ解放されるかは間接的にしか制御できないため、この問題への対応が必要となる。例えばRubyでは、コールバック関数を無条件に専用の配列に保存しておくことで、GCが解放しないようにしている。これは厳密には「メモリリーク」（使われなくなったメモリが解放されずに残り続けること）に当たるが、GUIアプリケーションで使われるコールバック関数の数は通常限られているため、実際には大きな問題にはならない。一方、Crystalではより複雑な方法が取られている。各コールバック関数を、それが関連するボタンなどのコントロールのインスタンスに紐付けて管理する。さらに、ウィンドウの中にボタンがあり、そのボタンの中にラベルがある、といったコントロール同士の「所有関係」をツリー構造として再現する。こうすることで、親が子を「所有している」と見なされ、親がまだ使われている限りは子もGCによって誤って解放されることを防ぎ、誤ったGCによる回収を大幅に減らすことができる。

次に、libui自身のメモリ管理ルールについて見ていこう。libuiはC言語のライブラリであるため、メモリの管理は基本的に「ユーザーが自分で解放する」ことを前提としている。しかし実際には、「親となるコントロールが解放されたら、その下にある子コントロールのメモリも自動的に解放される」という便利な仕組みを持っている。ここで親となれるのは、Window（ウィンドウ）、Box（ボックス）、Grid（グリッド）、Group（グループ）、Tab（タブ）、Form（フォーム）といった特定のコントロールだ。これらの親コントロールを破棄すると、まず子コントロールが解放され、次に親コントロール自身が解放される。このため、実際にはウィンドウを閉じる際に、そのウィンドウに含まれる全ての子コントロールがまとめて解放されることが多い。問題は、ウィンドウのタイトルバーにある「×」ボタンがクリックされた場合のように、ウィンドウが自動的に破棄されることがある点だ。このような自動的な解放がlibui内部で行われても、Crystal側からはその事実を直接知ることができない。メモリ解放直後にポインタがNULLになることを確認するなどの方法もあるが、確実ではない。一方、メニューバーの「終了」オプションからアプリケーションを終了する場合、これはウィンドウの破棄とは異なり、自動でウィンドウが破棄されるわけではない。この場合、開発者が明示的にウィンドウを破棄し、「uiQuit」という関数を呼び出してアプリケーションを終了させる必要がある。

libuiには、メモリリークを検出するための機能が組み込まれており、これは通常非常に役立つ。しかし、GC言語と組み合わせる際には、この機能も注意が必要だ。なぜなら、GC言語ではメモリがいつ解放されるかが不定であるため、リーク検出時に「すべてのメモリが解放されたか」を保証できないからだ。GCの「finalize」という、オブジェクトがGCによって解放される直前に呼ばれる処理にフックしてメモリ解放を行うような実装は、この理由から避けるべきだとされている。

また、特定のコントロールには特別な解放手順が必要となる場合がある。例えば「Table（テーブル）」コントロールは、「TableModel（テーブルモデル）」と「Table（テーブル）」という二つの部分に分かれている。TableModelは、そのモデルを使っている全てのTableが破棄された後でなければ解放できない。そのため、解放の手順としては、まずTableを親コントロールから外し、次にTableを明示的に破棄し、最後にTableModelを破棄するという複雑な手順が必要になる。一方、「Area（エリア）」コントロールは比較的シンプルで、コントロール自体を破棄するだけでよい。さらに、「MultilineEntry（複数行入力欄）」コントロールは、原因はまだ調査中とのことだが、macOS環境ではTableと同様に親から外し個別に破棄しないと問題が発生するケースがあるようだ。

このように、libui（あるいは後継プロジェクトのlibui-ng）を使う際には、特にメモリ解放に関して多くの重要な考慮事項があることがわかる。RubyやCrystalのようなガベージコレクションを使う言語では、普段はメモリ管理についてほとんど意識する必要がない。C言語のライブラリをGC言語から使う場合でも、多くの場合はGCのfinalizeのような仕組みを使えば、手動でのメモリ管理は不要になることが多い。しかし、今回の事例が示すように、GUIライブラリのように、ユーザーとの対話を通して「いつ」「どんな操作が」行われるかによって動作が変わるような、タイミングや同期が重要なインタラクティブな処理を伴うライブラリでは、GCに全面的に頼りきることはできない場合がある。このような状況では、開発者が適切なタイミングで手動でメモリを解放する仕組みが必要となる。RubyやCrystalには、「RAII（Resource Acquisition Is Initialization）」という考え方に基づいた、特定の処理ブロックを抜けるときに自動的にリソースを解放するAPIが用意されていることが多く、これを使えば多くのケースに対応できる。それでも対応が難しいケースもあるようだが、これは試行錯誤を重ねて解決していくべき課題だ。

今回の解説が、システムエンジニアを目指す皆さんの学びの一助になれば幸いだ。