Work around a dalvik JDWP/GC deadlock.

Also add a few missing TEMP_FAILURE_RETRYs that can cause dalvik to
incorrectly decide that the debugger connection has been broken.

Bug: 8191824
Change-Id: I791b514c6bec1ca634a65d9f87c5fa06da01b5ed
Dump native stacks for all threads in native code.

Bug: 7432159
Change-Id: I83cb530155edfc35ae3be0f7a2a044245223d2d5
Harden the native stack dumping decision.

We've seen monkey crashes in this code, though I haven't been
able to reproduce them in my own SIGQUIT stress tests. Address
the two most likely causes of trouble: dumping the signal catcher's
own thread (which will always be runnable), and assuming that the
Method* pulled from the save area is non-NULL.

Bug: 8596028
Change-Id: I59d1dcb2264a774d8416d50a5f77a06c70d37c59
More native stack dump hardening.

Threads just starting up or shutting down might not have any managed
stack frames, leading to a NULL "currFrame" frame pointer in the
interpreter stack.

Bug: 8596028
Change-Id: Ie24c8d5f8e78a5abe882a9e639046c03abb91649
Fix some leaks in VfyBasicBlock & BitVector.

Change-Id: I20050135588fc96268911b8ab690b04c8ad949bc
GC triggering performance optimizations

Copy the correct starting heap size at process init.
Interfaces to set GC/managed heap parameters.

Change-Id: I1080ba60ae64d546c0f35925bc7c931b89c7600b
JIT: Performance fix for const doubles

Some recent Arm processors take a performance hit when
creating a floating point double by loading it as a pair of singles.
Legacy code to support soft floating point doubles as a pair of core
registers loaded double immediates in this way.

With the CL, we handle double immediates as a single unit.

(cherry-pick of c8129911e598ad0ca8d7b31012444ab6ce8bce45.)

Change-Id: Ic1512e34bfd233a6f5ffd58ce843965adbbad875
Fix JIT bug related to immediate doubles

Change 256211 (JIT: Performance Fix for const doubles) introduced a
defect that can cause the JIT to use the wrong floating point
double constant in traces in which the following conditions hold:

   o Two (or more) different 64-bit floating point constants are used.
   o The physical register holding the first constant is still live
     at the time the second constant is used.
   o The low 32 bits of the two constants are identical.

In this situation, the load/copy optimization pass will incorrectly
determine that the two constants are the same, delete the load of
the second constant and re-use the first constant value.

Note: this problem only occurs with 64-bit floating point literals.
64-bit long literals are unaffected.

This CL works around the problem, and a subsequent CL will rework
disambiguation of 64-bit immediates in a somewhat cleaner fashion.

(cherry-pick of c1757a6deab0ca0bfd42c38612d92b2f26c41dbe.)

Change-Id: I795b4b753550d2745cbbdd83ae25f4a7088990f6
Fix JIT initialization race

See b/8767735 Slow thread in thread spin test

A race exists in thread creation/JIT initialization that can
leave the JIT permanantly disabled for a thread (typically
the first interpreter thread).

(cherry-pick of 67985d960f5c877f86d0bba251d2d55c7a062b8d.)

Change-Id: Ic7e3a1cde2833ac78455fa5d465156b5e0896fc1