See https://uma.googleplex.com/p/chrome/timeline_v2/?sid=c213dd611d18fe0cd9c8312099327f06 

Since Sonny has worked on similar stuff before, let's put it in his plate.

The increase on arm is clear enough that I think this justifies being RBS

Issue 710279 has been merged into this issue.

We are targeting a stable RC on Wednesday, meaning any fixes have to be in by Tuesday night, is there any chance we can get a fix in before tomorrow afternoon?

Has this been looked at yet?

Root cause is still not understood. We should def keep this as high priority, but right now I don't think holding stable on it is the right move.

Sonny is looking at this now to see if we can find any low hanging fruit. I don't think merging to 58 is a good idea though. I am fine with this being on 59.

I found this CL to be a cause: http://crrev.com/2640263003.
That CL caused around 3% increase in browser process memory after startup and idle. There may be other causes but it's hard to find because the memory footprint increase could be specific to a particular usage.

We should get a resolution on this well before 59 goes to stable.

#11: Was the intent to mark this as Release Block Stable or Beta? Looks more like stable blocker

May I know how to measure the memory usage / how to run the test locally?

On the other hand, the CL (http://crrev.com/2640263003) has nothing to do with R59. It is only effective with gcc. In R59, chrome is built by clang.

I'll keep investigating but the outcome will not resolve the release blocker. Reassigning to Sonny.

#14: I used chrome://tracing to measure memory footprint, as described in the "Platform Independent" section here: https://docs.google.com/document/d/15mBOu_uZbgP5bpdHZJXEnF9csSRq7phUWXnZcteVr0o/edit#heading=h.9nj5ra4vpzyi

If R59 is no longer using GCC then that CL won't affect anything to R59.

Since R59 is no longer using GCC, this bug shouldn't affect 59 and should no longer be blocking release 59.

The bug turns out to be only in 58 and not in 59 and above.
Are we gonna fix this in 58?

59 is stable in under two weeks, we are not planning any further 58 releases, so there is not much point in fixing 58 (chance of emergency respin is not super high).