* glibc_malloc_overhead
@ 2011-09-30 7:34 Eli Zaretskii
2011-09-30 17:13 ` glibc_malloc_overhead Paul Eggert
0 siblings, 1 reply; 3+ messages in thread
From: Eli Zaretskii @ 2011-09-30 7:34 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
Re this change:
- initial_malloc_max = (1 << 16) - 1 - XMALLOC_OVERRUN_CHECK_OVERHEAD,
+ glibc_malloc_overhead = 3 * sizeof (size_t) - 1,
+ initial_malloc_max =
+ (1 << 16) - 1 - glibc_malloc_overhead - XMALLOC_OVERRUN_CHECK_OVERHEAD,
charset_table_size_init = initial_malloc_max / sizeof (struct charset)
};
How stable can we expect the value of glibc_malloc_overhead to be?
What if the glibc developers decide to change it whenever they see
fit?
In any case, I'd suggest to only account for this overhead if glibc is
being used. No need to "punish" other builds, especially if they
don't use mmap at all.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: glibc_malloc_overhead
2011-09-30 7:34 glibc_malloc_overhead Eli Zaretskii
@ 2011-09-30 17:13 ` Paul Eggert
2011-09-30 17:21 ` glibc_malloc_overhead Eli Zaretskii
0 siblings, 1 reply; 3+ messages in thread
From: Paul Eggert @ 2011-09-30 17:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 09/30/11 00:34, Eli Zaretskii wrote:
> How stable can we expect the value of glibc_malloc_overhead to be?
> What if the glibc developers decide to change it whenever they see fit?
I think the value is fairly stable, but of course there's no guarantee.
(I blundered into the problem only because I was using some unusual
debugging options; normally, the code happened to not ask for a number
of bytes in the magic range that causes a core dump.)
> I'd suggest to only account for this overhead if glibc is
> being used.
Better yet, let's modify it to not depend on this particular glibc
internal at all. I did that in the trunk, as bzr 105968.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: glibc_malloc_overhead
2011-09-30 17:13 ` glibc_malloc_overhead Paul Eggert
@ 2011-09-30 17:21 ` Eli Zaretskii
0 siblings, 0 replies; 3+ messages in thread
From: Eli Zaretskii @ 2011-09-30 17:21 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
> Date: Fri, 30 Sep 2011 10:13:26 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
>
> > I'd suggest to only account for this overhead if glibc is
> > being used.
>
> Better yet, let's modify it to not depend on this particular glibc
> internal at all. I did that in the trunk, as bzr 105968.
Thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-09-30 17:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-30 7:34 glibc_malloc_overhead Eli Zaretskii
2011-09-30 17:13 ` glibc_malloc_overhead Paul Eggert
2011-09-30 17:21 ` glibc_malloc_overhead Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).