From: Robert Pluim <rpluim@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: psainty@orcon.net.nz, pieter@vanoostrum.org, 38407@debbugs.gnu.org
Subject: bug#38407: 27.0.50; infinite loop with display of large file without newlines
Date: Wed, 04 Dec 2019 10:15:55 +0100 [thread overview]
Message-ID: <m2r21k78ok.fsf@gmail.com> (raw)
In-Reply-To: <lxpnhd9ecn.fsf@cochabamba.vanoostrum.org>
>>>>> On Tue, 03 Dec 2019 18:05:42 +0200, Eli Zaretskii <eliz@gnu.org> said:
Eli> Yes, I was wondering about that myself. But we need more details to
Eli> understand better what, if anything, can be done about this.
Eli> First, which part of SAVE_IT causes this? I'm guessing it's this
Eli> part:
Eli> #define SAVE_IT(ITCOPY, ITORIG, CACHE) \
Eli> do { \
Eli> if (CACHE) \
Eli> bidi_unshelve_cache (CACHE, true); \
Eli> ITCOPY = ITORIG; \
Eli> CACHE = bidi_shelve_cache (); \ <<<<<<<<<<<<
Eli> } while (false)
Yes, itʼs bidi_shelve_cache
Eli> If that is true, then I think the offending part of bidi_shelve_cache
Eli> is this:
Eli> alloc = (bidi_shelve_header_size
Eli> + bidi_cache_idx * sizeof (struct bidi_it));
Eli> databuf = xmalloc (alloc);
Eli> bidi_cache_total_alloc += alloc;
Eli> memcpy (databuf, &bidi_cache_idx, sizeof (bidi_cache_idx));
Eli> memcpy (databuf + sizeof (bidi_cache_idx), <<<<<<<
Eli> bidi_cache, bidi_cache_idx * sizeof (struct bidi_it)); <<<<<<<
Eli> memcpy (databuf + sizeof (bidi_cache_idx)
Eli> + bidi_cache_idx * sizeof (struct bidi_it),
Eli> bidi_cache_start_stack, sizeof (bidi_cache_start_stack));
Eli> And if this guess is also true, then I think the problem is that
Eli> databuf + sizeof (bidi_cache_idx) is unaligned on 64-bit systems,
Eli> since bidi_cache_idx is an int.
The '_unaligned_' bit of that memmove function name does not mean
thatʼs itʼs doing unoptimized unaligned copies: it means it accepts
unaligned pointers, and aligns them as necessary to enable fast
copying. Anyway, I made bidi_cache_idx an intptr_t, and it made no
difference.
I think that misalignment is vastly dwarfed by the following:
(gdb) l bidi_shelve_cache
973 {
974 unsigned char *databuf;
975 ptrdiff_t alloc;
976
977 /* Empty cache. */
978 if (bidi_cache_idx == 0)
979 return NULL;
980
981 alloc = (bidi_shelve_header_size
982 + bidi_cache_idx * sizeof (struct bidi_it));
(gdb) b 980
Breakpoint 3 at 0x4b66aa: file bidi.c, line 981.
(gdb) commands
Type commands for breakpoint(s) 3, one per line.
End with a line saying just "end".
>p bidi_cache_idx
>p bidi_cache_idx * sizeof(struct bidi_it)
>end
Thread 1 "emacs" hit Breakpoint 3, bidi_shelve_cache () at bidi.c:981
981 alloc = (bidi_shelve_header_size
$25 = 30860
$26 = 71842080
which means Emacs is copying 70MB of data every time bidi_shelve_cache
is called, and itʼs called *a lot* in this scenario. Could we not do
this shelving by pointer-swapping or similar rather than copying?
Robert
next prev parent reply other threads:[~2019-12-04 9:15 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-27 21:52 bug#38407: 27.0.50; infinite loop with display of large file without newlines Pieter van Oostrum
2019-11-27 23:38 ` Phil Sainty
2019-11-28 0:30 ` Phil Sainty
2019-11-28 1:22 ` Phil Sainty
2019-11-28 6:51 ` Pieter van Oostrum
2019-11-28 15:14 ` Eli Zaretskii
2019-11-28 18:30 ` Pieter van Oostrum
2019-11-28 18:53 ` Eli Zaretskii
2019-11-28 22:09 ` Pieter van Oostrum
2019-11-29 7:12 ` Eli Zaretskii
2019-11-29 11:48 ` Phil Sainty
2019-11-29 13:20 ` Eli Zaretskii
2019-11-29 13:48 ` Dmitry Gutov
2019-11-29 14:26 ` Eli Zaretskii
2019-11-29 14:31 ` Dmitry Gutov
2019-11-29 15:03 ` Eli Zaretskii
2019-11-29 16:53 ` Dmitry Gutov
2019-11-29 19:28 ` Eli Zaretskii
2019-11-29 17:24 ` Pieter van Oostrum
2019-11-29 19:30 ` Eli Zaretskii
2019-11-30 8:25 ` Pieter van Oostrum
2019-12-01 7:23 ` Pieter van Oostrum
2019-12-01 10:37 ` Phil Sainty
2019-12-01 16:35 ` Pieter van Oostrum
2019-12-01 18:40 ` Pieter van Oostrum
2019-12-02 16:23 ` Eli Zaretskii
2019-12-01 17:45 ` Eli Zaretskii
2019-12-02 10:27 ` Robert Pluim
2019-12-03 11:20 ` Robert Pluim
2019-12-03 16:05 ` Eli Zaretskii
2019-12-04 9:15 ` Robert Pluim [this message]
2019-12-04 15:45 ` Eli Zaretskii
2019-12-05 7:27 ` Robert Pluim
2019-12-05 15:01 ` Eli Zaretskii
2019-12-05 20:38 ` Phil Sainty
2019-12-06 8:04 ` Eli Zaretskii
2019-12-07 1:28 ` Phil Sainty
2019-12-07 7:56 ` Eli Zaretskii
2019-11-28 15:06 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2r21k78ok.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=38407@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=pieter@vanoostrum.org \
--cc=psainty@orcon.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.