bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

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'

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@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.

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@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.

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 70796@debbugs.gnu.org
> Date: Mon, 06 May 2024 14:35:42 +0200
> 
> Eli Zaretskii <eliz@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?

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Eli Zaretskii <eliz@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...

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@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.

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Eli Zaretskii <eliz@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

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Ihor Radchenko <yantar92@posteo.net>,  70796@debbugs.gnu.org
> Date: Sat, 18 May 2024 08:27:15 +0200
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >
> >> Eli Zaretskii <eliz@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?

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Tassilo Horn]

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@gmail.com>
>> Cc: Ihor Radchenko <yantar92@posteo.net>,  70796@debbugs.gnu.org
>> Date: Sat, 18 May 2024 08:27:15 +0200
>> 
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> 
>> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> >
>> >> Eli Zaretskii <eliz@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?

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Tassilo Horn]

Eli Zaretskii <eliz@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

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Tassilo Horn <tsdh@gnu.org> writes:

> Eli Zaretskii <eliz@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)

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Ihor Radchenko]

Gerd Möllmann <gerd.moellmann@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>

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Tassilo Horn]

Gerd Möllmann <gerd.moellmann@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

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Ihor Radchenko <yantar92@posteo.net> writes:

> Gerd Möllmann <gerd.moellmann@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.

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

Tassilo Horn <tsdh@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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gc-messages --]
[-- Type: text/x-patch, Size: 589 bytes --]

diff --git a/src/alloc.c b/src/alloc.c
index 28e32554472..7911078ba59 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -6584,7 +6584,7 @@ garbage_collect (void)
 #endif /* MAX_SAVE_STACK > 0 */
 
   if (garbage_collection_messages)
-    message1_nolog ("Garbage collecting...");
+    message1 ("Garbage collecting...");
 
   block_input ();
 
@@ -6689,7 +6689,7 @@ garbage_collect (void)
       if (message_p || minibuf_level > 0)
 	restore_message ();
       else
-	message1_nolog ("Garbage collecting...done");
+	message1 ("Garbage collecting...done");
     }
 
   unbind_to (count, Qnil);

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Tassilo Horn]

Gerd Möllmann <gerd.moellmann@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

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Tassilo Horn <tsdh@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...

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Tassilo Horn]

Yes, right, x86 on GNU/Linux.

Am Sa, 25. Mai 2024, um 09:58, schrieb Gerd Möllmann:
> Tassilo Horn <tsdh@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...

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

"Tassilo Horn" <tsdh@gnu.org> writes:

> Yes, right, x86 on GNU/Linux.
>
> Am Sa, 25. Mai 2024, um 09:58, schrieb Gerd Möllmann:
>> Tassilo Horn <tsdh@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.

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Eli Zaretskii]

Ping!  Can we make some further progress here?

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  70796@debbugs.gnu.org,  Ihor Radchenko
>  <yantar92@posteo.net>
> Date: Sat, 01 Jun 2024 11:05:10 +0200
> 
> "Tassilo Horn" <tsdh@gnu.org> writes:
> 
> > Yes, right, x86 on GNU/Linux.
> >
> > Am Sa, 25. Mai 2024, um 09:58, schrieb Gerd Möllmann:
> >> Tassilo Horn <tsdh@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.
> 

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> Ping!  Can we make some further progress here?
>
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  70796@debbugs.gnu.org,  Ihor Radchenko
>>  <yantar92@posteo.net>
>> Date: Sat, 01 Jun 2024 11:05:10 +0200
>> 
>> "Tassilo Horn" <tsdh@gnu.org> writes:
>> 
>> > Yes, right, x86 on GNU/Linux.
>> >
>> > Am Sa, 25. Mai 2024, um 09:58, schrieb Gerd Möllmann:
>> >> Tassilo Horn <tsdh@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.

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Tassilo Horn]

Gerd Möllmann <gerd.moellmann@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

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  70796@debbugs.gnu.org,  yantar92@posteo.net
> Date: Sun, 16 Jun 2024 11:45:16 +0200
> 
> Gerd Möllmann <gerd.moellmann@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.

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tsdh@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  70796@debbugs.gnu.org,  yantar92@posteo.net
>> Date: Sun, 16 Jun 2024 11:45:16 +0200
>> 
>> Gerd Möllmann <gerd.moellmann@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

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Tassilo Horn <tsdh@gnu.org>
>>> Cc: Eli Zaretskii <eliz@gnu.org>,  70796@debbugs.gnu.org,  yantar92@posteo.net
>>> Date: Sun, 16 Jun 2024 11:45:16 +0200
>>> 
>>> Gerd Möllmann <gerd.moellmann@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

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Tassilo Horn]

Andrea Corallo <acorallo@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

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Tassilo Horn <tsdh@gnu.org>
>>>> Cc: Eli Zaretskii <eliz@gnu.org>,  70796@debbugs.gnu.org,  yantar92@posteo.net
>>>> Date: Sun, 16 Jun 2024 11:45:16 +0200
>>>> 
>>>> Gerd Möllmann <gerd.moellmann@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.

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Andrea Corallo]

Tassilo Horn <tsdh@gnu.org> writes:

> Andrea Corallo <acorallo@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

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>
>> Andrea Corallo <acorallo@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 :-).

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Tassilo Horn <tsdh@gnu.org> writes:
>>
>>> Andrea Corallo <acorallo@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

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>> Tassilo Horn <tsdh@gnu.org> writes:
>>>
>>>> Andrea Corallo <acorallo@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.

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Andrea Corallo <acorallo@gnu.org> writes:
>>>
>>>> Tassilo Horn <tsdh@gnu.org> writes:
>>>>
>>>>> Andrea Corallo <acorallo@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>

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Gerd Möllmann]

Andrea Corallo <acorallo@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 :-)

bug#70796: 30.0.50; bug-reference-mode leading to constant GCing

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@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