This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][malloc] Improve malloc initialization sequence
- From: DJ Delorie <dj at redhat dot com>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Cc: fweimer at redhat dot com, libc-alpha at sourceware dot org, nd at arm dot com
- Date: Mon, 02 Oct 2017 18:01:07 -0400
- Subject: Re: [PATCH][malloc] Improve malloc initialization sequence
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=dj at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E467E883C1
> - /*
> - If max_fast is 0, we know that av hasn't
> - yet been initialized, in which case do so below
> - */
The comment before the function needs to be edited as well.
> - if (get_max_fast () != 0) {
> + {
Mild preference for "touch all the lines, but get the indentation
right". The remaining {} block need not be a full {} block.
__libc_mallopt() calls malloc_consolidate, with a comment that says
"Ensure initialization/consolidation" - do we need to consolidate here,
or is it another remnant? Either way, at least the comment is wrong
now.
The comment for malloc_init_state() is also wrong now.
_int_malloc calls malloc_consolidate to initialize arenas, although it
also needs the consolidation feature.
comment in mtrim() is wrong now, or it needs to call init? (ok, pretty
much every call to malloc_consolidate needs to be checked to see if they
really are initializing the arenas; there are a lot of public APIs that
might be called before malloc/realloc/calloc, which is when
ptmalloc_init gets called)
I wonder if an assert in malloc_consolidate would be prudent...