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.
<rdar://problem/49133014>
Created attachment 365657 [details] Patch
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?
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.
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.
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
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
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
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
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.
Committed r243389: <https://trac.webkit.org/changeset/243389>