After trying and failing to generate a small repro (I always got soft deopts instead of the bug), I realized that it's because Leszek already fixed it! https://chromium-review.googlesource.com/c/v8/v8/+/2150586
On Wednesday, July 29, 2020 at 4:23:56 PM UTC-7, Seth Brenith wrote: > > A few brief observations based on stepping through the problem area in the > debugger: > > - The generated code for this JS function calls directly into > Builtins_LoadICTrampoline_Megamorphic. > - However, the feedback vector slot for that load is in monomorphic > state. > - The map we're currently loading from matches the map in the feedback > vector. > - We don't find the relevant data in the global megamorphic lookup > cache. > - UpdatePolymorphicIC returns true, so IC::SetCache returns without > running UpdateMegamorphicCache, so this property lookup never has any > chance to get faster. > > Does anybody have advice about how a LoadIC could initially get into this > state where its feedback says monomorphic but the generated code is > executing a megamorphic load? > > > On Monday, July 27, 2020 at 12:44:59 AM UTC-7, Camillo Bruni wrote: >> >> Hi, >> >> Inline Caches are a crucial optimization >> <https://en.wikipedia.org/wiki/Inline_caching> to speed up >> property accesses. >> Usually, you get misses the first time an inline cache is used (for >> initialization) or when the shape of objects is different (different order, >> different types of properties). >> >> Spending 55% of your time in LoadIC_Miss seems really high. Without >> access to the repro this is hard to assess. >> >> cheers, >> Camillo >> >> On Sat, 25 Jul 2020 at 21:12, Wayakorn Vadhanasin <waya...@gmail.com> >> wrote: >> >>> I am working on updating my Electron app from Electron 4 (Chromium 69) >>> to Electron 8 (Chromium 80). I am occasionally experiencing random delays >>> in my app while calling a JS function to process HTML DOMs (no external >>> callouts). >>> >>> Looking closely at the profiling data collected from the Windows >>> Performance Analysis tool, I am seeing the following calls during the repro: >>> >>> * v8::internal::Runtime_LoadIC_Miss* - 55% >>> * v8::internal::LoadIC::Load *- 13% >>> >>> More details on the LoadIC_Miss: >>> v8::internal::IC::UpdatePolymorphicIC >>> v8::internal::IC::SetCache >>> v8::internal::LoadIC::UpdateCaches >>> v8::internal::LoadIC::Load >>> v8::internal::Runtime_LoadIC_Miss >>> >>> Very few instances of the above occurred in a normal condition, only >>> when there was a perf issue. >>> >>> I'd like to understand more what inline cache is doing. Have there been >>> many churns in this area since Chromium 69? Any hints or suggestions on the >>> next step of investigation is appreciated. Thanks in advance. >>> >>> Way >>> >>> >>> >>> >>> -- >>> -- >>> v8-users mailing list >>> v8-u...@googlegroups.com >>> http://groups.google.com/group/v8-users >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "v8-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to v8-u...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-users/ad7fe487-be79-491a-96ee-37c286274c12n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/v8-users/ad7fe487-be79-491a-96ee-37c286274c12n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/889e5acd-4a02-4b87-aab1-1371a702d8b3o%40googlegroups.com.
