EXPERIMENTAL: Implement a GC

[jonathanvdc]

Hi! Here's a PR that implements a garbage collector for CUDAnative. Major additions include:

• The garbage collector itself (gc.jl). The GC is a non-moving, semi-conservative, stop-the-world GC that uses a free list for memory allocations.
• Numerous changes to the compiler itself to support the GC.
• An implementation of the important bits of the low-level Julia array API. This allows us to use regular arrays from Julia kernels.
• A flexible interrupt mechanism that implements GPU-to-CPU callbacks. The GC uses it to trigger collections, which happen on the CPU rather than the GPU.
• Threading primitives. The GC uses them to ensure mutual exclusion for critical sections.
• A bump allocator that can be used as a fast alternative to the GC. Unlike the GC, the bump allocator can't expand its heap when necessary. However, it is very fast and its heap is easy to dispose after a kernel completes. This latter point is a big win over the old memory allocator based on CUDA malloc, which will leak memory perpetually, even across kernel invocations.
• A set of GC benchmarks for evaluating the GC's performance.

[maleadt]

Great! Good to have this here as a PR.

Would you mind factoring out the bump allocator? I'd prefer to merge something less complex first. It's also a strict improvement, whereas the complex GC might degrade performance.

[jonathanvdc]

Wow, that was fast!

The bump allocator's implementation is a bit intertwined with the GC's, but I'll see what I can do.

With regard to performance, both the bump allocator and the GC are opt-in. So neither will affect the performance of existing CUDAnative kernels.

[maleadt]

With regard to performance, both the bump allocator and the GC are opt-in. So neither will affect the performance of existing CUDAnative kernels.

Yeah, but I think we could reasonably try and default to the bump allocator in the short term, since the current allocator is so bad (both in terms of performance and usability). That would be easier if it doesn't depend on the rest of the functionality in this PR.