How GC works

• Most initial objects allocated in Eden space

• Young generation has two survivor spaces

  • Objects that survive GC get moved to the survivor space

  • Only one survivor space in use at a time

  • Objects copied between survivor spaces

  

Minor GC

Minor GC happens when Young generation is full.

A number in the green rectangle is a number of minor GCs which the object has survived.

After minor GC survivor space is swapped, Eden space is cleared and new allocations happen in Eden space.

Major GC

Major GC happens when Old generation is full. It collects old and young generations (actually called Full GC).

Memory allocation

Non realistic and idealistic usecase of one thread (just to demonstrate an idea):

After allocation of memory the pointer (arrow) just incremented (which is very quickly)

Multi threading usecase

Java uses Thread Local Allocation Buffers (TLABs). Each Thread gets its own buffer in the Eden space. This buffers helps to avoid any locking mechanism (locking could have been required because many threads are sharing same heap memory and they need to allocate objects concurrently). Every thread can allocate memory just in given buffer.

Live roots

Live roots are references from

• track frames

• static variables

• JNI (Java Native Interface)

• synchronisation monitors

Objects in Young Gen can be references by objects in Old Gen. And such objects should survive GC. The issue is that Young GC scans only Eden and Survive spaces for Root set references. It does not scan Old Gen.

Young GC does not scan Old Gen due to efficiency . To fix this issue there are Card Tables.

When write to young Gen object happens (I assume from Old Gen), this write goes through Write Barrier (this is a mechanism in JVM). Write Barrier triggers code in JVM, and this code updates an entry in a table. During Minor GC this Card Table is scanned and if there were any changes for particular entry (and entry corresponds to the object in Young Gen) then object in Young Gen survives.