tag:blogger.com,1999:blog-8288194986820249216.post1960488595799900613..comments2024-03-22T05:09:17.789-07:00Comments on Abstract Heresies: More on GCJoe Marshallhttp://www.blogger.com/profile/03233353484280456977noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-8288194986820249216.post-49643289806311539982011-09-25T17:53:31.664-07:002011-09-25T17:53:31.664-07:00"So long as you have sufficient memory, you c..."So long as you have sufficient memory, you can make the cost of a collection be close to (or even equal to) zero."<br /><br />At least you can make the cost of all collections amortized over the total running time arbitrarily small. Appel argues exactly that point in http://www.cs.princeton.edu/~appel/papers/45.psKeith Rarickhttps://www.blogger.com/profile/15060512050042852855noreply@blogger.comtag:blogger.com,1999:blog-8288194986820249216.post-12434605576523407142011-09-23T07:51:19.933-07:002011-09-23T07:51:19.933-07:00JBF said So far you haven't touched what I wou...<a href="http://www.blogger.com/profile/14532492936220876390" rel="nofollow">JBF</a> said <i>So far you haven't touched what I would argue is the big issue with garbage collections, that is pause times.</i><br>I don't have enough to say about pause times except to note that if you don't GC at all, you don't pause, either.<br><br><br /><a href="http://www.blogger.com/profile/03095166606444968520" rel="nofollow">Jason Wilson</a> said <i>that isn't the only cost of "garbage". You'd need to quantify the costs of not doing compaction.</i><br><br />That seems difficult. Before I add a cost metric to the model, I want to see if the crude model has any utility.Joe Marshallhttps://www.blogger.com/profile/03233353484280456977noreply@blogger.comtag:blogger.com,1999:blog-8288194986820249216.post-33635745181493349602011-09-22T16:57:12.044-07:002011-09-22T16:57:12.044-07:00Of course with an unlimited memory budget you can ...Of course with an unlimited memory budget you can make the GC time irrelevant but that isn't the only cost of "garbage". You'd need to quantify the costs of not doing compaction (more cache misses and more TLB misses - maybe - sometimes the GC rearranges objects in a less beneficial order than the original allocation order).<br /><br />Since no one wants to "waste" memory, typically people use less heap than they really should. For example, a production process I was working on was allocated only 512Mb of Java memory (heap and whatever else Java allocates memory for). I complained that my smart phone had that much memory and people agreed to raise it all the way up to 1Gb. I don't have the time spent in GC off-hand to share.Jason Wilsonhttps://www.blogger.com/profile/03095166606444968520noreply@blogger.comtag:blogger.com,1999:blog-8288194986820249216.post-89890075955006263412011-09-22T13:53:08.693-07:002011-09-22T13:53:08.693-07:00I realize this is going to be a long comment touch...I realize this is going to be a long comment touching lots of subjects, but I'll give it a try.<br /><br />- I've heard claims that the the "current" Java benchmark everyone optimizes for has a GC overhead of around 2%. While I can't back the claim at all it seems to fit with your numbers. This was btw with a parallel (1 thread per hw thread) implementation of non-concurrent mark-and-sweep.<br /><br />- So far you haven't touched what I would argue is the big issue with garbage collections, that is pause times.<br /><br />Basically all collectors today are either stop-and-copy or mark-and-sweep or a combination (stop-and-copy for young gen, mark-and-sweep for old gen seems to be a local maximum).<br /><br />Stop and copy is good because work is O(live objects) _and_ it gives you compaction for free, but usually you waste 50% of your heap and you can't run it in parallel with your mutators.<br /><br />Mark and sweep is good because you can chop work up in smaller pieces and much work can be done with mutators running. Work is however O(live set) for mark + O(heap size) for sweep, and compaction is a pain to implement with bounded pause times.<br /><br />Space overhead is a lot lower than 50%, but you need "mark bits" in the object headers (or in separate bitsets for better cache behavior) and you often use cards for write barriers.<br /><br />What we haven't seen yet is a GC that handles large heaps (100+ G), has bounded pause-times (hundreds of milliseconds) and has a reasonable overhead in time (single digits overhead?) (and space).JBFhttps://www.blogger.com/profile/14532492936220876390noreply@blogger.com