1.G2.9 std::alloc运行模式
(1) 每个链表都是20*2,20个切割好,其余的20个作为战备池
(2)分配的范围在8K~128K。
2.embedded pointers
(1)当客户段使用小区快,获得的既是char*(指向某个union obj)。此时虽然客户端没有诸如LString或ZString之类的信息可得知区块大小,但由于区块是给object所用,相当于object大小,object ctor自然不会过分。
(2)union obj {
union obj* free_list_link;
};
改用struct可
3.std_alloc运行一瞥
(1)初始时的16个链表
(2)申请32bytes
申请32bytes,由于pool为空,故所取并成功向pool灌注32*20*2 + RoundUp(0>>4)=1280,从中切出1个区块返回客户,19个区块给list#3,余640备用,
>累计申请量:1280
>pool大小:640
(3)申请64bytes(连线表示链表连在一起)
(4)申请96bytes
战备池pool为空,累计申请量为1280/16=80,调整为8的倍数
累计申请量:1280+96*20*2+80 = 5200
战备池pool大小:96*20*2+80-96*20 = 2000
(5)申请88bytes(连线表示链表连在一起)
挂在88/8-1在10个链表,战备池有剩余,切割88*20,剩余战备池pool大小:2000-88*20=240
(6)连续三次申请88bytes
(7)申请8bytes
战备池pool大小:240-8*20=80
(8)申请104bytes
战备池pool大小为80不足104bytes,80/8-1=9,将战备池pool挂到第9个链表
新申请104*20*2+[累计申请总量5200/16=325调整8的倍数328]
战备池pool大小104*20*2+328-104*2=2408
(9)申请112bytes
累计申请量:9688
pool大小:2408-112*20=168
(10)申请48bytes
累计申请量:9688
战备池pool大小:168-48*3=24
(11)现在假设内存10000bytes,继续申请72bytes
挂在9处的为80bytes,然后剪断,挂在第8个链表,战备池剩余80-72=8
(12)继续申请72bytes
战备池pool大小不足72bytes,然后将战备池8bytes挂在第0个链表;
向右边继续查找,在第10个链表,截取72bytes,战备池剩余88-72=16
(13) 申请120bytes
战备池pool大小16不足120,然后将16bytes/8-1=1挂在第1个链表
向右查找>120,没有申请失败
(14)检讨