Solidify GC triggering and reporting

Ensure that multiple roughly simultaneous collection requests are
unlikely to result in multiple GCs. Previously multiple direct calls
to CollectGarbageInternal would essentially be queued, with each
waiting for the previous one to complete. This might happen if we're
essentially out of memory, with multiple threads running.

Whenever easily possible, capture the GC number before checking
whether we should GC, so that we can corrrectly check for a GC
triggered since we performed the test.

Reset GC cause when appropriate so HeapTrim doesn't always show
up as the cause.

Update old_native_bytes_allocated before FinishGC(), closing the
window during which we could decide to start a second native-triggered
GC without having seen the effect of the first.

No longer support ConcurrentGC() calls from VMRuntime, since they
weren't safe anyway.

No longer mark the GC following a WaitForGCToComplete triggered by
native allocation as blocking. That wait just waits for the previous
GC and does not trigger a new one. We already marked the previous
one as blocking.

Have CheckGCForNative sleep briefly if the GC it's waiting for
hasn't started yet. Previously it waited for a running GC to finish,
but the requested one may not yet have started by then.

Drive-by fix for TotalBytesAllocated() metric.

Test: Build and boot AOSP. Manually check GC log messages.
Bug: 181351667
Change-Id: Ifd1e4afdffca7de25844d49299d552fce44b6760

0 files changed, 0 insertions, 0 deletions