Garbage Collection

[charsleysa]

Currently there is no way to reclaim memory in MOSA.
This issue may not seem much of a big deal now but when we get ARM support up and running MOSA may be run in memory constrained environments so it will need to reclaim unused memory or it will run out of memory quite quickly.

Garbage collection in the Runtime will solve this but the issue is how do we implement it?

I propose that for starters we look at using a reference counter implementation as it will be the easiest to implement. I am aware that there are issues with it such as circular reference failure but those are minimal cases which are acceptable for MOSA 1.5.

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

[ArsenShnurkov]

Garbage Collector + Memory manager what is stable for use (in COSMOS OS):
http://cosmos.codeplex.com/discussions/462382

[charsleysa]

@ArsenShnurkov that code can't be used for a few reasons:
It's old and outdated
COSMOS don't even use it any more
MOSA and COSMOS have different structures which make code ports almost impossible.

Also I severely dislike their code management, it looks very fragmented and difficult to follow.

With MOSA we should be able to create a simple garbage collector thanks to the compiler and it's IR stages which allow us to quickly insert code to all platforms and allow us to make calls into the platform specific runtimes.

[tgiphil]

I would avoid what I consider to be the rabbit hole pursuit of trying to implement a working reference counting garbage collector. What makes MOSA unique is that all the compilation stages maintain if a register or stack location is an object type or something else. This is by design so precise garbage collector can be implemented. I'd rather spend time in that pursuit.

[charsleysa]

The problem I see with the way mosa is at the moment is that while we know this information at compile time we are missing a lot of this information at runtime.

With a mark and sweep system, if we miss even one root that would cause a fatal crash of the operating system.

As of yet I haven't figured out an efficient implementation of Mark and sweep.

[ArsenShnurkov]

Staccato: A Parallel and Concurrent Real-time Compacting Garbage Collector for Multiprocessors
http://researcher.watson.ibm.com/researcher/files/us-groved/rc24504.pdf
summer of 2006

the Garbage Collection Bibliography (up to 2009-2010)
http://www.cs.kent.ac.uk/people/staff/rej/gcbib/gcbib.pdf

Just google query (it gives citation counts):
https://www.google.com/search?q=%22real-time+garbage+collection%22+filetype%3Apdf

[tgiphil]

My current thoughts and plans for the first basic GC implementation are:

1. Precise object tracking --- the compiler will emit detailed stack and register usage.
2. Objects are allocated from memory blocks (maybe around 4k each)
3. Objects can span more than one block.
4. Memory block allocations are tracked and hold flags to indicate active or not per block
5. All objects contain a bit to indicate if the object was traversed already during a GC (the meaning of the bit flips each GC cycle)
6. On garbage collection -

• All threads are suspended
• All the memory block flags are initially set to not active
• Object references on stack and static heap locations are collected ("root references")
• All root references are traversed to find additional objects
• Object that get traversed have their GC bit set (or flipped) - once flipped they are not traversed again
• Memory blocks containing an object that got their GC bit set is set to active
• Once all objects are traversed, all memory blocks which remain inactive are either re-used for future memory allocations or released back to the OS.
• Finally, all threads are resumed.

This is a simple design with some advantages: notably easy/straightforward implementation, fast memory allocator, reclamation of unused memory (without compacting) and disadvantages: internal fragmentation (by objects less than 4k) and external fragmentation (less continuous memory).

Again, only my initial thoughts - this may change as we get closer to implementation.

[GeroL]

GC of .Net itself: https://github.com/dotnet/coreclr/tree/master/src/gc
C++ but still maybe useable somehow

[ArsenShnurkov]

https://www.azul.com/resources/azul-technology/azul-c4-garbage-collector/
Continuously Concurrent Compacting Collector
it never falls back to a stop-the-world compaction.
http://stackoverflow.com/questions/5841847/does-net-have-something-similar-to-what-azul-provides-for-java

[tgiphil]

@ArsenShnurkov I'm working on 1) Precise Object Tracking now. It requires structure changes to the compiler to track object references and object offsets. In addition, x86 specific operand types, which are incompatible with other platforms, are being removed.