[Webkit-unassigned] [Bug 146602] New: DFG fragile frozen values are fundamentally broken

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=146602

            Bug ID: 146602
           Summary: DFG fragile frozen values are fundamentally broken
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: fpizlo at apple.com

We currently have the notion of a FragileValue, which is a value known to the compiler but not tracked by the GC in any way - it's not marked and it's not weak.  This is used to support AI bootstrap for OSR must-handle values.  The philosophy is that if the compiler does use the value for optimization, it will be strengthened to a weak value (or maybe even a strong value, though we probably won't do that).  But this is too much of a pipe dream.  I've found at least one case where the compiler does use the value, but never strengthens it: it will happen if the value ends up in an OSR entry data expected value.  Then if we GC, we might kill the value, but OSR entry will still try to use it for validation.  That might sort of just work, but it's clearly shady.

The reason why we make must-handle values fragile and not weak is that most of the time the values disappear from the abstract state: they are LUBed to a non-constant.  If we kept them around as weak, we'd have too many cases of the GC killing the code because it thought that the value was somehow meaningful to the code when it was only used as a temporary artifact of optimization.

So, it's true that it's very important for must-handle values not to automatically be weak or strong.  It's also true that the values are necessary for AI bootstrap because we need to know what values OSR entry will require.  But we shouldn't accomplish these goals by having the compiler hold onto what are essentially dangling pointers.

A better solution is to turn the bootstrap into a late widening pass: after CFAPhase achieves convergence, it should check if the must-handle values would widen the valuesAtHead of the must-handle block.  If they would widen them into a non-constant, then we don't need to ever have the compiler track the must-handle values.  If some must-handle value widen a valueAtHead from bottom to a constant, then we can do weak freezing.  This makes sense: in that case we know for sure that the compilation's validity relies on the value being alive, and it makes perfect sense for the GC to jettison the resulting JIT code if the value dies.  This approach will let us get rid of FragileValue.  It will also let us get rid of the must-handle bootstrap in InPlaceAbstractState, and replace it with a must-handle widening in CFAPhase.  CFAPhase will then rerun its fixpoint if the widening changed the results.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150704/cc1da0c0/attachment.html>