64位土地中的堆碎片

Question

過去，當我在長時間運行C++守護進程時，我不得不處理堆碎片問題。像保留大量分配池這樣的技巧是爲了防止連續堆空間耗盡所必需的。

這仍然是一個64位地址空間的問題？ Perf對我來說不是一個問題，所以我寧願簡化我的代碼，不再處理緩衝池等事情。有沒有人有任何關於這個問題的經驗或故事？我正在使用Linux，但我想象許多相同的問題適用於Windows。

Answer 1

如果您的進程真正需要千兆字節的虛擬地址空間，那麼升級到64位確實會立即消除對解決方法的需求。

但值得研究你期望你的過程使用多少內存。如果它只有一個GB或更少的區域，那麼即使瘋狂的碎片也不會讓你用完32位地址空間 - 內存泄漏可能是問題所在。 （順便說一下，Windows更具有限制性，因爲它在操作系統的每個進程中都保留了不重要的地址空間量）。

Answer 2

堆碎片在32位以下的64位下是一樣的問題。如果您以不同的生命週期提出大量請求，那麼您將得到一個零碎的堆。不幸的是，64位操作系統並沒有真正幫助解決這個問題，因爲它們仍然無法真正地將小部分空閒內存移動到更大的連續塊。

如果你想處理堆碎片，你仍然必須使用相同的舊技巧。

64位操作系統在這裏可以提供幫助的唯一方法是，如果存在足夠大的內存量以至於您永遠不會分割它。

Answer 3

這仍然是64位地址空間的問題嗎？

不，這不是問題。

這是32位系統上的問題，但這不再是64位系統上的問題。

64位系統上的虛擬地址空間非常大（當前x86_64處理器上的時間爲2^48個字節，並且隨着新的x86_64處理器出現，設置逐漸增加到2^64）由於碎片導致的連續的虛擬地址空間實際上是不可能的（對於除了一些高度臆造的角落情況以外的所有其他地方）。 （這是由於64是「唯一」雙32而引起的直覺的常見錯誤，這導致人們認爲64位地址空間大約是32位地址空間的兩倍。事實上，完整的64位地址空間是32位地址空間的40億倍）。

換句話說，如果它把你的32位守護進程一週分段到一個階段，它不能分配一個x字節塊，比將要花至少一千年來分割今天的x86_64處理器48位地址空間，並且需要八千萬年來分割未來計劃的完整64-b它的地址空間。