ART运行时为新创建对象分配内存的过程分析

        ART运行时和Dalvik虚拟机1样，在堆上为对象分配内存时都要解决内存碎片和内存不足问题。内存碎片问题可使用dlmalloc技术解决。内存不足问题则通过垃圾回收和在允许范围内增长堆大小解决。由于垃圾回收会影响程序，因此ART运行时采取力度从小到大的进垃圾回收策略。1旦力度小的垃圾回收履行过后能满足分配要求，那就不需要进行力度大的垃圾回收了。本文就详细分析ART运行时在堆上为对象分配内存的进程。

本博参加博客之星评选，求投票：点击投票

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

       从前面ART运行时Java堆创建进程分析1文可以知道，在ART运行时中，主要用来分配对象的堆空间Zygote Space和Allocation Space的底层使用的都是匿名同享内存，并且通过C库提供的malloc和free接口来分进行管理。这样就能够通过dlmalloc技术来尽可能解决碎片问题。这1点与我们在前面Dalvik虚拟机为新创建对象分配内存的进程分析1文提到的Dalvik虚拟机解决堆内存碎片问题的方法是1样的。因此，接下来在分析ART运行时为新创建对象分配的进程中，主要会分析它是如何解决内存不足的问题的。

       ART运行时为新创建对象分配的进程如图1所示：

图1 ART运行时为新创建对象分配内存的进程

        对照Dalvik虚拟机为新创建对象分配内存的进程分析1文的图2，可以发现，ART运行时和Dalvik虚拟机为新创建对象分配内存的进程几近是1模1样的，它们的区分仅仅是在于垃圾搜集的方式和策略不同。

        从前面Android运行时ART履行类方法的进程分析1文可以知道，ART运行时为从DEX字节码翻译得到的Native代码提供的1个函数调用表中，有1个pAllocObject接口，是用来分配对象的。当ART运行时以Quick模式运行在ARM体系结构时，上述提到的pAllocObject接口由函数art_quick_alloc_object来实现。因此，接下来我们就从函数art_quick_alloc_object的实现开始分析ART运行时为新创建对象分配内存的进程。

        函数art_quick_alloc_object的实现以下所示：

       这是1段ARM汇编，我们需要注意的1点是Native代码调用ART运行时提供的对象分配接口的参数传递方式。其中，参数type_idx描写的是要分配的对象的类型，通过寄存器r0传递，参数method描写的是当前调用的类方法，通过寄存器r1传递。

       函数art_quick_alloc_object是通过调用另外1个函数artAllocObjectFromCode来分配对象的。函数art_quick_alloc_object除传递前面描写的参数type_idx和method给函数artAllocObjectFromCode以外，还会传递另外的两个参数。其中1个是描写当前线程的1个Thread对象，该对象总是保存在寄存器r9中，现在由于要通过参数的情势传递给另外1个函数，因此就将它放在寄存器r2。另外1个是栈指针sp，也是由于要通过参数的情势的传递另外1个函数，这里也会将它放在寄存器r3中。

       函数artAllocObjectFromCode的实现以下所示：

        函数artAllocObjectFromCode又是通过调用另外1个函数AllocObjectFromCode来分配对象的。不过，在调用函数AllocObjectFromCode之前，函数artAllocObjectFromCode会先调用另外1个函数FinishCalleeSaveFrameSetup在当前调用栈帧中保存1个运行时信息。这个运行时信息描写的是接下来要调用的方法的类型为Runtime::kRefsOnly，也就是由被调用者保存那些不是用来传递参数的通用寄存器，即除r0-r3的其它通用寄存器。

        函数AllocObjectFromCode的实现以下所示：

       参数type_idx描写的是要分配的对象的类型，函数AllocObjectFromCode需要将它解析为1个Class对象，以即可以取得更多的信息进行内存分配。

       函数AllocObjectFromCode首先是在当前调用类方法method的Dex Cache中检查是不是已存在1个与参数type_idx对应的Class对象。如果已存在，那末就说明参数type_idx描写的对象类型已被加载和解析过了，因此这时候候就能够直接拿来使用。否则的话，就通过调用保存在当前运行时对象内部的1个ClassLinker对象的成员函数ResolveType来对参数type_idx描写的对象类型进行加载和解析。关于Dex Cache的知识，可以参数前面Android运行时ART履行类方法的进程分析1文，而对象类型（即类）的加载和解析进程可以参考前面Android运行时ART加载类和方法的进程分析1文。

       得到了要分配的对象的类型klass以后，如果参数access_check的值等于true，那末就对该类型进行检查，即检查它是不是可以实例化和是不是可以访问。如果检查通过，或不需要检查，那末接下来还要确保类型klass是已初始化过了的。前面的检查都没有问题以后，最后函数AllocObjectFromCode就调用Class类的成员函数AllocObject来分配1个类型为klass的对象。

       Class类的成员函数AllocObject的实现以下所示：

      这里我们就终究看到调用ART运行时内部的Heap对象的成员函数AllocObject在堆上分配对象了，其中，要分配的大小保存在当前Class对象的成员变量object_size_中。

      Heap类的成员函数AllocObject的实现以下所示：

        这个函数定义在文件art/runtime/gc/heap.cc中。

        Heap类的成员函数AllocObject首先是要肯定要在哪一个Space上分配内存。可以分配内存的Space有3个，分别Zygote Space、Allocation Space和Large Space。不过，Zygote Space在还没有划分出Allocation Space之前，就在Zygote Space上分配，而当Zygote Space划分出Allocation Space以后，就只能在Allocation Space上分配。从前面ART运行时Java堆创建进程分析1文可以知道，Heap类的成员变量alloc_space_在Zygote Space在还没有划分出Allocation Space之前指向Zygote Space，划分以后就指向Allocation Space。Large Object Space则始终由Heap类的成员变量large_object_space_指向。

        只要满足以下3个条件，就在Large Object Space上分配，否则就在Zygote Space或Allocation Space上分配：

        1. 要求分配的内存大于等于Heap类的成员变量large_object_threshold_指定的值。这个值等于3 * kPageSize，即3个页面的大小。

        2. 已从Zygote Space划分出Allocation Space，即Heap类的成员变量have_zygote_space_的值等于true。

        3. 被分配的对象是1个原子类型数组，即byte数组、int数组和boolean数组等。

        肯定好要在哪一个Space上分配内存以后，就能够调用Heap类的成员函数Allocate进行分配了。如果分配成功，Heap类的成员函数Allocate就返回新分配的对象，保存在变量obj中。接下来再做3件事情：

        1. 调用Object类的成员函数SetClass设置新分配对象obj的类型。

        2. 调用Heap类的成员函数RecordAllocation记录当前的内存分配状态。

        3. 检查当前已分配出去的内存是不是已到达由Heap类的成员变量concurrent_start_bytes_设定的阀值。如果到达，那末就调用Heap类的成员函数RequestConcurrentGC通知GC履行1次并行GC。关于履行并行GC的阀值，接下来分要ART运行时的垃圾搜集进程中再详细分析。

        另外一方面，如果Heap类的成员函数Allocate分配内存失败，则Heap类的成员函数AllocObject抛出1个OOM异常。

        接下来，我们先分析Heap类的成员函数RecordAllocation的实现，接着再分析Heap类的成员函数Allocate的实现。由于后者的履行流程比较复杂，而前者的履行流程比较简单。我们先分析容易的，以避免打断后面的分析。

        Heap类的成员函数RecordAllocation的实现以下所示：

        Heap类的成员函数RecordAllocation首先是记录当前已分配的内存字节数和对象数，接着再将新分配的对角压入到Heap类的成员变量allocation_stack_描写的Allocation Stack中去。后面这1点与Dalvik虚拟机的做法是不1样的。Dalvik虚拟机直接将新分配出来的对象记录在Live Bitmap中，具体可以参考前面Dalvik虚拟机为新创建对象分配内存的进程分析1文。ART运行时之所以要将新分配的对象压入到Allocation Stack中去，是为了以后可以履行Sticky GC。

        注意，如果不能成功将将新分配的对角压入到Allocation Stack中，就说明上次GC以来，新分配的对象太多了，因此这时候候就需要履行1个Sticky GC，将Allocation Stack里面的垃圾进行回收，然后再尝试将新分配的对象压入到Allocation Stack中，直到成功为止。

        接下来我们就重点分析Heap类的成员函数Allocate的实现，以即可以了解新创建对象在堆上分配的具体进程，以下所示：

        这个函数定义在文件art/runtime/gc/heap.cc中。

        Heap类的成员函数Allocate首先调用成员函数TryToAllocate尝试在不履行GC的情况下进行内存分配。如果分配失败，再调用成员函数AllocateInternalWithGc进行带GC的内存分配。

       Heap类的成员函数Allocate是1个模板函数，不同类型的Space会致使调用不同重载的成员函数TryToAllocate进行不带GC的内存分配。虽然可以用来分配内存的Space有Zygote Space、Allocation Space和Large Object Space3个，但是前二者的类型是相同的，因此实际上只有两个不同重载版本的成员函数TryToAllocate，它们的实现以下所示：

        Heap类两个重载版本的成员函数TryToAllocate的实现逻辑都几近是相同的，首先是调用另外1个成员函数IsOutOfMemoryOnAllocation判断分配要求的内存后是不是会超过堆的大小限制。如果超过，则分配失败；否则的话再在指定的Space进行内存分配。

        Heap类的成员函数IsOutOfMemoryOnAllocation的实现以下所示：

        Heap类的成员变量num_bytes_allocated_描写的是目前已分配出去的内存字节数，成员变量max_allowed_footprint_描写的是目前堆可分配的最大内存字节数，成员变量growth_limit_描写的是目前堆允许增长到的最大内存字节数。这里需要注意的1点是，max_allowed_footprint_是Heap类施加的1个限制，不会对各个Space实际可分配的最大内存字节数产生影响，并且各个Space在创建的时候，已把自己可分配的最大内存数设置为允许使用的最大内存字节数的。

        如果目前堆已分配出去的内存字节数再加上要求分配的内存字节数new_footprint小于等于目前堆可分配的最大内存字节数max_allowed_footprint_，那末分配出要求的内存字节数以后不会造成OOM，因此Heap类的成员函数IsOutOfMemoryOnAllocation就返回false。。

        另外一方面，如果目前堆已分配出去的内存字节数再加上要求分配的内存字节数new_footprint大于目前堆可分配的最大内存字节数max_allowed_footprint_，并且也大于目前堆允许增长到的最大内存字节数growth_limit_，那末分配出要求的内存字节数以后造成OOM，因此Heap类的成员函数IsOutOfMemoryOnAllocation就返回true。

       剩下另外1种情况，目前堆已分配出去的内存字节数再加上要求分配的内存字节数new_footprint大于目前堆可分配的最大内存字节数max_allowed_footprint_，但是小于等于目前堆允许增长到的最大内存字节数growth_limit_，这时候候就要看情况了会不会出现OOM了。如果ART运行时运行在非并行GC的模式中，即Heap类的成员变量concurrent_gc_等于false，那末取决于允不允许增长堆的大小，即参数grow的值。如果不允许，那末Heap类的成员函数IsOutOfMemoryOnAllocation就返回true，表示当前要求的分配会造成OOM。如果允许，那末Heap类的成员函数IsOutOfMemoryOnAllocation就会修改目前堆可分配的最大内存字节数max_allowed_footprint_，并且返回false，表示允许当前要求的分配。这意味着，在非并行GC运行模式中，在分配内存进程中遇到内存不足，并且当前可分配内存还未到达增长上限时，要等到履行完成1次非并行GC后，才能成功分配到内存，由于每次履行完成GC以后，都会依照预先设置的堆目标利用率来增长堆的大小。

        另外一方面，如果ART运行时运行在并行GC的模式中，那末只要前堆已分配出去的内存字节数再加上要求分配的内存字节数new_footprint不地超过目前堆允许增长到的最大内存字节数growth_limit_，那末就不管允不允许增长堆的大小，都认为不会产生OOM，因此Heap类的成员函数IsOutOfMemoryOnAllocation就返回false。这意味着，在并行GC运行模式中，在分配内存进程中遇到内存不足，并且当前可分配内存还未到达增长上限时，不过等到履行并行GC后，就有可能成功分配到内存，由于实际履行内存分配的Space可分配的最大内存字节数是足够的。

        回到前面Heap类的成员函数TryToAllocate中，从前面ART运行时Java堆创建进程分析1文可以知道，对Large Object Space版本的成员函数TryToAllocate，调用的是LargeObjectMapSpace类的成员函数Alloc进行内存分配，而对Zygote Space或Allocation Space版本的成员函数TryToAllocate，如果成员变量running_on_valgrind_的值等于true，就调用ValgrindDlMallocSpace类的成员函数AllocNonvirtual进行内存分配，否则就调用DlMallocSpace类的成员函数Alloc进行内存分配。我们假定Heap类的成员变量running_on_valgrind_的值等于false，因此接下来我们主要分析LargeObjectMapSpace类的成员函数Alloc和DlMallocSpace类的成员函数Alloc的实现。

       LargeObjectMapSpace类的成员函数Alloc的实现以下所示：

       从这里就能够看到，Large Object Map Space分配内存的逻辑是很简单的，直接就是调用MemMap类的静态成员函数MapAnonymous创建1块指定大小的匿名内存，然后再将该匿名同享内存添加到成员变量large_objects_描写的1个向量中去，最后更新内部的各个统计数据。

       DlMallocSpace类的成员函数Alloc的实现以下所示：

       DlMallocSpace类的成员函数Alloc调用另外1个成员函数AllocNonvirtual来进行内存分配，后者的实现以下所示：

       DlMallocSpace类的成员函数AllocNonvirtual首先是调用另外1个成员函数AllocWithoutGrowthLocked在不增长Space的大小的条件下进行内存分配，分配成功以后再调用函数memset对分配出来的内存进行清空，最后将分配出来的内存返回给调用者。

       DlMallocSpace类的成员函数AllocWithoutGrowthLocked的实现以下所示：

        从前面ART运行时Java堆创建进程分析1文可以知道，DlMallocSpace底层使用的匿名同享内存块被封装成1个mspace对象，并且保存在成员变量mspace_中，因此这里就能够直接调用C库提供的mspace_malloc接口进行内存分配。使用mspace_malloc分配的内存会自动被清空，因此这里不用再手动清空。DlMallocSpace类的成员函数AllocWithoutGrowthLocked在将分配出来的内存返回给调用者之前，一样是会更新内部的各个统计数据。

        回到前面Heap类的成员函数Allocate中，在调用成员函数TryToAllocate不能成功分配指定大小的内存块以后，接下来就继续调用成员函数AllocateInternalWithGc履行带GC的内存分配，它的实现以下所示：

        Heap类的成员函数AllocateInternalWithGc主要是通过垃圾回收来满足要求分配的内存，它的履行逻辑以下所示：

        1. 调用Heap类的成员函数WaitForConcurrentGcToComplete检查是不是有并行GC正在履行。如果有的话，就等待其履行完成，并且得到它的类型last_gc。如果last_gc如果不等于collector::kGcTypeNone，就表示有并行GC并且已履行完成，因此就能够调用Heap类的成员函数TryToAllocate在不增长当前堆大小的条件下再次尝试分配要求的内存了。如果分配成功，则返回得到的内存起始地址给调用者。否则的话，继续往下履行。

        2.  顺次履行kGcTypeSticky、kGcTypePartial和kGcTypeFull3种类型的GC。每次GC履行终了，都尝试调用Heap类的成员函数TryToAllocate在不增长当前堆大小的条件下再次尝试分配要求的内存。如果分配内存成功，则返回得到的内存起始地址给调用者，并且不再履行下1个种类型的GC。

        这里需要注意的1点是，kGcTypeSticky、kGcTypePartial和kGcTypeFull3种类型的GC的垃圾回收力度是顺次加强：kGcTypeSticky只回收上次GC后在Allocation Space中新分配的垃圾对象；kGcTypePartial只回收Allocation Space的垃圾对象；kGcTypeFull同时回收Zygote Space和Allocation Space的垃圾对象。通过这类策略，就有可能以最小代价解决分配对象时遇到的内在不足问题。不过，对类型为kGcTypeSticky和kGcTypePartial的GC，它们的履行是条件的

        类型为kGcTypeSticky的GC的履行代码虽然是最小的，但是它能够回收的垃圾也是最小的。如果回收的垃圾不足于满足要求分配的内存，那就相当于做了1次无用功了。因此，履行类型为kGcTypeSticky的GC需要满足两个条件。第1个条件是上次GC后在Allocation Space上分配的内存要到达1定的阀值，这样才有比较大的几率回收到较多的内存。第2个条件Allocation Space剩余的未分配内存要到达1定的阀值，这样可以保证在回收得到较少内存时，也有比较大的几率满足要求分配的内存。前1个阀值定义在Heap类的成员变量min_alloc_space_size_for_sticky_gc_中，它的值设置为2M，而上次GC以来分配的内存通过当前Allocation Space的大小估算得到，即通过调用Heap类的成员变量alloc_space_指向的1个DlMallocSpace对象的成员函数Size取得。后1个阀值定义在Heap类的成员变量min_remaining_space_for_sticky_gc_中，它的值设置为1M，而Allocation Space剩余的未分配内存可以用Allocation Space的总大小减去当前Allocation Space的大小得到。通过调用Heap类的成员变量alloc_space_指向的1个DlMallocSpace对象的成员函数Capacity取得其总大小。

        类型为kGcTypePartial的GC的履行条件是已从Zygote Space中划分出Allocation Space。从前面ART运行时Java堆创建进程分析1文可以知道，当Heap类的成员变量have_zygote_space_的值等于true时，就表明已从Zygote Space中划分出Allocation Space了。因此，在这类情况下，就能够履行类型为kGcTypePartial的GC了。

        每种类型的GC都是通过调用Heap类的成员函数CollectGarbageInternal来履行。注意这时候候调用Heap类的成员函数CollectGarbageInternal传递的第3个参数为false，表示不对那些只被软援用对象援用的对象进行回收。如果上述的3种类型的GC履行终了，还是不能满足分配要求的内存，则继续往下履行。

        3. 经过前面3种类型的GC后还是不能成功分配到内存，那就说明能够回收的内存还是太小了，因此，这时候候只能通过在允许范围内增长堆的大小来满足内存分配要求了。前面分析Heap类的成员函数TryToAlloctate时，将第4个参数设置为true，便可在允许范围内增长堆大小的条件下进行内存分配。如果在允许范围内增长了堆的大小还是不能成功分配到要求的内存，那就只能出最后的1个大招了。

        4.  最后的大招是首先履行1个类型为kGcTypeFull的、要求回收那些只被软援用对象援用的对象的GC，接着再在允许范围内增长堆大小的条件下尝试分配内存。这1次如果还是失败，那就真的是内存不足了。

        至此，我们就对ART运行时在堆上为新创建对象分配内存的进程分析完成了。从中我们就能够看到，ART运行时面临的最大挑战就是内存不足问题，它要通过在允许范围内增长堆大小和垃圾回收两个手段来解决。其中，垃圾回收会对程序造成影响，因此在履行垃圾回收时，使用的力度要从小到大。在接下来的1篇文章中，我们就将详细分析这些力度不同的垃圾回收是如何实现的，敬请关注！更多的信息也能够关注老罗的新浪微博：http://weibo.com/shengyangluo。