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.
Emacs with the SpiderMonkey garbage collector
11–20 of 46 posts
Re: Emacs with the SpiderMonkey garbage collector
#12my emacs gc strategy: disable the gc. do manual collections by restarting every now and then.
Why would you want to do that? Are you running on a severely memory-restricted machine?
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.
Re: Emacs with the SpiderMonkey garbage collector
#13I 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'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.
Re: Emacs with the SpiderMonkey garbage collector
#14The 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 different sizes of objects), great for systems with lots of objects dying young (mark & sweep needs to reclaim each died young object), cycle removal (ref count's pitfall), and generational GC is just an extension of the copying concept (in addition to copy from old heap to new heap, copy from younger generation to older generations).
Re: Emacs with the SpiderMonkey garbage collector
#15I 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'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.
Re: Emacs with the SpiderMonkey garbage collector
#16Earlier quoted context omitted.
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 u…
I'm curious how you get long pauses. I only really see giant pauses when I do a sync process call that takes longer than I expected. So, updating GLOBAL tags, for example.
Re: Emacs with the SpiderMonkey garbage collector
#17The 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
Re: Emacs with the SpiderMonkey garbage collector
#18Earlier quoted context omitted.
Why would you want to do that? Are you running on a severely memory-restricted machine?
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. (though their multiprocess approach seems _insane_ to me, _especially_ in a language that gives you safe shared-memory concurrency!))
here's the necessary incantations, in any case anyone wants to try this at home:
;; never collect.
(setq gc-cons-threshold 10000000000)
(defun garbage-collect (&rest args)
(message "trying to garbage collect. probably you want to quit emacs."))
(setq garbage-collection-messages t)
Re: Emacs with the SpiderMonkey garbage collector
#19Earlier 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.
You can load shared libraries in Emacs and Rust can expose a C ABI so it should already be possible to write plugins in Rust. In the same vein, this is cool: https://github.com/janestreet/ecaml
Re: Emacs with the SpiderMonkey garbage collector
#20The 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…
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.