GHCガベージコレクタは "大きな"オブジェクトを特別に扱いますか?それとも他のオブジェクトとまったく同じ扱いですか?GHCガベージコレクタはラージオブジェクトに対して特別な最適化を持っていますか?
GCエンジンの中には大きなオブジェクトを別の領域に置くものがあります。スキャンする頻度が低く、収集アルゴリズムが異なります(たとえば、コピーする代わりに圧縮する、または断片化を試みるのではなくフリーリストを使用するなど)。 GHCはこのようなことをしますか?
GHCガベージコレクタは "大きな"オブジェクトを特別に扱いますか?それとも他のオブジェクトとまったく同じ扱いですか?GHCガベージコレクタはラージオブジェクトに対して特別な最適化を持っていますか?
GCエンジンの中には大きなオブジェクトを別の領域に置くものがあります。スキャンする頻度が低く、収集アルゴリズムが異なります(たとえば、コピーする代わりに圧縮する、または断片化を試みるのではなくフリーリストを使用するなど)。 GHCはこのようなことをしますか?
はい。 GHCヒープは、連続した1つのメモリ領域に保持されません。むしろ、それはorganized into blocksです。
割り当てられたオブジェクトのサイズが特定のしきい値(block_size * 8/10、block_sizeが約3.2k)の場合、オブジェクトを保持するブロックはlarge(BF_LARGE)としてマークされます。今では、ガベージコレクションが発生すると、このブロックから新しいブロックに大きなオブジェクトをコピーするのではなく、ブロック自体が新しい世代のブロックセットに追加されます。これは、リンクされたリスト(正確には大きなオブジェクトリスト)で手を加えることを含む。
大きなブロック内でデッドスペースを再利用するにはしばらく時間がかかることになるので、バグ7831に示すように、大きなオブジェクトにフラグメンテーションが発生する可能性があります。しかし、これは通常、個々の割り当てがメガブロックサイズ1Mの半分に達するまで発生しません。
例ではblock_sizeを5kにし、しきい値4kを設定しないでください。 – Sal
ああ、あなたは正しいので、私は乗算を反転した。 block_sizeは4kです。しきい値は〜3.2kです。私はそれを修正した。 –