baiyan

全部视频:https://segmentfault.com/a/11...

源视频地址:http://replay.xesv5.com/ll/24...

malloc和free函数思考

  • 字符串的非二进制安全:如果存的字符串内容中带有\0,那么它会被当做字符串结束标志,提前判定字符串结束,而并非到字符串末尾正常结束。
  • malloc一块内存之后,它的size是存在哪里的?
  • free一块内存,如何知道free多大的内存?
  • 解决方案:在分配的内存地址空间附近额外分配一块内存记录size。

  • malloc()系统调用是非常慢的,相当于你去面包店买一个面包,需要和面、发酵...等等一系列繁琐的工作,为了避免多次从用户态切换到内核态进行内存分配,PHP会先向操作系统内核申请一块大的内存空间,然后由用户态的PHP虚拟机所实现自己的一套内存管理机制,来管理这一大块内存。以后再申请内存,只需要PHP虚拟机来实现具体的内存分配操作即可,不用再向内核申请。这样就减少了向操作系统申请内存的次数,以空间换时间,避免频繁的进行系统调用,提高了性能。

操作系统内存基本概念

  • chunk:2MB大小内存
  • page:4KB大小内存
  • 二者关系:一个chunk由512个page组成(2MB/4KB = 512)(512 = 2^9,4KB = 2^12,2MB = 2^21)。
  • mmap():系统调用,将一个文件或者其它对象映射进内存,分配chunk。
  • 内存不够用怎么办:选择一个占用内存大的进程并挂起,并将其使用的内存置换到硬盘上,分配给新进程使用。当挂起进程被唤醒的时候,唤醒进程会到内存中找对应的页,但是无法找到,故产生缺页中断,操作系统会将硬盘中的页置换回内存,供唤醒进程继续运行。

PHP内存分配

PHP内存分类:small/large/huge

  • small:size <= 3KB(有30种规格)
  • large:3KB < size <= 2MB - 4KB
  • huge:size >= 2MB - 4KB
  • 思考:为什么large规格内存是 <= 2MB - 4KB?

答:在small和large内存分配规格中,首先会分配一个chunk,chunk的第一个page中存有一个结构体,用来保存chunk中每一个page的相关存储信息(即zend_alloc.h中的mm_heap结构体)。但是huge规格不需要,直接拿来用即可(因为huge内存已经大于2MB(即一个chunk)),无需记录内部存储细节信息)。思考一个问题:一个page有4KB,至于用这么大的空间去存吗?

struct _zend_mm_heap {
#if ZEND_MM_CUSTOM
    int                use_custom_heap;
#endif
#if ZEND_MM_STORAGE
    zend_mm_storage   *storage;
#endif
#if ZEND_MM_STAT
    size_t             size;                  /* 当前使用内存(PHP库函数memory_get_usage()方法就是取此字段的值)*/
    size_t             peak;                /*  内存使用峰值 */
#endif
    zend_mm_free_slot *free_slot[ZEND_MM_BINS];  /*它是一个大小为ZEND_MM_BINS = 30的数组,每个存储单元是一个单向链表,用来挂载30种不同规格的small内存(下面会讲)*/
#if ZEND_MM_STAT || ZEND_MM_LIMIT
    size_t             real_size;               /* current size of allocated pages */
#endif
#if ZEND_MM_STAT
    size_t             real_peak;               /* peak size of allocated pages */
#endif
#if ZEND_MM_LIMIT
    size_t             limit;                   /* memory limit */
    int                overflow;                /* memory overflow flag */
#endif

    zend_mm_huge_list *huge_list;               /* list of huge allocated blocks */

    zend_mm_chunk     *main_chunk;
    zend_mm_chunk     *cached_chunks;            /* list of unused chunks */
    int                chunks_count;            /* number of alocated chunks */
    int                peak_chunks_count;        /* peak number of allocated chunks for current request */
    int                cached_chunks_count;        /* number of cached chunks */
    double             avg_chunks_count;        /* average number of chunks allocated per request */
    int                last_chunks_delete_boundary; /* numer of chunks after last deletion */
    int                last_chunks_delete_count;    /* number of deletion over the last boundary */
#if ZEND_MM_CUSTOM
    union {
        struct {
            void      *(*_malloc)(size_t);
            void       (*_free)(void*);
            void      *(*_realloc)(void*, size_t);
        } std;
        struct {
            void      *(*_malloc)(size_t ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC);
            void       (*_free)(void*  ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC);
            void      *(*_realloc)(void*, size_t  ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC);
        } debug;
    } custom_heap;
#endif
};
  • 重点关注中文注释的部分,我们看到zend_mm_heap结构体并不是很大,那么继续关注其中重点的zend_mm_chunk结构体:
struct _zend_mm_chunk {
    zend_mm_heap      *heap;
    zend_mm_chunk     *next;
    zend_mm_chunk     *prev;
    uint32_t           free_pages;                /* number of free pages */
    uint32_t           free_tail;               /* number of free pages at the end of chunk */
    uint32_t           num;
    char               reserve[64 - (sizeof(void*) * 3 + sizeof(uint32_t) * 3)];
    zend_mm_heap       heap_slot;               /* used only in main chunk */
    zend_mm_page_map   free_map;                 /* 512 bits or 64 bytes */
    zend_mm_page_info  map[ZEND_MM_PAGES];      /* 2 KB = 512 * 4 */
};
  • 1个chunk有512个page。
  • 第一个heap字段是zend_mm_heap类型的结构体指针,方便在512个page中直接找到第一个存储额外信息的page。下面两个next和prev字段构成一个双向链表,用于chunk与chunk之间的连接。
  • 重点关注倒数第二个字段zend_mm_page_map类型的字段,有512bit(即64B),每一个bit用来存储当前这个chunk中的每一个页(因为一共有512个页)是否使用。
  • 除了看它是否使用,还要看每个page的具体使用的大小和其他相关情况并记录相关信息。
  • 最后一个zend_mm_page_info类型的字段解决了上述问题。ZEND_MM_PAGES = (ZEND_MM_CHUNK_SIZE / ZEND_MM_PAGE_SIZE) = 2MB/4KB = 512个存储单元,每个存储单元是typedef uint32_t zend_mm_page_info类型,即4B大小用来存储额外的使用情况信息,这个字段一共是2KB。用来存储使用的大小和额外信息,所以这里2KB加上剩余字段,差不多会使用4KB的空间,所以chunk的第一个page需要留出来记录这些信息。
  • 那么这个page_info(uint32_t),这里32位是如何利用的呢,先看如何标记内存规格
#define ZEND_MM_IS_FRUN                  0x00000000
#define ZEND_MM_IS_LRUN                  0x40000000
#define ZEND_MM_IS_SRUN                  0x80000000
  • 第32位为1代表small内存,即0x8。然后低5位(2^5 > 30种规格)存储bit_num(即ZEND_MM_BINS_INFO宏的索引,以便快速找到所需页的数量等信息(下面会讲))
  • 第31位为1代表large内存,即0x4。然后低10位表示分配的页数(>= 512即可)为什么不用9位呢?2^9 = 512足够了???
  • 第31、32位都是1,即0xC,低5位表示bit_num,这里3KB规格就是29,16~25bit表示偏移量。以申请3KB为例,一定是3个4KB的page,分为4个3KB(见下文)。第一个3KB就是0xC作为连续分配4个3KB的起始标记(约定),偏移量是0,bit_num是29;第二个3KB就是0x8,偏移量是1,bit_num同样是29;第3、4个3KB内存同理,只是偏移量不同。
  • _emalloc() -> zend_mm_alloc_heap() ->分配三种内存规格的其中一种:
static zend_always_inline void *zend_mm_alloc_heap(zend_mm_heap *heap, size_t size ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC)
{
    void *ptr;
    if (size <= ZEND_MM_MAX_SMALL_SIZE) {
        ptr = zend_mm_alloc_small(heap, size, ZEND_MM_SMALL_SIZE_TO_BIN(size) ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
        return ptr;
    } else if (size <= ZEND_MM_MAX_LARGE_SIZE) {
        ptr = zend_mm_alloc_large(heap, size ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
        return ptr;
    } else {
        return zend_mm_alloc_huge(heap, size ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
    }
}

small内存

  • 注意一个page可以包含多个small内存块,首先满足一次性分配的page总量必须能够除尽分配的规格大小。换句话说,尽量不要有内存碎片。例如:分配3KB的small内存,不能只分配1个page,因为会剩下1KB大小的内存碎片,不能够再次利用并分配。所以需要求得一个规格和4KB的最小公倍数,作为总的分配空间。但是如果最小公倍数过大,导致所需要的page太多,那么退而求其次,即使留有很少的内存碎片,也算是可以满足需求的。下面举几个例子:
  • 例1:假如分配8B规格的small内存:我们先找最小的可以除尽8B的page大小。因为4KB可以除尽8B,所以我们取1个page就够了,故一共正好可以分成512个8B的内存。我们取1个8B内存返回给用户,然后剩余511个8B内存会挂在zend_mm_heap结构体的zend_mm_free_slot *free_slot[ZEND_MM_BINS]字段中。这里ZEND_MM_BINS宏 = 30,恰好这30个数组单元对应30种small内存规格,共有30个单向链表,每一个单向链表都是挂载的多分配的内存。如上例中的8B内存,就会挂载剩下多分配的511个8B内存。当下次再次有分配请求的时候,直接从链表上拿即可,不用再去重新分配。同时也避免了内存碎片的产生。当释放内存的时候,直接利用头插法(相比尾插法复杂度O(1))插入到链表头部即可。
  • small内存最小的分配规格就是8B,因为指针在64位系统下是8B,能够满足free_slot字段单向链表的需求。

  • 例2:假如分配3KB规格的small内存:我们同样先找可以整除3KB的page大小。因为4KB不可以除尽3KB,所以1个page虽然可以满足3KB的分配需求,但是还是会留有1KB的内存碎片,所以我们不能直接拿1个page来用。我们取最小的可以整除3KB的4KB倍数,求得该值为3(4KB * 3 / 3KB = 4)个3KB大小的内存块。那么同样我们取1个3KB内存返回给用户,剩余3个3KB内存挂在上面的zend_mm_heap结构体中free_slot字段的链表上,等待后续的分配请求。

  • 例3:假如分配40B规格的small内存,为什么下面代码也仅仅用了1个page,那是因为4KB和40B的最小公倍数过大,导致一次性申请的page太多,所以不能一味的找二者的最小公倍数,所以退而求其次,只分配1个page。虽然4096/40 = 102.5,代码中直接取了102作为最终分配的数量。第1个返回给用户,剩下101个挂在free_slot链表上等待后续的分配请求。

    • 下面是所有的small内存分配规格:
/* bin_num, size, count, pages */
/*数组下标,分配规格大小,共能分配多少个这样规格大小的内存块,需要的页的数量*/
#define  ZEND_MM_BINS_INFO(_, x, y) \
    _( 0,    8,  512, 1, x, y) \
    _( 1,   16,  256, 1, x, y) \
    _( 2,   24,  170, 1, x, y) \
    _( 3,   32,  128, 1, x, y) \
    _( 4,   40,  102, 1, x, y) \
    _( 5,   48,   85, 1, x, y) \
    _( 6,   56,   73, 1, x, y) \
    _( 7,   64,   64, 1, x, y) \
    _( 8,   80,   51, 1, x, y) \
    _( 9,   96,   42, 1, x, y) \
    _(10,  112,   36, 1, x, y) \
    _(11,  128,   32, 1, x, y) \
    _(12,  160,   25, 1, x, y) \
    _(13,  192,   21, 1, x, y) \
    _(14,  224,   18, 1, x, y) \
    _(15,  256,   16, 1, x, y) \
    _(16,  320,   64, 5, x, y) \
    _(17,  384,   32, 3, x, y) \
    _(18,  448,    9, 1, x, y) \
    _(19,  512,    8, 1, x, y) \
    _(20,  640,   32, 5, x, y) \
    _(21,  768,   16, 3, x, y) \
    _(22,  896,    9, 2, x, y) \
    _(23, 1024,    8, 2, x, y) \
    _(24, 1280,   16, 5, x, y) \
    _(25, 1536,    8, 3, x, y) \
    _(26, 1792,   16, 7, x, y) \
    _(27, 2048,    8, 4, x, y) \
    _(28, 2560,    8, 5, x, y) \
    _(29, 3072,    4, 3, x, y)
  • 思考:给一个size,如何确定它的bin_num(也就是索引),从而快速找到count和pages?
static zend_always_inline int zend_mm_small_size_to_bin(size_t size)
{
...
    unsigned int t1, t2;

    if (size <= 64) {
        /* we need to support size == 0 ... */
        return (size - !!size) >> 3;
    } else {
        t1 = size - 1;
        t2 = zend_mm_small_size_to_bit(t1) - 3;
        t1 = t1 >> t2;
        t2 = t2 - 3;
        t2 = t2 << 2;
        return (int)(t1 + t2);
    }
#endif
}
  • 当size <= 64的时候,size会递增8,那么直接>>3位(除以8)就可以得到索引的偏移量,很好理解。这里的!!size是为了兼容size = 0的情况,这样在右移3位之前就不会出现负值;减去!!size(即减1)是为了兼容size为8B规格等边界情况。
  • 当size > 64的时候,详情参考:small内存规格的计算 核心思想:可以将size看成等差数列,按照公差分组。首先找出当前size属于哪个组,在组内的偏移量是多少,最终把二者相加。
  • small内存分配流程:
static zend_always_inline void *zend_mm_alloc_small(zend_mm_heap *heap, size_t size, int bin_num ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC)
{
...
    if (EXPECTED(heap->free_slot[bin_num] != NULL)) {
        zend_mm_free_slot *p = heap->free_slot[bin_num];
        heap->free_slot[bin_num] = p->next_free_slot;
        return (void*)p;
    } else {
        return zend_mm_alloc_small_slow(heap, bin_num ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
    }
}
  • 如果free_slot上挂载的多余分配的内存不是空,那么直接从free_slot链表的第一个位置上拿就可以了,然后链指针向后移,等待下次内存分配。否则调用zend_mm_alloc_small_slow函数,注意这个slow就代表重新申请chunk、分配page等等,这里暂不展开。

内存对齐

  • 内存对齐:所申请的内存返回的起始地址都是逻辑地址(下面会讲),且该地址一定是2MB的整数倍,这就是内存对齐。在PHP中,可以判定一定是申请的huge规格的内存。因为small和large内存的第一个page存放了zend_mm_heap结构体,肯定不是2MB地址的整数倍。这样可以快速计算出当前地址属于第几个chunk。比如地址是4096,就属于第3个chunk。
  • 所以内存对齐的优点就是如果对齐了,就可以直接判断是huge规格,不需要额外存储用于以后判断的字段。
  • x64体系结构的计算机的地址共有64位,任何一个内存地址都可以分为首地址 + 偏移量,如1019地址(10进制) = 1000(首地址) + 19 (偏移量);从二进制角度来看,2MB = 10 0000 0000 0000 0000 0000,低21位全部为0(偏移量为0),高43位为首地址(第22位为1,高64-22 = 42位全部为0)就构成了64位的逻辑地址。这样可以方便地进行逻辑地址与物理地址的转换。
  • 向操作系统申请内存都是以页为单位,所以申请的内存都是4KB的整数倍,不会出现4K+1这种逻辑地址。
  • 思考:PHP向操作系统申请内存是以chunk为单位,但是操作系统只返回4KB整数倍的内存起始地址,并不是2MB内存的起始地址,一个chunk中,分配到2MB整数倍起始地址是1/512概率,如何让操作系统申请的地址直接是2MB的整数倍呢?
  • 答案:多申请一部分存储空间,掐头去尾,保证起始地址2MB对齐。

gdb调试相关

  • gdb需要指定一个可执行的二进制程序来进行调试,相关命令用法google即可,常用r/b/n/s/p
  • 当利用gdb b main的时候,为什么php没有main()入口函数却仍可以正常执行上述gdb命令?因为虚拟机会默认帮助你加一个main()和return
  • 编译器优化:将inline函数直接注入到函数里面去,把宏进行替换等等,所以编译的时候为方便调试需要禁用编译器优化
03-05 17:18