From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Cc: "Mattias Engdegård" <mattiase@acm.org>
Subject: Re: scratch/bytecode-speedup 870806d4c4 04/11: Pin bytecode strings to avoid copy at call time
Date: Tue, 11 Jan 2022 12:09:33 -0500 [thread overview]
Message-ID: <jwvczkyyzls.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20220111165048.75C05C0DA31@vcs2.savannah.gnu.org> ("Mattias Engdegård"'s message of "Tue, 11 Jan 2022 11:50:47 -0500 (EST)")
> branch: scratch/bytecode-speedup
> commit 870806d4c453addca794aa0940298425241e13d9
> Author: Mattias Engdegård <mattiase@acm.org>
> Commit: Mattias Engdegård <mattiase@acm.org>
>
> Pin bytecode strings to avoid copy at call time
> + /* ... we plonk BYTESTR and VECTOR there to ensure that they survive
> + GC (bug#33014), since these variables aren't used directly beyond
> + the interpreter prologue and wouldn't be found in the stack frame
> + otherwise. */
> + stack_base[0] = bytestr;
> + stack_base[1] = vector;
> + Lisp_Object *top = stack_base + 1;
> + Lisp_Object *stack_lim = top + stack_items;
> + unsigned char const *bytestr_data = SDATA (bytestr);
Why not keep a ref to the function object itself?
That would also allow providing a new bytecode to extract a `self`
reference to the function that's being executed.
Oh, I think I can see one reason: there's no such object when we're
called from `Fbyte_code`. Maybe `Fbyte_code` should be reimplemented as
`(funcall (make-byte-code 0 bytecode csts depth))`?
(and change `bytecomp.el` not to use `byte-code` any more)
(and mark `byte-code` as obsolete)
Stefan
next parent reply other threads:[~2022-01-11 17:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <164191984181.15147.4731922332585678354@vcs2.savannah.gnu.org>
[not found] ` <20220111165048.75C05C0DA31@vcs2.savannah.gnu.org>
2022-01-11 17:09 ` Stefan Monnier [this message]
[not found] ` <20220111165050.357D6C0DA35@vcs2.savannah.gnu.org>
2022-01-11 17:22 ` scratch/bytecode-speedup 1dca615cf9 08/11: Move a runtime interpreter check to ENABLE_CHECKING Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvczkyyzls.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=mattiase@acm.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).