"External allocation" tracking for direct buffers.
The native memory allocated for ByteBuffer.allocateDirect was not being
tracked by the VM's "external allocation" mechanism. This adds the
necessary calls to the Harmony OSMemory allocator, which is what
actually calls malloc().
The external alloc stuff just takes size values, so we tuck a copy of
the allocation size into the allocated block, and pull it out when it's
time to free the memory.
(Includes in a couple of other changes that I had to commit somewhere so
I could sync.)
diff --git a/vm/Thread.c b/vm/Thread.c
index ae81230..ad7c4b6 100644
--- a/vm/Thread.c
+++ b/vm/Thread.c
@@ -530,8 +530,8 @@
* Could be that a resume-all is in progress, and something
* grabbed the CPU when the wakeup was broadcast. The thread
* performing the resume hasn't had a chance to release the
- * thread suspend lock. (Should no longer be an issue --
- * we now release before broadcast.)
+ * thread suspend lock. (We release before the broadcast,
+ * so this should be a narrow window.)
*
* Could be we hit the window as a suspend was started,
* and the lock has been grabbed but the suspend counts
@@ -622,6 +622,7 @@
LOGI("threadid=%d: killing leftover daemon threadid=%d [TODO]\n",
self->threadId, target->threadId);
+ LOGI(" name='%s'\n", dvmGetThreadName(target));
// TODO: suspend and/or kill the thread
// (at the very least, we can "rescind their JNI privileges")