Zero Garbage Collector for CoreCLR
Switch branches/tags
Nothing to show
Clone or download
Permalink
Failed to load latest commit information.
src Bump-pointer implementation - not working Nov 9, 2018
.gitignore Changes due to GC API 2.1 Nov 7, 2018
LICENSE Initial commit Aug 21, 2017
README.md Small fixes - configuration Nov 9, 2018

README.md

CoreCLR.ZeroGC

Zero Garbage Collector for CoreCLR

Starting from .NET Core 2.0 coupling between Garbage Collector and the Execution Engine itself have been loosened. Prior to this version, the Garbage Collector code was pretty much tangled with the rest of the CoreCLR code. However, Local GC initiative in version 2.0 is already mature enough to start using it. The purpose of the exercise we are going to do is to prepare Zero Garbage Collector that replaces the default one.

Zero Garbage Collector is the simplest possible implementation that in fact does almost nothing. It only allows you to allocate objects, because this is obviously required by the Execution Engine. Created objects are never automatically deleted and theoretically, no longer needed memory is never reclaimed. Why one would be interested in such a simple GC implementation? There are at least two reasons:

  • it is an excellent basis for the development of your own Garbage Collection mechanism. It provides the necessary functionality to make runtime work properly and you can build on top of that.
  • it may be interesting for special use cases like very short living applications or such that almost no allocate memory (you can come up with those concepts as No-alloc or Zero-alloc programming). In such case providing GC overhead is unnecessary and it may be wise to get rid of it. It is like making huge GC.TryStartNoGCRegion over all you application.

Samples

WebApi

It is super important to set the GC to workstation mode, instead of Server mode. As explained in articles below, even in custom GC the difference between Workstation and Server should be irreleveant, this setting influece how runtime handles write barriers. In case of Server GC it will end in StackOverflowException or any other nasty crash.

You can find detailed description of the project: