EvictedAfterDocumentRestoredReason - Restore/Evict races still happening?

[Tal Pressman]

Hi BfCachers,

(cc: altimin@, arthursonzogni@)

kouhei@ asked me to take a look at the code here dealing with restore/evict races, and I after looking at it for a bit I have some questions I hope you can help with.

The code in question attempts to verify that if a frame gets an eviction request, then it is still in the cache (i.e.: has not been restored). There has been a previous discussion of this here, and a CL to fix the race condition by carlscab was landed in M89. However, looking at UMA and crash/ (internal), the issue still seems to be happening.

According to UMA, in the past month this happened ~16K times compared to ~962M "successful" evictions. As far as I could tell from the DWOCs on crash/, they all originated from the EvictFromBackForwardCache mojo call. Unfortunately, the histogram always logs the same reason (kByJavaScript) regardless of the reason provided in the mojo call and I have been unable to extract the reason from the dumps, so it is a little difficult to narrow down the exact cause of the eviction on the renderer side[1].

So my questions:

1. Do we have data on how often this occurred before Carlos' CL? UMA doesn't seem to have data that far back.
2. Given the relatively low number of occurrences, how important is this?
3. Does anyone have any ideas on what may be causing this?

Thanks,

Tal

[1] Following Fergal's advice, I'll try adding crash keys and will hopefully have some more info on that next week.

[Alexander Timin]

Thanks for looking into this!

Carlos's patch should have fixed one of the sources of the renderer-initiated evictions (evictions due to JS execution), but we've also added another one (evictions due to network request limits). 

+Yuzu Saijo has landed the fix for those, I believe — could you point us to the version / milestone which should have these fixes?

Crash keys are a good option, but for situations like this adding a new DebugScenario might be helpful (as the trace should tell us the state of both browser and renderer around the problematic call). 

[Tal Pressman]

Ah, I wasn't aware of DebugScenario, I'll check it out, thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "bfcache-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/bfcache-dev/woijoH17LS4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bfcache-dev...@chromium.org.
To view this discussion on the web, visit https://groups.google.com/a/chromium.org/d/msgid/bfcache-dev/CALHg4nnFaSU%3DaZ8s2JtqhHf6Ho0fAMorB1an-9o_4kUrkx%2BT2A%40mail.gmail.com.