From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: MPS: native comp Date: Tue, 30 Apr 2024 05:05:06 -0400 Message-ID: References: <86le4wsj14.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39790"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org, Helmut Eller To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 30 11:05:30 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1s1jQY-000A5e-64 for ged-emacs-devel@m.gmane-mx.org; Tue, 30 Apr 2024 11:05:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1jQC-0008F3-L2; Tue, 30 Apr 2024 05:05:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s1jQB-0008Es-Cu for emacs-devel@gnu.org; Tue, 30 Apr 2024 05:05:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s1jQA-00042u-W7; Tue, 30 Apr 2024 05:05:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=FiKN8SfkDcJvI/KK1rqdcOmlD6/ip2F8y5Xnwec+Fbk=; b=Nf8yG8GAsLVh24pHADox OV2a02WBUV0RPI+o3HcTXNLJlvoocWTj7iJsLD9gb6GeHS/r82qkqkxHbvmPo7XLbBBWh1nFX3nCf NJlI4HtwVlSShUhkXhADwy4avX5q7FhdUbbhuLqzDAo5APWUcozhhSpbdvFQfL/HbKS/mKgvpkJrp yxni8pF4GxsxzvbGbNLi2UuDOoagKyC4wicGQzSGuJRkfxeKwpvzM/VWdCkz4whiyk8CnCNcgPeqd qyGAsVwDWM2acs9Vt2tv/AhSaQrAn2e57ySgPK5sNXjiQ9hQhyIf+omnM78JnbKCvjwDT2hdkSh+M 0zrh2m3uX0BghA==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1s1jQA-0001E3-Mv; Tue, 30 Apr 2024 05:05:06 -0400 In-Reply-To: (Andrea Corallo's message of "Tue, 30 Apr 2024 04:54:47 -0400") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:318408 Archived-At: Andrea Corallo writes: > Gerd M=C3=B6llmann writes: > >> Andrea Corallo writes: >> >>> Gerd M=C3=B6llmann writes: >>> >>>> Gerd M=C3=B6llmann writes: >>>> >>>>> That promises to become fun :-/ >>>> >>>> Sometimes one needs a bit of luck. Another try landed me in an abort in >>>> set_internal, and I could see that we have another case of a symbol >>>> pointing to a tombstone. So, we have another reference in the >>>> compilation unit that we don't trace. >>> >>> Maybe you can make it more reproducible building at -J1? >> >> I meanwhile suspect it's ASLR. When I run things under LLDB, ASLR is off >> (LLDB does that). When I gmake (with -j1), ASLR on. > > Yep that makes sense > >>>> @Andrea: Any intuition where else references could lurk, perhaps? I'm >>>> currently doing this: >>>> >>>> static mps_res_t >>>> fix_comp_unit (mps_ss_t ss, struct Lisp_Native_Comp_Unit *u) >>>> { >>>> MPS_SCAN_BEGIN (ss) >>>> { >>>> IGC_FIX_CALL_FN (ss, struct Lisp_Vector, u, fix_vectorlike); >>>> if (u->data_imp_relocs) >>>> { >>>> size_t n =3D ASIZE (u->data_impure_vec); >>>> IGC_FIX12_NOBJS (ss, u->data_imp_relocs, n); >>>> } >>>> if (u->data_relocs) >>>> { >>>> size_t n =3D ASIZE (u->data_vec); >>>> IGC_FIX12_NOBJS (ss, u->data_relocs, n); >>>> } >>>> } >>>> MPS_SCAN_END (ss); >>>> return MPS_RES_OK; >>>> } >>>> >>>> Maybe there's something wrong with that (the ASIZEs maybe?) >>> >>> I think the size should be fine, >> >> Thanks. >> >>> it would be very interesting to know which one is the symbol that was >>> actually killed by the GC. This would give us strong indications. >>> Maybe we can use the watchpoint strategy to identify it? >> >> It's the symbol that leads to the setting-constant error in the eager >> macro expansion error. You can see that in the debug org file I attached >> to another mail. >> >> data =3D 0x000000010f0eb008 "byte-compile-form-stack" >> >> The problem is apparently similar to what we had before: The symbol has >> been moved in memory (not freed), and a reference to the symbol was not >> updated because we don't trace it. So a watchpoint won't help - the >> problem is that nothing changes :-). > > If the object was moved and the d_reloc is now updated by MPS I've a > doubt: > > What if our object (say d_reloc[x]) is loaded in a register by the > compiler? How does the register gets updated by MPS? In native code we > do this all the time for performance reasons. > >> Next strategy or tactic, I think, could be to produce a C file for >> macroexp.eln, and see where the symbol appears. I would imagine that I >> can deduce from the text representaton of the constants in C what index >> correspondons to the symbol, and then see if it is used in surprising >> ways. Maybe. WDYT? > > You'll probably see what I mentioned above. At the beginning of the > compiled function we load in regular variables the lisp objects from > d_reloc so GCC leverage the register allocater and keep in registers. > > For instance we do exactly this 'byte-compile-form-stack' and others > here: > > macroexp-1776619e-76691d27.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > extern struct Lisp_X * > F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_0 (long long nargs, st= ruct Lisp_X * * args) > { > struct freloc_link_table * freloc; > struct Lisp_X * slot_0; > struct Lisp_X * slot_1; > struct Lisp_X * slot_2; > struct Lisp_X * slot_3; > struct Lisp_X * slot_4; > struct Lisp_X * slot_5; > struct Lisp_X * slot_6; > struct comp_handler * c; > > entry: > freloc =3D freloc_link_table; > /* Lisp function: nil */ > slot_0 =3D *args; > /* ptr_arithmetic */ > args =3D (struct Lisp_X * *)bitcast((unsigned long long)((unsigned long= long)bitcast((void *)args, unsigned long long) + (unsigned long long)8 * (= unsigned long long)(long long)1)\ > , void *); > goto entry_rest_args; > > entry_rest_args: > /* calling subr: list */ > slot_1 =3D freloc->R6c697374_list_0 ((nargs - (long long)1), args); > goto bb_0; > > bb_0: > /* let */ > slot_2 =3D d_reloc[(long long)0]; > /* byte-compile-form-stack */ > slot_3 =3D d_reloc[(long long)1]; > /* cons */ > slot_4 =3D d_reloc[(long long)2]; > > [...] > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Where we load it in 'slot_3'. > > I think the easiest is to to make objects loaded from native code non > movable. Is this possible with MPS? What would be the downside of this? > They are very rarely collected anyway. WDYT? > > Thanks > > Andrea BTW we should be able to prove this is the issue compiling at with native-comp-speed 0. Andrea