《Glibc内存管理》笔记DAY4】的更多相关文章

目录 分箱式内存管理 Small bins Large bins 内容来源 分箱式内存管理   对于空闲的 chunk,ptmalloc 采用分箱式内存管理方式,根据空闲 chunk 的大小和处于的状态将其放在四个不同的 bin 中,这四个空闲 chunk 的容器包括 fast bins,unsorted bin,small bins 和 large bins.Fast bins 是小内存块的高速缓存,当一些大小小于 64 字节的 chunk 被回收时,首先会放入 fast bins 中,在分配…
目录 分箱式内存管理 Unsorted bin Fast bins 核心结构体分析 malloc_state 内容来源 分箱式内存管理 Unsorted bin   Unsorted bin 可以看作是 small bins 和 large bins 的 cache,只有一个 unsorted bin,以双向链表管理空闲 chunk,空闲 chunk 不排序,所有的 chunk 在回收时都要先放到 unsorted bin 中,分配时,如果在 unsorted bin 中没有合适的 chunk,…
目录 边界标记法 内容来源 边界标记法 /* conversion from malloc headers to user pointers, and back */ #define chunk2mem(p) ((Void_t*)((char*)(p) + 2*SIZE_SZ)) #define mem2chunk(mem) ((mchunkptr)((char*)(mem) - 2*SIZE_SZ)) chunk2mem(p):根据 chunk 地址获得返回给用户的内存地址 mem2chunk…
目录 Ptmalloc内存管理设计 Main_arena 与 non_main_arena chunk 的组织 空闲 chunk 容器 sbrk 与 mmap 内存分配概述 内存回收概述 边界标记法 内容来源 Ptmalloc内存管理设计 具有长生命周期的大内存分配使用 mmap. 特别大的内存分配总是使用 mmap. 具有短生命周期的内存分配使用 brk,因为用 mmap 映射匿名页,当发生缺页异常时,linux 内核为缺页分配一个新物理页,并将该物理页清 0,一个 mmap 的内存块需要映射…
目录 x86_64栈和mmap固定映射地址 内存的延迟分配 内核数据结构 mm_struct Heap 操作相关函数 Mmap 映射区域操作相关函数 内容来源 x86_64栈和mmap固定映射地址   只需要设置全局变量randomize_va_space 值 为 0 , 这 个 变 量 默 认 值 为 1 . 用 户 可 以 通 过 设 置/proc/sys/kernel/randomize_va_space 来停用该特性,也可以用如下命令: sudo sysctl -w kernel.ran…
前言 大家好,我是雨乐. 5年前,在上家公司的时候,因为进程OOM造成了上千万的损失,当时用了一个月的时间来分析glibc源码,最终将问题彻底解决. 最近在逛知乎的时候,发现不少人有对malloc/free有类似的疑惑,恰好自己有阅读过这方面的源码,所以将之前的源码阅读笔记整理了下,用了大概3周的时间写了这篇文章,分析glibc的内存管理精髓,相信对c/c++从业者都会有用. 由于本文涉及知识点较多,因此为了方便阅读,提供了PDF版本,可以留言获取 提纲 1 写在前面 源码分析本身就很枯燥乏味,…
更新中 在Linux平台下做漏洞利用的时候,针对于Heap部分总是有些不求甚解,下面开个博文来记录下<Glibc内存管理:ptmalloc2源代码分析>这本书的读后感和收获,一些简单的点将不再记录 说明,本博文中所有的实验均在Linux Ubuntu16.04的环境下进行 目录树: 一些关于计算size的宏 "chunk to mem" and "mem to chunk" about size 分箱式内存管理 smallbins largebins 一…
本文转载自glibc内存管理那些事儿 Linux内存空间简介 32位Linux平台下进程虚拟地址空间分布如下图: 进程虚拟地址空间分布 图中,0xC0000000开始的最高1G空间是内核地址空间,剩下3G空间是用户态空间.用户态空间从上到下依次为stack栈(向下增长).mmap(匿名文件映射区).Heap堆(向上增长).bss数据段.数据段.只读代码段. 其中,Heap区是程序的动态内存区,同时也是C++内存泄漏的温床.malloc.free均发生在这个区域.本文将简单介绍下glibc在动态内…
引用计数器 当一个对象被创建出来,就要分配给内存这个对象,当不用这个对象的时候,就要及时的回收,为了可以明确知道对象有没有被使用,就要用引用计数器来体现,只要计数器不为0,表明对象被使用中. 1.方法的基本使用 1> retain :计数器+1,会返回对象本身 2> release :计数器-1,没有返回值 3> retainCount :获取当前的计数器 4> dealloc * 当一个对象要被回收的时候,就会调用 * 一定要调用[super dealloc],这句调用要放在最后…
java内存管理机制 在java中,内存管理由JVM完全负责,java中的"垃圾回收器"负责自动回收无用对象占据的内存资源,这样可以大大减少程序猿在内存管理上花费的时间,可以更集中于业务逻辑和具体功能实现:但这并不是说java有了垃圾回收器程序猿就可以高枕无忧,将内存管理抛之脑外了!一方面,实际上java中还存在垃圾回收器没法回收以某种"特殊方式"分配的内存的情况(这种特殊方式我们将在下文中进行详细描述):另一方面,java的垃圾回收是不能保证一定发生的,除非JVM…
前面已经分析了linux内存管理算法(伙伴管理算法)的准备工作. 具体的算法初始化则回到start_kernel()函数接着往下走,下一个函数是mm_init(): [file:/init/main.c] /* * Set up kernel memory allocators */ static void __init mm_init(void) { /* * page_cgroup requires contiguous pages, * bigger than MAX_ORDER unle…
前面分析了memblock算法.内核页表的建立.内存管理框架的构建,这些都是x86处理的setup_arch()函数里面初始化的,因地制宜,具有明显处理器的特征.而start_kernel()接下来的初始化则是linux通用的内存管理算法框架了. build_all_zonelists()用来初始化内存分配器使用的存储节点中的管理区链表,是为内存管理算法(伙伴管理算法)做准备工作的.具体实现: [file:/mm/page_alloc.c] /* * Called with zonelists_…
前面已经分析了内存管理框架的构建实现过程,有部分内容未完全呈现出来,这里主要做个补充. 如下图,这是前面已经看到过的linux物理内存管理框架的层次关系. 现着重分析一下各个管理结构体的成员功能作用. [file:/include/linux/mmzone.h] typedef struct pglist_data { struct zone node_zones[MAX_NR_ZONES]; struct zonelist node_zonelists[MAX_ZONELISTS]; int…
前面构建内存管理框架,已经将内存管理node节点设置完毕,接下来将是管理区和页面管理的构建.此处代码实现主要在于setup_arch()下的一处钩子:x86_init.paging.pagetable_init().据前面分析可知x86_init结构体内该钩子实际上挂接的是native_pagetable_init()函数. native_pagetable_init(): [file:/arch/x86/mm/init_32.c] void __init native_pagetable_in…
memory:表示可用可分配的内存: 结束完memblock算法初始化前的准备工作,回到memblock算法初始化及其算法实现上面.memblock是一个很简单的算法. memblock算法的实现是,它将所有状态都保存在一个全局变量__initdata_memblock中,算法的初始化以及内存的申请释放都是在将内存块的状态做变更.那么从数据结构入手, __initdata_memblock是一个memblock结构体.其结构体定义: [file:/include/linux/memblock.h…
memblock算法是linux内核初始化阶段的一个内存分配器(它取代了原来的bootmem算法),实现较为简单.负责page allocator初始化之前的内存管理和分配请求. 分析memblock算法,可以从几点入手: memblock算法初始化: memblock算法管理内存的申请和释放: memblock算法前的准备: 前面已经分析了linux系统在初始化的过程中,使用int 15中断探知了机器的内存分布图(e820图),其数据是存储在boot_params.e820_map里面,这里面…
本文转载自:http://blog.chinaunix.net/uid-26859697-id-5573776.html kmalloc()是基于slab/slob/slub分配分配算法上实现的,不少地方将其作为slab/slob/slub分配算法的入口,实际上是略有区别的. 现在分析一下其实现: [file:/include/linux/slab.h] /** * kmalloc - allocate memory * @size: how many bytes of memory are r…
程序员接触的内存空间和系统接触的物理内存空间是有所区别的.对于一般进程来讲,他面对的是一个线性虚拟内存空间:地址从0到最大值.每一个进程面对的虚拟内存空间都是一样的,都享有全部的内存地址.虚拟内存空间是线性的,但并不意味着是连续的.部分地址段的虚拟空间可以是缺失的(不是所有地址都可以用来存储数据). 虚拟内存可以按页管理,每一页大小一般为4kb.每一页背后都有一个实际物理内存(可以是主存也可以是辅存)与之对应.在物理内存中我们不叫页,而称之为帧.分页的好处就是可以在主存不够的情况下把辅存给利用上…
此处承接前面未深入分析的页面释放部分,主要详细分析伙伴管理算法中页面释放的实现.页面释放的函数入口是__free_page(),其实则是一个宏定义. 具体实现: [file:/include/linux/gfp.h] #define __free_page(page) __free_pages((page), 0) 而__free_pages()的实现: [file:/mm/page_alloc.c] void __free_pages(struct page *page, unsigned i…
此处接前文,分析free_area_init_nodes()函数最后部分,分析其末尾的循环: for_each_online_node(nid) { pg_data_t *pgdat = NODE_DATA(nid); free_area_init_node(nid, NULL, find_min_pfn_for_node(nid), NULL); /* Any memory on that node */ if (pgdat->node_present_pages) node_set_stat…
传统的计算机结构中,整个物理内存都是一条线上的,CPU访问整个内存空间所需要的时间都是相同的.这种内存结构被称之为UMA(Uniform Memory Architecture,一致存储结构).但是随着计算机的发展,一些新型的服务器结构中,尤其是多CPU的情况下,物理内存空间的访问就难以控制所需的时间相同了.在多CPU的环境下,系统只有一条总线,有多个CPU都链接到上面,而且每个CPU都有自己本地的物理内存空间,但是也可以通过总线去访问别的CPU物理内存空间,同时也存在着一些多CPU都可以共同访…
1.对象的创建 虚拟机遇到一条new指令时,首先会去检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载.解析和初始化过.如果没有,则必须先进行相应的类的加载. 2.对象的访问定位 简历对象是为了使用对象,我们的java程序需要通过栈上的refrerence数据来操作堆上的具体对象.由于reference类型在java虚拟机规范中只规定了一个指向对象的引用,并没有定义这个引用应该通过何种方式去定位.访问堆中的对象的具体位置,所以对象访问方式也是取决于…
我们在进行iOS开发时,经常会在类的声明部分看见类似于@synthesize window=_window; 的语句,那么,这个window是什么,_ window又是什么,两个东西分别怎么用,这是一个比较基本的问题,也关乎我们理解Objective-C中对类.类的属性.类的存取器.类的局部变量的统一理解. 在32位系统中,如果类的 @interface 部分没有进行 ivar 声明,但有 @property 声明,在类的 @implementation 部分有响应的 @synthesize,则…
本文转载自:http://blog.chinaunix.net/uid-26859697-id-5758037.html 分析完kmemleak实现后,照常实验一下,以确定功能正常. 如kmemcheck一样,该功能需要在内核开启的情况下才能够使用.主要的配置项有:CONFIG_DEBUG_KERNEL.CONFIG_HAVE_DEBUG_KMEMLEAK.CONFIG_DEBUG_KMEMLEAK,以及配置信息记录条数的CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE,…
前面分析了伙伴管理算法的初始化,在切入分析代码实现之前,例行先分析一下其实现原理. 伙伴管理算法(也称之为Buddy算法),该算法将所有空闲的页面分组划分为MAX_ORDER个页面块链表进行管理,其中MAX_ORDER定义: [file:/include/linux/mmzone.h] #ifndef CONFIG_FORCE_MAX_ZONEORDER #define MAX_ORDER 11 #else #define MAX_ORDER CONFIG_FORCE_MAX_ZONEORDER…
虽说前文分析内存管理框架构建的实现,提到了find_zone_movable_pfns_for_nodes(),但这里不准备复述什么,仅针对required_movablecore和required_kernelcore做一个补充. 以required_movablecore为例,代码中没有很清晰地表明该值从何而来,仅有一处cmdline_parse_movablecore()疑似赋值的实现: [file:/mm/page_alloc.c] /* * movablecore=size sets…
前面已经分析了内核页表的准备工作以及内核低端内存页表的建立,接着回到init_mem_mapping()中,低端内存页表建立后紧随着还有一个函数early_ioremap_page_table_range_init(): [file:/arch/x86/mm/init.c] /* * Build a proper pagetable for the kernel mappings. Up until this * point, we've been running on some set of…
前面的前奏已经分析介绍了建立内核页表相关变量的设置准备,接下来转入正题分析内核页表的建立. 建立内核页表的关键函数init_mem_mapping(): [file:/arch/x86/mm/init.c] void __init init_mem_mapping(void) { unsigned long end; probe_page_size_mask(); #ifdef CONFIG_X86_64 end = max_pfn << PAGE_SHIFT; #else end = max…
前面已经分析过了Intel的内存映射和linux的基本使用情况,已知head_32.S仅是建立临时页表,内核还是要建立内核页表,做到全面映射的.下面就基于RAM大于896MB,而小于4GB ,切CONFIG_HIGHMEM配置了高端内存的环境情况进行分析. 建立内核页表前奏,了解两个很关键的变量: max_pfn:最大物理内存页面帧号: max_low_pfn:低端内存区(直接映射空间区的内存)的最大可用页帧号: max_pfn 的值来自setup_arch()中,setup_arch()函数中…