[webkit-reviews] review denied: [Bug 230143] [bmalloc] Merge large frees after making them eligible : [Attachment 438567] patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 6 15:30:36 PDT 2021


Geoffrey Garen <ggaren at apple.com> has denied Basuke Suzuki
<Basuke.Suzuki at sony.com>'s request for review:
Bug 230143: [bmalloc] Merge large frees after making them eligible
https://bugs.webkit.org/show_bug.cgi?id=230143

Attachment 438567: patch

https://bugs.webkit.org/attachment.cgi?id=438567&action=review




--- Comment #17 from Geoffrey Garen <ggaren at apple.com> ---
Comment on attachment 438567
  --> https://bugs.webkit.org/attachment.cgi?id=438567
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=438567&action=review

> Source/bmalloc/ChangeLog:22
> +	   Here's a quick result from testmem on MacBook Air M1. The
differences are tiny.

This patch seems to include some subtleties, including a potential throughput
penalty at the end of scavenging. Can we point to a clearer memory improvement
that would justify the subtleties and the potential throughput penalty? We
generally prefer not to make changes for performance unless we can measure the
impact.

> Source/bmalloc/bmalloc/LargeMap.cpp:69
>  void LargeMap::add(const LargeRange& range)

Why does LargeMap::add change at all in this patch? Why isn't the heap always
back in a fully merged, consistent state after LargeMap::mergeNeighbors() has
returned?

> Source/bmalloc/bmalloc/LargeMap.cpp:90
> +	       auto* next = it + 1;
> +	       if (next != m_free.end() && canMerge(*it, *next)) {
> +		   *it = merge(*it, *next);
> +		   m_free.remove(next);
> +	       }

I don't think it's right to check only the immediate neighbor (it + 1) for
merging. m_free is not sorted, so I'm not sure what this would achieve.

> Source/bmalloc/bmalloc/LargeMap.cpp:112
> +	   auto* next = &range + 1;
> +
> +	   while (next < m_free.end() && canMerge(range, *next))
> +	       range = merge(range, *next++);

Same comment about it + 1.

> Source/bmalloc/bmalloc/Vector.h:174
> +    BASSERT(from < to);
> +    size_t moveCount = end() - to;
> +    if (moveCount)
> +	   std::memmove(from, to, moveCount * sizeof(T));

No need to check moveCount here.


More information about the webkit-reviews mailing list