ESR "Waning of Python" post

[Marko Rauhamaa]

Paul Rubin <no.email at 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