This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: malloc cache/trace preview
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: DJ Delorie <dj at redhat dot com>, <libc-alpha at sourceware dot org>
- Cc: <nd at arm dot com>
- Date: Wed, 10 Feb 2016 12:29:15 +0000
- Subject: Re: malloc cache/trace preview
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <201602092251 dot u19MpO5s027665 at greed dot delorie dot com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 09/02/16 22:51, DJ Delorie wrote:
>
> I just pushed to branch dj/malloc two features I've been working on,
> for preview and criticism:
>
> First, a per-thread cache that speeds up small (<1024) allocations by
> up to 5-10x (average 2x).
>
> Second, the start of a low-overhead workload tracing feature that can
> be (eventually) enabled for an existing program to capture its malloc
> et al calls and later replay them for benchmarking.
>
i think the sbrk in the ctor of the trace tool is not ok,
if there are malloc calls using brk before that ctor.
(makes the malloc heap non-contiguous.)
(and probably the tmp filename should come from the env)