Paul Rubin <no.email@nospam.invalid>: > But it's possible to do parallel GC with bounded latency. Perry > Cheng's 2001 PhD thesis says how to do it and is fairly readable: > > http://reports-archive.adm.cs.cmu.edu/anon/2001/CMU-CS-01-174.pdf
Thanks. On a quick glance, it is difficult to judge what the worst-case time and space behavior are as the thesis mixes theory and practice and leans heavily on practice. The thesis says in its introduction: A real-time collector comprises two important features: pauses are bounded by some reasonably small value and the mutator can make sufficient progress between pauses. Different collectors meet these conditions with varying degrees of success and their viability depends on application needs. It is important to note that a collector must also complete collection within a reasonable time. A "real-time" collector which mereloy stops collections whenever it runs out of time would be hard real-time but useless if it never finishes a collection. In such cases, memory is soon exhausted. As with other real-time applications, the most important distinction among real-time collectors is the strength of the guarantee. > If you hang out with users of Lisp, Haskell, Ocaml, Java, Ruby, etc., > they (like Python users) have all kinds of complaints about their > languages, but GC pauses aren't a frequent topic of those complaints. I don't suffer from it, either. > Most applications don't actually care about sub-millisecond realtime. > They just want pauses to be small or infrequent enough to not interfere > with interactively using a program. If there's a millisecond pause > every few seconds of operation and an 0.2 second pause a few times an > hour, that's usually fine. Emacs occasionally hangs for about a minute to perform garbage collection. Similarly, Firefox occasionally becomes unresponsive for a long time, and I'm guessing it's due to GC. Marko -- https://mail.python.org/mailman/listinfo/python-list