[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHD6eXdNfYs4or4he4Zsaog__t51+DKG5iGto8p_cxbpe4dAFQ@mail.gmail.com>
Date: Fri, 28 Jun 2024 15:04:38 -0700
From: David Goldblatt <davidtgoldblatt@...il.com>
To: libc-coord@...ts.openwall.com
Cc: enh <enh@...gle.com>, Zijun Zhao <zijunzhao@...gle.com>
Subject: Re: aligned_realloc()
On Thu, Jun 27, 2024 at 11:55 PM Florian Weimer <fweimer@...hat.com> wrote:
> The signature could look like this:
>
> size_t realloc_no_move (void *ptr, size_t b, size_t m, size_t x_min,
> size_t x_max);
>
> PTR must not be null. The function changes the size of the object to
> m * x + b, where x_min ≤ x ≤ x_max if such an x exists, or leaves
> the size of the object unchanged. It returns the new size of the
> object.
>
> It's not ideal because recovering the concrete x used may require a
> division, but I assume it's usually a division by constant, so not too
> costly. Returning the x value is problematic if the existing allocation
> is not within the right arithmetic progression.
>
> This would also be helpful in the implementation of data structures such
> as std::vector, where in-place resizing and moving allocations require
> different execution paths.
>
This is very close to the jemalloc 'xallocx' function, which was intended
to help the sorts of cases you mention. Our experience with it that it was
not as useful as it seems; both for the reasons mentioned in the p0401
reference upthread, but also there's this fundamental tension in that this
optimization doesn't really matter for small allocations, and for big ones
you sort of *hope* you fail (if you're doing a good job at fragmentation
avoidance, you expect there to not be adjacent unoccupied storage;
likewise). You also start facing tensions about things you don't really
have enough user-input to have a good opinion on (is it better to copy into
already dirty storage? Or better to take a soft fault at the next page of
storage? It depends on how confident you are about more, similar requests
coming soon).
- David
Content of type "text/html" skipped
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.
