→ bcew: 這是假設malloc得到的起點會亂飄,要用&(~(0xF))修成16 byte 11/05 15:00
→ bcew: aligned,在修的過程最多只會減15而已0x123F & (~(0xF)) = 11/05 15:00
→ bcew: 0x1230 11/05 15:00
→ suscym: 那請問為何size部分 1024要+15呢 11/05 15:19
推 maik060: 若mem指到0x1231, 而ptr要對齊的位置是0x1240, 多用了15 11/05 15:49
→ maik060: 所以一開始size就多要了15byes, 不然會爆掉 ? 11/05 15:50
推 KaryuuIssen: 因為你+16可能會浪費16bytes 如同上面兩位舉的例子: 11/05 16:13
→ KaryuuIssen: (0x1230+16)&(~ 0xF)=0x1240 但0x1230本身就已符合 11/05 16:14
推 ucrxzero: Upbound公式是(byte+align-1)/align 11/05 18:15
→ ucrxzero: Lowerbound公式是byte/align 11/05 18:17
→ ucrxzero: &~0x0F就是強制對齊16 11/05 18:19
→ ucrxzero: +16回錯啦 11/05 18:19
→ ucrxzero: 會 11/05 18:19
→ ucrxzero: 你少考慮了原本就是16進位的狀況 11/05 18:20
→ ucrxzero: *16對齊 11/05 18:20
推 ucrxzero: 簡單來說就是取upbound 的概念 這題就沒問題了 11/05 18:27
→ ucrxzero: lowerbound可能會導致ptr小於mem 11/05 18:28
→ ucrxzero: 所以一定是取upperbound 11/05 18:28
→ ucrxzero: 是說先別管我最前面兩推的公式,只是感覺那很重要你以 11/05 18:29
→ ucrxzero: 後一定會遇到 11/05 18:29
→ bcew: 如前面m大說的,要確保修正後的ptr,指向的1024B都是自己mal 11/05 18:39
→ bcew: loc的,就是先多要15,ptr+15後再用&修正(扣掉不align部分) 11/05 18:39
推 ucrxzero: 而且答案其實沒有考慮到最尾巴(多出來尾部使用) 的pa 11/05 18:39
→ ucrxzero: dding部分 11/05 18:39
→ ucrxzero: 只是我最前面upperbound用除法這題用NAND而已 11/05 18:40
→ ucrxzero: 更正 clear flag 11/05 18:41
→ ucrxzero: 其實答案沒處理結尾padding的處理讓人有點解一半的感覺 11/05 18:43
→ ucrxzero: 是說我最前面兩推的公式是整數除法喔(無條件捨去 11/05 18:45
推 ucrxzero: 阿靠腰我前面的兩個公式忘記還要乘以align 11/05 18:47
→ ucrxzero: 不過概念對就好 11/05 18:47
推 ucrxzero: 重點就是取16的upbound 其他都不用管 11/05 18:51
推 wulouise: 可以順便貼原始link嗎? 11/05 19:55
https://stackoverflow.com/questions/381244/purpose-of-memory-alignment
→ bcew: 有點好奇u大的沒處理padding是什麼,function用ptr,free用m 11/05 21:34
→ bcew: em,應該是沒overflow也沒leak。 11/05 21:34
推 ucrxzero: 不是upperbound是rounddown才對= = C++STL用太多了SORRY 11/05 22:10
→ ucrxzero: *roundup 11/05 22:10
→ ucrxzero: to bcew : 這樣會浪費一點點最後的空間 11/05 22:11
→ ucrxzero: 是round-up round-down才對 == 11/05 22:11
推 ucrxzero: 破英文 11/05 22:14
推 ucrxzero: to bcew: 不會怎麼樣 但是 那個多出來的空間不會被mark 11/05 22:25
→ ucrxzero: 不會被使用 11/05 22:25
→ ucrxzero: 是不是有寫法讓padding也是16對齊??這個才對吧我想 11/05 22:26
→ ucrxzero: 要不然樓主找的答案會浪費很多空間,那為啥我不要直接分 11/05 22:26
→ ucrxzero: 配 2048就好 爽到爆~ 11/05 22:26
→ ucrxzero: 同意? 11/05 22:26
→ ucrxzero: 網路差 打字一職片段 11/05 22:27
推 ucrxzero: 是說我錯了 因為分配完才知道mem的起始位置~ 11/05 22:59
→ ucrxzero: 以上都當我放屁 11/05 22:59
推 Bencrie: 不是有 posix_memalign 可以用? 11/05 23:00
推 taffy128s: 一串未16-byte aligned 的空間 有可能 11/05 23:04
→ taffy128s: 頭多1尾多15 11/05 23:04
→ taffy128s: 頭多2尾多14 11/05 23:04
→ taffy128s: ... 11/05 23:04
→ taffy128s: 頭多15尾多1 11/05 23:04
→ taffy128s: 最壞情況是頭多15尾多1 對吧 11/05 23:04
→ taffy128s: 所以我無論如何 只要補15讓尾巴變16 11/05 23:04
→ taffy128s: 開頭位址再 & ~0x0F 就可以了 是吧 11/05 23:04
推 ucrxzero: 對對對你說的都對 11/05 23:06
→ ucrxzero: 就是 round-up而已= = 11/05 23:08
→ bcew: to u大:要滿足起點對齊16B,總量1024B,使用1039B滿足需求, 11/05 23:09
→ bcew: 不管什麼組合都是前後共15B沒用到,我覺得已經是最小浪費了 11/05 23:09
→ bcew: ,用更小的空間就有某條件不能滿足。 11/05 23:09
推 taffy128s: 恩恩 不用這摸激動 我只是提出另一個講法 看看能不能幫 11/05 23:11
→ taffy128s: 助原po 11/05 23:11
推 ucrxzero: 我本來是想說分配的時候就決定結尾突然想到這是OS的事情 11/05 23:12
→ ucrxzero: 很棒GOOD 11/05 23:12
→ bcew: 果然是有誤會^^ 11/05 23:14
推 wulouise: 原本SO問題的答案很詳細,有另外提到aligned_alloc 可用 11/05 23:18
推 Apache: 大師 11/06 00:04
感謝大家熱烈的解答~ 高手真多
不然這部分網路上幾乎都是外國的討論
※ 編輯: suscym (114.137.100.199 臺灣), 11/06/2020 08:52:44
→ suscym: 那實作上 似乎可以先判斷+15前本身是否已是16的倍數 是的 11/06 09:51
→ suscym: 話就可以不用做後面的事 省時間省memory(不用多配15) 這 11/06 09:52
→ suscym: 樣對嗎? 還是其實多了這判斷反而不會比較有效率 11/06 09:52
推 ucrxzero: 你跟我錯一樣的地方欸你要怎麼確認配的mem是16倍數 那 11/06 10:11
→ ucrxzero: 時候malloc都配完了 原子操作(malloc)就是不讓你這樣子 11/06 10:11
推 ucrxzero: 那你無限迴圈malloc free 到mem有16對齊好了 我記得lin 11/06 10:17
→ ucrxzero: ux是 best fit 只能慢慢等 11/06 10:17
推 CoNsTaR: realloc 的成本和 +15 的成本二選一而已啊 11/06 13:21
推 ucrxzero: 怕 11/06 13:36
推 wulouise: 我記得gnu是alloc一定會給alingned過的 11/07 08:47
推 ucrxzero: 我也覺得奇怪 11/07 11:04