• Benedikt Meurer's avatar
    [feedback-vector] Don't go MEGAMORPHIC due to dying handlers. · 40c68926
    Benedikt Meurer authored
    This fixes a problem where ICs for transitioning stores go MEGAMORPHIC
    if the transition target map dies in between invocations of the IC,
    which is totally possible, since we only hold on weakly to these
    transition targets (both from the FeedbackVectors and also from the
    TransitonArrays).
    
    The root problem here was an inconsistency in how the maps and handlers
    are being reported by the FeedbackVector. On the on hand side the method
    FeedbackVector::ExtractMaps() will report all receiver maps that are
    still present (i.e. which haven't died themselves), but then the other
    method FeedbackVector::FindHandlers() will only report handlers that are
    still alive (i.e. which in case of transition target maps being used as
    handlers haven't died yet). If the length of these lists don't match the
    IC chickens out and goes MEGAMORPHIC. But this is exactly the case with
    the transitioning stores, where there's no handler anymore, i.e. as can
    be seen in this simple example:
    
    ```
    // Flags: --expose-gc
    function C() { this.x = 1; }
    new C();
    new C();
    gc();     // map with the `C.x` property dies
    new C();  // now the STORE_IC in C goes MEGAMORPHIC
    ```
    
    So the problem is that we have these two methods that don't agree with
    each other. Now FeedbackVector::ExtractMaps() is also used by TurboFan
    and it even reports receiver maps for PREMONOMORPHIC state, which is
    different from the use case that the ICs need. So I replaced the
    FeedbackVector::FindHandlers() with a completely new method
    FeedbackVector::ExtractMapsAndHandlers(), which returns both the maps
    and handlers, exactly as the ICs need it. And only returns pairs for
    which both the receiver map and the handler are still alive.
    
    This fixes the odd problem that sometimes STORE_ICs going MEGAMORPHIC
    for no apparent reason. Due to the weakness of the transition target
    maps, they can still die and cause deoptimizations, but at least
    TurboFan will now be able to reoptimize again later with the new maps
    and still generate proper code.
    
    Bug: v8:9316
    Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
    Change-Id: I74c8b60f792f310dc813f997e69efe9ad434296a
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1637878
    Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
    Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
    Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
    Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#61948}
    40c68926
Name
Last commit
Last update
..
OWNERS Loading commit data...
accessor-assembler.cc Loading commit data...
accessor-assembler.h Loading commit data...
binary-op-assembler.cc Loading commit data...
binary-op-assembler.h Loading commit data...
call-optimization.cc Loading commit data...
call-optimization.h Loading commit data...
handler-configuration-inl.h Loading commit data...
handler-configuration.cc Loading commit data...
handler-configuration.h Loading commit data...
ic-inl.h Loading commit data...
ic-stats.cc Loading commit data...
ic-stats.h Loading commit data...
ic.cc Loading commit data...
ic.h Loading commit data...
keyed-store-generic.cc Loading commit data...
keyed-store-generic.h Loading commit data...
stub-cache.cc Loading commit data...
stub-cache.h Loading commit data...