emacs-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]