GitLab

This should allow us to differentiate between "couldn't get the
stack" and "didn't try to get the stack".  Also show the thread's
state (e.g. 'R' for running, 'D' for uninterruptible syscall).

Bug 7053953

(cherry-pick of b3667a19.)

Change-Id: I0a40cb3d3cdd9aef8589a39586cccd9c229aa8cb

(cherry-pick of 60497bbc.)

Change-Id: I4f8c1bac2ac3bdc1d931e91f3e2e8038fe4c2b5a

We can just use the existing Math intinsics.

Bug: 7146208
Change-Id: I9e78d33cf65a5dcc5a7c0133e67bd9c3c1e43f23

I'm not sure where the 1.34 number comes from but it's incorrect.
From the spec, the encoded_annotation is made up of a single byte
plus an unlimited number of uleb128 values. Each of these values
can double in width in the worst case. I received (personal) email
from one user who'd run into a case worse than the incorrect 1.34
limit.

Change-Id: I3b676e6d2b274aaa538ca61ce23945b3d49aff04

In dex files, there are several places where one object refers
to another object by its position in the file. The dex merger
is generally very careful to adjust these mappings when combining
dex files.

Unfortunately one of these cases was broken. Each try_item refers
to a corresponding encoded_catch_handler by its byte offset in a
list. Most of the time this byte offset is the same in the input
dex file and the output dex file. But encoded_catch_handlers are
variable-length because they use a variable-length uleb128 encoding
to address the type_idx being caught. When dex files are merged,
some exception types may go from having a small index to having
a large index, increasing the number of bytes required to encode
that index. This breaks our ability to directly copy over offsets
as we were doing previously.

Bug: http://code.google.com/p/android/issues/detail?id=36490
Change-Id: I3bdadf20899fdb5d4d074e69103b33c0404a31f8

dalvikvm --help would fail here:

  #0  __pthread_mutex_destroy (mutex=0x0) at pthread_mutex_destroy.c:28
  #1  0xf7b36e13 in dvmDestroyMutex (pMutex=0x0) at dalvik/vm/Thread.h:465
  #2  dvmQuasiAtomicsShutdown () at dalvik/vm/Atomic.cpp:188
  #3  0xf7b65781 in dvmShutdown () at dalvik/vm/Init.cpp:1889
  #4  0xf7b65f31 in ~ScopedShutdown (this=<synthetic pointer>, __in_chrg=<optimized out>) at dalvik/vm/Init.cpp:1317
  #5  dvmStartup (argc=11, argv=0x804b360, ignoreUnrecognized=false, pEnv=0x804b398) at dalvik/vm/Init.cpp:1548
  #6  0xf7b790e2 in JNI_CreateJavaVM (p_vm=0xffffc758, p_env=0xffffc75c, vm_args=0xffffc760) at dalvik/vm/Jni.cpp:3502
  #7  0x08048958 in main (argc=13, argv=0xffffc8b8) at dalvik/dalvikvm/Main.cpp:212

Change-Id: I8c833ca5ea454d9b2d1714a569fb728562088659

With dlmalloc 2.8.6 the compiler pragmas to suppress warnings are not
necessary.
Remove unnecessary dlmalloc dl prefix #define.

Depends upon: https://android-review.googlesource.com/42351

Change-Id: Idc45cee9342efec0aab63d5172b3308a0fca3c4f

Change-Id: I1f9813c9dc1dfc388f82f37584fe60256b6a8b12

Fixes the GC aspect of the regression in FrameworkTest for Gc.
Large bitmap test seems to be unaffected.

Changes are:
We now have minimum sleep of 1ms instead of 10ms in dvmSuspendAll.
Some heuristics to avoid doing extra GCs if an allocation waited for a concurrent Gc.

Change-Id: I3797c7dc813e26bd1f7bb0a9dbe55eb70dd1c9c9

Previously debugInfos' size of 0 caused a malformed dex file
because debug data was present but not mentioned in the table
of contents.

Change-Id: I07171aaee12fef9f303fc505909f44ef1a714114

Card scanning uses dvmHeapSourceGetValue to scan from the heap base to
the total foot print of the heap. Trimming the Zygote may lower the
footprint of the heap by creating a hole in the middle. This hole is
unaccounted for in the card scanning leading to missed dirty cards.

This was a regression introduced by:
https://android-review.googlesource.com/#/c/41728/
as it didn't #define MORECORE_CANNOT_TRIM 1 that was previously defined
here:
https://android-review.googlesource.com/#/c/41731/4/libcutils/mspace.c

Introduce a notion of dvmHeapSourceGetLimit so that card scanning
doesn't rely on footprint. Trim the heap before forking the Zygote. This
change continues to enable morecore trimming of mspaces.

Change-Id: I3f0b12371097f50a1f920cac25846ca08685e7ed

When dx generates a switch on a value in a high register, it prepends a move
instruction, to move the value to a low register. However, this causes the
switch data pseudo-instruction to use address of the move instruction as the
base address of the switch targets, rather than the address of the switch
instruction

Change-Id: I0708d35ec3059c30221cd0a64f426244411d31ea

Switch to using dlmalloc 2.8.5. Define mspace functionality directly
using dlmalloc rather than taking from libcutils.
Remove growth limit check in tryMalloc that only checks initial growth
limit.
Implement trimming at the end of the mspace.

Depends upon: https://android-review.googlesource.com/41717

Change-Id: Ia2c6b50bdb0b0d5aae4b18deefbd1bf50dfa49d5

This patch consists of:
- changes to mterp/ that turn all literals from absolute
  to PC relative, so the relocations can be resolved at
  (build) link time
- changes to compiler/template/ that result in the
  compiler templates to live in the non-executable
  .data.rel.ro section (this code is never executed
  directly, only from the jit heap, so there is no
  reason to put it in the .text section)

Change-Id: I2dc97bd4720b393a74b7277a188f0c7b681fc932
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@gmail.com>

Change-Id: Ia182af8f5ca3967a21003b3d1513145f8e6e5db0

Bug: http://code.google.com/p/android/issues/detail?id=35934
Change-Id: I7bf31f6c80c794beb3554ad2f60ed5ebbca0c65e

Bug: http://code.google.com/p/android/issues/detail?id=36003
Change-Id: I7fb53b0898158a3ad7b0eb4f8385674ddaeffd60

Change-Id: I0a82ced8ce31ae0e6916509a1c79b738c475ae18

Without the fix the compiler is still safe since the offending memory access
is a read, though the hoisted distance is non-deterministic. The easiest and
safest fix is to unconditionally hoist a load when it can reach the
scheduling barrier.

Change-Id: I021161cb2a6e011301ab65ba62bc2a74af1cb552
Signed-off-by: Douglas Leung <douglas@mips.com>

1. LOG->ALOG conversion
2. Remove Jumbo opcodes support

Change-Id: Ifbd1eae2f5e7a1cab5828ebfbdba380ad499abfd