【文章內(nèi)容簡介】 public: ...... static ALWAYS_INLINE bool AllocatorHasAllocationStack(AllocatorType allocator_type) { return allocator_type != kAllocatorTypeBumpPointer amp。amp。 allocator_type != kAllocatorTypeTLAB。 } ...... }。 這個函數(shù)定義在文件art/runtime/gc/。 前面提到，ART運行時線程的TLAB是來自于Bump Pointer Space的，而Bump Pointer Space是與Compacting GC相關(guān)的，Allocation Stack是與Sticky GC相關(guān)的，這就意味著Compacting GC不會執(zhí)行Sticky類型的GC。 第二件事情是調(diào)用Heap類的成員函數(shù)AllocatorMayHaveConcurrentGC判斷參數(shù)allocator指定的分配器是否與Concurrent GC相關(guān)，并且當前使用的GC就是一個Concurrent GC。如果條件都成立的話，就調(diào)用Heap類的成員函數(shù)CheckConcurrentGC檢查是否需要發(fā)起一個Concurrent GC請求。 Heap類的成員函數(shù)AllocatorMayHaveConcurrentGC的實現(xiàn)如下所示：[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片class Heap { public: ...... static ALWAYS_INLINE bool AllocatorMayHaveConcurrentGC(AllocatorType allocator_type) { return AllocatorHasAllocationStack(allocator_type)。 } ...... }。 這個函數(shù)定義在文件art/runtime/gc/。 Heap類的成員函數(shù)AllocatorMayHaveConcurrentGC的判斷邏輯與上面分析的成員函數(shù)AllocatorHasAllocationStack是一樣的，這就意味著目前提供的Compacting GC都是非Concurrent的。不過以后是會提供具有Concurrent功能的Compacting GC的，稱為Concurrent Copying GC。 以上就是Heap類的成員函數(shù)AllocObjectWithAllocator的實現(xiàn)，接下來我們繼續(xù)分析Heap類的成員函數(shù)TryToAllocate和AllocateInternalWithGc的實現(xiàn)，以便可以更好地了解ART運行時分配對象的過程。這也有利用我們后面分析ART運行時的Compacting GC的執(zhí)行過程。 Heap類的成員函數(shù)TryToAllocate的實現(xiàn)如下所示：[cpp] view plain copy 在CODE上查看代碼片派生到我的代碼片template const bool kInstrumented, const bool kGrow inline mirror::Object* Heap::TryToAllocate(Thread* self, AllocatorType allocator_type, size_t alloc_size, size_t* bytes_allocated, size_t* usable_size) { if (allocator_type != kAllocatorTypeTLAB amp。amp。 UNLIKELY(IsOutOfMemoryOnAllocationkGrow(allocator_type, alloc_size))) { return nullptr。 } mirror::Object* ret。 switch (allocator_type) { case kAllocatorTypeBumpPointer: { DCHECK(bump_pointer_space_ != nullptr)。 alloc_size = RoundUp(alloc_size, space::BumpPointerSpace::kAlignment)。 ret = bump_pointer_space_AllocNonvirtual(alloc_size)。 if (LIKELY(ret != nullptr)) { *bytes_allocated = alloc_size。 *usable_size = alloc_size。 } break。 } case kAllocatorTypeRosAlloc: { if (kInstrumented amp。amp。 UNLIKELY(running_on_valgrind_)) { // If running on valgrind, we should be using the instrumented path. ret = rosalloc_space_Alloc(self, alloc_size, bytes_allocated, usable_size)。 } else { DCHECK(!running_on_valgrind_)。 ret = rosalloc_space_AllocNonvirtual(self, alloc_size, bytes_allocated, usable_size)。 } break。 } case kAllocatorTypeDlMalloc: { if (kInstrumented amp。amp。 UNLIKELY(running_on_valgrind_)) { // If running on valgrind, we should be using the instrumented path. ret = dlmalloc_space_Alloc(self, alloc_size, bytes_allocated, usable_size)。 } else { DCHECK(!running_on_valgrind_)。 ret = dlmalloc_space_AllocNonvirtual(self, alloc_size, bytes_allocated, usable_size)。 } break。 } case kAllocatorTypeNonMoving: { ret = non_moving_space_Alloc(self, alloc_size, bytes_allocated, usable_size)。 break。 } case kAllocatorTypeLOS: { ret = large_object_space_Alloc(self, alloc_size, bytes_allocated, usable_size)。 // Note that the bump pointer spaces aren39。t necessarily next to // the other continuous spaces like the nonmoving alloc space or // the zygote space. DCHECK(ret == nullptr || large_object_space_Contains(ret))。 break。 } case kAllocatorTypeTLAB: { DCHECK_ALIGNED(alloc_size, space::BumpPointerSpace::kAlignment)。 if (UNLIKELY(selfTlabSize() alloc_size)) { const size_t new_tlab_size = alloc_size + kDefaultTLABSize。 if (UNLIKELY(IsOutOfMemoryOnAllocationkGrow(allocator_type, new_tlab_size))) { return nullptr。 } // Try allocating a new thread local buffer, if the allocaiton fails the space must be // full so return nullptr. if (!bump_pointer_space_AllocNewTlab(self, new_tlab_size)) { return nullptr。 } *bytes_allocated = new_tlab_size。 } else { *bytes_allocated = 0。 } // The allocation can39。t fail. ret = selfAllocTlab(alloc_size)。 DCHECK(ret != nullptr)。 *usable_size = alloc_size。 break。 } default: { LOG(FATAL) Invalid allocator type。 ret = nullptr。 } } return ret。 } 這個函數(shù)定義在文件art/runtime/gc/。 Heap類的成員函數(shù)TryToAllocate的實現(xiàn)是很直覺的，我們可以通過圖3來描述：首先，如果不是指定在當前ART運行時線程的TLAB中分配對象，并且指定分配的對象大小超出了當前堆的限制，那么就會分配失敗，返回一個nullptr指針。 接下來，就根據(jù)參數(shù)allocator指定的分配器在不同的Space中分配對象： 1. 指定在Bump Pointer Space中分配對象，就調(diào)用Heap類的成員變量bump_pointer_space_指向的一個BumpPointerSpace對象的成員函數(shù)AllocNonvirtual分配指定大小的內(nèi)存。 2. 指定在Ros Alloc Space中分配對象，就調(diào)用Heap類的成員變量rosalloc_space_指向的一個RosAllocSpace對象的成員函數(shù)Alloc者AllocNonvirtual分配指定大小的內(nèi)存。當模板參數(shù)kInstrumented的值等于true，并且Heap類的成員變量running_on_valgrind_的值等于true時，就調(diào)用RosAllocSpace類的成員函數(shù)Alloc進行分配。否則的話，就調(diào)用RosAllocSpace類的成員函數(shù)AllocNonvirtual進行分配。從Heap類的成員變量running_on_valgrind_的命令就可以很容易推斷出，調(diào)用RosAllocSpace類的成員函數(shù)Alloc分配的內(nèi)存具有非法內(nèi)存訪問檢查功能，在前面一篇文章中，我們有提到這種內(nèi)存分配方式。 3. 指定在Dl Malloc Space中分配對象，就調(diào)用Heap類的成員變量dlmalloc_space_指向的一個DlMallocSpace對象的成員函數(shù)Alloc者AllocNonvirtual分配指定大小的內(nèi)存。這一點與在Ros Alloc Space中分配對象的邏輯是完全一致的，除了一個是在Dl Malloc Space中分配內(nèi)存， 另一個是在Ros Alloc Space中分配對象之外。 4. 指定在Non Moving Space中分配對象，就調(diào)用Heap類的成員變量non_moving_space_指向的一個RosAllocSpace對象或者DlMallocSpace對象的成員函數(shù)Alloc分配指定大小的內(nèi)存。從前面一文可以知道，Heap類的成員變量non_moving_space_指向的可能是一個Ro