And THAT is the problem [LWN.net]

And THAT is the problem

Posted Aug 22, 2011 22:40 UTC (Mon) by cmccabe (guest, #60281)
In reply to: And THAT is the problem by zlynx
Parent article: HP dropping webOS devices

> I can back that up with my own personal experience. Java software and
> C#/.NET too will show unexpected and very annoying pauses whenever the GC
> is required to run.

The JVMs in use on servers do not use incremental garbage collection. I mentioned this is in the post that started this thread.

> C or C++ software, even Perl and Python software never
> demonstrated this erratic behavior.

CPython's garbage collector is based on reference counting, which is inherently incremental. So it's no surprise that you don't see long pauses there.

Perl's garbage collector is "usually" based on reference counting. It does a full mark and sweep when a thread shuts down, apparently. See http://perldoc.perl.org/perlobj.html#Two-Phased-Garbage-C...

> If you would like to see it for yourself, please run JEdit on a system
> with 256MB RAM while editing several files of several megabytes each.

I would like to, but unfortunately systems with 256MB of RAM are no longer manufactured or sold.

> That
> is one application I know I experienced problems with while Emacs and vi
> never acted funny.

Ironically, emacs actually implements its own garbage collector, which is based on mark-and-sweep. So apparently even on your ancient 256 MB machine, old-fashioned stop-the-world GC is fast enough that you don't notice it. As a side note, it's a little strange to see emacs held up as a shining example of efficient programming. The sarcastic joke in the past was that emacs stood for "eight megs and constantly swapping." Somehow that doesn't seem like such a good punchine any more, though. :)

The bottom line is that well-implemented garbage collection has its place on modern systems.

(Log in to post comments)

There are nothing ironic here...

Posted Aug 24, 2011 9:07 UTC (Wed) by khim (subscriber, #9252) [Link]

Ironically, emacs actually implements its own garbage collector, which is based on mark-and-sweep. So apparently even on your ancient 256 MB machine, old-fashioned stop-the-world GC is fast enough that you don't notice it.

This machine may be ancient, but emacs is beyond ancient. You said it yourself:

As a side note, it's a little strange to see emacs held up as a shining example of efficient programming. The sarcastic joke in the past was that emacs stood for "eight megs and constantly swapping."

It's still good punchline - but now it can be used as showcase for GC. If you system is so beefy, is so overpowered, is so high-end that you can actually throw 10 times as much on the problem as it actually needs... then sure as hell GC is acceptable. But this is not what GC proponents will tell you, right?