[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More over-engineering
From: |
Stefan Monnier |
Subject: |
More over-engineering |
Date: |
Fri, 27 Nov 2015 12:00:23 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
What's up with allocate_emacs_value in emacs-modules.c?
Are we really allocating a structure for every Lisp_Object value we pass
through the modules API? Why do that?
The GC will find all Lisp_Object values that are stored in other Lisp
object or on the stack, so there are rather few remaining cases where
a Lisp_Object value has to be protected from GC. For those remaining
cases, we do want to provide a way for the C code to "pin" the object
(we call it "gc-protect" them in Emacs's C code), but looking at the
emacs-modules.c is looks like we don't even do that because those
emacs_value objects are auto-reclaimed when upon return, so they only
"protect" data whose lifetime doesn't escape the current module call
(and most of those cases correspond to having a Lisp_Object on the
stack, so there's no need for GC protection anyway).
Stefan
- More over-engineering,
Stefan Monnier <=
- Re: More over-engineering, Aurélien Aptel, 2015/11/27
- Re: More over-engineering, David Kastrup, 2015/11/27
- Re: More over-engineering, Stefan Monnier, 2015/11/27
- Re: More over-engineering, Eli Zaretskii, 2015/11/27
- Re: More over-engineering, Stefan Monnier, 2015/11/27
- Re: More over-engineering, Eli Zaretskii, 2015/11/27
- Re: More over-engineering, Stefan Monnier, 2015/11/27
- Re: More over-engineering, Eli Zaretskii, 2015/11/28
- Re: More over-engineering, Stefan Monnier, 2015/11/28
- Re: More over-engineering, Eli Zaretskii, 2015/11/28