Live data from Hacker News

Emacs with the SpiderMonkey garbage collector

lists.gnu.org

1–10 of 46 posts

Re: Emacs with the SpiderMonkey garbage collector

#2
The main difference between the current mark-and-sweep garbage collector and the SpiderMonkey garbage collector is that the latter is a copying garbage collector and precise, meaning that objects may change address during GC and that only typed values, not memory locations that might or might not be, must be trace

Out of all the types of gc out there going to a copying gc seems not very compelling. Mark and sweep is not bad at all (well understood, straight forward to implement), and you don't have to worry about double dereferencing pointers (ie some implementations of Cheneys, I don't know if spidermonkey refercences are indirect pointers to one of two buffers).

Re: Emacs with the SpiderMonkey garbage collector

#6
post #3

Could someone explain, for someone not familiar with low level programming, what would be the advantages of using another garbage collector in Emacs?

This is asked in the thread, though I'm not sure I saw a good answer, yet.

Basic answer is if there are complaints with the garbage collector causing stalls or other hiccups, then moving to a faster one could help.

Now, this implies that a new one would, ipso facto, be faster. That is not guaranteed. But, garbage collectors have gotten quite effective in modern times. Extra memory helps, of course.

Re: Emacs with the SpiderMonkey garbage collector

#7

The main difference between the current mark-and-sweep garbage collector and the SpiderMonkey garbage collector is that the latter is a copying garbage collector and precise, meaning that objects may change address during GC and that only typed values, not memory locations that might or might not be, must be trace Out of all the types of gc out there going to a copying gc seems not very compelling. Mark and sweep is…

Moving GCs are fairly non-intuitive. It seems like the extra overhead to do pointer updates and data copying would cause performance loss, but the generational nature of objects helps a lot. Copying means you get clean pages a lot faster and have fewer OS level allocations caused by pages sparsely populated with gen2 objects.

The Microsoft .NET implementation use a copying GC. IIRC the HotSpot JVM GC is compacting as well. Conservative GCs are much easier when interacting with C though, especially if you have to share pointers.

Re: Emacs with the SpiderMonkey garbage collector

#8
post #6
post #3

Could someone explain, for someone not familiar with low level programming, what would be the advantages of using another garbage collector in Emacs?

This is asked in the thread, though I'm not sure I saw a good answer, yet. Basic answer is if there are complaints with the garbage collector causing stalls or other hiccups, then moving to a faster one could help. Now, this implies that a new one would, ipso facto, be faster. That is not guaranteed. But, garbage collectors have gotten quite effective in modern times. Extra memory helps, of course.

There are two ways a new GC might be helpful. It might reduce the length of any individual pause (though normally at the expense of total overall pauses) and it might reduce total memory usage by compacting the heap and being a precise rather than a conservative collector.

The current emacs GC can introduce long pauses, so I’d be happy to see something which improved Thant, and I have seen annoying increased memory usage in long emacs processes so experiments in this area would be welcome.

Re: Emacs with the SpiderMonkey garbage collector

#9
post #3

Could someone explain, for someone not familiar with low level programming, what would be the advantages of using another garbage collector in Emacs?

I don't see any advantage of Emacs going from the current mark-sweep collector to a copying collector. I don't notice GC pauses using Emacs, and even after being up for weeks, I don't notice it bloating from memory fragmentation. It also seems like a lot of work to change a large, mature codebase to work with a GC that moves objects.

EDIT: Apparently my experience is not universal -- see below: https://news.ycombinator.com/item?id=15803046

Post reply on HN