dalvik/libdex: Don't reduce optimization level to -O2

Don't reduce optimization level to -O2: It's sufficient to disable
function inlining

Change-Id: Ie6d9978cf0bf0e49cfa296c09c4eba913f22c303
Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer@linaro.org>
Change dalvik script to use exec

Change-Id: I0a82ced8ce31ae0e6916509a1c79b738c475ae18
Optimize those StrictMath routines that are identical to Math routines.

We can just use the existing Math intinsics.

Bug: 7146208
Change-Id: I9e78d33cf65a5dcc5a7c0133e67bd9c3c1e43f23
Fix reporting of initial pause time

The "rootEnd" time was being captured before dvmClearCardTable()
was called.

Bug 5567332

Change-Id: I5499f1648c3e41296c18fa5d95d834c2d2853e8f
Report GC pause times more accurately.

Include the time that it actually took to pause or suspend
threads in the reported time.

Also report the amount of time that other threads spend blocked
waiting for a concurrent GC to complete.

Change-Id: I80af351c2dc3171fc7db48dbbb361f3d92bbca80
Don't log "WAIT_FOR_CONCURRENT_GC blocked 0ms".

Stupid to spend more time logging than we spent waiting. (Highly visible
in the zygote's preloading phase.)

Change-Id: If2d6b6093b3bebae0887aa385745b7ed9225216b
Fix for 6994917: GC is slower per FrameworkPerf test

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
Fix an ugly bug where try/catch offsets weren't being mapped properly.

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
Fix a bug where the max blowup of annotations was incorrect.

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
Fix a bug where debugInfos' size wasn't being computed.

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
Use 0xde as the poison value after JIT code cache reset.

(cherry-pick of 60497bbcee68d98b2bdcb3fb64682b00d61b942d.)

Change-Id: I4f8c1bac2ac3bdc1d931e91f3e2e8038fe4c2b5a