似乎有一種觀點認為在 64 位體系結構上不需要使用“拆分堆棧”運行時模型。我說似乎是，因為我還沒有看到有人真的這么說，只能繞著它跳舞：典型的多線程程序的內存使用量可以顯著減少，因為每個線程不需要最壞情況下的堆棧大小。在 32 位地址空間中運行數百萬個線程（完整的 NPTL 線程或協同例程）成為可能。——伊恩·蘭斯·泰勒...暗示 64 位地址空間已經可以處理它。和......拆分堆棧的持續開銷和狹窄的用例（在 32 位體系結構上產生大量 I/O 綁定任務）是不可接受的...--bstrie兩個問題：這是他們所說的嗎？其次，如果是這樣，為什么它們在 64 位架構上是不必要的？
3 回答
HUH函數
TA貢獻1836條經驗 獲得超4個贊
是的，他們就是這么說的。
在 64 位架構上（目前）不需要拆分堆棧，因為 64 位虛擬地址空間非常大，可以包含數百萬個堆棧地址范圍，如果需要，每個地址范圍都相當于整個 32 位地址空間。
在當今使用的平面內存模型中，從虛擬地址到物理內存位置的轉換是在硬件 MMU的支持下完成的。在amd64 上，事實證明將 64 位虛擬地址空間的大塊保留給您正在創建的每個新堆棧會更好（意味著總體上更快），而只將第一頁 (4kB) 映射到實際 RAM。這樣，堆棧將能夠根據需要在連續的虛擬地址上增長和縮小（意味著每個函數序言中的代碼更少，一個很大的優化），而操作系統重新配置 MMU 以將虛擬地址的每個頁面映射到實際RAM 的空閑頁面，每當堆棧增長或縮小到高于/低于某些可配置閾值時。
通過巧妙地選擇閾值（例如參見動態數組理論），您可以在平均堆棧操作上實現 O(1) 復雜度，同時保留數百萬堆棧的好處，這些堆?？梢愿鶕枰鲩L并且只消耗內存他們使用。
PS：當前的 Go 實現遠遠落后于此:-)
慕桂英546537
TA貢獻1848條經驗 獲得超10個贊
更新 Go 1.4（2014 年第四季度）
更改為運行時：
在 Go 1.4 之前，運行時（垃圾收集器、并發支持、接口管理、映射、切片、字符串等）主要是用 C 編寫的，有一些匯編器支持。
在 1.4 中，大部分代碼已轉換為 Go，以便垃圾收集器可以在運行時掃描程序堆棧并獲取有關哪些變量處于活動狀態的準確信息。
這種重寫使 1.4 中的垃圾收集器完全精確，這意味著它知道程序中所有活動指針的位置。這意味著堆會更小，因為不會有誤報使非指針保持活動狀態。其他相關更改也減少了堆大小，與之前的版本相比，總體上減少了 10%-30%。
結果是堆棧不再分段，消除了“熱拆分”問題。當達到堆棧限制時，會分配一個新的更大的堆棧，goroutine 的所有活動幀都被復制到那里，并且所有指向堆棧的指針都會被更新。
初步答復（2014 年 3 月）
Agis Anastasopoulo的文章“ Go中的連續堆?！币步鉀Q了這個問題
在堆棧邊界碰巧陷入緊密循環的情況下，重復創建和銷毀段的開銷變得很大。
這在 Go 社區內部被稱為“熱分裂”問題。
“熱拆分”將在 Go 1.3 中通過實現連續堆棧來解決。
現在，當堆棧需要增長時，會發生以下情況，而不是分配新段：
創建一個新的、更大的堆棧
將舊堆棧的內容復制到新堆棧
重新調整每個復制的指針以指向新地址
銷毀舊堆棧
下面提到一個主要出現在 32 位架構中的問題：
不過也有一定的挑戰。
1.2 運行時不知道堆棧中指針大小的字是否為實際指針?？赡苡懈↑c數和最罕見的整數，如果解釋為指針，實際上會指向數據。
由于缺乏此類知識，垃圾收集器必須保守地將堆棧幀中的所有位置視為根。這留下了內存泄漏的可能性，尤其是在 32 位體系結構上，因為它們的地址池要小得多。
然而，在復制堆棧時，必須避免這種情況，并且在重新調整時只應考慮真正的指針。
工作已經完成，關于實時堆棧指針的信息現在嵌入在二進制文件中，可供運行時使用。
這意味著不僅 1.3 中的收集器可以精確地堆疊數據，而且現在可以重新調整堆棧指針。
- 3 回答
- 0 關注
- 267 瀏覽
添加回答
舉報
0/150
提交
取消