Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs with the SpiderMonkey garbage collector

lists.gnu.org

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Emacs with the SpiderMonkey garbage collector

#31

Post by blt »

__s wrote: post #17
marktangotango wrote: post #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…

Copying GC can be straight forward to implement: https://github.com/serprex/luwa/blob/d96ba8fc478813a0a65a65c... Get to punt the allocator as a bump allocator

I found the interaction between the C call stack, the implicit call stack of the interpreted language, and the garbage collector to be tricky. However, I do not see why copying would be any more tricky than compacting.

Re: Emacs with the SpiderMonkey garbage collector

#32

Post by blt »

ww520 wrote: post #14
marktangotango wrote: post #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…

Out of the 3 general garbage collector types - copying, mark & sweep, and reference count - copying is superior in general. The benefits of copying include: automatic compaction when copying from old heap to new heap (no memory fragmentation), improved locality (objects are closely packed), extremely fast reclamation (just throw away the old heap whereas mark & sweep needs to maintain/update the free list for differe…

What about a compacting collector? It gives the locality and fast allocation benefits of the copying while using less memory.

Re: Emacs with the SpiderMonkey garbage collector

#33

Post by arcticbull »

gcb0 wrote: post #25
cies wrote: post #15

Earlier quoted context omitted.

Yeah, much more hackable it will be fur sure. It may also come with speed improvements, as Rust did for FF. :) And I can imagine that writing (parts of) Emacs' plugins in Rust (for speed and/or hackability) may also be a great addition.

extremely naive to think a new language added perf over C++. its obviously a side effect of rewriting a 20+ yrs codebase under an updated architecture vision from scratch.

It's not that it's impossible in C++ just that it's impractical to write large-scale solutions with a complex threading model with the "don't screw up" model C++ uses. The Rust compiler provides what amount to built-in unit tests with every build pass that allow you to fearlessly write code without data races. This in turn allows the new architecture you're referencing.

Re: Emacs with the SpiderMonkey garbage collector

#34

Post by wowtip »

dilap wrote: post #18
aoeusnth1 wrote: post #12

Earlier quoted context omitted.

I'm assuming the opposite - they're running on a machine with lots of memory, and Emacs is getting bogged down by frequent and slow GC pauses. I have run into this problem myself and actually quit using Emacs because its GC lag was so bad.

yeah, this is correct. iirc it was some sort of "autocomplete open a file" library that was running slowly, mostly because of gc -- disabling gc made that snappy, and i have enough memory that it doesn't really matter if emacs never reclaims it. i also really don't like having my editor pause to do gc. (i'm addicted to emacs flexibility, but i would love a better-engineered replacement. maybe xi editor, someday. (tho…

Could turning it off cause other issues (in Emacs / in OS), apart from eating lots of memory?

Re: Emacs with the SpiderMonkey garbage collector

#35

Post by mburns »

pmoriarty wrote: post #24
cies wrote: post #11

I came across this some time ago, may be of interest: https://github.com/Wilfred/remacs It's a port of the EmacsOS to Rust, should be able to run all your elisp code at some point.

I wonder if it's possible to combine remacs with guile emacs to make guile remacs?

https://github.com/Wilfred/remacs/issues/66#issuecomment-273...

Re: Emacs with the SpiderMonkey garbage collector

#36

Post by andreareina »

wowtip wrote: post #34
dilap wrote: post #18

Earlier quoted context omitted.

yeah, this is correct. iirc it was some sort of "autocomplete open a file" library that was running slowly, mostly because of gc -- disabling gc made that snappy, and i have enough memory that it doesn't really matter if emacs never reclaims it. i also really don't like having my editor pause to do gc. (i'm addicted to emacs flexibility, but i would love a better-engineered replacement. maybe xi editor, someday. (tho…

Could turning it off cause other issues (in Emacs / in OS), apart from eating lots of memory?

The OOM killer preferentially targets processes with a lot of memory allocated. If you actually let emacs consume all memory it's likely to die without warning.

Re: Emacs with the SpiderMonkey garbage collector

#37

Post by mrighele »

arcticbull wrote: post #33
gcb0 wrote: post #25

Earlier quoted context omitted.

extremely naive to think a new language added perf over C++. its obviously a side effect of rewriting a 20+ yrs codebase under an updated architecture vision from scratch.

It's not that it's impossible in C++ just that it's impractical to write large-scale solutions with a complex threading model with the "don't screw up" model C++ uses. The Rust compiler provides what amount to built-in unit tests with every build pass that allow you to fearlessly write code without data races. This in turn allows the new architecture you're referencing.

I don't think you need a complex threading model. The browser showed that you can get good interaction with single-threaded environment as long as you 1) can offload computation to other processes (web services, in the case of the browser, or more recently, workers) through message-passing and 2) such interaction can be performed asynchronously (i.e. while you wait for the result you can continue with the rest).

I think such kind of approach could be adopted by emacs without having to rewrite everything from scratch. Taking advantage of this would require of course rewriting a good amount of code (both elisp and C), but it could be done bit by bit over the course of a long time.

Re: Emacs with the SpiderMonkey garbage collector

#38

Post by krylon »

taeric wrote: post #6
S4M wrote: 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.

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

Is that an actual problem, though?

Maybe I just don't push Emacs that far, but I have never felt GC performance to be much of a problem on even remotely capable hardware (say, anything at least as fast as a Raspberry Pi model 2).

Plus, Emacs allows the user to configure the frequency at which the garbage collector kicks in. Tweaking gc-cons-threshold has been entirely sufficient for my needs.

Re: Emacs with the SpiderMonkey garbage collector

#39

Post by bitwize »

rurban wrote: post #30
bitwize wrote: post #23

Earlier quoted context omitted.

And this is where the "it takes five times as much RAM to run a GC'd program with the same performance as the equivalent program with explicitly managed memory" bit kicks in. Value semantics covers 95% of your object-lifetime needs. The other 5% can be covered with some form of reference counting and being smart about strong vs. weak references. Tracing GC is like bubble sort: almost always a suboptimal solution.

Not 5x as much ram. Exactly 2x more ram. You copy between two half spaces, back and forth. That's why it's usually also called semispace collector. What you are talking in the 2nd paragraph is total nonsense in a lisp world. Lisp solved this problem decades ago, with copying collectors. Stack values are 20%, plus refcounts do not work with rplac* able trees and are super slow.

Yes -- five times as much RAM: http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf

As it turns out, compared to the analysis and tree traversal inherent in even a fast GC algorithm, the overhead of malloc() and free() is really quite small. So yes, it takes twice as much memory to use a copying GC, right out of the starting gate -- but in order to match the performance of the equivalent explicitly managed program, it takes even more memory on top of that. And real time -- forget about it. It takes highly tuned, specialized algorithms to run a GC language that can meet hard real-time deadlines. You'll know you've found a decent algorithm because it will be proprietary -- part of some expensive, specialized JVM the Navy uses to crunch radar data aboard ship or something. The conventional algorithms (stop-and-copy, generational, etc.) are all fucking terrible.

And I wasn't talking about "in a Lisp world". Lisp is dead for real application development. Hell, the scruffies won, and C++ is now the predominant language in AI -- where Lisp was once said to thrive. Of course refcounts don't work if you try to build a graph with only one kind of reference. But a) you should know what kind of data structure you're building (cyclic or acyclic, graph or tree) and b) you should use weak references where possible to inform the deallocator which references not to chase. It's called being smart. Yes, it's a little more work than using a tracing GC, but it's still far less cognitively taxing or error-prone than using malloc() and free() manually.

Re: Emacs with the SpiderMonkey garbage collector

#40

Post by dilap »

wowtip wrote: post #34
dilap wrote: post #18

Earlier quoted context omitted.

yeah, this is correct. iirc it was some sort of "autocomplete open a file" library that was running slowly, mostly because of gc -- disabling gc made that snappy, and i have enough memory that it doesn't really matter if emacs never reclaims it. i also really don't like having my editor pause to do gc. (i'm addicted to emacs flexibility, but i would love a better-engineered replacement. maybe xi editor, someday. (tho…

Could turning it off cause other issues (in Emacs / in OS), apart from eating lots of memory?

so far so good, been doing it since january (so coming up on 1 year).

i remembered what the driving reason was to disable gc:

turning off gc gets my emacs startup time down to ~400ms from ~600ms.

Post reply on HN