A typical generational garbage collector keeps recently allocated data in a sepa

ID: 646420 • Letter: A

Question

A typical generational garbage collector keeps recently allocated data in a

separate memory region. In typical programs, a lot of data is short-lived, so

collecting young garbage (a minor GC cycle) frequently and collecting old

garbage infrequently is a good compromise between memory overhead and time

spent doing GC.

Intuitively, the benefit of a generational garbage collector compared with a

single-region collector should increase as the latency ratio of main memory

relative to cache increases, because the data in the young region is accessed

often and kept all in one place. Do experimental results corroborate this

intuition?

Here are a few papers that talk about the cache implications of generational

garbage collectors:

Caching Considerations for Generational Garbage Collection
The Effect of Garbage Collection on Cache Performance

From what I can gather, the primary issue is that garbage collected systems

trade off space in memory to avoid up front collection. The same thing applies

to cache memory. As you suggested, the things in the first generation are most

likely going to be sitting in cache, and so their allocation and collection

will be much faster than something in main memory, or paged out to disk. The

main issue is the size of the first generation with respect to the size of your

cache. If your cache fills up before the first generation does, then you start

to lose those benefits as the misses start piling up.

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.