This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]