Whenever I see GC, I immediately think of tradeoffs. One can optimize a GC algorithm (or GC configuration setting) to work well for one type of workload. Like

Whenever I see GC, I immediately think of tradeoffs. One can optimize a GC algorithm (or GC configuration setting) to work well for one type of workload. Likewise, one can always create a pathological workload for any GC configuration because GC has unavoidable tradeoff between cpu time and memory footprint. Therefore, I read his article with the intent of placing his findings in the "taxonomy" of GC tradeoffs. In that vein, I noticed that his benchmarks and graphs do not include measurements for memory footprint. Instead, it has throughput statistics such as "ops/sec" or "sign/second". I think I see why working memory size isn't emphasized. He's testing a crypto algorithm "ECDSA-P256 Sign". I'm not familiar with it but I assume we can think of it as a typical hash function[1] that doesn't require unpredictable dynamic allocation of memory as the algorithm processes the bytes of input. (A typical hash function uses the same fixed amount of memory whether hashing 1 kilobyte or 1 terabyte.) If his synthetic benchmark to play with GOGC was using a different type of workload... such as a text parser that stressed the GC with thousands of different sized memory objects, we'd see memory footprint as part of the analysis. [1] https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signatu...