3 ms·
The "stop the world" phase of the collector will almost always be under 10 milliseconds and usually much less. ...and all of a sudden, GC becomes a non-issue f
by NateDad 11y ago
The "stop the world" phase of the collector will almost always be under 10 milliseconds and usually much less.
...and all of a sudden, GC becomes a non-issue for all but the most highly performing software.
- millstone 11y agoNo, there are many more potential issues with GCs beyond this one metric.
- flohofwoe 11y ago10ms is still a gargantuan amount of time for any type of application that must present a smoothly animated UI (not just games), about 60% of the per-frame budget. Every frame where the GC decides to kick in would result in a skipped frame, which is very noticeable. The only acceptable type of garbage collector for this type of application (and I wouldn't call an animated UI application a "most highly performing software") is a garbage collector that allows full control over when and how long it triggers. This sentence from the release notes "The 'stop the world' phase of the collector will almost always be under 10 milliseconds and usually much less." is completely meaningless in this regard, it basically still says "time required for garbage collection can be anything, sometimes less then 10ms, sometimes more, who knows...".
- NateDad 11y agoIf you'd seen the graphs you'd see that the stop time is related to total memory used. 10ms only happens with a large number of gigs of memory being used. For more reasonable amounts (up to a few gigs) the stop times are 1-3ms.
- Gepsens 11y agoDid you read ? With 1 Gig of Heap that's less than 1ms, and if you're creating a UI or a gaming engine there are ways to recycle objects in order to prevent GCs from working on useless object groups
- pcwalton 11y agoThat's highly oversimplified. It traded throughput for pause time. (Pause time is not the only metric that matters; thinking that it is is a common misconception about GC that bugs me.)