GNU bug report logs - #78620
[PATCH] Make obarray's buckets a Lisp_Vector

Previous Next

Package: emacs;

Reported by: Helmut Eller <eller.helmut <at> gmail.com>

Date: Wed, 28 May 2025 12:05:04 UTC

Severity: normal

Tags: notabug, patch, wontfix

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 78620 <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 78620 <at> debbugs.gnu.org
Subject: Re: bug#78620: [PATCH] Make obarray's buckets a Lisp_Vector
Date: Wed, 28 May 2025 18:49:34 +0200
[Message part 1 (text/plain, inline)]
On Wed, May 28 2025, Pip Cet wrote:

> "Helmut Eller" <eller.helmut <at> gmail.com> writes:
>
>> Making the Lisp_Obarray.buckets field a proper Lisp_Vector instead of a
>> plain Lisp_Object[] would make some things simpler: some #ifdef HAVE_MPS
>> can be removed and the dumper is a bit simpler too.
>
> Or we could make it a Lisp_Object, and use the generic vectorlike code.
> I really do not understand your reasoning for wanting to do the
> opposite, and use more raw pointers in heap objects.  What is the
> advantage?

The advantage is better static type checking and better documentation.
Compare the field declarations:

  struct Lisp_Vector *buckets;

with
  
  Lisp_Object buckets;

Which one describes the data structure better?  Clearly the first.

[...]
> I realize there's no consensus for following my suggestion (if it's on
> the heap, and thus fixable, use a Lisp_Object; if you need a raw
> pointer, it should only ever be in a local variable).  But I don't think
> there's any consensus for doing the opposite either.

I think that in structures, raw pointers to objects on the GC heap will
not go away.  So we can as well take advantage of them.

[...]
> As for less fundamental things that should probably be fixed:
>
> I notice that vector_size doesn't mask out the GC mark bit, but it is
> used instead of gc_asize in the new AREF.  So the new AREF is
> problematic when used during GC.
[...]
> The pdumper code should probably use strong weight for the bucket
> vector, not WEIGHT_NORMAL, in order to avoid changing the dump layout
> unpredictably.
[...]
> Since size_bits and the size of the new vectors are redundant, it'd be
> nice to assert things are as they should be in obarray_size.

Valid points.  See amended patch below.

[0001-Make-obarray-s-buckets-a-Lisp_Vector.patch (text/x-diff, attachment)]

This bug report was last modified 53 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.