[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aQZ-cWuCc_xRL7qx@intrepid>
Date: Sat, 1 Nov 2025 22:41:05 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Alejandro Colomar <alx@...nel.org>,
"A. Wilcox" <AWilcox@...cox-tech.com>,
Lénárd Szolnoki <cpp@...ardszolnoki.com>,
Thorsten Glaser <tg@...bsd.de>,
Collin Funk <collin.funk1@...il.com>
Subject: Re: [RFC] add realloci() and reallocarrayi()
Am Fri, Oct 31, 2025 at 03:01:58PM +0100 schrieb Alejandro Colomar:
> Hi,
>
> I have not tested this patch (not even tried building yet). It's just
> an initial draft, requesting comments about the overall idea.
>
> So far, I've only implemented this in the mallocng implementation, as
> the oldmalloc implementation was too weird for me to fully understand.
> Do we need an old implementation too?
>
Whether we need one or not probably depends on if the proposal is
accepted by the C standard, which, judging from the other thread, is
currently up in the air.
Oldmalloc is a pretty simple malloc implementation. On the high level,
there are two allocators: One for large allocations (above
MMAP_THRESHOLD) and one for smaller allocations.
The large allocations use mmap() directly. They are identified at
runtime by having even used chunks not have the C_INUSE flag set for
their size. The psize indicates the offset to the start of the mapped
page, for alignment reasons. For large allocations, realloci() could
probably be implemented by calling mremap() *without* MREMAP_MAYMOVE.
Small allocations use a linked list approach: Each chunk knows its size
and its predecessor's size. Memory blocks are terminated with zero-sized
pseudo-chunks that are always in use. Additionally, free chunks are
added to doubly-linked lists called "bins", where they are classified by
size. The specifics don't really matter for realloci(). You can probably
implement it by combining the current chunk with its successors until
either the size requirement is met or you run into a chunk that is in
use. At the end, you can also split the chunk to shrink it to fit the
request exactly, and leave the rest over to future allocations.
For requests that jump the boundary between those two allocators: I
don't really see the harm in having a chunk start out as mmapped chunk
and become remapped to be smaller. Obviously, the effective size cannot
shrink below 1 page (minus whatever alignment overhead was reserved),
but just having that page dangle about and eventually be unmapped by
free(), though maybe inefficient, is probably not harmful.
The other direction, Rich has in the past spoken out about how there
should not be allocated managed chunks larger than MMAP_THRESHOLD in
size. I don't quite see the issue myself (allocated chunks only matter
in the chunk list in each block, where the size class doesn't matter,
and freed chunks are joined with their free predecessors and successors
to possibly form a size above MMAP_THRESHOLD anyway), but perhaps I am
missing something.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
