On Mon, Apr 9, 2018 at 4:58 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote:

> My understanding is that under some "huge" size, jemalloc returns
> allocations from particularly-sized buckets.

The mozjemalloc source has a decent ascii-art table [1].

> This makes me expect that realloc() between bucket sizes is going to
> always copy the data instead of just adjusting allocated metadata,
> because to do otherwise would mess up the bucketing.

Sure, but not all reallocs are between bucket sizes. You can realloc from
1KB to 1.99KB and end up in the same bucket.

> Is this so? Specifically, is it actually useful that nsStringBuffer
> uses realloc() as opposed to malloc(), memcpy() with actually
> semantically filled amount and free()?
> Upon superficial code reading, it seems to me that currently changing
the capacity of an nsA[C]STring might uselessly use realloc to copy
> data that's not semantically live data from the string's point of view
> and wouldn't really need to be preserved. Have I actually discovered
> useless copying or am I misunderstanding?

In this case I think you're right. In the string code we use a doubling
strategy up to 8MiB so they'll always be in a new bucket/chunk. After 8MiB
we grow by 1.125 [2], but always round up to the nearest MiB. Our
HugeRealloc logic always makes a new allocation if the difference is
greater than or equal to 1MiB [3] so that's always going to get hit. I
should note that on OSX we use some sort of 'pages_copy' when the realloc
is large enough, this is probably more efficient than memcpy.



dev-platform mailing list

Reply via email to