Simple BlinkGC heap compaction.

third_party/WebKit/Source/platform/heap/ThreadState.cpp

Index: third_party/WebKit/Source/platform/heap/ThreadState.cpp
diff --git a/third_party/WebKit/Source/platform/heap/ThreadState.cpp b/third_party/WebKit/Source/platform/heap/ThreadState.cpp
index 9057cec1faf2a469839695d299c41d01ff2d33ec..097330f8d57ec9f4cabecfb0e36983e087b3180c 100644
--- a/third_party/WebKit/Source/platform/heap/ThreadState.cpp
+++ b/third_party/WebKit/Source/platform/heap/ThreadState.cpp
@@ -38,6 +38,7 @@
 #include "platform/heap/CallbackStack.h"
 #include "platform/heap/Handle.h"
 #include "platform/heap/Heap.h"
+#include "platform/heap/HeapCompact.h"
 #include "platform/heap/PagePool.h"
 #include "platform/heap/SafePoint.h"
 #include "platform/heap/Visitor.h"
@@ -1034,12 +1035,54 @@ void ThreadState::flushHeapDoesNotContainCacheIfNeeded() {
 }
 
 void ThreadState::makeConsistentForGC() {
+  if (isMainThread()) {
+    // For the main thread, report heap + freelist residency to the
+    // heap compactor. It uses the data to determine if compactions
+    // is now worthwhile for one or more of the sub heaps/arenas it can
+    // compact.
+    size_t heapSize = 0;
+    size_t freeSize = 0;
+    using Residency = std::pair<size_t, size_t>;
+    Vector<Residency> residencies;
+    NormalPageArena* arena;
+    for (int i = BlinkGC::Vector1ArenaIndex; i <= BlinkGC::HashTableArenaIndex;
+         ++i) {
+      arena = static_cast<NormalPageArena*>(m_arenas[i]);
+      heapSize += arena->arenaSize();
+      freeSize += arena->freeListSize();
+      residencies.append(Residency(arena->arenaSize(), arena->freeListSize()));
+    }
+    heap().compaction()->setHeapResidency(heapSize, freeSize, residencies);
+  }
   ASSERT(isInGC());
   TRACE_EVENT0("blink_gc", "ThreadState::makeConsistentForGC");
   for (int i = 0; i < BlinkGC::NumberOfArenas; ++i)
     m_arenas[i]->makeConsistentForGC();
 }
 
+void ThreadState::compact() {
+  if (!heap().compaction()->isCompacting())
+    return;
+
+  // Compaction is done eagerly and before the mutator threads get
+  // to run again. Doing it lazily is problematic, as the mutator's
+  // references to live objects could suddenly be invalidated by
+  // compaction of a page/heap. We do know all the references to
+  // the relocating objects just after marking, but won't later.
+  // (e.g., stack references could have been created, new objects
+  // created which refer to old collection objects, and so on.)
+  //
+  heap().compaction()->startCompacting(this);
+  // TODO: implement bail out wrt any overall deadline, not
+  // compacting heaps if the time budget has been exceeded.
+  static_cast<NormalPageArena*>(m_arenas[BlinkGC::HashTableArenaIndex])
+      ->sweepCompact();
+  for (int i = BlinkGC::Vector1ArenaIndex; i <= BlinkGC::InlineVectorArenaIndex;
+       ++i)
+    static_cast<NormalPageArena*>(m_arenas[i])->sweepCompact();
+  heap().compaction()->finishedCompacting(this);
+}
+
 void ThreadState::makeConsistentForMutator() {
   ASSERT(isInGC());
   for (int i = 0; i < BlinkGC::NumberOfArenas; ++i)
@@ -1123,9 +1166,12 @@ void ThreadState::preSweep() {
 
   eagerSweep();
 
+  compact();

[haraken, 2016/11/30 06:29:53]

- Is there any reason you put compact() after pre-finalization and eager
sweeping? I'm just curious.

- As I mentioned in the doc, it's (at least theoretically) unsafe to do a
compaction in preSweep() because other threads may already be accessing the heap
collections we're compacting right now. To prevent the risk, we need to do the
compaction during the stop-the-world phase. (Note that other threads cannot
obtain a CrossThreadPersistent while some thread is in the stop-the-world
phase.) So we want to move the heap compaction to postGC(), but we cannot easily
do that because the heap compaction must run after the thread-local weak
processing. Is my understanding correct?

- Once we finish shipping the per-thread heap, we no longer need the
thread-local weak processing because everything runs on the single thread. Will
it simplify your things?

[sof, 2016/11/30 06:52:44]

I had stability problems doing it a step or two earlier here, I'm fairly sure -
but I can't recall the details just now.
Yes, quite right it is - other threads shouldn't be able to view an arena that's
in the process of being compacted.

I haven't seen it manifest itself as a problem, but having the per-thread
signalling of "i've finished compacting" also synchronize the thread, would be
one place to address this problem.
Potentially, but I do wonder/worry how per-thread collection will interact with
cross-thread persistents referring to compactable & movable objects.

[haraken, 2016/11/30 07:09:49]

BTW, do you know why we need to run the heap compaction after the thread-local
weak processing? What happens if we simply move the heap compaction to postGC()?
The cross-thread heap collection must go through a CrossThreadPersistent. The
CrossThreadPersistent::get() needs to acquire a lock. The lock cannot be
acquired while some thread is doing a GC.

In any case, it will take a couple of more time to finish shipping the
per-thread heap, so we shouldn't rely on the per-thread heap.

[sof, 2016/11/30 07:26:38]

We cannot run compaction before the liveness of the (weak) objects have been
determined (and all fixups registered). What if a weak object will become alive,
point to others that will etc.
That could be done, cross-thread persistents aren't meant for fine-grained &
often use, but would "read only" access of a cross-thread heap object be
problematic without compaction, while a per-thread GC runs?

[haraken, 2016/11/30 08:51:19]

The liveness should have been determined by the end of the stop-the-world phase,
right? The thread-local weak processing is already not allowed to mutate the
object graph.

Maybe the complicated thread-local weak processing on HashTable causes some
issue, but I'm not sure what it is.
Would it be an option to make the read-only access acquire the lock as well?
Before talking about cross-thread heap collections, it's already dangerous to
let one thread access cross-thread things while the other thread is running a
GC.

[sof, 2016/11/30 09:22:14]

Yes, could do that then also. I don't know if you had planned to insist on doing
this already, or if this would be a new requirement to support a "movable" GC.

[sof, 2016/11/30 10:47:41]

Ah, now I remember the issue: if you finalize container objects before
prefinalizers or eager sweeping have run, you upset the expect finalization
ordering -- none of these can now access collections about to be swept, which
they previously could.

+
 #if defined(ADDRESS_SANITIZER)
   poisonAllHeaps();
 #endif
+
   if (previousGCState == EagerSweepScheduled) {
     // Eager sweeping should happen only in testing.
     completeSweep();
@@ -1685,6 +1731,9 @@ void ThreadState::collectGarbage(BlinkGC::StackState stackState,
   if (!parkThreadsScope.parkThreads())
     return;
 
+  heap().compaction()->checkIfCompacting(&heap(), visitor.get(), gcType,
+                                         reason);
+
   ScriptForbiddenIfMainThreadScope scriptForbidden;
 
   TRACE_EVENT2("blink_gc,devtools.timeline", "BlinkGCMarking", "lazySweeping",