emacs modules memory leak in 27

emacs modules memory leak in 27

[Milan Stanojević]

This is on emacs-27 branch.

env-make_global_ref will add a reference to the underlying Lisp_Object
and allocate emacs_value from the global storage. env->free_global_ref
on the other hand will only remove a reference to the underlying
Lisp_Object and not free the emacs_value.

The global storage of emacs_values seems to be only growing and is
never collected (and I think with the current array implementation it
is probably not possible to collect).

This leak is not present in 26 and I think the leak was introduced
with the change in the underlying representation of emacs_value. (If
I'm reading git history right, since 26 this was changed and then
reverted and then changed again).

Re: emacs modules memory leak in 27

[Milan Stanojević]

I submitted the bug report.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42482

I wonder if some kind of hybrid approach would work. Use the same
representation like emacs-26 (emacs_value is Lisp_Object) but also
have an array of emacs_values created in the environment (like in
emacs-27) that can be used to mark them for garbage collection. Global
storage wouldn't be necessary.

On Mon, Jul 20, 2020 at 12:41 PM Milan Stanojević
<mstanojevic@janestreet.com> wrote:
>
> This is on emacs-27 branch.
>
> env-make_global_ref will add a reference to the underlying Lisp_Object
> and allocate emacs_value from the global storage. env->free_global_ref
> on the other hand will only remove a reference to the underlying
> Lisp_Object and not free the emacs_value.
>
> The global storage of emacs_values seems to be only growing and is
> never collected (and I think with the current array implementation it
> is probably not possible to collect).
>
> This leak is not present in 26 and I think the leak was introduced
> with the change in the underlying representation of emacs_value. (If
> I'm reading git history right, since 26 this was changed and then
> reverted and then changed again).