The trace shows there are 16k objects of blink::PerformanceEntry.

panicker@: Would you mind taking a look? It looks like we sometimes allocate a crazy number of PerformanceEntry objects.

Yes, I'll take a look in the morning.
Any idea about the CL range where the regression was observed?

AFAICT we haven't made recent changes to PerformanceBase::addResourceTiming.
From a quick initial look it appears that the resourcetimingbuffer can be set arbitrarily (upto max size of unsigned) by the user.
So as a first step it might be good to determine whether Facebook is setting this to a very large value OR we are leaking these objects.

It's just an observation from my testing. So I can't tell when it started.

Is it possible to attach debugger and determine the value of m_resourceTimingBufferSize here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/timing/PerformanceBase.h?l=172
set here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/timing/PerformanceBase.cpp?l=227

rewording the title as this is not a regression, but an investigation.
panicker@ are you suggesting that this is WAI if the client actually requested a 2 MB buffer via JS? If so looks like something we should keep track of in memory-infra.

(I agree this is not a regression, but a bug)
Yes, we can definitely fix the implementation and the spec to cap the buffer size.
Would be great to determine if that's the issue that ssid@ is observing though.

ssid: can you check #9 ?
Re #9: lemme clarify my position: if this is due to the JS content doing  Performance.setResourceTimingBufferSize(1000) I think all this becomes WAI as this is not different than the content doing: new Array(1000).
The only action in this case would be:
- improving the memory instrumentation code we have to make sure we surface this to avoid reopening a bug like this next time.
- maybe reaching out to FB folks and pointing out that it has a cost.

If this turns out to be a more endemic problem, we can evaluate whether there is something that could be done to reduce the per-event memory footprint of the resource timing buffer itself, or cap it as you say.

Part of the problem here is that without setting a large buffer it is difficult to ensure that events are not missed. With performance observer this should eventually become less of an issue. If you guys think this is a large issue in the short term we could explore clearing the buffer more aggressively. I also think it wouldn't be unreasonable to have the platform expire entries after N minutes. 

Just verified that the value is set to 100000 by facebook.com. By comment #11, I think the main issue here is to keep around this buffer for days. But it might not be worth fixing this issue and updating the spec. panicker@ would that be an easy fix?

Re-assigning to keishi to verify if we need a dump provider to account for these performance timing objects.
Reducing priority and marking this as feature.

Capping the buffer in the implementation right now (without spec update) would cause an interoperability issue / inconsistency between browsers.
From the spec perspective the answer here is to use PerformanceObserver moving forward.
I can't think of short term fixes other than making developers aware of the cost.

Makes sense.
+pfeldman
TL;DR a high Performance.setResourceTimingBufferSize() can cause a non-trivial (~2 MiB) use of memory in the renderer. I wonder it would make sense having this surfaced in devtools' memory pane.

Can we make PerformanceResourceTiming listen to MemoryCoordinator so that it can clear the buffer when the system is under high memory pressure?

> I wonder it would make sense having this surfaced in devtools' memory pane.

What's your goal here? We could emit a 'performance violation' into console when it happens.

Just to confirm: Per the spec, is it okay to clear the buffer at any time?

Re #16:
> What's your goal here?
Essentially the TL;DR of this bug is that if developer use a given JS feature (Performance.setResourceTimingBufferSize()) they end up using memory which is *not* acounted by the V8 heap, and hence, by the devtools heap profiler tooling.

But they (JS developers) are directly responsible for it, so maybe that information should be surfaced to them in some way? Not sure what the best way of surfacing it is (or surfacing makes sense at all). 

The spec says:
The user agent may choose to limit how many resources are included as PerformanceResourceTiming objects in the Performance Timeline [PERFORMANCE-TIMELINE-2].
https://w3c.github.io/resource-timing/#dom-performance-setresourcetimingbuffersize

So could we clear m_resourceTimingBuffer when we are under memory pressure?

I filed this bug asking for clarification whether we can clear the buffer under pressure: 
https://github.com/w3c/resource-timing/issues/94
Clearing the buffer under high memory pressure definitely sounds reasonable to me.

FWIW, surfacing these types of egregious performance violations to the web developer totally makes sense to me.

Do we have an idea on how wide spread that is? Typical user is not looking at the heap profiler, so I would not put it there. Depending on how systematic that is, we could surface it in different places. For example, if particular framework is doing it without the users's explicit consent, we could yell at the library in console.

If that is a one-off case though, we would place it elsewhere. Still hesitant putting it into Memory. Btw, the API is a footgun it seems, we should totally ignore the given value.

My sense is that this particular issue of making massive buffers for Resource Timing is one-off. The explicit recommendation is small buffer sizes. 
Are you asking about the more general question of developers inadvertently causing large memory bloat? That seems worth surfacing somehow.
I don't think we need to do something just for this specific case.

Yeah, this is a one off issue on our end. We're going to follow up and come up with something better here. In general we haven't seen many issues come up because of this, so thanks for the report!

Since there is an owner, change status to assigned.

I don't think there's anything to do here beyond the spec bug that was filed:
https://github.com/w3c/resource-timing/issues/94