Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

-> haraken@ for blink GC related issue.

Is there any GC change in 53 that might affect this behavior?

There was no specific, big oilpan-related change in M53.

But given that Chrome OS is forcibly sending too many memory-pressures, it's possible that any small change changed GC timings and caused some janks.

#4, ChromeOS isn't sending memory pressure event to blink gc. I disabled it on https://codereview.chromium.org/1858033002, so I don't think that's related.

I believe that my current M53 includes the hugepages kernel flag enabled,
so renderers run most of Chrome from an anonymous hugepage-mapped segment.
That will clear affect memory management, but whether it might introduce
jank in some situations is not clear (to me, at least).

FWIW chrome://histograms on this device shows:

Histogram: BlinkGC.GCReason recorded 11427 samples, average = 0.9 (flags =
0x41)
0 ---------------O (1951 = 17.1%)
1 ------------------------------------------------------------------------O
(9263 = 81.1%) {17.1%}
2 -O (180 = 1.6%) {98.1%}
3 ...
5 O (33 = 0.3%) {99.7%}
6 O (0 = 0.0%) {100.0%}

I have zero tab discards this session, but a whole load of OOM'd tabs,
indicating that the kernel process-killer kicked in.

The tests that has been done so far indicate that this issue is seriously present, and is separate from other jank/hang issue tracked by  issue 627183 .

GC can easily take up half the CPU: 

53.80%     0.00%  chrome           chrome                      [.] v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, char const*, char const*, v8::GCCallbackFlags)
                 |
                 --- v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, char const*, char const*, v8::GCCallbackFlags)
                    |
                    |--87.23%-- v8::internal::Factory::CopyFixedArrayAndGrow(v8::internal::Handle<v8::internal::FixedArray>, int, v8::internal::PretenureFlag)
                    |          v8::internal::SharedFunctionInfo::AddToOptimizedCodeMap(v8::internal::Handle<v8::internal::SharedFunctionInfo>, v8::internal::Handle<v8::internal::Context>, v8::internal::MaybeHandle<v8::internal::Code>, v8::internal::Handle<v8::internal::LiteralsArray>, v8::internal::BailoutId)
                    |......

I shared the results of my tests with both haraken, and jochen in an e-mail thread.

From what I've seen there is at least one tab with about 1GB of V8 heap which results in repeated garbage collections.

Issue 628345 has been merged into this issue.

afakhry@ is this assigned to the right owner at this point?

Yes, I think it is.

haraken@ can you please comment on this bug? This has not been updated in a long time. If we don't think this is something we can fix in the M53 timeframe we should move the milestone to M54.

It's hard for me to look into this issue since I don't have the device.

wez@, oshima@, afakhry@: Would any one of you mind taking over this issue?

From what I understand from #10, it looks like that Chrome is actually allocating a lot of memory and that's why V8's GC is triggered and then Oilpan's GC follows up.

Re#15: This is not specific to any particular device. You can use whatever device you have.

Isn't this a specific issue on devices that have ZRAM?

As far as I look at UMA, I don't observe such problematic janks.

afakhry@ are there any specific steps haraken@ should use to repro this issue? If we cannot conclusively repro this issue we should continue to investigate but make this non-RBS. Agree?

This issue should repro on a tab, app, or extension that's using a lot of RAM (around 1GB or more). Or when there are many tabs and apps open and collectively using a lot of RAM.

Would you give me a more concrete repro step?

Does it happen on Linux? What websites should I open with what user interactions?

Yes, it does happen on Linux. Please load the attached simple app that I created on your Linux workstation and use it to continuously allocate memory. Once the app goes beyond 1GB, its CPU usage will be around 100% all the time.

Deleted: mem_pressure1.zip 7.3 KB

mem_pressure1.zip 7.3 KB Download

Windows and Mac as well?

I haven't tested on either.

I'm confused. Your app is allocating a crazy amount of memory, so I won't be surprised that it will consume a lot of time in GCs.

If this kind of a thing is happening on a real-world website, I'd say that it's a bug of the website.

So, you're saying that if an app/tab needs to allocate a huge amount of memory to do whatever valid operations it needs to do, then this is a bug?

If it allocates several GBs of memory, it should be a bug of the website.

Remember that Svelte devices has <512 MB. There're many Android devices that have <2 GB.

Removing the RB label.

Restoring RB label, since this is a ChromeOS regression, not Android.

The app in #21 is just a way to simulate a condition. You can create several of these apps and load them, keep each at around 200 MB or so, such that all collectively use a lot of memory, you will hit the problem as well.

To be clear: The problem here isn't "running low on memory causes jank." The problem is "running low on memory now causes a LOT more jank than it used to"

wez@ from what haraken@ is saying this looks like by design. Let us take a deeper look at this. Making this non-RBS for now.

Re #30: haraken@ was asserting, IIUC, that high memory usage is not a valid use-case on potentially-low-memory Android devices, whereas this is actually an unexplained recent regression in ChromeOS performance under high memory pressure.

With the minimized test case in #21, are you observing that the recent ChromeOS is triggering more GCs than old ones? Are you observing more V8 GCs, or Oilpan GCs?

Probably V8. Please take a look at comment #9.

assigning to marchuk@ to check and reproduce 

@marchuk, please check if the issue is still reproducible.

Could not reproduce on latest versions 58,59,60,61, played for long time with different devices per steps, for BlinkGC.TimeForSweepingAllObjects got maximum average 4.6 on Linux actively running 24 days and 3.5 for ChromeOS running for 1 week