On my Linux box with M60 stable, I saw the memory consumption go between
150MB to 2.7GB while scrolling up and down.  On some occasion memory is
collected (?) and goes down as low as 150-200MB, but again it increases
if I continue scrolling.

So it may not be monotonically increasing, but looks like the consumption
is weird.

Routing to canvas team for further triage.

Hi Kochi,

Thanks for the update. Can you please share the estimated timeline for this fix.

Regards,

I'm not sure if this is related to canvas or garbage collection, but I'll do a manual bisect to hopefully find out the culprit change.

As expected, this is not a canvas bug. The problem has appeared after display list 2D canvas is disabled in https://chromium.googlesource.com/chromium/src/+/3750a7881ce851e03ce6177dca30307eb4a7f5c6, but this is not the source of the regression as regular 2D canvas should work fine too. Doing bisect from a much earlier version, the regression has happened after Oilpan is enabled in https://chromium.googlesource.com/chromium/src/+/b25744bcc43fc02389cb7e5e2a59a050c05a9386.

This regression seems to be very similar to crbugs.com/626082. I re-assign this bug to the owner of 626082 and leave the merging decision to the new owner.

I see GCs happening regularly and cleaning up memory. What you observe is the zig-zag behavior of a GC reaching certain limits.

We've been improving the scheduling in this area recently so you might observe tighter bounds with M61+ but the behavior in general is working as intended. In any case, there should also emergency GCs kicking in if we actually run out of memory which I don't observe in this scenario.

Now, as for the rather huge size of 2GB reported by the task manager: On a local V8 trace I see that the reported external size is <100M. Now this is only a minor problem as we already do GCs. With better accounting though they would be more aggressive. This is way better with current ToT (5432ec0c90b5f5d1c9802c1a676e2bff491fd957) where I see external reported to V8 if ~190M and thus better GC timing.

zakerinasab@: maybe there is some accounting (AdjustAmountOfExternalMemory) missing? 

May be. In HTMLCanvasElement::UpdateExternallyAllocatedMemory() we do not account for the memory used in Skia, which can prevent GC from triggering at the proper time. Looking into this.

Adding brianosman@ for an insight from Skia side. We might have to report the amount of memory allocated in SkCanvas if it is not reported to GC anywhere else.

Thanks for looking into this!

This seems to be fixed on Chrome ToT.

According to the bisect, this is fixed after this V8 update (refs/heads/master@{#478608}): https://chromium.googlesource.com/chromium/src/+/937beecff0b2085a3205786fb794bbf74e5e5ff9

This is fixed on dev, beta, canary and ToT for Windows. I'm tagging this bug as Won'tFix.