Bug 203121 – [bmalloc] Bug fix for wait time when it's in mini mode.

• Component: bmalloc
• Status: RESOLVED FIXED

[Basuke Suzuki]

m_waitTime is never changed on mini mode since https://trac.webkit.org/changeset/243144/webkit

[Basuke Suzuki]

Created attachment 381232 [details]
PATCH

[Basuke Suzuki]

Simple bug fix.

[Basuke Suzuki]

Oh, there's no watchOS EWS...

[Yusuke Suzuki]

Comment on attachment 381232 [details]
PATCH

r=me. Yes, this is apparently not intended behavior.

[Basuke Suzuki]

Thanks!

[WebKit Commit Bot]

Comment on attachment 381232 [details]
PATCH

Clearing flags on attachment: 381232

Committed r251268: <https://trac.webkit.org/changeset/251268>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/56391220>

[Yusuke Suzuki]

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).

[Yusuke Suzuki]

Committed r252157: <https://trac.webkit.org/changeset/252157>

[Saam Barati]

(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

[Yusuke Suzuki]

(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.

[Yusuke Suzuki]

(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

[Yusuke Suzuki]

Reopening to attach new patch.

[Yusuke Suzuki]

Created attachment 383012 [details]
Patch

[Yusuke Suzuki]

Created attachment 383013 [details]
Patch

[Saam Barati]

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?

[Yusuke Suzuki]

Committed r252224: <https://trac.webkit.org/changeset/252224>