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: Some experience with the igc branch Date: Sun, 22 Dec 2024 18:56:11 +0100 Message-ID: References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29073"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: =?utf-8?Q?=C3=93scar?= Fuentes , emacs-devel@gnu.org, Helmut Eller , Andrea Corallo To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 22 18:56:54 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 1tPQCE-0007NJ-7E for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Dec 2024 18:56:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPQBg-0004uh-Md; Sun, 22 Dec 2024 12:56:20 -0500 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 1tPQBe-0004sw-7P for emacs-devel@gnu.org; Sun, 22 Dec 2024 12:56:18 -0500 Original-Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tPQBc-000598-HZ; Sun, 22 Dec 2024 12:56:17 -0500 Original-Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-aab925654d9so646459466b.2; Sun, 22 Dec 2024 09:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734890174; x=1735494974; darn=gnu.org; h=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=KW9oWTCLqB4EmsD7BPOuS6QWrMAjYweQTdrwsD1POT8=; b=IPL+ivc5ESnhR6xmt9xWFuSwg8tCDZLhOZHOfEOHRBbKnNaY+c3MJ4IpQ6ajZGGqf+ sHgpwfsXZ07A74WtkS49LtY9flvXzO7GJ+n0sOroLSDcH0HmsPCOHDtM6ODnW+qxIe2s 92of97tLWWtf2KCRw8ilgGHERe6hOqUpFE5ycYUrbXiHblmzFUBp72RHd5y8UIoSxf2Y 7ooWUQ0bwlmSd3BYca3uCFx9+DoaZKslQDLfsqjWHq3BKWXQ323AfAstVPSXiVXoZ2Bx YD0Inc5QK/85r3Yn4R+dv1Y3bZhp3f5g/PBCNEq54azW2z62r83K+yd3m+R7HRV074Eo RLmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734890174; x=1735494974; h=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=KW9oWTCLqB4EmsD7BPOuS6QWrMAjYweQTdrwsD1POT8=; b=QHrgcTXCyIqXeIMEDNnqJolflfCtjVOQdOMxfDQEagemHu6XYFO4xf672IIUWRRgiQ arH/ayYvjEkgmo0pu8tismj4+/NsRTr9E/2NLUnEtfjLoAYDFQS+qfBeCpFuj+H0+06t mu320qmXwiSntLL9mpUwNmEVIQptavu9J334Z9hKv0dCvs//rKqSBNUDtJWsdTGnXR+l b1TzwqeOS2hBwr6YIh2Q/dwWXUKjXVMBaSBDiWFsHZAqaF8Gf9JyWv6Lg8VH49wDAALJ TopzVQIcCQmlD2MC47YMkVOPQUWfVoNoYaL+enszAJKEfOPKBob0kPUJEaAxZgLgmDWH 6N9g== X-Forwarded-Encrypted: i=1; AJvYcCWpE1qjDTFEpCBuNsh6SqHRWFkPGjFv4MJ11rp4MxzRjgtIeXNgVN228Ae682m25QYbE4oi63Mlqg==@gnu.org, AJvYcCXDjmMT5C6X2to67vJEFHeY+fW2dhLZpO2G/dA2ss0nj/5gts6780QIt5t8DDwksAxDKBce+DC40veMQks=@gnu.org X-Gm-Message-State: AOJu0YxOehwtBepioww21z877XGFXds136xuzPH5xoXhz+lqGb1B/x3y 6KP0tb94AtVTrGqLdZXUP5go8OwX5NJwz3zwNtLQLINA39Y0sWKKiofc6Q== X-Gm-Gg: ASbGncsPZmIaD/0M/TsoRw47vrYFGQsIcETfnpBOsGCbGy2FdA7LSkFv/bj9YPZv/uY nP+x/qGwUYFWw0+qS2SqWVVxlAhJ7GtYtMvYoObn4xieUILqiST/SocuZMnsR6F9XBAK7M2ttOs AJkf+otN/2DEwtwKlqh9iKP3LB4QhP0JC3RR7qtD1kS9OrFuobtr4k1q92LVmzi4KTexy099UHp nsuq3ZG0LB83ngkUUu8IukZYdPpQzzxTxkxVmrKOpVoqm7Pa8lGbtDuaiockB4iWOaOqyKNOcef ivK1Qn3XurBmAir/LILii3TC0jh7+4B3s6DWTnayfvAblDT9mFSdbG5TuWxg/zXiqA== X-Google-Smtp-Source: AGHT+IH4evEWu1NGRYxAsAArdxl53gnJox3IizKynmrxPzIeSTjIsxqvrNL/KYa8g0MXblBu93iSsQ== X-Received: by 2002:a17:906:dc89:b0:aa6:af4b:7c89 with SMTP id a640c23a62f3a-aac3446dd7cmr920932866b.61.1734890173791; Sun, 22 Dec 2024 09:56:13 -0800 (PST) Original-Received: from pro2 (p200300e0b71f6700b0196211433a3436.dip0.t-ipconnect.de. [2003:e0:b71f:6700:b019:6211:433a:3436]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e830d9dsm410513566b.5.2024.12.22.09.56.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Dec 2024 09:56:13 -0800 (PST) In-Reply-To: <87ldw7fwet.fsf@protonmail.com> (Pip Cet's message of "Sun, 22 Dec 2024 17:41:47 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::635; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x635.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:326871 Archived-At: Pip Cet writes: > 3. bytecode stack marking. That comment raises my red-flag alert, > because it sounds like we're just accepting a preventable crash at this > stage rather than wanting to do anything about it. The reality, of > course, is different, but I'd be happier if we refused to create a byte > code object that intends to use more stack than we can guarantee we > would scan. Can we do that? > > Pip You mean my comment here? static mps_res_t scan_bc (mps_ss_t ss, void *start, void *end, void *closure) { MPS_SCAN_BEGIN (ss) { struct igc_thread_list *t = closure; struct bc_thread_state *bc = &t->d.ts->bc; igc_assert (start == (void *) bc->stack); igc_assert (end == (void *) bc->stack_end); /* FIXME/igc: 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 = 1024; char *scan_end = bc_next_frame (bc->fp); scan_end += HORRIBLE_ESTIMATE; end = 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; } I never felt like changing the byte code stack, TBH. For reasons :-).