diff options
| author | TDYa127 <tdy@google.com> | 2012-03-24 20:21:51 -0700 |
|---|---|---|
| committer | Shih-wei Liao <sliao@google.com> | 2012-03-26 21:12:42 -0700 |
| commit | b4669208ee02f16c198eb21332701b6a0c5af278 (patch) | |
| tree | d8572216565a0daacb49958599e0a95c3b873769 | |
| parent | 8e5e9788d636f37d13d6c3f7b4050b18360f3141 (diff) | |
| download | art-b4669208ee02f16c198eb21332701b6a0c5af278.zip art-b4669208ee02f16c198eb21332701b6a0c5af278.tar.gz art-b4669208ee02f16c198eb21332701b6a0c5af278.tar.bz2 | |
Fix space_test for (USE_LLVM_COMPILER) build.
If we use libcutils, it will link bionic's dlmalloc. And we will call
bionic's init_mparams(). The init_mparams() initializes a "static"
variable, mparams. So, if we don't call ART's copy of init_mparams(), our
own mparams will not be initialized. Later, when we call
mspace_set_footprint_limit(), which only exists in ART's copy of
dlmalloc, it can not successfully set limit.
The problematic code path is as follows:
Most recent callee is:
art::Runtime::VisitRoots at art/src/runtime.cc:839
art::MarkSweep::MarkRoots at art/src/mark_sweep.cc:91
art::Heap::CollectGarbageInternal at art/src/heap.cc:581
art::Heap::AllocateLocked at art/src/heap.cc:465
art::Heap::AllocateLocked at art/src/heap.cc:421
art::Heap::AllocObject at art/src/heap.cc:281
art::Array::Alloc at art/src/object.cc:1252
art::PrimitiveArray<unsigned short>::Alloc at art/src/object.cc:1280
art::String::Alloc at art/src/object.cc:1392
art::String::AllocFromModifiedUtf8 at art/src/object.cc:1380
art::String::AllocFromModifiedUtf8 at art/src/object.cc:1375
art::InternTable::InternStrong at art/src/intern_table.cc:136
art::ClassLinker::AllocDexCache at art/src/class_linker.cc:1042
art::ClassLinker::AppendToBootClassPath at art/src/class_linker.cc:1607
art::ClassLinker::InitFromCompiler at art/src/class_linker.cc:314
art::ClassLinker::CreateFromCompiler at art/src/class_linker.cc:213
art::Runtime::Init at art/src/runtime.cc:666
art::Runtime::Create at art/src/runtime.cc:495
which is the oldest callee.
This will happen to (!USE_LLVM_COMPILER) build as well:
When creating runtime.class_linker_, it should allocate DexCache.
When initializing DexCache, it needs to allocate managed Object.
Then, when running (USE_LLVM_COMPILER) build, allocate without growth failed.
See space->AllocWithoutGrowth() at heap.cc:442.
Then, (USE_LLVM_COMPILER) build will call CollectGarbageInternal, which will call
through Runtime::VisitRoots(). VisitRoots needs class_linker. But at that time,
we are still initializing runtime::class_linker_!
In general, this could be a bug for (!USE_LLVM_COMPILER) build too, when
we need to run GC before class_linker_ is initialized.
(cherry picked from commit 8771a2fe9f5892fa4646cf50ae728f54b427356f)
Change-Id: I02b313b4153bb7ff7554aaf3d0dc760c5bdb2087
| -rw-r--r-- | build/Android.gtest.mk | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/build/Android.gtest.mk b/build/Android.gtest.mk index c85b170..790765b 100644 --- a/build/Android.gtest.mk +++ b/build/Android.gtest.mk @@ -57,7 +57,7 @@ define build-art-test ifeq ($(ART_USE_LLVM_COMPILER),true) LOCAL_C_INCLUDES += frameworks/compile/linkloader - LOCAL_STATIC_LIBRARIES += librsloader libcutils + LOCAL_STATIC_LIBRARIES += librsloader endif # Mac OS linker doesn't understand --export-dynamic. |