libcorkscrew native stacks, mutex ranking, and better ScopedThreadListLock.

This change uses libcorkscrew to show native stacks for threads in kNative or,
unlike dalvikvm, kVmWait --- working on the runtime directly I've found it
somewhat useful to be able to see _which_ internal resource we're waiting on.
We can always take that back out (or make it oatexecd-only) if it turns out to
be too noisy/confusing for app developers.

This change also lets us rank mutexes and enforce -- in oatexecd -- that you
take locks in a specific order.

Both of these helped me test the third novelty: removing the heap locking from
ScopedThreadListLock. I've manually inspected all the callers and added a
ScopedHeapLock where I think one is necessary. In manual testing, this makes
jdb a lot less prone to locking us up. There still seems to be a problem with
the JDWP VirtualMachine.Resume command, but I'll look at that separately. This
is a big enough and potentially disruptive enough change already.

Change-Id: Iad974358919d0e00674662dc8a69cc65878cfb5c

1 files changed, 1 insertions, 1 deletions

diff --git a/src/hprof/hprof.cc b/src/hprof/hprof.cc
index be37207..4d5cae1 100644
--- a/src/hprof/hprof.cc
+++ b/src/hprof/hprof.cc
@@ -757,7 +757,7 @@ void HprofBitmapCallback(Object *obj, void *arg) {
  */
 int DumpHeap(const char* fileName, int fd, bool directToDdms) {
   CHECK(fileName != NULL);
-  ScopedHeapLock lock;
+  ScopedHeapLock heap_lock;
   ScopedThreadStateChange tsc(Thread::Current(), Thread::kRunnable);
 
   ThreadList* thread_list = Runtime::Current()->GetThreadList();