[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MPS signals and Emacs
From: |
Gerd Möllmann |
Subject: |
Re: MPS signals and Emacs |
Date: |
Mon, 22 Apr 2024 22:55:30 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Paul Eggert <eggert@cs.ucla.edu> writes:
> On 2024-04-22 00:49, Gerd Möllmann wrote:
>> There are ambigupus and there are exact referenes. An object references
>> from at least one ambiguos reference cannot be moved, others can.
>
> It's not merely a question of ambiguous vs exact references. It's also
> a question of hashing.
There are several possibilites. Something MPS supports is described here:
https://memory-pool-system.readthedocs.io/en/latest/topic/location.html
In the branch, I've used an address-independent hash for now, to keep
things simple and make fast progress.
(Don't know if you read that in some thread on emacs-devel, perhaps it's
useful as background info: The whole effort started as an experiment if
MPS could potentially be used in Emacs. It took me 8 weeks so far, which
includes learning MPS.
As of now, it can build Emacs w/o native compilation from scratch, and
tests succeed except 3. One of which was caused by a change in
coreutils, for which Michael Albinus added a fix to master. The second
was a test that expected a certain behavior of finalizers, which I
didn't give priority now. The 3rd test is one of Eglot's which I don't
understand, and don't have the nerves to investigate.
Initially it was macOS only, but Helmut showed that it works on Debian,
too.
Not to bad :-). But naturally, a lot of things will still be needed to
be done.)
> For example, the Emacs Lisp internals hash references with low-level
> functions like sxhash_eq's call to XHASH, to implement functions like
> make-hash-table. If exact references are moved, hashing them won't
> work because their XHASH values will change. Does the MPS branch use
> exact references for any Lisp object visible to the Elisp programmer?
> If so, won't there be subtle bugs with make-hash-table and the like?
> Or does the MPS branch work around this issue by rebuilding every hash
> table after a GC?
The problem with eq hash tables is pretty well known in CL/Scheme
implementations. CMUCL, for example, keep track which keys move during
GC, and get/puthash rehash these. What MPS came up with is described
under the link above.
> Also, does the MPS branch have similar workarounds for every other
> place the C code uses XHASH, XLI, XPNTR, etc.? For example, suppose GC
> occurs during sort_overlays, so that compare_overlays (which uses XLI)
> is no longer a total ordering, which means qsort has undefined
> behavior?
Of course, places depending on addresses not changing will need to be
delt with.
What the problem with XPMTR is I didn't understand. In the branch, I'm
using both pointers and tagged values as references, if you meant that.
- Re: MPS signals and Emacs, (continued)
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/22
- Re: MPS signals and Emacs, Eli Zaretskii, 2024/04/22
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/22
- Re: MPS signals and Emacs, Eli Zaretskii, 2024/04/22
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/22
- Re: MPS signals and Emacs, Eli Zaretskii, 2024/04/22
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/22
- Re: MPS signals and Emacs, Eli Zaretskii, 2024/04/22
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/22
- Re: MPS signals and Emacs, Paul Eggert, 2024/04/22
- Re: MPS signals and Emacs,
Gerd Möllmann <=
- Re: MPS signals and Emacs, Paul Eggert, 2024/04/22
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/22
- Message not available
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/23
- Re: MPS signals and Emacs, Helmut Eller, 2024/04/23
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/23
- Re: MPS signals and Emacs, Helmut Eller, 2024/04/23
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/23
- Message not available
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/24
- Re: MPS signals and Emacs, Eli Zaretskii, 2024/04/22
- Re: MPS signals and Emacs, Gerd Möllmann, 2024/04/22