Emacs with the SpiderMonkey garbage collector
lists.gnu.org
Emacs with the SpiderMonkey garbage collector
1–10 of 46 posts
Re: Emacs with the SpiderMonkey garbage collector
#2Out 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
#3Re: Emacs with the SpiderMonkey garbage collector
#4Re: Emacs with the SpiderMonkey garbage collector
#5Re: Emacs with the SpiderMonkey garbage collector
#6Could someone explain, for someone not familiar with low level programming, what would be the advantages of using another garbage collector in Emacs?
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
#7The 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…
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
#8Could 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.
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
#9Could someone explain, for someone not familiar with low level programming, what would be the advantages of using another garbage collector in Emacs?
EDIT: Apparently my experience is not universal -- see below: https://news.ycombinator.com/item?id=15803046
Re: Emacs with the SpiderMonkey garbage collector
#10my emacs gc strategy: disable the gc. do manual collections by restarting every now and then.