op_check_tdz does not def its argument
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
index 9c65026..082240b 100644 (file)
@@ -1,3 +1,153 @@
+2019-03-08  Tadeu Zagallo  <tzagallo@apple.com>
+
+        op_check_tdz does not def its argument
+        https://bugs.webkit.org/show_bug.cgi?id=192880
+        <rdar://problem/46221598>
+
+        Reviewed by Saam Barati.
+
+        This prevented the for-in loop optimization in the bytecode generator, since
+        the analysis sees a redefinition of the loop variable.
+
+        * bytecode/BytecodeUseDef.h:
+        (JSC::computeDefsForBytecodeOffset):
+
+2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Make more fields lazy in JSGlobalObject
+        https://bugs.webkit.org/show_bug.cgi?id=195449
+
+        Reviewed by Mark Lam.
+
+        This patch makes more fields lazy-allocated in JSGlobalObject to save memory.
+
+        1. Some minor structures like moduleRecordStructure.
+        2. Some functions like parseInt / parseFloat. While they are eagerly created in JIT mode anyway to materialize NumberConstructor, we can lazily allocate them in non JIT mode.
+        3. ArrayBuffer constructor. While it is eagerly allocated in WebCore, we can make lazily allocated in JSC.
+
+        * interpreter/Interpreter.cpp:
+        (JSC::Interpreter::execute):
+        * runtime/JSArrayBufferPrototype.h:
+        * runtime/JSGlobalObject.cpp:
+        (JSC::JSGlobalObject::init):
+        (JSC::JSGlobalObject::visitChildren):
+        * runtime/JSGlobalObject.h:
+        (JSC::JSGlobalObject::parseIntFunction const):
+        (JSC::JSGlobalObject::parseFloatFunction const):
+        (JSC::JSGlobalObject::evalFunction const):
+        (JSC::JSGlobalObject::strictEvalActivationStructure const):
+        (JSC::JSGlobalObject::moduleRecordStructure const):
+        (JSC::JSGlobalObject::moduleNamespaceObjectStructure const):
+        (JSC::JSGlobalObject::proxyObjectStructure const):
+        (JSC::JSGlobalObject::callableProxyObjectStructure const):
+        (JSC::JSGlobalObject::proxyRevokeStructure const):
+        (JSC::JSGlobalObject::arrayBufferConstructor const):
+        (JSC::JSGlobalObject::arrayBufferPrototype const):
+        (JSC::JSGlobalObject::arrayBufferStructure const):
+        * runtime/ProxyObject.h:
+        * runtime/StrictEvalActivation.cpp:
+        (JSC::StrictEvalActivation::StrictEvalActivation):
+        * runtime/StrictEvalActivation.h:
+        * wasm/js/JSWebAssemblyMemory.cpp:
+        (JSC::JSWebAssemblyMemory::buffer):
+        * wasm/js/WebAssemblyModuleConstructor.cpp:
+        (JSC::webAssemblyModuleCustomSections):
+
+2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] Remove merging must handle values into proven types in CFA
+        https://bugs.webkit.org/show_bug.cgi?id=195444
+
+        Reviewed by Saam Barati.
+
+        Previously, we are merging must handle values as a proven constant in CFA. This is OK as long as this proven AbstractValue is blurred by merging the other legit AbstractValues
+        from the successors. But let's consider the following code, this is actually generated DFG graph from the attached test in r242626.
+
+            Block #2 (loop header) succ #3, #4
+            ...
+            1: ForceOSRExit
+            ...
+            2: JSConstant(0)
+            3: SetLocal(@2, loc6)
+            ...
+            4: Branch(#3, #4)
+
+            Block #3 (This is OSR entry target) pred #2, #3, must handle value for loc6 => JSConstant(Int32, 31)
+            ...
+            5: GetLocal(loc6)
+            6: StringFromCharCode(@5)
+            ...
+
+        Block #3 is OSR entry target. So we have must handle value for loc6 and it is Int32 constant 31. Then we merge this constant as a proven value in #3's loc6 AbstractValue.
+        If the value from #2 blurs the value, it is OK. However, #2 has ForceOSRExit. So must handle value suddenly becomes the only source of loc6 in #3. Then we use this constant
+        as a proven value. But this is not expected behavior since must handle value is just a snapshot of the locals when we kick off the concurrent compilation. In the above example,
+        we assume that loop index is an constant 31, but it is wrong, and OSR entry fails. Because there is no strong assumption that the must handle value is the proven type or value,
+        we should not merge it in CFA.
+
+        Since (1) this is just an optimization, (2) type information is already propagated in prediction injection phase, and (3) the must handle value does not show the performance
+        progression in r211461 and we no longer see type misprediction in marsaglia-osr-entry.js, this patch simply removes must handle value type widening in CFA.
+
+        * dfg/DFGCFAPhase.cpp:
+        (JSC::DFG::CFAPhase::run):
+        (JSC::DFG::CFAPhase::performBlockCFA):
+        (JSC::DFG::CFAPhase::injectOSR): Deleted.
+
+2019-03-07  Yusuke Suzuki  <ysuzuki@apple.com>
+
+        [JSC] StringFromCharCode fast path should accept 0xff in DFG and FTL
+        https://bugs.webkit.org/show_bug.cgi?id=195429
+
+        Reviewed by Saam Barati.
+
+        We can create single characters without allocation up to 0xff character code. But currently, DFGSpeculativeJIT and FTLLowerDFGToB3 go to the slow path
+        for 0xff case. On the other hand, DFG DoesGC phase says GC won't happen if the child is int32 constant and it is <= 0xff. So, if you have `String.fromCharCode(0xff)`,
+        this breaks the assumption in DFG DoesGC. The correct fix is changing the check in DFGSpeculativeJIT and FTLLowerDFGToB3 from AboveOrEqual to Above.
+        Note that ThunkGenerators's StringFromCharCode thunk was correct.
+
+        * dfg/DFGSpeculativeJIT.cpp:
+        (JSC::DFG::SpeculativeJIT::compileFromCharCode):
+        * ftl/FTLLowerDFGToB3.cpp:
+        (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
+
+2019-03-07  Mark Lam  <mark.lam@apple.com>
+
+        Follow up refactoring in try-finally code after r242591.
+        https://bugs.webkit.org/show_bug.cgi?id=195428
+
+        Reviewed by Saam Barati.
+
+        1. Added some comments in emitFinallyCompletion() to describe each completion case.
+        2. Converted CatchEntry into a struct.
+        3. Renamed variable hasBreaksOrContinuesNotCoveredByJumps to hasBreaksOrContinuesThatEscapeCurrentFinally
+           to be more clear about its purpose.
+
+        * bytecompiler/BytecodeGenerator.cpp:
+        (JSC::BytecodeGenerator::generate):
+        (JSC::BytecodeGenerator::emitOutOfLineExceptionHandler):
+        (JSC::BytecodeGenerator::emitFinallyCompletion):
+        * bytecompiler/BytecodeGenerator.h:
+
+2019-03-07  Saam Barati  <sbarati@apple.com>
+
+        CompactVariableMap::Handle's copy operator= leaks the previous data
+        https://bugs.webkit.org/show_bug.cgi?id=195398
+
+        Reviewed by Yusuke Suzuki.
+
+        The copy constructor was just assigning |this| to the new value,
+        forgetting to decrement the ref count of the thing pointed to by
+        the |this| handle. Based on Yusuke's suggestion, this patch refactors
+        the move constructor, move operator=, and copy operator= to use the
+        swap() primitive and the copy constructor primitive.
+
+        * parser/VariableEnvironment.cpp:
+        (JSC::CompactVariableMap::Handle::Handle):
+        (JSC::CompactVariableMap::Handle::swap):
+        (JSC::CompactVariableMap::Handle::operator=): Deleted.
+        * parser/VariableEnvironment.h:
+        (JSC::CompactVariableMap::Handle::Handle):
+        (JSC::CompactVariableMap::Handle::operator=):
+
 2019-03-07  Tadeu Zagallo  <tzagallo@apple.com>
 
         Lazily decode cached bytecode