From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by sourceware.org (Postfix) with ESMTPS id 75D3B3858407 for ; Fri, 17 Dec 2021 17:53:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 75D3B3858407 Received: by mail-yb1-xb2e.google.com with SMTP id 131so8632465ybc.7 for ; Fri, 17 Dec 2021 09:53:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=enHNtMKWeTnl+79V4GokuzcUoqrhkDspnkucpAFQ5f0=; b=Kxc4kvMMWHfGZwB/miNrOASmrMp8XGqMKmYSiR+d/JiOYlKbk8UoD1Z0PHgKAY2AHo +PsyrZjDmhAyuft7Vmhwlg7N2Ioy3JZjjrmYN87+cxzA256wDJjfZApd/FfLH+yzIOvF a8jUKvc2rWuaKLN8AWZ+IIrSANdjSihVlI26R6Ny5FPSeMizKGizgXbdPg+LjAGv5A8j igfA3nQ8hDgBcJLOmolpy8uyq871RwZC87y6x+EJCvRrQEtPH7QPJdZ6phE/jA6MsuF7 cigYusxA1MnWP83cc4/B1I77aiUcLi1ykRnAYg7GJ+Vc7+9VliuAIqdwLrsg/wDgHNld TaEQ== X-Gm-Message-State: AOAM532kIYuSpKEMbcJScndBpELEkeahdaG7VyxKCaRhyJVLGpDf5gju SwDBUAa1cx86xf5rpLPQHK9oPZbULJpaVIaV0yY= X-Google-Smtp-Source: ABdhPJwv/Ec731m++A4tySD83hcwcthhf4BHY82YF63hlcNp2wcY2JGOFBbnFNdTNRXnYstoopQ2SrrN6cGYES7Wcog= X-Received: by 2002:a25:dad4:: with SMTP id n203mr5401258ybf.554.1639763637000; Fri, 17 Dec 2021 09:53:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Date: Fri, 17 Dec 2021 18:53:45 +0100 Message-ID: Subject: Re: Memory leaks (detected by Valgrind) To: Andrea Corallo Cc: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= , =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen_via_Jit?= , Alex Coplan , Mark Wielaard X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: jit@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 17:53:59 -0000 Am Fr., 17. Dez. 2021 um 17:07 Uhr schrieb Andrea Corallo < andrea.corallo@arm.com>: > Marc Nieper-Wi=C3=9Fkirchen writes: > > > Am Fr., 17. Dez. 2021 um 15:54 Uhr schrieb Andrea Corallo andrea.corallo@arm.com>:Marc Nieper-Wi=C3=9Fkirchen via Jit jit@gcc.gnu.org> writes: > > > >> Am Fr., 17. Dez. 2021 um 11:52 Uhr schrieb Alex Coplan Alex.Coplan@arm.com > >>>: > >> > >>> Hi, > >>> > >>> > -----Original Message----- > >>> > From: Jit On > Behalf Of > >>> Marc > >>> > Nieper-Wi=C3=9Fkirchen via Jit > >>> > Sent: 17 December 2021 10:29 > >>> > To: Mark Wielaard > >>> > Cc: Marc Nieper-Wi=C3=9Fkirchen ; > 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=3D63854 > >> > >> > >> Oh, that the bug has been open so long and is still open is unfortunat= e > 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 th= e > information in any medium. Thank you. >