• mhahnenberg@apple.com's avatar
    DFG should have a separate StoreBarrier node · 4968e1a3
    mhahnenberg@apple.com authored
    Reviewed by Filip Pizlo.
    This is in preparation for GenGC. We use a separate StoreBarrier node instead of making them implicitly 
    part of other nodes so that it's easier to run analyses on them, e.g. for the StoreBarrierElisionPhase. 
    They are inserted during the fixup phase. Initially they do not generate any code.
    * CMakeLists.txt:
    * GNUmakefile.list.am:
    * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
    * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
    * JavaScriptCore.xcodeproj/project.pbxproj:
    * dfg/DFGAbstractHeap.h:
    * dfg/DFGAbstractInterpreter.h:
    * dfg/DFGAbstractInterpreterInlines.h:
    * dfg/DFGClobberize.h:
    * dfg/DFGConstantFoldingPhase.cpp:
    (JSC::DFG::ConstantFoldingPhase::foldConstants): Whenever we insert new nodes that require StoreBarriers,
    we have to add those new StoreBarriers too. It's important to note that AllocatePropertyStorage and 
    ReallocatePropertyStorage nodes require their StoreBarriers to come after them since they allocate first,
    which could cause a GC, and then store the resulting buffer into their JSCell, which requires the barrier.
    If we ever require that write barriers occur before stores, we'll have to split these nodes into 
    AllocatePropertyStorage + StoreBarrier + PutPropertyStorage.
    * dfg/DFGFixupPhase.cpp:
    * dfg/DFGNode.h:
    * dfg/DFGNodeType.h:
    * dfg/DFGOSRExitCompiler32_64.cpp:
    * dfg/DFGOSRExitCompiler64.cpp:
    * dfg/DFGPlan.cpp:
    * dfg/DFGPredictionPropagationPhase.cpp:
    * dfg/DFGSafeToExecute.h:
    * dfg/DFGSpeculativeJIT.cpp:
    (JSC::DFG::SpeculativeJIT::genericWriteBarrier): The fast path write barrier check. It loads the 
    byte that contains the mark bit of the object. 
    (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): If the fast path check fails we try to store the 
    cell in the WriteBarrierBuffer so as to avoid frequently flushing all registers in order to make a C call.
    (JSC::DFG::SpeculativeJIT::osrWriteBarrier): More barebones version of the write barrier to be executed 
    during an OSR exit into baseline code. We must do this so that the baseline JIT object and array profiles 
    are properly cleared during GC.
    * dfg/DFGSpeculativeJIT.h:
    * dfg/DFGSpeculativeJIT32_64.cpp:
    * dfg/DFGSpeculativeJIT64.cpp:
    * dfg/DFGStoreBarrierElisionPhase.cpp: Added. New DFG phase that does block-local elision of redundant
    StoreBarriers. Every time a StoreBarrier on a particular object is executed, a bit is set indicating that 
    that object doesn't need any more StoreBarriers. 
    (JSC::DFG::StoreBarrierElisionPhase::couldCauseGC): Nodes that could cause a GC reset the bits for all of the 
    objects known in the current block. 
    (JSC::DFG::StoreBarrierElisionPhase::allocatesFreshObject): A node that creates a new object automatically 
    sets the bit for that object since if a GC occurred as the result of that object's allocation then that 
    object would not need a barrier since it would be guaranteed to be a young generation object until the 
    next GC point.
    * dfg/DFGStoreBarrierElisionPhase.h: Added.
    * heap/Heap.cpp:
    * heap/Heap.h:
    * heap/MarkedBlock.h:
    * heap/WriteBarrierBuffer.cpp: Added. The WriteBarrierBuffer buffers a set of JSCells that are awaiting 
    a pending WriteBarrier. This buffer is used by the DFG to avoid the overhead of calling out to C repeatedly
    to invoke a write barrier on a single JSCell. Instead the DFG has inline code to fill the WriteBarrier buffer
    until its full, and then to call out to C to flush it. The WriteBarrierBuffer will also be flushed prior to 
    each EdenCollection.
    * heap/WriteBarrierBuffer.h: Added.
    * jit/JITOperations.cpp:
    * jit/JITOperations.h:
    * runtime/VM.h:
    * wtf/Platform.h: Added an #define for ENABLE(GGC) which will be used for landing things related to GenGC.
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160796 268f45cc-cd09-0410-ab3c-d52691b4dbfc