20,741
edits
(→Status) |
|||
| Line 234: | Line 234: | ||
Additionally, by only mark/sweeping the youngest generation on most iterations, the garbage collector can reduce the impact of long-lived objects on its performance. In a traditional mark/sweep garbage collector, long-lived objects can cause the garbage collector to spend a significant amount of time scanning through the entire program's memory, even if most of the objects in memory are short-lived and eligible for collection. With a generational garbage collector, long-lived objects are only scanned during the initial collection of the youngest generation, after which they are moved to older generations and are not scanned as frequently. This can further improve the performance of the garbage collector and reduce its impact on the program's overall performance. | Additionally, by only mark/sweeping the youngest generation on most iterations, the garbage collector can reduce the impact of long-lived objects on its performance. In a traditional mark/sweep garbage collector, long-lived objects can cause the garbage collector to spend a significant amount of time scanning through the entire program's memory, even if most of the objects in memory are short-lived and eligible for collection. With a generational garbage collector, long-lived objects are only scanned during the initial collection of the youngest generation, after which they are moved to older generations and are not scanned as frequently. This can further improve the performance of the garbage collector and reduce its impact on the program's overall performance. | ||
=== Heuristics === | |||
There are several heuristics that can be used to determine if an existing mark/sweep garbage collector (GC) has been successfully ported to a generational GC scheme. | |||
* Self-checks: These are checks that can be performed by the GC itself to ensure that it is functioning correctly. Some examples of self-checks include: | |||
** Checking the number of pools in use: A generational GC typically divides the heap into multiple pools based on the age of the objects contained within them. The GC can check that the expected number of pools is being used. | |||
** Checking the number of objects and references in use: The GC can track the number of objects and references that are currently being used and ensure that this number is within expected limits. | |||
** Tracking memory allocations and deallocations: The GC can track the number of memory allocations and deallocations that are occurring within each pool and ensure that this number is within expected limits. | |||
== incremental GC == | == incremental GC == | ||