m_waitTime is never changed on mini mode since https://trac.webkit.org/changeset/243144/webkit
Created attachment 381232 [details] PATCH
Simple bug fix.
Oh, there's no watchOS EWS...
Comment on attachment 381232 [details] PATCH r=me. Yes, this is apparently not intended behavior.
Thanks!
Comment on attachment 381232 [details] PATCH Clearing flags on attachment: 381232 Committed r251268: <https://trac.webkit.org/changeset/251268>
All reviewed patches have been landed. Closing bug.
<rdar://problem/56391220>
Internally, we found that this behavior is making RAMification 1% regressed. And this is because, 1. Due to this accidental behavior, we are always using 10ms for the time interval. 2. And this works well for mini-mode. For now, I'll roll-out this change and keep mini-mode scavenging period 10ms. And another thing I would like to see is that the memory number w/ system malloc. Our bmalloc is focusing on performance, while system malloc does good thing for memory footprint in sacrifice of throughput. The purpose of Mini mode is making memory footprint small w/ small throughput loss, and this policy matches well to the system malloc. It would be possible that we could get some good memory footprint further by switching to system malloc by specifying Malloc=1 environment option. So, for now, I'll roll out this patch, (or, just removing adjusting part for mini-mode too).
Committed r252157: <https://trac.webkit.org/changeset/252157>
(In reply to Yusuke Suzuki from comment #10) > Committed r252157: <https://trac.webkit.org/changeset/252157> why roll out this code? At least we should make the code sensible instead of updating a local variable which is never used
(In reply to Saam Barati from comment #11) > (In reply to Yusuke Suzuki from comment #10) > > Committed r252157: <https://trac.webkit.org/changeset/252157> > > why roll out this code? At least we should make the code sensible instead of > updating a local variable which is never used Because of RAMification regression, we decide that the old broken behavior (always using 10ms) is the safest option for now. We will add a patch that is removing adjusting part for mini-mode in a separate patch.
(In reply to Saam Barati from comment #11) > (In reply to Yusuke Suzuki from comment #10) > > Committed r252157: <https://trac.webkit.org/changeset/252157> > > why roll out this code? At least we should make the code sensible instead of > updating a local variable which is never used See the ChangeLog of roll-out. > We should clean up to make this bug's behavior default. And we should look for a bit larger interval here
Reopening to attach new patch.
Created attachment 383012 [details] Patch
Created attachment 383013 [details] Patch
Comment on attachment 383013 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=383013&action=review r=me > Source/bmalloc/bmalloc/Scavenger.cpp:-504 > - if (m_isInMiniMode) { > - timeSpentScavenging *= 50; > - newWaitTime = std::chrono::duration_cast<std::chrono::milliseconds>(timeSpentScavenging); > - newWaitTime = std::min(std::max(newWaitTime, std::chrono::milliseconds(25)), std::chrono::milliseconds(500)); > - } else { Can we file a FIXME?
Committed r252224: <https://trac.webkit.org/changeset/252224>