Bug 196121 – [BMalloc] No need to delay deallocating chunks based on recent use

• Component: bmalloc
• Status: RESOLVED FIXED

[Michael Saboff]

This is a follow-up for r243144 <https://trac.webkit.org/changeset/243144>.  The code checked in with that change set employed the used since last scavenge logic on small chunks, but that isn't needed for small chunks as their memory isn't decommitted directly.  Instead we "deallocate" small chunks by adding them to a large range free list.  When this large range free list is scavenged, we'll actually decommit the backing memory.  This reduces the number of scavenger passes needed to decommit small chunks from 4 to 3.

[Radar WebKit Bug Importer]

<rdar://problem/49133014>

[Michael Saboff]

Created attachment 365657 [details]
Patch

[Mark Lam]

Comment on attachment 365657 [details]
Patch

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

r=me if EWS bots are happy.

> Source/bmalloc/ChangeLog:9
> +        We can decommit small chunks immediately as that adds them to the LargeRange free list.  That free list employs the

By "decommit" here, do you mean "deallocate" instead?

[Michael Saboff]

Comment on attachment 365657 [details]
Patch

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

>> Source/bmalloc/ChangeLog:9
>> +        We can decommit small chunks immediately as that adds them to the LargeRange free list.  That free list employs the
> 
> By "decommit" here, do you mean "deallocate" instead?

The terms in this case are nearly the same, but I'll change it to deallocate as that is part of the function's name.

[Mark Lam]

Comment on attachment 365657 [details]
Patch

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

>>> Source/bmalloc/ChangeLog:9
>>> +        We can decommit small chunks immediately as that adds them to the LargeRange free list.  That free list employs the
>> 
>> By "decommit" here, do you mean "deallocate" instead?
> 
> The terms in this case are nearly the same, but I'll change it to deallocate as that is part of the function's name.

Yeah, I was just a bit confused because in the previous sentence, it said "small chunks ... their memory isn't decommitted directly", and then, we follow it with this "We can decommit small chunks immediately".  I think "deallocate" referring to the function that we call is less confusing.

[EWS Watchlist]

Comment on attachment 365657 [details]
Patch

Attachment 365657 [details] did not pass win-ews (win):
Output: https://webkit-queues.webkit.org/results/11608466

New failing tests:
legacy-animation-engine/animations/resume-after-page-cache.html

[EWS Watchlist]

Created attachment 365673 [details]
Archive of layout-test-results from ews204 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews204  Port: win-future  Platform: CYGWIN_NT-6.1-2.10.0-0.325-5-3-x86_64-64bit

[EWS Watchlist]

Comment on attachment 365657 [details]
Patch

Attachment 365657 [details] did not pass mac-wk2-ews (mac-wk2):
Output: https://webkit-queues.webkit.org/results/11609357

New failing tests:
http/wpt/mediarecorder/MediaRecorder-AV-audio-video-dataavailable.html

[EWS Watchlist]

Created attachment 365681 [details]
Archive of layout-test-results from ews105 for mac-highsierra-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105  Port: mac-highsierra-wk2  Platform: Mac OS X 10.13.6

[Michael Saboff]

The mac-wk2 test results without this patch show a crash in media recorder tests, so that failure doesn't seem relevant.

The windows test legacy-animation-engine/animations/resume-after-page-cache.html
 is failing intermittently in windows builds.

Going to land this patch as these failures don't seem relevant.

[Michael Saboff]

Committed r243389: <https://trac.webkit.org/changeset/243389>