6 ms·

> That is untrue. Indeed. Emacs actually got a preliminary port to the Boehm generational, incremental, mark-sweep collector many years ago, with a complete l

by gnufx 4y ago

> That is untrue. Indeed. Emacs actually got a preliminary port to the Boehm generational, incremental, mark-sweep collector many years ago, with a complete lack of interest in pursuing it. Also, Emacs conservative stack scanning came from SIOD via SCM https://people.delphiforums.com/gjc//siod.html#garbage https://people.delphiforums.com/gjc//siod.html#garbage

zasdffaa 4y ago
> Indeed. Emacs actually got a preliminary port to the Boehm generational, incremental, mark-sweep collector many years ago, with a complete lack of interest in pursuing it. Ja have a link? Asking because I've interacted with the devs and they are highly focused on getting emacs better. They would not reject it if it offered solid value. Also you have a link to this Boehm collector you mention as the only one I know of is the conservative one and I'd like to know more. TIA
- rurban 4y ago
  The boehm GC is the most conservative one. And very slow.
  - gnufx 4y ago
    Slow in the same way that the conservative stack scanning was bound to leak. I did actually run Emacs with it after experience elsewhere. Edit: I wonder how Boehm is somehow "most conservative", compared with, say, the Memory Pool System which I'd also look at these days but wasn't an option then.
    - zasdffaa 4y ago
      The MPS wasn't 'conservative' in any way IIRC, it was precise? Are we talking different terminologies perhaps? https://en.wikipedia.org/wiki/Boehm_garbage_collector https://en.wikipedia.org/wiki/Boehm_garbage_collector https://en.wikipedia.org/wiki/Tracing_garbage_collection#Precise_vs._conservative_and_internal_pointers https://en.wikipedia.org/wiki/Tracing_garbage_collection#Pre...
      - gnufx 4y ago
        Why argue with the people who actually produce the collectors? "GC uncooperative programs using conservative collection" https://www.ravenbrook.com/project/mps/ https://www.ravenbrook.com/project/mps/ I think it's a Bartlett-style "mostly-copying" collector, as in Scheme->C, but you can read the code and documentation.
        zasdffaa 4y ago
        I think it's an option, but I admit not one I was aware of. AFAIK the MP is a framework, and this is an option not the only way... but still, you're again! I'll do some reading, thanks.
- 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

> Indeed. Emacs actually got a preliminary port to the Boehm generational, incremental, mark-sweep collector many years ago, with a complete lack of interest in pursuing it. Ja have a link? Asking because I've interacted with the devs and they are highly focused on getting emacs better. They would not reject it if it offered solid value. Also you have a link to this Boehm collector you mention as the only one I know of is the conservative one and I'd like to know more. TIA

rurban 4y ago
The boehm GC is the most conservative one. And very slow.
- gnufx 4y ago
  Slow in the same way that the conservative stack scanning was bound to leak. I did actually run Emacs with it after experience elsewhere. Edit: I wonder how Boehm is somehow "most conservative", compared with, say, the Memory Pool System which I'd also look at these days but wasn't an option then.
  - zasdffaa 4y ago
    The MPS wasn't 'conservative' in any way IIRC, it was precise? Are we talking different terminologies perhaps? https://en.wikipedia.org/wiki/Boehm_garbage_collector https://en.wikipedia.org/wiki/Boehm_garbage_collector https://en.wikipedia.org/wiki/Tracing_garbage_collection#Precise_vs._conservative_and_internal_pointers https://en.wikipedia.org/wiki/Tracing_garbage_collection#Pre...
    - gnufx 4y ago
      Why argue with the people who actually produce the collectors? "GC uncooperative programs using conservative collection" https://www.ravenbrook.com/project/mps/ https://www.ravenbrook.com/project/mps/ I think it's a Bartlett-style "mostly-copying" collector, as in Scheme->C, but you can read the code and documentation.
      - zasdffaa 4y ago
        I think it's an option, but I admit not one I was aware of. AFAIK the MP is a framework, and this is an option not the only way... but still, you're again! I'll do some reading, thanks.
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.