Pure nil and t?

Pure nil and t?

[Dmitry Antipov]

For a long byte-compile runs, ~15-17% of objects seen by GC are nil and t
(especially nil, which is ~10x more "popular" than t).  What about making
them pure?  Thus way they will be quickly filtered out by PURE_POINTER_P
check in mark_object, thus offloading GC from an in-depth examination of
them each time when they're found.

Dmitry

Re: Pure nil and t?

[David Kastrup]

Dmitry Antipov <dmantipov@yandex.ru> writes:

> For a long byte-compile runs, ~15-17% of objects seen by GC are nil and t
> (especially nil, which is ~10x more "popular" than t).  What about making
> them pure?  Thus way they will be quickly filtered out by PURE_POINTER_P
> check in mark_object, thus offloading GC from an in-depth examination of
> them each time when they're found.

In my Emacs I see
M-: (symbol-plist nil) RET
(event-symbol-element-mask (nil 0) event-symbol-elements (nil) modifier-cache ((0)))
M-: (symbol-plist t) RET
(event-symbol-element-mask (t 0) event-symbol-elements (t) modifier-cache ((0 . t)))

While I consider it likely that those are the result of glitches and/or
bugs, it would be nice if those glitches did not lead to crashes by
letting these plists get collected in spite of being accessible.

I have no idea whether this would be the case.  It's just that I can
imagine it to be.

-- 
David Kastrup

Re: Pure nil and t?

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Dmitry Antipov <dmantipov@yandex.ru> writes:
>
>> For a long byte-compile runs, ~15-17% of objects seen by GC are nil and t
>> (especially nil, which is ~10x more "popular" than t).  What about making
>> them pure?  Thus way they will be quickly filtered out by PURE_POINTER_P
>> check in mark_object, thus offloading GC from an in-depth examination of
>> them each time when they're found.
>
> In my Emacs I see
> M-: (symbol-plist nil) RET
> (event-symbol-element-mask (nil 0) event-symbol-elements (nil) modifier-cache ((0)))
> M-: (symbol-plist t) RET
> (event-symbol-element-mask (t 0) event-symbol-elements (t) modifier-cache ((0 . t)))
>
> While I consider it likely that those are the result of glitches and/or
> bugs, it would be nice if those glitches did not lead to crashes by
> letting these plists get collected in spite of being accessible.

They probably would have to be made pure as well, and checks would have
to be added to not try to modify any of the fields of a pure symbol.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."