Memory leaks (detected by Valgrind)

[Marc Nieper-Wißkirchen]

Am Fr., 17. Dez. 2021 um 17:07 Uhr schrieb Andrea Corallo <
andrea.corallo@arm.com>:

> Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com> writes:
>
> > Am Fr., 17. Dez. 2021 um 15:54 Uhr schrieb Andrea Corallo <mailto:
> andrea.corallo@arm.com>:Marc Nieper-Wißkirchen via Jit <mailto:
> jit@gcc.gnu.org> writes:
> >
> >> Am Fr., 17. Dez. 2021 um 11:52 Uhr schrieb Alex Coplan <mailto:
> Alex.Coplan@arm.com
> >>>:
> >>
> >>> Hi,
> >>>
> >>> > -----Original Message-----
> >>> > From: Jit <jit-bounces+alex.coplan=mailto:arm.com@gcc.gnu.org> On
> Behalf Of
> >>> Marc
> >>> > Nieper-Wißkirchen via Jit
> >>> > Sent: 17 December 2021 10:29
> >>> > To: Mark Wielaard <mailto:mark@klomp.org>
> >>> > Cc: Marc Nieper-Wißkirchen <mailto:marc.nieper%2Bgnu@gmail.com>;
> mailto:jit@gcc.gnu.org
> >>> > Subject: Re: Memory leaks (detected by Valgrind)
> >>> >
> >>> > Thanks!
> >>> >
> >>> > With `--enable-valgrind-annotations`, the "uses of uninitialized
> values"
> >>> > have gone away, but a lot of small leaks are still present:
> >>>
> >>> Memory leaks with libgccjit are a known issue, see
> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63854
> >>
> >>
> >> Oh, that the bug has been open so long and is still open is unfortunate
> as
> >> a process using libgccjit usually lasts a lot longer than a single
> compiler
> >> run by gcc.
> >
> > This weakens the usefulness of libgccjit considerably, doesn't it?
>
> Agree, IMO it does.
>
> > If I have to start a new process to invoke it, only a bit is won
> > compared to writing out C and using the C frontend of GCC through
> > exec, no?
>
> Correct.  We leave with that also because we use subprocesses to obtain
> parallelism (we have no posix thread exposure in Elisp) *and* in any
> case we would not be able to backport the hypothetical fix to old
> distros.
>

Speaking of parallelism: When I tried to find where the memory losses come
from, I saw a lot of global variables like `link_command_spec' in `gcc.c'.
Does it mean that compiling the context is not thread-safe? (I may have
missed that in libgccjit's documentation.)

> > How to you pass back the result of the compilation from the
> > subprocess to the original process in Emacs?
>
> For us it's easy as the output of the compilation is a file (we'll reuse
> it in different sessions).
>
> > PS How difficult is it to fix the memory leaks?
>
> Good question.
>
>   Andrea
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>