4 ms·

That work is actually still in the repo: https://git.savannah.gnu.org/cgit/emacs.git/tree/?h=other-branches/Boehm-GC https://git.savannah.gnu.org/cgit/emacs.gi

by gnufx 4y ago

That work is actually still in the repo: https://git.savannah.gnu.org/cgit/emacs.git/tree/?h=other-branches/Boehm-GC https://git.savannah.gnu.org/cgit/emacs.git/tree/?h=other-br... You may not believe the history, but you weren't there; I don't know how much is in mail archives. There was, for instance, a bizarre campaign to keep the charset `unification' out of Emacs 22. For some reason rms went along with that even when eval showed the argument was bogus.

zasdffaa 4y ago
That looks like the boehm GC, but Boehm is conservative. In no way is the Boehm GC that I'm aware of is generational or incremental (though it is mark-sweep). Start of long thread: https://mail.gnu.org/archive/html/emacs-devel/2016-11/msg00551.html https://mail.gnu.org/archive/html/emacs-devel/2016-11/msg005... "I was poking at alloc.c recently and realized that the existing conservative GC code is somewhat unsafe. In particular, 1) mark_maybe_pointer looks only for exact matches on object start. It's perfectly legal for the compiler to keep an interior object pointer and discard the pointer to the object start. 2) INTERVAL is GCed, but it's not represented in the memory tree: struct interval isn't a real lisp object and it's allocated as MEM_TYPE_NON_LISP. Even a direct pointer to the start of an interval won't protect it from GC. Shouldn't we treat intervals like conses? We've been getting by on dumb luck and the magnanimity of the compiler." Boehm was dropped for good reason.
- gnufx 4y ago
  > In no way is the Boehm GC that I'm aware of is generational or incremental Boehm disagrees: https://www.hboehm.info/gc/#details https://www.hboehm.info/gc/#details That thread isn't talking about the same thing, which it says no-one volunteered to write.
  - zasdffaa 4y ago
    I don't have time to go over the thread - conservative seems dodgy. I'll have to take your word for it. As for your main point, much to my surprise, you're right although I don't understand how, it doesn't match what I've read of it. No matter, you're right.

by gnufx 4y ago

zasdffaa 4y ago

That looks like the boehm GC, but Boehm is conservative. In no way is the Boehm GC that I'm aware of is generational or incremental (though it is mark-sweep). Start of long thread: https://mail.gnu.org/archive/html/emacs-devel/2016-11/msg00551.html https://mail.gnu.org/archive/html/emacs-devel/2016-11/msg005... "I was poking at alloc.c recently and realized that the existing conservative GC code is somewhat unsafe. In particular, 1) mark_maybe_pointer looks only for exact matches on object start. It's perfectly legal for the compiler to keep an interior object pointer and discard the pointer to the object start. 2) INTERVAL is GCed, but it's not represented in the memory tree: struct interval isn't a real lisp object and it's allocated as MEM_TYPE_NON_LISP. Even a direct pointer to the start of an interval won't protect it from GC. Shouldn't we treat intervals like conses? We've been getting by on dumb luck and the magnanimity of the compiler." Boehm was dropped for good reason.

gnufx 4y ago
> In no way is the Boehm GC that I'm aware of is generational or incremental Boehm disagrees: https://www.hboehm.info/gc/#details https://www.hboehm.info/gc/#details That thread isn't talking about the same thing, which it says no-one volunteered to write.
- zasdffaa 4y ago
  I don't have time to go over the thread - conservative seems dodgy. I'll have to take your word for it. As for your main point, much to my surprise, you're right although I don't understand how, it doesn't match what I've read of it. No matter, you're right.