Goには、待ち時間のないガベージコレクションはありません。これらの主張がどこにあるのかを指摘できれば、それらを修正しようと思います。
GoogleがGoよりも優れていると考える利点の1つは、メモリレイアウトをより詳細に制御できることです。例えば、シンプルな2Dグラフィックパッケージが定義できます:ゴーで
type Rect struct {
Min Point
Max Point
}
type Point struct {
X int
Y int
}
を、のRectは、メモリ内の連続したばかりの4つの整数です。 & r.Maxを渡して、* Pointを期待する関数にすることができます。これは、Rect変数rの真ん中へのポインタです。
Javaでは、同等の表現はRectクラスとPointクラスを作成することです。この場合、RectのMinフィールドとMaxフィールドは別々に割り当てられたオブジェクトへのポインタになります。これには、より多くの割り当てられたオブジェクトが必要であり、より多くのメモリを占有し、ガベージコレクタに追跡し、より多くのことを与える必要があります。一方、オブジェクトの中央にポインタを作成する必要はありません。
Javaは、プログラマがメモリレイアウトをより詳細に制御できるようにします。このコントロールを使用すると、ガベージコレクタの負荷を軽減できます。これは、大量のデータを持つプログラムでは非常に重要です。メモリレイアウトを制御することは、キャッシュ効果などの理由でハードウェアから性能を引き出すためにも重要であるが、それは元々の問題に接している。
現在のGo配布のコレクタは、妥当なものですが、最先端のものではありません。私たちは、今後1年か2年の間にそれを改善する努力をもっと費やす予定です。 Goのガベージコレクタは、現代のJavaガベージコレクタほど良くはありませんが、ガベージコレクションを必要としないプログラムをGoで作成する方が簡単だと考えています。ガベージコレクションは、同等のJavaプログラムよりもGoプログラムの問題のほうが少ないことを示しています。
Javaゲームでは、ガベージコレクタがゲームの適切なポイントに達するまで実行されません(たとえばポーズメニューなど)。これを達成するために、私はいつも、作成されたすべてのオブジェクトへの参照を保持し、ポーズメニューまたはレベルの終わりに達するとそれらをすべて解放するマネージャクラスのようなものを持っています。 –
比較のためにこれが好きかもしれません。 http://code.google.com/p/jgo/ Goが 'struct'をサポートしている場合、JITが暗黙的にこれを行うことを期待するのではなく、GCを明示的に回避する可能性があります。 –
@JonTaylorなぜこれをやったのですか? JVMのガベージコレクタのパフォーマンスやその他の理由がありますか? –