Question about DEFVAR_LISP_NOPRO

Question about DEFVAR_LISP_NOPRO

[Gerd Möllmann]

I came across another esoteric question in the context of a moving GC.

Emacs contains has a few uses of DEFVAR_LISP_NOPRO, which is like
DEFVAR_LISP, except that it does not staticpro the variable.

  #define DEFVAR_LISP_NOPRO(lname, vname, doc)	\
    do {					\
      static struct Lisp_Objfwd const o_fwd	\
        = {Lisp_Fwd_Obj, &globals.f_##vname};	\
      defvar_lisp_nopro (&o_fwd, lname);	\
    } while (false)

Example:

  DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table,
                 doc: /*  Vector of valid font weight values. ... */);
    Vfont_weight_table = BUILD_STYLE_TABLE (weight_table);
    make_symbol_constant (intern_c_string ("font-weight-table"));

Here a symbol is defined which has a value that is forwarded to the
static globals.f_Vfont_weight_table, but that static is not staticpro'd.

My question is simply: What the heck?

I understand that this can be necessary, in rare cases, when one needs to
staticpro stuff before defvar_lisp is usable, during Emacs' startup. I've
done that myself, but the other cases make no sense to me.

Does someone perhaps have an idea what other reasons could be to use
DEFVAR_LISP_NOPRO?

Re: Question about DEFVAR_LISP_NOPRO

[Stefan Monnier]

> I came across another esoteric question in the context of a moving GC.
>
> Emacs contains has a few uses of DEFVAR_LISP_NOPRO, which is like
> DEFVAR_LISP, except that it does not staticpro the variable.
>
>   #define DEFVAR_LISP_NOPRO(lname, vname, doc)	\
>     do {					\
>       static struct Lisp_Objfwd const o_fwd	\
>         = {Lisp_Fwd_Obj, &globals.f_##vname};	\
>       defvar_lisp_nopro (&o_fwd, lname);	\
>     } while (false)
>
> Example:
>
>   DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table,
>                  doc: /*  Vector of valid font weight values. ... */);
>     Vfont_weight_table = BUILD_STYLE_TABLE (weight_table);
>     make_symbol_constant (intern_c_string ("font-weight-table"));
>
> Here a symbol is defined which has a value that is forwarded to the
> static globals.f_Vfont_weight_table, but that static is not staticpro'd.
>
> My question is simply: What the heck?

I think only Kenichi knows the real answer (commit d0ab1ebe49f7), but my
guess is that it was just an optimization because those vars always
refer to each of the three elements of the `font_style_table` which *is*
gcpro'd and is not exposed to ELisp so we know that a non-moving GC doesn't
need to know about those vars.

IOW, it seems perfectly safe to change those to plain `DEFVAR_LISP`
(and get rid of `DEFVAR_LISP_NOPRO`).


        Stefan

Re: Question about DEFVAR_LISP_NOPRO

[Gerd Möllmann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I came across another esoteric question in the context of a moving GC.
>>
>> Emacs contains has a few uses of DEFVAR_LISP_NOPRO, which is like
>> DEFVAR_LISP, except that it does not staticpro the variable.
>>
>>   #define DEFVAR_LISP_NOPRO(lname, vname, doc)	\
>>     do {					\
>>       static struct Lisp_Objfwd const o_fwd	\
>>         = {Lisp_Fwd_Obj, &globals.f_##vname};	\
>>       defvar_lisp_nopro (&o_fwd, lname);	\
>>     } while (false)
>>
>> Example:
>>
>>   DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table,
>>                  doc: /*  Vector of valid font weight values. ... */);
>>     Vfont_weight_table = BUILD_STYLE_TABLE (weight_table);
>>     make_symbol_constant (intern_c_string ("font-weight-table"));
>>
>> Here a symbol is defined which has a value that is forwarded to the
>> static globals.f_Vfont_weight_table, but that static is not staticpro'd.
>>
>> My question is simply: What the heck?
>
> I think only Kenichi knows the real answer (commit d0ab1ebe49f7), but my
> guess is that it was just an optimization because those vars always
> refer to each of the three elements of the `font_style_table` which *is*
> gcpro'd and is not exposed to ELisp so we know that a non-moving GC doesn't
> need to know about those vars.
>
> IOW, it seems perfectly safe to change those to plain `DEFVAR_LISP`
> (and get rid of `DEFVAR_LISP_NOPRO`).

Thanks, Stefan.

BTW, this comment in process_mark_stack isn't true because of
DEFVAR_LISP_NOPRO:

	      case SYMBOL_FORWARDED:
		/* If the value is forwarded to a buffer or keyboard field,
		   these are marked when we see the corresponding object.
		   And if it's forwarded to a C variable, either it's not
		   a Lisp_Object var, or it's staticpro'd already.  */
		break;

Re: Question about DEFVAR_LISP_NOPRO

[Stefan Monnier]

> BTW, this comment in process_mark_stack isn't true because of
> DEFVAR_LISP_NOPRO:
>
> 	      case SYMBOL_FORWARDED:
> 		/* If the value is forwarded to a buffer or keyboard field,
> 		   these are marked when we see the corresponding object.
> 		   And if it's forwarded to a C variable, either it's not
> 		   a Lisp_Object var, or it's staticpro'd already.  */

Yeah, it should be completed with "or it's reachable from
`font_style_table` which is also staticpro'd" 🙁


        Stefan

Re: Question about DEFVAR_LISP_NOPRO

[Gerd Möllmann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> BTW, this comment in process_mark_stack isn't true because of
>> DEFVAR_LISP_NOPRO:
>>
>> 	      case SYMBOL_FORWARDED:
>> 		/* If the value is forwarded to a buffer or keyboard field,
>> 		   these are marked when we see the corresponding object.
>> 		   And if it's forwarded to a C variable, either it's not
>> 		   a Lisp_Object var, or it's staticpro'd already.  */
>
> Yeah, it should be completed with "or it's reachable from
> `font_style_table` which is also staticpro'd" 🙁

Buhut... after fixing my fixing functions:

Loading /Users/gerd/emacs/github/igc/lisp/emacs-lisp/cconv.el (source)...
*** MPS GC start: Generation 0 of a chain has reached capacity: start a minor collection.
*** MPS GC start: Generation 0 of a chain has reached capacity: start a minor collection.
Loading /Users/gerd/emacs/github/igc/lisp/cus-start.el (source)...
Loading /Users/gerd/emacs/github/igc/lisp/tooltip.el (source)...
Loading /Users/gerd/emacs/github/igc/lisp/international/iso-transl.el (source)...
Loading /Users/gerd/emacs/github/igc/lisp/emacs-lisp/rmc.el (source)...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name bootstrap-emacs.pdmp
Dumping fingerprint: b5f4eba29e5aaa696eb0cd505f3c894794b520617dfa65b7e8f5dff42eb84e4b
Dump complete (8.49 seconds)
Byte counts: header=100 hot=18219148 discardable=155616 cold=12918304
Reloc counts: hot=1269818 discardable=8081

Alas

ANCIENT=yes gmake -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
'../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp  -f batch-byte-compile emacs-lisp/macroexp.el
bootstrap-emacs(1160,0x7ff857900100) malloc: *** error for object 0x182e91e40: pointer being freed was not allocated
bootstrap-emacs(1160,0x7ff857900100) malloc: *** set a breakpoint in malloc_error_break to debug
Fatal error 6: Aborted

Only 87873464531 problems remaining ;-)

Re: Question about DEFVAR_LISP_NOPRO

[Stefan Monnier]

> Buhut... after fixing my fixing functions:
>
> Loading /Users/gerd/emacs/github/igc/lisp/emacs-lisp/cconv.el (source)...
> *** MPS GC start: Generation 0 of a chain has reached capacity: start a minor collection.
> *** MPS GC start: Generation 0 of a chain has reached capacity: start a minor collection.
> Loading /Users/gerd/emacs/github/igc/lisp/cus-start.el (source)...
> Loading /Users/gerd/emacs/github/igc/lisp/tooltip.el (source)...
> Loading /Users/gerd/emacs/github/igc/lisp/international/iso-transl.el (source)...
> Loading /Users/gerd/emacs/github/igc/lisp/emacs-lisp/rmc.el (source)...
> Finding pointers to doc strings...
> Finding pointers to doc strings...done
> Dumping under the name bootstrap-emacs.pdmp
> Dumping fingerprint: b5f4eba29e5aaa696eb0cd505f3c894794b520617dfa65b7e8f5dff42eb84e4b
> Dump complete (8.49 seconds)
> Byte counts: header=100 hot=18219148 discardable=155616 cold=12918304
> Reloc counts: hot=1269818 discardable=8081

Yay!

> ANCIENT=yes gmake -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
> '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp  -f
> batch-byte-compile emacs-lisp/macroexp.el
> bootstrap-emacs(1160,0x7ff857900100) malloc: *** error for object
> 0x182e91e40: pointer being freed was not allocated
> bootstrap-emacs(1160,0x7ff857900100) malloc: *** set a breakpoint in malloc_error_break to debug
> Fatal error 6: Aborted
>
> Only 87873464531 problems remaining ;-)

Almost there.


        Stefan

Re: Question about DEFVAR_LISP_NOPRO

[K. Handa]

In article <jwvil0vbx6t.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >   DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table,
> >                  doc: /*  Vector of valid font weight values. ... */);
> >     Vfont_weight_table = BUILD_STYLE_TABLE (weight_table);
> >     make_symbol_constant (intern_c_string ("font-weight-table"));
> >
> > Here a symbol is defined which has a value that is forwarded to the
> > static globals.f_Vfont_weight_table, but that static is not staticpro'd.
> >
> > My question is simply: What the heck?

> I think only Kenichi knows the real answer (commit d0ab1ebe49f7), but my
> guess is that it was just an optimization because those vars always
> refer to each of the three elements of the `font_style_table` which *is*
> gcpro'd and is not exposed to ELisp so we know that a non-moving GC doesn't
> need to know about those vars.

As far as I remember, Stefan is right, it was for optimization.

---
K. Handa
handa@gnu.org

Re: Question about DEFVAR_LISP_NOPRO

[Gerd Möllmann]

"K. Handa" <handa@gnu.org> writes:

> In article <jwvil0vbx6t.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> >   DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table,
>> >                  doc: /*  Vector of valid font weight values. ... */);
>> >     Vfont_weight_table = BUILD_STYLE_TABLE (weight_table);
>> >     make_symbol_constant (intern_c_string ("font-weight-table"));
>> >
>> > Here a symbol is defined which has a value that is forwarded to the
>> > static globals.f_Vfont_weight_table, but that static is not staticpro'd.
>> >
>> > My question is simply: What the heck?
>
>> I think only Kenichi knows the real answer (commit d0ab1ebe49f7), but my
>> guess is that it was just an optimization because those vars always
>> refer to each of the three elements of the `font_style_table` which *is*
>> gcpro'd and is not exposed to ELisp so we know that a non-moving GC doesn't
>> need to know about those vars.
>
> As far as I remember, Stefan is right, it was for optimization.

Thanks.