GNU bug report logs -
#70796
30.0.50; bug-reference-mode leading to constant GCing
Previous Next
To reply to this bug, email your comments to 70796 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 06 May 2024 06:55:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Gerd Möllmann <gerd.moellmann <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 06 May 2024 06:55:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
This is in an Emacs compiled from the branch scratch/igc, but I see the
same in master.
When loading admin/igc.org in scratch/igc I see very frequent GC, even
while doing nothing at all. Memory profiler shows this
4,192,076,326 68% - redisplay_internal (C function)
2,997,520,400 48% - jit-lock-function
2,997,520,400 48% - jit-lock-fontify-now
2,982,457,616 48% - jit-lock--run-functions
2,982,457,616 48% - run-hook-wrapped
2,982,457,616 48% - #<compiled-function 8A7>
2,769,181,376 45% - font-lock-fontify-region
2,769,181,376 45% - font-lock-default-fontify-region
2,707,362,176 44% - font-lock-fontify-keywords-region
276,400,512 4% + org-do-emphasis-faces
197,821,440 3% + org-fontify-drawers
197,821,440 3% + org-activate-links
197,821,440 3% + org-activate-tags
197,821,440 3% + org-activate-dates
197,821,440 3% + org-activate-footnote-links
197,821,440 3% + org-fontify-macros
197,821,440 3% + org-font-lock-add-priority-faces
197,821,440 3% + org-do-latex-and-related
197,821,440 3% + org-activate-code
197,821,440 3% + org-fontify-meta-lines-and-blocks
197,821,440 3% + org-fontify-inline-src-blocks
197,821,440 3% + org-cite-activate
57,104,384 0% re-search-forward
61,819,200 1% + font-lock-unfontify-region
213,276,240 3% + bug-reference-fontify
15,062,784 0% - run-with-timer
15,062,784 0% + apply
97,280 0% + file-remote-p
336 0% + desktop-auto-save-set-timer
144 0% + tab-bar-make-keymap
1,955,072,562 31% + command-execute
129,456 0% + timer-event-handler
1,024 0% + corfu--auto-post-command
0 0% ...
Disabling bug-reference-mode in the Org buffer makes it stop constantly
GCing.
In GNU Emacs 30.0.50 (build 4, aarch64-apple-darwin23.4.0, NS
appkit-2487.50 Version 14.4.1 (Build 23E224)) of 2024-05-06 built on
pro2.fritz.box
Repository revision: 5067d5484f80ac39d9aa57bd53343e335b744003
Repository branch: scratch/igc
Windowing system distributor 'Apple', version 10.3.2487
System Description: macOS 14.4.1
Configured using:
'configure --cache-file
/var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.igc
--with-native-compilation=no --with-mps=yes CC=clang'
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 06 May 2024 11:50:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 70796 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Mon, 06 May 2024 08:53:29 +0200
>
> This is in an Emacs compiled from the branch scratch/igc, but I see the
> same in master.
>
> When loading admin/igc.org in scratch/igc I see very frequent GC, even
> while doing nothing at all. Memory profiler shows this
>
> 4,192,076,326 68% - redisplay_internal (C function)
> 2,997,520,400 48% - jit-lock-function
> 2,997,520,400 48% - jit-lock-fontify-now
> 2,982,457,616 48% - jit-lock--run-functions
> 2,982,457,616 48% - run-hook-wrapped
> 2,982,457,616 48% - #<compiled-function 8A7>
> 2,769,181,376 45% - font-lock-fontify-region
> 2,769,181,376 45% - font-lock-default-fontify-region
> 2,707,362,176 44% - font-lock-fontify-keywords-region
> 276,400,512 4% + org-do-emphasis-faces
> 197,821,440 3% + org-fontify-drawers
> 197,821,440 3% + org-activate-links
> 197,821,440 3% + org-activate-tags
> 197,821,440 3% + org-activate-dates
> 197,821,440 3% + org-activate-footnote-links
> 197,821,440 3% + org-fontify-macros
> 197,821,440 3% + org-font-lock-add-priority-faces
> 197,821,440 3% + org-do-latex-and-related
> 197,821,440 3% + org-activate-code
> 197,821,440 3% + org-fontify-meta-lines-and-blocks
> 197,821,440 3% + org-fontify-inline-src-blocks
> 197,821,440 3% + org-cite-activate
> 57,104,384 0% re-search-forward
> 61,819,200 1% + font-lock-unfontify-region
> 213,276,240 3% + bug-reference-fontify
> 15,062,784 0% - run-with-timer
> 15,062,784 0% + apply
> 97,280 0% + file-remote-p
> 336 0% + desktop-auto-save-set-timer
> 144 0% + tab-bar-make-keymap
> 1,955,072,562 31% + command-execute
> 129,456 0% + timer-event-handler
> 1,024 0% + corfu--auto-post-command
> 0 0% ...
Where's the evidence of "frequent GC" in this profile?
(And "memory profile" has nothing to do with memory usage, contrary to
popular belief.)
> Disabling bug-reference-mode in the Org buffer makes it stop constantly
> GCing.
I believe you. But showing the number of GCs (e.g., using the
variable gcs-done) would tell us the story more convincingly.
Alternatively, if you can share an Org file where this could be seen,
please do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 06 May 2024 12:37:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Mon, 06 May 2024 08:53:29 +0200
>>
>> This is in an Emacs compiled from the branch scratch/igc, but I see the
>> same in master.
>>
>> When loading admin/igc.org in scratch/igc I see very frequent GC, even
>> while doing nothing at all. Memory profiler shows this
>>
>> 4,192,076,326 68% - redisplay_internal (C function)
>> 2,997,520,400 48% - jit-lock-function
>> 2,997,520,400 48% - jit-lock-fontify-now
>> 2,982,457,616 48% - jit-lock--run-functions
>> 2,982,457,616 48% - run-hook-wrapped
>> 2,982,457,616 48% - #<compiled-function 8A7>
>> 2,769,181,376 45% - font-lock-fontify-region
>> 2,769,181,376 45% - font-lock-default-fontify-region
>> 2,707,362,176 44% - font-lock-fontify-keywords-region
>> 276,400,512 4% + org-do-emphasis-faces
>> 197,821,440 3% + org-fontify-drawers
>> 197,821,440 3% + org-activate-links
>> 197,821,440 3% + org-activate-tags
>> 197,821,440 3% + org-activate-dates
>> 197,821,440 3% + org-activate-footnote-links
>> 197,821,440 3% + org-fontify-macros
>> 197,821,440 3% + org-font-lock-add-priority-faces
>> 197,821,440 3% + org-do-latex-and-related
>> 197,821,440 3% + org-activate-code
>> 197,821,440 3% + org-fontify-meta-lines-and-blocks
>> 197,821,440 3% + org-fontify-inline-src-blocks
>> 197,821,440 3% + org-cite-activate
>> 57,104,384 0% re-search-forward
>> 61,819,200 1% + font-lock-unfontify-region
>> 213,276,240 3% + bug-reference-fontify
>> 15,062,784 0% - run-with-timer
>> 15,062,784 0% + apply
>> 97,280 0% + file-remote-p
>> 336 0% + desktop-auto-save-set-timer
>> 144 0% + tab-bar-make-keymap
>> 1,955,072,562 31% + command-execute
>> 129,456 0% + timer-event-handler
>> 1,024 0% + corfu--auto-post-command
>> 0 0% ...
>
> Where's the evidence of "frequent GC" in this profile?
I didn't say the profile is evidence of frequent GCs.
> (And "memory profile" has nothing to do with memory usage, contrary to
> popular belief.)
>
>> Disabling bug-reference-mode in the Org buffer makes it stop constantly
>> GCing.
>
> I believe you. But showing the number of GCs (e.g., using the
> variable gcs-done) would tell us the story more convincingly.
> Alternatively, if you can share an Org file where this could be seen,
> please do.
So, believe me. Or not, as you please. I said where the Org file is at
the beginning.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 06 May 2024 14:05:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 70796 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 70796 <at> debbugs.gnu.org
> Date: Mon, 06 May 2024 14:35:42 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Where's the evidence of "frequent GC" in this profile?
>
> I didn't say the profile is evidence of frequent GCs.
>
> > (And "memory profile" has nothing to do with memory usage, contrary to
> > popular belief.)
> >
> >> Disabling bug-reference-mode in the Org buffer makes it stop constantly
> >> GCing.
> >
> > I believe you. But showing the number of GCs (e.g., using the
> > variable gcs-done) would tell us the story more convincingly.
> > Alternatively, if you can share an Org file where this could be seen,
> > please do.
>
> So, believe me. Or not, as you please. I said where the Org file is at
> the beginning.
Ah, okay, sorry for missing that.
I tried to scroll through that with Emacs 30 from master, and here's
the CPU profile:
20 74% Automatic GC
4 14% - command-execute
4 14% - call-interactively
2 7% - funcall-interactively
2 7% - scroll-up-command
2 7% scroll-up
2 7% - byte-code
2 7% - read-extended-command
2 7% - read-extended-command-1
2 7% - completing-read
2 7% - completing-read-default
2 7% - read-from-minibuffer
2 7% redisplay_internal (C function)
3 11% redisplay_internal (C function)
0 0% ...
I get roughly one GC cycle per full scroll top to bottom.
Interestingly, bug-reference-fontify is not in the profile, perhaps
because it's lower-resolution than on your system with "memory"
profiler.
And here's the profile with bug-reference-mode turned off:
15 48% Automatic GC
8 25% redisplay_internal (C function)
8 25% - command-execute
8 25% - call-interactively
4 12% - funcall-interactively
3 9% - scroll-down-command
3 9% scroll-down
1 3% - scroll-up-command
1 3% scroll-up
4 12% - byte-code
3 9% - read--expression
3 9% - read-from-minibuffer
2 6% redisplay_internal (C function)
1 3% - read-extended-command
1 3% - read-extended-command-1
1 3% - completing-read
1 3% - completing-read-default
1 3% - read-from-minibuffer
1 3% redisplay_internal (C function)
0 0% ...
This does fewer GCs (about 75% of what I see with bug-reference-mode
turned ON), but not by a large factor.
Looking at bug-reference-fontify, I see that it conses a string -- but
it only does that when it finds a match for bug-reference-bug-regexp,
and there are no such matches in igc.org on the branch, AFAICT.
So I'm not sure which part(s) of bug-reference.el make a lot of
garbage, or why.
Ihor, any ideas?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 06 May 2024 14:10:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> So I'm not sure which part(s) of bug-reference.el make a lot of
> garbage, or why.
This maybe completely wrong, but my suspicion was that bug-reference
somehow triggers Org fontification, which creates more garbage. If
that's possible...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Tue, 07 May 2024 07:00:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> So I'm not sure which part(s) of bug-reference.el make a lot of
>> garbage, or why.
>
> This maybe completely wrong, but my suspicion was that bug-reference
> somehow triggers Org fontification, which creates more garbage. If
> that's possible...
Maybe bug-reference-fontify should return a list (jit-lock-bounds beg
end)? Looks to me like if it doesn't we could end up fontifying the
whole buffer for Org. See jit-lock--run-functions.
Not sure but the behaviour looks like somethign like that could be
happening.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 18 May 2024 06:29:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>> So I'm not sure which part(s) of bug-reference.el make a lot of
>>> garbage, or why.
>>
>> This maybe completely wrong, but my suspicion was that bug-reference
>> somehow triggers Org fontification, which creates more garbage. If
>> that's possible...
>
> Maybe bug-reference-fontify should return a list (jit-lock-bounds beg
> end)? Looks to me like if it doesn't we could end up fontifying the
> whole buffer for Org. See jit-lock--run-functions.
>
> Not sure but the behaviour looks like somethign like that could be
> happening.
Ping
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 18 May 2024 08:09:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 70796 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Ihor Radchenko <yantar92 <at> posteo.net>, 70796 <at> debbugs.gnu.org
> Date: Sat, 18 May 2024 08:27:15 +0200
>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >>> So I'm not sure which part(s) of bug-reference.el make a lot of
> >>> garbage, or why.
> >>
> >> This maybe completely wrong, but my suspicion was that bug-reference
> >> somehow triggers Org fontification, which creates more garbage. If
> >> that's possible...
> >
> > Maybe bug-reference-fontify should return a list (jit-lock-bounds beg
> > end)? Looks to me like if it doesn't we could end up fontifying the
> > whole buffer for Org. See jit-lock--run-functions.
> >
> > Not sure but the behaviour looks like somethign like that could be
> > happening.
>
> Ping
Tassilo, could you please take a look at this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 18 May 2024 15:50:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Hi all,
it's the first day of my vacation so I'm away from the computer until next Saturday evening at best. But then I'll have a look.
Bye,
Tassilo
Am Sa, 18. Mai 2024, um 10:07, schrieb Eli Zaretskii:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Ihor Radchenko <yantar92 <at> posteo.net>, 70796 <at> debbugs.gnu.org
>> Date: Sat, 18 May 2024 08:27:15 +0200
>>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>> >
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >>
>> >>> So I'm not sure which part(s) of bug-reference.el make a lot of
>> >>> garbage, or why.
>> >>
>> >> This maybe completely wrong, but my suspicion was that bug-reference
>> >> somehow triggers Org fontification, which creates more garbage. If
>> >> that's possible...
>> >
>> > Maybe bug-reference-fontify should return a list (jit-lock-bounds beg
>> > end)? Looks to me like if it doesn't we could end up fontifying the
>> > whole buffer for Org. See jit-lock--run-functions.
>> >
>> > Not sure but the behaviour looks like somethign like that could be
>> > happening.
>>
>> Ping
>
> Tassilo, could you please take a look at this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Fri, 24 May 2024 20:01:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi all,
I'm back and had a look at this issue.
>> > Maybe bug-reference-fontify should return a list (jit-lock-bounds
>> > beg end)?
Indeed, that's what I'm doing now. I'm not entirely sure if that fixes
the GC issue but it's certainly a good idea anyhow.
Please report back if it helps.
Thanks,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Fri, 24 May 2024 20:21:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Tassilo Horn <tsdh <at> gnu.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi all,
>
> I'm back and had a look at this issue.
>
>>> > Maybe bug-reference-fontify should return a list (jit-lock-bounds
>>> > beg end)?
>
> Indeed, that's what I'm doing now. I'm not entirely sure if that fixes
> the GC issue but it's certainly a good idea anyhow.
>
> Please report back if it helps.
I'm afraid it didn't help yet. It's still GCing constantly, without
doing anything.
(I used your fix in a running Emacs, with the following change:
modified lisp/progmodes/bug-reference.el
@@ -196,10 +196,10 @@ bug-reference-fontify
(funcall bug-reference-url-format)))))))
;; Delete remaining but unused overlays.
(dolist (ov overlays)
- (delete-overlay ov)))
- ;; Signal the bounds we actually fontified to jit-lock to allow for
- ;; optimizations (bug#70796).
- `(jit-lock-bounds ,beg-line . ,end-line)))
+ (delete-overlay ov))
+ ;; Signal the bounds we actually fontified to jit-lock to allow for
+ ;; optimizations (bug#70796).
+ `(jit-lock-bounds ,beg-line . ,end-line))))
;; Taken from button.el.
(defun bug-reference-push-button (&optional pos _use-mouse-action)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Fri, 24 May 2024 20:28:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> I'm afraid it didn't help yet. It's still GCing constantly, without
> doing anything.
FYI, I have no problems on your file and I do have bug-reference-mode
enabled in all buffers.
Do you have a recipe starting from emacs -Q?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Fri, 24 May 2024 21:35:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>> Please report back if it helps.
>
> I'm afraid it didn't help yet. It's still GCing constantly, without
> doing anything.
>
> (I used your fix in a running Emacs, with the following change:
Oups. Fixed on master.
But anyhow, I don't see how bug-reference-fontify could be so costly
GC-wise...
FWIW, I think goto-address-mode (buttonizing URLs and email addresses)
will probably have the same effect, at least the code looks pretty
similar. Can you confirm?
I'll have a look at you sample file tomorrow. How do you make GCs
"visible" so that I can see when excessive GCing starts/stops?
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 25 May 2024 04:11:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Ihor Radchenko <yantar92 <at> posteo.net> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> I'm afraid it didn't help yet. It's still GCing constantly, without
>> doing anything.
>
> FYI, I have no problems on your file and I do have bug-reference-mode
> enabled in all buffers.
>
> Do you have a recipe starting from emacs -Q?
Not at the moment, sorry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 25 May 2024 04:36:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 70796 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tassilo Horn <tsdh <at> gnu.org> writes:
> But anyhow, I don't see how bug-reference-fontify could be so costly
> GC-wise...
It is not by itself, AFAICT. Org fontification allocates which ich not a
problem normally, but with bug-reference active, it is triggered over
and over again.
Interesting observation:
I just built master without native compilation because that's faster.
With .elcs only, I don't seem to get the constant GCs with
9ebe6aa5f1092241a98e0a16db918e3dc1062f1c which is before your fix.
With native compilation I do.
Just double-checked that this is indeed the case. Now it gets
interesting :-/. This is on macOS 14.5, arm64, libgccjit 14.1.
> FWIW, I think goto-address-mode (buttonizing URLs and email addresses)
> will probably have the same effect, at least the code looks pretty
> similar. Can you confirm?
Yes, goto-address-mode has the same effect.
>
> I'll have a look at you sample file tomorrow. How do you make GCs
> "visible" so that I can see when excessive GCing starts/stops?
You can use the attached patch to log GC messages in *Messages* which
makes it easier to see. Then load the Org file, expand all nodes (S-TAB
as needed), move a bit around, and see it happening. And set
garbage-collection-messages to t of course.
[0001-On-no-branch-9ebe6aa5f10-lisp-dired.el-dired-mode-map-Bind-E-to-dired-do-open-bug-18132.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 25 May 2024 07:38:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>> But anyhow, I don't see how bug-reference-fontify could be so costly
>> GC-wise...
>
> It is not by itself, AFAICT. Org fontification allocates which ich not
> a problem normally, but with bug-reference active, it is triggered
> over and over again.
>
> Interesting observation:
>
> I just built master without native compilation because that's faster.
> With .elcs only, I don't seem to get the constant GCs with
> 9ebe6aa5f1092241a98e0a16db918e3dc1062f1c which is before your fix.
> With native compilation I do.
>
> Just double-checked that this is indeed the case. Now it gets
> interesting :-/. This is on macOS 14.5, arm64, libgccjit 14.1.
I've now checked out the scratch/igc branch and opened admin/igc.org
with the current emacs (master branch) with native compilation + your
gc-messages patch and garbage-collection-messages set to t. I cannot
reproduce the problem.
I've also added a (message "BRF") as first expression to
bug-reference-fontify. After scrolling the buffer from top to bottom,
the function won't be called anymore unless I edit some text. I assume
that in your case, bug-reference-fontify and font-lock-fontify-region
(the latter including the Org fontification) are run over and over again
unless you remove the former...
I have no explanation. Especially with admin/igc.org,
bug-reference-fontify is essentially a no-op. There are no bug
references (text matching bug-reference-bug-regexp), so it's just a
regex search with no match and there are no overlays created or moved.
How can a failed regex search somehow trigger another jit-lock cycle
(and only with native compilation on MacOS)?
>> FWIW, I think goto-address-mode (buttonizing URLs and email addresses)
>> will probably have the same effect, at least the code looks pretty
>> similar. Can you confirm?
>
> Yes, goto-address-mode has the same effect.
Alright. Then you can probably even simplify the issue with
--8<---------------cut here---------------start------------->8---
(defun i-do-nothing (start end) nil)
--8<---------------cut here---------------end--------------->8---
and then M-: (jit-lock-register #'i-do-nothing) RET in some buffer,
right?
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 25 May 2024 08:00:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Tassilo Horn <tsdh <at> gnu.org> writes:
>>> FWIW, I think goto-address-mode (buttonizing URLs and email addresses)
>>> will probably have the same effect, at least the code looks pretty
>>> similar. Can you confirm?
>>
>> Yes, goto-address-mode has the same effect.
>
> Alright. Then you can probably even simplify the issue with
>
> (defun i-do-nothing (start end) nil)
>
> and then M-: (jit-lock-register #'i-do-nothing) RET in some buffer,
> right?
Yes, same problem. In a native build with current HEAD,
984fb346fdf0d5ec9eaea6126aad0bea8823b8a3.
As I mentioned, no problem without native compilation. I guess you have
an x86 cpu? Just to make sure...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 25 May 2024 08:18:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Yes, right, x86 on GNU/Linux.
Am Sa, 25. Mai 2024, um 09:58, schrieb Gerd Möllmann:
> Tassilo Horn <tsdh <at> gnu.org> writes:
>
>>>> FWIW, I think goto-address-mode (buttonizing URLs and email addresses)
>>>> will probably have the same effect, at least the code looks pretty
>>>> similar. Can you confirm?
>>>
>>> Yes, goto-address-mode has the same effect.
>>
>> Alright. Then you can probably even simplify the issue with
>>
>> (defun i-do-nothing (start end) nil)
>>
>> and then M-: (jit-lock-register #'i-do-nothing) RET in some buffer,
>> right?
>
> Yes, same problem. In a native build with current HEAD,
> 984fb346fdf0d5ec9eaea6126aad0bea8823b8a3.
>
> As I mentioned, no problem without native compilation. I guess you have
> an x86 cpu? Just to make sure...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 01 Jun 2024 09:07:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 70796 <at> debbugs.gnu.org (full text, mbox):
"Tassilo Horn" <tsdh <at> gnu.org> writes:
> Yes, right, x86 on GNU/Linux.
>
> Am Sa, 25. Mai 2024, um 09:58, schrieb Gerd Möllmann:
>> Tassilo Horn <tsdh <at> gnu.org> writes:
>>
>>>>> FWIW, I think goto-address-mode (buttonizing URLs and email addresses)
>>>>> will probably have the same effect, at least the code looks pretty
>>>>> similar. Can you confirm?
>>>>
>>>> Yes, goto-address-mode has the same effect.
>>>
>>> Alright. Then you can probably even simplify the issue with
>>>
>>> (defun i-do-nothing (start end) nil)
>>>
>>> and then M-: (jit-lock-register #'i-do-nothing) RET in some buffer,
>>> right?
>>
>> Yes, same problem. In a native build with current HEAD,
>> 984fb346fdf0d5ec9eaea6126aad0bea8823b8a3.
>>
>> As I mentioned, no problem without native compilation. I guess you have
>> an x86 cpu? Just to make sure...
Another data point: when building with native-comp-speed 0, the
problem is also gone.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 15 Jun 2024 07:55:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Ping! Can we make some further progress here?
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70796 <at> debbugs.gnu.org, Ihor Radchenko
> <yantar92 <at> posteo.net>
> Date: Sat, 01 Jun 2024 11:05:10 +0200
>
> "Tassilo Horn" <tsdh <at> gnu.org> writes:
>
> > Yes, right, x86 on GNU/Linux.
> >
> > Am Sa, 25. Mai 2024, um 09:58, schrieb Gerd Möllmann:
> >> Tassilo Horn <tsdh <at> gnu.org> writes:
> >>
> >>>>> FWIW, I think goto-address-mode (buttonizing URLs and email addresses)
> >>>>> will probably have the same effect, at least the code looks pretty
> >>>>> similar. Can you confirm?
> >>>>
> >>>> Yes, goto-address-mode has the same effect.
> >>>
> >>> Alright. Then you can probably even simplify the issue with
> >>>
> >>> (defun i-do-nothing (start end) nil)
> >>>
> >>> and then M-: (jit-lock-register #'i-do-nothing) RET in some buffer,
> >>> right?
> >>
> >> Yes, same problem. In a native build with current HEAD,
> >> 984fb346fdf0d5ec9eaea6126aad0bea8823b8a3.
> >>
> >> As I mentioned, no problem without native compilation. I guess you have
> >> an x86 cpu? Just to make sure...
>
> Another data point: when building with native-comp-speed 0, the
> problem is also gone.
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sat, 15 Jun 2024 08:09:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Ping! Can we make some further progress here?
>
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70796 <at> debbugs.gnu.org, Ihor Radchenko
>> <yantar92 <at> posteo.net>
>> Date: Sat, 01 Jun 2024 11:05:10 +0200
>>
>> "Tassilo Horn" <tsdh <at> gnu.org> writes:
>>
>> > Yes, right, x86 on GNU/Linux.
>> >
>> > Am Sa, 25. Mai 2024, um 09:58, schrieb Gerd Möllmann:
>> >> Tassilo Horn <tsdh <at> gnu.org> writes:
>> >>
>> >>>>> FWIW, I think goto-address-mode (buttonizing URLs and email addresses)
>> >>>>> will probably have the same effect, at least the code looks pretty
>> >>>>> similar. Can you confirm?
>> >>>>
>> >>>> Yes, goto-address-mode has the same effect.
>> >>>
>> >>> Alright. Then you can probably even simplify the issue with
>> >>>
>> >>> (defun i-do-nothing (start end) nil)
>> >>>
>> >>> and then M-: (jit-lock-register #'i-do-nothing) RET in some buffer,
>> >>> right?
>> >>
>> >> Yes, same problem. In a native build with current HEAD,
>> >> 984fb346fdf0d5ec9eaea6126aad0bea8823b8a3.
>> >>
>> >> As I mentioned, no problem without native compilation. I guess you have
>> >> an x86 cpu? Just to make sure...
>>
>> Another data point: when building with native-comp-speed 0, the
>> problem is also gone.
>>
No progress in this matter from my side. I don't know what's going on.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sun, 16 Jun 2024 09:46:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> No progress in this matter from my side. I don't know what's going on.
Same here. The issue went from "bug-reference-mode leading to constant
GC-ing" to "any (additional) function (including a no-op function) in
jit-lock-functions leads to constant GC-ing on MacOS but only with
native compilation and only when native-comp-speed > 0." I feel
responsible for bug-reference-mode but Mac-specific issues during
redisplay that only happen with native-compilation are out of by
expertise, sorry.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Sun, 16 Jun 2024 10:45:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 70796 <at> debbugs.gnu.org (full text, mbox):
> From: Tassilo Horn <tsdh <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70796 <at> debbugs.gnu.org, yantar92 <at> posteo.net
> Date: Sun, 16 Jun 2024 11:45:16 +0200
>
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> > No progress in this matter from my side. I don't know what's going on.
>
> Same here. The issue went from "bug-reference-mode leading to constant
> GC-ing" to "any (additional) function (including a no-op function) in
> jit-lock-functions leads to constant GC-ing on MacOS but only with
> native compilation and only when native-comp-speed > 0." I feel
> responsible for bug-reference-mode but Mac-specific issues during
> redisplay that only happen with native-compilation are out of by
> expertise, sorry.
Andrea, could you perhaps look into this?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 07:35:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Tassilo Horn <tsdh <at> gnu.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70796 <at> debbugs.gnu.org, yantar92 <at> posteo.net
>> Date: Sun, 16 Jun 2024 11:45:16 +0200
>>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>> > No progress in this matter from my side. I don't know what's going on.
>>
>> Same here. The issue went from "bug-reference-mode leading to constant
>> GC-ing" to "any (additional) function (including a no-op function) in
>> jit-lock-functions leads to constant GC-ing on MacOS but only with
>> native compilation and only when native-comp-speed > 0." I feel
>> responsible for bug-reference-mode but Mac-specific issues during
>> redisplay that only happen with native-compilation are out of by
>> expertise, sorry.
>
> Andrea, could you perhaps look into this?
I'll be happy to look into it but I don't use MacOS and AFAIR Tassilo
mentioned it's not reproducible on x86 (GNU/Linux?).
I'll give it try here as well, but also to me the reproducer itself is
not 100% clear.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 08:09:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Tassilo Horn <tsdh <at> gnu.org>
>>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70796 <at> debbugs.gnu.org, yantar92 <at> posteo.net
>>> Date: Sun, 16 Jun 2024 11:45:16 +0200
>>>
>>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>>
>>> > No progress in this matter from my side. I don't know what's going on.
>>>
>>> Same here. The issue went from "bug-reference-mode leading to constant
>>> GC-ing" to "any (additional) function (including a no-op function) in
>>> jit-lock-functions leads to constant GC-ing on MacOS but only with
>>> native compilation and only when native-comp-speed > 0." I feel
>>> responsible for bug-reference-mode but Mac-specific issues during
>>> redisplay that only happen with native-compilation are out of by
>>> expertise, sorry.
>>
>> Andrea, could you perhaps look into this?
>
> I'll be happy to look into it but I don't use MacOS and AFAIR Tassilo
> mentioned it's not reproducible on x86 (GNU/Linux?).
>
> I'll give it try here as well, but also to me the reproducer itself is
> not 100% clear.
>
> Andrea
Okay, so this is what I tried:
I bootstrapped two Emacs from current master (7be66d8223e) one
--with-native-compilation=yes the other --with-native-compilation=no and
boths with Gerd patch applied.
Also I checkout current scratch/igc (2343d55dff4) to get igc.org.
I then tried to run with boths native/non-native emacsen with:
.../src/emacs -eval '(setq garbage-collection-messages t)' -Q ~/emacs4/admin/igc.org
Once started looking in *Messages* I see 7 GC cycles in the the
non-native build and 5 in the native one, also I can scroll without
issues or other GC cycles.
Note that only during the first start the native copiled Emacs did a
number of GC cycles more to jit some code but I guess that's expected.
Am I trying to repruduce this correctly?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 08:20:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Okay, so this is what I tried:
>
> I bootstrapped two Emacs from current master (7be66d8223e) one
> --with-native-compilation=yes the other --with-native-compilation=no
> and boths with Gerd patch applied.
>
> Also I checkout current scratch/igc (2343d55dff4) to get igc.org.
>
> I then tried to run with boths native/non-native emacsen with:
>
> .../src/emacs -eval '(setq garbage-collection-messages t)' -Q
> ~/emacs4/admin/igc.org
>
> Once started looking in *Messages* I see 7 GC cycles in the the
> non-native build and 5 in the native one, also I can scroll without
> issues or other GC cycles.
>
> Note that only during the first start the native copiled Emacs did a
> number of GC cycles more to jit some code but I guess that's expected.
>
> Am I trying to repruduce this correctly?
Yes. And you also need to put some function in addition to
font-lock-fontify-region in jit-lock-functions, either by enabling
bug-reference-mode, goto-address-mode, or simply defining
(defun i-do-nothing (start end) nil)
and then M-: (jit-lock-register #'i-do-nothing) RET in the igc.org
buffer.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 08:23:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> From: Tassilo Horn <tsdh <at> gnu.org>
>>>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 70796 <at> debbugs.gnu.org, yantar92 <at> posteo.net
>>>> Date: Sun, 16 Jun 2024 11:45:16 +0200
>>>>
>>>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>>>
>>>> > No progress in this matter from my side. I don't know what's going on.
>>>>
>>>> Same here. The issue went from "bug-reference-mode leading to constant
>>>> GC-ing" to "any (additional) function (including a no-op function) in
>>>> jit-lock-functions leads to constant GC-ing on MacOS but only with
>>>> native compilation and only when native-comp-speed > 0." I feel
>>>> responsible for bug-reference-mode but Mac-specific issues during
>>>> redisplay that only happen with native-compilation are out of by
>>>> expertise, sorry.
>>>
>>> Andrea, could you perhaps look into this?
>>
>> I'll be happy to look into it but I don't use MacOS and AFAIR Tassilo
>> mentioned it's not reproducible on x86 (GNU/Linux?).
>>
>> I'll give it try here as well, but also to me the reproducer itself is
>> not 100% clear.
>>
>> Andrea
>
> Okay, so this is what I tried:
>
> I bootstrapped two Emacs from current master (7be66d8223e) one
> --with-native-compilation=yes the other --with-native-compilation=no and
> boths with Gerd patch applied.
>
> Also I checkout current scratch/igc (2343d55dff4) to get igc.org.
>
> I then tried to run with boths native/non-native emacsen with:
>
> .../src/emacs -eval '(setq garbage-collection-messages t)' -Q ~/emacs4/admin/igc.org
>
>
> Once started looking in *Messages* I see 7 GC cycles in the the
> non-native build and 5 in the native one, also I can scroll without
> issues or other GC cycles.
>
> Note that only during the first start the native copiled Emacs did a
> number of GC cycles more to jit some code but I guess that's expected.
>
> Am I trying to repruduce this correctly?
Almost. After loading the Org file, please M-x goto-address-mode RET, or
M-x bug-reference-mode RET. In fact, registering anything with
jit-lock-register seems to have the same effect. Tassilo posted a
do-nothing example.
For me that is, because no one not on macOS/arm64 seems to see that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 08:31:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Tassilo Horn <tsdh <at> gnu.org> writes:
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
>> Okay, so this is what I tried:
>>
>> I bootstrapped two Emacs from current master (7be66d8223e) one
>> --with-native-compilation=yes the other --with-native-compilation=no
>> and boths with Gerd patch applied.
>>
>> Also I checkout current scratch/igc (2343d55dff4) to get igc.org.
>>
>> I then tried to run with boths native/non-native emacsen with:
>>
>> .../src/emacs -eval '(setq garbage-collection-messages t)' -Q
>> ~/emacs4/admin/igc.org
>>
>> Once started looking in *Messages* I see 7 GC cycles in the the
>> non-native build and 5 in the native one, also I can scroll without
>> issues or other GC cycles.
>>
>> Note that only during the first start the native copiled Emacs did a
>> number of GC cycles more to jit some code but I guess that's expected.
>>
>> Am I trying to repruduce this correctly?
>
> Yes. And you also need to put some function in addition to
> font-lock-fontify-region in jit-lock-functions, either by enabling
> bug-reference-mode, goto-address-mode, or simply defining
>
> (defun i-do-nothing (start end) nil)
>
> and then M-: (jit-lock-register #'i-do-nothing) RET in the igc.org
> buffer.
>
> Bye,
> Tassilo
Okay I tried both your suggestion both Gerd's one on the native compiled
instance with no effect on the number of GC cycles (I'm on GNU/Linux X86-64).
The best I can do is to try later this afternoon on GNU/Linux AArch64
and see if something changes.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 09:04:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Tassilo Horn <tsdh <at> gnu.org> writes:
>
>> Andrea Corallo <acorallo <at> gnu.org> writes:
>>
>>> Okay, so this is what I tried:
>>>
>>> I bootstrapped two Emacs from current master (7be66d8223e) one
>>> --with-native-compilation=yes the other --with-native-compilation=no
>>> and boths with Gerd patch applied.
>>>
>>> Also I checkout current scratch/igc (2343d55dff4) to get igc.org.
>>>
>>> I then tried to run with boths native/non-native emacsen with:
>>>
>>> .../src/emacs -eval '(setq garbage-collection-messages t)' -Q
>>> ~/emacs4/admin/igc.org
>>>
>>> Once started looking in *Messages* I see 7 GC cycles in the the
>>> non-native build and 5 in the native one, also I can scroll without
>>> issues or other GC cycles.
>>>
>>> Note that only during the first start the native copiled Emacs did a
>>> number of GC cycles more to jit some code but I guess that's expected.
>>>
>>> Am I trying to repruduce this correctly?
>>
>> Yes. And you also need to put some function in addition to
>> font-lock-fontify-region in jit-lock-functions, either by enabling
>> bug-reference-mode, goto-address-mode, or simply defining
>>
>> (defun i-do-nothing (start end) nil)
>>
>> and then M-: (jit-lock-register #'i-do-nothing) RET in the igc.org
>> buffer.
>>
>> Bye,
>> Tassilo
>
> Okay I tried both your suggestion both Gerd's one on the native compiled
> instance with no effect on the number of GC cycles (I'm on GNU/Linux X86-64).
>
> The best I can do is to try later this afternoon on GNU/Linux AArch64
> and see if something changes.
Thanks. I'm still suspecting either macOS or libgccjit 14 on arm64, BTW,
or a combination. But I guess I already mentioned that :-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 09:32:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
>> Tassilo Horn <tsdh <at> gnu.org> writes:
>>
>>> Andrea Corallo <acorallo <at> gnu.org> writes:
>>>
>>>> Okay, so this is what I tried:
>>>>
>>>> I bootstrapped two Emacs from current master (7be66d8223e) one
>>>> --with-native-compilation=yes the other --with-native-compilation=no
>>>> and boths with Gerd patch applied.
>>>>
>>>> Also I checkout current scratch/igc (2343d55dff4) to get igc.org.
>>>>
>>>> I then tried to run with boths native/non-native emacsen with:
>>>>
>>>> .../src/emacs -eval '(setq garbage-collection-messages t)' -Q
>>>> ~/emacs4/admin/igc.org
>>>>
>>>> Once started looking in *Messages* I see 7 GC cycles in the the
>>>> non-native build and 5 in the native one, also I can scroll without
>>>> issues or other GC cycles.
>>>>
>>>> Note that only during the first start the native copiled Emacs did a
>>>> number of GC cycles more to jit some code but I guess that's expected.
>>>>
>>>> Am I trying to repruduce this correctly?
>>>
>>> Yes. And you also need to put some function in addition to
>>> font-lock-fontify-region in jit-lock-functions, either by enabling
>>> bug-reference-mode, goto-address-mode, or simply defining
>>>
>>> (defun i-do-nothing (start end) nil)
>>>
>>> and then M-: (jit-lock-register #'i-do-nothing) RET in the igc.org
>>> buffer.
>>>
>>> Bye,
>>> Tassilo
>>
>> Okay I tried both your suggestion both Gerd's one on the native compiled
>> instance with no effect on the number of GC cycles (I'm on GNU/Linux X86-64).
>>
>> The best I can do is to try later this afternoon on GNU/Linux AArch64
>> and see if something changes.
>
> Thanks. I'm still suspecting either macOS or libgccjit 14 on arm64, BTW,
> or a combination. But I guess I already mentioned that :-).
Right I repeated the test on AArch64 using.
This is the content of my *Messages* after opening igc.org, defining and
registering 'i-do-nothing', and scrolling a bit up and down.
=====
For information about GNU Emacs and the GNU system, type C-h C-a.
Garbage collecting... [25 times]
i-do-nothing
(jit-lock-function)
Garbage collecting...done
===
We see some more GC cycles compared to X86_64 at the beginning but I
guess that's not the focus here because after 'i-do-nothing' is
registered I see only a GC cycle and nothing more (even if I scroll).
So to me this all looks good.
PS On this machine I'm on libgccjit 13.2.1.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 09:55:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Andrea Corallo <acorallo <at> gnu.org> writes:
>>
>>> Tassilo Horn <tsdh <at> gnu.org> writes:
>>>
>>>> Andrea Corallo <acorallo <at> gnu.org> writes:
>>>>
>>>>> Okay, so this is what I tried:
>>>>>
>>>>> I bootstrapped two Emacs from current master (7be66d8223e) one
>>>>> --with-native-compilation=yes the other --with-native-compilation=no
>>>>> and boths with Gerd patch applied.
>>>>>
>>>>> Also I checkout current scratch/igc (2343d55dff4) to get igc.org.
>>>>>
>>>>> I then tried to run with boths native/non-native emacsen with:
>>>>>
>>>>> .../src/emacs -eval '(setq garbage-collection-messages t)' -Q
>>>>> ~/emacs4/admin/igc.org
>>>>>
>>>>> Once started looking in *Messages* I see 7 GC cycles in the the
>>>>> non-native build and 5 in the native one, also I can scroll without
>>>>> issues or other GC cycles.
>>>>>
>>>>> Note that only during the first start the native copiled Emacs did a
>>>>> number of GC cycles more to jit some code but I guess that's expected.
>>>>>
>>>>> Am I trying to repruduce this correctly?
>>>>
>>>> Yes. And you also need to put some function in addition to
>>>> font-lock-fontify-region in jit-lock-functions, either by enabling
>>>> bug-reference-mode, goto-address-mode, or simply defining
>>>>
>>>> (defun i-do-nothing (start end) nil)
>>>>
>>>> and then M-: (jit-lock-register #'i-do-nothing) RET in the igc.org
>>>> buffer.
>>>>
>>>> Bye,
>>>> Tassilo
>>>
>>> Okay I tried both your suggestion both Gerd's one on the native compiled
>>> instance with no effect on the number of GC cycles (I'm on GNU/Linux X86-64).
>>>
>>> The best I can do is to try later this afternoon on GNU/Linux AArch64
>>> and see if something changes.
>>
>> Thanks. I'm still suspecting either macOS or libgccjit 14 on arm64, BTW,
>> or a combination. But I guess I already mentioned that :-).
>
> Right I repeated the test on AArch64 using.
>
> This is the content of my *Messages* after opening igc.org, defining and
> registering 'i-do-nothing', and scrolling a bit up and down.
>
> =====
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Garbage collecting... [25 times]
> i-do-nothing
> (jit-lock-function)
> Garbage collecting...done
> ===
>
> We see some more GC cycles compared to X86_64 at the beginning but I
> guess that's not the focus here because after 'i-do-nothing' is
> registered I see only a GC cycle and nothing more (even if I scroll).
>
> So to me this all looks good.
>
> PS On this machine I'm on libgccjit 13.2.1.
Thanks. I'm currently waiting for a new GCC/libgccjit release which I
think should happen relatively soon. I'll report back when that happens.
Much more I cannot do either ATM, I'm afraid.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 10:12:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> Andrea Corallo <acorallo <at> gnu.org> writes:
>>>
>>>> Tassilo Horn <tsdh <at> gnu.org> writes:
>>>>
>>>>> Andrea Corallo <acorallo <at> gnu.org> writes:
>>>>>
>>>>>> Okay, so this is what I tried:
>>>>>>
>>>>>> I bootstrapped two Emacs from current master (7be66d8223e) one
>>>>>> --with-native-compilation=yes the other --with-native-compilation=no
>>>>>> and boths with Gerd patch applied.
>>>>>>
>>>>>> Also I checkout current scratch/igc (2343d55dff4) to get igc.org.
>>>>>>
>>>>>> I then tried to run with boths native/non-native emacsen with:
>>>>>>
>>>>>> .../src/emacs -eval '(setq garbage-collection-messages t)' -Q
>>>>>> ~/emacs4/admin/igc.org
>>>>>>
>>>>>> Once started looking in *Messages* I see 7 GC cycles in the the
>>>>>> non-native build and 5 in the native one, also I can scroll without
>>>>>> issues or other GC cycles.
>>>>>>
>>>>>> Note that only during the first start the native copiled Emacs did a
>>>>>> number of GC cycles more to jit some code but I guess that's expected.
>>>>>>
>>>>>> Am I trying to repruduce this correctly?
>>>>>
>>>>> Yes. And you also need to put some function in addition to
>>>>> font-lock-fontify-region in jit-lock-functions, either by enabling
>>>>> bug-reference-mode, goto-address-mode, or simply defining
>>>>>
>>>>> (defun i-do-nothing (start end) nil)
>>>>>
>>>>> and then M-: (jit-lock-register #'i-do-nothing) RET in the igc.org
>>>>> buffer.
>>>>>
>>>>> Bye,
>>>>> Tassilo
>>>>
>>>> Okay I tried both your suggestion both Gerd's one on the native compiled
>>>> instance with no effect on the number of GC cycles (I'm on GNU/Linux X86-64).
>>>>
>>>> The best I can do is to try later this afternoon on GNU/Linux AArch64
>>>> and see if something changes.
>>>
>>> Thanks. I'm still suspecting either macOS or libgccjit 14 on arm64, BTW,
>>> or a combination. But I guess I already mentioned that :-).
>>
>> Right I repeated the test on AArch64 using.
>>
>> This is the content of my *Messages* after opening igc.org, defining and
>> registering 'i-do-nothing', and scrolling a bit up and down.
>>
>> =====
>> For information about GNU Emacs and the GNU system, type C-h C-a.
>> Garbage collecting... [25 times]
>> i-do-nothing
>> (jit-lock-function)
>> Garbage collecting...done
>> ===
>>
>> We see some more GC cycles compared to X86_64 at the beginning but I
>> guess that's not the focus here because after 'i-do-nothing' is
>> registered I see only a GC cycle and nothing more (even if I scroll).
>>
>> So to me this all looks good.
>>
>> PS On this machine I'm on libgccjit 13.2.1.
>
> Thanks. I'm currently waiting for a new GCC/libgccjit release which I
> think should happen relatively soon. I'll report back when that happens.
> Much more I cannot do either ATM, I'm afraid.
Maybe you could try my same libgccjit version, this would confirm if
it's a libgccjit version specific bug or it's OS specific.
In case you can build any libgccjit easily from the gcc repo following
[1].
Another approach would be to add the ";; no-native-compile: t" cookie by
bisection to our .el files to discover if a specific compilation unit
being native compiled is causing the issue you observe.
Thanks
Andrea
[1] <https://gcc.gnu.org/onlinedocs/jit/internals/index.html#working-on-the-jit-library>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 10:35:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <acorallo <at> gnu.org> writes:
> Maybe you could try my same libgccjit version, this would confirm if
> it's a libgccjit version specific bug or it's OS specific.
>
> In case you can build any libgccjit easily from the gcc repo following
> [1].
Homebrew libgccjit unforunately only supports a pre-built version 14, or
--HEAD which so far never built successfully.
My own attempts to build from GCC git also failed so far because of
conflicting dependencies, and I didn't want to mess that much with my
system. Also, I found GCC's use, or non-use, of branches and tags pretty
confusing, and couldn't find an up-to-date description how that's
intended to work. Anyway, I've given up on that.
> Another approach would be to add the ";; no-native-compile: t" cookie by
> bisection to our .el files to discover if a specific compilation unit
> being native compiled is causing the issue you observe.
I thought about something like that to at least find the place where
things go astray, but - besides the fact that that would take me forever
- in the end I would be in the same position that I was with igc: a
thousandt lines arm64 assembly, C code that looks okay, and so on...
So, won't happen, sorry :-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#70796; Package
emacs.
(Mon, 17 Jun 2024 14:14:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 70796 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Andrea Corallo <acorallo <at> gnu.org> writes:
>
>> Maybe you could try my same libgccjit version, this would confirm if
>> it's a libgccjit version specific bug or it's OS specific.
>>
>> In case you can build any libgccjit easily from the gcc repo following
>> [1].
>
> Homebrew libgccjit unforunately only supports a pre-built version 14, or
> --HEAD which so far never built successfully.
>
> My own attempts to build from GCC git also failed so far because of
> conflicting dependencies, and I didn't want to mess that much with my
> system. Also, I found GCC's use, or non-use, of branches and tags pretty
> confusing, and couldn't find an up-to-date description how that's
> intended to work. Anyway, I've given up on that.
I think just everything in releases/gcc-* is supposed to be release
ready, but there are also tags (ex refs/tags/releases/gcc-14.1.0).
Anyway I compiled libgccjit based on current releases/gcc-14 and run on
my AArch64 testbench without being able to observe the issue.
>> Another approach would be to add the ";; no-native-compile: t" cookie by
>> bisection to our .el files to discover if a specific compilation unit
>> being native compiled is causing the issue you observe.
>
> I thought about something like that to at least find the place where
> things go astray, but - besides the fact that that would take me forever
> - in the end I would be in the same position that I was with igc: a
> thousandt lines arm64 assembly, C code that looks okay, and so on...
I don't think so, by bissection is typically few steps and once the CU
is indentified we tipically narrow down the function. With this
technique in the past we worked on non trivial bugs with success.
> So, won't happen, sorry :-)
No worries I'm not the one affected ;)
Andrea
This bug report was last modified 162 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.