Garbage collectors

Reference counting garbage collectors

Pros

1. Easy to implement

Cons

1. Additional data (field) needed to store reference counter
2. Atomicity of counter changing? -> very slow
3. If counter change is not atomic -> GIL needed instead

Generational garbage collectors

1. Based on assumption that objects usually die young
2. Used in Python VM and in JVM as well
3. Heap is splitted into so called generations
   • 3 generations in Python VM
   • 2 generations in JVM

Pros

1. Allocation is for free
2. Deallocation can be started in its own thread or threads

Cons

1. Hard to implement (correctly)
2. Stop-the-world full GC is needed sometimes

Java heap memory model

Generations

1. Two generations - young and old
2. Objects are created mainly in young generation

Young generation structure

1. Eden space for newly created objects
2. Two survivor spaces
   • one space to be freed

Objects are created in eden

When eden is full, objects are moved into selected survivor space

At the end of this operation, eden is free

After many cycles of empying eden, the survivor space gets full:

1. Regular GC starts
2. Live objects are moved into second survivor space
3. “Survive counter” is increased by one
4. This means the space is compact

At the end of regular GC, one survivor space if free and second is compacted

After many cycles the survivor space is going to be full:

1. Object that survive many cycles of regular GC is moved into old generation area

Full GC needs to be started from time to time on old area. It is slow, but usually many object survives.

More speedup possible

1. Thread Local Allocation Buffers (TLAB)
2. Allocation = add a constant to offset pointing to free region
3. Nothing more!