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 14:47:16 +0200 Message-ID: References: <3174C6A6-28A6-492E-A268-E391A13FEA36@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="525"; 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 14:48:53 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 1s3xm1-000AZo-Bv for ged-emacs-devel@m.gmane-mx.org; Mon, 06 May 2024 14:48:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s3xlL-0000eb-Fr; Mon, 06 May 2024 08:48:15 -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 1s3xka-00009W-WA for emacs-devel@gnu.org; Mon, 06 May 2024 08:47:35 -0400 Original-Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s3xkX-0007wC-N1; Mon, 06 May 2024 08:47:23 -0400 Original-Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a59c0a6415fso326968466b.1; Mon, 06 May 2024 05:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714999638; x=1715604438; 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=IthxsL9WK9nuWlOJbVkQVOl7YAb1afhGtGj+taZptjs=; b=Od1hTO64Ro4jx1yfo8PBndkm971m3s3HW1vf1Pc4wd2WI6RuSooka/vr+PRAmSzS1K MtPaFkQ6hZKdTGW3bGVVn4BmUoTIb+uGg5x4PFYj5RUFvKEUU9AdcjaO3olkhjG1tkVP g7Bf0DIWUozq6KWCnth6SXlTzIFURP8YGJAIh5Fd8aVcrYiexVUTiTQ3yXKRza7yeYb2 gG04k+MJLo68NVRrEV1IwpVimdnp67Np0U8z70+5VlLaDmQj7viKQvE8vwJTGwb+Hxk8 tb0uyoj31hhmmOR0w2IHPP+mhrKY3JVJbZW8tc32dhXEHf+tvdVMcX64OHYgQ0ttVeRc g4Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714999638; x=1715604438; 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=IthxsL9WK9nuWlOJbVkQVOl7YAb1afhGtGj+taZptjs=; b=tuDmDwN+fEpmJnZMXlcNFh5+sBOH+ZwV6DAX3Cr7HsSfKqXJPd86CL635p28tonBB8 +DtTPoDFBbprMR5WVjQkUDzc7F/OS2NUsr82Gt/b18Ab8UtArwwuaGy3nWWFbtrnJ+gZ LFFUFaxrbujP/eEA2hACqv0Ht5slXkho/VGUy2klSjwlTewkXW7CD1rIT1qFIOw/uIUv bih7Dl3JdwxNneFNlwQqow7RaHsVyvFXvN6Kx8+rzgpVkYxZp3ieAHFnQw6IvFFcu6D1 6LuzY7RVHGtWcclJAGKLvJt+ygNd5bOPQuAQiaZP85HTzd9EajuokAdIonLUKzxJTEYI 9kcA== X-Forwarded-Encrypted: i=1; AJvYcCXaGJGD3Hok0hbcvyrwDvU7nj9PJLScebVnAzv8Gdl7xCblzBHsB73ZakdYQjt0wIoXp+PwTNsnu08kLx4oO1F9EnBp X-Gm-Message-State: AOJu0Yw5XFygOThhF4UZDv541oxBeHlvz6HiDhlDU5x05v1bILTZjRVo FKAeW9+LcUSFRY/UV8n54DxeqALg5E5HjdNTTfDy0KMIQuKOdH/pS3K5Aw== X-Google-Smtp-Source: AGHT+IE/2nMibFUpONeHHYPzDbe/9JcE/8yRzMiyIeXinUm6aVyscvMSIeTqkznMH0TPw8ucIbmE9g== X-Received: by 2002:a17:906:1d1b:b0:a59:a0c1:b217 with SMTP id n27-20020a1709061d1b00b00a59a0c1b217mr3825788ejh.46.1714999637537; Mon, 06 May 2024 05:47:17 -0700 (PDT) Original-Received: from pro2.fritz.box (p4fe3a55e.dip0.t-ipconnect.de. [79.227.165.94]) by smtp.gmail.com with ESMTPSA id lx4-20020a170906af0400b00a5239720044sm5187600ejb.8.2024.05.06.05.47.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 May 2024 05:47:17 -0700 (PDT) In-Reply-To: <3174C6A6-28A6-492E-A268-E391A13FEA36@gmail.com> ("Mattias =?utf-8?Q?Engdeg=C3=A5rd=22's?= message of "Mon, 6 May 2024 14:12:46 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::62c; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x62c.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:318887 Archived-At: Mattias Engdeg=C3=A5rd writes: > 6 maj 2024 kl. 11.58 skrev Gerd M=C3=B6llmann : > >> I think I fixed, or better said worked around, something important today >> in scan_bc which can lead to objects being "lost". Might be interesting >> to see if some errors magically disappear. > > I'm not sure what you are trying to fix. Dodging a data race? > > To see if I understood what your problem is, and how MPS works, consider = the thread state > > Lisp_Object *a; > int top; > > where `a` is a heap-allocated array of some size, but only indices [0..to= p] are actually used so the GC doesn't need to look at the rest. The mutato= r thread does: > > 1 x =3D a[top]; > 2 top =3D top - 1; > > What does the GC thread see? Even if it reads a (signal-atomic) > snapshot of the mutator's register and stack, does this atomicity > extend to `top` which isn't even a Lisp_Object? Is the mutator > suspended during this scan? > > Furthermore, the compiler is allowed to hoist the store in line 2 past > the load in line 1. If that's the only problem, it may just be a > matter of adding a compiler barrier (acquire). It would be easiest if you'd look at scan_bc in igc.c on the branch That explains it better als prosa: static mps_res_t scan_bc (mps_ss_t ss, void *start, void *end, void *closure) { MPS_SCAN_BEGIN (ss) {x struct igc_thread_list *t =3D closure; struct bc_thread_state *bc =3D &t->d.ts->bc; igc_assert (start =3D=3D (void *) bc->stack); igc_assert (end =3D=3D (void *) bc->stack_end); /* FIXME: AFAIU the current top frame starts at bc->fp->next_stack and has a maximum length that is given by the bytecode being executed (COMPILED_STACK_DEPTH). So, we need to scan upto bc->fo->next_stack + that max depth to be safe. Since I don't have that number ATM, I'm using an arbitrary estimate for now. This must be changed to something better. Note that Mattias said the bc stack marking will be changed in the future. */ const size_t HORRIBLE_ESTIMATE =3D 1024; char *scan_end =3D bc_next_frame (bc->fp); scan_end +=3D HORRIBLE_ESTIMATE; end =3D min (end, (void *) scan_end); if (end > start) IGC_FIX_CALL (ss, scan_ambig (ss, start, end, NULL)); } MPS_SCAN_END (ss); return MPS_RES_OK; }