From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: MPS: Bytecode stack Date: Mon, 06 May 2024 15:35:40 +0200 Message-ID: References: <3174C6A6-28A6-492E-A268-E391A13FEA36@gmail.com> <038B57D6-C449-4C10-85F8-69D0A7844219@gmail.com> 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="12884"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , Helmut Eller , Emacs Devel To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 06 15:36:49 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 1s3yWO-0003DH-SE for ged-emacs-devel@m.gmane-mx.org; Mon, 06 May 2024 15:36:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s3yVR-0001KM-Cs; Mon, 06 May 2024 09:35:49 -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 1s3yVO-0001JV-93 for emacs-devel@gnu.org; Mon, 06 May 2024 09:35:46 -0400 Original-Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s3yVM-00084Y-IB; Mon, 06 May 2024 09:35:46 -0400 Original-Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a556d22fa93so455248166b.3; Mon, 06 May 2024 06:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715002542; x=1715607342; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=vv4eyRVplg9xYZH1bnMKYVxo+4L4EyleVSgbnZK1lVk=; b=S9Vak1VDl7MkhcwPk/1nxEA0WrmlSmt6dia7WngbBw+CMT8vhOles6xwKNLm+RxW5h 3GvqJIvuwUhh5bXboRgVNptsSHUiFSyRM/3AK9dBm7ic/JNOpWwbc7zKM3lsLxPyTQpC nyF90RDxiCRdEO5KhBY1/g62PvC+io3mufVtyvvZ9CPRsOoC6odff94uWXg/yhzP58qT gWhxAKoI8GmaxGzD9fIU4jBe/RdgKVQMGsFG70/o1d0+aFVY8DnOFeHPbZ++Pg/IZWWk r7jTu28MtZrUTYah2ihWAZyiUdfnxwJt1f+cdmD11HG6pQNEx0vGKL1Wlb5UtF4Izkk7 /Kgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715002542; x=1715607342; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=vv4eyRVplg9xYZH1bnMKYVxo+4L4EyleVSgbnZK1lVk=; b=Aw+XbTKeFwVGr1V2XJrDVjCmviv4NzAh/6/Hl9I/zX61kNZs3IZdrGNNXom20KKzOt sWpixULNF6wU0Q1OJrTLV5K+m7ANl/i4pZKxUgVD2OAJQwuGRXDJWCeWKCmuQUdYy3DG qZPGZPmbIUbho/D1YjeHp0EQGL1qkOJRR0Awos2kdtgTy2Sne1v18NXk+vGnEaHWkAPq GncimLOORxWXQLVznqV/I/ubT3xF9mshq1nM9ZHanuiLtYsyuKLa3tqyOZt6u3A2TGwZ suzQi7Vnfx/yb9MxeQK2FGwhmsE0uw2pQ3btHJnyvgn2k/QrR0Ej6XexTcB8uJIiuxfi MPfw== X-Forwarded-Encrypted: i=1; AJvYcCXcheVAFIqZd7RtSIzW+abcICRk8ukaOjvdZiwFk0M2wk0IavF08MczqI5phVbYCJ/XRg+pEJ5Fvn4JJTlqNHuUY/SV X-Gm-Message-State: AOJu0Yzu0aqPvHPEIa6uMJJ4zuB4W1m5iHb7YIt+oHK7+H24iGm2MT7Y V8bCqVqKkZGM9i0aQs1+AymkiNGq87uOeTXJIahUZxLT9jZDrGsADEXYLQ== X-Google-Smtp-Source: AGHT+IHGXw7aUK/Yj/8JnPlaLPfLZCiuMj+zjCMctj5GBkfWAPTJtVMzHYu1wQgHI0Uz03g4Kyoftw== X-Received: by 2002:a17:907:bb86:b0:a59:9edf:14b8 with SMTP id xo6-20020a170907bb8600b00a599edf14b8mr4513832ejc.3.1715002541828; Mon, 06 May 2024 06:35:41 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3a55e.dip0.t-ipconnect.de. [79.227.165.94]) by smtp.gmail.com with ESMTPSA id fx26-20020a170906b75a00b00a59a3c26fd9sm3290251ejb.152.2024.05.06.06.35.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 May 2024 06:35:41 -0700 (PDT) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Mon, 06 May 2024 15:23:29 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::634; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x634.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:318891 Archived-At: Gerd M=C3=B6llmann writes: > Mattias Engdeg=C3=A5rd writes: > >> 6 maj 2024 kl. 14.47 skrev Gerd M=C3=B6llmann : >> >>> It would be easiest if you'd look at scan_bc in igc.c on the branch >> >> I did, which is why I wondered whether I had understood the problem corr= ectly. Maybe we can help each other: >> >>> /* FIXME: AFAIU the current top frame starts at bc->fp->next_stack >> >> Does it? Look at the ASCII art in bytecode.c. During bytecode >> execution, fp->next_stack is the lowest completely unused entry of the >> bytecode stack, but that refers to the engine register `fp` which is >> almost but not entirely in sync with `bc->fp`. There are gaps when >> there is live data on the stack beyond bc->fp->next_stack, such as >> during frame setup: >> >> 514 Lisp_Object *frame_base =3D bc->fp->next_stack; >> 515 struct bc_frame *fp =3D (struct bc_frame *)(frame_base + max_stac= k); >> 516=20 >> 517 if ((char *)fp->next_stack > bc->stack_end) >> 518 error ("Bytecode stack overflow"); >> 519=20 >> 520 /* Save the function object so that the bytecode and vector are >> 521 held from removal by the GC. */ >> 522 fp->fun =3D fun; >> 523 /* Save previous stack pointer and pc in the new frame. If we ca= me >> 524 directly from outside, these will be NULL. */ >> 525 fp->saved_top =3D top; >> 526 fp->saved_pc =3D pc; >> 527 fp->saved_fp =3D bc->fp; >> 528 bc->fp =3D fp; >> >> which is why I was concerned about whether there might be a race >> somewhere. Note, however, that in this particular window we don't >> stash anything to the stack beyond bc->fp->next_stack that isn't >> already accessible via ambig refs elsewhere (`fun` in particular). >> >> There may be similar gaps when we pop stack frames: return from a >> function and in the catch and condition-case handling, but it would be >> easier if I knew what I was looking for. > > Ok, let me try to explain. Thanks for looking into this! > > I made the bc stack(s) ambig roots (conservativly scanned, like with > mark_memory). For the root address range I use the stack's start and > end. Since that is quite large (512K?), I though it a good idea to scan > less. So scan_bc tries to figure out an 'end' address that is smaller > the whole stack's end. That's all it is about. How to find a realistic, > scan end. Or, wait a moment... I'm wondering about what happens when the client continues to exec byte code while we are scanning... The root is not like objects in MPS memory to which we get granted exclusive access. Or so I think ATM. But roots can have a barrier applied to them, I think. MPS_RM_PROT. I have to read a bit. (BTW, funny I think: Emacs/master froze while having Emacs/igc in LLDB, and Emacs/igc was still functioning well :-))