【源码Linux系统】【jdk源码 编译】【字体psd源码】源码图解

时间:2024-11-26 23:46:01 编辑:怎么编译cefsharp源码 来源:msql源码

1.C语言的源码图解编译过程是怎样的?
2.图解Go里面的WaitGroup了解编程语言核心实现源码
3.图解UE4源码AI行为树系统 其二 一棵行为树是怎么被运行起来的
4.图解UE4源码 其三(一)行为树系统执行任务的流程 发起执行请求
5.JDK成长记7:3张图搞懂HashMap底层原理!
6.图解Lua分代GC

源码图解

C语言的源码图解编译过程是怎样的?

       C语言编译过程详解

       C语言的编译链接过程是要把我们编写的一个C程序(源代码)转换成可以在硬件上运行的程序(可执行代码),需要进行编译和链接。源码图解编译就是源码图解把文本形式源代码翻译为机器语言形式的目标文件的过程。链接是源码图解把目标文件、操作系统的源码图解源码Linux系统启动代码和用到的库文件进行组织形成最终生成可执行代码的过程。过程图解如下:

       从图上可以看到,源码图解整个代码的源码图解编译过程分为编译和链接两个过程,编译对应图中的源码图解大括号括起的部分,其余则为链接过程。源码图解

       一、源码图解编译过程

       编译过程又可以分成两个阶段:编译和汇编。源码图解

       1、源码图解编译

       编译是源码图解读取源程序(字符流),对之进行词法和语法的源码图解分析,将高级语言指令转换为功能等效的汇编代码,源文件的编译过程包含两个主要阶段:

       第一个阶段是预处理阶段,在正式的编译阶段之前进行。预处理阶段将根据已放置在文件中的预处理指令来修改源文件的内容。如#include指令就是一个预处理指令,它把头文件的内容添加到.cpp文件中。这个在编译之前修改源文件的方式提供了很大的灵活性,以适应不同的计算机和操作系统环境的限制。一个环境需要的代码跟另一个环境所需的代码可能有所不同,因为可用的硬件或操作系统是不同的。在许多情况下,可以把用于不同环境的代码放在同一个文件中,再在预处理阶段修改代码,使之适应当前的环境。

       主要是以下几方面的处理:

       (1)宏定义指令,如 #define a b。

       对于这种伪指令,预编译所要做的是将程序中的所有a用b替换,但作为字符串常量的 a则不被替换。还有 #undef,则将取消对某个宏的定义,使以后该串的出现不再被替换。

       (2)条件编译指令,如#ifdef,#ifndef,#else,#elif,#endif等。

       这些伪指令的引入使得程序员可以通过定义不同的宏来决定编译程序对哪些代码进行处理。预编译程序将根据有关的文件,将那些不必要的代码过滤掉

       (3) 头文件包含指令,如#include "FileName"或者#include <FileName>等。

       在头文件中一般用伪指令#define定义了大量的宏(最常见的是字符常量),同时包含有各种外部符号的声明。采用头文件的目的主要是为了使某些定义可以供多个不同的C源程序使用。因为在需要用到这些定义的C源程序中,只需加上一条#include语句即可,而不必再在此文件中将这些定义重复一遍。预编译程序将把头文件中的定义统统都加入到它所产生的输出文件中,以供编译程序对之进行处理。包含到C源程序中的头文件可以是系统提供的,这些头文件一般被放在/usr/include目录下。在程序中#include它们要使用尖括号(<>)。另外开发人员也可以定义自己的jdk源码 编译头文件,这些文件一般与C源程序放在同一目录下,此时在#include中要用双引号("")。

       (4)特殊符号,预编译程序可以识别一些特殊的符号。

       例如在源程序中出现的LINE标识将被解释为当前行号(十进制数),FILE则被解释为当前被编译的C源程序的名称。预编译程序对于在源程序中出现的这些串将用合适的值进行替换。

       预编译程序所完成的基本上是对源程序的“替代”工作。经过此种替代,生成一个没有宏定义、没有条件编译指令、没有特殊符号的输出文件。这个文件的含义同没有经过预处理的源文件是相同的,但内容有所不同。下一步,此输出文件将作为编译程序的输出而被翻译成为机器指令。

       第二个阶段编译、优化阶段。经过预编译得到的输出文件中,只有常量;如数字、字符串、变量的定义,以及C语言的关键字,如main,if,else,for,while,{ ,}, +,-,*,\等等。

       编译程序所要作得工作就是通过词法分析和语法分析,在确认所有的指令都符合语法规则之后,将其翻译成等价的中间代码表示或汇编代码。

       优化处理是编译系统中一项比较艰深的技术。它涉及到的问题不仅同编译技术本身有关,而且同机器的硬件环境也有很大的关系。优化一部分是对中间代码的优化。这种优化不依赖于具体的计算机。另一种优化则主要针对目标代码的生成而进行的。

       对于前一种优化,主要的工作是删除公共表达式、循环优化(代码外提、强度削弱、变换循环控制条件、已知量的合并等)、复写传播,以及无用赋值的删除,等等。

        后一种类型的优化同机器的硬件结构密切相关,最主要的是考虑是如何充分利用机器的各个硬件寄存器存放的有关变量的值,以减少对于内存的访问次数。另外,如何根据机器硬件执行指令的特点(如流水线、RISC、CISC、VLIW等)而对指令进行一些调整使目标代码比较短,执行的效率比较高,也是一个重要的研究课题。

       2、汇编

       汇编实际上指把汇编语言代码翻译成目标机器指令的过程。对于被翻译系统处理的每一个C语言源程序,都将最终经过这一处理而得到相应的目标文件。目标文件中所存放的也就是与源程序等效的目标的机器语言代码。目标文件由段组成。字体psd源码通常一个目标文件中至少有两个段:

       代码段:该段中所包含的主要是程序的指令。该段一般是可读和可执行的,但一般却不可写。

       数据段:主要存放程序中要用到的各种全局变量或静态的数据。一般数据段都是可读,可写,可执行的。

       UNIX环境下主要有三种类型的目标文件:

       (1)可重定位文件

       其中包含有适合于其它目标文件链接来创建一个可执行的或者共享的目标文件的代码和数据。

       (2)共享的目标文件

       这种文件存放了适合于在两种上下文里链接的代码和数据。

       第一种是链接程序可把它与其它可重定位文件及共享的目标文件一起处理来创建另一个 目标文件;

       第二种是动态链接程序将它与另一个可执行文件及其它的共享目标文件结合到一起,创建一个进程映象。

       (3)可执行文件

       它包含了一个可以被操作系统创建一个进程来执行之的文件。汇编程序生成的实际上是第一种类型的目标文件。对于后两种还需要其他的一些处理方能得到,这个就是链接程序的工作了。

       二、链接过程

       由汇编程序生成的目标文件并不能立即就被执行,其中可能还有许多没有解决的问题。

       例如,某个源文件中的函数可能引用了另一个源文件中定义的某个符号(如变量或者函数调用等);在程序中可能调用了某个库文件中的函数,等等。所有的这些问题,都需要经链接程序的处理方能得以解决。

       链接程序的主要工作就是将有关的目标文件彼此相连接,也即将在一个文件中引用的符号同该符号在另外一个文件中的定义连接起来,使得所有的这些目标文件成为一个能够被操作系统装入执行的统一整体。

       根据开发人员指定的同库函数的链接方式的不同,链接处理可分为两种:

       (1)静态链接

       在这种链接方式下,函数的代码将从其所在地静态链接库中被拷贝到最终的可执行程序中。这样该程序在被执行时这些代码将被装入到该进程的虚拟地址空间中。静态链接库实际上是一个目标文件的集合,其中的每个文件含有库中的一个或者一组相关函数的代码。

       (2) 动态链接

       在此种方式下,函数的代码被放到称作是动态链接库或共享对象的某个目标文件中。链接程序此时所作的只是在最终的可执行程序中记录下共享对象的名字以及其它少量的登记信息。在此可执行文件被执行时,动态链接库的全部内容将被映射到运行时相应进程的虚地址空间。动态链接程序将根据可执行程序中记录的信息找到相应的函数代码。

       对于可执行文件中的函数调用,可分别采用动态链接或静态链接的方法。使用动态链接能够使最终的可执行文件比较短小,并且当共享对象被多个进程使用时能节约一些内存,因为在内存中只需要保存一份此共享对象的代码。但并不是使用动态链接就一定比使用静态链接要优越。在某些情况下动态链接可能带来一些性能上损害。

       我们在linux使用的gcc编译器便是把以上的几个过程进行捆绑,使用户只使用一次命令就把编译工作完成,这的确方便了编译工作,但对于初学者了解编译过程就很不利了,下图便是gcc代理的编译过程:

       从上图可以看到:

       预编译

       将.c 文件转化成 .i文件

       使用的gcc命令是:gcc –E

       对应于预处理命令cpp

       编译

       将.c/.h文件转换成.s文件

       使用的gcc命令是:gcc –S

       对应于编译命令 cc –S

       汇编

       将.s 文件转化成 .o文件

       使用的gcc 命令是:gcc –c

       对应于汇编命令是 as

       链接

       将.o文件转化成可执行程序

       使用的gcc 命令是: gcc

       对应于链接命令是 ld

       总结起来编译过程就上面的四个过程:预编译、编译、汇编、链接。了解这四个过程中所做的工作,对我们理解头文件、库等的工作过程是有帮助的,而且清楚的了解编译链接过程还对我们在编程时定位错误,以及编程时尽量调动编译器的c 考试 源码检测错误会有很大的帮助的。

       是否可以解决您的问题?

图解Go里面的WaitGroup了解编程语言核心实现源码

       sync.WaitGroup核心实现逻辑简单,主要用于等待一组goroutine退出。它通过Add方法指定等待的goroutine数量,Done方法递减计数。计数为0时,等待结束。sync.WaitGroup内部使用了一个state1数组,其中只有一个元素,类型为[3]uint。这是为了内存对齐,确保数据按照4字节对齐,从而在位和位平台间兼容。

       内部元素采用uint类型进行计数,长度为8字节。这是为了防止在位平台上对字节的uint操作可能不是原子的情况。使用uint保证了原子操作的执行和性能。在CPU缓存线(cache line)的上下文中,8字节长度可能有助于确保对缓存线的操作是原子的,从而避免数据损坏。

       测试8字节指针的构造,验证了在经过编译器进行内存分配对齐后,如果元素指针的地址不能被8整除,则其地址+4可以被8整除。这展示了编译器层内存对齐的实现细节。

       sync.WaitGroup中的8字节uint采用分段计数的方式,高位记录需要Done的数量,低位记录正在等待结束的计数。

       源码的核心原理包括使用位uint进行计数,通过高位记录需要Done的数量和低位记录等待的数量。当发现count>0时,Wait的goroutine会排队等待。任务完成后,goroutine执行Done操作,直到count==0,完成并唤醒所有等待的goroutine。

       计数与信号量的实现通过根据当前指针的地址确定采用哪个分段进行计数和等待。添加等待计数和Done完成等待事件分别对应sync.WaitGroup的Add和Done方法。等待所有操作完成时,sync.WaitGroup确保所有任务完成。

       为了深入理解这些概念,可以参考相关文章和资源,如关于CPU缓存线大小和原子操作的讨论。此外,更多源码分析文章可关注特定的公告号或网站,如www.sreguide.com。本篇文章由ArtiPub自动发布平台发布。

图解UE4源码AI行为树系统 其二 一棵行为树是怎么被运行起来的

       让我们深入理解UE4中AI行为树的运行机制。首先,行为树的运行流程大致分为以下几个步骤:

发起执行: 可以通过AAIController::RunBehaviorTree()函数或Run Behavior任务节点启动新树。

抽象逻辑理解: 从Run Behavior任务节点出发,关键在于OwnerComp.PushInstance(*BehaviorAsset),这涉及子树的监控和结束条件。

检查与加载: 在运行前,UBehaviorTreeComponent会对子树资源、全局UBehaviorTreeManager、发起节点的父节点意愿进行检查。只有当所有条件满足,才会加载行为树资源。android 秀源码

内存计算与初始化: 加载后,通过FNodeInitializationData计算节点的执行顺序、内存需求,注入顶层decorator,然后设置初始值和内存偏移。

实例化与缓存: 将计算结果的树模板存入缓存,供后续使用。加载完成后,行为树实例会被添加到InstanceStack并标记为活跃。

       新树加载并初始化完毕后,执行流程开始于根节点的服务调用和根节点的执行。每个节点的详细运行机制会在后续内容中进一步探讨。理解这些步骤有助于我们更好地掌握行为树的控制和执行逻辑。

图解UE4源码 其三(一)行为树系统执行任务的流程 发起执行请求

       本文探讨UE4源码中的行为树系统执行任务流程,重点解析了发起执行请求的机制。在UE4中,行为树系统负责执行特定任务,而请求执行的关键代码在于调用`UBehaviorTreeComponent::RequestExecution()`函数。本文将分别从行为树加载后执行、任务执行完毕后搜索下一个任务、以及由Decorator引发的Abort请求三种情境出发,详细解析RequestExecution函数的内部逻辑。

       ### 引子一:已加载行为树的执行

       行为树加载完毕后,执行的关键代码就是发起执行请求。`RequestExecution()`函数的执行,实质上是开始执行行为树内的任务。在行为树加载后,调用此函数启动执行流程,开始搜索并执行任务。

       ### 引子二:任务执行完毕

       任务执行完成后,行为树会自动发起搜索和执行下一个任务的请求。这同样依赖于`RequestExecution()`函数,但调用方式不同,需要传入任务执行的结果作为参数。

       ### 引子三:TimeLimit修饰器

       UE4自带的`BTDecorator_TimeLimit`修饰器用于限制任务执行时间。当时间超过设定值,该修饰器会触发任务的Abort。分析其内部逻辑时,我们发现它通过调整时间计数器来控制任务执行时间,而不是通过直接中断任务。

       ### 发起执行请求的关键信息

       请求执行的过程涉及多个关键信息的传递,包括搜索的起始点和结束点、要执行的节点、上一次任务的结果、是否尝试执行下一个子节点等。这些信息构成`ExecutionRequest`结构体,由`RequestExecution()`函数生成。

       ### 新手难度:从行为树加载后讲起

       从行为树加载后执行为例,`RequestExecution()`函数仅做了初始化标志位、确定搜索范围、设定请求执行节点等基础操作。这些步骤为后续的执行流程做好准备。

       ### 中级难度:任务执行完毕后搜索下一个任务

       在任务执行完毕后,调用`RequestExecution()`以自动搜索下一个任务。此时,函数逻辑主要围绕上一次任务的结果,决定是否切换到更高优先级的任务。

       ### 终极难度:Decorator的Abort

       当Decorator引发任务中断时,`RequestExecution()`需要处理更复杂的逻辑,包括调整搜索范围、确保请求执行的节点符合特定条件。这涉及到更深入地理解行为树的结构和Decorator的工作机制。

       ### 应用——追查Decorator Abort记录

       通过分析`RequestExecution()`函数的调用记录,可以追踪行为树运行过程中由Decorator引发的中断事件,有助于深入了解行为树的执行流程和异常情况。

       本文通过对UE4源码中的`RequestExecution()`函数的深入分析,揭示了行为树系统执行任务流程中的关键机制,为理解和优化行为树的运行提供了理论基础和实践指导。

JDK成长记7:3张图搞懂HashMap底层原理!

       一句话讲, HashMap底层数据结构,JDK1.7数组+单向链表、JDK1.8数组+单向链表+红黑树。

       在看过了ArrayList、LinkedList的底层源码后,相信你对阅读JDK源码已经轻车熟路了。除了List很多时候你使用最多的还有Map和Set。接下来我将用三张图和你一起来探索下HashMap的底层核心原理到底有哪些?

       首先你应该知道HashMap的核心方法之一就是put。我们带着如下几个问题来看下图:

       如上图所示,put方法调用了putVal方法,之后主要脉络是:

       如何计算hash值?

       计算hash值的算法就在第一步,对key值进行hashCode()后,对hashCode的值进行无符号右移位和hashCode值进行了异或操作。为什么这么做呢?其实涉及了很多数学知识,简单的说就是尽可能让高和低位参与运算,可以减少hash值的冲突。

       默认容量和扩容阈值是多少?

       如上图所示,很明显第二步回调用resize方法,获取到默认容量为,这个在源码里是1<<4得到的,1左移4位得到的。之后由于默认扩容因子是0.,所以两者相乘就是扩容大小阈值*0.=。之后就分配了一个大小为的Node[]数组,作为Key-Value对存放的数据结构。

       最后一问题是,如何进行hash寻址的?

       hash寻址其实就在数组中找一个位置的意思。用的算法其实也很简单,就是用数组大小和hash值进行n-1&hash运算,这个操作和对hash取模很类似,只不过这样效率更高而已。hash寻址后,就得到了一个位置,可以把key-value的Node元素放入到之前创建好的Node[]数组中了。

       当你了解了上面的三个原理后,你还需要掌握如下几个问题:

       还是老规矩,看如下图:

       当hash值计算一致,比如当hash值都是时,Key-Value对的Node节点还有一个next指针,会以单链表的形式,将冲突的节点挂在数组同样位置。这就是数据结构中所提到解决hash 的冲突方法之一:单链法。当然还有探测法+rehash法有兴趣的人可以回顾《数据结构和算法》相关书籍。

       但是当hash冲突严重的时候,单链法会造成原理链接过长,导致HashMap性能下降,因为链表需要逐个遍历性能很差。所以JDK1.8对hash冲突的算法进行了优化。当链表节点数达到8个的时候,会自动转换为红黑树,自平衡的一种二叉树,有很多特点,比如区分红和黑节点等,具体大家可以看小灰算法图解。红黑树的遍历效率是O(logn)肯定比单链表的O(n)要好很多。

       总结一句话就是,hash冲突使用单链表法+红黑树来解决的。

       上面的图,核心脉络是四步,源码具体的就不粘出来了。当put一个之后,map的size达到扩容阈值,就会触发rehash。你可以看到如下具体思路:

       情况1:如果数组位置只有一个值:使用新的容量进行rehash,即e.hash & (newCap - 1)

       情况2:如果数组位置有链表,根据 e.hash & oldCap == 0进行判断,结果为0的使用原位置,否则使用index + oldCap位置,放入元素形成新链表,这里不会和情况1新的容量进行rehash与运算了,index + oldCap这样更省性能。

       情况3:如果数组位置有红黑树,根据split方法,同样根据 e.hash & oldCap == 0进行树节点个数统计,如果个数小于6,将树的结果恢复为普通Node,否则使用index + oldCap,调整红黑树位置,这里不会和新的容量进行rehash与运算了,index + oldCap这样更省性能。

       你有兴趣的话,可以分别画一下这三种情况的图。这里给大家一个图,假设都出发了以上三种情况结果如下所示:

       上面源码核心脉络,3个if主要是校验了一堆,没做什么事情,之后赋值了扩容因子,不传递使用默认值0.,扩容阈值threshold通过tableSizeFor(initialCapacity);进行计算。注意这里只是计算了扩容阈值,没有初始化数组。代码如下:

       竟然不是大小*扩容因子?

       n |= n >>> 1这句话,是在干什么?n |= n >>> 1等价于n = n | n >>>1; 而|表示位运算中的或,n>>>1表示无符号右移1位。遇到这种情况,之前你应该学到了,如果碰见复杂逻辑和算法方法就是画图或者举例子。这里你就可以举个例子:假设现在指定的容量大小是,n=cap-1=,那么计算过程应该如下:

       n是int类型,java中一般是4个字节,位。所以的二进制: 。

       最后n+1=,方法返回,赋值给threshold=。再次注意这里只是计算了扩容阈值,没有初始化数组。

       为什么这么做呢?一句话,为了提高hash寻址和扩容计算的的效率。

       因为无论扩容计算还是寻址计算,都是二进制的位运算,效率很快。另外之前你还记得取余(%)操作中如果除数是2的幂次方则等同于与其除数减一的与(&)操作。即 hash%size = hash & (size-1)。这个前提条件是除数是2的幂次方。

       你可以再回顾下resize代码,看看指定了map容量,第一次put会发生什么。会将扩容阈值threshold,这样在第一次put的时候就会调用newCap = oldThr;使得创建一个容量为threshold的数组,之后从而会计算新的扩容阈值newThr为newCap*0.=*0.=。也就是说map到了个元素就会进行扩容。

       除了今天知识,技能的成长,给大家带来一个金句甜点,结束我今天的分享:坚持的三个秘诀之一目标化。

       坚持的秘诀除了上一节提到的视觉化,第二个秘诀就是目标化。顾名思义,就是需要给自己定立一个目标。这里要提到的是你的目标不要定的太高了。就比如你想要增加肌肉,给自己定了一个目标,每天5组,每次个俯卧撑,你看到自己胖的身形或者海报,很有刺激,结果开始前两天非常厉害,干劲十足,特别奥利给。但是第三天,你想到要个俯卧撑,你就不想起床,就算起来,可能也会把自己撅死过去......其实你的目标不要一下子定的太大,要从微习惯开始,比如我媳妇从来没有做过俯卧撑,就让她每天从1个开始,不能多,我就怕她收不住,做多了。一开始其实从习惯开始,先变成习惯,再开始慢慢加量。量太大养不成习惯,量小才能养成习惯。很容易做到才能养成,你想想是不是这个道理?

       所以,坚持的第二个秘诀就是定一个目标,可以通过小量目标,养成微习惯。比如每天你可以读五分钟书或者5分钟成长记,不要多,我想超过你也会睡着了的.....

       最后,大家可以在阅读完源码后,在茶余饭后的时候问问同事或同学,你也可以分享下,讲给他听听。

图解Lua分代GC

       一直对GC很感兴趣,最近阅读Lua GC相关资料并结合Lua5.4.6源码总结了Lua的分代GC机制。

       在Lua中,对象根据年龄被划分为新旧不同阶段。其中,NEW、SURVIVAL属于新对象;OLD、OLD0、OLD1、TOUCHED1、TOUCHED2属于老对象。

       对象的颜色表示其状态,分为黑、白、灰三种。黑色代表对象已被完全标记,灰色代表有待标记,白色代表不再被使用的对象。YoungGC通过递归标记灰色对象,清理白色对象。

       对象颜色通过mark字段中的三个比特位表示,黑色占一个比特,白色占两个比特,全0表示灰色状态。

       使用三色标记方法,对象颜色动态变化,帮助GC准确识别无用对象。

       在Lua GC中,对象的管理通过特定的链表结构实现,包含普通无析构函数对象链表、有析构函数对象链表以及灰色对象链表。

       新对象经历两次小GC才能成为老对象的机制,旨在确保新对象的生命周期大于一次年轻代GC间隔,避免错误标记。

       源码中只标记OLD1年龄态对象的原因是,G_TOUCHED1、G_TOUCHED2、OLD0年龄态对象已经在灰链中。而OLD年龄态在小GC时不进行引用标记。

       OLD1年龄态对象已经历两次小GC,理论上属于老对象范畴。但将其直接归并入OLD态会导致SURVIVAL年龄态对象的引用标记问题。

       通过上述机制,Lua的分代GC实现了高效而精准的对象管理,降低了内存碎片,提升了程序性能。

PyTorch ResNet 使用与源码解析

       在PyTorch中,我们可以通过torchvision.model库轻松使用预训练的图像分类模型,如ResNet。本文将重点讲解ResNet的使用和源码解析。

       模型介绍与ResNet应用

       torchvision.model库提供了多种预训练模型,包括ResNet,其特点是层深度的残差网络。首先,我们需要加载预训练的模型参数:

       模型加载代码:

       python

       model = torchvision.models.resnet(pretrained=True)

       接着,将模型放置到GPU上,并设置为评估模式:

       GPU和评估模式设置:

       python

       model = model.to(device='cuda')

       model.eval()

       Inference流程

       在进行预测时,主要步骤包括数据预处理和网络前向传播:

       关键代码:

       python

       with torch.no_grad():

        output = model(input_data)

       残差连接详解

       ResNet的核心是残差块,包含两个路径:一个是拟合残差的路径(称为残差路径),另一个是恒等映射(称为shortcut)。通过element-wise addition将两者连接:

       残差块结构:

       1. 残差路径: [公式]

       2. 短路路径: [公式] (通常为identity mapping)

       网络结构与变种

       ResNet有不同深度的变种,如ResNet、ResNet、ResNet等,网络结构根据层数和块的数量有所不同:

       不同ResNet的结构图:

       ...

       源码分析

       构造函数中,例如ResNet的构造过程是通过_resnet()方法逐步构建网络,涉及BasicBlock或Bottleneck的使用:

       ResNet构造函数:

       ...

       源码的深入解析包括forward()方法的执行流程,以及_make_layer()方法定义网络层:

       forward()方法和_make_layer()方法:

       ...

       图解示例

       ResNet和ResNet的不同层结构,如layer1的升维与shortcut处理:

       ResNet和ResNet的图解:

       ...

       希望这些内容对理解ResNet在PyTorch中的应用有所帮助。如果你从中受益,别忘了分享或支持作者继续创作。

+ 张图剖析内存分配之 malloc 详解

       本文将深入剖析内存分配中的malloc函数,虽然不详述源码,但重点讲解其实际操作。首先,理解malloc分配的内存结构至关重要。

       当malloc分配内存时,会额外添加首部和尾部。如图所示,分配的0x字节内存中,浅绿色fill部分是用户请求的,返回的是该区域的起始指针。fill区域周围有预填充的gap,用于区分用户可使用区域和不可使用区域,且在归还时能检测是否越界。

       内存管理涉及层次结构,系统在程序启动前会用__cdecl_heap_init分配堆空间,构建管理动态内存的个HEADER节点链表,每个节点管理1MB内存。每个节点结构中包含指向虚拟地址空间的pHeapData,这部分相当于未分配的"门牌号"。

       接下来是内存页的划分和管理,新的内存页被分为K大小的段,并按需挂载到链表。分配和归还过程包括从链表查找空间、开辟新group、合并空闲内存以及记录使用情况。当一个group全回收后,不会立即归还系统,而是等待其他group的回收一起操作,以提高效率。

       通过以上图解和步骤,我们对malloc的内存分配有了直观的认识。要了解更多细节,可以参考相关视频教程,如"C++开发"系列,以及获取更多C/C++和Linux架构师学习资源。