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

21–30 of 46 posts

Re: Emacs with the SpiderMonkey garbage collector

#21

Post by cbsmith »

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 is actually very compelling for the right use case (and in fact was part of the standard JVM GC model until it switched over to G1GC). It's particularly useful when you have small, fixed sized objects (hello there cons cell!) and low survivorship (hello eden space!). In the right use case it also helps performance because it increases cache locality.

Re: Emacs with the SpiderMonkey garbage collector

#22

Post by cbsmith »

sitharus wrote: post #7
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…

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…

It also means you can have a much dumber allocator, which is particularly helpful if you do a lot of allocations that never survive long enough to need to be moved.

Re: Emacs with the SpiderMonkey garbage collector

#23

Post by bitwize »

jchanimal wrote: post #20
ww520 wrote: post #14

Earlier quoted context omitted.

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…

I agree. We used this architecture in Apache CouchDB, and it can also be seen in the Lucene fulltext index. The only downfall is needing enough free space to perform the copy.

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.

Re: Emacs with the SpiderMonkey garbage collector

#24

Post by pmoriarty »

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?

Re: Emacs with the SpiderMonkey garbage collector

#25

Post by gcb0 »

cies wrote: post #15
pzone wrote: post #13

Earlier quoted context omitted.

I'm thrilled to see how much progress this project is making. The ancient core of Emacs written in C is nearly impossible for a newcomer to understand. Porting it to Rust might make it possible to work on the codebase and feel confident that your changes is correct.

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.

Re: Emacs with the SpiderMonkey garbage collector

#26

Post by convolvatron »

jchanimal wrote: post #20
ww520 wrote: post #14

Earlier quoted context omitted.

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…

I agree. We used this architecture in Apache CouchDB, and it can also be seen in the Lucene fulltext index. The only downfall is needing enough free space to perform the copy.

you don't need to compact the whole working area as in the classical implementation. if you find that a page is sparse enough, just copy it into a less-than-full page of the next generation.

Re: Emacs with the SpiderMonkey garbage collector

#27

Post by nbaksalyar »

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.

Fearless concurrency is very important for performance though. You can read more on that here: https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...

Re: Emacs with the SpiderMonkey garbage collector

#28

Post by Rusky »

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.

In the case of Firefox, that new architecture was impossible without Rust. Mozilla tried and failed twice.

Re: Emacs with the SpiderMonkey garbage collector

#29

Post by rurban »

fusiongyro wrote: post #5

Wow! My gut instinct would have been to try Boehm, but I have no idea why one would prefer one GC over another with Emacs.

Because Boehm is still a conservative mark & sweep, whilst a modern copying collector with nan tagging is MUCH faster. It only needs twice as much memory.

The root scanning problem with nested calls causing races is known. I do have the same problem. You need to assign to volatile temps, or implement boehm-like scanning of registers. Which is not easily portable. Volatile temps are, and they are fast enough for me. Still running circles around boehm or any other m&s GC.

Re: Emacs with the SpiderMonkey garbage collector

#30

Post by rurban »

bitwize wrote: post #23
jchanimal wrote: post #20

Earlier quoted context omitted.

I agree. We used this architecture in Apache CouchDB, and it can also be seen in the Lucene fulltext index. The only downfall is needing enough free space to perform the copy.

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.

Post reply on HN