Art 虛擬機系列Heap內存模型分配策略詳解
背景
隨著性能優(yōu)化逐步進入深水區(qū)，我們發(fā)現(xiàn)很多大廠的方案，其實都建立在對正常虛擬機運行過程中Hook的基礎上，建立自己的優(yōu)化方案。因此，只有了解了art虛擬機的運行機制，才能真正去實施一些特殊的“魔改”方案。因為art代碼非常龐大，我們會從很多的方面去了解他。本片是Heap 模型的第一篇。
內存分配
當我們在java層 new 一個對象的時候，由于有虛擬機的存在，我們開發(fā)者不用了解任何相關的內存分配細節(jié)，就能夠完成一次內存的分配。那么，art虛擬機究竟是怎么幫助我們進行內存分配的，其實得益于art虛擬機抽象的以下分配類
我們從上圖可以看到，art把內存分配相關的模型策略，分為了6層
第一層
分為了Space與AllocSpace兩個類，他們都是一個虛類，即需要子類去實現(xiàn)virtual修飾的方法，比如我們看到Space類定義
class Space {
public:
// Dump space. Also key method for C++ vtables.
virtual void Dump(std::ostream& os) const;
Space代表一塊內存空間，AllocSpace代表一塊可用于內存分配的空間，AllocSpace則提供了內存分配與釋放相關的虛函數(shù)，Alloc，F(xiàn)ree，由特定的子類去實現(xiàn)對應的策略。
class AllocSpace {
public:
virtual mirror::Object* Alloc(Thread* self, size_t num_bytes, size_t* bytes_allocated,
size_t* usable_size, size_t* bytes_tl_bulk_allocated) = 0;
virtual size_t Free(Thread* self, mirror::Object* ptr) = 0;
再回過頭我們看到上面的類圖，我們就會發(fā)現(xiàn)子類中的ImageSpace是沒有繼承于AllocSpace，這就意味著，它其實是沒有實現(xiàn)對應的Alloc與Free相關的函數(shù)，因此，我們常說的GC機制，其實是不會作用在這塊內存空間上面的！非常有趣！我們下文會繼續(xù)講到，這跟art劃分的內存模型有很大關系
第二層
第二層是ContinuousSpace與DiscontinuousSpace兩個類，這兩個類的職責非常簡單，前者就是代表了該內存空間是連續(xù)的，后者是非連續(xù)。
劃分為連續(xù)與非連續(xù)，其實更大的作用是在GC過程中相關的內存整理，非連續(xù)的空間有更簡單的分配方式
第三層
MemMapSpace 與 LargeObjectSpace是第三層，在這里，已經(jīng)開始根據(jù)外部所需要的空間的大小，進行了不同的空間劃分。比如當分配的內存屬于java對象String或者是基礎類型的數(shù)組，且內存超過3個內存頁（Heap 構造時我們會講到，一般是12kb）的時候，就會把資源分配到LargeObject內存空間里面，其他的就分配在MemMapSpace
第四層
到了第四層，我們出現(xiàn)了第一個非常重要的內存分配空間，ImageSpcace，ImageSpace用于.art文件的加載，我們知道應用可以在預編譯的時候，生成.art文件，還有就是一些系統(tǒng)類，比如boot.art，這些art文件在內存中的表現(xiàn)，其實就放在了ImageSpace中。同時我們也講到，ImageSpace沒有繼承AllocSpace，這也就意味著，它不會對外提供分配與釋放策略，因此該內存中，也不會被GC所影響?。梢园巡糠謫宇惙旁谶@里，達到GC抑制的效果）而另外的ContinuousMemMapAllocSpace，將由它的子類去實現(xiàn)常見的內存分配策略。
第五、六層
五六層就是具體的art內存分配策略了，包括了BumpPointerSpace，ZygoteSpace，RegionSpace，RosAllocSpace，DlMallocSpace，它們都有自己特有的內存分配策略，這些策略被應用在不同的各個地方（主要由GC策略選擇不同的內存分配策略）。下面我們按裝順序介紹一下這幾種內存分配策略
內存分配策略
BumpPointerSpace
BumpPointerSpace其實分配思想很簡單，就是順序分配，比如我第一次分配分配10kb內存，下一次再分配xxkb
BumpPointerSpace::BumpPointerSpace(const std::string& name, uint8_t* begin, uint8_t* limit)
: ContinuousMemMapAllocSpace(name,
MemMap::Invalid(),
begin,
begin,
limit,
kGcRetentionPolicyAlwaysCollect),
growth_end_(limit), 資源的尾部，
objects_allocated_(0), 當前有多少個mirrorobject
bytes_allocated_(0), 分配的內存大小
block_lock_("Block lock"),
main_block_size_(0) {
// This constructor gets called only from Heap::PreZygoteFork(), which
// doesn't require a mark_bitmap.
}
因為是順序分配，因此我們只需記錄一個尾部end地址（已分配的最后一個地址尾部），就能在下次分配直接找到分配的開始地址，非常簡單，這里就不詳細說分配過程，可以參考分配源碼
ZygoteSpace
ZygoteSpace本身沒有創(chuàng)建相關的內存資源，而是通過外部傳入的MemMap對象，作為內存資源，自身只是起到了一個管理作用
ZygoteSpace* ZygoteSpace::Create(const std::string& name,
MemMap&& mem_map,
accounting::ContinuousSpaceBitmap&& live_bitmap,
accounting::ContinuousSpaceBitmap&& mark_bitmap) {
DCHECK(live_bitmap.IsValid());
DCHECK(mark_bitmap.IsValid());
size_t objects_allocated = 0;
CountObjectsAllocated visitor(&objects_allocated);
ReaderMutexLock mu(Thread::Current(), *Locks::heap_bitmap_lock_);
live_bitmap.VisitMarkedRange(reinterpret_cast<uintptr_t>(mem_map.Begin()),
reinterpret_cast<uintptr_t>(mem_map.End()), visitor);
ZygoteSpace* zygote_space = new ZygoteSpace(name, std::move(mem_map), objects_allocated);
zygote_space->live_bitmap_ = std::move(live_bitmap);
zygote_space->mark_bitmap_ = std::move(mark_bitmap);
return zygote_space;
}
ZygoteSpace在art有特殊的含義，就是該內存空間是繼承自Zygote進程的資源存放地，雖然它繼承自AllocSpace，但是它的分配實現(xiàn)Alloc/Free，是不起作用的
mirror::Object* ZygoteSpace::Alloc(Thread*, size_t, size_t*, size_t*, size_t*) {
UNIMPLEMENTED(FATAL);
UNREACHABLE();
}
它作為一塊帶有“含義”的內存資源而存在，同時它不同于ImageSpace，ImageSpace存放的是系統(tǒng)資源內存，不會發(fā)生GC操作。而ZygoteSpace會在FullGC的時候，進行GC的操作。因為來自Zygote進程的內存，還是有回收的空間
RegionSpace
RegionSpace，其實是把內存資源通過劃分的思想，把內存劃分成一個個固定大小的Region而得名，相當于內存空間被劃分多個內存塊，進行內存分配時，在內存塊分配即可。
RegionSpace::RegionSpace(const std::string& name, MemMap&& mem_map, bool use_generational_cc)
: ContinuousMemMapAllocSpace(name,
std::move(mem_map),
mem_map.Begin(),
mem_map.End(),
mem_map.End(),
kGcRetentionPolicyAlwaysCollect),
region_lock_("Region lock", kRegionSpaceRegionLock),
use_generational_cc_(use_generational_cc),
time_(1U),
num_regions_(mem_map_.Size() / kRegionSize),
madvise_time_(0U),
num_non_free_regions_(0U),
num_evac_regions_(0U),
max_peak_num_non_free_regions_(0U),
non_free_region_index_limit_(0U),
current_region_(&full_region_),
evac_region_(nullptr),
cyclic_alloc_region_index_(0U) {
CHECK_ALIGNED(mem_map_.Size(), kRegionSize);
CHECK_ALIGNED(mem_map_.Begin(), kRegionSize);
DCHECK_GT(num_regions_, 0U);
num_regions_ 個Region空間
regions_.reset(new Region[num_regions_]);
uint8_t* region_addr = mem_map_.Begin();
for (size_t i = 0; i < num_regions_; ++i, region_addr += kRegionSize) {
regions_[i].Init(i, region_addr, region_addr + kRegionSize);
}
mark_bitmap_ =
accounting::ContinuousSpaceBitmap::Create("region space live bitmap", Begin(), Capacity());
if (kIsDebugBuild) {
CHECK_EQ(regions_[0].Begin(), Begin());
for (size_t i = 0; i < num_regions_; ++i) {
CHECK(regions_[i].IsFree());
CHECK_EQ(static_cast<size_t>(regions_[i].End() - regions_[i].Begin()), kRegionSize);
if (i + 1 < num_regions_) {
CHECK_EQ(regions_[i].End(), regions_[i + 1].Begin());
}
}
CHECK_EQ(regions_[num_regions_ - 1].End(), Limit());
}
DCHECK(!full_region_.IsFree());
DCHECK(full_region_.IsAllocated());
size_t ignored;
DCHECK(full_region_.Alloc(kAlignment, &ignored, nullptr, &ignored) == nullptr);
// Protect the whole region space from the start.
Protect();
}
其中分配會采取內存對其，由屬性kRegionSize決定（每個Region默認1m）
因為抽象出來一個個Region，我們能夠隨心的去分配想要的內存，不局限內存本身是否是連續(xù)的，同時因為每個內存塊當前的狀態(tài)不同（比如，有的已經(jīng)分配了，有的沒有），因此每個Region本身還對應一個狀態(tài)RegionState
enum class RegionState : uint8_t {
kRegionStateFree, 該Region沒有內存分配
kRegionStateAllocated, 內存塊已分配
kRegionStateLarge, 大對象Region，比如4m的大對象（那么就需要4個Region），其中第一塊Region狀態(tài)為kRegionStateLarge，其他就是kRegionStateLargeTail
kRegionStateLargeTail, 如上
};
RegionSpace本身還定義著很多toSpace，fromSpace的操作，其實它就是Copying Collection（拷貝垃圾回收機制）的內存分配模型。然后android默認的垃圾回收機制，前臺是CMS，后臺是HSC，因此，RegionSpace能被發(fā)揮作用的地方其實還算是有點局限，除非你指定了Copying Collection垃圾回收機制
DlmallocSpace 與 RosAllocSpace
我們從上文的類圖可以看到DlmallocSpace與RosAllocSpace ，都是MallocSpace的子類，而我們的Heap里面，其實只有MallocSpace對象，具體選擇實現(xiàn)的子類是DlmallocSpace還是RosAllocSpace，其實由kUseRosAlloc決定，默認是使用RosAllocSpace。
space::MallocSpace* Heap::CreateMallocSpaceFromMemMap(MemMap&& mem_map,
size_t initial_size,
size_t growth_limit,
size_t capacity,
const char* name,
bool can_move_objects) {
space::MallocSpace* malloc_space = nullptr;
if (kUseRosAlloc) {
// Create rosalloc space.
malloc_space = space::RosAllocSpace::CreateFromMemMap(std::move(mem_map),
name,
kDefaultStartingSize,
initial_size,
growth_limit,
capacity,
low_memory_mode_,
can_move_objects);
} else {
malloc_space = space::DlMallocSpace::CreateFromMemMap(std::move(mem_map),
name,
kDefaultStartingSize,
initial_size,
growth_limit,
capacity,
can_move_objects);
}
if (collector::SemiSpace::kUseRememberedSet) {
accounting::RememberedSet* rem_set =
new accounting::RememberedSet(std::string(name) + " remembered set", this, malloc_space);
CHECK(rem_set != nullptr) << "Failed to create main space remembered set";
AddRememberedSet(rem_set);
}
CHECK(malloc_space != nullptr) << "Failed to create " << name;
malloc_space->SetFootprintLimit(malloc_space->Capacity());
return malloc_space;
}
DlmallocSpace與RosAllocSpace兩者不同點就在于，實現(xiàn)的機制不一樣，DlmallocSpace采用的是dlmalloc內存分配管理模型，它是一個開源庫，也是c語音malloc調用的具體實現(xiàn)。dlmalloc內存機制如下（其實就是malloc的機制）
而RosAllocSpace，采用的是谷歌自己的內存分配rosalloc完成，具體實現(xiàn)機制如下
rosalloc是一種動態(tài)分配內存算法，專門為了art虛擬機做了適配，其實它是一種多粒度內存分配算法，ros的意思就是run of slot，可以理解為一個run是RosAllocSpace中內存分配的單元，每個Run有自己的內存分配粒度（slot）
比如Run1 中代表可分配10kb為單位的內存，Run2則代表可分配1M為單位的內存，具體的內存由slot決定。
更加具體的分配細節(jié)，可以在這里看到，我們就不深入細節(jié)，有個概念就好。
LargeObjectSpace
它的創(chuàng)建過程很簡單，就是初始化num_bytes_allocated_等分配的參數(shù)
LargeObjectSpace::LargeObjectSpace(const std::string& name, uint8_t* begin, uint8_t* end,
const char* lock_name)
: DiscontinuousSpace(name, kGcRetentionPolicyAlwaysCollect),
lock_(lock_name, kAllocSpaceLock),
num_bytes_allocated_(0), num_objects_allocated_(0), total_bytes_allocated_(0),
total_objects_allocated_(0), begin_(begin), end_(end) {
}
不知道大家有沒有發(fā)現(xiàn)，LargeObjectSpace跟其他Space不一樣，它繼承于DiscontinuousSpace，意味著它的分配是不連續(xù)的，我們看一下它的分配過程就理解了
mirror::Object* LargeObjectMapSpace::Alloc(Thread* self, size_t num_bytes,
size_t* bytes_allocated, size_t* usable_size,
size_t* bytes_tl_bulk_allocated) {
std::string error_msg;
每次都調用MapAnonymous，其實它最終調用的就是mmap
MemMap mem_map = MemMap::MapAnonymous("large object space allocation",
num_bytes,
PROT_READ | PROT_WRITE,
/*low_4gb=*/ true,
&error_msg);
if (UNLIKELY(!mem_map.IsValid())) {
LOG(WARNING) << "Large object allocation failed: " << error_msg;
return nullptr;
}
mirror::Object* const obj = reinterpret_cast<mirror::Object*>(mem_map.Begin());
const size_t allocation_size = mem_map.BaseSize();
MutexLock mu(self, lock_);
large_objects_.Put(obj, LargeObject {std::move(mem_map), false /* not zygote */});
DCHECK(bytes_allocated != nullptr);
if (begin_ == nullptr || begin_ > reinterpret_cast<uint8_t*>(obj)) {
begin_ = reinterpret_cast<uint8_t*>(obj);
}
end_ = std::max(end_, reinterpret_cast<uint8_t*>(obj) + allocation_size);
*bytes_allocated = allocation_size;
if (usable_size != nullptr) {
*usable_size = allocation_size;
}
DCHECK(bytes_tl_bulk_allocated != nullptr);
*bytes_tl_bulk_allocated = allocation_size;
num_bytes_allocated_ += allocation_size;
total_bytes_allocated_ += allocation_size;
++num_objects_allocated_;
++total_objects_allocated_;
return obj;
}
可以看到，分配的時候，其實每次都是采用mmap去分配內存空間，而LargeObjectMapSpace就是將mmap返回的空間進行了一次管理，所以它才是不連續(xù)的，很好理解，這也意味指這塊內存的增長，不會影響屬于連續(xù)內存分配的其他Space（這里能做很多黑科技）。
那么我們分配的內存什么時候會被劃分進入LargeObjectSpace呢？其實我們直接看Heap分配條件即可，被定義為大對象要滿足以下條件
inline bool Heap::ShouldAllocLargeObject(ObjPtr<mirror::Class> c, size_t byte_count) const {
return byte_count >= large_object_threshold_ && (c->IsPrimitiveArray() || c->IsStringClass());
}
large_object_threshold_默認為12kb
總結
我們通過本文，初步了解了art內存分配的幾個模型，為什么要寫這個系列呢，其實就是因為最近大廠很多針對內存優(yōu)化的方案，都離不開對虛擬機內存分配的知識的了解！希望能夠通過這一系列的文章，能夠對自己有幫助！
以上就是Art 虛擬機系列Heap內存模型分配策略詳解的詳細內容，更多關于Art 虛擬機Heap內存分配的資料請關注腳本之家其它相關文章！
相關文章
這篇文章主要介紹了Android實現(xiàn)新浪微博一鍵分享的實例代碼,具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-07-07
Android UI設計與開發(fā)之仿人人網(wǎng)V5.9.2最新版引導界面
這篇文章主要為大家詳細介紹了Android UI設計與開發(fā)之仿人人網(wǎng)V5.9.2最新版引導界面，具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-08-08
Android自定義View實現(xiàn)隨機數(shù)驗證碼
這篇文章主要為大家詳細介紹了Android如何利用自定義View實現(xiàn)隨機數(shù)驗證碼效果，文中的示例代碼講解詳細，感興趣的小伙伴可以了解一下2022-06-06
這篇文章主要介紹了Android打包版本號設置方法,需要的朋友可以參考下2017-10-10
手機游戲，即便是休閑類的小游戲，往往也涉及大量紋理資源、音視頻資源、文件讀寫以及網(wǎng)絡通信，處理的稍有不甚就會出現(xiàn)畫面卡頓，交互不暢的情況2014-04-04
Android?Studio實現(xiàn)帶三角函數(shù)對數(shù)運算功能的高級計算器
這篇文章主要為大家詳細介紹了Android?Studio實現(xiàn)帶三角函數(shù)對數(shù)運算功能的高級計算器，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2022-05-05
這篇文章主要為大家詳細介紹了直接應用項目中的Android圖片緩存技術，簡單、方便、高效，感興趣的小伙伴們可以參考一下2016-04-04
Android實現(xiàn)取消GridView中Item選中時默認的背景色
這篇文章主要介紹了Android實現(xiàn)取消GridView中Item選中時默認的背景色,涉及Android GridView中Item屬性設置的相關技巧,需要的朋友可以參考下2016-02-02
這篇文章主要介紹了Android 圓角邊框的實現(xiàn)方式匯總的相關資料,需要的朋友可以參考下2016-03-03
本篇文章主要介紹了android中強制更新app實例代碼，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-05-05