Mostly precise GC #726

LukasKellenberger · 2017-05-20T10:52:39Z

Prototype of a Mark-Region Garbage Collector.

Todo:

Handle stack overflow
Automatically resize heap

densh · 2017-05-20T12:22:07Z

🎉Woohooo! 🎉

If anyone is interested in how it works, it's a clean-room implementation based on the "Immix: a mark-region garbage collector with space efficiency, fast collection, and mutator performance" paper and there is also talk from the authors available online.

We are going to talk more about this in detail at ScalaDays CPH.

Note: this is an intended fix for #128.

densh · 2017-05-21T09:33:52Z

@LukasKellenberger, please reformat using new bin/clangfmt script from #632.

fgoepel · 2017-05-21T11:23:56Z

What pause times should be expected with this new GC? From the paper it looks like they focussed mainly on throughput. Although I also found another paper that suggests that there are low-latency GC designs based on Immix.

I assume that JVM Scala is likely to stay the better option if maximum throughput is desired, so it might be a smart play to ensure Scala Native is suitable for realtime applications. (Go also seems to have made great strides towards this with their GC improvements.)

densh · 2017-05-21T17:45:02Z

@shado23 As you correctly noticed, immix itself doesn't aim at addressing the issue of GC pause times. Primary motivation for it right now it to improve throughput performance on GC-heavy workloads. Current prototype fully achieves this goal, providing a major improvement on our benchmarks.

Solving GC pause times is the next step after this, but it fundamentally depends on having a good tracing collector to start with. Typical solution for this problem is to make your existing collector to run concurrently with the application utilizing a separate thread for the garbage collection.

densh

First pass.

densh · 2017-05-22T10:04:59Z

nativelib/src/main/resources/gc/immix/ImmixGC.c

+
+void scalanative_collect() { Heap_collect(heap, stack); }
+
+void scalanative_safepoint() {}


Given that this is not used for now in any way, lets move the definition of the safepoint implementation in the safepoint.c, not to duplicate it in every GC implementation.

densh · 2017-05-22T10:08:27Z

nativelib/src/main/resources/gc/immix/ImmixGC.c

+    void **alloc = (void **)Heap_allocLarge(heap, size);
+    *alloc = info;
+    return (void *)alloc;
+}


It seems like our allocation entry points are slowly getting out of hand here. We really need a doc page in the contributors guide section that explains a bit more about compiler/gc interface. This should list all of the supported allocation entry points, their signatures, and expected behavior.

More specifically I'd only leave three allocation entry points:

scalanative_alloc_small

scalanative_alloc_large

scalanative_alloc_atomic

Leaving out the raw version altogether (it's an artifact of Boehm GC.)

The scalanative_alloc_raw is used for arrays. This would mean that we need to change the allocation of array to choose the correct function depending on the size.

densh · 2017-05-22T10:09:16Z

nativelib/src/main/resources/gc/immix/ImmixGC.c

+
+void *scalanative_alloc_raw_atomic(size_t size) {
+    return scalanative_alloc_raw(size);
+}


This one is used in the java library quite a bit without any RTTI in the start of the object. I'm pretty sure that this is unsound at the moment.

An obvious solution would be to use an RTTI of an Object class and return a pointer 1 word past the RTTI. But this would fall apart if the pointer gets stored somewhere as we only support inner pointers for stack to heap references, but not for heap to heap references, don't we?

Yes that's correct, everywhere apart from the stack, pointers are assumed to point on rtti.

densh · 2017-05-22T10:10:30Z

nativelib/src/main/resources/gc/immix/ImmixGC.c

+    return (void *)alloc;
+}
+
+void *scalanative_alloc_large(void *info, size_t size) {


We need to have a precise definition of large in the docs.

We need an assert that object is large here.

Where should we document this ? Is there documentation about the GC interface ?

We need to create a new page for this. E.g. docs/contrib/gc.rst.

densh · 2017-05-22T10:11:54Z

nativelib/src/main/resources/gc/immix/ImmixGC.c

+    return scalanative_alloc_raw(size);
+}
+
+void *scalanative_alloc(void *info, size_t size) {


Given it calls to allocSmall in the implementation, the more appropriate name for this one is scalanative_alloc_small. Also needs an assert that size is indeed small.

densh · 2017-05-22T11:00:52Z

nativelib/src/main/resources/gc/immix/headers/ObjectHeader.h

+#include "../Log.h"
+
+typedef enum {
+    object_forward = 0x0,


This doesn't seem to be used at the moment, I assume that's the state you set for objects that are being evacuated to a different location?

Yes, this flag will be used for evacuation during the marking phase.

densh · 2017-05-22T11:02:05Z

nativelib/src/main/resources/gc/immix/Marker.h

+#include "Heap.h"
+#include "datastructures/Stack.h"
+
+void Mark_roots(Heap *heap, Stack *stack);


Marker_markRoots.

densh · 2017-05-22T11:02:23Z

nativelib/src/main/resources/gc/immix/Marker.c

+    markModules(heap, stack);
+
+    mark(heap, stack);
+}


This file has quite a few naming convention violations.

densh · 2017-05-22T11:03:41Z

nativelib/src/main/resources/gc/immix/Heap.h

+static inline bool heap_isWordInHeap(Heap *heap, word_t *word) {
+    return heap_isWordInSmallHeap(heap, word) ||
+           heap_isWordInLargeHeap(heap, word);
+}


Can we make sure that large and small objects heaps are adjacent in memory? This way we'll need just two bounds checks here instead of 4.

Yes and no. We can do it but it will not help. The problem being that we can map memory only once for both heaps and grow up and down. But we can have a value from the stack pointing to "unallocated heap" meaning part of memory that has been mapped but where the heaps have not grown to yet.

You're right, with growing heap this isn't going to work at all.

densh · 2017-05-22T11:13:04Z

nativelib/src/main/resources/gc/immix/Allocator.c

+    word_t *end = (word_t *)((uint8_t *)start + size);
+
+    if (end > allocator->largeLimit) {
+        // DIFFERENT FROM IMMIX


Can you elaborate on this comment? It doesn't seem to be very clear.

This comment should be removed, it's different from the mmtk code because of multithreading, the access to the global allocator needs to be synchronised.

Agreed, lets remove it.

LukasKellenberger · 2017-05-22T12:33:58Z

tools/src/main/scala/scala/scalanative/optimizer/pass/AllocLowering.scala

-        let(n, Op.Call(allocSig, alloc, Seq(cls.rtti.const, size), Next.None))
+        val size = MemoryLayout.sizeOf(cls.layout.struct)
+        val allocMethod =
+          if (size < LARGE_OBJECT_MIN_SIZE) alloc else largeAlloc


@densh Here we need the check to take into account the header of the object in the GC. The total allocated size needs to be less than 8K. But the header size can change depending on the GC. Should we add GC specific properties in compiler ?

If the compiler would know about the GC, we could also adapt the injection passes.

densh · 2017-05-25T13:44:45Z

Needs a rebase on top of master due to changes in #730 #733 #734 #737

densh · 2017-05-26T11:25:17Z

nativelib/src/main/resources/gc/immix/datastructures/Stack.h

-#define PRINT_STACK_OVERFLOW
-
-#define INITIAL_STACK_SIZE (8)
+#define INITIAL_STACK_SIZE (128 * 1024)


This seems to be really small, is this sufficient not to overflow on our benchmarks?

densh · 2017-05-26T12:43:50Z

Needs another rebase due to a bug in CI that was fixed in #744

…nd inner pointers)

densh

Naming convention changes.

densh · 2017-05-26T12:45:29Z

docs/user/sbt.rst

+    Immix is a mostly precise mark-region collector based on the paper:
+    `Immix: A Mark-Region Garbage Collector with Space Efficiency,
+     Fast Collection, and Mutator Performance
+    <http://www.cs.utexas.edu/users/speedway/DaCapo/papers/immix-pldi-2008.pdf>`_.


We can't really expect our end-users to read papers to understand what we did. Contributors maybe, but not the end-users.

densh · 2017-05-26T12:46:12Z

nativelib/src/main/resources/gc/immix/Allocator.c

+ * Updates the the cursor and the limit of the Allocator to point to the first
+ * free line of the new block.
+ */
+void firstLineNewBlock(Allocator *allocator, BlockHeader *block) {


Allocator_firstLineNewBlock.

densh · 2017-05-26T12:46:25Z

nativelib/src/main/resources/gc/immix/Allocator.c

+    }
+}
+
+bool getNextLine(Allocator *allocator) {


Allocator_getNextLine

densh · 2017-05-26T12:46:36Z

nativelib/src/main/resources/gc/immix/Allocator.c

+ * Updates the cursor and the limit of the Allocator to point the next line of
+ * the recycled block
+ */
+bool nextLineRecycled(Allocator *allocator) {


Allocator_nextLineRecycled

densh · 2017-05-26T12:46:54Z

nativelib/src/main/resources/gc/immix/Allocator.c

+ * the fast allocator is too small to fit
+ * the block to alloc.
+ */
+word_t *overflowAllocation(Allocator *allocator, size_t size) {


Allocator_overflowAllocation.

Do you want to add the module name to all functions ? I did it only for "public" (defined in .h) functions.

Yep, I think it's a good idea to add it. It helps to easily navigate the codebase without IDE.

densh · 2017-05-26T12:56:31Z