[Webkit-unassigned] [Bug 94810] Vector::shrinkToFit should use realloc when canCopyWithMemcpy is true

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=94810





--- Comment #10 from Yong Li <yoli at rim.com>  2012-08-28 10:20:26 PST ---
(In reply to comment #9)
> It is not obvious if
> 1) This will increase memory fragmentation because realloc is not flexible for shrink.
> 2) This will not provide any improvement and it is just extra code to support.
> 3) Fastmalloc does the right thing and the patch avoid some memcopy.
> 
> (3) should go in WebKit, (1) and (2) should just be discarded. I only ask you make sure you have the third case.
> 
> > Probably adding an ENABLE switch is better?
> 
> No, please. ENABLE switch is a bad idea here.

It seems FastMalloc is OK, as its realloc() allocates a new block when "the new size is significantly smaller than the old size".

  // Reallocate if the new size is larger than the old size,
  // or if the new size is significantly smaller than the old size.
  if ((new_size > old_size) || (AllocationSize(new_size) < old_size)) {

But not all ports are using same memory allocator. Some ports have USE_SYSTEM_MALLOC defined. As Alexey said, "at least OS X man page for realloc implies that it cannot move the allocation when shrinking".

PLATFORM(BLACKBERRY) also uses the system memory allocator. I'm trying to get some numbers on QNX, but the results won't apply to all ports.


BTW, I've seen in reality WebKit runs out-of-memory in shrinkToFit, which is a little bit weird: it is trying to shrink memory usage, but ends up with allocating more memory and runs OOM even faster. Reusing the old memory address for larges blocks can also reduce memory spikes in some cases.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.