| c54e12a413e16f90526318f1f466a900a717fbb0 |
|
15-Oct-2014 |
Mathieu Chartier <mathieuc@google.com> |
Change MemMap::maps_ to not be global variable
Runtime.exit() was causing globals to get destructed at the same time
that another thread was using it for allocating a new mem map.
(cherry picked from commit 6e88ef6b604a7a945a466784580c42e6554c1289)
Bug: 17962201
Change-Id: I400cb7b8141d858f3c08a6fe59a02838c04c6962
|
| 5369c40f75fdcb1be7a7c06db212ce965c83a164 |
|
25-Aug-2014 |
Mathieu Chartier <mathieuc@google.com> |
Add native memory accounting through custom allocator.
Added a custom allocator that lets you pass in a special tag which
specifices where the allocation came from. This is used when
dumping. The performance overhead is low since each allocation only
does a atomic add/sub for each allocation/free.
The measurements are dumped to traces.txt during SIGQUIT.
Example output:
I/art (27274): AllocatorTagHeap active=120 max=120 total=168
I/art (27274): AllocatorTagMonitorList active=1572 max=6240 total=11724
I/art (27274): AllocatorTagClassTable active=185208 max=185208 total=268608
I/art (27274): AllocatorTagInternTable active=430368 max=430368 total=436080
I/art (27274): AllocatorTagMaps active=5616 max=6168 total=34392
I/art (27274): AllocatorTagLOS active=1024 max=1536 total=2044
I/art (27274): AllocatorTagSafeMap active=0 max=51936 total=533688
I/art (27274): AllocatorTagLOSMaps active=144 max=1248 total=5760
I/art (27274): AllocatorTagReferenceTable active=10944 max=11840 total=19136
I/art (27274): AllocatorTagHeapBitmap active=32 max=40 total=56
I/art (27274): AllocatorTagHeapBitmapLOS active=8 max=8 total=8
I/art (27274): AllocatorTagVerifier active=0 max=18844 total=1073156
I/art (27274): AllocatorTagModUnionCardSet active=5300 max=5920 total=56020
I/art (27274): AllocatorTagModUnionReferenceArray active=24864 max=24864 total=24864
I/art (27274): AllocatorTagJNILibrarires active=320 max=320 total=320
I/art (27274): AllocatorTagOatFile active=1400 max=1400 total=5852
Bug: 16238192
Change-Id: Ibb470ef2e9c9a24563bb46422d46a55799704d82
|
| 9660918229e895c4d6c4c361fd84a75abc683de0 |
|
21-Aug-2014 |
Narayan Kamath <narayan@google.com> |
Make a couple of map checks debug only.
This cost us close to 80ms in app startup times.
The checks that a reused region was within an already
existent map has been demoted to a debug check.
A couple of other negative checks have been removed
outright because one of them was superflous and the other
wasn't guaranteed to be correct.
bug: 16828525
Change-Id: I00f76de06df0ea4ced40fdcb7825248d4b662045
|
| bddaea2b88b0a19d9cc7a4dea772af8e829323b3 |
|
21-Aug-2014 |
Narayan Kamath <narayan@google.com> |
Make a couple of map checks debug only.
This cost us close to 80ms in app startup times.
The checks that a reused region was within an already
existent map has been demoted to a debug check.
A couple of other negative checks have been removed
outright because one of them was superflous and the other
wasn't guaranteed to be correct.
bug: 16828525
Change-Id: I00f76de06df0ea4ced40fdcb7825248d4b662045
|
| ac304133ab4b988777bcc5ad12257cbb99c3871e |
|
28-Apr-2014 |
Jim_Guo <jim_guo@htc.com> |
ART: Fix memory unmapped twice issue in ElfFile::Load(bool)
Root Cause:
The overlapped memory region will be unmapped by
(1) ~MemMap() of reservation MemMap (reserve) and
(2) ~MemMap() of "reuse" MemMap (segment).
Someone takes the memory region after (1) and it will be unmapped in (2).
So, SIGSEGV occurs when using the unmapped memory region.
Solution:
Fixes this issue by skip unmap "reuse" MemMap in destructor.
And always create reservation MemMap before "reuse" MemMap. (It also solved
the fixupELF case which does not reserve the whole needed memory region).
Bug: 16486685
(cherry picked from commit a62a588a9202f69e53fbeb3045ea8ea5ec2587f8)
Change-Id: Icb83c8e87fa168027d9d8adb34925000399d3d2a
|
| a62a588a9202f69e53fbeb3045ea8ea5ec2587f8 |
|
28-Apr-2014 |
Jim_Guo <jim_guo@htc.com> |
ART: Fix memory unmapped twice issue in ElfFile::Load(bool)
Root Cause:
The overlapped memory region will be unmapped by
(1) ~MemMap() of reservation MemMap (reserve) and
(2) ~MemMap() of "reuse" MemMap (segment).
Someone takes the memory region after (1) and it will be unmapped in (2).
So, SIGSEGV occurs when using the unmapped memory region.
Solution:
Fixes this issue by skip unmap "reuse" MemMap in destructor.
And always create reservation MemMap before "reuse" MemMap. (It also solved
the fixupELF case which does not reserve the whole needed memory region).
Bug: 16486685
Change-Id: I8f2538861d5c3fa7b9a04d2c3f516319cc060291
|
| c3ccc1039e0bbc0744f958cb8719cf96bce5b853 |
|
25-Jun-2014 |
Ian Rogers <irogers@google.com> |
Fix the Mac build on x86-64.
Change-Id: I4ed3783a96d844de0b0a295df26d0a48c02a3726
|
| c5f17732d8144491c642776b6b48c85dfadf4b52 |
|
06-Jun-2014 |
Ian Rogers <irogers@google.com> |
Remove deprecated WITH_HOST_DALVIK.
Bug: 13751317
Fix the Mac build:
- disable x86 selector removal that causes OS/X 10.9 kernel panics,
- madvise don't need does zero memory on the Mac, factor into MemMap
routine,
- switch to the elf.h in elfutils to avoid Linux kernel dependencies,
- we can't rely on exclusive_owner_ being available from other pthread
libraries so maintain our own when futexes aren't available (we
can't rely on the OS/X 10.8 hack any more),
- fix symbol naming in assembly code,
- work around C library differences,
- disable backtrace in DumpNativeStack to avoid a broken libbacktrace
dependency,
- disable main thread signal handling logic,
- align the stack in stub_test,
- use $(HOST_SHLIB_SUFFIX) rather than .so in host make file variables.
Not all host tests are passing on the Mac with this change. dex2oat
works as does running HelloWorld.
Change-Id: I5a232aedfb2028524d49daa6397a8e60f3ee40d3
|
| 3eed93dd5be03e5539827bebf0f414251a12e15e |
|
04-Jun-2014 |
Hiroshi Yamauchi <yamauchi@google.com> |
Verify there's no mem map gap for immune region not to break.
This adds code that verifies that there's no memory map gap between
the image space and the main space so that the immune region
functionality won't silently break. For example, if there's a gap and
a large object is allocated in that gap, the large object is
incorrectly part of the immune region and the marking breaks.
Bug: 14059466
Change-Id: Ie6ed82988d74b6d0562ebbbaac96ee43c15b14a6
|
| d8f26dbebe72c1cbdfa85bdeeb003283c7435db3 |
|
20-May-2014 |
Andreas Gampe <agampe@google.com> |
ART: Randomize mem_map start address for linear scan search
When using linear scan for mem_map, randomize the start of the
search with getauxval(AT_RANDOM).
Change-Id: Id1e4c86b928147d74b9b0b73ff704de5d87b4500
|
| 8dba5aaaffc0bc2b2580bf02f0d9095c00d26a17 |
|
12-Mar-2014 |
Stuart Monteith <stuart.monteith@arm.com> |
AArch64: Add memory allocation in low 4GB
MAP_32BIT is implemented for only x86_64. Other 64bit platforms
don't have an equivalent.
This is a unsophisticated implemention of a scheme using msync and
MAP_FIXED to reproduce the functionality of MAP_32BIT.
Adds MAP_FIXED to RemapAtEnd, as the address used for the new mmap
doesn't get located correctly without it on aarch64.
Add MemMap::next_mem_pos_ to store last position. Add a safety assert.
Change-Id: I61871ff7fc327554c43e1d7f448c3d376490f1ea
|
| ef7d42fca18c16fbaf103822ad16f23246e2905d |
|
06-Jan-2014 |
Ian Rogers <irogers@google.com> |
Object model changes to support 64bit.
Modify mirror objects so that references between them use an ObjectReference
value type rather than an Object* so that functionality to compress larger
references can be captured in the ObjectRefererence implementation.
ObjectReferences are 32bit and all other aspects of object layout remain as
they are currently.
Expand fields in objects holding pointers so they can hold 64bit pointers. Its
expected the size of these will come down by improving where we hold compiler
meta-data.
Stub out x86_64 architecture specific runtime implementation.
Modify OutputStream so that reads and writes are of unsigned quantities.
Make the use of portable or quick code more explicit.
Templatize AtomicInteger to support more than just int32_t as a type.
Add missing, and fix issues relating to, missing annotalysis information on the
mutator lock.
Refactor and share implementations for array copy between System and uses
elsewhere in the runtime.
Fix numerous 64bit build issues.
Change-Id: I1a5694c251a42c9eff71084dfdd4b51fff716822
|
| b60847e72d040bf5e08b787d4b63708f7a506a31 |
|
06-Feb-2014 |
Brian Carlstrom <bdc@google.com> |
Merge "Fix apps with more than one dex file with the same name"
|
| 0d6adac2550113da33d42e88f0d87a57b25c5a60 |
|
06-Feb-2014 |
Brian Carlstrom <bdc@google.com> |
Fix apps with more than one dex file with the same name
Reverts most of 60836d5a9bcf8b30984aae4279a4f6233b0bf622 which I
believe was an incorrect attempt to address issue introduced in
8d31bbd3d6536de12bc20e3d29cfe03fe848f9da, which is also reverted here.
Also adds some debugging aids include operator<< for DexFile and
MemMap and checksum information to OatFile logging.
Bug: 12802375
Change-Id: Idd6f7dd487f6e01e9479cd15cd4b61580160e8a3
|
| fd7e7f1253927c8d7f17e7cbc259daaf51868bd3 |
|
22-Oct-2013 |
Hiroshi Yamauchi <yamauchi@google.com> |
Fix a double unmap issue in MemMap::UnMapAtEnd().
MemMap::UnMapAtEnd() unmaps the unused tail of the alloc space during
a zygote fork. But it can cause the same tail region of the memory to
be unmapped twice (once in UnMapAtEnd() and once more in ~MemMap()
during a shutdown.)
I encountered a crash because of this issue in SpaceTest.ZygoteTest
(which happens to happen only on a device in a branch with the
rosalloc change probably due to some randomness in mmap address
choice, etc.)
Here's what happens:
1) CreateZygoteSpace() will call UnMapAtEnd() and unmap the unused
tail of the alloc space.
2) In the same function, after UnMapAtEnd(), several libc new/malloc
allocations, including a new DlMallocSpace object, happen. This
happens to cause libc to map a new memory region that overlaps with
the memory region that has just been unmapped in 1) and use it to
allocate those allocations (that is, the new DlMallocSpace object is
allocated in that memory region.) This is a second DlMallocSpace that
becomes the new alloc space after zygote fork. The first DlMallocSpace
becomes the zygote space. Note that that libc maps that memory region
before the underlying memory of the second DlMallocSpace is mapped.
3) During a Runtime shutdown (which happens once for a normal VM
shutdown or at the end of each test run) all the spaces get destructed
including the the two DlMallocSpaces one by one. When the first
DlMallocSpace gets destructed (note the space list is sorted by
address,) its super destructor ~MemMap() unmaps the original memory
region that's already partially unmapped in 2). Now this memory region
includes the libc memory region that includes the second DlMallocSpace
object.
4) When the second DlMallocSpace object gets attempted to be
destructed, the memory in which the object resides is already unmapped
in 3) and causes a SIGSEGV.
This change replaces UnMapAtEnd() with a new function RemapAtEnd()
which combines the unmapping of the tail region and remapping of it to
achieve the following two things:
1) Fixes this double unmap issue by updating the base_size_ member
variable to exclude the already-unmapped tail region so that ~MemMap()
will not unmap the tail region again.
2) Improves on the non-atomicity issue in the unmap/map sequence in
CreateZygoteSpace(). That is, once the unused tail portion of the
memory region of the origina alloc space is unmapped, something like
libc could come along and take that memory region, before the memory
region is mapped again for the new alloc space. This, as a result,
would make a hole between the old alloc (new zygote) space and the new
alloc space and cause the two spaces to be
non-contiguous. RemapAtEnd() eliminates new/malloc allocations between
the unmap and the map calls. But note this still isn't perfect as
other threads could in theory take the memory region between the
munmap and the mmap calls.
Added tests.
Change-Id: I43bc3a33a2cbfc7a092890312e34aa5285384589
|
| 8d31bbd3d6536de12bc20e3d29cfe03fe848f9da |
|
13-Oct-2013 |
Ian Rogers <irogers@google.com> |
Throw IOException at source of failing to open a dex file.
Before is:
java.lang.ClassNotFoundException: Didn't find class "GCBench" on path: DexPathList[[zip file "/disk2/dalvik-dev/out/host/linux-x86/framework/GCBench.jar"],nativeLibraryDirectories=[/disk2/dalvik-dev/out/host/linux-x86/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
Suppressed: java.lang.ClassNotFoundException: GCBench
at java.lang.Class.classForName(Native Method)
at java.lang.BootClassLoader.findClass(ClassLoader.java:781)
at java.lang.BootClassLoader.loadClass(ClassLoader.java:841)
at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
... 1 more
Caused by: java.lang.NoClassDefFoundError: Class "LGCBench;" not found
... 5 more
And after is:
java.lang.ClassNotFoundException: Didn't find class "GCBench" on path: DexPathList[[zip file "/disk2/dalvik-dev/out/host/linux-x86/framework/GCBench.jar"],nativeLibraryDirectories=[/disk2/dalvik-dev/out/host/linux-x86/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
Suppressed: java.io.IOException: Zip archive '/disk2/dalvik-dev/out/host/linux-x86/framework/GCBench.jar' doesn't contain classes.dex
at dalvik.system.DexFile.openDexFile(Native Method)
at dalvik.system.DexFile.<init>(DexFile.java:80)
at dalvik.system.DexFile.<init>(DexFile.java:59)
at dalvik.system.DexPathList.loadDexFile(DexPathList.java:268)
at dalvik.system.DexPathList.makeDexElements(DexPathList.java:235)
at dalvik.system.DexPathList.<init>(DexPathList.java:113)
at dalvik.system.BaseDexClassLoader.<init>(BaseDexClassLoader.java:48)
at dalvik.system.PathClassLoader.<init>(PathClassLoader.java:38)
at java.lang.ClassLoader.createSystemClassLoader(ClassLoader.java:128)
at java.lang.ClassLoader.access$000(ClassLoader.java:65)
at java.lang.ClassLoader$SystemClassLoader.<clinit>(ClassLoader.java:81)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:137)
Suppressed: java.lang.ClassNotFoundException: GCBench
at java.lang.Class.classForName(Native Method)
at java.lang.BootClassLoader.findClass(ClassLoader.java:781)
at java.lang.BootClassLoader.loadClass(ClassLoader.java:841)
at java.lang.ClassLoader.loadClass(ClassLoader.java:504)
... 1 more
Caused by: java.lang.NoClassDefFoundError: Class "LGCBench;" not found
... 5 more
Also, move dex file verifier messages out of logs.
In the process the ClassLinker::dex_lock_ needed tidying to cover a smaller
scope. Bug 11301553.
Change-Id: I80058652e11e7ea63457cc01a0cb48afe1c15543
|
| e0948e13d5a4552e6a2728087573c07961e4a4f9 |
|
29-Aug-2013 |
Brian Carlstrom <bdc@google.com> |
Make DexFiles opened from files readonly by default, but writable during dex2oat
Bug: 9618388
Change-Id: I83f2e16ee8446a79a94a84971146d807bb0c9ee0
|
| fc0e3219edc9a5bf81b166e82fd5db2796eb6a0d |
|
17-Jul-2013 |
Brian Carlstrom <bdc@google.com> |
Fix multiple inclusion guards to match new pathnames
Change-Id: Id7735be1d75bc315733b1773fba45c1deb8ace43
|
| 7940e44f4517de5e2634a7e07d58d0fb26160513 |
|
12-Jul-2013 |
Brian Carlstrom <bdc@google.com> |
Create separate Android.mk for main build targets
The runtime, compiler, dex2oat, and oatdump now are in seperate trees
to prevent dependency creep. They can now be individually built
without rebuilding the rest of the art projects. dalvikvm and jdwpspy
were already this way. Builds in the art directory should behave as
before, building everything including tests.
Change-Id: Ic6b1151e5ed0f823c3dd301afd2b13eb2d8feb81
|