This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: malloc() and spinlocks
> I don't want to break anything. I just want something like this - see the
> thread-m.h.patch attachment. I don't know if the code should be duplicated or
> if the spinlock code is not necessary in the not _LIBC part.
In the patch for thread-m.h which I just sent, there is no code
duplication. Please try it out.
> The
> mallo.c.patch is for __inline__ - I don't know if you even want to apply
> that, and I doubt it can go in in this form (having simply __inline__ there),
> I simply added a couple of __inline__ where I liked :).
I really see no point in this, see below.. Your inline patch would
only cause code size explosion and no real benefit.
> --- malloc.c.sav Mon Nov 25 15:14:55 2002
> +++ malloc.c Mon Nov 25 16:43:08 2002
> @@ -2337,8 +2337,10 @@ void weak_variable (*__after_morecore_ho
> */
>
> #if __STD_C
> +__inline__
> static void do_check_chunk(mstate av, mchunkptr p)
All these do_check functions are only called when MALLOC_DEBUG is set,
i.e. not in glibc and not in any critical paths.
> @@ -2668,8 +2679,10 @@ static void do_check_malloc_state(mstate
> */
>
> #if __STD_C
> +__inline__
> static Void_t* sYSMALLOc(INTERNAL_SIZE_T nb, mstate av)
All the sYS... function involve slow system calls like sbrk() or
mmap() so there is little benefit in inlining these.
> @@ -3182,6 +3197,7 @@ static int sYSTRIm(pad, av) size_t pad;
>
> #ifdef HAVE_MMAP
>
> +__inline__
> static void
> internal_function
> #if __STD_C
Same for mmap_chunk and mremap_chunk, these always involve very slow
system calls because the mmaped chunks are large.
> /*
> ------------------------------ malloc ------------------------------
> */
>
> +__inline__
> Void_t*
> _int_malloc(mstate av, size_t bytes)
The _int_... functions are really big functions and also an exported
interface in glibc-2.3. Although I agree we pay an indirection price
here I wouldn't want to inline here because of the extreme code size
increase.
> +__inline__
> #if __STD_C
> static void malloc_consolidate(mstate av)
This one might be a reasonable candidate for inlining (although a
relatively large function). Note that gcc has the chance to decide
whether to inline this even without adding __inline__ explicitly. But
I'll think about adding this for the next release.
Regards,
Wolfram.