Description
Currently, when using MMTk, System.gc() calls memory_manager::handle_user_collection_request(mmtk, tls) which in turn calls MMTK::handle_user_collection_request(tls, false, false) (also a public method). The two false means the GC is not forced, and does not need to be exhaustive.
In mmtk/mmtk-core#1140, we discussed letting the VM trigger GC manually before running benchmarks. To make that possible, System.gc() should force an exhaustive GC.
But the Java API does not require System.gc() to be forced and exhaustive. According to the Java API, System.gc() is best-effort.
There is no guarantee that this effort will recycle any particular number of unused objects, reclaim any particular amount of space, or complete at any particular time, if at all, before the method returns or ever. There is also no guarantee that this effort will determine the change of reachability in any particular number of objects, or that any particular number of Reference objects will be cleared and enqueued.
Intuitively, when the user calls System.gc(), they usually intend to let the GC collect as many dead objects as possible. But there are cases when the user intends to retain soft references (which are usually used to implement caches) but recycle weakly or phantomly reachable objects. Again the Java API does not force any behaviour for that. That means we are essentially free to implement System.gc() however we like.