XPCOM strings currently don't make use of malloc_good_size() to avoid clown shoes. They should, but there's the complication that attribute storage wants exactly-sized nsStringBuffers, so rounding shouldn't be applied in all cases. Rounding belongs inside XPCOM string and not to the callers, because there's the complication of nsStringBuffer taking 8 bytes for its own bookkeeping. I suggest the following: * When creating the string initially, don't round. * When growing the buffer in a currently-arbitrary (doubling) way, round using malloc_good_size(). * Add a new fallible method that sets the length of the string to the argument, rounded up. (Caller can then examine the length to see what the actual new length is.) Use case: Writing to the string with BeginWriting().
Same question here as for the nsTArray case in bug 1360139 comment 1. We round to powers of two or the nearest megabyte for a decent approximation to jemalloc bucket size: http://dxr.mozilla.org/mozilla-central/source/xpcom/string/nsTSubstring.cpp#77
Before I filed this, I thought I saw simple "double the buffer size" code which I thought was potentially not bucket-snapping in the presence of adopting exactly-sized nsStringBuffers from attribute storage. But now I can't locate such "double the buffer size" code, so now I have no idea how I ended up thinking I had seen such a thing. I should have checked again before filing this. Sorry. I only checked that this code didn't call malloc_good_size(). If the current growth strategy already matches jemalloc buckets despite not calling malloc_good_size(), I guess my request then is just: * Add a new fallible method that sets the length of the string to the argument rounded up to corresponding actual capacity and returns the new length/capacity. (It seems that the Capacity() method is protected.)
(In reply to Henri Sivonen (:hsivonen) from comment #2) > * Add a new fallible method that sets the length of the string to the > argument rounded up to corresponding actual capacity and returns the new > length/capacity. > > (It seems that the Capacity() method is protected.) An alternative, which would involve more methods calls (including FFI crossings from Rust) to use, would be making Capacity() public.