glibc_malloc_overhead

glibc_malloc_overhead

[Eli Zaretskii]

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.

Re: glibc_malloc_overhead

[Paul Eggert]

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.

Re: glibc_malloc_overhead

[Eli Zaretskii]

> 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.