5 ms·
In practice there are also hybrids that try to delay long stop-the-world phases as much as possible, but still need to stop-the-world when compacting the heap,
by bad_user 13y ago
In practice there are also hybrids that try to delay long stop-the-world phases as much as possible, but still need to stop-the-world when compacting the heap, like JVM's CMS.
And I was under the impression that there already are GC implementations that never go into stop-the-world phases, like Azul's Pauseless GC [1]. There's also the new G1 from JDK 7 that promises to make pauses fewer and more predictable than CMS, while avoiding many memory fragmentation issues that CMS has (how well that works out in practice, remains to be seen, as it's not fully matured at this point).
Btw, I love how Rust is trying to solve memory management issues by reinventing the problem. That's what new languages should do, instead of reimplementing other languages poorly.
[1] http://www.artima.com/lejava/articles/azul_pauseless_gc.html http://www.artima.com/lejava/articles/azul_pauseless_gc.html
- eru 13y agoOn top of that, malloc (and friends) don't make any useful worst-case runtime guarantees either.
- hga 13y agoThat's very important to remember if your heap has a messy enough history. The right language + a good GC can give you much better bounded worse case guarantees, with Azul's as the best I know of for an imperative language (the more functional, the easier it is to do a variety of things).
- hga 13y agoYes, there are ones like Azul's, and don't forget the copying GCs that have different characteristics than mark/sweep(/compact).