Zygote: Restrict slave mountspace so Dalvik apps can mount system-wide volumes

Android 4.2 implements multi-user storage using per-process mount
namespaces.  Originally, everything under "/" (the entire filesystem
hierarchy) is marked as a recursive-slave mountspace for all zygote
instances.  This is done so that user-storage sandbox mounts under
/storage/emulated are hidden from other apps and users.

Unfortunately this means that any Dalvik app (actually, any program whose
clone/fork ancestry includes a Dalvik zygote, which is everything except
services spawned directly from init) cannot mount system-wide volumes.
Thus, apps like CifsManager are effectively broken in Android 4.2, since
its cifs mounts are only visible to the CifsManager app itself.  All other
apps see empty mountpoints instead of the mounted volume.  Furthermore,
Linux provides no provision for a process to "escape" a recursive-slave
mountspace in versions prior to Linux 3.8 (setns syscall).

Here, we restrict the slave mountspace to /storage (and, due to a possible
kernel bug, /mnt/shell/emulated) so that Dalvik apps can mount system-wide
volumes elsewhere (with appropriate permission, as in earlier versions of
Android), while retaining full multi-user storage compatibility.

This change requires that a tmpfs volume is mounted as /storage in init.rc.
If this volume is unavailable, then Zygote falls back to the previous
behavior of marking the entire filesystem hierarchy as slave.  It also
implicitly requires that EMULATED_STORAGE_TARGET is path-prefixed by (part
of the subhierarchy of) ANDROID_STORAGE, which is the typical case.
dalvik: squashed JIT improvements

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