This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] malloc per-thread cache ready for review
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Jeff Law <law at redhat dot com>
- Cc: DJ Delorie <dj at redhat dot com>, Markus Trippelsdorf <markus at trippelsdorf dot de>, libc-alpha at sourceware dot org
- Date: Wed, 1 Feb 2017 19:23:59 +0300 (MSK)
- Subject: Re: [patch] malloc per-thread cache ready for review
- Authentication-results: sourceware.org; auth=none
- References: <xnh94dlwg2.fsf@greed.delorie.com> <e00cd039-b1e4-45a7-e9de-bff2cc291b0d@redhat.com>
On Wed, 1 Feb 2017, Jeff Law wrote:
> On 02/01/2017 09:14 AM, DJ Delorie wrote:
> > Markus Trippelsdorf <markus@trippelsdorf.de> writes:
> > > Thanks. It works fine now.
> >
> > Excellent :-)
> >
> > > But I see no speedups for a simple compile time test:
> >
> > GCC is single threaded and has its own internal memory management system
> > it layers on top of malloc, and I've not seen it benefit from a
> > per-thread cache.
> Actually most of GCC's key internal structures are layered on top of mmap'd
> pages. It doesn't go through malloc for any of the key data structures.
As I recall from looking at profiling data, GCC's C++ frontend is nevertheless a
heavy user of libc malloc/free. Apart from that, GCC uses its custom GC-capable
allocator extensively.
Alexander