GC unit test infra, start adding GC tests

[osa1]

This refactors the RTS to allow testing garbage collectors and adds a simple GC
test (more tests to be implemented in a new PR).

Major changes:

• New trait Memory is introduced, with a alloc_words method for heap
  allocation.

• All allocating functions now take a generic Memory argument. Part of this
  is necessary for testing the collectors, but this also enables more testing:
  we now test more code paths in mark stack implementation.

• Copying and mark-compact GC entry points now take these arguments:

  • mem: &mut M: memory implementation
  • get_hp: callback to get heap pointer
  • set_hp: SetHp: callback to set heap pointer
  • mem_base: u32: beginning of dynamic heap
  • mem_end: u32: end of dynamic heap
  • static_roots: SkewedPtr: pointer to the static root array
  • closure_table_loc: *mut SkewedPtr: address of the closure table in
    dynamic heap

• Monomorphised versions of copying and mark-compact GC entry points added to
  be called from compiled code

• Copying GC refactored to avoid using grow_memory, it now uses alloc_words
  to allocate in to-space.

• New crate motoko-rts-macros added. This defines a macro ic_mem_fn which
  is used to generate monomorphised versions of allocationg functions, to be
  called from compiled code.

• Randomized testing in RTS tests now use proptest instead of quickcheck.
  proptest is much more flexible than quickcheck, allows easier testing in some
  cases.

Perf changes:

Using CanCan backend benchmark as described here:
#2033 (comment)

• With copying GC the the benchmark uses 1.5% more instructions. I suspect this
  is caused by the change in copying GC to use alloc_words instead of
  grow_memory.

• With compacting GC the benchmark uses 0.12% less instructions

TODOs:

• I had to disable the test big-array-access. It's a failing test, and the
  backtrace changes depending on RTS build flags (debug or release).

[dfinity-ci]

This PR does not affect the produced WebAssembly code.

[crusso]

I must admit, this PR is kinda large to review now, but hopefully some of the comments are useful....

[crusso]

Indeed, I wonder if adding some monadic syntax to let you build heap graphs using monadic syntax would be useful for writing tests. Does Rust let you do that easily?

[crusso]

The arguments look identical here. Can you instead compute the gc function and apply the result to the arguments, sans repetition?

[osa1]

So the problem here is compacting_gc_internal and copying_gc_internal functions have generic parameters, so they're like C++ templates rather than OCaml/Haskell functions with type parameters. We can't return them from functions for two reasons (1) type system not powerful enough for higher rank types, so we can't return a value of type forall x y z . ... (2) the runtime does not support values with type parameters (which would require monomorphising in runtime). I also mentioned this briefly in the GC type, copying here:

/// Enum for the GC implementations. GC functions are generic so we can't put them into arrays or
/// other data types, we use this type instead.
#[derive(Debug, Clone, Copy)]
pub enum GC {
    Copying,
    MarkCompact,
}

[crusso]

Unresolved TODO? @ggreif might know the answers to your questions...

[osa1]

Right, so this code was ported from the C implementation of RTS and I added this TODO to ask about it later and document it. Would be good to know what "tag" means here and document it.

[crusso]

https://github.com/dfinity/motoko-base/blob/927119e172964f4038ebc7018f9cc1b688544bfa/src/Float.mo#L79 might give a clue.

[crusso]

I'm curious: I wonder why we do this rather than just switching the role of the two space and from space. Is that to accommodate a memory.grow on the next round of mutation and avoid interpreting pointers as offset relative to the current to_space base?

[osa1]

Is that to accommodate a memory.grow on the next round of mutation and avoid interpreting pointers as offset relative to the current to_space base?

It is to allow bump allocation until the end of Wasm heap without loss of efficiency. If keep using to-space we will have less room to bump the heap pointer until end of Wasm heap. Before copying GC the heap is like this:

| static heap | dynamic heap |........(unallocated)...........|
^             ^              ^                                ^
0           heap base      heap pointer                  end of Wasm heap
                           (allocation pointer)              (4GiB)

Allocation is done by bumping the heap pointer until it reaches end of Wasm heap, and calling memory.grow on the way to allocate Wasm pages when needed.

After copying live data to to-space it looks like this:

| static heap | from-space   |to-space  |....(unallocated)....|
^             ^              ^          ^                     ^
0           heap base      to-space   heap pointer          end of Wasm heap

Now if we don't move to-space back to from-space we'll have much less space to allocate (the "unallocated" part).

We could implement a slow path for allocation that, when hp == end of Wasm heap, checks if we have any space between heap base and beginning of current space. Or more generally, we could make allocation area a list of ranges on the heap (though I think we will need at most two ranges in this list), so handle cases like:

| static heap | to-space | from-space | to-space |
                                                 ^
                                            end of Wasm heap

Which becomes this after GC:

| static heap | alloc area | live data | alloc area |
                                                    ^
                                               end of Wasm heap

[crusso]

Yeah, all makes sense, thanks for the explanation!

[crusso]

Curious why you got rid of ic_fn, but LGTM

[osa1]

Curious why you got rid of ic_fn, but LGTM

It wasn't as useful as ic_mem_fn. What it did was it converted this

#[ic_fn]
fn blah() { ... }

into

// original function, to be used in tests
fn blah(...) { ... }

// wrapper to be called from generated code
#[cfg(feature = "ic")]
#[no_mangle]
fn ic_blah(...) { blah(...) }

I can do the same without using the macro by adding cfg(...) and no_mangle manually:

#[cfg_feature = "ic"]
#[no_mangle]
fn blah() { ... }

and use it in both tests and from generated code.