Goは32bit開発に不適

Do Not Use Go for 32bit Development

私は今、大量のGoのコードをCに書き換える作業をしている。時間は金で買えない。主たる開発者として、金はここで止まってしまう。わたしは顧客と話し、責任を負った訳だ。私の過ちは、Goを信頼したことだ。私は自分のモットーを思い出すべきだったのだ。Nullius in verba（政治信教の言を入るべからず）

Goは1.0がリリースされたが、もし、32bitサポートが必須であれば、Goを選んではいけない。

32bit Goには多くのバグがあるが、特に問題なのがひとつある。

実行開始の初期化時に、Goは512MBの仮想アドレス空間を予約しようとする。予約できなければ、クラッシュする。Goは、ガベージコレクションのためにこの空間を必要とする、おそらく、すべてのGC言語、いや、すべての言語は、メモリ管理に対して、似たような手法を用いているだろうから、この問題は潜在的にひっかるであろう。32bitのWindowsにおいては、プロセスは2GBのユーザー空間のメモリーにしかアクセスできない。このユーザー空間は、フラグメントを引き起こす。例えば、512MBの確保のまえに、DLLを読み込んだりなどすれば、可能性がある。結果として、Goランタイムが空間を予約するのを妨げる。

Goは単一の巨大なブロックの確保をあてにしている。おそらく、他のGC言語では、より小さな単位のメモリーを使う仕組みを実装しているのだろう。

この問題は再現とテストが難しい。ほとんどの場合、Goは全く問題なく動くからだ。どうやら、リブートは問題の解決に役立つのではないかと思う。また、この問題に直面するのはWindowsだけではないかとも思う。Linuxではこのバグリポートは上がってこなかった。Goの開発者は、この問題をすでに把握しているが、優先順位は低い。

Goでのプログラミングは素晴らしいものだ。私はRob Pikeの「プログラマーは問題を解決する代わりに文句ばかり言う」という言も、もっともだと思う。残念ながら、私はGoランタイムコードに慣れていないため、ソースコードの中に飛び込んで、新たなバグを生み出さずに、メモリ管理の問題を修正できる自信はない。それに、納期に追われていて、時間もない。時間がとれたら、この問題の修正を試みるつもりだ。

追記：Goの開発者はとても親切で、問題の理解を助けてくれたことは追記しておく。ただし、彼らのいう解決方法は一貫して、「64bitに移行しろ」であった。

なるほど、16bitから32bitへの移行は、セグメント管理が面倒だから起こった。物理メモリ量もムーアの法則を裏切らないように増えていったが、やはり単一の32bitアドレス空間でないとプログラミングが面倒だったのだろう。32bitから64bitへの移行も、物理メモリの量ではなく、仮想アドレス空間の欠乏から起こるのかもしれない。