2019-04-10 Alan Coon <alancoon@apple.com> Cherry-pick r243841. rdar://problem/49725678 -apple-trailing-word is needed for browser detection https://bugs.webkit.org/show_bug.cgi?id=196575 Unreviewed. PerformanceTests: * MotionMark/resources/debug-runner/motionmark.css: (#intro .start-benchmark p): Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore: This is an unreviewed partial revert of r243819. Turns out there are some websites which use this property to do browser detection. So, we need to continue to parse the property, but we don't need the property to do anything. Test: fast/text/trailing-word-detection.html * Configurations/FeatureDefines.xcconfig: * css/CSSComputedStyleDeclaration.cpp: (WebCore::ComputedStyleExtractor::valueForPropertyinStyle): * css/CSSPrimitiveValueMappings.h: (WebCore::CSSPrimitiveValue::CSSPrimitiveValue): (WebCore::CSSPrimitiveValue::operator TrailingWord const): * css/CSSProperties.json: * css/CSSValueKeywords.in: * css/parser/CSSParserFastPaths.cpp: (WebCore::CSSParserFastPaths::isValidKeywordPropertyAndValue): (WebCore::CSSParserFastPaths::isKeywordPropertyID): * rendering/style/RenderStyle.h: (WebCore::RenderStyle::trailingWord const): (WebCore::RenderStyle::setTrailingWord): (WebCore::RenderStyle::initialTrailingWord): * rendering/style/RenderStyleConstants.h: Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Source/WebKit: * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: LayoutTests: * fast/text/trailing-word-detection-expected.txt: Added. * fast/text/trailing-word-detection.html: Added. * platform/gtk/TestExpectations: * platform/win/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243841 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-04-03 Myles C. Maxfield <mmaxfield@apple.com> -apple-trailing-word is needed for browser detection https://bugs.webkit.org/show_bug.cgi?id=196575 Unreviewed. * Configurations/FeatureDefines.xcconfig: 2019-04-10 Alan Coon <alancoon@apple.com> Cherry-pick r243819. rdar://problem/49725678 Remove support for -apple-trailing-word https://bugs.webkit.org/show_bug.cgi?id=196525 Reviewed by Zalan Bujtas. This CSS property is nonstandard and not used. .: * Source/cmake/WebKitFeatures.cmake: Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore: * Configurations/FeatureDefines.xcconfig: * css/CSSComputedStyleDeclaration.cpp: (WebCore::ComputedStyleExtractor::valueForPropertyinStyle): * css/CSSPrimitiveValueMappings.h: (WebCore::CSSPrimitiveValue::operator TrailingWord const): Deleted. * css/CSSProperties.json: * css/CSSValueKeywords.in: * css/parser/CSSParserFastPaths.cpp: (WebCore::CSSParserFastPaths::isValidKeywordPropertyAndValue): (WebCore::CSSParserFastPaths::isKeywordPropertyID): * rendering/SimpleLineLayout.cpp: (WebCore::SimpleLineLayout::canUseForStyle): * rendering/SimpleLineLayoutCoverage.cpp: (WebCore::SimpleLineLayout::printReason): * rendering/SimpleLineLayoutCoverage.h: * rendering/line/BreakingContext.h: (WebCore::BreakingContext::BreakingContext): (WebCore::BreakingContext::lineBreak): (WebCore::BreakingContext::clearLineBreakIfFitsOnLine): (WebCore::BreakingContext::commitLineBreakClear): (WebCore::BreakingContext::commitLineBreakAtCurrentWidth): (WebCore::BreakingContext::handleBR): (WebCore::BreakingContext::handleFloat): (WebCore::BreakingContext::handleText): (WebCore::BreakingContext::handleEndOfLine): (WebCore::BreakingContext::InlineIteratorHistory::InlineIteratorHistory): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::push): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::update): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::renderer const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::offset const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::nextBreakablePosition const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::atTextParagraphSeparator const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::previousInSameNode const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::get const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::current const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::historyLength const): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::moveTo): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::increment): Deleted. (WebCore::BreakingContext::InlineIteratorHistory::clear): Deleted. (WebCore::BreakingContext::optimalLineBreakLocationForTrailingWord): Deleted. * rendering/style/RenderStyle.h: (WebCore::RenderStyle::trailingWord const): Deleted. (WebCore::RenderStyle::setTrailingWord): Deleted. (WebCore::RenderStyle::initialTrailingWord): Deleted. * rendering/style/RenderStyleConstants.h: * rendering/style/StyleRareInheritedData.cpp: (WebCore::StyleRareInheritedData::StyleRareInheritedData): (WebCore::StyleRareInheritedData::operator== const): * rendering/style/StyleRareInheritedData.h: Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Source/WebInspectorUI: * UserInterface/Models/CSSKeywordCompletions.js: Source/WebKit: * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Tools: * Scripts/webkitperl/FeatureList.pm: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: LayoutTests: * fast/text/trailing-word-expected.html: Removed. * fast/text/trailing-word.html: Removed. * platform/gtk/TestExpectations: * platform/mac/fast/text/trailing-word-parse-expected.txt: Removed. * platform/mac/fast/text/trailing-word-parse.html: Removed. * platform/win/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243819 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-04-03 Myles C. Maxfield <mmaxfield@apple.com> Remove support for -apple-trailing-word https://bugs.webkit.org/show_bug.cgi?id=196525 Reviewed by Zalan Bujtas. This CSS property is nonstandard and not used. * Configurations/FeatureDefines.xcconfig: 2019-04-09 Alan Coon <alancoon@apple.com> Cherry-pick r243639. rdar://problem/49725710 BackwardsGraph needs to consider back edges as the backward's root successor https://bugs.webkit.org/show_bug.cgi?id=195991 Reviewed by Filip Pizlo. JSTests: * stress/map-b3-licm-infinite-loop.js: Added. Source/JavaScriptCore: * b3/testb3.cpp: (JSC::B3::testInfiniteLoopDoesntCauseBadHoisting): (JSC::B3::run): Source/WTF: Previously, our backwards graph analysis was slightly wrong. The idea of backwards graph is that the root of the graph has edges to terminals in the original graph. And then the original directed edges in the graph are flipped. However, we weren't considering loops as a form of terminality. For example, we wouldn't consider an infinite loop as a terminal. So there were no edges from the root to a node in the infinite loop. This lead us to make mistakes when we used backwards dominators to compute control flow equivalence. This is better understood in an example: ``` preheader: while (1) { if (!isCell(v)) continue; load structure ID if (cond) continue; return } ``` In the previous version of this algorithm, the only edge from the backwards root would be to the block containing the return. This would lead us to believe that the loading of the structureID backwards dominates the preheader, leading us to believe it's control flow equivalent to preheader. This is obviously wrong, since we can loop forever if "v" isn't a cell. The solution here is to treat any backedge in the graph as a "terminal" node. Since a backedge implies the existence of a loop. In the above example, the backwards root now has an edge to both blocks with "continue". This prevents us from falsely claiming that the return is control flow equivalent with the preheader. This patch uses DFS spanning trees to compute back edges. An edge u->v is a back edge when u is a descendent of v in the DFS spanning tree of the Graph. * WTF.xcodeproj/project.pbxproj: * wtf/BackwardsGraph.h: (WTF::BackwardsGraph::BackwardsGraph): * wtf/SpanningTree.h: Added. (SpanningTree::SpanningTree): (SpanningTree::isDescendent): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243639 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-28 Saam Barati <sbarati@apple.com> BackwardsGraph needs to consider back edges as the backward's root successor https://bugs.webkit.org/show_bug.cgi?id=195991 Reviewed by Filip Pizlo. * b3/testb3.cpp: (JSC::B3::testInfiniteLoopDoesntCauseBadHoisting): (JSC::B3::run): 2019-03-27 Alan Coon <alancoon@apple.com> Cherry-pick r243280. rdar://problem/49308036 Cap length of an array with spread to MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH. https://bugs.webkit.org/show_bug.cgi?id=196055 <rdar://problem/49067448> Reviewed by Yusuke Suzuki. JSTests: * stress/new_array_with_spread-should-cap-array-size-to-MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH.js: Added. Source/JavaScriptCore: We are doing this because: 1. We expect the array to be densely packed. 2. SpeculativeJIT::compileAllocateNewArrayWithSize() (and the FTL equivalent) expects the array length to be less than MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH if we don't want to use an ArrayStorage shape. 3. There's no reason why an array with spread needs to be that large anyway. MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH is plenty. In this patch, we also add a debug assert in compileAllocateNewArrayWithSize() and emitAllocateButterfly() to check for overflows. * assembler/AbortReason.h: * dfg/DFGOperations.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCreateRest): (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread): (JSC::DFG::SpeculativeJIT::emitAllocateButterfly): (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread): * runtime/ArrayConventions.h: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243280 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-21 Mark Lam <mark.lam@apple.com> Cap length of an array with spread to MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH. https://bugs.webkit.org/show_bug.cgi?id=196055 <rdar://problem/49067448> Reviewed by Yusuke Suzuki. We are doing this because: 1. We expect the array to be densely packed. 2. SpeculativeJIT::compileAllocateNewArrayWithSize() (and the FTL equivalent) expects the array length to be less than MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH if we don't want to use an ArrayStorage shape. 3. There's no reason why an array with spread needs to be that large anyway. MIN_ARRAY_STORAGE_CONSTRUCTION_LENGTH is plenty. In this patch, we also add a debug assert in compileAllocateNewArrayWithSize() and emitAllocateButterfly() to check for overflows. * assembler/AbortReason.h: * dfg/DFGOperations.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCreateRest): (JSC::DFG::SpeculativeJIT::compileNewArrayWithSpread): (JSC::DFG::SpeculativeJIT::emitAllocateButterfly): (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread): * runtime/ArrayConventions.h: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): 2019-03-27 Alan Coon <alancoon@apple.com> Cherry-pick r243069. rdar://problem/49308056 Structure::flattenDictionary() should clear unused property slots. https://bugs.webkit.org/show_bug.cgi?id=195871 <rdar://problem/48959497> Reviewed by Michael Saboff. JSTests: * stress/structure-flattenDictionary-should-clear-unused-property-slots.js: Added. Source/JavaScriptCore: It currently attempts to do this but fails because it's actually clearing up the preCapacity region instead. The fix is simply to account for the preCapacity when computing the start address of the property slots. * runtime/Structure.cpp: (JSC::Structure::flattenDictionaryStructure): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243069 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-18 Mark Lam <mark.lam@apple.com> Structure::flattenDictionary() should clear unused property slots. https://bugs.webkit.org/show_bug.cgi?id=195871 <rdar://problem/48959497> Reviewed by Michael Saboff. It currently attempts to do this but fails because it's actually clearing up the preCapacity region instead. The fix is simply to account for the preCapacity when computing the start address of the property slots. * runtime/Structure.cpp: (JSC::Structure::flattenDictionaryStructure): 2019-03-27 Alan Coon <alancoon@apple.com> Cherry-pick r242838. rdar://problem/49307991 REGRESSION (iOS 12.2): Webpage using CoffeeScript crashes https://bugs.webkit.org/show_bug.cgi?id=195613 Reviewed by Mark Lam. JSTests: New regression test. * stress/regexp-backref-inbounds.js: Added. (testRegExp): Source/JavaScriptCore: The bug here is in Yarr JIT backreference matching code. We are incorrectly using a checkedOffset / inputPosition correction when checking for the available length left in a string. It is improper to do these corrections as a backreference's match length is based on what was matched in the referenced capture group and not part of the checkedOffset and inputPosition computed when we compiled the RegExp. In some cases, the resulting incorrect calculation would allow us to go past the subject string's length. Removed these adjustments. After writing tests for the first bug, found another bug where the non-greedy backreference backtracking code didn't do an "are we at the end of the input?" check. This caused an infinite loop as we'd jump from the backtracking code back to try matching one more backreference, fail and then backtrack. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generateBackReference): (JSC::Yarr::YarrGenerator::backtrackBackReference): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242838 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-12 Michael Saboff <msaboff@apple.com> REGRESSION (iOS 12.2): Webpage using CoffeeScript crashes https://bugs.webkit.org/show_bug.cgi?id=195613 Reviewed by Mark Lam. The bug here is in Yarr JIT backreference matching code. We are incorrectly using a checkedOffset / inputPosition correction when checking for the available length left in a string. It is improper to do these corrections as a backreference's match length is based on what was matched in the referenced capture group and not part of the checkedOffset and inputPosition computed when we compiled the RegExp. In some cases, the resulting incorrect calculation would allow us to go past the subject string's length. Removed these adjustments. After writing tests for the first bug, found another bug where the non-greedy backreference backtracking code didn't do an "are we at the end of the input?" check. This caused an infinite loop as we'd jump from the backtracking code back to try matching one more backreference, fail and then backtrack. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generateBackReference): (JSC::Yarr::YarrGenerator::backtrackBackReference): 2019-03-13 Babak Shafiei <bshafiei@apple.com> Cherry-pick r242810. rdar://problem/48839349 The HasIndexedProperty node does GC. https://bugs.webkit.org/show_bug.cgi?id=195559 <rdar://problem/48767923> Reviewed by Yusuke Suzuki. JSTests: * stress/HasIndexedProperty-does-gc.js: Added. Source/JavaScriptCore: HasIndexedProperty can call the slow path operationHasIndexedPropertyByInt(), which can eventually call JSString::getIndex(), which can resolve a rope. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242810 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-12 Mark Lam <mark.lam@apple.com> The HasIndexedProperty node does GC. https://bugs.webkit.org/show_bug.cgi?id=195559 <rdar://problem/48767923> Reviewed by Yusuke Suzuki. HasIndexedProperty can call the slow path operationHasIndexedPropertyByInt(), which can eventually call JSString::getIndex(), which can resolve a rope. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2019-03-13 Babak Shafiei <bshafiei@apple.com> Cherry-pick r242667. rdar://problem/48839311 Stack overflow crash in JSC::JSObject::hasInstance. https://bugs.webkit.org/show_bug.cgi?id=195458 <rdar://problem/48710195> Reviewed by Yusuke Suzuki. JSTests: * stress/stack-overflow-in-custom-hasInstance.js: Added. Source/JavaScriptCore: * runtime/JSObject.cpp: (JSC::JSObject::hasInstance): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242667 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-08 Mark Lam <mark.lam@apple.com> Stack overflow crash in JSC::JSObject::hasInstance. https://bugs.webkit.org/show_bug.cgi?id=195458 <rdar://problem/48710195> Reviewed by Yusuke Suzuki. * runtime/JSObject.cpp: (JSC::JSObject::hasInstance): 2019-03-13 Babak Shafiei <bshafiei@apple.com> Cherry-pick r242569. rdar://problem/48839273 Air::reportUsedRegisters must padInterference https://bugs.webkit.org/show_bug.cgi?id=195303 <rdar://problem/48270343> Reviewed by Keith Miller. JSTests: * stress/optional-def-arg-width-should-be-both-early-and-late-use.js: Added. Source/JavaScriptCore: reportUsedRegisters uses reg liveness to eliminate loads/moves into dead registers. However, liveness can report incorrect results in certain scenarios when considering liveness at instruction boundaries. For example, it can go wrong when an Inst has a LateUse of a register and the following Inst has an EarlyDef of that same register. Such a scenario could lead us to incorrectly say the register is not live-in to the first Inst. Pad interference inserts Nops between such instruction boundaries that cause this issue. The test with this patch fixes the issue in reportUsedRegisters. This patch also conservatively makes it so that lowerAfterRegAlloc calls padInterference since it also reasons about liveness. * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirPadInterference.h: * b3/air/AirReportUsedRegisters.cpp: (JSC::B3::Air::reportUsedRegisters): * b3/testb3.cpp: (JSC::B3::testReportUsedRegistersLateUseNotDead): (JSC::B3::run): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242569 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-06 Saam Barati <sbarati@apple.com> Air::reportUsedRegisters must padInterference https://bugs.webkit.org/show_bug.cgi?id=195303 <rdar://problem/48270343> Reviewed by Keith Miller. reportUsedRegisters uses reg liveness to eliminate loads/moves into dead registers. However, liveness can report incorrect results in certain scenarios when considering liveness at instruction boundaries. For example, it can go wrong when an Inst has a LateUse of a register and the following Inst has an EarlyDef of that same register. Such a scenario could lead us to incorrectly say the register is not live-in to the first Inst. Pad interference inserts Nops between such instruction boundaries that cause this issue. The test with this patch fixes the issue in reportUsedRegisters. This patch also conservatively makes it so that lowerAfterRegAlloc calls padInterference since it also reasons about liveness. * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirPadInterference.h: * b3/air/AirReportUsedRegisters.cpp: (JSC::B3::Air::reportUsedRegisters): * b3/testb3.cpp: (JSC::B3::testReportUsedRegistersLateUseNotDead): (JSC::B3::run): 2019-03-13 Babak Shafiei <bshafiei@apple.com> Cherry-pick r242276. rdar://problem/48839389 DFG: Loop-invariant code motion (LICM) should not hoist dead code https://bugs.webkit.org/show_bug.cgi?id=194945 <rdar://problem/48311657> Reviewed by Saam Barati. * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::run): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242276 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-03-13 Babak Shafiei <bshafiei@apple.com> Cherry-pick r242114. rdar://problem/48839372 wasmToJS() should purify incoming NaNs. https://bugs.webkit.org/show_bug.cgi?id=194807 <rdar://problem/48189132> Reviewed by Saam Barati. JSTests: * wasm/regress/wasmToJS-should-purify-NaNs.js: Added. Source/JavaScriptCore: * runtime/JSCJSValue.h: (JSC::jsNumber): * runtime/TypedArrayAdaptors.h: (JSC::IntegralTypedArrayAdaptor::toJSValue): * wasm/js/WasmToJS.cpp: (JSC::Wasm::wasmToJS): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242114 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-26 Mark Lam <mark.lam@apple.com> wasmToJS() should purify incoming NaNs. https://bugs.webkit.org/show_bug.cgi?id=194807 <rdar://problem/48189132> Reviewed by Saam Barati. * runtime/JSCJSValue.h: (JSC::jsNumber): * runtime/TypedArrayAdaptors.h: (JSC::IntegralTypedArrayAdaptor::toJSValue): * wasm/js/WasmToJS.cpp: (JSC::Wasm::wasmToJS): 2019-03-13 Babak Shafiei <bshafiei@apple.com> Cherry-pick r241615. rdar://problem/48839366 SamplingProfiler::stackTracesAsJSON() should escape strings. https://bugs.webkit.org/show_bug.cgi?id=194649 <rdar://problem/48072386> Reviewed by Saam Barati. JSTests: * stress/sampling-profiler-stack-trace-with-double-quote-in-function-name.js: Added. * stress/type-profiler-with-double-quote-in-constructor-name.js: Added. * stress/type-profiler-with-double-quote-in-field-name.js: Added. * stress/type-profiler-with-double-quote-in-optional-field-name.js: Added. Source/JavaScriptCore: Ditto for TypeSet::toJSONString() and TypeSet::toJSONString(). * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::stackTracesAsJSON): * runtime/TypeSet.cpp: (JSC::TypeSet::toJSONString const): (JSC::StructureShape::toJSONString const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241615 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-15 Mark Lam <mark.lam@apple.com> SamplingProfiler::stackTracesAsJSON() should escape strings. https://bugs.webkit.org/show_bug.cgi?id=194649 <rdar://problem/48072386> Reviewed by Saam Barati. Ditto for TypeSet::toJSONString() and TypeSet::toJSONString(). * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::stackTracesAsJSON): * runtime/TypeSet.cpp: (JSC::TypeSet::toJSONString const): (JSC::StructureShape::toJSONString const): 2019-02-28 Andy Estes <aestes@apple.com> [watchOS] Disable Parental Controls content filtering <rdar://problem/48464986> Rubber-stamped by Beth Dakin. * Configurations/FeatureDefines.xcconfig: 2019-02-20 Alan Coon <alancoon@apple.com> Cherry-pick r241772. rdar://problem/48248228 Fix DFG doesGC() for TryGetById and ProfileType nodes. https://bugs.webkit.org/show_bug.cgi?id=194821 <rdar://problem/48206690> Reviewed by Saam Barati. Fix doesGC() for the following nodes: ProfileType: calls operationProcessTypeProfilerLogDFG(), which can calculatedClassName(), which can call JSString::tryGetValue(), which can resolve a rope. TryGetById: calls operationTryGetByIdOptimize(), which can startWatchingPropertyForReplacements() on a structure, which can allocate StructureRareData. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241772 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-19 Mark Lam <mark.lam@apple.com> Fix DFG doesGC() for TryGetById and ProfileType nodes. https://bugs.webkit.org/show_bug.cgi?id=194821 <rdar://problem/48206690> Reviewed by Saam Barati. Fix doesGC() for the following nodes: ProfileType: calls operationProcessTypeProfilerLogDFG(), which can calculatedClassName(), which can call JSString::tryGetValue(), which can resolve a rope. TryGetById: calls operationTryGetByIdOptimize(), which can startWatchingPropertyForReplacements() on a structure, which can allocate StructureRareData. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2019-02-20 Alan Coon <alancoon@apple.com> Cherry-pick r241753. rdar://problem/48243425 Fix DFG doesGC() for CompareEq/Less/LessEq/Greater/GreaterEq and CompareStrictEq nodes. https://bugs.webkit.org/show_bug.cgi?id=194800 <rdar://problem/48183773> Reviewed by Yusuke Suzuki. Fix doesGC() for the following nodes: CompareEq: CompareLess: CompareLessEq: CompareGreater: CompareGreaterEq: CompareStrictEq: Only return false (i.e. does not GC) for child node use kinds that have been vetted to not do anything that can GC. For all other use kinds (including StringUse and BigIntUse), we return true (i.e. does GC). * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241753 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-18 Mark Lam <mark.lam@apple.com> Fix DFG doesGC() for CompareEq/Less/LessEq/Greater/GreaterEq and CompareStrictEq nodes. https://bugs.webkit.org/show_bug.cgi?id=194800 <rdar://problem/48183773> Reviewed by Yusuke Suzuki. Fix doesGC() for the following nodes: CompareEq: CompareLess: CompareLessEq: CompareGreater: CompareGreaterEq: CompareStrictEq: Only return false (i.e. does not GC) for child node use kinds that have been vetted to not do anything that can GC. For all other use kinds (including StringUse and BigIntUse), we return true (i.e. does GC). * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2019-02-20 Alan Coon <alancoon@apple.com> Cherry-pick r241634. rdar://problem/48243442 RELEASE_ASSERT at com.apple.JavaScriptCore: JSC::jsSubstringOfResolved https://bugs.webkit.org/show_bug.cgi?id=194558 Reviewed by Saam Barati. JSTests: New regression test. * stress/regexp-unicode-within-string.js: Added. Source/JavaScriptCore: Added an in bounds check before the read of the next character for Unicode regular expressions for pattern generation that didn't already have such checks. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce): (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed): (JSC::Yarr::YarrGenerator::generateCharacterClassOnce): (JSC::Yarr::YarrGenerator::generateCharacterClassFixed): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241634 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-15 Michael Saboff <msaboff@apple.com> RELEASE_ASSERT at com.apple.JavaScriptCore: JSC::jsSubstringOfResolved https://bugs.webkit.org/show_bug.cgi?id=194558 Reviewed by Saam Barati. Added an in bounds check before the read of the next character for Unicode regular expressions for pattern generation that didn't already have such checks. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce): (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed): (JSC::Yarr::YarrGenerator::generateCharacterClassOnce): (JSC::Yarr::YarrGenerator::generateCharacterClassFixed): 2019-02-20 Alan Coon <alancoon@apple.com> Cherry-pick r241613. rdar://problem/48243234 [JSC] CodeBlock::jettison should clear related watchpoints https://bugs.webkit.org/show_bug.cgi?id=194544 Reviewed by Mark Lam. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::jettison): * dfg/DFGCommonData.h: (JSC::DFG::CommonData::clearWatchpoints): Added. * dfg/CommonData.cpp: (JSC::DFG::CommonData::clearWatchpoints): Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241613 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-15 Robin Morisset <rmorisset@apple.com> CodeBlock::jettison should clear related watchpoints https://bugs.webkit.org/show_bug.cgi?id=194544 Reviewed by Mark Lam. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::jettison): * dfg/DFGCommonData.h: (JSC::DFG::CommonData::clearWatchpoints): Added. * dfg/CommonData.cpp: (JSC::DFG::CommonData::clearWatchpoints): Added. 2019-02-20 Alan Coon <alancoon@apple.com> Cherry-pick r241547. rdar://problem/48220627 Web Inspector: don't include accessibility role in DOM.Node object payloads https://bugs.webkit.org/show_bug.cgi?id=194623 <rdar://problem/36384037> Reviewed by Devin Rousso. Source/JavaScriptCore: Remove property of DOM.Node that is no longer being sent. * inspector/protocol/DOM.json: Source/WebCore: Accessibility properties are complicated to fetch at all the points where we want to build and push nodes immediately. Turning on AX often indirectly causes style recalc and layout. This is bad because we are often building nodes in the first place due to a DOM node tree update (i.e., NodeInserted). It turns out that DOM.getAccessibilityPropertiesForNode is called every time we display the computed role in the Elements Tab > Nodes Sidebar > Accessibility Section. So it is not necessary to collect this information in a problematic way when initially pushing the node, as it will be updated anyway. No new tests, no change in behavior. * inspector/agents/InspectorDOMAgent.cpp: (WebCore::InspectorDOMAgent::buildObjectForNode): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241547 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-13 Brian Burg <bburg@apple.com> Web Inspector: don't include accessibility role in DOM.Node object payloads https://bugs.webkit.org/show_bug.cgi?id=194623 <rdar://problem/36384037> Reviewed by Devin Rousso. Remove property of DOM.Node that is no longer being sent. * inspector/protocol/DOM.json: 2019-02-13 Alan Coon <alancoon@apple.com> Cherry-pick r241267. rdar://problem/47971556 Remove the RELEASE_ASSERT check for duplicate cases in the BinarySwitch constructor. https://bugs.webkit.org/show_bug.cgi?id=194493 <rdar://problem/36380852> Reviewed by Yusuke Suzuki. Having duplicate cases in the BinarySwitch is not a correctness issue. It is however not good for performance and memory usage. As such, a debug ASSERT will do. We'll also do an audit of the clients of BinarySwitch to see if it's possible to be instantiated with duplicate cases in https://bugs.webkit.org/show_bug.cgi?id=194492 later. Also added some value dumps to the RELEASE_ASSERT to help debug the issue when we see duplicate cases. * jit/BinarySwitch.cpp: (JSC::BinarySwitch::BinarySwitch): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241267 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-10 Mark Lam <mark.lam@apple.com> Remove the RELEASE_ASSERT check for duplicate cases in the BinarySwitch constructor. https://bugs.webkit.org/show_bug.cgi?id=194493 <rdar://problem/36380852> Reviewed by Yusuke Suzuki. Having duplicate cases in the BinarySwitch is not a correctness issue. It is however not good for performance and memory usage. As such, a debug ASSERT will do. We'll also do an audit of the clients of BinarySwitch to see if it's possible to be instantiated with duplicate cases in https://bugs.webkit.org/show_bug.cgi?id=194492 later. Also added some value dumps to the RELEASE_ASSERT to help debug the issue when we see duplicate cases. * jit/BinarySwitch.cpp: (JSC::BinarySwitch::BinarySwitch): 2019-02-13 Alan Coon <alancoon@apple.com> Cherry-pick r241228. rdar://problem/47971567 Nodes that rely on being dominated by CheckInBounds should have a child edge to it https://bugs.webkit.org/show_bug.cgi?id=194334 <rdar://problem/47844327> Reviewed by Mark Lam. JSTests: * stress/check-in-bounds-should-be-a-child-use.js: Added. (func): Source/JavaScriptCore: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::convertToHasIndexedProperty): * dfg/DFGIntegerCheckCombiningPhase.cpp: (JSC::DFG::IntegerCheckCombiningPhase::handleBlock): * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGNodeType.h: * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileHasIndexedProperty): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCheckInBounds): (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241228 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-08 Saam barati <sbarati@apple.com> Nodes that rely on being dominated by CheckInBounds should have a child edge to it https://bugs.webkit.org/show_bug.cgi?id=194334 <rdar://problem/47844327> 2019-02-27 Robin Morisset <rmorisset@apple.com> DFG: Loop-invariant code motion (LICM) should not hoist dead code https://bugs.webkit.org/show_bug.cgi?id=194945 <rdar://problem/48311657> Reviewed by Saam Barati. * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::run): Reviewed by Mark Lam. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::convertToHasIndexedProperty): * dfg/DFGIntegerCheckCombiningPhase.cpp: (JSC::DFG::IntegerCheckCombiningPhase::handleBlock): * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGNodeType.h: * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileHasIndexedProperty): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCheckInBounds): (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty): 2019-02-13 Alan Coon <alancoon@apple.com> Cherry-pick r241210. rdar://problem/47971573 Fix DFG's doesGC() for CheckTierUp*, GetByVal, PutByVal*, and StringCharAt nodes. https://bugs.webkit.org/show_bug.cgi?id=194446 <rdar://problem/47926792> Reviewed by Saam Barati. Fix doesGC() for the following nodes: CheckTierUpAtReturn: Calls triggerTierUpNow(), which calls triggerFTLReplacementCompile(), which calls Worklist::completeAllReadyPlansForVM(), which uses DeferGC. CheckTierUpInLoop: Calls triggerTierUpNowInLoop(), which calls tierUpCommon(), which calls Worklist::completeAllReadyPlansForVM(), which uses DeferGC. CheckTierUpAndOSREnter: Calls triggerOSREntryNow(), which calls tierUpCommon(), which calls Worklist::completeAllReadyPlansForVM(), which uses DeferGC. GetByVal: case Array::String calls operationSingleCharacterString(), which calls jsSingleCharacterString(), which can allocate a string. PutByValDirect: PutByVal: PutByValAlias: For the DFG only, the integer TypeArrays calls compilePutByValForIntTypedArray(), which may call slow paths operationPutByValDirectStrict(), operationPutByValDirectNonStrict(), operationPutByValStrict(), or operationPutByValNonStrict(). All of these slow paths call putByValInternal(), which may create exception objects, or call the generic JSValue::put() which may execute arbitrary code. StringCharAt: Can call operationSingleCharacterString(), which calls jsSingleCharacterString(), which can allocate a string. Also fix DFG::SpeculativeJIT::compileGetByValOnString() and FTL's compileStringCharAt() to use the maxSingleCharacterString constant instead of a literal constant. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnString): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241210 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-08 Mark Lam <mark.lam@apple.com> Fix DFG's doesGC() for CheckTierUp*, GetByVal, PutByVal*, and StringCharAt nodes. https://bugs.webkit.org/show_bug.cgi?id=194446 <rdar://problem/47926792> Reviewed by Saam Barati. Fix doesGC() for the following nodes: CheckTierUpAtReturn: Calls triggerTierUpNow(), which calls triggerFTLReplacementCompile(), which calls Worklist::completeAllReadyPlansForVM(), which uses DeferGC. CheckTierUpInLoop: Calls triggerTierUpNowInLoop(), which calls tierUpCommon(), which calls Worklist::completeAllReadyPlansForVM(), which uses DeferGC. CheckTierUpAndOSREnter: Calls triggerOSREntryNow(), which calls tierUpCommon(), which calls Worklist::completeAllReadyPlansForVM(), which uses DeferGC. GetByVal: case Array::String calls operationSingleCharacterString(), which calls jsSingleCharacterString(), which can allocate a string. PutByValDirect: PutByVal: PutByValAlias: For the DFG only, the integer TypeArrays calls compilePutByValForIntTypedArray(), which may call slow paths operationPutByValDirectStrict(), operationPutByValDirectNonStrict(), operationPutByValStrict(), or operationPutByValNonStrict(). All of these slow paths call putByValInternal(), which may create exception objects, or call the generic JSValue::put() which may execute arbitrary code. StringCharAt: Can call operationSingleCharacterString(), which calls jsSingleCharacterString(), which can allocate a string. Also fix DFG::SpeculativeJIT::compileGetByValOnString() and FTL's compileStringCharAt() to use the maxSingleCharacterString constant instead of a literal constant. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnString): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): 2019-02-07 Alan Coon <alancoon@apple.com> Cherry-pick r241140. rdar://problem/47893590 Fix more doesGC() for CheckTraps, GetMapBucket, and Switch nodes. https://bugs.webkit.org/show_bug.cgi?id=194399 <rdar://problem/47889777> Reviewed by Yusuke Suzuki. Fix doesGC() for the following nodes: CheckTraps: We normally will not emit this node because Options::usePollingTraps() is false by default. However, as it is implemented now, CheckTraps can GC because it can allocate a TerminatedExecutionException. If we make the TerminatedExecutionException a singleton allocated at initialization time, doesGC() can return false for CheckTraps. https://bugs.webkit.org/show_bug.cgi?id=194323 GetMapBucket: Can call operationJSMapFindBucket() or operationJSSetFindBucket(), which calls HashMapImpl::findBucket(), which calls jsMapHash(), which can resolve a rope. Switch: If switchData kind is SwitchChar, can call operationResolveRope() . If switchData kind is SwitchString and the child use kind is not StringIdentUse, can call operationSwitchString() which resolves ropes. DirectTailCall: ForceOSRExit: Return: TailCallForwardVarargs: TailCallVarargs: Throw: These are terminal nodes. It shouldn't really matter what doesGC() returns for them, but following our conservative practice, unless we have a good reason for doesGC() to return false, we should just return true. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@241140 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-07 Mark Lam <mark.lam@apple.com> Fix more doesGC() for CheckTraps, GetMapBucket, and Switch nodes. https://bugs.webkit.org/show_bug.cgi?id=194399 <rdar://problem/47889777> Reviewed by Yusuke Suzuki. Fix doesGC() for the following nodes: CheckTraps: We normally will not emit this node because Options::usePollingTraps() is false by default. However, as it is implemented now, CheckTraps can GC because it can allocate a TerminatedExecutionException. If we make the TerminatedExecutionException a singleton allocated at initialization time, doesGC() can return false for CheckTraps. https://bugs.webkit.org/show_bug.cgi?id=194323 GetMapBucket: Can call operationJSMapFindBucket() or operationJSSetFindBucket(), which calls HashMapImpl::findBucket(), which calls jsMapHash(), which can resolve a rope. Switch: If switchData kind is SwitchChar, can call operationResolveRope() . If switchData kind is SwitchString and the child use kind is not StringIdentUse, can call operationSwitchString() which resolves ropes. DirectTailCall: ForceOSRExit: Return: TailCallForwardVarargs: TailCallVarargs: Throw: These are terminal nodes. It shouldn't really matter what doesGC() returns for them, but following our conservative practice, unless we have a good reason for doesGC() to return false, we should just return true. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2019-02-05 Alan Coon <alancoon@apple.com> Cherry-pick r240917. rdar://problem/47810465 DFG's doesGC() is incorrect about the SameValue node's behavior. https://bugs.webkit.org/show_bug.cgi?id=194211 <rdar://problem/47608913> Reviewed by Saam Barati. Only the DoubleRepUse case is guaranteed to not GC. The other case may GC because it calls operationSameValue() which may allocate memory for resolving ropes. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240917 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-02-04 Mark Lam <mark.lam@apple.com> DFG's doesGC() is incorrect about the SameValue node's behavior. https://bugs.webkit.org/show_bug.cgi?id=194211 <rdar://problem/47608913> Reviewed by Saam Barati. Only the DoubleRepUse case is guaranteed to not GC. The other case may GC because it calls operationSameValue() which may allocate memory for resolving ropes. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2019-02-05 Alan Coon <alancoon@apple.com> Cherry-pick r240681. rdar://problem/47774514 ValueRecovery::recover() should purify NaN values it recovers. https://bugs.webkit.org/show_bug.cgi?id=193978 <rdar://problem/47625488> Reviewed by Saam Barati. JSTests: * stress/value-recovery-of-double-displaced-in-jsstack-should-be-purified.js: Added. Source/JavaScriptCore: According to DFG::OSRExit::executeOSRExit() and DFG::OSRExit::compileExit(), recovered DoubleDisplacedInJSStack values need to be purified. ValueRecovery::recover() should do the same. * bytecode/ValueRecovery.cpp: (JSC::ValueRecovery::recover const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240681 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-29 Mark Lam <mark.lam@apple.com> ValueRecovery::recover() should purify NaN values it recovers. https://bugs.webkit.org/show_bug.cgi?id=193978 <rdar://problem/47625488> Reviewed by Saam Barati. According to DFG::OSRExit::executeOSRExit() and DFG::OSRExit::compileExit(), recovered DoubleDisplacedInJSStack values need to be purified. ValueRecovery::recover() should do the same. * bytecode/ValueRecovery.cpp: (JSC::ValueRecovery::recover const): 2019-02-05 Alan Coon <alancoon@apple.com> Cherry-pick r240616. rdar://problem/47774497 ToString node actually does GC. https://bugs.webkit.org/show_bug.cgi?id=193920 <rdar://problem/46695900> Reviewed by Yusuke Suzuki. JSTests: * stress/dfg-to-string-on-int-does-gc.js: Added. * stress/dfg-to-string-on-string-object-does-not-gc.js: Added. * stress/dfg-to-string-on-string-or-string-object-does-not-gc.js: Added. Source/JavaScriptCore: Other than for StringObjectUse and StringOrStringObjectUse, ToString and CallStringConstructor can allocate new JSStrings, and hence, can GC. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240616 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-28 Mark Lam <mark.lam@apple.com> ToString node actually does GC. https://bugs.webkit.org/show_bug.cgi?id=193920 <rdar://problem/46695900> Reviewed by Yusuke Suzuki. Other than for StringObjectUse and StringOrStringObjectUse, ToString and CallStringConstructor can allocate new JSStrings, and hence, can GC. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2019-02-05 Alan Coon <alancoon@apple.com> Cherry-pick r240448. rdar://problem/47774335 Update ARM64EHash https://bugs.webkit.org/show_bug.cgi?id=193776 <rdar://problem/47526457> Reviewed by Mark Lam. See radar for details. * assembler/AssemblerBuffer.h: (JSC::ARM64EHash::update): (JSC::ARM64EHash::finalHash const): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240448 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-24 Saam Barati <sbarati@apple.com> Update ARM64EHash https://bugs.webkit.org/show_bug.cgi?id=193776 <rdar://problem/47526457> Reviewed by Mark Lam. See radar for details. * assembler/AssemblerBuffer.h: (JSC::ARM64EHash::update): (JSC::ARM64EHash::finalHash const): 2019-02-06 Mark Lam <mark.lam@apple.com> Cherry-pick r240998. rdar://problem/47843417 2019-02-05 Mark Lam <mark.lam@apple.com> Fix DFG's doesGC() for a few more nodes. https://bugs.webkit.org/show_bug.cgi?id=194307 <rdar://problem/47832956> Reviewed by Yusuke Suzuki. Fix doesGC() for the following nodes: NumberToStringWithValidRadixConstant: Calls operationInt32ToStringWithValidRadix(), which calls int32ToString(), which can allocate a string. Calls operationInt52ToStringWithValidRadix(), which calls int52ToString(), which can allocate a string. Calls operationDoubleToStringWithValidRadix(), which calls numberToString(), which can allocate a string. RegExpExecNonGlobalOrSticky: calls createRegExpMatchesArray() which allocates memory for all kinds of objects. RegExpMatchFast: calls operationRegExpMatchFastString(), which calls RegExpObject::execInline() and RegExpObject::matchGlobal(). Both of these allocates memory for the match result. RegExpMatchFastGlobal: calls operationRegExpMatchFastGlobalString(), which calls RegExpObject's collectMatches(), which allocates an array amongst other objects. StringFromCharCode: If the uint32 code to convert is greater than maxSingleCharacterString, we'll call operationStringFromCharCode(), which calls jsSingleCharacterString(), which allocates a new string if the code is greater than maxSingleCharacterString. Also fix SpeculativeJIT::compileFromCharCode() and FTL's compileStringFromCharCode() to use maxSingleCharacterString instead of a literal constant. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileFromCharCode): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode): 2019-02-06 Mark Lam <mark.lam@apple.com> Cherry-pick r240991. rdar://problem/47855123 2019-02-05 Mark Lam <mark.lam@apple.com> Move DFG nodes that clobberize() says will write(Heap) to the doesGC() list that returns true. https://bugs.webkit.org/show_bug.cgi?id=194298 <rdar://problem/47827555> Reviewed by Saam Barati. We do this for 3 reasons: 1. It's clearer when reading doesGC()'s code that these nodes will return true. 2. If things change in the future where clobberize() no longer reports these nodes as write(Heap), each node should be vetted first to make sure that it can never GC before being moved back to the doesGC() list that returns false. 3. This reduces the list of nodes that we need to audit to make sure doesGC() is correct in its claims about the nodes' GCing possibility. The list of nodes moved are: ArrayPush ArrayPop Call CallEval CallForwardVarargs CallVarargs Construct ConstructForwardVarargs ConstructVarargs DefineDataProperty DefineAccessorProperty DeleteById DeleteByVal DirectCall DirectConstruct DirectTailCallInlinedCaller GetById GetByIdDirect GetByIdDirectFlush GetByIdFlush GetByIdWithThis GetByValWithThis GetDirectPname GetDynamicVar HasGenericProperty HasOwnProperty HasStructureProperty InById InByVal InstanceOf InstanceOfCustom LoadVarargs NumberToStringWithRadix PutById PutByIdDirect PutByIdFlush PutByIdWithThis PutByOffset PutByValWithThis PutDynamicVar PutGetterById PutGetterByVal PutGetterSetterById PutSetterById PutSetterByVal PutStack PutToArguments RegExpExec RegExpTest ResolveScope ResolveScopeForHoistingFuncDeclInEval TailCall TailCallForwardVarargsInlinedCaller TailCallInlinedCaller TailCallVarargsInlinedCaller ToNumber ToPrimitive ValueNegate * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2019-02-06 Mark Lam <mark.lam@apple.com> Cherry-pick r240917. rdar://problem/47810465 2019-02-03 Mark Lam <mark.lam@apple.com> DFG's doesGC() is incorrect about the SameValue node's behavior. https://bugs.webkit.org/show_bug.cgi?id=194211 <rdar://problem/47608913> Reviewed by Saam Barati. Only the DoubleRepUse case is guaranteed to not GC. The other case may GC because it calls operationSameValue() which may allocate memory for resolving ropes. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2019-01-28 Mark Lam <mark.lam@apple.com> Cherry-pick r240616. rdar://problem/47774497 2019-01-28 Mark Lam <mark.lam@apple.com> ToString node actually does GC. https://bugs.webkit.org/show_bug.cgi?id=193920 <rdar://problem/46695900> Reviewed by Yusuke Suzuki. Other than for StringObjectUse and StringOrStringObjectUse, ToString and CallStringConstructor can allocate new JSStrings, and hence, can GC. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2019-01-30 Babak Shafiei <bshafiei@apple.com> Cherry-pick r240633. rdar://problem/47682687 [watchOS] Enable Parental Controls content filtering https://bugs.webkit.org/show_bug.cgi?id=193939 <rdar://problem/46641912> Reviewed by Ryosuke Niwa. Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Source/WebKit: * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Source/WTF: * wtf/Platform.h: Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240633 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-28 Andy Estes <aestes@apple.com> [watchOS] Enable Parental Controls content filtering https://bugs.webkit.org/show_bug.cgi?id=193939 <rdar://problem/46641912> Reviewed by Ryosuke Niwa. * Configurations/FeatureDefines.xcconfig: 2019-01-30 Babak Shafiei <bshafiei@apple.com> Cherry-pick r239969. rdar://problem/47638452 Add option to JSC to dump memory footprint on script completion https://bugs.webkit.org/show_bug.cgi?id=193422 Reviewed by Mark Lam. Added the --footprint option to dump peak and current memory usage. This uses the same OS calls added in r2362362. * jsc.cpp: (printUsageStatement): (CommandLine::parseArguments): (jscmain): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239969 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-14 Michael Saboff <msaboff@apple.com> Add option to JSC to dump memory footprint on script completion https://bugs.webkit.org/show_bug.cgi?id=193422 Reviewed by Mark Lam. Added the --footprint option to dump peak and current memory usage. This uses the same OS calls added in r2362362. * jsc.cpp: (printUsageStatement): (CommandLine::parseArguments): (jscmain): 2019-01-28 Babak Shafiei <bshafiei@apple.com> Cherry-pick r240449. rdar://problem/47586886 stress/const-semantics.js fails a dfg-eager / ftl-eager run with an ASAN release build. https://bugs.webkit.org/show_bug.cgi?id=190693 Reviewed by Michael Saboff. JSTests: * stress/regress-190693.js: Added. (truth): (assert): (shouldThrowInvalidConstAssignment): (taz): Source/JavaScriptCore: JITStubRoutine's fields are marked only when JITStubRoutine::m_mayBeExecuting is true. This becomes true when we find the executable address in our conservative roots, which means that we could be executing it right now. This means that object liveness in JITStubRoutine depends on the information gathered in ConservativeRoots. However, our constraints are separated, "Conservative Scan" and "JIT Stub Routines". They can even be executed concurrently, so that "JIT Stub Routines" may miss to mark the actually executing JITStubRoutine because "Conservative Scan" finds it later. When finalizing the GC, we delete the dead JITStubRoutines. At that time, since "Conservative Scan" already finishes, we do not delete some JITStubRoutines which do not mark the depending objects. Then, in the next cycle, we find JITStubRoutines still live, attempt to mark the depending objects, and encounter the dead objects which are collected in the previous cycles. This patch removes "JIT Stub Routines" and merge it to "Conservative Scan". Since "Conservative Scan" and "JIT Stub Routines" need to be executed only when the execution happens (ensured by GreyedByExecution and CollectionPhase check), this change is OK for GC stop time. * heap/ConservativeRoots.h: (JSC::ConservativeRoots::roots const): (JSC::ConservativeRoots::roots): Deleted. * heap/Heap.cpp: (JSC::Heap::addCoreConstraints): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::append): * heap/SlotVisitor.h: * jit/GCAwareJITStubRoutine.cpp: (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine): * jit/GCAwareJITStubRoutine.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240449 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-24 Yusuke Suzuki <ysuzuki@apple.com> stress/const-semantics.js fails a dfg-eager / ftl-eager run with an ASAN release build. https://bugs.webkit.org/show_bug.cgi?id=190693 Reviewed by Michael Saboff. JITStubRoutine's fields are marked only when JITStubRoutine::m_mayBeExecuting is true. This becomes true when we find the executable address in our conservative roots, which means that we could be executing it right now. This means that object liveness in JITStubRoutine depends on the information gathered in ConservativeRoots. However, our constraints are separated, "Conservative Scan" and "JIT Stub Routines". They can even be executed concurrently, so that "JIT Stub Routines" may miss to mark the actually executing JITStubRoutine because "Conservative Scan" finds it later. When finalizing the GC, we delete the dead JITStubRoutines. At that time, since "Conservative Scan" already finishes, we do not delete some JITStubRoutines which do not mark the depending objects. Then, in the next cycle, we find JITStubRoutines still live, attempt to mark the depending objects, and encounter the dead objects which are collected in the previous cycles. This patch removes "JIT Stub Routines" and merge it to "Conservative Scan". Since "Conservative Scan" and "JIT Stub Routines" need to be executed only when the execution happens (ensured by GreyedByExecution and CollectionPhase check), this change is OK for GC stop time. * heap/ConservativeRoots.h: (JSC::ConservativeRoots::roots const): (JSC::ConservativeRoots::roots): Deleted. * heap/Heap.cpp: (JSC::Heap::addCoreConstraints): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::append): * heap/SlotVisitor.h: * jit/GCAwareJITStubRoutine.cpp: (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine): * jit/GCAwareJITStubRoutine.h: 2019-01-28 Babak Shafiei <bshafiei@apple.com> Cherry-pick r240447. rdar://problem/47586899 Object Allocation Sinking phase can move a node that walks the stack into a place where the InlineCallFrame is no longer valid https://bugs.webkit.org/show_bug.cgi?id=193751 <rdar://problem/47280215> Reviewed by Michael Saboff. JSTests: * stress/object-allocation-sinking-phase-must-only-move-allocations-if-stack-trace-is-still-valid.js: Added. (let.thing): (foo.let.hello): (foo): Source/JavaScriptCore: The Object Allocation Sinking phase may move allocations around inside of the program. However, it was not ensuring that it's still possible to walk the stack at the point in the program that it moved the allocation to. Certain InlineCallFrames rely on data in the stack when taking a stack trace. All allocation sites can do a stack walk (we do a stack walk when we GC). Conservatively, this patch says we're ok to move this allocation if we are moving within the same InlineCallFrame. We could be more precise and do an analysis of stack writes. However, this scenario is so rare that we just take the conservative-and-straight-forward approach of checking that the place we're moving to is the same InlineCallFrame as the allocation site. In general, this issue arises anytime we do any kind of code motion. Interestingly, LICM gets this right. It gets it right because the only InlineCallFrames we can't move out of are the InlineCallFrames that have metadata stored on the stack (callee for closure calls and argument count for varargs calls). LICM doesn't have this issue because it relies on Clobberize for doing its effects analysis. In clobberize, we model every node within an InlineCallFrame that meets the above criteria as reading from those stack fields. Consequently, LICM won't hoist any node in that InlineCallFrame past the beginning of the InlineCallFrame since the IR we generate to set up such an InlineCallFrame contains writes to that stack location. * dfg/DFGObjectAllocationSinkingPhase.cpp: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240447 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-24 Saam Barati <sbarati@apple.com> Object Allocation Sinking phase can move a node that walks the stack into a place where the InlineCallFrame is no longer valid https://bugs.webkit.org/show_bug.cgi?id=193751 <rdar://problem/47280215> Reviewed by Michael Saboff. The Object Allocation Sinking phase may move allocations around inside of the program. However, it was not ensuring that it's still possible to walk the stack at the point in the program that it moved the allocation to. Certain InlineCallFrames rely on data in the stack when taking a stack trace. All allocation sites can do a stack walk (we do a stack walk when we GC). Conservatively, this patch says we're ok to move this allocation if we are moving within the same InlineCallFrame. We could be more precise and do an analysis of stack writes. However, this scenario is so rare that we just take the conservative-and-straight-forward approach of checking that the place we're moving to is the same InlineCallFrame as the allocation site. In general, this issue arises anytime we do any kind of code motion. Interestingly, LICM gets this right. It gets it right because the only InlineCallFrames we can't move out of are the InlineCallFrames that have metadata stored on the stack (callee for closure calls and argument count for varargs calls). LICM doesn't have this issue because it relies on Clobberize for doing its effects analysis. In clobberize, we model every node within an InlineCallFrame that meets the above criteria as reading from those stack fields. Consequently, LICM won't hoist any node in that InlineCallFrame past the beginning of the InlineCallFrame since the IR we generate to set up such an InlineCallFrame contains writes to that stack location. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2019-01-28 Babak Shafiei <bshafiei@apple.com> Cherry-pick r240364. rdar://problem/47586820 [DFG] AvailabilityMap::pruneByLiveness should make non-live operands Availability::unavailable instead of Availability() https://bugs.webkit.org/show_bug.cgi?id=193711 <rdar://problem/47250262> Reviewed by Saam Barati. JSTests: * stress/availability-was-cleared-when-locals-are-not-live.js: Added. (shouldBe): (foo): (bar): (baz): Source/JavaScriptCore: When pruning OSR Availability based on bytecode liveness, we accidentally clear the Availability (making it DeadFlush) instead of making it Availability::unavailable() (Making it ConflictingFlush). In OSRAvailabilityAnalysisPhase, we perform forward analysis. We first clear all the availability of basic blocks DeadFlush, which is an empty set. And then, we set operands in the root block ConflictingFlush. In this forward analysis, DeadFlush is BOTTOM, and ConflictingFlush is TOP. Then, we propagate information by merging availability until we reach to the fixed-point. As an optimization, we perform "pruning" of the availability in the head of the basic blocks. We remove availabilities of operands which are not live in the bytecode liveness at the head of the basic block. The problem is, when removing availabilities, we set DeadFlush for them instead of ConflictingFlush. Basically, it means that we set BOTTOM (an empty set) instead of TOP. Let's consider the following simple example. We have 6 basic blocks, and they are connected as follows. BB0 -> BB1 -> BB2 -> BB4 | \ ^ v > BB3 / BB5 And consider about loc1 in FTL, which is required to be recovered in BB4's OSR exit. BB0 does nothing head: loc1 is dead tail: loc1 is dead BB1 has MovHint @1, loc1 head: loc1 is dead tail: loc1 is live BB2 does nothing head: loc1 is live tail: loc1 is live BB3 has PutStack @1, loc1 head: loc1 is live tail: loc1 is live BB4 has OSR exit using loc1 head: loc1 is live tail: loc1 is live (in bytecode) BB5 does nothing head: loc1 is dead tail: loc1 is dead In our OSR Availability analysis, we always prune loc1 result in BB1's head since its head says "loc1 is dead". But at that time, we clear the availability for loc1, which makes it DeadFlush, instead of making it ConflictingFlush. So, the flush format of loc1 in each tail of BB is like this. BB0 ConflictingFlush (because all the local operands are initialized with ConflictingFlush) BB1 DeadFlush+@1 (pruning clears it) BB2 DeadFlush+@1 (since it is propagated from BB1) BB3 FlushedJSValue+@1 with loc1 (since it has PutStack) BB4 FlushedJSValue+@1 with loc1 (since MERGE(DeadFlush, FlushedJSValue) = FlushedJSValue) BB5 DeadFlush (pruning clears it) Then, if we go the path BB0->BB1->BB2->BB4, we read the value from the stack while it is not flushed. The correct fix is making availability "unavailable" when pruning based on bytecode liveness. * dfg/DFGAvailabilityMap.cpp: (JSC::DFG::AvailabilityMap::pruneByLiveness): When pruning availability, we first set all the operands Availability::unavailable(), and copy the calculated value from the current availability map. * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): Add logging things for debugging. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240364 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-23 Yusuke Suzuki <ysuzuki@apple.com> [DFG] AvailabilityMap::pruneByLiveness should make non-live operands Availability::unavailable instead of Availability() https://bugs.webkit.org/show_bug.cgi?id=193711 <rdar://problem/47250262> Reviewed by Saam Barati. When pruning OSR Availability based on bytecode liveness, we accidentally clear the Availability (making it DeadFlush) instead of making it Availability::unavailable() (Making it ConflictingFlush). In OSRAvailabilityAnalysisPhase, we perform forward analysis. We first clear all the availability of basic blocks DeadFlush, which is an empty set. And then, we set operands in the root block ConflictingFlush. In this forward analysis, DeadFlush is BOTTOM, and ConflictingFlush is TOP. Then, we propagate information by merging availability until we reach to the fixed-point. As an optimization, we perform "pruning" of the availability in the head of the basic blocks. We remove availabilities of operands which are not live in the bytecode liveness at the head of the basic block. The problem is, when removing availabilities, we set DeadFlush for them instead of ConflictingFlush. Basically, it means that we set BOTTOM (an empty set) instead of TOP. Let's consider the following simple example. We have 6 basic blocks, and they are connected as follows. BB0 -> BB1 -> BB2 -> BB4 | \ ^ v > BB3 / BB5 And consider about loc1 in FTL, which is required to be recovered in BB4's OSR exit. BB0 does nothing head: loc1 is dead tail: loc1 is dead BB1 has MovHint @1, loc1 head: loc1 is dead tail: loc1 is live BB2 does nothing head: loc1 is live tail: loc1 is live BB3 has PutStack @1, loc1 head: loc1 is live tail: loc1 is live BB4 has OSR exit using loc1 head: loc1 is live tail: loc1 is live (in bytecode) BB5 does nothing head: loc1 is dead tail: loc1 is dead In our OSR Availability analysis, we always prune loc1 result in BB1's head since its head says "loc1 is dead". But at that time, we clear the availability for loc1, which makes it DeadFlush, instead of making it ConflictingFlush. So, the flush format of loc1 in each tail of BB is like this. BB0 ConflictingFlush (because all the local operands are initialized with ConflictingFlush) BB1 DeadFlush+@1 (pruning clears it) BB2 DeadFlush+@1 (since it is propagated from BB1) BB3 FlushedJSValue+@1 with loc1 (since it has PutStack) BB4 FlushedJSValue+@1 with loc1 (since MERGE(DeadFlush, FlushedJSValue) = FlushedJSValue) BB5 DeadFlush (pruning clears it) Then, if we go the path BB0->BB1->BB2->BB4, we read the value from the stack while it is not flushed. The correct fix is making availability "unavailable" when pruning based on bytecode liveness. * dfg/DFGAvailabilityMap.cpp: (JSC::DFG::AvailabilityMap::pruneByLiveness): When pruning availability, we first set all the operands Availability::unavailable(), and copy the calculated value from the current availability map. * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): Add logging things for debugging. 2019-01-25 Mark Lam <mark.lam@apple.com> Cherry-pick r240335. rdar://problem/47494779 2019-01-23 David Kilzer <ddkilzer@apple.com> [JSC] Duplicate global variables: JSC::opcodeLengths <https://webkit.org/b/193714> <rdar://problem/47340200> Reviewed by Mark Lam. * bytecode/Opcode.cpp: (JSC::opcodeLengths): Move array implementation here and mark const. * bytecode/Opcode.h: (JSC::opcodeLengths): Change to extern declaration. 2019-01-25 Mark Lam <mark.lam@apple.com> Cherry-pick r240329. rdar://problem/47458354 This is for a follow up fix that was missed in the cherry-pick for rdar://problem/47458354. 2019-01-22 Yusuke Suzuki <ysuzuki@apple.com> Unreviewed, fix initial global lexical binding epoch https://bugs.webkit.org/show_bug.cgi?id=193603 <rdar://problem/47380869> * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): 2019-01-25 Mark Lam <mark.lam@apple.com> Cherry-pick r239940. rdar://problem/47295340 Also picked up a few missing changes in JITPropertyAccess32_64.cpp from the cherry-pick of r240041. 2019-01-14 Mark Lam <mark.lam@apple.com> Fix all CLoop JSC test failures (including some LLInt bugs due to recent bytecode format change). https://bugs.webkit.org/show_bug.cgi?id=193402 <rdar://problem/46012309> Reviewed by Keith Miller. The CLoop builds via build-jsc were previously completely disabled after our change to enable ASM LLInt build without the JIT. As a result, JSC tests have regressed on CLoop builds. The CLoop builds and tests will be re-enabled when the fix for https://bugs.webkit.org/show_bug.cgi?id=192955 lands. This patch fixes all the regressions (and some old bugs) so that the CLoop test bots won't be red when CLoop build gets re-enabled. In this patch, we do the following: 1. Change CLoopStack::grow() to set the new CLoop stack top at the maximum allocated capacity (after discounting the reserved zone) as opposed to setting it only at the level that the client requested. This fixes a small performance bug that I happened to noticed when I was debugging a stack issue. It does not affect correctness. 2. In LowLevelInterpreter32_64.asm: 1. Fix loadConstantOrVariableTag() to use subi for computing the constant index because the VirtualRegister offset and FirstConstantRegisterIndex values it is operating on are both signed ints. This is just to be pedantic. The previous use of subu will still produce a correct value. 2. Fix llintOpWithReturn() to use getu (instead of get) for reading OpIsCellWithType::type because it is of type JSType, which is a uint8_t. 3. Fix llintOpWithMetadata() to use loadis for loading OpGetById::Metadata::modeMetadata.protoLoadMode.cachedOffset[t5] because it is of type PropertyOffset, which is a signed int. 4. Fix commonCallOp() to use getu for loading fields argv and argc because they are of type unsigned for OpCall, OpConstruct, and OpTailCall, which are the clients of commonCallOp. 5. Fix llintOpWithMetadata() and getClosureVar() to use loadp for loading OpGetFromScope::Metadata::operand because it is of type uintptr_t. 3. In LowLevelInterpreter64.asm: 1. Fix llintOpWithReturn() to use getu for reading OpIsCellWithType::type because it is of type JSType, which is a uint8_t. 2. Fix llintOpWithMetadata() to use loadi for loading OpGetById::Metadata::modeMetadata.protoLoadMode.structure[t2] because it is of type StructureID, which is a uint32_t. Fix llintOpWithMetadata() to use loadis for loading OpGetById::Metadata::modeMetadata.protoLoadMode.cachedOffset[t2] because it is of type PropertyOffset, which is a signed int. 3. commonOp() should reload the metadataTable for op_catch because unlike for the ASM LLInt, the exception unwinding code is not able to restore "callee saved registers" for the CLoop interpreter because the CLoop uses pseudo-registers (see the CLoopRegister class). This was the source of many exotic Cloop failures after the bytecode format change (which introduced the metadataTable callee saved register). Hence, we fix it by reloading metadataTable's value on re-entry via op_catch for exception handling. We already take care of restoring it in op_ret. 4. Fix llintOpWithMetadata() and getClosureVar() to use loadp for loading OpGetFromScope::Metadata::operand because it is of type uintptr_t. 4. In LowLevelInterpreter.asm: Fix metadata() to use loadi for loading metadataTable offsets because they are of type unsigned. This was also a source of many exotic CLoop test failures. 5. Change CLoopRegister into a class with a uintptr_t as its storage element. Previously, we were using a union to convert between various value types that we would store in this pseudo-register. This method of type conversion is undefined behavior according to the C++ spec. As a result, the C++ compiler may choose to elide some CLoop statements, thereby resulting in some exotic bugs. We fix this by now always using accessor methods and assignment operators to ensure that we use bitwise_cast to do the type conversions. Since bitwise_cast uses a memcpy, this ensures that there's no undefined behavior, and that CLoop statements won't get elided willy-nilly by the compiler. Ditto for the CloopDobleRegisters. Similarly, use bitwise_cast for ints2Double() and double2Ints() utility functions. Also use bitwise_cast (instead of reinterpret_cast) for the CLoop CAST macro. 6. Fix cloop.rb to use the new CLoopRegister and CLoopDoubleRegister classes. Add a clLValue accessor for offlineasm operand types to distinguish LValue use of the operands from RValue uses. Replace the use of clearHighWord() with simply casting to uint32_t. This is more efficient for the C++ compiler (and help speed up debug build runs). Also fix 32-bit arithmetic operations to only set the lower 32-bit value of the pseudo registers. This fixes some CLoop JSC test failures. This patch has been manually tested with the JSC tests on the following builds: 64bit X86 ASM LLLint (without JIT), 64bit and 32bit X86 CLoop, and ARMv7 Cloop. * interpreter/CLoopStack.cpp: (JSC::CLoopStack::grow): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: (JSC::CLoopRegister::i const): (JSC::CLoopRegister::u const): (JSC::CLoopRegister::i32 const): (JSC::CLoopRegister::u32 const): (JSC::CLoopRegister::i8 const): (JSC::CLoopRegister::u8 const): (JSC::CLoopRegister::ip const): (JSC::CLoopRegister::i8p const): (JSC::CLoopRegister::vp const): (JSC::CLoopRegister::cvp const): (JSC::CLoopRegister::callFrame const): (JSC::CLoopRegister::execState const): (JSC::CLoopRegister::instruction const): (JSC::CLoopRegister::vm const): (JSC::CLoopRegister::cell const): (JSC::CLoopRegister::protoCallFrame const): (JSC::CLoopRegister::nativeFunc const): (JSC::CLoopRegister::i64 const): (JSC::CLoopRegister::u64 const): (JSC::CLoopRegister::encodedJSValue const): (JSC::CLoopRegister::opcode const): (JSC::CLoopRegister::operator ExecState*): (JSC::CLoopRegister::operator const Instruction*): (JSC::CLoopRegister::operator JSCell*): (JSC::CLoopRegister::operator ProtoCallFrame*): (JSC::CLoopRegister::operator Register*): (JSC::CLoopRegister::operator VM*): (JSC::CLoopRegister::operator=): (JSC::CLoopRegister::bitsAsDouble const): (JSC::CLoopRegister::bitsAsInt64 const): (JSC::CLoopDoubleRegister::operator T const): (JSC::CLoopDoubleRegister::d const): (JSC::CLoopDoubleRegister::bitsAsInt64 const): (JSC::CLoopDoubleRegister::operator=): (JSC::LLInt::ints2Double): (JSC::LLInt::double2Ints): (JSC::LLInt::decodeResult): (JSC::CLoop::execute): (JSC::LLInt::Ints2Double): Deleted. (JSC::LLInt::Double2Ints): Deleted. (JSC::CLoopRegister::CLoopRegister): Deleted. (JSC::CLoopRegister::clearHighWord): Deleted. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/cloop.rb: 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240327. rdar://problem/47494707 REGRESSION(r239612) Crash at runtime due to broken DFG assumption https://bugs.webkit.org/show_bug.cgi?id=193709 <rdar://problem/47363838> Unreviewed, rollout to watch the tests. JSTests: * stress/object-tostring-changed-proto.js: Removed. * stress/object-tostring-changed.js: Removed. * stress/object-tostring-misc.js: Removed. * stress/object-tostring-other.js: Removed. * stress/object-tostring-untyped.js: Removed. Source/JavaScriptCore: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupObjectToString): Deleted. * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileObjectToString): Deleted. * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf): (JSC::FTL::DFG::LowerDFGToB3::compileObjectToString): Deleted. * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/ObjectPrototype.cpp: (JSC::ObjectPrototype::finishCreation): (JSC::objectProtoFuncToString): * runtime/ObjectPrototype.h: * runtime/ObjectPrototypeInlines.h: Removed. * runtime/StructureRareData.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240327 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-22 Yusuke Suzuki <ysuzuki@apple.com> REGRESSION(r239612) Crash at runtime due to broken DFG assumption https://bugs.webkit.org/show_bug.cgi?id=193709 <rdar://problem/47363838> Unreviewed, rollout to watch the tests. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupObjectToString): Deleted. * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileObjectToString): Deleted. * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf): (JSC::FTL::DFG::LowerDFGToB3::compileObjectToString): Deleted. * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/ObjectPrototype.cpp: (JSC::ObjectPrototype::finishCreation): (JSC::objectProtoFuncToString): * runtime/ObjectPrototype.h: * runtime/ObjectPrototypeInlines.h: Removed. * runtime/StructureRareData.h: 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r239951. rdar://problem/47295353 [JSC] Do not use asArrayModes() with Structures because it discards TypedArray information https://bugs.webkit.org/show_bug.cgi?id=193372 Reviewed by Saam Barati. JSTests: * stress/typed-array-array-modes-profile.js: Added. (foo): Source/JavaScriptCore: When RegisteredStructureSet is filtered with AbstractValue, we use structure, SpeculationType, and ArrayModes. However, we use asArrayModes() function with IndexingMode to compute the ArrayModes in AbstractValue. This is wrong since this discards TypedArray ArrayModes. As a result, if RegisteredStructureSet with TypedArrays is filtered with ArrayModes of AbstractValue populated from TypedArrays, we filter all the structures out since AbstractValue's ArrayModes become NonArray, which is wrong with the TypedArrays' ArrayModes. This leads to incorrect FTL code generation with MultiGetByOffset etc. nodes because, 1. AI think that this MultiGetByOffset never succeeds since all the values of RegisteredStructureSet are filtered out by the AbstractValue. 2. AI says the state of MultiGetByOffset is invalid since AI think it never succeeds. 3. So subsequent code becomes FTL crash code since AI think the execution should do OSR exit. 4. Then, FTL emits the code for MultiGetByOffset, and emits crash after that. 5. But in reality, the incoming value can match to the one of the RegisteredStructureSet value since (1)'s structures are incorrectly filtered by the incorrect ArrayModes. 6. Then, the execution goes on, and falls into the FTL crash. This patch fixes the incorrect ArrayModes calculation by the following changes 1. Rename asArrayModes to asArrayModesIgnoringTypedArrays. 2. Fix incorrect asArrayModesIgnoringTypedArrays use in our code. Use arrayModesFromStructure instead. 3. Fix OSR exit code which stores incorrect ArrayModes to the profiles. * bytecode/ArrayProfile.cpp: (JSC::dumpArrayModes): (JSC::ArrayProfile::computeUpdatedPrediction): * bytecode/ArrayProfile.h: (JSC::asArrayModesIgnoringTypedArrays): (JSC::arrayModesFromStructure): (JSC::arrayModesIncludeIgnoringTypedArrays): (JSC::shouldUseSlowPutArrayStorage): (JSC::shouldUseFastArrayStorage): (JSC::shouldUseContiguous): (JSC::shouldUseDouble): (JSC::shouldUseInt32): (JSC::asArrayModes): Deleted. (JSC::arrayModeFromStructure): Deleted. (JSC::arrayModesInclude): Deleted. * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::observeTransitions): (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::mergeOSREntryValue): (JSC::DFG::AbstractValue::contains const): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::observeTransition): (JSC::DFG::AbstractValue::validate const): (JSC::DFG::AbstractValue::observeIndexingTypeTransition): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::fromObserved): (JSC::DFG::ArrayMode::alreadyChecked const): * dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::structureWouldPassArrayModeFiltering): (JSC::DFG::ArrayMode::arrayModesThatPassFiltering const): (JSC::DFG::ArrayMode::arrayModesWithIndexingShape const): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): (JSC::DFG::OSRExit::compileExit): * dfg/DFGRegisteredStructureSet.cpp: (JSC::DFG::RegisteredStructureSet::filterArrayModes): (JSC::DFG::RegisteredStructureSet::arrayModesFromStructures const): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * jit/JITInlines.h: (JSC::JIT::chooseArrayMode): (JSC::arrayProfileSaw): Deleted. * runtime/JSType.h: (JSC::isTypedArrayType): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239951 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-14 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Do not use asArrayModes() with Structures because it discards TypedArray information https://bugs.webkit.org/show_bug.cgi?id=193372 Reviewed by Saam Barati. When RegisteredStructureSet is filtered with AbstractValue, we use structure, SpeculationType, and ArrayModes. However, we use asArrayModes() function with IndexingMode to compute the ArrayModes in AbstractValue. This is wrong since this discards TypedArray ArrayModes. As a result, if RegisteredStructureSet with TypedArrays is filtered with ArrayModes of AbstractValue populated from TypedArrays, we filter all the structures out since AbstractValue's ArrayModes become NonArray, which is wrong with the TypedArrays' ArrayModes. This leads to incorrect FTL code generation with MultiGetByOffset etc. nodes because, 1. AI think that this MultiGetByOffset never succeeds since all the values of RegisteredStructureSet are filtered out by the AbstractValue. 2. AI says the state of MultiGetByOffset is invalid since AI think it never succeeds. 3. So subsequent code becomes FTL crash code since AI think the execution should do OSR exit. 4. Then, FTL emits the code for MultiGetByOffset, and emits crash after that. 5. But in reality, the incoming value can match to the one of the RegisteredStructureSet value since (1)'s structures are incorrectly filtered by the incorrect ArrayModes. 6. Then, the execution goes on, and falls into the FTL crash. This patch fixes the incorrect ArrayModes calculation by the following changes 1. Rename asArrayModes to asArrayModesIgnoringTypedArrays. 2. Fix incorrect asArrayModesIgnoringTypedArrays use in our code. Use arrayModesFromStructure instead. 3. Fix OSR exit code which stores incorrect ArrayModes to the profiles. * bytecode/ArrayProfile.cpp: (JSC::dumpArrayModes): (JSC::ArrayProfile::computeUpdatedPrediction): * bytecode/ArrayProfile.h: (JSC::asArrayModesIgnoringTypedArrays): (JSC::arrayModesFromStructure): (JSC::arrayModesIncludeIgnoringTypedArrays): (JSC::shouldUseSlowPutArrayStorage): (JSC::shouldUseFastArrayStorage): (JSC::shouldUseContiguous): (JSC::shouldUseDouble): (JSC::shouldUseInt32): (JSC::asArrayModes): Deleted. (JSC::arrayModeFromStructure): Deleted. (JSC::arrayModesInclude): Deleted. * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::observeTransitions): (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::mergeOSREntryValue): (JSC::DFG::AbstractValue::contains const): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::observeTransition): (JSC::DFG::AbstractValue::validate const): (JSC::DFG::AbstractValue::observeIndexingTypeTransition): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::fromObserved): (JSC::DFG::ArrayMode::alreadyChecked const): * dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::structureWouldPassArrayModeFiltering): (JSC::DFG::ArrayMode::arrayModesThatPassFiltering const): (JSC::DFG::ArrayMode::arrayModesWithIndexingShape const): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): (JSC::DFG::OSRExit::compileExit): * dfg/DFGRegisteredStructureSet.cpp: (JSC::DFG::RegisteredStructureSet::filterArrayModes): (JSC::DFG::RegisteredStructureSet::arrayModesFromStructures const): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * jit/JITInlines.h: (JSC::JIT::chooseArrayMode): (JSC::arrayProfileSaw): Deleted. * runtime/JSType.h: (JSC::isTypedArrayType): 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r239947. rdar://problem/47295371 Re-enable ability to build --cloop builds. https://bugs.webkit.org/show_bug.cgi?id=192955 Source/JavaScriptCore: <rdar://problem/46882363> Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: Source/WebCore: Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: Source/WebCore/PAL: <rdar://problem/46882363> Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: Source/WebKit: <rdar://problem/46882363> Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: <rdar://problem/46882363> Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: Tools: <rdar://problem/46882363> Reviewed by Saam barati and Keith Miller. The --cloop build option was being ignored this whole time since r236381. This patch makes it possible to build CLoop builds again. * Scripts/build-jsc: * Scripts/webkitperl/FeatureList.pm: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239947 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-14 Mark Lam <mark.lam@apple.com> Re-enable ability to build --cloop builds. https://bugs.webkit.org/show_bug.cgi?id=192955 <rdar://problem/46882363> Reviewed by Saam barati and Keith Miller. * Configurations/FeatureDefines.xcconfig: 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r239929. rdar://problem/47295348 Fix property access on ARM with the baseline JIT https://bugs.webkit.org/show_bug.cgi?id=193393 Reviewed by Yusuke Suzuki. Code was still using currentInstruction[4] to access the instruction's metadata. Updated to use metadata.getPutInfo and metadata.resolveType. * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239929 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-14 Dominik Infuehr <dinfuehr@igalia.com> Fix property access on ARM with the baseline JIT https://bugs.webkit.org/show_bug.cgi?id=193393 Reviewed by Yusuke Suzuki. Code was still using currentInstruction[4] to access the instruction's metadata. Updated to use metadata.getPutInfo and metadata.resolveType. * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240254. rdar://problem/47458354 [JSC] Invalidate old scope operations using global lexical binding epoch https://bugs.webkit.org/show_bug.cgi?id=193603 <rdar://problem/47380869> Patch by Yusuke Suzuki <ysuzuki@apple.com> on 2019-01-22 Reviewed by Saam Barati. JSTests: * stress/let-lexical-binding-shadow-existing-global-property-ftl.js: * stress/scope-operation-cache-global-property-before-deleting.js: Added. (shouldThrow): (bar): * stress/scope-operation-cache-global-property-bump-counter.js: Added. (shouldBe): (get1): (get2): (get1If): (get2If): * stress/scope-operation-cache-global-property-even-if-it-fails.js: Added. (shouldThrow): (foo): Source/JavaScriptCore: Even if the global lexical binding does not shadow the global property at that time, we need to clear the cached information in scope related operations since we may have a global property previously. Consider the following example, foo = 0; function get() { return foo; } print(get()); // 0 print(get()); // 0 delete globalThis.foo; $.evalScript(`const foo = 42;`); print(get()); // Should be 42, but it returns 0 if the cached information in get() is not cleared. To invalidate the cache easily, we introduce global lexical binding epoch. It is bumped every time we introduce a new lexical binding into JSGlobalLexicalEnvironment, since that name could shadow the global property name previously. In op_resolve_scope, we first check the epoch stored in the metadata, and go to slow path if it is not equal to the current epoch. Our slow path code convert the scope operation to the appropriate one even if the resolve type is not UnresolvedProperty type. After updating the resolve type of the bytecode, we update the cached epoch to the current one, so that we can use the cached information as long as we stay in the same epoch. In op_get_from_scope and op_put_to_scope, we do not use this epoch since Structure check can do the same thing instead. If op_resolve_type is updated by the epoch, and if it starts returning JSGlobalLexicalEnvironment instead JSGlobalObject, obviously the structure check fails. And in the slow path, we update op_get_from_scope and op_put_to_scope appropriately. So, the metadata for scope related bytecodes are eventually updated to the appropriate one. In DFG and FTL, we use the watchpoint based approach. In DFG and FTL, we concurrently attempt to get the watchpoint for the lexical binding and look into it by using `isStillValid()` to avoid infinite compile-and-fail loop. When the global lexical binding epoch overflows we iterate all the live CodeBlock and update the op_resolve_scope's epoch. Even if the shadowing happens, it is OK if we bump the epoch, since op_resolve_scope will return JSGlobalLexicalEnvironment instead of JSGlobalObject, and following structure check in op_put_to_scope and op_get_from_scope fail. We do not need to update op_get_from_scope and op_put_to_scope because of the same reason. * bytecode/BytecodeList.rb: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::notifyLexicalBindingUpdate): (JSC::CodeBlock::notifyLexicalBindingShadowing): Deleted. * bytecode/CodeBlock.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGDesiredGlobalProperties.cpp: (JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread): * dfg/DFGDesiredGlobalProperties.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::watchGlobalProperty): * dfg/DFGGraph.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::isStillValidOnMainThread): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_resolve_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::tryCachePutToScopeGlobal): (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch): (JSC::JSGlobalObject::getReferencedPropertyWatchpointSet): (JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet): (JSC::JSGlobalObject::notifyLexicalBindingShadowing): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::globalLexicalBindingEpoch const): (JSC::JSGlobalObject::globalLexicalBindingEpochOffset): (JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch): * runtime/Options.cpp: (JSC::correctOptions): (JSC::Options::initialize): (JSC::Options::setOptions): (JSC::Options::setOptionWithoutAlias): * runtime/Options.h: * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240254 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-22 Yusuke Suzuki <ysuzuki@apple.com> [JSC] Invalidate old scope operations using global lexical binding epoch https://bugs.webkit.org/show_bug.cgi?id=193603 <rdar://problem/47380869> Reviewed by Saam Barati. Even if the global lexical binding does not shadow the global property at that time, we need to clear the cached information in scope related operations since we may have a global property previously. Consider the following example, foo = 0; function get() { return foo; } print(get()); // 0 print(get()); // 0 delete globalThis.foo; $.evalScript(`const foo = 42;`); print(get()); // Should be 42, but it returns 0 if the cached information in get() is not cleared. To invalidate the cache easily, we introduce global lexical binding epoch. It is bumped every time we introduce a new lexical binding into JSGlobalLexicalEnvironment, since that name could shadow the global property name previously. In op_resolve_scope, we first check the epoch stored in the metadata, and go to slow path if it is not equal to the current epoch. Our slow path code convert the scope operation to the appropriate one even if the resolve type is not UnresolvedProperty type. After updating the resolve type of the bytecode, we update the cached epoch to the current one, so that we can use the cached information as long as we stay in the same epoch. In op_get_from_scope and op_put_to_scope, we do not use this epoch since Structure check can do the same thing instead. If op_resolve_type is updated by the epoch, and if it starts returning JSGlobalLexicalEnvironment instead JSGlobalObject, obviously the structure check fails. And in the slow path, we update op_get_from_scope and op_put_to_scope appropriately. So, the metadata for scope related bytecodes are eventually updated to the appropriate one. In DFG and FTL, we use the watchpoint based approach. In DFG and FTL, we concurrently attempt to get the watchpoint for the lexical binding and look into it by using `isStillValid()` to avoid infinite compile-and-fail loop. When the global lexical binding epoch overflows we iterate all the live CodeBlock and update the op_resolve_scope's epoch. Even if the shadowing happens, it is OK if we bump the epoch, since op_resolve_scope will return JSGlobalLexicalEnvironment instead of JSGlobalObject, and following structure check in op_put_to_scope and op_get_from_scope fail. We do not need to update op_get_from_scope and op_put_to_scope because of the same reason. * bytecode/BytecodeList.rb: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::notifyLexicalBindingUpdate): (JSC::CodeBlock::notifyLexicalBindingShadowing): Deleted. * bytecode/CodeBlock.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGDesiredGlobalProperties.cpp: (JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread): * dfg/DFGDesiredGlobalProperties.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::watchGlobalProperty): * dfg/DFGGraph.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::isStillValidOnMainThread): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_resolve_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::tryCachePutToScopeGlobal): (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::bumpGlobalLexicalBindingEpoch): (JSC::JSGlobalObject::getReferencedPropertyWatchpointSet): (JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet): (JSC::JSGlobalObject::notifyLexicalBindingShadowing): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::globalLexicalBindingEpoch const): (JSC::JSGlobalObject::globalLexicalBindingEpochOffset): (JSC::JSGlobalObject::addressOfGlobalLexicalBindingEpoch): * runtime/Options.cpp: (JSC::correctOptions): (JSC::Options::initialize): (JSC::Options::setOptions): (JSC::Options::setOptionWithoutAlias): * runtime/Options.h: * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240138. rdar://problem/47458154 Audit bytecode fields and ensure that LLInt instructions for accessing them are appropriate. https://bugs.webkit.org/show_bug.cgi?id=193557 <rdar://problem/47369125> Reviewed by Yusuke Suzuki. 1. Rename some bytecode fields so that it's easier to discern whether the LLInt is accessing them the right way: - distinguish between targetVirtualRegister and targetLabel. - name all StructureID fields as structureID (oldStructureID, newStructureID) instead of structure (oldStructure, newStructure). 2. Use bitwise_cast in struct Fits when sizeof(T) == size. This prevents potential undefined behavior issues arising from doing assignments with reinterpret_cast'ed pointers. 3. Make Special::Pointer an unsigned type (previously int). Make ResolveType an unsigned type (previously int). 4. In LowLevelInterpreter*.asm: - rename the op macro argument to opcodeName or opcodeStruct respectively. This makes it clearer which argument type the macro is working with. - rename the name macro argument to opcodeName. - fix operator types to match the field type being accessed. The following may have resulted in bugs before: 1. The following should be read with getu() instead of get() because they are unsigned ints: OpSwitchImm::m_tableIndex OpSwitchChar::m_tableIndex OpGetFromArguments::m_index OpPutToArguments::m_index OpGetRestLength::m_numParametersToSkip OpJneqPtr::m_specialPointer should also be read with getu() though this wasn't a bug because it was previously an int by default, and is only changed to an unsigned int in this patch. 2.The following should be read with loadi (not loadp) because they are of unsigned type (not a pointer): OpResolveScope::Metadata::m_resolveType CodeBlock::m_numParameters (see prepareForTailCall) 3. OpPutToScope::Metadata::m_operand should be read with loadp (not loadis) because it is a uintptr_t. 4. The following should be read with loadi (not loadis) because they are unsigned ints: OpNegate::Metadata::m_arithProfile + ArithProfile::m_bits OpPutById::Metadata::m_oldStructureID OpPutToScope::Metadata::m_getPutInfo + GetPutInfo::m_operand These may not have manifested in bugs because the operations that follow the load are 32-bit instructions which ignore the high word. 5. Give class GetPutInfo a default constructor so that we can use bitwise_cast on it. Also befriend LLIntOffsetsExtractor so that we can take the offset of m_operand in it. * bytecode/ArithProfile.h: * bytecode/BytecodeList.rb: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::finalizeLLIntInlineCaches): * bytecode/Fits.h: * bytecode/GetByIdMetadata.h: * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache): * bytecode/PreciseJumpTargetsInlines.h: (JSC::jumpTargetForInstruction): (JSC::updateStoredJumpTargetsForInstruction): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): * bytecode/SpecialPointer.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::Label::setLocation): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * jit/JITArithmetic.cpp: (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareAndJumpSlow): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emitBinaryDoubleOp): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_jneq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::emit_op_profile_type): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_jeq): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emit_op_profile_type): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::setupGetByIdPrototypeCache): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: * runtime/GetPutInfo.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240138 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-17 Mark Lam <mark.lam@apple.com> Audit bytecode fields and ensure that LLInt instructions for accessing them are appropriate. https://bugs.webkit.org/show_bug.cgi?id=193557 <rdar://problem/47369125> Reviewed by Yusuke Suzuki. 1. Rename some bytecode fields so that it's easier to discern whether the LLInt is accessing them the right way: - distinguish between targetVirtualRegister and targetLabel. - name all StructureID fields as structureID (oldStructureID, newStructureID) instead of structure (oldStructure, newStructure). 2. Use bitwise_cast in struct Fits when sizeof(T) == size. This prevents potential undefined behavior issues arising from doing assignments with reinterpret_cast'ed pointers. 3. Make Special::Pointer an unsigned type (previously int). Make ResolveType an unsigned type (previously int). 4. In LowLevelInterpreter*.asm: - rename the op macro argument to opcodeName or opcodeStruct respectively. This makes it clearer which argument type the macro is working with. - rename the name macro argument to opcodeName. - fix operator types to match the field type being accessed. The following may have resulted in bugs before: 1. The following should be read with getu() instead of get() because they are unsigned ints: OpSwitchImm::m_tableIndex OpSwitchChar::m_tableIndex OpGetFromArguments::m_index OpPutToArguments::m_index OpGetRestLength::m_numParametersToSkip OpJneqPtr::m_specialPointer should also be read with getu() though this wasn't a bug because it was previously an int by default, and is only changed to an unsigned int in this patch. 2.The following should be read with loadi (not loadp) because they are of unsigned type (not a pointer): OpResolveScope::Metadata::m_resolveType CodeBlock::m_numParameters (see prepareForTailCall) 3. OpPutToScope::Metadata::m_operand should be read with loadp (not loadis) because it is a uintptr_t. 4. The following should be read with loadi (not loadis) because they are unsigned ints: OpNegate::Metadata::m_arithProfile + ArithProfile::m_bits OpPutById::Metadata::m_oldStructureID OpPutToScope::Metadata::m_getPutInfo + GetPutInfo::m_operand These may not have manifested in bugs because the operations that follow the load are 32-bit instructions which ignore the high word. 5. Give class GetPutInfo a default constructor so that we can use bitwise_cast on it. Also befriend LLIntOffsetsExtractor so that we can take the offset of m_operand in it. * bytecode/ArithProfile.h: * bytecode/BytecodeList.rb: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::finalizeLLIntInlineCaches): * bytecode/Fits.h: * bytecode/GetByIdMetadata.h: * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache): * bytecode/PreciseJumpTargetsInlines.h: (JSC::jumpTargetForInstruction): (JSC::updateStoredJumpTargetsForInstruction): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): * bytecode/SpecialPointer.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::Label::setLocation): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * jit/JITArithmetic.cpp: (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareAndJumpSlow): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emitBinaryDoubleOp): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_jneq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::emit_op_profile_type): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_jeq): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emit_op_profile_type): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::setupGetByIdPrototypeCache): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: * runtime/GetPutInfo.h: 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240106. rdar://problem/47458403 [JSC] ToThis omission in DFGByteCodeParser is wrong https://bugs.webkit.org/show_bug.cgi?id=193513 <rdar://problem/45842236> Reviewed by Saam Barati. JSTests: * stress/to-this-omission-with-different-strict-modes.js: Added. (thisA): (thisAStrictWrapper): Source/JavaScriptCore: DFGByteCodeParser omitted ToThis node when we have `ToThis(ToThis(value))`. This semantics is wrong if ToThis has different semantics in the sloppy mode and the strict mode. If we convert `ToThisInSloppyMode(ToThisInStrictMode(boolean))` to `ToThisInStrictMode(boolean)`, we get boolean instead of BooleanObject. This optimization is introduced more than 7 years ago, and from that, we have several optimizations that can remove such ToThis nodes in BytecodeParser, AI, and Fixup. Furthermore, this optimization is simply wrong since `toThis()` function of JSCell can be defined as they want. Before ensuring all the toThis function is safe, we should not fold `ToThis(ToThis(value))` => `ToThis(value)`. This patch just removes the problematic optimization. The performance numbers look neutral. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240106 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-17 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] ToThis omission in DFGByteCodeParser is wrong https://bugs.webkit.org/show_bug.cgi?id=193513 <rdar://problem/45842236> Reviewed by Saam Barati. DFGByteCodeParser omitted ToThis node when we have `ToThis(ToThis(value))`. This semantics is wrong if ToThis has different semantics in the sloppy mode and the strict mode. If we convert `ToThisInSloppyMode(ToThisInStrictMode(boolean))` to `ToThisInStrictMode(boolean)`, we get boolean instead of BooleanObject. This optimization is introduced more than 7 years ago, and from that, we have several optimizations that can remove such ToThis nodes in BytecodeParser, AI, and Fixup. Furthermore, this optimization is simply wrong since `toThis()` function of JSCell can be defined as they want. Before ensuring all the toThis function is safe, we should not fold `ToThis(ToThis(value))` => `ToThis(value)`. This patch just removes the problematic optimization. The performance numbers look neutral. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240041. rdar://problem/47458234 Refactor new bytecode structs so that the fields are prefixed with "m_". https://bugs.webkit.org/show_bug.cgi?id=193467 Reviewed by Saam Barati and Tadeu Zagallo. This makes it easier to do a manual audit of type correctness of the LLInt instructions used to access these fields. Without this change, it would be difficult (and error prone) to distinguish the difference between field names and macro variables. This audit will be done after this patch lands. * bytecode/BytecodeGeneratorification.cpp: (JSC::BytecodeGeneratorification::BytecodeGeneratorification): * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFromLLInt): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::finalizeLLIntInlineCaches): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow): (JSC::CodeBlock::getArrayProfile): (JSC::CodeBlock::notifyLexicalBindingShadowing): (JSC::CodeBlock::tryGetValueProfileForBytecodeOffset): (JSC::CodeBlock::arithProfileForPC): (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): * bytecode/CodeBlockInlines.h: (JSC::CodeBlock::forEachValueProfile): (JSC::CodeBlock::forEachArrayProfile): (JSC::CodeBlock::forEachArrayAllocationProfile): (JSC::CodeBlock::forEachObjectAllocationProfile): (JSC::CodeBlock::forEachLLIntCallLinkInfo): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache): * bytecode/PreciseJumpTargetsInlines.h: (JSC::jumpTargetForInstruction): (JSC::extractStoredJumpTargetsForInstruction): (JSC::updateStoredJumpTargetsForInstruction): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): * bytecode/UnlinkedCodeBlock.cpp: (JSC::dumpLineColumnEntry): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::fuseCompareAndJump): (JSC::BytecodeGenerator::fuseTestAndJmp): (JSC::BytecodeGenerator::emitEqualityOp): (JSC::BytecodeGenerator::endSwitch): (JSC::StructureForInContext::finalize): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleVarargsCall): (JSC::DFG::ByteCodeParser::parseGetById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::handlePutByVal): (JSC::DFG::ByteCodeParser::handlePutAccessorById): (JSC::DFG::ByteCodeParser::handlePutAccessorByVal): (JSC::DFG::ByteCodeParser::handleNewFunc): (JSC::DFG::ByteCodeParser::handleNewFuncExp): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareCatchOSREntry): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * generator/Argument.rb: * generator/Metadata.rb: * generator/Opcode.rb: * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emit_op_mod): (JSC::JIT::emit_op_negate): (JSC::JIT::emitBitBinaryOpFastPath): (JSC::JIT::emit_op_bitnot): (JSC::JIT::emitRightShiftFastPath): (JSC::JIT::emit_op_add): (JSC::JIT::emitMathICFast): (JSC::JIT::emitMathICSlow): (JSC::JIT::emit_op_div): (JSC::JIT::emit_op_mul): (JSC::JIT::emit_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_mod): * jit/JITCall.cpp: (JSC::JIT::emitPutCallResult): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileTailCall): (JSC::JIT::compileOpCall): * jit/JITCall32_64.cpp: (JSC::JIT::emitPutCallResult): (JSC::JIT::emit_op_ret): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCall): * jit/JITInlines.h: (JSC::JIT::emitValueProfilingSiteIfProfiledOpcode): (JSC::JIT::emitValueProfilingSite): (JSC::JIT::copiedGetPutInfo): (JSC::JIT::copiedArithProfile): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_is_undefined_or_null): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emit_op_throw): (JSC::JIT::compileOpStrictEq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_debug): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_new_regexp): (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emitNewFuncExprCommon): (JSC::JIT::emit_op_new_array): (JSC::JIT::emit_op_new_array_with_size): (JSC::JIT::emit_op_has_structure_property): (JSC::JIT::emit_op_has_indexed_property): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emit_op_enumerator_structure_pname): (JSC::JIT::emit_op_enumerator_generic_pname): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): (JSC::JIT::emit_op_profile_control_flow): (JSC::JIT::emit_op_argument_count): (JSC::JIT::emit_op_get_rest_length): (JSC::JIT::emit_op_get_argument): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_is_undefined_or_null): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emit_op_neq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::compileOpStrictEq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_debug): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emit_op_has_structure_property): (JSC::JIT::emit_op_has_indexed_property): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emit_op_enumerator_structure_pname): (JSC::JIT::emit_op_enumerator_generic_pname): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/JITOperations.cpp: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::setupGetByIdPrototypeCache): (JSC::LLInt::getByVal): (JSC::LLInt::genericCall): (JSC::LLInt::varargsSetup): (JSC::LLInt::commonCallEval): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): (JSC::updateArithProfileForUnaryArithOp): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::tryCachePutToScopeGlobal): (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240041 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-16 Mark Lam <mark.lam@apple.com> Refactor new bytecode structs so that the fields are prefixed with "m_". https://bugs.webkit.org/show_bug.cgi?id=193467 Reviewed by Saam Barati and Tadeu Zagallo. This makes it easier to do a manual audit of type correctness of the LLInt instructions used to access these fields. Without this change, it would be difficult (and error prone) to distinguish the difference between field names and macro variables. This audit will be done after this patch lands. * bytecode/BytecodeGeneratorification.cpp: (JSC::BytecodeGeneratorification::BytecodeGeneratorification): * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFromLLInt): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::finalizeLLIntInlineCaches): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow): (JSC::CodeBlock::getArrayProfile): (JSC::CodeBlock::notifyLexicalBindingShadowing): (JSC::CodeBlock::tryGetValueProfileForBytecodeOffset): (JSC::CodeBlock::arithProfileForPC): (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): * bytecode/CodeBlockInlines.h: (JSC::CodeBlock::forEachValueProfile): (JSC::CodeBlock::forEachArrayProfile): (JSC::CodeBlock::forEachArrayAllocationProfile): (JSC::CodeBlock::forEachObjectAllocationProfile): (JSC::CodeBlock::forEachLLIntCallLinkInfo): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache): * bytecode/PreciseJumpTargetsInlines.h: (JSC::jumpTargetForInstruction): (JSC::extractStoredJumpTargetsForInstruction): (JSC::updateStoredJumpTargetsForInstruction): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): * bytecode/UnlinkedCodeBlock.cpp: (JSC::dumpLineColumnEntry): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::fuseCompareAndJump): (JSC::BytecodeGenerator::fuseTestAndJmp): (JSC::BytecodeGenerator::emitEqualityOp): (JSC::BytecodeGenerator::endSwitch): (JSC::StructureForInContext::finalize): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleVarargsCall): (JSC::DFG::ByteCodeParser::parseGetById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::handlePutByVal): (JSC::DFG::ByteCodeParser::handlePutAccessorById): (JSC::DFG::ByteCodeParser::handlePutAccessorByVal): (JSC::DFG::ByteCodeParser::handleNewFunc): (JSC::DFG::ByteCodeParser::handleNewFuncExp): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareCatchOSREntry): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * generator/Argument.rb: * generator/Metadata.rb: * generator/Opcode.rb: * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emit_op_mod): (JSC::JIT::emit_op_negate): (JSC::JIT::emitBitBinaryOpFastPath): (JSC::JIT::emit_op_bitnot): (JSC::JIT::emitRightShiftFastPath): (JSC::JIT::emit_op_add): (JSC::JIT::emitMathICFast): (JSC::JIT::emitMathICSlow): (JSC::JIT::emit_op_div): (JSC::JIT::emit_op_mul): (JSC::JIT::emit_op_sub): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_mod): * jit/JITCall.cpp: (JSC::JIT::emitPutCallResult): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileTailCall): (JSC::JIT::compileOpCall): * jit/JITCall32_64.cpp: (JSC::JIT::emitPutCallResult): (JSC::JIT::emit_op_ret): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCall): * jit/JITInlines.h: (JSC::JIT::emitValueProfilingSiteIfProfiledOpcode): (JSC::JIT::emitValueProfilingSite): (JSC::JIT::copiedGetPutInfo): (JSC::JIT::copiedArithProfile): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_is_undefined_or_null): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emit_op_throw): (JSC::JIT::compileOpStrictEq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_debug): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_new_regexp): (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emitNewFuncExprCommon): (JSC::JIT::emit_op_new_array): (JSC::JIT::emit_op_new_array_with_size): (JSC::JIT::emit_op_has_structure_property): (JSC::JIT::emit_op_has_indexed_property): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emit_op_enumerator_structure_pname): (JSC::JIT::emit_op_enumerator_generic_pname): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): (JSC::JIT::emit_op_profile_control_flow): (JSC::JIT::emit_op_argument_count): (JSC::JIT::emit_op_get_rest_length): (JSC::JIT::emit_op_get_argument): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_is_undefined_or_null): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emit_op_neq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::compileOpStrictEq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_debug): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emit_op_has_structure_property): (JSC::JIT::emit_op_has_indexed_property): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emit_op_enumerator_structure_pname): (JSC::JIT::emit_op_enumerator_generic_pname): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/JITOperations.cpp: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::setupGetByIdPrototypeCache): (JSC::LLInt::getByVal): (JSC::LLInt::genericCall): (JSC::LLInt::varargsSetup): (JSC::LLInt::commonCallEval): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): (JSC::updateArithProfileForUnaryArithOp): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::tryCachePutToScopeGlobal): (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240229. rdar://problem/47458326 DFG: When inlining DataView set* intrinsics we need to set undefined as our result https://bugs.webkit.org/show_bug.cgi?id=193644 <rdar://problem/46209745> Reviewed by Yusuke Suzuki. JSTests: * stress/data-view-set-intrinsic-undefined-result-2.js: Added. (foo): * stress/data-view-set-intrinsic-undefined-result.js: Added. (foo): (bar): Source/JavaScriptCore: This patch also makes it so we fail fast when we make this mistake. I've made this mistake more than once. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240229 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-20 Saam Barati <sbarati@apple.com> DFG: When inlining DataView set* intrinsics we need to set undefined as our result https://bugs.webkit.org/show_bug.cgi?id=193644 <rdar://problem/46209745> Reviewed by Yusuke Suzuki. This patch also makes it so we fail fast when we make this mistake. I've made this mistake more than once. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240225. rdar://problem/47458257 Unreviewed, fix -Wint-in-bool-context warning https://bugs.webkit.org/show_bug.cgi?id=193483 <rdar://problem/47280522> * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::addCheckStructureForOriginalStringObjectUse): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240225 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-20 Michael Catanzaro <mcatanzaro@igalia.com> Unreviewed, fix -Wint-in-bool-context warning https://bugs.webkit.org/show_bug.cgi?id=193483 <rdar://problem/47280522> * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::addCheckStructureForOriginalStringObjectUse): 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240186. rdar://problem/47458146 Follow-up: Gigacages should start allocations from a slide <https://bugs.webkit.org/show_bug.cgi?id=193523> <rdar://problem/44958707> * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): Add UNUSED_PARAM(kind) to fix the build. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240186 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-18 David Kilzer <ddkilzer@apple.com> Follow-up: Gigacages should start allocations from a slide <https://bugs.webkit.org/show_bug.cgi?id=193523> <rdar://problem/44958707> * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): Add UNUSED_PARAM(kind) to fix the build. 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240175. rdar://problem/47458146 Gigacages should start allocations from a slide https://bugs.webkit.org/show_bug.cgi?id=193523 Reviewed by Mark Lam. Source/bmalloc: This patch makes it so that Gigacage Heaps slide the start of the cage by some random amount. We still ensure that there is always at least 4/2GB, on MacOS/iOS respectively, of VA space available for allocation. Also, this patch changes some macros into constants since macros are the devil. * bmalloc/Gigacage.cpp: (Gigacage::bmalloc::protectGigacageBasePtrs): (Gigacage::bmalloc::unprotectGigacageBasePtrs): (Gigacage::bmalloc::runwaySize): (Gigacage::ensureGigacage): (Gigacage::shouldBeEnabled): * bmalloc/Gigacage.h: (Gigacage::name): (Gigacage::gigacageSizeToMask): (Gigacage::size): (Gigacage::mask): (Gigacage::basePtr): (Gigacage::ensureGigacage): (Gigacage::wasEnabled): (Gigacage::isCaged): (Gigacage::isEnabled): (Gigacage::caged): (Gigacage::disableDisablingPrimitiveGigacageIfShouldBeEnabled): (Gigacage::canPrimitiveGigacageBeDisabled): (Gigacage::disablePrimitiveGigacage): (Gigacage::addPrimitiveDisableCallback): (Gigacage::removePrimitiveDisableCallback): * bmalloc/Heap.cpp: (bmalloc::Heap::Heap): * bmalloc/Sizes.h: (bmalloc::Sizes::maskSizeClass): (bmalloc::Sizes::maskObjectSize): (bmalloc::Sizes::logSizeClass): (bmalloc::Sizes::logObjectSize): (bmalloc::Sizes::sizeClass): (bmalloc::Sizes::objectSize): (bmalloc::Sizes::pageSize): Source/JavaScriptCore: This patch changes some macros into constants since macros are the devil. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * llint/LowLevelInterpreter64.asm: Source/WTF: This patch changes some macros into constants since macros are the devil. * wtf/Gigacage.cpp: * wtf/Gigacage.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240175 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-18 Keith Miller <keith_miller@apple.com> Gigacages should start allocations from a slide https://bugs.webkit.org/show_bug.cgi?id=193523 Reviewed by Mark Lam. This patch changes some macros into constants since macros are the devil. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * llint/LowLevelInterpreter64.asm: 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240114. rdar://problem/47458257 StringObjectUse should not be a structure check for the original string object structure https://bugs.webkit.org/show_bug.cgi?id=193483 <rdar://problem/47280522> Reviewed by Yusuke Suzuki. JSTests: * stress/cant-eliminate-string-object-structure-check-when-string-object-is-proven.js: Added. (foo): (a.valueOf.0): Source/JavaScriptCore: Prior to this patch, the use kind for StringObjectUse implied that we do a StructureCheck on the input operand for the *original* StringObject structure. This is generally not how we use UseKinds, so it's no surprise that this is buggy. A UseKind should map to a set of SpeculatedTypes, not an actual set of structures. This patch changes the meaning of StringObjectUse to mean an object where jsDynamicCast<StringObject*> would succeed. This patch also fixes a bug that was caused by the old and weird usage of the UseKind to mean StructureCheck. Consider a program like this: ``` S1 = Original StringObject structure S2 = Original StringObject structure with the field "f" added a: GetLocal() b: CheckStructure(@a, {S2}) c: ToString(StringObject:@a) ``` According to AI, in the above program, we would exit at @c, since StringObject:@a implies a structure check of {S1}, and the intersection of {S1} and {S2} is {}. So, we'd convert the program to be: ``` a: GetLocal() b: CheckStructure(@a, {S2}) c: Check(StringObject:@a) d: Unreachable ``` However, AI would set the proof status of the StringObject:@a edge to be proven, since the SpeculatedType for @a is SpecStringObject. This was incorrect of AI to do because the SpeculatedType itself didn't capture the full power of StringObjectUse. However, having a UseKind mean CheckStructure is weird precisely because what AI was doing is a natural fit to how we typically we think about UseKinds. So the above program would then incorrectly be converted to this, and we'd crash when reaching the Unreachable node: ``` a: GetLocal() b: CheckStructure(@a, {S2}) d: Unreachable ``` This patch makes it so that StringObjectUse just means that the object that filters through a StringObjectUse check must !!jsDynamicCast<StringObject*>. This is now in line with all other UseKinds. It also lets us simplify a bunch of other code that had weird checks for the StringObjectUse UseKind. This patch also makes it so that anywhere where we used to rely on StringObjectUse implying a structure check we actually emit an explicit CheckStructure node. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/ExitKind.cpp: (JSC::exitKindToString): * bytecode/ExitKind.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGCSEPhase.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGEdgeUsesStructure.h: Removed. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion): (JSC::DFG::FixupPhase::addCheckStructureForOriginalStringObjectUse): (JSC::DFG::FixupPhase::fixupToPrimitive): (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor): (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd): (JSC::DFG::FixupPhase::isStringObjectUse): Deleted. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::canOptimizeStringObjectAccess): * dfg/DFGMayExit.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOrStringValueOf): (JSC::DFG::SpeculativeJIT::speculateStringObject): (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure): Deleted. * dfg/DFGUseKind.h: (JSC::DFG::alreadyChecked): (JSC::DFG::usesStructure): Deleted. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf): (JSC::FTL::DFG::LowerDFGToB3::speculateStringObject): (JSC::FTL::DFG::LowerDFGToB3::speculateStringOrStringObject): (JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForCell): (JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForStructureID): Deleted. * runtime/JSType.cpp: (WTF::printInternal): * runtime/JSType.h: * runtime/StringObject.h: (JSC::StringObject::createStructure): * runtime/StringPrototype.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240114 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-17 Saam barati <sbarati@apple.com> StringObjectUse should not be a structure check for the original string object structure https://bugs.webkit.org/show_bug.cgi?id=193483 <rdar://problem/47280522> Reviewed by Yusuke Suzuki. Prior to this patch, the use kind for StringObjectUse implied that we do a StructureCheck on the input operand for the *original* StringObject structure. This is generally not how we use UseKinds, so it's no surprise that this is buggy. A UseKind should map to a set of SpeculatedTypes, not an actual set of structures. This patch changes the meaning of StringObjectUse to mean an object where jsDynamicCast<StringObject*> would succeed. This patch also fixes a bug that was caused by the old and weird usage of the UseKind to mean StructureCheck. Consider a program like this: ``` S1 = Original StringObject structure S2 = Original StringObject structure with the field "f" added a: GetLocal() b: CheckStructure(@a, {S2}) c: ToString(StringObject:@a) ``` According to AI, in the above program, we would exit at @c, since StringObject:@a implies a structure check of {S1}, and the intersection of {S1} and {S2} is {}. So, we'd convert the program to be: ``` a: GetLocal() b: CheckStructure(@a, {S2}) c: Check(StringObject:@a) d: Unreachable ``` However, AI would set the proof status of the StringObject:@a edge to be proven, since the SpeculatedType for @a is SpecStringObject. This was incorrect of AI to do because the SpeculatedType itself didn't capture the full power of StringObjectUse. However, having a UseKind mean CheckStructure is weird precisely because what AI was doing is a natural fit to how we typically we think about UseKinds. So the above program would then incorrectly be converted to this, and we'd crash when reaching the Unreachable node: ``` a: GetLocal() b: CheckStructure(@a, {S2}) d: Unreachable ``` This patch makes it so that StringObjectUse just means that the object that filters through a StringObjectUse check must !!jsDynamicCast<StringObject*>. This is now in line with all other UseKinds. It also lets us simplify a bunch of other code that had weird checks for the StringObjectUse UseKind. This patch also makes it so that anywhere where we used to rely on StringObjectUse implying a structure check we actually emit an explicit CheckStructure node. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/ExitKind.cpp: (JSC::exitKindToString): * bytecode/ExitKind.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGCSEPhase.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGEdgeUsesStructure.h: Removed. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion): (JSC::DFG::FixupPhase::addCheckStructureForOriginalStringObjectUse): (JSC::DFG::FixupPhase::fixupToPrimitive): (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor): (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd): (JSC::DFG::FixupPhase::isStringObjectUse): Deleted. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::canOptimizeStringObjectAccess): * dfg/DFGMayExit.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOrStringValueOf): (JSC::DFG::SpeculativeJIT::speculateStringObject): (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure): Deleted. * dfg/DFGUseKind.h: (JSC::DFG::alreadyChecked): (JSC::DFG::usesStructure): Deleted. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf): (JSC::FTL::DFG::LowerDFGToB3::speculateStringObject): (JSC::FTL::DFG::LowerDFGToB3::speculateStringOrStringObject): (JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForCell): (JSC::FTL::DFG::LowerDFGToB3::speculateStringObjectForStructureID): Deleted. * runtime/JSType.cpp: (WTF::printInternal): * runtime/JSType.h: * runtime/StringObject.h: (JSC::StringObject::createStructure): * runtime/StringPrototype.h: 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240040. rdar://problem/47458365 JSFunction::canUseAllocationProfile() should account for builtin functions with no own prototypes. https://bugs.webkit.org/show_bug.cgi?id=193423 <rdar://problem/46209355> Reviewed by Saam Barati. JSTests: * microbenchmarks/sinkable-new-object-with-builtin-constructor.js: Added. * stress/constructing-builtin-functions-with-getter-prototype-should-only-call-getter-once-per-new-1.js: Added. * stress/constructing-builtin-functions-with-getter-prototype-should-only-call-getter-once-per-new-2.js: Added. * stress/jsfunction-cannot-use-allocation-profile-with-builtin-functions-with-no-prototype.js: Added. Source/JavaScriptCore: JSFunction::canUseAllocationProfile() should return false for most builtins because the majority of them have no prototype property. The only exception to this is the few builtin functions that are explicitly used as constructors. For these builtin constructors, JSFunction::canUseAllocationProfile() should also return false if the prototype property is a getter or custom getter because getting the prototype would then be effectful. * dfg/DFGOperations.cpp: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSFunctionInlines.h: (JSC::JSFunction::canUseAllocationProfile): * runtime/PropertySlot.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240040 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-15 Mark Lam <mark.lam@apple.com> JSFunction::canUseAllocationProfile() should account for builtin functions with no own prototypes. https://bugs.webkit.org/show_bug.cgi?id=193423 <rdar://problem/46209355> Reviewed by Saam Barati. JSFunction::canUseAllocationProfile() should return false for most builtins because the majority of them have no prototype property. The only exception to this is the few builtin functions that are explicitly used as constructors. For these builtin constructors, JSFunction::canUseAllocationProfile() should also return false if the prototype property is a getter or custom getter because getting the prototype would then be effectful. * dfg/DFGOperations.cpp: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSFunctionInlines.h: (JSC::JSFunction::canUseAllocationProfile): * runtime/PropertySlot.h: 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240024. rdar://problem/47458299 [JSC] Use KnownStringUse for GetByVal(Array::String) since AI would offer wider type information and offer non-string type after removing Check(String) https://bugs.webkit.org/show_bug.cgi?id=193438 <rdar://problem/45581249> Reviewed by Saam Barati and Keith Miller. JSTests: Under the heavy load (like, compiling WebKit), AI in this code can broaden type information after the 1st run. Then, GetByVal(String) crashed. * stress/string-get-by-val-lowering.js: Added. (shouldBe): (test): * stress/type-for-get-by-val-can-be-widen-after-ai.js: Added. (Hello): (foo): Source/JavaScriptCore: GetByVal(Array::String) emits Check(String) before that. But AI can broaden type constraint in the second run. After the first run removes Check(String), it would happen that AI starts saying the type of 1st child is not String. To claim that it *is* a String type, we should use KnownStringUse here. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): StringCharAt and GetByVal(Array::String) share the underlying compiler code. We should change StringUse => KnownStringUse for StringCharAt too. And StringCharAt and StringCharCodeAt potentially have the same problem. This patch fixes it too. * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240024 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-15 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Use KnownStringUse for GetByVal(Array::String) since AI would offer wider type information and offer non-string type after removing Check(String) https://bugs.webkit.org/show_bug.cgi?id=193438 <rdar://problem/45581249> Reviewed by Saam Barati and Keith Miller. GetByVal(Array::String) emits Check(String) before that. But AI can broaden type constraint in the second run. After the first run removes Check(String), it would happen that AI starts saying the type of 1st child is not String. To claim that it *is* a String type, we should use KnownStringUse here. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): StringCharAt and GetByVal(Array::String) share the underlying compiler code. We should change StringUse => KnownStringUse for StringCharAt too. And StringCharAt and StringCharCodeAt potentially have the same problem. This patch fixes it too. * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt): 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r240023. rdar://problem/47458203 Try ripping out inferred types because it might be a performance improvement https://bugs.webkit.org/show_bug.cgi?id=190906 Reviewed by Yusuke Suzuki. This patch removes inferred types from JSC. Initial evidence shows that this might be around a ~1% speedup on Speedometer2 and JetStream2. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/Fits.h: * bytecode/PutByIdFlags.cpp: (WTF::printInternal): * bytecode/PutByIdFlags.h: * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeForStubInfo): (JSC::PutByIdStatus::computeFor): * bytecode/PutByIdVariant.cpp: (JSC::PutByIdVariant::operator=): (JSC::PutByIdVariant::replace): (JSC::PutByIdVariant::transition): (JSC::PutByIdVariant::setter): (JSC::PutByIdVariant::attemptToMerge): (JSC::PutByIdVariant::dumpInContext const): * bytecode/PutByIdVariant.h: (JSC::PutByIdVariant::requiredType const): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::isType const): Deleted. * dfg/DFGAbstractValue.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleGetByOffset): (JSC::DFG::ByteCodeParser::handlePutByOffset): (JSC::DFG::ByteCodeParser::load): (JSC::DFG::ByteCodeParser::store): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): (JSC::DFG::ConstantFoldingPhase::emitGetByOffset): (JSC::DFG::ConstantFoldingPhase::emitPutByOffset): * dfg/DFGDesiredInferredType.h: Removed. * dfg/DFGDesiredWatchpoints.cpp: (JSC::DFG::DesiredWatchpoints::reallyAdd): (JSC::DFG::DesiredWatchpoints::areStillValid const): (JSC::DFG::DesiredWatchpoints::dumpInContext const): (JSC::DFG::InferredTypeAdaptor::add): Deleted. * dfg/DFGDesiredWatchpoints.h: (JSC::DFG::DesiredWatchpoints::isWatched): (JSC::DFG::InferredTypeAdaptor::hasBeenInvalidated): Deleted. (JSC::DFG::InferredTypeAdaptor::dumpInContext): Deleted. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): (JSC::DFG::Graph::inferredValueForProperty): (JSC::DFG::Graph::inferredTypeFor): Deleted. * dfg/DFGGraph.h: (JSC::DFG::Graph::registerInferredType): Deleted. (JSC::DFG::Graph::inferredTypeForProperty): Deleted. * dfg/DFGInferredTypeCheck.cpp: Removed. * dfg/DFGInferredTypeCheck.h: Removed. * dfg/DFGNode.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset): (JSC::FTL::DFG::LowerDFGToB3::checkInferredType): Deleted. * generator/DSL.rb: * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizers): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::branchIfNotType): Deleted. * jit/AssemblyHelpers.h: * jit/Repatch.cpp: (JSC::tryCachePutByID): * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/InferredStructure.cpp: (JSC::InferredStructure::InferredStructure): Deleted. * runtime/InferredStructure.h: (): Deleted. * runtime/InferredStructureWatchpoint.cpp: (JSC::InferredStructureWatchpoint::fireInternal): Deleted. * runtime/InferredType.cpp: Removed. * runtime/InferredType.h: Removed. * runtime/InferredTypeInlines.h: Removed. * runtime/InferredTypeTable.cpp: Removed. * runtime/InferredTypeTable.h: Removed. * runtime/JSObjectInlines.h: (JSC::JSObject::putDirectInternal): * runtime/Structure.cpp: (JSC::Structure::materializePropertyTable): (JSC::Structure::addNewPropertyTransition): (JSC::Structure::removePropertyTransition): (JSC::Structure::willStoreValueSlow): (JSC::Structure::visitChildren): * runtime/Structure.h: (JSC::PropertyMapEntry::PropertyMapEntry): * runtime/StructureInlines.h: (JSC::Structure::get): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240023 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-15 Saam Barati <sbarati@apple.com> Try ripping out inferred types because it might be a performance improvement https://bugs.webkit.org/show_bug.cgi?id=190906 Reviewed by Yusuke Suzuki. This patch removes inferred types from JSC. Initial evidence shows that this might be around a ~1% speedup on Speedometer2 and JetStream2. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/AccessCase.cpp: (JSC::AccessCase::generateImpl): * bytecode/Fits.h: * bytecode/PutByIdFlags.cpp: (WTF::printInternal): * bytecode/PutByIdFlags.h: * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): (JSC::PutByIdStatus::computeForStubInfo): (JSC::PutByIdStatus::computeFor): * bytecode/PutByIdVariant.cpp: (JSC::PutByIdVariant::operator=): (JSC::PutByIdVariant::replace): (JSC::PutByIdVariant::transition): (JSC::PutByIdVariant::setter): (JSC::PutByIdVariant::attemptToMerge): (JSC::PutByIdVariant::dumpInContext const): * bytecode/PutByIdVariant.h: (JSC::PutByIdVariant::requiredType const): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::isType const): Deleted. * dfg/DFGAbstractValue.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleGetByOffset): (JSC::DFG::ByteCodeParser::handlePutByOffset): (JSC::DFG::ByteCodeParser::load): (JSC::DFG::ByteCodeParser::store): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): (JSC::DFG::ConstantFoldingPhase::emitGetByOffset): (JSC::DFG::ConstantFoldingPhase::emitPutByOffset): * dfg/DFGDesiredInferredType.h: Removed. * dfg/DFGDesiredWatchpoints.cpp: (JSC::DFG::DesiredWatchpoints::reallyAdd): (JSC::DFG::DesiredWatchpoints::areStillValid const): (JSC::DFG::DesiredWatchpoints::dumpInContext const): (JSC::DFG::InferredTypeAdaptor::add): Deleted. * dfg/DFGDesiredWatchpoints.h: (JSC::DFG::DesiredWatchpoints::isWatched): (JSC::DFG::InferredTypeAdaptor::hasBeenInvalidated): Deleted. (JSC::DFG::InferredTypeAdaptor::dumpInContext): Deleted. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): (JSC::DFG::Graph::inferredValueForProperty): (JSC::DFG::Graph::inferredTypeFor): Deleted. * dfg/DFGGraph.h: (JSC::DFG::Graph::registerInferredType): Deleted. (JSC::DFG::Graph::inferredTypeForProperty): Deleted. * dfg/DFGInferredTypeCheck.cpp: Removed. * dfg/DFGInferredTypeCheck.h: Removed. * dfg/DFGNode.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset): (JSC::FTL::DFG::LowerDFGToB3::checkInferredType): Deleted. * generator/DSL.rb: * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizers): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::branchIfNotType): Deleted. * jit/AssemblyHelpers.h: * jit/Repatch.cpp: (JSC::tryCachePutByID): * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/InferredStructure.cpp: (JSC::InferredStructure::InferredStructure): Deleted. * runtime/InferredStructure.h: (): Deleted. * runtime/InferredStructureWatchpoint.cpp: (JSC::InferredStructureWatchpoint::fireInternal): Deleted. * runtime/InferredType.cpp: Removed. * runtime/InferredType.h: Removed. * runtime/InferredTypeInlines.h: Removed. * runtime/InferredTypeTable.cpp: Removed. * runtime/InferredTypeTable.h: Removed. * runtime/JSObjectInlines.h: (JSC::JSObject::putDirectInternal): * runtime/Structure.cpp: (JSC::Structure::materializePropertyTable): (JSC::Structure::addNewPropertyTransition): (JSC::Structure::removePropertyTransition): (JSC::Structure::willStoreValueSlow): (JSC::Structure::visitChildren): * runtime/Structure.h: (JSC::PropertyMapEntry::PropertyMapEntry): * runtime/StructureInlines.h: (JSC::Structure::get): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2019-01-23 Alan Coon <alancoon@apple.com> Cherry-pick r239961. rdar://problem/47458424 [BigInt] Literal parsing is crashing when used inside a Object Literal https://bugs.webkit.org/show_bug.cgi?id=193404 Reviewed by Yusuke Suzuki. JSTests: * stress/big-int-literal-inside-literal-object.js: Added. Source/JavaScriptCore: Former implementation was relying into token.m_data.radix after the call of `next()` into Parser.cpp. This is not safe because next clobbers token.m_data.radix in some cases (e.g is CLOSEBRACE). Now we get radix value before calling `next()` into parser and store in a local variable. * parser/Parser.cpp: (JSC::Parser<LexerType>::parsePrimaryExpression): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239961 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-14 Caio Lima <ticaiolima@gmail.com> [BigInt] Literal parsing is crashing when used inside a Object Literal https://bugs.webkit.org/show_bug.cgi?id=193404 Reviewed by Yusuke Suzuki. Former implementation was relying into token.m_data.radix after the call of `next()` into Parser.cpp. This is not safe because next clobbers token.m_data.radix in some cases (e.g is CLOSEBRACE). Now we get radix value before calling `next()` into parser and store in a local variable. * parser/Parser.cpp: (JSC::Parser<LexerType>::parsePrimaryExpression): 2019-01-15 Alan Coon <alancoon@apple.com> Cherry-pick r239904. rdar://problem/4726030 Have prefers-color-scheme: light always match on macOS versions before Mojave. https://bugs.webkit.org/show_bug.cgi?id=191655 rdar://problem/46074680 Reviewed by Megan Gardner. Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. Source/WebCore: Tests: css-dark-mode/older-systems/prefers-color-scheme.html css-dark-mode/older-systems/supported-color-schemes-css.html css-dark-mode/older-systems/supported-color-schemes.html Use new HAVE(OS_DARK_MODE_SUPPORT) to make it easier to find code. Added HAVE(OS_DARK_MODE_SUPPORT) around more bits to make it work on older systems. * Configurations/FeatureDefines.xcconfig: * dom/Document.cpp: (WebCore::Document::useDarkAppearance const): * inspector/agents/InspectorPageAgent.cpp: (WebCore::InspectorPageAgent::enable): * page/Page.cpp: (WebCore::Page::setUseDarkAppearance): (WebCore::Page::useDarkAppearance const): (WebCore::Page::setUseDarkAppearanceOverride): * platform/mac/LocalDefaultSystemAppearance.h: (WebCore::LocalDefaultSystemAppearance::usingDarkAppearance const): * platform/mac/LocalDefaultSystemAppearance.mm: (WebCore::LocalDefaultSystemAppearance::LocalDefaultSystemAppearance): (WebCore::LocalDefaultSystemAppearance::~LocalDefaultSystemAppearance): * platform/mac/ScrollAnimatorMac.mm: * rendering/RenderThemeMac.mm: (-[WebCoreTextFieldCell _adjustedCoreUIDrawOptionsForDrawingBordersOnly:]): (-[WebListButtonCell drawWithFrame:inView:]): (WebCore::RenderThemeMac::platformInactiveSelectionBackgroundColor const): (WebCore::RenderThemeMac::platformInactiveSelectionForegroundColor const): (WebCore::RenderThemeMac::platformActiveListBoxSelectionBackgroundColor const): (WebCore::RenderThemeMac::platformInactiveListBoxSelectionBackgroundColor const): (WebCore::RenderThemeMac::platformInactiveListBoxSelectionForegroundColor const): (WebCore::RenderThemeMac::systemColor const): Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. Source/WebKit: * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. * UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::effectiveAppearanceIsDark): * UIProcess/RemoteLayerTree/mac/ScrollerMac.mm: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. * WebView/WebView.mm: (-[WebView _effectiveAppearanceIsDark]): Source/WTF: * wtf/Platform.h: Define HAVE_OS_DARK_MODE_SUPPORT on macOS 10.14. Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. * TestWebKitAPI/Tests/WebKit/mac/ForceLightAppearanceInBundle.mm: LayoutTests: * css-dark-mode/older-systems/prefers-color-scheme-expected.txt: Added. * css-dark-mode/older-systems/prefers-color-scheme.html: Added. * css-dark-mode/older-systems/supported-color-schemes-css-expected.txt: Added. * css-dark-mode/older-systems/supported-color-schemes-css.html: Added. * css-dark-mode/older-systems/supported-color-schemes-expected.txt: Added. * css-dark-mode/older-systems/supported-color-schemes.html: Added. * platform/mac/TestExpectations: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239904 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-12 Timothy Hatcher <timothy@apple.com> Have prefers-color-scheme: light always match on macOS versions before Mojave. https://bugs.webkit.org/show_bug.cgi?id=191655 rdar://problem/46074680 Reviewed by Megan Gardner. * Configurations/FeatureDefines.xcconfig: ENABLE_DARK_MODE_CSS_macosx for all OS versions. 2019-01-15 Alan Coon <alancoon@apple.com> Cherry-pick r239898. rdar://problem/47260206 Unreviewed, fix scope check assertions https://bugs.webkit.org/show_bug.cgi?id=193308 * bytecode/CodeBlock.cpp: (JSC::CodeBlock::notifyLexicalBindingShadowing): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::notifyLexicalBindingShadowing): * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239898 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-12 Yusuke Suzuki <yusukesuzuki@slowstart.org> Unreviewed, fix scope check assertions https://bugs.webkit.org/show_bug.cgi?id=193308 * bytecode/CodeBlock.cpp: (JSC::CodeBlock::notifyLexicalBindingShadowing): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::notifyLexicalBindingShadowing): * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): 2019-01-15 Alan Coon <alancoon@apple.com> Cherry-pick r239888. rdar://problem/47260286 Compile out Web API Statistics Collection https://bugs.webkit.org/show_bug.cgi?id=193370 <rdar://problem/45388584> Reviewed by Brent Fulgham. Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. Source/WebCore: No new tests. This patch disables functionality. The associated tests are skipped. These functions are now no-ops unless web API statistics is enabled. * Configurations/FeatureDefines.xcconfig: * loader/ResourceLoadObserver.cpp: (WebCore::ResourceLoadObserver::logFontLoad): (WebCore::ResourceLoadObserver::logCanvasRead): (WebCore::ResourceLoadObserver::logCanvasWriteOrMeasure): (WebCore::ResourceLoadObserver::logNavigatorAPIAccessed): (WebCore::ResourceLoadObserver::logScreenAPIAccessed): * loader/ResourceLoadStatistics.cpp: (WebCore::ResourceLoadStatistics::encode const): (WebCore::ResourceLoadStatistics::decode): (WebCore::ResourceLoadStatistics::toString const): (WebCore::ResourceLoadStatistics::merge): * loader/ResourceLoadStatistics.h: The associated struct members are skipped unless web API statistics is enabled. Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. Source/WebKit: * Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. * Shared/WebCoreArgumentCoders.cpp: (IPC::ArgumentCoder<ResourceLoadStatistics>::encode): Skipped encoding of web API statistics. (IPC::ArgumentCoder<ResourceLoadStatistics>::decode): Skipped decoding of web API statistics. Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. LayoutTests: * platform/ios-wk2/TestExpectations: http/tests/webAPIStatistics skipped. * platform/mac-wk2/TestExpectations: http/tests/webAPIStatistics skipped. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239888 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-11 John Wilander <wilander@apple.com> Compile out Web API Statistics Collection https://bugs.webkit.org/show_bug.cgi?id=193370 <rdar://problem/45388584> Reviewed by Brent Fulgham. * Configurations/FeatureDefines.xcconfig: Defined ENABLE_WEB_API_STATISTICS, off by default. 2019-01-15 Alan Coon <alancoon@apple.com> Cherry-pick r239882. rdar://problem/47260361 DFG combined liveness can be wrong for terminal basic blocks https://bugs.webkit.org/show_bug.cgi?id=193304 <rdar://problem/45268632> Reviewed by Yusuke Suzuki. JSTests: * stress/dfg-combined-liveness-consider-terminal-blocks-bytecode-liveness.js: Added. Source/JavaScriptCore: If a block doesn't have any successors, it can't rely on the typical backwards liveness propagation that CombinedLiveness was doing. The phase first got what was live in bytecode and IR at the heads of each block. Then for each block, it made the live at tail the union of the live at head for each successor. For a terminal block though, this could be wrong. We could end up saying nothing is live even though many things may be live in bytecode. We must account for what's bytecode live at the end of the block. Consider a block that ends with: ``` ForceOSRExit Unreachable ``` Things may definitely be live in bytecode at the tail. However, we'll report nothing as being alive. This probably subtly breaks many analyses, but we have a test case of it breaking the interference analysis that the ArgumentsEliminationPhase performs. * dfg/DFGBasicBlock.h: (JSC::DFG::BasicBlock::last const): * dfg/DFGCombinedLiveness.cpp: (JSC::DFG::addBytecodeLiveness): (JSC::DFG::liveNodesAtHead): (JSC::DFG::CombinedLiveness::CombinedLiveness): * dfg/DFGCombinedLiveness.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239882 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-11 Saam barati <sbarati@apple.com> DFG combined liveness can be wrong for terminal basic blocks https://bugs.webkit.org/show_bug.cgi?id=193304 <rdar://problem/45268632> Reviewed by Yusuke Suzuki. If a block doesn't have any successors, it can't rely on the typical backwards liveness propagation that CombinedLiveness was doing. The phase first got what was live in bytecode and IR at the heads of each block. Then for each block, it made the live at tail the union of the live at head for each successor. For a terminal block though, this could be wrong. We could end up saying nothing is live even though many things may be live in bytecode. We must account for what's bytecode live at the end of the block. Consider a block that ends with: ``` ForceOSRExit Unreachable ``` Things may definitely be live in bytecode at the tail. However, we'll report nothing as being alive. This probably subtly breaks many analyses, but we have a test case of it breaking the interference analysis that the ArgumentsEliminationPhase performs. * dfg/DFGBasicBlock.h: (JSC::DFG::BasicBlock::last const): * dfg/DFGCombinedLiveness.cpp: (JSC::DFG::addBytecodeLiveness): (JSC::DFG::liveNodesAtHead): (JSC::DFG::CombinedLiveness::CombinedLiveness): * dfg/DFGCombinedLiveness.h: 2019-01-15 Alan Coon <alancoon@apple.com> Cherry-pick r239879. rdar://problem/47260206 [JSC] Global lexical bindings can shadow global variables if it is `configurable = true` https://bugs.webkit.org/show_bug.cgi?id=193308 <rdar://problem/45546542> Reviewed by Saam Barati. JSTests: * stress/const-lexical-binding-shadow-existing-global-property-ftl.js: Added. (shouldThrow): (shouldBe): (foo): (get shouldThrow): * stress/const-lexical-binding-shadow-existing-global-property-tdz-ftl.js: Added. (shouldThrow): (shouldBe): (foo): (get shouldBe): (get shouldThrow): (get return): * stress/const-lexical-binding-shadow-existing-global-property-tdz.js: Added. (shouldThrow): (shouldBe): (foo): (get shouldBe): (get shouldThrow): * stress/const-lexical-binding-shadow-existing-global-property.js: Added. (shouldThrow): (shouldBe): (foo): * stress/const-lexical-binding-shadowing-global-properties-and-eval-injection.js: Added. (shouldThrow): (shouldBe): (foo): * stress/global-add-function-should-not-be-shadowed-by-lexical-bindings.js: Added. (shouldThrow): * stress/global-static-variables-should-not-be-shadowed-by-lexical-bindings.js: Added. (shouldThrow): * stress/let-lexical-binding-shadow-existing-global-property-ftl.js: Added. (shouldThrow): (shouldBe): (foo): * stress/let-lexical-binding-shadow-existing-global-property-tdz-ftl.js: Added. (shouldThrow): (shouldBe): (foo): (get shouldBe): (get shouldThrow): (get return): * stress/let-lexical-binding-shadow-existing-global-property-tdz.js: Added. (shouldThrow): (shouldBe): (foo): (get shouldBe): (get shouldThrow): * stress/let-lexical-binding-shadow-existing-global-property.js: Added. (shouldThrow): (shouldBe): (foo): * stress/let-lexical-binding-shadowing-global-properties-and-eval-injection.js: Added. (shouldThrow): (shouldBe): (foo): Source/JavaScriptCore: Previously, we assumed that lexical bindings in JSGlobalLexicalEnvironment cannot shadow existing global properties. However, it is wrong. According to the spec, we can shadow global properties if a property's attribute is configurable = true. For example, we execute two scripts. script1.js bar = 42; function load() { return bar; } print(bar); // 42 print(load()); // 42 script2.js let bar = 0; // This lexical binding can shadow the global.bar defined in script1.js print(bar); // 0 print(load()); // 0 In JSC, we cache GlobalProperty resolve type and its associated information in op_resolve_type, op_get_from_scope, and op_put_to_scope. They attempt to load a property from JSGlobalObject directly. However, once the newly added lexical binding starts shadowing this, our existing instructions become invalid since they do not respect JSGlobalLexicalEnvironment. In this patch, we fix this issue by introducing the following mechanisms. 1. We have a HashMap<property name, watchpoint set> in JSGlobalObject. DFG and FTL create a watchpoint set with the property name if the generated code depends on GlobalProperty condition of op_resolve_scope etc. These watchpoint will be fired when the shadowing happens, so that our generated DFG and FTL code will be invalidated if it depends on the condition which is no longer valid. 2. When we detect shadowing, we iterate all the live CodeBlocks which globalObject is the target one. And we rewrite instructions in them from GlobalProperty to GlobalLexicalVar (or Dynamic precisely). So, the subsequent LLInt code just works well. "Dynamic" conversion happens when your op_put_to_scope attempts to put a value onto a const lexical binding. This fails and it should throw a type error. 3. GlobalProperty scope operations in Baseline JIT start checking ResolveType in metadata, and emit code for GlobalProperty and GlobalLexicalVar. Once the rewrite happens, baseline JIT continues working because it checks the rewritten metadata's ResolveType. We use this mechanism (which is similar to haveABadTime() thing) because, 1. Shadowing should be super rare. Before r214145, we made these cases as SytaxError. Thus, before r214145, this type of code cannot be executed in WebKit. And the number of the live CodeBlocks for the given JSGlobalObject should be small. This supports introducing rather simple (but not so efficient) mechanism instead of the complicated one. 2. Rewriting instructions immediately forces GlobalProperty => GlobalLexicalVar / Dynamic conversion in all the possible CodeBlock. This allows us to avoid compilation failure loop in DFG and FTL: DFG and FTL codes are invalidated by the watchpoint, but we may attempt to compile the code with the invalidated watchpoint and GlobalProperty status if we do not rewrite it. One possible other implementation is having and checking a counter in instruction, and every time we introduce a new shadow binding, bump the counter. And eventually executed instruction will go to the slow path and rewrite itself. However, this way leaves the not-executed-again-yet instructions as is, and DFG and FTL repeatedly fail to compile if we just watch the invalidated watchpoint for that. Rewriting all the existing GlobalProperty immediately avoids this situation easily. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::notifyLexicalBindingShadowing): * bytecode/CodeBlock.h: (JSC::CodeBlock::scriptMode const): * bytecode/Watchpoint.h: (JSC::WatchpointSet::create): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGDesiredGlobalProperties.cpp: Added. (JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread): (JSC::DFG::DesiredGlobalProperties::reallyAdd): * dfg/DFGDesiredGlobalProperties.h: Added. (JSC::DFG::DesiredGlobalProperties::addLazily): We need this DesiredGlobalProperties mechanism since we do not want to ref() the UniquedStringImpl in DFG and FTL thread. We keep JSGlobalObject* and identifierNumber, and materialize WatchpointSets for each JSGlobalObject's property referenced from DFG and FTL and inject CodeBlock jettison watchpoints in the main thread. * dfg/DFGDesiredGlobalProperty.h: Added. (JSC::DFG::DesiredGlobalProperty::DesiredGlobalProperty): (JSC::DFG::DesiredGlobalProperty::globalObject const): (JSC::DFG::DesiredGlobalProperty::identifierNumber const): (JSC::DFG::DesiredGlobalProperty::operator== const): (JSC::DFG::DesiredGlobalProperty::operator!= const): (JSC::DFG::DesiredGlobalProperty::isHashTableDeletedValue const): (JSC::DFG::DesiredGlobalProperty::hash const): (JSC::DFG::DesiredGlobalProperty::dumpInContext const): (JSC::DFG::DesiredGlobalProperty::dump const): (JSC::DFG::DesiredGlobalPropertyHash::hash): (JSC::DFG::DesiredGlobalPropertyHash::equal): * dfg/DFGGraph.h: (JSC::DFG::Graph::globalProperties): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::reallyAdd): (JSC::DFG::Plan::isStillValidOnMainThread): (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): (JSC::DFG::Plan::cancel): * dfg/DFGPlan.h: (JSC::DFG::Plan::globalProperties): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addStaticGlobals): (JSC::JSGlobalObject::notifyLexicalBindingShadowing): (JSC::JSGlobalObject::getReferencedPropertyWatchpointSet): (JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet): * runtime/JSGlobalObject.h: * runtime/ProgramExecutable.cpp: (JSC::hasRestrictedGlobalProperty): (JSC::ProgramExecutable::initializeGlobalProperties): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239879 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-11 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Global lexical bindings can shadow global variables if it is `configurable = true` https://bugs.webkit.org/show_bug.cgi?id=193308 <rdar://problem/45546542> Reviewed by Saam Barati. Previously, we assumed that lexical bindings in JSGlobalLexicalEnvironment cannot shadow existing global properties. However, it is wrong. According to the spec, we can shadow global properties if a property's attribute is configurable = true. For example, we execute two scripts. script1.js bar = 42; function load() { return bar; } print(bar); // 42 print(load()); // 42 script2.js let bar = 0; // This lexical binding can shadow the global.bar defined in script1.js print(bar); // 0 print(load()); // 0 In JSC, we cache GlobalProperty resolve type and its associated information in op_resolve_type, op_get_from_scope, and op_put_to_scope. They attempt to load a property from JSGlobalObject directly. However, once the newly added lexical binding starts shadowing this, our existing instructions become invalid since they do not respect JSGlobalLexicalEnvironment. In this patch, we fix this issue by introducing the following mechanisms. 1. We have a HashMap<property name, watchpoint set> in JSGlobalObject. DFG and FTL create a watchpoint set with the property name if the generated code depends on GlobalProperty condition of op_resolve_scope etc. These watchpoint will be fired when the shadowing happens, so that our generated DFG and FTL code will be invalidated if it depends on the condition which is no longer valid. 2. When we detect shadowing, we iterate all the live CodeBlocks which globalObject is the target one. And we rewrite instructions in them from GlobalProperty to GlobalLexicalVar (or Dynamic precisely). So, the subsequent LLInt code just works well. "Dynamic" conversion happens when your op_put_to_scope attempts to put a value onto a const lexical binding. This fails and it should throw a type error. 3. GlobalProperty scope operations in Baseline JIT start checking ResolveType in metadata, and emit code for GlobalProperty and GlobalLexicalVar. Once the rewrite happens, baseline JIT continues working because it checks the rewritten metadata's ResolveType. We use this mechanism (which is similar to haveABadTime() thing) because, 1. Shadowing should be super rare. Before r214145, we made these cases as SytaxError. Thus, before r214145, this type of code cannot be executed in WebKit. And the number of the live CodeBlocks for the given JSGlobalObject should be small. This supports introducing rather simple (but not so efficient) mechanism instead of the complicated one. 2. Rewriting instructions immediately forces GlobalProperty => GlobalLexicalVar / Dynamic conversion in all the possible CodeBlock. This allows us to avoid compilation failure loop in DFG and FTL: DFG and FTL codes are invalidated by the watchpoint, but we may attempt to compile the code with the invalidated watchpoint and GlobalProperty status if we do not rewrite it. One possible other implementation is having and checking a counter in instruction, and every time we introduce a new shadow binding, bump the counter. And eventually executed instruction will go to the slow path and rewrite itself. However, this way leaves the not-executed-again-yet instructions as is, and DFG and FTL repeatedly fail to compile if we just watch the invalidated watchpoint for that. Rewriting all the existing GlobalProperty immediately avoids this situation easily. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::notifyLexicalBindingShadowing): * bytecode/CodeBlock.h: (JSC::CodeBlock::scriptMode const): * bytecode/Watchpoint.h: (JSC::WatchpointSet::create): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGDesiredGlobalProperties.cpp: Added. (JSC::DFG::DesiredGlobalProperties::isStillValidOnMainThread): (JSC::DFG::DesiredGlobalProperties::reallyAdd): * dfg/DFGDesiredGlobalProperties.h: Added. (JSC::DFG::DesiredGlobalProperties::addLazily): We need this DesiredGlobalProperties mechanism since we do not want to ref() the UniquedStringImpl in DFG and FTL thread. We keep JSGlobalObject* and identifierNumber, and materialize WatchpointSets for each JSGlobalObject's property referenced from DFG and FTL and inject CodeBlock jettison watchpoints in the main thread. * dfg/DFGDesiredGlobalProperty.h: Added. (JSC::DFG::DesiredGlobalProperty::DesiredGlobalProperty): (JSC::DFG::DesiredGlobalProperty::globalObject const): (JSC::DFG::DesiredGlobalProperty::identifierNumber const): (JSC::DFG::DesiredGlobalProperty::operator== const): (JSC::DFG::DesiredGlobalProperty::operator!= const): (JSC::DFG::DesiredGlobalProperty::isHashTableDeletedValue const): (JSC::DFG::DesiredGlobalProperty::hash const): (JSC::DFG::DesiredGlobalProperty::dumpInContext const): (JSC::DFG::DesiredGlobalProperty::dump const): (JSC::DFG::DesiredGlobalPropertyHash::hash): (JSC::DFG::DesiredGlobalPropertyHash::equal): * dfg/DFGGraph.h: (JSC::DFG::Graph::globalProperties): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::reallyAdd): (JSC::DFG::Plan::isStillValidOnMainThread): (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): (JSC::DFG::Plan::cancel): * dfg/DFGPlan.h: (JSC::DFG::Plan::globalProperties): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addStaticGlobals): (JSC::JSGlobalObject::notifyLexicalBindingShadowing): (JSC::JSGlobalObject::getReferencedPropertyWatchpointSet): (JSC::JSGlobalObject::ensureReferencedPropertyWatchpointSet): * runtime/JSGlobalObject.h: * runtime/ProgramExecutable.cpp: (JSC::hasRestrictedGlobalProperty): (JSC::ProgramExecutable::initializeGlobalProperties): 2019-01-15 Alan Coon <alancoon@apple.com> Cherry-pick r239787. rdar://problem/47260350 Gigacage disabling checks should handle the GIGACAGE_ALLOCATION_CAN_FAIL case properly. https://bugs.webkit.org/show_bug.cgi?id=193292 <rdar://problem/46485450> Reviewed by Yusuke Suzuki. Source/bmalloc: Previously, when GIGACAGE_ALLOCATION_CAN_FAIL is true, we allow the Gigacage to be disabled if we fail to allocate memory for it. However, Gigacage::primitiveGigacageDisabled() still always assumes that the Gigacage is always enabled after ensureGigacage() is called. This patch updates Gigacage::primitiveGigacageDisabled() to allow the Gigacage to already be disabled if GIGACAGE_ALLOCATION_CAN_FAIL is true and wasEnabled() is false. In this patch, we also put the wasEnabled flag in the 0th slot of the g_gigacageBasePtrs buffer to ensure that it is also protected against writes just like the Gigacage base pointers. To achieve this, we do the following: 1. Added a reservedForFlags field in struct BasePtrs. 2. Added a ReservedForFlagsAndNotABasePtr Gigacage::Kind. 3. Added assertions to ensure that the BasePtrs::primitive is at the offset matching the offset computed from Gigacage::Primitive. Ditto for BasePtrs::jsValue and Gigacage::JSValue. 4. Added assertions to ensure that Gigacage::ReservedForFlagsAndNotABasePtr is not used for fetching a Gigacage base pointer. 5. Added RELEASE_BASSERT_NOT_REACHED() to implement such assertions in bmalloc. No test added because this issue requires Gigacage allocation to fail in order to manifest. I've tested it manually by modifying the code locally to force an allocation failure. * bmalloc/BAssert.h: * bmalloc/Gigacage.cpp: (Gigacage::ensureGigacage): (Gigacage::primitiveGigacageDisabled): * bmalloc/Gigacage.h: (Gigacage::wasEnabled): (Gigacage::setWasEnabled): (Gigacage::name): (Gigacage::basePtr): (Gigacage::size): * bmalloc/HeapKind.h: (bmalloc::heapKind): Source/JavaScriptCore: * runtime/VM.h: (JSC::VM::gigacageAuxiliarySpace): Source/WTF: Update the USE_SYSTEM_MALLOC version of Gigacage.h to match the bmalloc version. * wtf/Gigacage.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239787 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-09 Mark Lam <mark.lam@apple.com> Gigacage disabling checks should handle the GIGACAGE_ALLOCATION_CAN_FAIL case properly. https://bugs.webkit.org/show_bug.cgi?id=193292 <rdar://problem/46485450> Reviewed by Yusuke Suzuki. * runtime/VM.h: (JSC::VM::gigacageAuxiliarySpace): 2019-01-09 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r239755. rdar://problem/47158650 Leak of VectorBufferBase.m_buffer (16-64 bytes) under JSC::CompactVariableEnvironment in com.apple.WebKit.WebContent running layout tests <https://webkit.org/b/193264> <rdar://problem/46651026> Reviewed by Yusuke Suzuki. * parser/VariableEnvironment.cpp: (JSC::CompactVariableMap::Handle::~Handle): Call delete on m_environment instead of fastFree() to make sure the destructors for the Vector instance variables are run. This fixes the leaks because calling fastFree() would only free the CompactVariableEnvironment object, but not the heap-based buffers allocated for the Vector instance variables. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239755 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-08 David Kilzer <ddkilzer@apple.com> Leak of VectorBufferBase.m_buffer (16-64 bytes) under JSC::CompactVariableEnvironment in com.apple.WebKit.WebContent running layout tests <https://webkit.org/b/193264> <rdar://problem/46651026> Reviewed by Yusuke Suzuki. * parser/VariableEnvironment.cpp: (JSC::CompactVariableMap::Handle::~Handle): Call delete on m_environment instead of fastFree() to make sure the destructors for the Vector instance variables are run. This fixes the leaks because calling fastFree() would only free the CompactVariableEnvironment object, but not the heap-based buffers allocated for the Vector instance variables. 2019-01-09 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r239731. rdar://problem/47158715 LLInt put_by_id uses the wrong load instruction for loading flags from the metadata https://bugs.webkit.org/show_bug.cgi?id=193221 Reviewed by Mark Lam. JSTests: * stress/put-by-id-flags.js: Added. (f): (g): (numberOfDFGCompiles): Source/JavaScriptCore: The flags are only 4 bytes, but were loaded with loadp. It used to work, since the flags were followed by a 4-byte padding, but it broke after the struct was compacted in r239626. * llint/LowLevelInterpreter64.asm: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239731 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-01-08 Tadeu Zagallo <tzagallo@apple.com> LLInt put_by_id uses the wrong load instruction for loading flags from the metadata https://bugs.webkit.org/show_bug.cgi?id=193221 Reviewed by Mark Lam. The flags are only 4 bytes, but were loaded with loadp. It used to work, since the flags were followed by a 4-byte padding, but it broke after the struct was compacted in r239626. * llint/LowLevelInterpreter64.asm: 2019-01-09 Alan Coon <alancoon@apple.com> Apply patch. rdar://problem/47158817 2019-01-09 Keith Miller <keith_miller@apple.com> Mark kJSTypeSymbol as available in mid year update of the OS. * API/JSValueRef.h: 2019-01-04 Tadeu Zagallo <tzagallo@apple.com> Baseline version of get_by_id may corrupt metadata https://bugs.webkit.org/show_bug.cgi?id=193085 <rdar://problem/23453006> Reviewed by Saam Barati. The Baseline version of get_by_id unconditionally calls `emitArrayProfilingSiteForBytecodeIndexWithCell` if the property is `length`. However, since the bytecode rewrite, get_by_id only has an ArrayProfile entry in the metadata if its mode is `GetByIdMode::ArrayLength`. That might result in one of two bad things: 1) get_by_id's mode is not ArrayLength, and a duplicate, out-of-line ArrayProfile entry will be created by `CodeBlock::getOrAddArrayProfile`. 2) get_by_id's mode *is* ArrayLength and we generate the array profiling code pointing to the ArrayProfile that lives in the metadata table. This works fine as long as get_by_id does not change modes. If that happens, the JIT code will write into the metadata table, overwriting the 'GetByIdModeMetadata` for another mode. Add a check to the Baseline version of get_by_id so that we only do the ArrayProfiling if the get_by_id's mode is ArrayLength * bytecode/BytecodeList.rb: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::getArrayProfile): (JSC::CodeBlock::addArrayProfile): Deleted. (JSC::CodeBlock::getOrAddArrayProfile): Deleted. * bytecode/CodeBlock.h: (JSC::CodeBlock::numberOfArrayProfiles const): Deleted. (JSC::CodeBlock::arrayProfiles): Deleted. * bytecode/CodeBlockInlines.h: (JSC::CodeBlock::forEachArrayProfile): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::emitArrayProfilingSiteForBytecodeIndexWithCell): Deleted. * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_id): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_id): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): 2019-01-02 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Optimize Object.prototype.toString https://bugs.webkit.org/show_bug.cgi?id=193031 Reviewed by Saam Barati. Object.prototype.toString is frequently used for type checking. It is called many times in wtb-lebab.js. This patch optimizes Object.prototype.toString by the following two optimizations. 1. We should emit code looking up cached to string in DFG and FTL. toString's result is cached in the Structure. We emit a fast path code in DFG and FTL to lookup this cache. 2. We should not create objects for primitive values in major cases. When Object.prototype.toString(primitive) is called, this primitive is converted to an object by calling ToObject. But if the result is appropriately cached in the Structure, we should get it in the fast path without creating this object. When converting primitives to objects, Structures used in these newly created objects are known (Structure for StringObject etc.). So we can first query the cached string before actually converting primitives to objects. This patch improves wtb-lebab.js by roughly 2%. before: lebab: 8.90 runs/s after : lebab: 9.09 runs/s * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupObjectToString): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileObjectToString): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileObjectToString): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/ObjectPrototype.cpp: (JSC::ObjectPrototype::finishCreation): (JSC::objectProtoFuncToString): * runtime/ObjectPrototype.h: * runtime/ObjectPrototypeInlines.h: Added. (JSC::structureForPrimitiveValue): (JSC::objectToString): * runtime/StructureRareData.h: 2019-01-03 Michael Saboff <msaboff@apple.com> DFG IntegerRangeOptimization phase exceeding loop limit shouldn't ASSERT https://bugs.webkit.org/show_bug.cgi?id=193094 Reviewed by Saam Barati. Removed this debug only ASSERT as one can construct test cases that will exceed the giveUpThreshold amount. This can be done with a large switch statement with at least one const or variable case clause. Such code bytecompiles to compare / jtrue sequences. Increasing the giveUpThreshold count doesn't help with the eventual code generated as B3 has optimizations to coalesce compare / branch code sequences even when we don't run the IntegerRangeOptimization phase. * dfg/DFGIntegerRangeOptimizationPhase.cpp: 2019-01-02 Devin Rousso <webkit@devinrousso.com> Web Inspector: Implement `queryObjects` Command Line API https://bugs.webkit.org/show_bug.cgi?id=176766 <rdar://problem/34890689> Reviewed by Joseph Pecoraro. Introduces a new Command Line function called `queryObjects` that will return an array of object that have the given constructor/prototype argument in their prototype chain. - `queryObjects(Promise)` will return an array of all Promises. - `queryObjects(Foo)` will return all objects created with the constructor `Foo`. Currently, an error is thrown if the first argument is one of the following: - Object - Object.prototype - Function - Function.prototype - Array - Array.prototype - Map - Map.prototype - Set - Set.prototype - Proxy The reason for this is that we don't want to expose any internal/builtin objects, as some of them are highly sensitive and undefined behaviour can occur if they are modified. * inspector/JSInjectedScriptHost.h: * inspector/JSInjectedScriptHost.cpp: (Inspector::checkForbiddenPrototype): Added. (Inspector::JSInjectedScriptHost::queryObjects): Added. Does a GC and then iterates over all live JSCell in the heap to find these objects. * inspector/JSInjectedScriptHostPrototype.cpp: (Inspector::JSInjectedScriptHostPrototype::finishCreation): (Inspector::jsInjectedScriptHostPrototypeFunctionQueryObjects): Added. * inspector/InjectedScriptSource.js: (queryObjects): Added. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::promisePrototype): Added. 2018-12-31 Keith Miller <keith_miller@apple.com> SourceProviders should use an actual URL instead of a string https://bugs.webkit.org/show_bug.cgi?id=192734 Reviewed by Yusuke Suzuki. This will be useful for the Module loader API in the future where by default it will use the relative path from the referring module to resolve dependencies. I didn't change the JSC shell's urls to be absolute paths as it caused problems with the stack traces in our Chakra tests. Since the absolute paths included system directories the diff would appear incorrect. See: https://bugs.webkit.org/show_bug.cgi?id=193077 * API/JSBase.cpp: (JSEvaluateScript): (JSCheckScriptSyntax): * API/JSScriptRef.cpp: (OpaqueJSScript::create): (OpaqueJSScript::OpaqueJSScript): * API/glib/JSCContext.cpp: (jsc_context_check_syntax): * jsc.cpp: (jscSource): (GlobalObject::moduleLoaderFetch): (functionCheckModuleSyntax): (runWithOptions): * parser/SourceCode.h: (JSC::makeSource): * parser/SourceProvider.cpp: (JSC::SourceProvider::SourceProvider): * parser/SourceProvider.h: (JSC::SourceProvider::url const): (JSC::StringSourceProvider::create): (JSC::StringSourceProvider::StringSourceProvider): (JSC::WebAssemblySourceProvider::create): (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider): * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * tools/CodeProfile.h: (JSC::CodeProfile::CodeProfile): * tools/FunctionOverrides.cpp: (JSC::initializeOverrideInfo): 2019-01-01 Jeff Miller <jeffm@apple.com> Update user-visible copyright strings to include 2019 https://bugs.webkit.org/show_bug.cgi?id=192811 Reviewed by Mark Lam. * Info.plist: 2018-12-30 Ross Kirsling <ross.kirsling@sony.com> [JSC] Identifier validity should be based on ID_Start / ID_Continue properties https://bugs.webkit.org/show_bug.cgi?id=193050 Reviewed by Yusuke Suzuki. From https://tc39.github.io/ecma262/#sec-names-and-keywords: UnicodeIDStart:: any Unicode code point with the Unicode property "ID_Start" UnicodeIDContinue:: any Unicode code point with the Unicode property "ID_Continue" * parser/Lexer.cpp: (JSC::Lexer<T>::Lexer): (JSC::isNonLatin1IdentStart): (JSC::isNonLatin1IdentPart): (JSC::isIdentPart): (JSC::Lexer<T>::lex): Ensure identifier start / part is based on ID_Start / ID_Continue. (Implies a special case for U+00B7, which is Latin-1 but Other_ID_Continue.) 2018-12-28 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Remove one indirection in JSObject::toStringName https://bugs.webkit.org/show_bug.cgi?id=193037 Reviewed by Keith Miller. We should not have additional one-level indirection in JSObject::toStringName. JSObject::toStringName is dispatched through methodTable. Even after that, we need to call JSObject::className function through methodTable again. But className function is rarely defined. So instead of introducing this indirection here, classes having className functions should have toStringName function too. This can remove one-level indirection in toStringName in major cases. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject<Parent>::toStringName): * debugger/DebuggerScope.cpp: (JSC::DebuggerScope::toStringName): * debugger/DebuggerScope.h: * runtime/JSObject.cpp: (JSC::JSObject::toStringName): 2018-12-27 Alex Christensen <achristensen@webkit.org> Resurrect Mac CMake build https://bugs.webkit.org/show_bug.cgi?id=192658 Reviewed by Yusuke Suzuki. * PlatformMac.cmake: 2018-12-25 Fujii Hironori <Hironori.Fujii@sony.com> [JSC][Win][Clang] warning: implicit conversion from 'size_t' (aka 'unsigned long long') to 'int32_t' (aka 'int') changes value from 18446744073709551552 to -64 [-Wconstant-conversion] https://bugs.webkit.org/show_bug.cgi?id=193035 Reviewed by Yusuke Suzuki. Clang-cl reports a compilation warning for implicit conversion from -64 size_t to int. Replaced '-maxFrameExtentForSlowPathCall' with '-static_cast<int32_t>(maxFrameExtentForSlowPathCall)'. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/ThunkGenerators.cpp: (JSC::slowPathFor): 2018-12-13 Yusuke Suzuki <yusukesuzuki@slowstart.org> [BigInt] Support BigInt in JSON.stringify https://bugs.webkit.org/show_bug.cgi?id=192624 Reviewed by Saam Barati. This patch adds BigInt support to JSON.stringify, specified in [1]. [1]: https://tc39.github.io/proposal-bigint/#sec-serializejsonproperty * runtime/JSONObject.cpp: (JSC::unwrapBoxedPrimitive): (JSC::Stringifier::toJSON): (JSC::Stringifier::toJSONImpl): (JSC::Stringifier::appendStringifiedValue): 2018-12-21 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Use appendUnbarriered for cached own keys https://bugs.webkit.org/show_bug.cgi?id=192981 Reviewed by Saam Barati. m_cachedOwnKeys would be changed to sentinel after checking `thisObject->m_cachedOwnKeys.unvalidatedGet() != cachedOwnKeysSentinel()` and before executing `visitor.append(thisObject->m_cachedOwnKeys)`. We never do this now, but might in the future. To make the code safe, we should use appendUnbarriered to mark non sentinel cell. * runtime/StructureRareData.cpp: (JSC::StructureRareData::visitChildren): 2018-12-20 Yusuke Suzuki <yusukesuzuki@slowstart.org> Use Ref<> as much as possible https://bugs.webkit.org/show_bug.cgi?id=192808 Reviewed by Alex Christensen. * API/JSTypedArray.cpp: (JSObjectMakeTypedArrayWithBytesNoCopy): * API/JSWeakObjectMapRefPrivate.cpp: * bytecompiler/StaticPropertyAnalyzer.h: (JSC::StaticPropertyAnalyzer::newObject): * dfg/DFGDesiredWatchpoints.cpp: (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add): * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::sweeper): * heap/Heap.h: * heap/IsoCellSet.cpp: (JSC::IsoCellSet::parallelNotEmptyMarkedBlockSource): * heap/IsoCellSet.h: * heap/IsoCellSetInlines.h: (JSC::IsoCellSet::forEachMarkedCellInParallel): * heap/Subspace.cpp: (JSC::Subspace::parallelDirectorySource): (JSC::Subspace::parallelNotEmptyMarkedBlockSource): * heap/Subspace.h: * heap/SubspaceInlines.h: (JSC::Subspace::forEachMarkedCellInParallel): * jsc.cpp: (functionDollarAgentReceiveBroadcast): * runtime/ArrayBuffer.cpp: (JSC::ArrayBuffer::slice const): (JSC::ArrayBuffer::sliceImpl const): * runtime/ArrayBuffer.h: * runtime/ArrayBufferNeuteringWatchpoint.cpp: (JSC::ArrayBufferNeuteringWatchpoint::ArrayBufferNeuteringWatchpoint): (JSC::ArrayBufferNeuteringWatchpoint::fireAll): * runtime/ArrayBufferNeuteringWatchpoint.h: * runtime/JSArrayBufferPrototype.cpp: (JSC::arrayBufferProtoFuncSlice): 2018-12-21 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Crashes seen under Inspector::ScriptCallFrame::~ScriptCallFrame https://bugs.webkit.org/show_bug.cgi?id=180373 <rdar://problem/33894170> Rubber-stamped by Devin Rousso. * inspector/AsyncStackTrace.cpp: (Inspector::AsyncStackTrace::truncate): The `lastUnlockedAncestor->remove()` may release the only reference to it's parent which we intend to use later but don't hold a RefPtr to. Keep the parent alive explicitly by protecting it. 2018-12-20 Chris Dumez <cdumez@apple.com> Use Optional::hasValue() instead of Optional::has_value() https://bugs.webkit.org/show_bug.cgi?id=192948 Reviewed by Tim Horton. * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py: (CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain): (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): 2018-12-20 Keith Miller <keith_miller@apple.com> Add support for globalThis https://bugs.webkit.org/show_bug.cgi?id=165171 Reviewed by Mark Lam. This patch adds support for the globalThis property on the global object. The globalThis property spec is in stage three and is quite simple. For reference: http://tc39.github.io/proposal-global/ * runtime/JSGlobalObject.cpp: 2018-12-20 Chris Dumez <cdumez@apple.com> Use Optional::valueOr() instead of Optional::value_or() https://bugs.webkit.org/show_bug.cgi?id=192933 Reviewed by Geoffrey Garen. * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm: (Inspector::RemoteConnectionToTarget::setup): * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: (Inspector::RemoteConnectionToTarget::setup): * parser/SourceCodeKey.h: (JSC::SourceCodeKey::SourceCodeKey): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): 2018-12-20 Joseph Pecoraro <pecoraro@apple.com> ITMLKit Inspector: Elements tab does not show DOM Tree https://bugs.webkit.org/show_bug.cgi?id=192910 <rdar://problem/46680585> Reviewed by Brian Burg. * inspector/agents/InspectorAgent.h: * inspector/agents/InspectorAgent.cpp: (Inspector::InspectorAgent::enable): (Inspector::InspectorAgent::activateExtraDomain): (Inspector::InspectorAgent::activateExtraDomains): Send extra domains immediately instead of waiting until the Inspector domain is enabled. This will ensure the frontend hears about extra augmented domains before augmenting agents get a chance to send any messages. 2018-12-20 Mark Lam <mark.lam@apple.com> Fix a typo in slow_path_construct_arityCheck and operationConstructArityCheck. https://bugs.webkit.org/show_bug.cgi?id=192939 <rdar://problem/46869516> Reviewed by Keith Miller. * jit/JITOperations.cpp: * runtime/CommonSlowPaths.cpp: 2018-12-20 Caio Lima <ticaiolima@gmail.com> [BigInt] We should enable CSE into arithmetic operations that speculate BigIntUse https://bugs.webkit.org/show_bug.cgi?id=192723 Reviewed by Yusuke Suzuki. This patch is adjusting clobberize rules into ValueOp nodes to enable more optimizations when we speculate BigIntUse. In such case, DFG now is able to apply CSE, LICM and commutativity on nodes like ValueAdd(BigInt, BigInt), ValueSub(BigInt, BigInt), etc. Here are the numbers we can observe with some microbenchmarks: baseline changes big-int-cse 108.2733+-0.8445 ^ 80.9897+-4.9781 ^ definitely 1.3369x faster big-int-licm 75.6641+-0.3477 ^ 57.8144+-1.6043 ^ definitely 1.3087x faster big-int-global-cse 145.3557+-1.0552 ^ 86.5866+-0.3025 ^ definitely 1.6787x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): 2018-12-19 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r239377. https://bugs.webkit.org/show_bug.cgi?id=192921 broke 32-bit JSC tests (Requested by keith_miller on #webkit). Reverted changeset: "[BigInt] We should enable CSE into arithmetic operations that speculate BigIntUse" https://bugs.webkit.org/show_bug.cgi?id=192723 https://trac.webkit.org/changeset/239377 2018-12-19 Chris Dumez <cdumez@apple.com> wtf/Optional.h: move-constructor and move-assignment operator should disengage the value being moved from https://bugs.webkit.org/show_bug.cgi?id=192728 <rdar://problem/46746779> Reviewed by Geoff Garen. * API/*: * Scripts/*: * assembler/*: * b3/*: * bytecode/*: * bytecompiler/*: * debugger/*: * dfg/*: * ftl/*: * heap/*: * inspector/*: * jit/*: * llint/*: * parser/*: * runtime/*: * tools/*: * wasm/*: * yarr/*: 2018-12-18 Simon Fraser <simon.fraser@apple.com> Web Inspector: Timelines: correctly label Intersection Observer callbacks https://bugs.webkit.org/show_bug.cgi?id=192669 <rdar://problem/46702490> Reviewed by Joseph Pecoraro. Add InspectorInstrumentation::willFireObserverCallback() and use it to wrap calls to Intersection Observer, Performance Observer and Mutation Observer callbacks so that they get correctly labeled in the Inspector timeline. * inspector/protocol/Timeline.json: 2018-12-18 Mark Lam <mark.lam@apple.com> JSPropertyNameEnumerator should cache the iterated object's structure only after getting its property names. https://bugs.webkit.org/show_bug.cgi?id=192464 <rdar://problem/46519455> Reviewed by Saam Barati. This is because the process of getting its property names may cause some lazy properties to be reified, and the structure will change. This is needed in order for get_direct_pname to work correctly. * runtime/JSPropertyNameEnumerator.h: (JSC::propertyNameEnumerator): 2018-12-19 Caio Lima <ticaiolima@gmail.com> [BigInt] We should enable CSE into arithmetic operations that speculate BigIntUse https://bugs.webkit.org/show_bug.cgi?id=192723 Reviewed by Saam Barati. This patch is adjusting clobberize rules into ValueOp nodes to enable more optimizations when we speculate BigIntUse. In such case, DFG now is able to apply CSE, LICM and commutativity on nodes like ValueAdd(BigInt, BigInt), ValueSub(BigInt, BigInt), etc. Here are the numbers we can observe with some microbenchmarks: baseline changes big-int-cse 108.2733+-0.8445 ^ 80.9897+-4.9781 ^ definitely 1.3369x faster big-int-licm 75.6641+-0.3477 ^ 57.8144+-1.6043 ^ definitely 1.3087x faster big-int-global-cse 145.3557+-1.0552 ^ 86.5866+-0.3025 ^ definitely 1.6787x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): 2018-12-19 Tadeu Zagallo <tzagallo@apple.com> String overflow in JSC::createError results in ASSERT in WTF::makeString https://bugs.webkit.org/show_bug.cgi?id=192833 <rdar://problem/45706868> Reviewed by Mark Lam. JSC::createError was calling WTF::makeString which would result in an assertion failure when the string was too big. Change it to call WTF::tryMakeString instead and return an OutOfMemory error if we fail to create the error string. * runtime/ExceptionHelpers.cpp: (JSC::createError): 2018-12-18 Ross Kirsling <ross.kirsling@sony.com> Error message for `-x ** y` contains a typo. https://bugs.webkit.org/show_bug.cgi?id=192832 Reviewed by Saam Barati. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseBinaryExpression): Make corrections to error message: "amiguous" -> "ambiguous", "parenthesis" -> "parentheses" 2018-12-18 Saam Barati <sbarati@apple.com> Update ARM64EHash https://bugs.webkit.org/show_bug.cgi?id=192823 <rdar://problem/45468257> Reviewed by Mark Lam. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::ARM64Assembler): * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::AbstractMacroAssembler): * assembler/AssemblerBuffer.h: (JSC::ARM64EHash::update): (JSC::ARM64EHash::finalHash const): (JSC::AssemblerBuffer::AssemblerBuffer): (JSC::AssemblerBuffer::putIntegralUnchecked): (JSC::ARM64EHash::ARM64EHash): Deleted. (JSC::ARM64EHash::hash const): Deleted. (JSC::ARM64EHash::randomSeed const): Deleted. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): 2018-12-18 Mark Lam <mark.lam@apple.com> JSON.stringify() should throw OOM on StringBuilder overflows. https://bugs.webkit.org/show_bug.cgi?id=192822 <rdar://problem/46670577> Reviewed by Saam Barati. * runtime/JSONObject.cpp: (JSC::Stringifier::stringify): (JSC::Stringifier::appendStringifiedValue): (JSC::Stringifier::Holder::appendNextProperty): 2018-12-18 Ross Kirsling <ross.kirsling@sony.com> Redeclaration of var over let/const/class should be a syntax error. https://bugs.webkit.org/show_bug.cgi?id=192298 Reviewed by Keith Miller. From https://tc39.github.io/ecma262/#sec-block-static-semantics-early-errors: It is a Syntax Error if any element of the LexicallyDeclaredNames of StatementList also occurs in the VarDeclaredNames of StatementList. Accordingly, this patch ensures that { let x; { var x; } } and { { var x; } let x; } are syntax errors. For the "var after" scenario: When checking for existing lexically-declared names, we can't simply check the current var scope; we need to check *all* enclosing scopes up to (and including) the current var scope. In so doing, we must also avoid violating the Annex B.3.5 condition that allows `try {} catch (e) { var e; }`. For the "var before" scenario: We ensure that lexical scopes always keep track of the vars being hoisted over them; this gives us a simple way to check the current block's var-declared names prior to making a lexical declaration. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseTryStatement): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::setIsSimpleCatchParameterScope): Added. (JSC::Scope::isSimpleCatchParameterScope): Added. (JSC::Scope::declareVariable): (JSC::Scope::addVariableBeingHoisted): Added. (JSC::Scope::declareLexicalVariable): (JSC::Scope::hasDeclaredVariable): (JSC::Scope::hasLexicallyDeclaredVariable): Added. (JSC::Parser::declareHoistedVariable): Added. (JSC::Parser::declareVariable): 2018-12-18 David Kilzer <ddkilzer@apple.com> clang-tidy: Use const reference for MediaTime parameter to prevent object copy <https://webkit.org/b/192814> Reviewed by Mark Lam. * runtime/JSCJSValue.h: (JSC::jsNumber): 2018-12-18 Saam Barati <sbarati@apple.com> Unreviewed. Appease a build error where we weren't using a variable defined in an "if" * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): 2018-12-17 Mark Lam <mark.lam@apple.com> Array unshift/shift should not race against the AI in the compiler thread. https://bugs.webkit.org/show_bug.cgi?id=192795 <rdar://problem/46724263> Reviewed by Saam Barati. The Array unshift and shift operations for ArrayStorage type arrays are protected using the cellLock. The AbstractInterpreter's foldGetByValOnConstantProperty() function does grab the cellLock before reading a value from the array's ArrayStorage, but does not get the array butterfly under the protection of the cellLock. This is insufficient and racy. For ArrayStorage type arrays, the fetching of the butterfly also needs to be protected by the cellLock. The unshift / shift operations can move values around in the butterfly. Hence, the fact that AI has fetched a butterfly pointer (while ensuring no structure change) is insufficient to guarantee that the values in the butterfly haven't shifted. Having AI hold the cellLock the whole time (from before fetching the butterfly till after reading the value from it) eliminates this race. Note: we only need to do this for ArrayStorage type arrays. Note also that though AI is holding the cellLock in this case, we still need to ensure that the array structure hasn't changed around the fetching of the butterfly. This is because operations other than unshift and shift are guarded by this protocol, and not the cellLock. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * runtime/JSArray.cpp: (JSC::JSArray::unshiftCountSlowCase): 2018-12-16 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Optimize Object.keys by caching own keys results in StructureRareData https://bugs.webkit.org/show_bug.cgi?id=190047 Reviewed by Saam Barati. Object.keys is one of the most frequently used function in web-tooling-benchmarks (WTB). Object.keys is dominant in lebab of WTB, and frequently called in babel and others. Since our Structure knows the shape of JSObject, we can cache the result of Object.keys in Structure (StructureRareData) as we cache JSPropertyNameEnumerator in StructureRareData. This patch caches the result of Object.keys in StructureRareData. The cached array is created as JSImmutableButterfly. And Object.keys creates CoW from this data. Currently, the lifetime strategy of this JSImmutableButterfly is the same to cached JSPropertyNameEnumerator. It is referenced from Structure, and collected when Structure is collected. This improves several benchmarks in SixSpeed. baseline patched object-assign.es5 350.1710+-3.6303 ^ 226.0368+-4.7558 ^ definitely 1.5492x faster for-of-object.es6 269.1941+-3.3430 ^ 127.9317+-2.3875 ^ definitely 2.1042x faster And it improves WTB lebab by 11.8%. Before: lebab: 6.10 runs/s After: lebab: 6.82 runs/s * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.cpp: (JSC::DFG::Node::convertToNewArrayBuffer): * dfg/DFGNode.h: * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileObjectKeys): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys): * runtime/Butterfly.h: (JSC::ContiguousData::Data::setStartingValue): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSImmutableButterfly.h: (JSC::JSImmutableButterfly::JSImmutableButterfly): We set JSEmpty to the underlying butterfly storage if indexing type is Contiguous. Otherwise, JSImmutableButterfly is half-baked one until all the storage is filled with some meaningful values, it leads to crash if half-baked JSImmutableButterfly is exposed to GC. * runtime/ObjectConstructor.cpp: (JSC::ownPropertyKeys): * runtime/Structure.cpp: (JSC::Structure::canCachePropertyNameEnumerator const): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::setCachedOwnKeys): (JSC::Structure::cachedOwnKeys const): (JSC::Structure::cachedOwnKeysIgnoringSentinel const): (JSC::Structure::canCacheOwnKeys const): * runtime/StructureRareData.cpp: (JSC::StructureRareData::visitChildren): (JSC::StructureRareData::cachedPropertyNameEnumerator const): Deleted. (JSC::StructureRareData::setCachedPropertyNameEnumerator): Deleted. * runtime/StructureRareData.h: * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::cachedPropertyNameEnumerator const): (JSC::StructureRareData::setCachedPropertyNameEnumerator): (JSC::StructureRareData::cachedOwnKeys const): (JSC::StructureRareData::cachedOwnKeysIgnoringSentinel const): (JSC::StructureRareData::cachedOwnKeysConcurrently const): (JSC::StructureRareData::setCachedOwnKeys): (JSC::StructureRareData::previousID const): Deleted. * runtime/VM.cpp: (JSC::VM::VM): 2018-12-17 Mark Lam <mark.lam@apple.com> SamplingProfiler's isValidFramePointer() should reject address at stack origin. https://bugs.webkit.org/show_bug.cgi?id=192779 <rdar://problem/46775869> Reviewed by Saam Barati. isValidFramePointer() was previously treating the address at StackBounds::origin() as valid stack memory. This is not true. StackBounds::origin() is actually the first address beyond valid stack memory. This is now fixed. * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::isValidFramePointer): 2018-12-17 Mark Lam <mark.lam@apple.com> Suppress ASAN on valid stack accesses in Probe-based OSRExit::executeOSRExit(). https://bugs.webkit.org/show_bug.cgi?id=192776 <rdar://problem/46772368> Reviewed by Keith Miller. 1. Add some asanUnsafe methods to the Register class. 2. Update the probe-based OSRExit::executeOSRExit() to use these asanUnsafe methods. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): * interpreter/Register.h: (JSC::Register::asanUnsafeUnboxedInt32 const): (JSC::Register::asanUnsafeUnboxedInt52 const): (JSC::Register::asanUnsafeUnboxedStrictInt52 const): (JSC::Register::asanUnsafeUnboxedDouble const): (JSC::Register::asanUnsafeUnboxedCell const): 2018-12-17 Mark Lam <mark.lam@apple.com> Fix stale assertion in attemptToForceStringArrayModeByToStringConversion(). https://bugs.webkit.org/show_bug.cgi?id=192770 <rdar://problem/46449037> Reviewed by Keith Miller. This assertion was added before Array::OriginalNonArray was introduced. It just needs to be updated to allow for Array::OriginalNonArray. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion): 2018-12-17 Matt Lewis <jlewis3@apple.com> Unreviewed, rolling out r239254. This broke the Windows 10 Debug build Reverted changeset: "Replace many uses of String::format with more type-safe alternatives" https://bugs.webkit.org/show_bug.cgi?id=192742 https://trac.webkit.org/changeset/239254 2018-12-15 Yusuke Suzuki <yusukesuzuki@slowstart.org> Unreviewed, suppress warnings in Linux * jsc.cpp: (jscmain): 2018-12-15 Yusuke Suzuki <yusukesuzuki@slowstart.org> Null pointer dereference in JSC::WriteBarrierBase() https://bugs.webkit.org/show_bug.cgi?id=191252 Reviewed by Keith Miller. JSPromiseDeferred::create can return nullptr and an exception if stack overflow happens. We would like to make it RELEASE_ASSERT since the current module mechanism is not immune to stack overflow. This patch renames JSPromiseDeferred::create to JSPromiseDeferred::tryCreate to tell that it can return nullptr. And we insert error checks or assertions after this call. * jsc.cpp: (GlobalObject::moduleLoaderImportModule): (GlobalObject::moduleLoaderFetch): * runtime/Completion.cpp: (JSC::rejectPromise): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncImportModule): * runtime/JSInternalPromiseDeferred.cpp: (JSC::JSInternalPromiseDeferred::tryCreate): (JSC::JSInternalPromiseDeferred::create): Deleted. * runtime/JSInternalPromiseDeferred.h: * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::importModule): (JSC::JSModuleLoader::resolve): (JSC::JSModuleLoader::fetch): (JSC::moduleLoaderParseModule): * runtime/JSPromise.h: * runtime/JSPromiseDeferred.cpp: (JSC::JSPromiseDeferred::tryCreate): * runtime/JSPromiseDeferred.h: * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyCompileFunc): (JSC::webAssemblyInstantiateFunc): (JSC::webAssemblyCompileStreamingInternal): (JSC::webAssemblyInstantiateStreamingInternal): 2018-12-15 Darin Adler <darin@apple.com> Use warning-ignoring macros more consistently and simply https://bugs.webkit.org/show_bug.cgi?id=192743 Reviewed by Mark Lam. * dfg/DFGSpeculativeJIT64.cpp: Use IGNORE_WARNINGS_BEGIN/END instead of IGNORE_CLANG_WARNINGS_BEGIN/END. Other callsites are using the non-clang-specific one for this warning, "implicit-fallthrough", and it seems there is no special need to use the clang-specific one here. * llint/LLIntData.cpp: Ditto, but here it's "missing-noreturn"." * tools/CodeProfiling.cpp: Ditto. 2018-12-15 Darin Adler <darin@apple.com> Replace many uses of String::format with more type-safe alternatives https://bugs.webkit.org/show_bug.cgi?id=192742 Reviewed by Mark Lam. * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::makeCall): Use makeString. (Inspector::InjectedScriptBase::makeAsyncCall): Ditto. * inspector/InspectorBackendDispatcher.cpp: (Inspector::BackendDispatcher::getPropertyValue): Ditto. * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::enable): Ditto. * jsc.cpp: (FunctionJSCStackFunctor::operator() const): Ditto. * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::initializeDateTimeFormat): Use string concatenation. * runtime/IntlObject.cpp: (JSC::canonicalizeLocaleList): Ditto. 2018-12-14 Darin Adler <darin@apple.com> LiteralParser has a bunch of uses of String::format with untrusted data https://bugs.webkit.org/show_bug.cgi?id=108883 rdar://problem/13666409 Reviewed by Mark Lam. * runtime/LiteralParser.cpp: (JSC::LiteralParser<CharType>::Lexer::lex): Use makeString instead of String::format. (JSC::LiteralParser<CharType>::Lexer::lexStringSlow): Ditto. (JSC::LiteralParser<CharType>::parse): Ditto. * runtime/LiteralParser.h: (JSC::LiteralParser::getErrorMessage): Use string concatenation instead of String::format. 2018-12-14 Mark Lam <mark.lam@apple.com> CallFrame::convertToStackOverflowFrame() needs to keep the top CodeBlock alive. https://bugs.webkit.org/show_bug.cgi?id=192717 <rdar://problem/46660677> Reviewed by Saam Barati. When throwing a StackOverflowError, we convert the topCallFrame into a StackOverflowFrame. Previously, we would nullify the codeBlock field in the frame because a StackOverflowFrame is only a sentinel and doesn't really correspond to any CodeBlocks. However, this is a problem because the topCallFrame may be the only remaining place that references the CodeBlock that the stack overflow is triggered in. The way we handle exceptions in JIT code is to return (from the runtime operation function throwing the exception) to the JIT code to check for the exception and if needed, do some clean up before jumping to the exception handling thunk. As a result, we need to keep that JIT code alive, which means we need to keep its CodeBlock alive. We only need to keep this CodeBlock alive until we've unwound (in terms of exception handling) out of it. We fix this issue by storing the CodeBlock to keep alive in the StackOverflowFrame for the GC to scan while the frame is still on the stack. We removed the call to convertToStackOverflowFrame() in lookupExceptionHandlerFromCallerFrame() because it is redundant. lookupExceptionHandlerFromCallerFrame() will only every be called after a StackOverFlowError has been thrown. Hence, the top frame is already guaranteed to be a StackOverflowFrame, and there should always be a StackOverFlowError exception pending. We added assertions for these instead. * interpreter/CallFrame.cpp: (JSC::CallFrame::convertToStackOverflowFrame): * interpreter/CallFrame.h: * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::codeBlockFromCallFrameCallee): (JSC::CommonSlowPaths::arityCheckFor): * runtime/VM.h: (JSC::VM::exceptionForInspection const): 2018-12-14 David Kilzer <ddkilzer@apple.com> clang-tidy: Fix unnecessary copy of objects for operator==() methods <https://webkit.org/b/192712> <rdar://problem/46739332> Reviewed by Andy Estes. * b3/air/AirAllocateRegistersByGraphColoring.cpp: (JSC::B3::Air::(anonymous namespace)::AbstractColoringAllocator::InterferenceEdge::operator==): - Change argument from const to const reference to avoid a copy. 2018-12-14 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r239153, r239154, and r239155. https://bugs.webkit.org/show_bug.cgi?id=192715 Caused flaky GC-related crashes seen with layout tests (Requested by ryanhaddad on #webkit). Reverted changesets: "[JSC] Optimize Object.keys by caching own keys results in StructureRareData" https://bugs.webkit.org/show_bug.cgi?id=190047 https://trac.webkit.org/changeset/239153 "Unreviewed, build fix after r239153" https://bugs.webkit.org/show_bug.cgi?id=190047 https://trac.webkit.org/changeset/239154 "Unreviewed, build fix after r239153, part 2" https://bugs.webkit.org/show_bug.cgi?id=190047 https://trac.webkit.org/changeset/239155 2018-12-14 Keith Miller <keith_miller@apple.com> Callers of JSString::getIndex should check for OOM exceptions https://bugs.webkit.org/show_bug.cgi?id=192709 Reviewed by Mark Lam. This patch also allows Strings to OOM when the StringObject wrapper attempts to look up an own property on the string. Remove isExtensibleImpl because it's only used in one place and call isStructureExtensible instead. * runtime/JSObject.cpp: (JSC::JSObject::isExtensible): * runtime/JSObject.h: (JSC::JSObject::isExtensibleImpl): Deleted. * runtime/JSString.h: (JSC::JSString::getStringPropertySlot): * runtime/StringObject.cpp: (JSC::StringObject::defineOwnProperty): 2018-12-13 Fujii Hironori <Hironori.Fujii@sony.com> [WinCairo][Clang] DLLLauncherMain.cpp: warning: unused function 'prependPath' and 'appleApplicationSupportDirectory' https://bugs.webkit.org/show_bug.cgi?id=192688 Reviewed by Ross Kirsling. These functions are used only in AppleWin port. * shell/DLLLauncherMain.cpp: (copyEnvironmentVariable): Moved. (getStringValue): Enclosed with #if !defined(WIN_CAIRO). (applePathFromRegistry): Ditto. (appleApplicationSupportDirectory): Ditto. (prependPath): Ditto. 2018-12-13 Dominik Infuehr <dinfuehr@igalia.com> Improve GDB output for LLInt on Linux https://bugs.webkit.org/show_bug.cgi?id=192660 Reviewed by Yusuke Suzuki. Annotate assembly code generated for LLInt with the bytecode operation. When debugging LLInt assembly code GDB is then able to show which bytecode instruction is implemented by the current assembly code. This also works for linux-perf. * llint/LowLevelInterpreter.cpp: * offlineasm/arm.rb: 2018-12-13 Mark Lam <mark.lam@apple.com> Add a missing exception check. https://bugs.webkit.org/show_bug.cgi?id=192626 <rdar://problem/46662163> Reviewed by Keith Miller. * runtime/ScopedArguments.h: 2018-12-13 Saam Barati <sbarati@apple.com> The JSC shell should listen for memory pressure events and respond to them https://bugs.webkit.org/show_bug.cgi?id=192647 Reviewed by Keith Miller. We want the JSC shell to behave more like the WebContent process when it comes to running performance tests. One way to make the shell more like this is to have it respond to memory pressure events in a similar way as the WebContent process. This makes it easier to run benchmarks like JetStream2 on the CLI on iOS. * jsc.cpp: (jscmain): * runtime/VM.cpp: (JSC::VM::drainMicrotasks): * runtime/VM.h: (JSC::VM::setOnEachMicrotaskTick): 2018-12-13 Mark Lam <mark.lam@apple.com> Ensure that StructureFlags initialization always starts with Base::StructureFlags. https://bugs.webkit.org/show_bug.cgi?id=192686 Reviewed by Keith Miller. This is purely a refactoring effort to make the code consistently start all StructureFlags initialization with Base::StructureFlags. Previously, sometimes Base::StructureFlags is appended at the end, and sometimes, it is expressed using the name of the superclass. This patch makes the code all consistent and easier to do a quick eye scan audit on to verify that no StructureFlags are forgetting to inherit Base::StructureFlags. Also added a static_assert in JSCallbackObject.h and JSBoundFunction.h. Both of these implement a customHasInstance() method, and rely on ImplementsHasInstance being included in the StructureFlags, and conversely, ImplementsDefaultHasInstance has to be excluded. JSBoundFunction.h is the only case where a bit (ImplementsDefaultHasInstance) needs to be masked out of the inherited Base::StructureFlags. * API/JSCallbackObject.h: * runtime/ArrayConstructor.h: * runtime/ArrayIteratorPrototype.h: * runtime/Exception.h: * runtime/FunctionRareData.h: * runtime/InferredType.h: * runtime/InferredTypeTable.h: * runtime/InferredValue.h: * runtime/JSBoundFunction.h: * runtime/MapPrototype.h: * runtime/SetPrototype.h: * runtime/StringPrototype.h: * runtime/SymbolConstructor.h: 2018-12-13 Mark Lam <mark.lam@apple.com> Add the JSC_traceBaselineJITExecution option for tracing baseline JIT execution. https://bugs.webkit.org/show_bug.cgi?id=192684 Reviewed by Saam Barati. This dataLogs the bytecode execution order of baseline JIT code when the JSC_traceBaselineJITExecution option is true. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * runtime/Options.h: 2018-12-13 David Kilzer <ddkilzer@apple.com> clang-tidy: Fix unnecessary object copies in JavaScriptCore <https://webkit.org/b/192680> <rdar://problem/46708767> Reviewed by Mark Lam. * assembler/testmasm.cpp: (JSC::invoke): - Make MacroAssemblerCodeRef<JSEntryPtrTag> argument a const reference. * b3/testb3.cpp: (JSC::B3::checkDisassembly): - Make CString argument a const reference. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileStringEquality): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetByIdWithThis): - Make JITCompiler::JumpList arguments a const reference. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::checkStructure): - Make RegisteredStructureSet argument a const reference. * jsc.cpp: (GlobalObject::moduleLoaderImportModule): Make local auto variables const references. (Workers::report): Make String argument a const reference. (addOption): Make Identifier argument a const reference. (runJSC): Make CString loop variable a const reference. 2018-12-13 Devin Rousso <drousso@apple.com> Web Inspector: remove DOM.BackendNodeId and associated commands/events https://bugs.webkit.org/show_bug.cgi?id=192478 Reviewed by Matt Baker. * inspector/protocol/DOM.json: 2018-12-13 Caio Lima <ticaiolima@gmail.com> [BigInt] Add ValueDiv into DFG https://bugs.webkit.org/show_bug.cgi?id=186178 Reviewed by Yusuke Suzuki. This patch is introducing a new node type called ValueDiv. This node is responsible to handle Untyped and Bigint specialization of division operator, while the ArithDiv variant handles Number/Boolean cases. BigInt specialization generates following speedup into simple benchmark: noSpec changes big-int-simple-div 10.6013+-0.4682 ^ 8.4518+-0.0943 ^ definitely 1.2543x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeDivSafe): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupArithDiv): (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::arithNodeFlags): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueDiv): (JSC::DFG::SpeculativeJIT::compileArithDiv): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileValueDiv): (JSC::FTL::DFG::LowerDFGToB3::compileArithDiv): (JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot): 2018-12-13 Yusuke Suzuki <yusukesuzuki@slowstart.org> Unreviewed, build fix after r239153, part 2 https://bugs.webkit.org/show_bug.cgi?id=190047 * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::cachedOwnKeys const): 2018-12-13 Yusuke Suzuki <yusukesuzuki@slowstart.org> Unreviewed, build fix after r239153 https://bugs.webkit.org/show_bug.cgi?id=190047 * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::cachedOwnKeys const): 2018-12-10 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Optimize Object.keys by caching own keys results in StructureRareData https://bugs.webkit.org/show_bug.cgi?id=190047 Reviewed by Keith Miller. Object.keys is one of the most frequently used function in web-tooling-benchmarks (WTB). Object.keys is dominant in lebab of WTB, and frequently called in babel and others. Since our Structure knows the shape of JSObject, we can cache the result of Object.keys in Structure (StructureRareData) as we cache JSPropertyNameEnumerator in StructureRareData. This patch caches the result of Object.keys in StructureRareData. The cached array is created as JSImmutableButterfly. And Object.keys creates CoW from this data. Currently, the lifetime strategy of this JSImmutableButterfly is the same to cached JSPropertyNameEnumerator. It is referenced from Structure, and collected when Structure is collected. This improves several benchmarks in SixSpeed. baseline patched object-assign.es5 350.1710+-3.6303 ^ 226.0368+-4.7558 ^ definitely 1.5492x faster for-of-object.es6 269.1941+-3.3430 ^ 127.9317+-2.3875 ^ definitely 2.1042x faster And it improves WTB lebab by 11.8%. Before: lebab: 6.10 runs/s After: lebab: 6.82 runs/s * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.cpp: (JSC::DFG::Node::convertToNewArrayBuffer): * dfg/DFGNode.h: * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileObjectKeys): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: * runtime/JSImmutableButterfly.h: (JSC::JSImmutableButterfly::createSentinel): * runtime/ObjectConstructor.cpp: (JSC::ownPropertyKeys): * runtime/Structure.cpp: (JSC::Structure::canCachePropertyNameEnumerator const): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::setCachedOwnKeys): (JSC::Structure::cachedOwnKeys const): (JSC::Structure::canCacheOwnKeys const): * runtime/StructureRareData.cpp: (JSC::StructureRareData::visitChildren): (JSC::StructureRareData::cachedPropertyNameEnumerator const): Deleted. (JSC::StructureRareData::setCachedPropertyNameEnumerator): Deleted. * runtime/StructureRareData.h: * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::cachedPropertyNameEnumerator const): (JSC::StructureRareData::setCachedPropertyNameEnumerator): (JSC::StructureRareData::cachedOwnKeys const): (JSC::StructureRareData::cachedOwnKeysConcurrently const): (JSC::StructureRareData::setCachedOwnKeys): (JSC::StructureRareData::previousID const): Deleted. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2018-12-12 Yusuke Suzuki <yusukesuzuki@slowstart.org> [DFG][FTL] Add NewSymbol https://bugs.webkit.org/show_bug.cgi?id=192620 Reviewed by Saam Barati. This patch introduces NewSymbol DFG node into DFG and FTL tiers. The main goal of this patch is not optimize NewSymbol code faster. Rather than that, this patch intends to offer SpecSymbol type information into DFG's data flow to optimize generated code in FTL backend. We add NewSymbol DFG node, which may take an argument. If an argument is not given, NewSymbol is for `Symbol()`. If an argument is given, ToString is emitted to this argument before passing it to NewSymbol. So NewSymbol node itself does not perform any type checks. ToString performs effects, but NewSymbol doesn't have any side observable effects. So we can decouple Symbol(description) call into NewSymbol(ToString(description)). * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGClobbersExitState.cpp: (JSC::DFG::clobbersExitState): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGMayExit.cpp: * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewSymbol): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStoreBarrierInsertionPhase.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileNewSymbol): 2018-12-12 Yusuke Suzuki <yusukesuzuki@slowstart.org> [BigInt] Implement DFG/FTL typeof for BigInt https://bugs.webkit.org/show_bug.cgi?id=192619 Reviewed by Keith Miller. This patch implements typeof for BigInt in DFG and FTL. Our DFG and FTL tiers now correctly consider about BigInt in the code generated for typeof. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::boolify): We add (SpecCell - SpecString) type filter for proven type since isString check is already performed here. (JSC::FTL::DFG::LowerDFGToB3::buildTypeOf): We use (SpecCell - SpecObject - SpecString) type filter for proven type since String and Object are already checked here. If we know the proven type does not include Symbol type here, we can omit the code for Symbol type. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitTypeOf): 2018-12-11 Yusuke Suzuki <yusukesuzuki@slowstart.org> [BigInt] Simplify boolean context evaluation by leveraging JSString::offsetOfLength() == JSBigInt::offsetOfLength() https://bugs.webkit.org/show_bug.cgi?id=192615 Reviewed by Saam Barati. JSString and JSBigInt have similar concept in terms of the implementation. Both are immutable, JSCells, and have length information. m_length is located just after JSCell header part, we can ensure `JSString::offsetOfLength() == JSBigInt::offsetOfLength()`, and it allows us to optimize the boolean context evaluation. This patch leverages the above information to reduce the code size for the boolean context evaluation. * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::boolify): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitConvertValueToBoolean): (JSC::AssemblyHelpers::branchIfValue): * runtime/JSBigInt.cpp: (JSC::JSBigInt::JSBigInt): (JSC::JSBigInt::offsetOfLength): Deleted. * runtime/JSBigInt.h: 2018-12-11 Justin Michaud <justin_michaud@apple.com> Implement feature flag for CSS Typed OM https://bugs.webkit.org/show_bug.cgi?id=192610 Reviewed by Ryosuke Niwa. * Configurations/FeatureDefines.xcconfig: 2018-12-10 Don Olmstead <don.olmstead@sony.com> Move ENABLE_RESOURCE_LOAD_STATISTICS to FeatureDefines.xcconfig https://bugs.webkit.org/show_bug.cgi?id=192573 Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2018-12-10 Mark Lam <mark.lam@apple.com> PropertyAttribute needs a CustomValue bit. https://bugs.webkit.org/show_bug.cgi?id=191993 <rdar://problem/46264467> Reviewed by Saam Barati. This is because GetByIdStatus needs to distinguish CustomValue properties from other types, and its only means of doing so is via the property's attributes. Previously, there's nothing in the property's attributes that can indicate that the property is a CustomValue. We fix this by doing the following: 1. Added a PropertyAttribute::CustomValue bit. 2. Added a PropertyAttribute::CustomAccessorOrValue convenience bit mask that is CustomAccessor | CustomValue. 3. Since CustomGetterSetter properties are only set via JSObject::putDirectCustomAccessor(), we added a check in JSObject::putDirectCustomAccessor() to see if the attributes bits include PropertyAttribute::CustomAccessor. If not, then the property must be a CustomValue, and we'll add the PropertyAttribute::CustomValue bit to the attributes bits. This ensures that the property attributes is sufficient to tell us if the property contains a CustomGetterSetter. 4. Updated all checks for PropertyAttribute::CustomAccessor to check for PropertyAttribute::CustomAccessorOrValue instead if their intent is to check for the presence of a CustomGetterSetter as opposed to checking specifically for one that is used as a CustomAccessor. This includes all the Structure transition code that needs to capture the attributes change when a CustomValue has been added. 5. Filtered out the PropertyAttribute::CustomValue bit in PropertyDescriptor. The fact that we're using a CustomGetterSetter as a CustomValue should remain invisible to the descriptor. This is because the descriptor should describe a CustomValue no differently from a plain value. 6. Added some asserts to ensure that property attributes are as expected, and to document some invariants. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): (JSC::GetByIdStatus::computeFor): * bytecode/InByIdStatus.cpp: (JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): * runtime/JSFunction.cpp: (JSC::getCalculatedDisplayName): * runtime/JSObject.cpp: (JSC::JSObject::putDirectCustomAccessor): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength): * runtime/JSObject.h: (JSC::JSObject::putDirectIndex): (JSC::JSObject::fillCustomGetterPropertySlot): (JSC::JSObject::putDirect): * runtime/JSObjectInlines.h: (JSC::JSObject::putDirectInternal): * runtime/PropertyDescriptor.cpp: (JSC::PropertyDescriptor::setDescriptor): (JSC::PropertyDescriptor::setCustomDescriptor): (JSC::PropertyDescriptor::setAccessorDescriptor): * runtime/PropertySlot.h: (JSC::PropertySlot::setCustomGetterSetter): 2018-12-10 Mark Lam <mark.lam@apple.com> LinkBuffer::copyCompactAndLinkCode() needs to be aware of ENABLE(SEPARATED_WX_HEAP). https://bugs.webkit.org/show_bug.cgi?id=192569 <rdar://problem/45615617> Reviewed by Saam Barati. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): 2018-12-10 Caio Lima <ticaiolima@gmail.com> [BigInt] Add ValueMul into DFG https://bugs.webkit.org/show_bug.cgi?id=186175 Reviewed by Yusuke Suzuki. This patch is adding a new DFG node called ValueMul. This node is responsible to handle multiplication operations that can result into non-number values. We emit such node during DFGByteCodeParser when the operands are not numbers. During FixupPhase, we change this operation to ArithMul if we can speculate Number/Boolean operands. The BigInt specialization shows a small progression: noSpec changes big-int-simple-mul 18.8090+-1.0435 ^ 17.4305+-0.2673 ^ definitely 1.0791x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupMultiplication): (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::arithNodeFlags): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueMul): (JSC::DFG::SpeculativeJIT::compileArithMul): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileValueMul): (JSC::FTL::DFG::LowerDFGToB3::compileArithMul): 2018-12-08 Mark Lam <mark.lam@apple.com> Reduce size of PropertySlot and PutPropertySlot. https://bugs.webkit.org/show_bug.cgi?id=192526 Reviewed by Keith Miller. With some minor adjustments, we can reduce the size of PropertySlot from 80 bytes (19 padding bytes) to 64 bytes (3 padding bytes), and PutPropertySlot from 40 bytes (4 padding bytes) to 32 bytes (0 padding bytes but with 6 unused bits). These measurements are for a 64-bit build. * runtime/PropertySlot.h: * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): 2018-12-08 Dominik Infuehr <dinfuehr@igalia.com> Record right offset with aligned wide instructions https://bugs.webkit.org/show_bug.cgi?id=192006 Reviewed by Yusuke Suzuki. Aligning bytecode instructions inserts nops into the instruction stream. Emitting an instruction did not record the actual start of the instruction with aligned instructions, but the nop just before the actual instruction. This was problematic with the StaticPropertyAnalyzer that used the wrong instruction offset. * bytecode/InstructionStream.h: (JSC::InstructionStream::MutableRef::clone): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::alignWideOpcode): (JSC::BytecodeGenerator::emitCreateThis): (JSC::BytecodeGenerator::emitNewObject): * generator/Opcode.rb: 2018-12-07 Tadeu Zagallo <tzagallo@apple.com> Align the metadata table on all platforms https://bugs.webkit.org/show_bug.cgi?id=192050 <rdar://problem/46312674> Reviewed by Mark Lam. Although certain platforms don't require the metadata to be aligned, values were being concurrently read and written to ValueProfiles, which caused crashes since these operations are not atomic on unaligned addresses. * bytecode/Opcode.cpp: (JSC::metadataAlignment): * bytecode/Opcode.h: * bytecode/UnlinkedMetadataTableInlines.h: (JSC::UnlinkedMetadataTable::finalize): 2018-12-05 Mark Lam <mark.lam@apple.com> speculationFromCell() should speculate non-Identifier strings as SpecString instead of SpecStringVar. https://bugs.webkit.org/show_bug.cgi?id=192441 <rdar://problem/46480355> Reviewed by Saam Barati. This is because a regular String (non-Identifier) can be converted into an Identifier. During DFG/FTL compilation, AbstractValue::checkConsistency() may expect a value to be of type SpecStringVar, but the mutator thread may have converted the string into an Identifier. This creates a race where AbstractValue::checkConsistency() may fail because it sees a SpecStringIdent when it expects the a SpecStringVar. The fix is to speculate non-Identifier strings as type SpecString which allows it to be SpecStringVar or SpecStringIndent. * bytecode/SpeculatedType.cpp: (JSC::speculationFromCell): 2018-12-04 Mark Lam <mark.lam@apple.com> DFG's StrengthReduction phase should not reduce Construct into DirectContruct when the executable does not have constructAbility. https://bugs.webkit.org/show_bug.cgi?id=192386 <rdar://problem/46445516> Reviewed by Saam Barati. This violates an invariant documented by a RELEASE_ASSERT in operationLinkDirectCall(). * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): 2018-12-04 Caio Lima <ticaiolima@gmail.com> [ESNext][BigInt] Support logic operations https://bugs.webkit.org/show_bug.cgi?id=179903 Reviewed by Yusuke Suzuki. We are introducing in this patch the ToBoolean support for JSBigInt. With this change, we can implement the correct behavior of BigInt as operand of logical opertions. During JIT genertion into DFG and FTL, we are using JSBigInt::m_length to verify if the number is 0n or not, following the same approach used by JSString. This is also safe in the case of BigInt, because only 0n has m_length == 0. We are not including BigInt speculation into Branch nodes in this patch, but the plan is to implement it in further patches. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::boolify): (JSC::FTL::DFG::LowerDFGToB3::isBigInt): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitConvertValueToBoolean): (JSC::AssemblyHelpers::branchIfValue): * runtime/JSBigInt.cpp: (JSC::JSBigInt::isZero const): (JSC::JSBigInt::offsetOfLength): (JSC::JSBigInt::toBoolean const): (JSC::JSBigInt::isZero): Deleted. * runtime/JSBigInt.h: * runtime/JSCellInlines.h: (JSC::JSCell::toBoolean const): (JSC::JSCell::pureToBoolean const): 2018-12-04 Devin Rousso <drousso@apple.com> Web Inspector: Audit: tests should support async operations https://bugs.webkit.org/show_bug.cgi?id=192171 <rdar://problem/46423562> Reviewed by Joseph Pecoraro. Add `awaitPromise` command for executing a callback when a Promise gets settled. Drive-by: allow `wasThrown` to be optional, instead of expecting it to always have a value. * inspector/protocol/Runtime.json: * inspector/InjectedScriptSource.js: (InjectedScript.prototype.awaitPromise): Added. * inspector/InjectedScript.h: * inspector/InjectedScript.cpp: (Inspector::InjectedScript::evaluate): (Inspector::InjectedScript::awaitPromise): Added. (Inspector::InjectedScript::callFunctionOn): (Inspector::InjectedScript::evaluateOnCallFrame): * inspector/InjectedScriptBase.h: * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::makeEvalCall): (Inspector::InjectedScriptBase::makeAsyncCall): Added. (Inspector::InjcetedScriptBase::checkCallResult): Added. (Inspector::InjcetedScriptBase::checkAsyncCallResult): Added. * inspector/agents/InspectorRuntimeAgent.h: * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::evaluate): (Inspector::InspectorRuntimeAgent::awaitPromise): (Inspector::InspectorRuntimeAgent::callFunctionOn): * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame): 2018-12-03 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r238833. Breaks macOS and iOS debug builds. Reverted changeset: "[ESNext][BigInt] Support logic operations" https://bugs.webkit.org/show_bug.cgi?id=179903 https://trac.webkit.org/changeset/238833 2018-12-03 Caio Lima <ticaiolima@gmail.com> [ESNext][BigInt] Support logic operations https://bugs.webkit.org/show_bug.cgi?id=179903 Reviewed by Yusuke Suzuki. We are introducing in this patch the ToBoolean support for JSBigInt. With this change, we can implement the correct behavior of BigInt as operand of logical opertions. During JIT genertion into DFG and FTL, we are using JSBigInt::m_length to verify if the number is 0n or not, following the same approach used by JSString. This is also safe in the case of BigInt, because only 0n has m_length == 0. We are not including BigInt speculation into Branch nodes in this patch, but the plan is to implement it in further patches. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::boolify): (JSC::FTL::DFG::LowerDFGToB3::isBigInt): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitConvertValueToBoolean): (JSC::AssemblyHelpers::branchIfValue): * runtime/JSBigInt.cpp: (JSC::JSBigInt::isZero const): (JSC::JSBigInt::offsetOfLength): (JSC::JSBigInt::toBoolean const): (JSC::JSBigInt::isZero): Deleted. * runtime/JSBigInt.h: * runtime/JSCellInlines.h: (JSC::JSCell::toBoolean const): (JSC::JSCell::pureToBoolean const): 2018-12-03 Keith Rollin <krollin@apple.com> Add .xcfilelist files https://bugs.webkit.org/show_bug.cgi?id=192082 <rdar://problem/46312533> Reviewed by Brent Fulgham. Add .xcfilelist files for Generate Derived Sources and Generate Unified Sources build phases in Xcode. These are just being staged for now; they'll be added to the Xcode projects later. * DerivedSources-input.xcfilelist: Added. * DerivedSources-output.xcfilelist: Added. * UnifiedSources-input.xcfilelist: Added. * UnifiedSources-output.xcfilelist: Added. 2018-12-03 Mark Lam <mark.lam@apple.com> Fix the bytecode code generator scripts to pretty print BytecodeStructs.h and BytecodeIndices.h. https://bugs.webkit.org/show_bug.cgi?id=192271 Reviewed by Keith Miller. This makes the generated code style compliant and human readable. * generator/Argument.rb: * generator/DSL.rb: * generator/Fits.rb: * generator/Metadata.rb: * generator/Opcode.rb: 2018-12-02 Zalan Bujtas <zalan@apple.com> Add a runtime feature flag for LayoutFormattingContext. https://bugs.webkit.org/show_bug.cgi?id=192280 Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2018-12-02 Caio Lima <ticaiolima@gmail.com> [ESNext][BigInt] Implement support for "<<" and ">>" https://bugs.webkit.org/show_bug.cgi?id=186233 Reviewed by Yusuke Suzuki. This patch is introducing the support for BigInt into lshift and rshift into LLint and Baseline layers. * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSBigInt.cpp: (JSC::JSBigInt::createWithLength): (JSC::JSBigInt::leftShift): (JSC::JSBigInt::signedRightShift): (JSC::JSBigInt::leftShiftByAbsolute): (JSC::JSBigInt::rightShiftByAbsolute): (JSC::JSBigInt::rightShiftByMaximum): (JSC::JSBigInt::toShiftAmount): * runtime/JSBigInt.h: 2018-12-01 Simon Fraser <simon.fraser@apple.com> Heap.h refers to the non-existent HeapStatistics https://bugs.webkit.org/show_bug.cgi?id=187882 Reviewed by Keith Miller. Just remove the "friend class HeapStatistics". * heap/Heap.h: 2018-11-29 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Keep TypeMaybeBigInt small https://bugs.webkit.org/show_bug.cgi?id=192203 Reviewed by Saam Barati. As BigInt is being implemented, more and more bytecodes start returning BigInt. It means that ResultType of these bytecodes include TypeMaybeBigInt. However, TypeMaybeBigInt was large number 0x20, leading to wide instruction since ResultType easily becomes larger than 32 (e.g. TypeInt32 | TypeMaybeBigInt == 33). This patch sorts the numbers of TypeMaybeXXX based on the frequency of appearance in the code. * parser/ResultType.h: 2018-11-30 Dean Jackson <dino@apple.com> Try to fix Windows build by using strcmp instead of strcasecmp. * jsc.cpp: (isMJSFile): 2018-11-30 Mark Lam <mark.lam@apple.com> Fix the bytecode code generator scripts to pretty print Bytecodes.h. https://bugs.webkit.org/show_bug.cgi?id=192258 Reviewed by Keith Miller. This makes Bytecodes.h more human readable. * generator/DSL.rb: * generator/Section.rb: 2018-11-30 Mark Lam <mark.lam@apple.com> Add the generator directory to the Xcode project. https://bugs.webkit.org/show_bug.cgi?id=192252 Reviewed by Michael Saboff. This is so that we can work with these bytecode class generator files easily in Xcode. * JavaScriptCore.xcodeproj/project.pbxproj: 2018-11-30 Don Olmstead <don.olmstead@sony.com> Rename ENABLE_SUBTLE_CRYPTO to ENABLE_WEB_CRYPTO https://bugs.webkit.org/show_bug.cgi?id=192197 Reviewed by Jiewen Tan. * Configurations/FeatureDefines.xcconfig: 2018-11-30 Dean Jackson <dino@apple.com> Add first-class support for .mjs files in jsc binary https://bugs.webkit.org/show_bug.cgi?id=192190 <rdar://problem/46375715> Reviewed by Keith Miller. Treat files with a .mjs extension as a module, regardless of whether or not the --module-file argument was given. * jsc.cpp: (printUsageStatement): Update usage. (isMJSFile): Helper to look for .mjs extensions. (CommandLine::parseArguments): Pick the appropriate script type. 2018-11-30 Caio Lima <ticaiolima@gmail.com> [BigInt] Implement ValueBitXor into DFG https://bugs.webkit.org/show_bug.cgi?id=190264 Reviewed by Yusuke Suzuki. This patch is splitting the BitXor node into ArithBitXor and ValueBitXor. This is necessary due the introduction of BigInt, since BitXor operations now can result into Int32 or BigInt. In such case, we use ArithBitXor when operands are Int and fallback to ValueBitXor when operands are anything else. In the case of ValueBitXor, we speculate BigInt when op1 and op2 are predicted as BigInt as well. BigInt specialization consist into call `operationBigIntBitXor` function, that calls JSBigInt::bitXor. * bytecode/BytecodeList.rb: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::arithProfileForPC): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecompiler/BytecodeGenerator.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo): (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueBitwiseOp): (JSC::DFG::SpeculativeJIT::compileBitwiseOp): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::bitOp): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileValueBitXor): (JSC::FTL::DFG::LowerDFGToB3::compileArithBitXor): (JSC::FTL::DFG::LowerDFGToB3::compileBitXor): Deleted. * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_bitxor): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): 2018-11-29 Justin Michaud <justin_michaud@apple.com> CSS Painting API should pass 'this' correctly to paint callback, and repaint when properties change. https://bugs.webkit.org/show_bug.cgi?id=191443 Reviewed by Dean Jackson. Export the simpler construct() method for use in WebCore. * runtime/ConstructData.h: 2018-11-28 Mark Lam <mark.lam@apple.com> ENABLE_SEPARATED_WX_HEAP needs to be defined in Platform.h. https://bugs.webkit.org/show_bug.cgi?id=192110 <rdar://problem/46317746> Reviewed by Saam Barati. * config.h: 2018-11-28 Keith Rollin <krollin@apple.com> Update generate-{derived,unified}-sources scripts to support generating .xcfilelist files https://bugs.webkit.org/show_bug.cgi?id=192031 <rdar://problem/46286816> Reviewed by Alex Christensen. The Generate Derived Sources and Generate Unified Sources build phases in Xcode need to have their inputs and outputs specified. This specification will come in the form of .xcfilelist files that will be attached to these build phases. There is one .xcfilelist file that lists the input file and one that lists the output files. As part of this work, the various generate-{derived,unified}-sources scripts that are executed in these Generate build phases are modified to help in the creation of these .xcfilelist files. In particular, they can now be invoked with command-line parameters. These parameters are then used to alter the normal execution of these scripts, causing them to produce the .xcfilelist files as opposed to actually generating the files that are listed in those files. * Scripts/generate-derived-sources.sh: * Scripts/generate-unified-sources.sh: 2018-11-28 Keith Rollin <krollin@apple.com> Revert print_all_generated_files work in r238008; tighten up target specifications https://bugs.webkit.org/show_bug.cgi?id=192025 <rdar://problem/46284301> Reviewed by Alex Christensen. In r238008, I added a facility for DerivedSources.make makefiles to print out the list of files that they generate. This output was used in the generation of .xcfilelist files used to specify the output of the associated Generate Derived Sources build phases in Xcode. This approach worked, but it meant that people would need to follow a specific convention to keep this mechanism working. Instead of continuing this approach, I'm going to implement a new facility based on the output of `make` when passed the -d flag (which prints dependency information). This new mechanism is completely automatic and doesn't need maintainers to follow a convention. To that end, remove most of the work performed in r238008 that supports the print_all_generated_files target. At the same time, it's important for the sets of targets and their dependencies to be complete and correct. Therefore, also include changes to bring those up-to-date. As part of that, you'll see prevalent use of a particular technique. Here's an example: BYTECODE_FILES = \ Bytecodes.h \ BytecodeIndices.h \ BytecodeStructs.h \ InitBytecodes.asm \ # BYTECODE_FILES_PATTERNS = $(subst .,%,$(BYTECODE_FILES)) all : $(BYTECODE_FILES) $(BYTECODE_FILES_PATTERNS): $(wildcard $(JavaScriptCore)/generator/*.rb) $(JavaScriptCore)/bytecode/BytecodeList.rb ... These lines indicate a set of generated files (those specified in BYTECODE_FILES). These files are generated by the BytecodeList.rb tool. But, as opposed to the normal rule where a single foo.output is generated by foo.input plus some additional dependencies, this rule produces multiple output files from a tool whose connection to the output files is not immediately clear. A special approach is needed where a single rule produces multiple output files. The normal way to implement this is to use an .INTERMEDIATE target. However, we used this approach in the past and ran into a problem with it, addressing it with an alternate approach in r210507. The above example shows this approach. The .'s in the list of target files are replaced with %'s, and the result is used as the left side of the dependency rule. * DerivedSources.make: 2018-11-28 Keith Rollin <krollin@apple.com> Remove Postprocess Headers dependencies https://bugs.webkit.org/show_bug.cgi?id=192023 <rdar://problem/46283377> Reviewed by Mark Lam. JavaScriptCore's Xcode Postprocess Headers build phase used to have a dependency on a specific handful of files. In r234227, the script used in this phase (postprocess-headers.sh) was completely rewritten to operate on *all* files in JSC's Public and Private headers directories instead of just this handful. This rewrite makes the previous dependency specification insufficient, leading to incorrect incremental builds if the right files weren't touched. Address this by removing the dependencies completely. This will cause postprocess-headers.sh to always be executed, even when none of its files are touch. Running this script all the time is OK, since it has built-in protections against unnecessarily touching files that haven't changed. * JavaScriptCore.xcodeproj/project.pbxproj: 2018-11-27 Mark Lam <mark.lam@apple.com> ENABLE_FAST_JIT_PERMISSIONS should be false for iosmac. https://bugs.webkit.org/show_bug.cgi?id=192055 <rdar://problem/46288783> Reviewed by Saam Barati. * Configurations/FeatureDefines.xcconfig: 2018-11-27 Saam barati <sbarati@apple.com> r238510 broke scopes of size zero https://bugs.webkit.org/show_bug.cgi?id=192033 <rdar://problem/46281734> Reviewed by Keith Miller. In r238510, I wrote the loop like this: `for (ScopeOffset offset { 0 }; offset <= symbolTable->maxScopeOffset(); offset += 1)` This breaks for scopes of size zero because maxScopeOffset() will be UINT_MAX. This patch fixes this by writing the loop as: `for (unsigned offset = 0; offset < symbolTable->scopeSize(); ++offset)` * dfg/DFGObjectAllocationSinkingPhase.cpp: 2018-11-27 Mark Lam <mark.lam@apple.com> ASSERTION FAILED: capacity && isPageAligned(capacity) in JSC::CLoopStack::CLoopStack(JSC::VM&). https://bugs.webkit.org/show_bug.cgi?id=192018 Reviewed by Saam Barati. This assertion failed because the regress-191579.js test was specifying --maxPerThreadStackUsage=400000 i.e. it was running with a stack size that is not page aligned. Given that the user can specify any arbitrary stack size, and the CLoop stack expects to be page aligned, we'll just round up the requested capacity to the next page alignment. * interpreter/CLoopStack.cpp: (JSC::CLoopStack::CLoopStack): 2018-11-27 Mark Lam <mark.lam@apple.com> [Re-landing] NaNs read from Wasm code needs to be be purified. https://bugs.webkit.org/show_bug.cgi?id=191056 <rdar://problem/45660341> Reviewed by Filip Pizlo. * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): 2018-11-27 Timothy Hatcher <timothy@apple.com> Web Inspector: Add support for forcing color scheme appearance in DOM tree. https://bugs.webkit.org/show_bug.cgi?id=191820 rdar://problem/46153172 Reviewed by Devin Rousso. * inspector/protocol/Page.json: Added setForcedAppearance. Also added the defaultAppearanceDidChange event and Appearance enum. 2018-11-27 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r238509. Causes JSC tests to fail on iOS. Reverted changeset: "NaNs read from Wasm code needs to be be purified." https://bugs.webkit.org/show_bug.cgi?id=191056 https://trac.webkit.org/changeset/238509 2018-11-27 Mark Lam <mark.lam@apple.com> Introducing a ENABLE_SEPARATED_WX_HEAP macro. https://bugs.webkit.org/show_bug.cgi?id=192013 <rdar://problem/45494310> Reviewed by Keith Miller. This makes the code a little more readable. I put the definition of ENABLE_SEPARATED_WX_HEAP in JSC's config.h instead of Platform.h because ENABLE_SEPARATED_WX_HEAP is only needed inside JSC. Also, ENABLE_SEPARATED_WX_HEAP depends on ENABLE(FAST_JIT_PERMISSIONS), which is only defined for JSC. * config.h: * jit/ExecutableAllocator.cpp: (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps): * jit/ExecutableAllocator.h: (JSC::performJITMemcpy): * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2018-11-26 Caio Lima <ticaiolima@gmail.com> Re-introduce op_bitnot https://bugs.webkit.org/show_bug.cgi?id=190923 Reviewed by Yusuke Suzuki. With the introduction of BigInt as a new type, we can't emit bitwise not as `x ^ -1` anymore, because this is incompatible with the new type. Based on that, this Patch is adding `op_bitnot` as a new operation into LLInt, as well as introducing ArithBitNot node into DFG to support JIT compilation of such opcode. We will use the ValueProfile of this intruction in the future to generate better code when its operand is not Int32. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::not32): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::not32): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::not32): * bytecode/BytecodeList.rb: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitUnaryOp): * bytecompiler/NodesCodegen.cpp: (JSC::UnaryPlusNode::emitBytecode): (JSC::BitwiseNotNode::emitBytecode): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileBitwiseNot): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileArithBitNot): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_bitnot): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/cloop.rb: * parser/NodeConstructors.h: (JSC::BitwiseNotNode::BitwiseNotNode): * parser/Nodes.h: * parser/ResultType.h: (JSC::ResultType::bigIntOrInt32Type): (JSC::ResultType::forBitOp): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2018-11-26 Saam barati <sbarati@apple.com> InPlaceAbstractState::endBasicBlock rule for SetLocal should filter the value based on the flush format https://bugs.webkit.org/show_bug.cgi?id=191956 <rdar://problem/45665806> Reviewed by Yusuke Suzuki. This is a similar bug to what Keith fixed in r232134. The issue is if we have a program like this: a: JSConstant(jsNumber(0)) b: SetLocal(Int32:@a, loc1, FlushedInt32) c: ArrayifyToStructure(Cell:@a) d: Jump(...) At the point in the program right after the Jump, a GetLocal for loc1 would return whatever the ArrayifyToStructure resulting type is. This breaks the invariant that a GetLocal must return a value that is a subtype of its FlushFormat. InPlaceAbstractState::endBasicBlock will know if a SetLocal is the final node touching a local slot. If so, it'll see if any nodes later in the block may have refined the type of the value stored in that slot. If so, endBasicBlock() further refines the type to ensure that any GetLocals loading from the same slot will result in having this more refined type. However, we must ensure that this logic only considers types within the hierarchy of the variable access data's FlushFormat, otherwise, we may break the invariant that a GetLocal's type is a subtype of its FlushFormat. * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::endBasicBlock): 2018-11-26 Saam barati <sbarati@apple.com> Object allocation sinking phase needs to iterate each scope offset instead of just iterating the symbol table's hashmap when handling an activation https://bugs.webkit.org/show_bug.cgi?id=191958 <rdar://problem/46221877> Reviewed by Yusuke Suzuki. There may be more entries in an activation than unique variables in a symbol table's hashmap. For example, if you have two parameters to a function, and they both are the same name, and the function uses eval, we'll end up with two scope slots, but only a single entry in the hashmap in the symbol table. Object allocation sinking phase was previously iterating over the hashmap, assuming these values were equivalent. This is wrong in the above case. Instead, we need to iterate over each scope offset. * dfg/DFGObjectAllocationSinkingPhase.cpp: * runtime/GenericOffset.h: (JSC::GenericOffset::operator+=): (JSC::GenericOffset::operator-=): 2018-11-26 Mark Lam <mark.lam@apple.com> NaNs read from Wasm code needs to be be purified. https://bugs.webkit.org/show_bug.cgi?id=191056 <rdar://problem/45660341> Reviewed by Filip Pizlo. * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): 2018-11-26 Tadeu Zagallo <tzagallo@apple.com> ASSERTION FAILED: m_outOfLineJumpTargets.contains(bytecodeOffset) https://bugs.webkit.org/show_bug.cgi?id=191716 <rdar://problem/45723878> Reviewed by Saam Barati. After https://bugs.webkit.org/show_bug.cgi?id=187373, when updating jump targets during generatorification, we only stored the new jump target when it changed. However, the out-of-line jump targets are cleared at the beginning of the pass, so we need to store it unconditionally. * bytecode/PreciseJumpTargetsInlines.h: (JSC::extractStoredJumpTargetsForInstruction): (JSC::updateStoredJumpTargetsForInstruction): 2018-11-23 Wenson Hsieh <wenson_hsieh@apple.com> Enable drag and drop support for iOSMac https://bugs.webkit.org/show_bug.cgi?id=191818 <rdar://problem/43907454> Reviewed by Dean Jackson. * Configurations/FeatureDefines.xcconfig: 2018-11-22 Mark Lam <mark.lam@apple.com> Make the jsc shell's dumpException() more robust against long exception strings. https://bugs.webkit.org/show_bug.cgi?id=191910 <rdar://problem/46212980> Reviewed by Michael Saboff. This only affects the dumping of the exception string in the jsc shell due to unhandled exceptions or exceptions at shell boot time before any JS code is running. * jsc.cpp: (dumpException): 2018-11-21 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Drop ARM_TRADITIONAL support in LLInt, baseline JIT, and DFG https://bugs.webkit.org/show_bug.cgi?id=191675 Reviewed by Mark Lam. We no longer maintain ARM_TRADITIONAL LLInt and JIT in JSC. This architecture will use CLoop instead. This patch removes ARM_TRADITIONAL support in LLInt and JIT. Discussed in https://lists.webkit.org/pipermail/webkit-dev/2018-October/030220.html. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/ARMAssembler.cpp: Removed. * assembler/ARMAssembler.h: Removed. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::linkCode): (JSC::LinkBuffer::dumpCode): * assembler/MacroAssembler.h: (JSC::MacroAssembler::patchableBranch32): * assembler/MacroAssemblerARM.cpp: Removed. * assembler/MacroAssemblerARM.h: Removed. * assembler/PerfLog.cpp: * assembler/PerfLog.h: * assembler/ProbeContext.h: (JSC::Probe::CPUState::pc): (JSC::Probe::CPUState::fp): (JSC::Probe::CPUState::sp): * assembler/testmasm.cpp: (JSC::isPC): (JSC::testProbeModifiesStackPointer): (JSC::testProbeModifiesStackValues): * bytecode/InlineAccess.h: (JSC::InlineAccess::sizeForPropertyAccess): (JSC::InlineAccess::sizeForPropertyReplace): (JSC::InlineAccess::sizeForLengthAccess): * dfg/DFGSpeculativeJIT.h: * disassembler/CapstoneDisassembler.cpp: (JSC::tryToDisassemble): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::debugCall): * jit/AssemblyHelpers.h: * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsImpl): (JSC::CCallHelpers::prepareForTailCallSlow): * jit/CallFrameShuffler.cpp: (JSC::CallFrameShuffler::prepareForTailCall): * jit/HostCallReturnValue.cpp: * jit/JITMathIC.h: (JSC::isProfileEmpty): * jit/RegisterSet.cpp: (JSC::RegisterSet::reservedHardwareRegisters): (JSC::RegisterSet::calleeSaveRegisters): (JSC::RegisterSet::llintBaselineCalleeSaveRegisters): (JSC::RegisterSet::dfgCalleeSaveRegisters): * jit/Repatch.cpp: (JSC::forceICFailure): * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): * llint/LLIntOfflineAsmConfig.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * offlineasm/arm.rb: * offlineasm/backends.rb: * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generateEnter): (JSC::Yarr::YarrGenerator::generateReturn): 2018-11-21 Saam barati <sbarati@apple.com> DFGSpeculativeJIT should not &= exitOK with mayExit(node) https://bugs.webkit.org/show_bug.cgi?id=191897 <rdar://problem/45871998> Reviewed by Mark Lam. exitOK is a statement about it being legal to exit. mayExit() is about being conservative and returning false only if an OSR exit *could never* happen. mayExit() tries to be as smart as possible to see if it can return false. It can't return false if a runtime exit *could* happen. However, there is code in the compiler where mayExit() returns false (because it uses data generated from AI about type checks being proved), but the code we emit in the compiler backend unconditionally generates an OSR exit, even if that exit may never execute. For example, let's say we have this IR: SomeNode(Boolean:@input) And we always emit code like this as a way of emitting a boolean type check: jump L1 if input == true jump L1 if input == false emit an OSR exit In such a program, when we generate the above OSR exit, in a validationEnabled() build, and if @input is proved to be a boolean, we'll end up crashing because we have the bogus assertion saying !exitOK. This is one reason why things are cleaner if we don't conflate mayExit() with exitOK. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): 2018-11-21 Saam barati <sbarati@apple.com> Fix assertion in KnownCellUse inside SpeculativeJIT::speculate https://bugs.webkit.org/show_bug.cgi?id=191895 <rdar://problem/46167406> Reviewed by Mark Lam. We were asserting that the input edge should have type SpecCell but it should really be SpecCellCheck since the type filter for KnownCellUse is SpecCellCheck. This patch cleans up that assertion code by joining a bunch of cases into a single function call which grabs the type filter for the edge UseKind and asserts that the incoming edge meets the type filter criteria. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculate): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::speculate): 2018-11-21 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Use ProtoCallFrame::numberOfRegisters instead of raw number `4` https://bugs.webkit.org/show_bug.cgi?id=191877 Reviewed by Sam Weinig. Instead of hard-coding `4` into LowLevelInterpreter, use ProtoCallFrame::numberOfRegisters. * interpreter/ProtoCallFrame.h: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2018-11-21 Mark Lam <mark.lam@apple.com> Creating a wasm memory that is bigger than the ArrayBuffer limit but smaller than the spec limit should throw OOME not RangeError. https://bugs.webkit.org/show_bug.cgi?id=191776 <rdar://problem/46152851> Reviewed by Saam Barati. * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::tryCreate): - return nullptr if the requested bytes exceed MAX_ARRAY_BUFFER_SIZE. The clients will already do a null check and throw an OutOfMemoryError if needed. (JSC::Wasm::Memory::grow): - throw OOME if newPageCount.bytes() > MAX_ARRAY_BUFFER_SIZE. * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::constructJSWebAssemblyMemory): - throw OOME if newPageCount.bytes() > MAX_ARRAY_BUFFER_SIZE. 2018-11-21 Caio Lima <ticaiolima@gmail.com> [BigInt] JSBigInt::createWithLength should throw when length is greater than JSBigInt::maxLength https://bugs.webkit.org/show_bug.cgi?id=190836 Reviewed by Saam Barati and Yusuke Suzuki. In this patch we are creating a new method called `JSBigInt::createWithLengthUnchecked` where we allocate a BigInt trusting the length received as argument. With this additional method, we now check if length passed to `JSBigInt::tryCreateWithLength` is not greater than JSBigInt::maxLength. When the length is greater than JSBigInt::maxLength, we then throw OOM exception. This required us to change the interface of some JSBigInt operations to receive `ExecState*` instead of `VM&`. We changed only operations that can throw because of OOM. We beleive that this approach of throwing instead of finishing the execution abruptly is better because JS programs can catch such exception and handle this issue properly. * dfg/DFGOperations.cpp: * jit/JITOperations.cpp: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSBigInt.cpp: (JSC::JSBigInt::createZero): (JSC::JSBigInt::tryCreateWithLength): (JSC::JSBigInt::createWithLengthUnchecked): (JSC::JSBigInt::createFrom): (JSC::JSBigInt::multiply): (JSC::JSBigInt::divide): (JSC::JSBigInt::copy): (JSC::JSBigInt::unaryMinus): (JSC::JSBigInt::remainder): (JSC::JSBigInt::add): (JSC::JSBigInt::sub): (JSC::JSBigInt::bitwiseAnd): (JSC::JSBigInt::bitwiseOr): (JSC::JSBigInt::bitwiseXor): (JSC::JSBigInt::absoluteAdd): (JSC::JSBigInt::absoluteSub): (JSC::JSBigInt::absoluteDivWithDigitDivisor): (JSC::JSBigInt::absoluteDivWithBigIntDivisor): (JSC::JSBigInt::absoluteLeftShiftAlwaysCopy): (JSC::JSBigInt::absoluteBitwiseOp): (JSC::JSBigInt::absoluteAddOne): (JSC::JSBigInt::absoluteSubOne): (JSC::JSBigInt::toStringGeneric): (JSC::JSBigInt::rightTrim): (JSC::JSBigInt::allocateFor): (JSC::JSBigInt::createWithLength): Deleted. * runtime/JSBigInt.h: * runtime/Operations.cpp: (JSC::jsAddSlowCase): * runtime/Operations.h: (JSC::jsSub): (JSC::jsMul): 2018-11-20 Mark Lam <mark.lam@apple.com> Remove invalid assertion in VMTraps::SignalSender's SignalAction. https://bugs.webkit.org/show_bug.cgi?id=191856 <rdar://problem/46089992> Reviewed by Yusuke Suzuki. The ASSERT(vm.traps().needTrapHandling()) assertion in SignalSender's SigAction function is invalid because we can't be sure that the trap has been handled yet by the time the trap fires. This is because the main thread may also check traps (in LLInt, baseline JIT and VM runtime code). There's a race to handle the trap. Hence, the SigAction cannot assume that the trap still needs handling by the time it is executed. This patch removed the invalid assertion. Also renamed m_trapSet to m_condition because it is a AutomaticThreadCondition, and all the ways it is used is as a condvar. The m_trapSet name doesn't seem appropriate nor meaningful. * runtime/VMTraps.cpp: (JSC::VMTraps::tryInstallTrapBreakpoints): - Added a !needTrapHandling() check as an optimization: there's no need to install VMTrap breakpoints if someone already beat us to handling the trap (remember, the main thread is racing against the VMTraps signalling thread to handle the trap too). We only need to install the VMTraps breakpoints if we need DFG/FTL compiled code to deopt so that they can check and handle pending traps. If the trap has already been handled, it's better to not deopt any DFG/FTL functions. (JSC::VMTraps::willDestroyVM): (JSC::VMTraps::fireTrap): (JSC::VMTraps::VMTraps): * runtime/VMTraps.h: 2018-11-21 Dominik Infuehr <dinfuehr@igalia.com> Enable JIT on ARM/Linux https://bugs.webkit.org/show_bug.cgi?id=191548 Reviewed by Yusuke Suzuki. Enable JIT by default on ARMv7/Linux after it was disabled with recent bytcode format change. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::getICStatusMap): * bytecode/CodeBlock.h: (JSC::CodeBlock::metadata): * bytecode/InByIdStatus.cpp: (JSC::InByIdStatus::computeFor): * bytecode/Instruction.h: (JSC::Instruction::cast): * bytecode/MetadataTable.h: (JSC::MetadataTable::forEach): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): (JSC::PutByIdStatus::hasExitSite): Deleted. * bytecode/PutByIdStatus.h: * dfg/DFGOSRExit.cpp: (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * generator/Argument.rb: * generator/Opcode.rb: * jit/GPRInfo.h: * jit/JIT.h: * jit/JITArithmetic32_64.cpp: (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_mod): (JSC::JIT::emitSlow_op_mod): * jit/JITCall32_64.cpp: (JSC::JIT::emitPutCallResult): (JSC::JIT::emit_op_ret): (JSC::JIT::emitSlow_op_call): (JSC::JIT::emitSlow_op_tail_call): (JSC::JIT::emitSlow_op_call_eval): (JSC::JIT::emitSlow_op_call_varargs): (JSC::JIT::emitSlow_op_tail_call_varargs): (JSC::JIT::emitSlow_op_tail_call_forward_arguments): (JSC::JIT::emitSlow_op_construct_varargs): (JSC::JIT::emitSlow_op_construct): (JSC::JIT::emit_op_call): (JSC::JIT::emit_op_tail_call): (JSC::JIT::emit_op_call_eval): (JSC::JIT::emit_op_call_varargs): (JSC::JIT::emit_op_tail_call_varargs): (JSC::JIT::emit_op_tail_call_forward_arguments): (JSC::JIT::emit_op_construct_varargs): (JSC::JIT::emit_op_construct): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileCallEval): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCall): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::compileSetupVarargsFrame): Deleted. * jit/JITInlines.h: (JSC::JIT::updateTopCallFrame): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): (JSC::JIT::emitSlow_op_loop_hint): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emit_op_instanceof_custom): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emit_op_neq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::compileOpStrictEq): (JSC::JIT::emit_op_stricteq): (JSC::JIT::emit_op_nstricteq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emit_op_jstricteq): (JSC::JIT::emit_op_jnstricteq): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_identity_with_profile): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_debug): (JSC::JIT::emit_op_enter): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emit_op_has_structure_property): (JSC::JIT::privateCompileHasIndexedProperty): (JSC::JIT::emit_op_has_indexed_property): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emit_op_enumerator_structure_pname): (JSC::JIT::emit_op_enumerator_generic_pname): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val_direct): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): * jit/RegisterSet.cpp: (JSC::RegisterSet::vmCalleeSaveRegisters): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * runtime/SamplingProfiler.cpp: (JSC::tryGetBytecodeIndex): 2018-11-20 Saam barati <sbarati@apple.com> Merging an IC variant may lead to the IC status containing overlapping structure sets https://bugs.webkit.org/show_bug.cgi?id=191869 <rdar://problem/45403453> Reviewed by Mark Lam. When merging two IC variant lists, we may end up in a world where we have overlapping structure sets. We defend against this when we append a new variant, but we should also defend against it once we merge in a new variant. Consider this case with MultiPutByOffset, where we merge two PutByIdStatuses together, P1 and P2. Let's consider these structures: s1 = {} s2 = {p: 0} s3 = {p: 0, p2: 1} P1 contains these variants: Transition: [s1 => s2] Replace: [s2, s3] P2 contains: Replace: [s2] Because of the ordering of the variants, we may end up combining P2's replace into P1's transition, forming this new list: Transition: [(s1, s2) => s2] Replace: [s2, s3] Obviously the ideal thing here is to have some ordering when we merge in variants to choose the most ideal option. It'd be ideal for P2's Replace to be merged into P1's replace. If we notice that this is super important, we can implement some kind of ordering. None of our tests (until this patch) stress this. This patch just makes it so we defend against this crazy scenario by falling back to the slow path gracefully. This prevents us from emitting invalid IR in FTL->B3 lowering by creating a switch with two case labels being identical values. * bytecode/ICStatusUtils.h: (JSC::appendICStatusVariant): 2018-11-20 Fujii Hironori <Hironori.Fujii@sony.com> REGRESSION(r238039) WebCore::JSDOMGlobalObject::createStructure is using JSC::Structure::create without including StructureInlines.h https://bugs.webkit.org/show_bug.cgi?id=191626 <rdar://problem/46161064> Unreviewed adding comment for my change r238366. * runtime/Structure.h: Added a comment for Structure::create. 2018-11-19 Mark Lam <mark.lam@apple.com> globalFuncImportModule() should return a promise when it clears exceptions. https://bugs.webkit.org/show_bug.cgi?id=191792 <rdar://problem/46090763> Reviewed by Michael Saboff. If we're clearing the exceptions in a CatchScope, then it means that we've handled the exception, and is able to proceed in a normal manner. Hence, we should not return the empty JSValue in this case: instead, we should return a Promise as expected by import's API. The only time when we can't return a promise is when we fail to create a Promise. In that case, we should be propagating the exception. Hence, globalFuncImportModule() contains a ThrowScope (for propagating the exception that arises from failure to create the Promise) wrapping a CatchScope (for catching any exception that arises from failure to execute the import). Also fixed similar issues, and some exception check issues in JSModuleLoader and the jsc shell. * jsc.cpp: (GlobalObject::moduleLoaderImportModule): (GlobalObject::moduleLoaderFetch): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncImportModule): * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::loadAndEvaluateModule): (JSC::JSModuleLoader::loadModule): (JSC::JSModuleLoader::requestImportModule): (JSC::JSModuleLoader::importModule): (JSC::JSModuleLoader::resolve): (JSC::JSModuleLoader::fetch): (JSC::moduleLoaderParseModule): (JSC::moduleLoaderResolveSync): 2018-11-19 Alex Christensen <achristensen@webkit.org> Add SPI to disable JIT in a WKWebView https://bugs.webkit.org/show_bug.cgi?id=191822 <rdar://problem/28119360> Reviewed by Geoffrey Garen. * jit/ExecutableAllocator.cpp: (JSC::jitDisabled): (JSC::allowJIT): (JSC::ExecutableAllocator::setJITEnabled): * jit/ExecutableAllocator.h: (JSC::ExecutableAllocator::setJITEnabled): 2018-11-19 Fujii Hironori <Hironori.Fujii@sony.com> [MSVC] X86Assembler.h(108): error C2666: 'WebCore::operator -': 7 overloads have similar conversions https://bugs.webkit.org/show_bug.cgi?id=189467 <rdar://problem/44290945> Reviewed by Mark Lam. This issue has happened several times. And, it seems that it will take more time for Microsoft to fix the MSVC bug. We need a effective workaround not to repeat this issue until they fix MSVC. Remove ": int8_t" of RegisterID only for COMPILER(MSVC). * assembler/X86Assembler.h: Added JSC_X86_ASM_REGISTER_ID_ENUM_BASE_TYPE macro. 2018-11-19 Yusuke Suzuki <yusukesuzuki@slowstart.org> [WebAssembly] I64 arguments / return value check should be moved from callWebAssemblyFunction to JSToWasm wrapper https://bugs.webkit.org/show_bug.cgi?id=190512 Reviewed by Keith Miller. This patch moves I64 arguments / return value check from callWebAssemblyFunction to JSToWasm wrapper. Since this check can be done when compiling the function, we should encode the result into the generated wrapper instead of checking every time we call callWebAssemblyFunction. This change is also one of the steps removing callWebAssemblyFunction entirely. * wasm/WasmExceptionType.h: * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::callWebAssemblyWrapperFunction): 2018-11-12 Yusuke Suzuki <yusukesuzuki@slowstart.org> Consider removing double load for accessing the instructions from LLInt https://bugs.webkit.org/show_bug.cgi?id=190932 Reviewed by Mark Lam. Changing InstructionStream to RefCountedArray like structure involves so much changes including BytecodeGraph, PreciseJumpTargets etc. Instead, CodeBlock simply hold a raw pointer to the InstructionStream's data. Since InstructionStream is not changed anymore, this pointer is valid while CodeBlock is live. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): * bytecode/CodeBlock.h: * bytecode/InstructionStream.h: (JSC::InstructionStream::rawPointer const): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2018-11-18 Fujii Hironori <Hironori.Fujii@sony.com> REGRESSION(r238039) WebCore::JSDOMGlobalObject::createStructure is using JSC::Structure::create without including StructureInlines.h https://bugs.webkit.org/show_bug.cgi?id=191626 Reviewed by Yusuke Suzuki. JSC::Structure::create is used everywhere. It should be defined in Structure.h, not in StructureInlines.h. * runtime/Structure.h: (JSC::Structure::create): Moved. * runtime/StructureInlines.h: Moved JSC::Structure::create. 2018-11-18 Yusuke Suzuki <yusukesuzuki@slowstart.org> Unreviewed, rolling in the rest of r237254 https://bugs.webkit.org/show_bug.cgi?id=190340 * parser/ParserModes.h: * parser/ParserTokens.h: (JSC::JSTextPosition::JSTextPosition): (JSC::JSTokenLocation::JSTokenLocation): Deleted. * runtime/CodeCache.cpp: (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): 2018-11-17 Devin Rousso <drousso@apple.com> Web Inspector: Network: add button to show system certificate dialog https://bugs.webkit.org/show_bug.cgi?id=191458 <rdar://problem/45977019> Reviewed by Joseph Pecoraro. * inspector/protocol/Network.json: Add `getSerializedCertificate` command. 2018-11-17 Dominik Infuehr <dinfuehr@igalia.com> Fix build with disabled DFG/FTL https://bugs.webkit.org/show_bug.cgi?id=191256 Reviewed by Yusuke Suzuki. Fix compilation errors and warnings with both DFG and FTL disabled at compile-time. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::getICStatusMap): * bytecode/InByIdStatus.cpp: (JSC::InByIdStatus::computeFor): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): (JSC::PutByIdStatus::hasExitSite): Deleted. * bytecode/PutByIdStatus.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): 2018-11-16 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Keep Web Inspector window alive across process swaps (PSON) (Local Inspector) https://bugs.webkit.org/show_bug.cgi?id=191740 <rdar://problem/45470897> Reviewed by Timothy Hatcher. * inspector/InspectorFrontendChannel.h: Expose EnumTraits for ConnectionType for WebKit IPC messages. 2018-11-16 Filip Pizlo <fpizlo@apple.com> All users of ArrayBuffer should agree on the same max size https://bugs.webkit.org/show_bug.cgi?id=191771 Reviewed by Mark Lam. Array buffers cannot be larger than 0x7fffffff, because otherwise loading typedArray.length in the DFG/FTL would produce a uint32 or would require a signedness check, neither of which sounds reasonable. It's better to just bound their max size instead. * runtime/ArrayBuffer.cpp: (JSC::ArrayBufferContents::ArrayBufferContents): (JSC::ArrayBufferContents::tryAllocate): (JSC::ArrayBufferContents::transferTo): (JSC::ArrayBufferContents::copyTo): (JSC::ArrayBufferContents::shareWith): * runtime/ArrayBuffer.h: * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::tryCreate): (JSC::Wasm::Memory::grow): * wasm/WasmPageCount.h: 2018-11-16 Saam Barati <sbarati@apple.com> KnownCellUse should also have SpecCellCheck as its type filter https://bugs.webkit.org/show_bug.cgi?id=191729 <rdar://problem/45872852> Reviewed by Filip Pizlo. We write transformations in the compiler like this where we emit edges with KnownCellUse if we know we're inserting code at a point where we're dominated by a Cell check: a: SomeValue b: Something(Cell:@a) c: SomethingElse(@b) d: CheckNotEmpty(@a) => a: SomeValue b: Something(Cell:@a) e: RandomOtherThing(KnownCellUse:@a) c: SomethingElse(@b) d: CheckNotEmpty(@a) However, doing this used to lead to subtly incorrect programs since KnownCellUse did not allow the empty value to flow through it. We used to end up incorrectly deleting @d in the above program. We fix this, we make KnownCellUse allow the empty value to flow through. * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): 2018-11-16 Tadeu Zagallo <tzagallo@apple.com> Fix assertion failure on BytecodeGenerator::recordOpcode https://bugs.webkit.org/show_bug.cgi?id=191724 <rdar://problem/45724395> Reviewed by Saam Barati. Since https://bugs.webkit.org/show_bug.cgi?id=187373, we were not restoring m_lastInstruction after patching the bytecode when finalizing StructureForInContexts, only m_lastOpcodeID, which led to the assertion failure. * bytecompiler/BytecodeGenerator.cpp: (JSC::StructureForInContext::finalize): 2018-11-15 Mark Lam <mark.lam@apple.com> RegExpObject's collectMatches should not be using JSArray::push to fill in its match results. https://bugs.webkit.org/show_bug.cgi?id=191730 <rdar://problem/46048517> Reviewed by Saam Barati. According to the spec https://www.ecma-international.org/ecma-262/9.0/index.html#sec-regexp.prototype-@@match, the RegExp match results are filled in using the spec's CreateDataProperty() function which does not consult the prototype for setters. JSArray:push() consults the prototype for setters. We should be using putDirectIndex() instead. * runtime/RegExpObjectInlines.h: (JSC::collectMatches): 2018-11-15 Mark Lam <mark.lam@apple.com> RegExp operations should not take fast patch if lastIndex is not numeric. https://bugs.webkit.org/show_bug.cgi?id=191731 <rdar://problem/46017305> Reviewed by Saam Barati. This is because if lastIndex is an object with a valueOf() method, it can execute arbitrary code which may have side effects, and side effects are not permitted by the RegExp fast paths. * builtins/RegExpPrototype.js: (globalPrivate.hasObservableSideEffectsForRegExpMatch): (overriddenName.string_appeared_here.search): (globalPrivate.hasObservableSideEffectsForRegExpSplit): (intrinsic.RegExpTestIntrinsic.test): * builtins/StringPrototype.js: (globalPrivate.hasObservableSideEffectsForStringReplace): 2018-11-15 Keith Rollin <krollin@apple.com> Delete old .xcfilelist files https://bugs.webkit.org/show_bug.cgi?id=191669 <rdar://problem/46081994> Reviewed by Chris Dumez. .xcfilelist files were created and added to the Xcode project files in https://trac.webkit.org/changeset/238008/webkit. However, they caused build issues and they were removed from the Xcode projects in https://trac.webkit.org/changeset/238055/webkit. This check-in removes the files from the repository altogether. They'll ultimately be replaced with new files with names that indicate whether the associated files are inputs to the Run Script phase or are files created by the Run Script phase. * DerivedSources.xcfilelist: Removed. * UnifiedSources.xcfilelist: Removed. 2018-11-14 Keith Rollin <krollin@apple.com> Move scripts for Derived and Unified Sources to external files https://bugs.webkit.org/show_bug.cgi?id=191670 <rdar://problem/46082278> Reviewed by Keith Miller. Move the scripts in the Generate Derived Sources and Generate Unified Sources Run Script phases from the Xcode projects to external shell script files. Then invoke those scripts from the Run Script phases. This refactoring is being performed to support later work that will invoke these scripts in other contexts. The scripts were maintained as-is when making the move. I did a little reformatting and added 'set -e' to the top of each file, but that's it. * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/generate-derived-sources.sh: Added. * Scripts/generate-unified-sources.sh: Added. 2018-11-14 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Pass Inspector::FrontendChannel as a reference connect/disconnect methods https://bugs.webkit.org/show_bug.cgi?id=191612 Reviewed by Matt Baker. * inspector/InspectorFrontendRouter.cpp: (Inspector::FrontendRouter::connectFrontend): (Inspector::FrontendRouter::disconnectFrontend): * inspector/InspectorFrontendRouter.h: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::connectFrontend): (Inspector::JSGlobalObjectInspectorController::disconnectFrontend): * inspector/JSGlobalObjectInspectorController.h: * inspector/remote/RemoteControllableTarget.h: * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm: (Inspector::RemoteConnectionToTarget::setup): (Inspector::RemoteConnectionToTarget::close): * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: (Inspector::RemoteConnectionToTarget::setup): (Inspector::RemoteConnectionToTarget::close): * runtime/JSGlobalObjectDebuggable.cpp: (JSC::JSGlobalObjectDebuggable::connect): (JSC::JSGlobalObjectDebuggable::disconnect): * runtime/JSGlobalObjectDebuggable.h: 2018-11-14 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Keep Web Inspector window alive across process swaps (PSON) (Remote Inspector) https://bugs.webkit.org/show_bug.cgi?id=191494 <rdar://problem/45469854> Reviewed by Devin Rousso. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: New domain and resources. * inspector/protocol/Target.json: Added. New protocol domain, modeled after Worker.json, to allow for multiplexing between different targets. * inspector/InspectorTarget.h: Each target will instantiate an InspectorTarget and must provide an identifier, type, and means of connecting/disconnecting to a frontend channel. * inspector/agents/InspectorTargetAgent.cpp: Added. (Inspector::InspectorTargetAgent::InspectorTargetAgent): (Inspector::InspectorTargetAgent::didCreateFrontendAndBackend): (Inspector::InspectorTargetAgent::willDestroyFrontendAndBackend): (Inspector::InspectorTargetAgent::exists): (Inspector::InspectorTargetAgent::initialized): (Inspector::InspectorTargetAgent::sendMessageToTarget): (Inspector::InspectorTargetAgent::sendMessageFromTargetToFrontend): (Inspector::targetTypeToProtocolType): (Inspector::buildTargetInfoObject): (Inspector::InspectorTargetAgent::targetCreated): (Inspector::InspectorTargetAgent::targetTerminated): (Inspector::InspectorTargetAgent::connectToTargets): (Inspector::InspectorTargetAgent::disconnectFromTargets): * inspector/agents/InspectorTargetAgent.h: Added. TargetAgent holds a list of targets, and connects/disconnects to each of the targets when a frontend connects/disconnects. * inspector/scripts/codegen/generator.py: Better enum casing of ServiceWorker. 2018-11-14 Yusuke Suzuki <yusukesuzuki@slowstart.org> Unreviewed, rolling in CodeCache in r237254 https://bugs.webkit.org/show_bug.cgi?id=190340 Land the CodeCache part without adding an additional hash value. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::fromGlobalCode): * bytecode/UnlinkedFunctionExecutable.h: * parser/SourceCodeKey.h: (JSC::SourceCodeKey::SourceCodeKey): (JSC::SourceCodeKey::operator== const): * runtime/CodeCache.cpp: (JSC::CodeCache::getUnlinkedGlobalCodeBlock): (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): * runtime/CodeCache.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::fromGlobalCode): * runtime/FunctionExecutable.h: 2018-11-13 Saam Barati <sbarati@apple.com> ProxyObject should check for VMInquiry and return early before throwing a stack overflow exception https://bugs.webkit.org/show_bug.cgi?id=191601 Reviewed by Mark Lam. This doesn't fix any bugs today, but it may reduce future bugs. It was always weird that ProxyObject::getOwnPropertySlot with VMInquiry might throw a stack overflow error instead of just returning false like it normally does when VMInquiry is passed in. * runtime/ProxyObject.cpp: (JSC::ProxyObject::getOwnPropertySlotCommon): 2018-11-13 Saam Barati <sbarati@apple.com> TypeProfileLog::processLogEntries should stash away any pending exceptions and re-apply them to the VM https://bugs.webkit.org/show_bug.cgi?id=191600 Reviewed by Mark Lam. processLogEntries will call into calculatedClassName, which will clear any exceptions it encounters (it assumes that they're stack overflow exceptions). However, this code may be called when an exception is already pending on the VM (e.g, when we throw an exception in the DFG, we compile an OSR exit offramp, which may compile a baseline codeblock, which will process the type profiler log). To get around this, processLogEntires should stash away and re-apply any pending exceptions. * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGOperations.cpp: * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets): * jit/JIT.cpp: (JSC::JIT::doMainThreadPreparationBeforeCompile): * jit/JITOperations.cpp: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/TypeProfilerLog.cpp: (JSC::TypeProfilerLog::processLogEntries): * runtime/TypeProfilerLog.h: * runtime/VM.cpp: (JSC::VM::dumpTypeProfilerData): * runtime/VM.h: (JSC::VM::DeferExceptionScope::DeferExceptionScope): * tools/JSDollarVM.cpp: (JSC::functionFindTypeForExpression): (JSC::functionReturnTypeFor): 2018-11-13 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r238132. The test added with this change is timing out on Debug JSC bots. Reverted changeset: "[BigInt] JSBigInt::createWithLength should throw when length is greater than JSBigInt::maxLength" https://bugs.webkit.org/show_bug.cgi?id=190836 https://trac.webkit.org/changeset/238132 2018-11-12 Mark Lam <mark.lam@apple.com> Add OOM detection to StringPrototype's substituteBackreferences(). https://bugs.webkit.org/show_bug.cgi?id=191563 <rdar://problem/45720428> Reviewed by Saam Barati. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * runtime/StringPrototype.cpp: (JSC::substituteBackreferencesSlow): (JSC::substituteBackreferencesInline): (JSC::substituteBackreferences): (JSC::replaceUsingRegExpSearch): (JSC::replaceUsingStringSearch): * runtime/StringPrototype.h: 2018-11-13 Mark Lam <mark.lam@apple.com> LLIntSlowPath's llint_loop_osr and llint_replace should set the topCallFrame. https://bugs.webkit.org/show_bug.cgi?id=191579 <rdar://problem/45942472> Reviewed by Saam Barati. Both of these functions do a lot of work. It would be good for the topCallFrame to be correct should we need to throw an exception. For example, we've observed the following crash trace: * frame #0: WTFCrash() at Assertions.cpp:253 frame #1: ... frame #2: JSC::StructureIDTable::get(this=0x00006040000162f0, structureID=1874583248) at StructureIDTable.h:129 frame #3: JSC::VM::getStructure(this=0x0000604000016210, id=4022066896) at VM.h:705 frame #4: JSC::JSCell::structure(this=0x00007ffeefbbde30, vm=0x0000604000016210) const at JSCellInlines.h:125 frame #5: JSC::JSCell::classInfo(this=0x00007ffeefbbde30, vm=0x0000604000016210) const at JSCellInlines.h:335 frame #6: JSC::JSCell::inherits(this=0x00007ffeefbbde30, vm=0x0000604000016210, info=0x0000000105eaf020) const at JSCellInlines.h:302 frame #7: JSC::JSObject* JSC::jsCast<JSC::JSObject*, JSC::JSCell>(from=0x00007ffeefbbde30) at JSCast.h:36 frame #8: JSC::asObject(cell=0x00007ffeefbbde30) at JSObject.h:1299 frame #9: JSC::asObject(value=JSValue @ 0x00007ffeefbba380) at JSObject.h:1304 frame #10: JSC::Register::object(this=0x00007ffeefbbdd58) const at JSObject.h:1514 frame #11: JSC::ExecState::jsCallee(this=0x00007ffeefbbdd40) const at CallFrame.h:107 frame #12: JSC::ExecState::isStackOverflowFrame(this=0x00007ffeefbbdd40) const at CallFrameInlines.h:36 frame #13: JSC::StackVisitor::StackVisitor(this=0x00007ffeefbba860, startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800) at StackVisitor.cpp:52 frame #14: JSC::StackVisitor::StackVisitor(this=0x00007ffeefbba860, startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800) at StackVisitor.cpp:41 frame #15: void JSC::StackVisitor::visit<(JSC::StackVisitor::EmptyEntryFrameAction)0, JSC::Interpreter::getStackTrace(JSC::JSCell*, WTF::Vector<JSC::StackFrame, 0ul, WTF::CrashOnOverflow, 16ul>&, unsigned long, unsigned long)::$_3>(startFrame=0x00007ffeefbbdd40, vm=0x0000631000000800, functor=0x00007ffeefbbaa60)::$_3 const&) at StackVisitor.h:147 frame #16: JSC::Interpreter::getStackTrace(this=0x0000602000005db0, owner=0x000062d00020cbe0, results=0x00006020000249d0, framesToSkip=0, maxStackSize=1) at Interpreter.cpp:437 frame #17: JSC::getStackTrace(exec=0x000062d00002c048, vm=0x0000631000000800, obj=0x000062d00020cbe0, useCurrentFrame=true) at Error.cpp:170 frame #18: JSC::ErrorInstance::finishCreation(this=0x000062d00020cbe0, exec=0x000062d00002c048, vm=0x0000631000000800, message=0x00007ffeefbbb800, useCurrentFrame=true) at ErrorInstance.cpp:119 frame #19: JSC::ErrorInstance::create(exec=0x000062d00002c048, vm=0x0000631000000800, structure=0x000062d0000f5730, message=0x00007ffeefbbb800, appender=0x0000000000000000, type=TypeNothing, useCurrentFrame=true)(WTF::String const&, WTF::String const&, JSC::RuntimeType, JSC::ErrorInstance::SourceTextWhereErrorOccurred), JSC::RuntimeType, bool) at ErrorInstance.h:49 frame #20: JSC::createRangeError(exec=0x000062d00002c048, globalObject=0x000062d00002c000, message=0x00007ffeefbbb800, appender=0x0000000000000000)(WTF::String const&, WTF::String const&, JSC::RuntimeType, JSC::ErrorInstance::SourceTextWhereErrorOccurred)) at Error.cpp:68 frame #21: JSC::createRangeError(exec=0x000062d00002c048, globalObject=0x000062d00002c000, message=0x00007ffeefbbb800) at Error.cpp:316 frame #22: JSC::createStackOverflowError(exec=0x000062d00002c048, globalObject=0x000062d00002c000) at ExceptionHelpers.cpp:77 frame #23: JSC::createStackOverflowError(exec=0x000062d00002c048) at ExceptionHelpers.cpp:72 frame #24: JSC::throwStackOverflowError(exec=0x000062d00002c048, scope=0x00007ffeefbbbaa0) at ExceptionHelpers.cpp:335 frame #25: JSC::ProxyObject::getOwnPropertySlotCommon(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbba80, slot=0x00007ffeefbbc720) at ProxyObject.cpp:372 frame #26: JSC::ProxyObject::getOwnPropertySlot(object=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbbd40, slot=0x00007ffeefbbc720) at ProxyObject.cpp:395 frame #27: JSC::JSObject::getNonIndexPropertySlot(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbbea0, slot=0x00007ffeefbbc720) at JSObjectInlines.h:150 frame #28: bool JSC::JSObject::getPropertySlot<false>(this=0x000062d000200e40, exec=0x000062d00002c048, propertyName=PropertyName @ 0x00007ffeefbbc320, slot=0x00007ffeefbbc720) at JSObject.h:1424 frame #29: JSC::JSObject::calculatedClassName(object=0x000062d000200e40) at JSObject.cpp:535 frame #30: JSC::Structure::toStructureShape(this=0x000062d000007410, value=JSValue @ 0x00007ffeefbbcae0, sawPolyProtoStructure=0x00007ffeefbbcf60) at Structure.cpp:1142 frame #31: JSC::TypeProfilerLog::processLogEntries(this=0x000060400000a950, reason=0x00007ffeefbbd5c0) at TypeProfilerLog.cpp:89 frame #32: JSC::JIT::doMainThreadPreparationBeforeCompile(this=0x0000619000034da0) at JIT.cpp:951 frame #33: JSC::JITWorklist::Plan::Plan(this=0x0000619000034d80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:43 frame #34: JSC::JITWorklist::Plan::Plan(this=0x0000619000034d80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:42 frame #35: JSC::JITWorklist::compileLater(this=0x0000616000001b80, codeBlock=0x000062d0001d88c0, loopOSREntryBytecodeOffset=0) at JITWorklist.cpp:256 frame #36: JSC::LLInt::jitCompileAndSetHeuristics(codeBlock=0x000062d0001d88c0, exec=0x00007ffeefbbde30, loopOSREntryBytecodeOffset=0) at LLIntSlowPaths.cpp:391 frame #37: llint_replace(exec=0x00007ffeefbbde30, pc=0x00006040000161ba) at LLIntSlowPaths.cpp:516 frame #38: llint_entry at LowLevelInterpreter64.asm:98 frame #39: vmEntryToJavaScript at LowLevelInterpreter64.asm:296 ... This crash occurred because StackVisitor was seeing an invalid topCallFrame while trying to capture the Error stack while throwing a StackOverflowError below llint_replace. While in this specific example, it is questionable whether we should be executing JS code below TypeProfilerLog::processLogEntries(), it is correct to have set the topCallFrame in llint_replace. We do this by calling LLINT_BEGIN_NO_SET_PC() at the top of llint_replace. We also do the same for llint_osr. Note: both of these LLInt slow path functions are called with a fully initialized CallFrame. Hence, there's no issue with setting topCallFrame to their CallFrames for these functions. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): 2018-11-13 Caio Lima <ticaiolima@gmail.com> [BigInt] JSBigInt::createWithLength should throw when length is greater than JSBigInt::maxLength https://bugs.webkit.org/show_bug.cgi?id=190836 Reviewed by Saam Barati. In this patch we are creating a new method called `JSBigInt::createWithLengthUnchecked` where we allocate a BigInt trusting the length received as argument. With this additional method, we now check if length passed to `JSBigInt::createWithLength` is not greater than JSBigInt::maxLength. When the length is greater than maxLength, we then throw OOM exception. This required change the interface of some JSBigInt operations to receive `ExecState*` instead of `VM&`. We changed only operations that can throw because of OOM. We beleive that this approach of throwing instead of finishing the execution abruptly is better because JS programs can catch such exception and handle this issue properly. * dfg/DFGOperations.cpp: * jit/JITOperations.cpp: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSBigInt.cpp: (JSC::JSBigInt::createZero): (JSC::JSBigInt::tryCreateWithLength): (JSC::JSBigInt::createWithLengthUnchecked): (JSC::JSBigInt::createFrom): (JSC::JSBigInt::multiply): (JSC::JSBigInt::divide): (JSC::JSBigInt::copy): (JSC::JSBigInt::unaryMinus): (JSC::JSBigInt::remainder): (JSC::JSBigInt::add): (JSC::JSBigInt::sub): (JSC::JSBigInt::bitwiseAnd): (JSC::JSBigInt::bitwiseOr): (JSC::JSBigInt::bitwiseXor): (JSC::JSBigInt::absoluteAdd): (JSC::JSBigInt::absoluteSub): (JSC::JSBigInt::absoluteDivWithDigitDivisor): (JSC::JSBigInt::absoluteDivWithBigIntDivisor): (JSC::JSBigInt::absoluteLeftShiftAlwaysCopy): (JSC::JSBigInt::absoluteBitwiseOp): (JSC::JSBigInt::absoluteAddOne): (JSC::JSBigInt::absoluteSubOne): (JSC::JSBigInt::toStringGeneric): (JSC::JSBigInt::rightTrim): (JSC::JSBigInt::allocateFor): (JSC::JSBigInt::createWithLength): Deleted. * runtime/JSBigInt.h: * runtime/Operations.cpp: (JSC::jsAddSlowCase): * runtime/Operations.h: (JSC::jsSub): (JSC::jsMul): 2018-11-12 Devin Rousso <drousso@apple.com> Web Inspector: Network: show secure certificate details per-request https://bugs.webkit.org/show_bug.cgi?id=191447 <rdar://problem/30019476> Reviewed by Joseph Pecoraro. Add Security domain to hold security related protocol types. * CMakeLists.txt: * DerivedSources.make: * inspector/protocol/Network.json: * inspector/protocol/Security.json: Added. * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator): 2018-11-12 Saam barati <sbarati@apple.com> Unreviewed. Rollout 238026: It caused ~8% JetStream 2 regressions on some iOS devices https://bugs.webkit.org/show_bug.cgi?id=191555 * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::fromGlobalCode): * bytecode/UnlinkedFunctionExecutable.h: * parser/SourceCodeKey.h: (JSC::SourceCodeKey::SourceCodeKey): (JSC::SourceCodeKey::operator== const): * runtime/CodeCache.cpp: (JSC::CodeCache::getUnlinkedGlobalCodeBlock): (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): * runtime/CodeCache.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::fromGlobalCode): * runtime/FunctionExecutable.h: 2018-11-11 Benjamin Poulain <benjamin@webkit.org> Fix a fixme: rename wtfObjcMsgSend to wtfObjCMsgSend https://bugs.webkit.org/show_bug.cgi?id=191492 Reviewed by Alex Christensen. Rename file. * API/JSValue.mm: 2018-11-10 Benjamin Poulain <benjamin@webkit.org> Fix a fixme: rename wtfObjcMsgSend to wtfObjCMsgSend https://bugs.webkit.org/show_bug.cgi?id=191492 Reviewed by Alex Christensen. * API/JSValue.mm: 2018-11-10 Michael Catanzaro <mcatanzaro@igalia.com> Unreviewed, silence -Wunused-variable warning * bytecode/Opcode.h: (JSC::padOpcodeName): 2018-11-09 Keith Rollin <krollin@apple.com> Unreviewed build fix after https://bugs.webkit.org/show_bug.cgi?id=191324 Remove the use of .xcfilelists until their side-effects are better understood. * JavaScriptCore.xcodeproj/project.pbxproj: 2018-11-09 Keith Miller <keith_miller@apple.com> LLInt VectorSizeOffset should be based on offset extraction https://bugs.webkit.org/show_bug.cgi?id=191468 Reviewed by Yusuke Suzuki. This patch also adds some usings to LLIntOffsetsExtractor that make it possible to use the bare names of Vector/RefCountedArray in offsets extraction. * llint/LLIntOffsetsExtractor.cpp: * llint/LowLevelInterpreter.asm: 2018-11-09 Yusuke Suzuki <yusukesuzuki@slowstart.org> Unreviewed, rolling in CodeCache in r237254 https://bugs.webkit.org/show_bug.cgi?id=190340 Land the CodeCache part, which uses DefaultHash<>::Hash instead of computeHash. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::fromGlobalCode): * bytecode/UnlinkedFunctionExecutable.h: * parser/SourceCodeKey.h: (JSC::SourceCodeKey::SourceCodeKey): (JSC::SourceCodeKey::operator== const): * runtime/CodeCache.cpp: (JSC::CodeCache::getUnlinkedGlobalCodeBlock): (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): * runtime/CodeCache.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::fromGlobalCode): * runtime/FunctionExecutable.h: 2018-11-08 Keith Miller <keith_miller@apple.com> put_by_val opcodes need to add the number tag as a 64-bit register https://bugs.webkit.org/show_bug.cgi?id=191456 Reviewed by Saam Barati. Previously the LLInt would add it as a pointer sized value. That is wrong if pointer size is less 64-bits. * llint/LowLevelInterpreter64.asm: 2018-11-08 Ross Kirsling <ross.kirsling@sony.com> [JSC] isStrWhiteSpace seems redundant with Lexer<UChar>::isWhiteSpace https://bugs.webkit.org/show_bug.cgi?id=191439 Reviewed by Saam Barati. * CMakeLists.txt: * runtime/ParseInt.h: (JSC::isStrWhiteSpace): Define isStrWhiteSpace in terms of isWhiteSpace and isLineTerminator. 2018-11-08 Michael Saboff <msaboff@apple.com> Options::useRegExpJIT() should use jitEnabledByDefault() just like useJIT() https://bugs.webkit.org/show_bug.cgi?id=191444 Reviewed by Saam Barati. * runtime/Options.h: 2018-11-08 Fujii Hironori <Hironori.Fujii@sony.com> [Win] UDis86Disassembler.cpp: warning: format specifies type 'unsigned long' but the argument has type 'uintptr_t' (aka 'unsigned long long') https://bugs.webkit.org/show_bug.cgi?id=191416 Reviewed by Saam Barati. * disassembler/UDis86Disassembler.cpp: (JSC::tryToDisassembleWithUDis86): Use PRIxPTR for uintptr_t. 2018-11-08 Keith Rollin <krollin@apple.com> Create .xcfilelist files https://bugs.webkit.org/show_bug.cgi?id=191324 <rdar://problem/45852819> Reviewed by Alex Christensen. As part of preparing for enabling XCBuild, create and use .xcfilelist files. These files are using during Run Script build phases in an Xcode project. If a Run Script build phase produces new files that are used later as inputs to subsequent build phases, XCBuild needs to know about these files. These files can be either specified in an "output files" section of the Run Script phase editor, or in .xcfilelist files that are associated with the Run Script build phase. This patch takes the second approach. It consists of three sets of changes: - Modify the DerivedSources.make files to have a 'print_all_generated_files" target that produces a list of the files they create. - Create a shell script that produces .xcfilelist files from the output of the previous step, as well as for the files created in the Generate Unified Sources build steps. - Add the new .xcfilelist files to the associated projects. Note that, with these changes, the Xcode workspace and projects can no longer be fully loaded into Xcode 9. Xcode will attempt to load the projects that have .xcfilelist files associated with them, but will fail and display a placeholder for those projects instead. It's expected that all developers are using Xcode 10 by now and that not being able to load into Xcode 9 is not a practical issue. Keep in mind that this is strictly an IDE issue, and that the projects can still be built with `xcodebuild`. Also note that the shell script that creates the .xcfilelist files can also be used to verify that the set of files that's currently checked in is up-to-date. This checking can be used as part of a check-in hook or part of check-webkit-style to sooner catch cases where the .xcfilelist files need to be regenerated. * DerivedSources.make: * DerivedSources.xcfilelist: Added. * JavaScriptCore.xcodeproj/project.pbxproj: * UnifiedSources.xcfilelist: Added. 2018-11-08 Ross Kirsling <ross.kirsling@sony.com> U+180E is no longer a whitespace character https://bugs.webkit.org/show_bug.cgi?id=191415 Reviewed by Saam Barati. Mongolian Vowel Separator stopped being a valid whitespace character as of ES2016. (https://github.com/tc39/ecma262/pull/300) * parser/Lexer.h: (JSC::Lexer<UChar>::isWhiteSpace): * runtime/ParseInt.h: (JSC::isStrWhiteSpace): * yarr/create_regex_tables: 2018-11-08 Keith Miller <keith_miller@apple.com> jitEnabledByDefault() should be on useJIT not useBaselineJIT https://bugs.webkit.org/show_bug.cgi?id=191434 Reviewed by Saam Barati. * runtime/Options.h: 2018-11-08 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Restrict domains at the target level instead of only at the window level https://bugs.webkit.org/show_bug.cgi?id=191344 Reviewed by Devin Rousso. * inspector/protocol/Console.json: * inspector/protocol/Debugger.json: * inspector/protocol/Heap.json: * inspector/protocol/Runtime.json: Remove workerSupported as it is now no longer necessary. It is implied by availability being empty (meaning it is supported everywhere). * inspector/protocol/Inspector.json: * inspector/protocol/ScriptProfiler.json: Restrict to "javascript" and "web" debuggables, not available in workers. * inspector/protocol/Worker.json: Cleanup, remove empty types list. * inspector/protocol/Recording.json: Cleanup, only expose this in the "web" domain for now. * inspector/scripts/codegen/generate_js_backend_commands.py: (JSBackendCommandsGenerator.generate_domain): * inspector/scripts/codegen/models.py: (Protocol.parse_domain): Allow a list of debuggable types. Add "worker" even though it is unused since that is a type we would want to allow or consider. (Domain.__init__): (Domains): Remove now unnecessary workerSupported code. Allow availability on a domain with only types. * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: Removed. * inspector/scripts/tests/generic/worker-supported-domains.json: Removed. 2018-11-07 Yusuke Suzuki <yusukesuzuki@slowstart.org> Consider removing double load for accessing the MetadataTable from LLInt https://bugs.webkit.org/show_bug.cgi?id=190933 Reviewed by Keith Miller. This patch removes double load for accesses to MetadataTable from LLInt. MetadataTable is now specially RefCounted class, which has interesting memory layout. When refcount becomes 0, MetadataTable asks UnlinkedMetadataTable to destroy itself. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::estimatedSize): (JSC::CodeBlock::visitChildren): * bytecode/CodeBlock.h: (JSC::CodeBlock::metadata): * bytecode/CodeBlockInlines.h: (JSC::CodeBlock::forEachValueProfile): (JSC::CodeBlock::forEachArrayProfile): (JSC::CodeBlock::forEachArrayAllocationProfile): (JSC::CodeBlock::forEachObjectAllocationProfile): (JSC::CodeBlock::forEachLLIntCallLinkInfo): * bytecode/MetadataTable.cpp: (JSC::MetadataTable::MetadataTable): (JSC::MetadataTable::~MetadataTable): (JSC::MetadataTable::sizeInBytes): * bytecode/MetadataTable.h: (JSC::MetadataTable::get): (JSC::MetadataTable::forEach): (JSC::MetadataTable::ref const): (JSC::MetadataTable::deref const): (JSC::MetadataTable::refCount const): (JSC::MetadataTable::hasOneRef const): (JSC::MetadataTable::buffer): (JSC::MetadataTable::linkingData const): (JSC::MetadataTable::getImpl): * bytecode/UnlinkedMetadataTable.h: (JSC::UnlinkedMetadataTable::buffer const): * bytecode/UnlinkedMetadataTableInlines.h: (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable): (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable): (JSC::UnlinkedMetadataTable::addEntry): (JSC::UnlinkedMetadataTable::sizeInBytes): (JSC::UnlinkedMetadataTable::finalize): (JSC::UnlinkedMetadataTable::link): (JSC::UnlinkedMetadataTable::unlink): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: 2018-11-07 Caio Lima <ticaiolima@gmail.com> [BigInt] Add support to BigInt into ValueAdd https://bugs.webkit.org/show_bug.cgi?id=186177 Reviewed by Keith Miller. We are adding a very primitive specialization case of BigInts into ValueAdd. When compiling a speculated version of this node to BigInt, we are currently calling 'operationAddBigInt', a function that expects only BigInts as parameter and effectly add numbers using JSBigInt::add. To properly speculate BigInt operands, we changed ArithProfile to observe when its result is a BigInt. With this new observation, we are able to identify when ValueAdd results into a String or BigInt. Here are some numbers for this specialization running microbenchmarks: big-int-simple-add 21.5411+-1.1096 ^ 15.3502+-0.7027 ^ definitely 1.4033x faster big-int-add-prediction-propagation 13.7762+-0.5578 ^ 10.8117+-0.5330 ^ definitely 1.2742x faster * bytecode/ArithProfile.cpp: (JSC::ArithProfile::emitObserveResult): (JSC::ArithProfile::shouldEmitSetNonNumeric const): (JSC::ArithProfile::shouldEmitSetBigInt const): (JSC::ArithProfile::emitSetNonNumeric const): (JSC::ArithProfile::emitSetBigInt const): (WTF::printInternal): (JSC::ArithProfile::shouldEmitSetNonNumber const): Deleted. (JSC::ArithProfile::emitSetNonNumber const): Deleted. * bytecode/ArithProfile.h: (JSC::ArithProfile::observedUnaryInt): (JSC::ArithProfile::observedUnaryNumber): (JSC::ArithProfile::observedBinaryIntInt): (JSC::ArithProfile::observedBinaryNumberInt): (JSC::ArithProfile::observedBinaryIntNumber): (JSC::ArithProfile::observedBinaryNumberNumber): (JSC::ArithProfile::didObserveNonInt32 const): (JSC::ArithProfile::didObserveNonNumeric const): (JSC::ArithProfile::didObserveBigInt const): (JSC::ArithProfile::setObservedNonNumeric): (JSC::ArithProfile::setObservedBigInt): (JSC::ArithProfile::observeResult): (JSC::ArithProfile::didObserveNonNumber const): Deleted. (JSC::ArithProfile::setObservedNonNumber): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::mayHaveNonNumericResult): (JSC::DFG::Node::mayHaveBigIntResult): (JSC::DFG::Node::mayHaveNonNumberResult): Deleted. * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): * dfg/DFGNodeFlags.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueAdd): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd): * runtime/CommonSlowPaths.cpp: (JSC::updateArithProfileForUnaryArithOp): (JSC::updateArithProfileForBinaryArithOp): 2018-11-07 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Fix "Javascript" => "JavaScript" enum in protocol generated objects https://bugs.webkit.org/show_bug.cgi?id=191340 Reviewed by Devin Rousso. * inspector/ConsoleMessage.cpp: (Inspector::messageSourceValue): Use new enum name. * inspector/scripts/codegen/generator.py: Correct the casing of "JavaScript". 2018-11-07 Tadeu Zagallo <tzagallo@apple.com> Align wide opcodes in the instruction stream https://bugs.webkit.org/show_bug.cgi?id=191254 Reviewed by Keith Miller. Pad the bytecode with nops to ensure that wide opcodes are 4-byte aligned on platforms that don't like unaligned memory access. For that, add a new type to represent jump targets, BoundLabel, which delays computing the offset in case we need to emit nops for padding. Extra padding is also emitted before op_yield and at the of each BytecodeWriter fragment, to ensure that the bytecode remains aligned after the rewriting. As a side effect, we can longer guarantee that the point immediately before emitting an opcode is the start of that opcode, since nops might be emitted in between if the opcode needs to be wide. To fix that, we only take the offset of opcodes after they have been emitted, using `m_lastInstruction.offset()`. * bytecode/BytecodeDumper.h: (JSC::BytecodeDumper::dumpValue): * bytecode/BytecodeGeneratorification.cpp: (JSC::BytecodeGeneratorification::run): * bytecode/BytecodeList.rb: * bytecode/BytecodeRewriter.h: (JSC::BytecodeRewriter::Fragment::align): (JSC::BytecodeRewriter::insertFragmentBefore): (JSC::BytecodeRewriter::insertFragmentAfter): * bytecode/Fits.h: * bytecode/InstructionStream.h: (JSC::InstructionStreamWriter::ref): * bytecode/PreciseJumpTargetsInlines.h: (JSC::updateStoredJumpTargetsForInstruction): * bytecompiler/BytecodeGenerator.cpp: (JSC::Label::setLocation): (JSC::BoundLabel::target): (JSC::BoundLabel::saveTarget): (JSC::BoundLabel::commitTarget): (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::recordOpcode): (JSC::BytecodeGenerator::alignWideOpcode): (JSC::BytecodeGenerator::emitProfileControlFlow): (JSC::BytecodeGenerator::emitResolveScope): (JSC::BytecodeGenerator::emitGetFromScope): (JSC::BytecodeGenerator::emitPutToScope): (JSC::BytecodeGenerator::emitGetById): (JSC::BytecodeGenerator::emitDirectGetById): (JSC::BytecodeGenerator::emitPutById): (JSC::BytecodeGenerator::emitDirectPutById): (JSC::BytecodeGenerator::emitGetByVal): (JSC::BytecodeGenerator::emitCreateThis): (JSC::BytecodeGenerator::beginSwitch): (JSC::BytecodeGenerator::endSwitch): (JSC::BytecodeGenerator::emitRequireObjectCoercible): (JSC::BytecodeGenerator::emitYieldPoint): (JSC::BytecodeGenerator::emitToThis): (JSC::Label::bind): Deleted. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::recordOpcode): Deleted. * bytecompiler/Label.h: (JSC::BoundLabel::BoundLabel): (JSC::BoundLabel::operator int): (JSC::Label::bind): * generator/Opcode.rb: 2018-11-07 Tadeu Zagallo <tzagallo@apple.com> REGRESSION(r237547): Test failures on 32-bit JSC since the JIT was disabled https://bugs.webkit.org/show_bug.cgi?id=191184 Reviewed by Saam Barati. Fix API test on CLoop: we can only disable the LLInt when the JIT is enabled. * API/tests/PingPongStackOverflowTest.cpp: (testPingPongStackOverflow): 2018-11-06 Justin Fan <justin_fan@apple.com> [WebGPU] Experimental prototype for WebGPURenderPipeline and WebGPUSwapChain https://bugs.webkit.org/show_bug.cgi?id=191291 Reviewed by Myles Maxfield. Properly disable WEBGPU on all non-Metal platforms for now. * Configurations/FeatureDefines.xcconfig: 2018-11-06 Keith Rollin <krollin@apple.com> Adjust handling of Include paths that need quoting https://bugs.webkit.org/show_bug.cgi?id=191314 <rdar://problem/45849143> Reviewed by Dan Bernstein. There are several places in the JavaScriptCore Xcode project where the paths defined in HEADER_SEARCH_PATHS are quoted. That is, the definitions look like: HEADER_SEARCH_PATHS = ( "\"${BUILT_PRODUCTS_DIR}/DerivedSources/JavaScriptCore\"", "\"${BUILT_PRODUCTS_DIR}/LLIntOffsets/${ARCHS}\"", "\"$(JAVASCRIPTCORE_FRAMEWORKS_DIR)/JavaScriptCore.framework/PrivateHeaders\"", "$(inherited)", ); The idea here is presumably to have the resulting $(CPP) command have -I options where the associated paths are themselves quoted, protecting against space characters in the paths. This approach to quote management can break under Xcode 9. If .xcfilelist files are added to the project, the 'objectVersion' value in the Xcode project file is changed from 46 to 51. If a project with objectVersion=51 is presented to Xcode 9 (as can happen when we build for older OS's), it produces build lines where the quotes are escaped, thereby becoming part of the path. The build then fails because a search for a file normally found in a directory called "Foo" will be looked for in "\"Foo\"", which doesn't exist. Simply removing the escaped quotes from the HEADER_SEARCH_PATHS definition doesn't work, leading to paths that need quoting due to space characters but that don't get this quoting (the part of the path after the space appears to simply go missing). Removing the escaped quotes from the HEADER_SEARCH_PATHS and moving the definitions to the .xcconfig fixes this problem. * Configurations/ToolExecutable.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: 2018-11-06 Michael Saboff <msaboff@apple.com> Multiple stress/regexp-compile-oom.js tests are failing on High Sierra Debug and Release JSC testers. https://bugs.webkit.org/show_bug.cgi?id=191271 Reviewed by Saam Barati. Fixed use of ThrowScope my adding release() calls. Found a few places where we needed RETURN_IF_EXCEPTION(). After some code inspections determined that we need to cover the exception bubbling for String.match() with a global RegExp as well as String.replace() and String.search(). * runtime/RegExpObjectInlines.h: (JSC::RegExpObject::matchInline): (JSC::collectMatches): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncSearchFast): * runtime/StringPrototype.cpp: (JSC::removeUsingRegExpSearch): (JSC::replaceUsingRegExpSearch): 2018-11-05 Don Olmstead <don.olmstead@sony.com> Fix typos in closing ENABLE guards https://bugs.webkit.org/show_bug.cgi?id=191273 Reviewed by Keith Miller. * ftl/FTLForOSREntryJITCode.h: * ftl/FTLJITCode.h: * jsc.cpp: * wasm/WasmMemoryInformation.h: * wasm/WasmPageCount.h: 2018-11-05 Keith Miller <keith_miller@apple.com> Make static_asserts in APICast into bitwise_cast https://bugs.webkit.org/show_bug.cgi?id=191272 Reviewed by Filip Pizlo. * API/APICast.h: (toJS): (toJSForGC): (toRef): 2018-11-05 Dominik Infuehr <dinfuehr@igalia.com> Enable LLInt on ARMv7/Linux https://bugs.webkit.org/show_bug.cgi?id=191190 Reviewed by Yusuke Suzuki. After enabling the new bytecode format in r237547, C_LOOP was forced on all 32-bit platforms. Now enable LLInt again on ARMv7-Thumb2/Linux. This adds a callee-saved register in ARMv7/Linux for the metadataTable and stores/restores it on LLInt function calls. It also introduces the globaladdr- instruction for the ARM-offlineasm to access the opcode-table. * jit/GPRInfo.h: * jit/RegisterSet.cpp: (JSC::RegisterSet::llintBaselineCalleeSaveRegisters): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * offlineasm/arm.rb: * offlineasm/asm.rb: * offlineasm/instructions.rb: 2018-11-05 Fujii Hironori <Hironori.Fujii@sony.com> [Win][Clang][JSC] JIT::is64BitType reports "warning: explicit specialization cannot have a storage class" https://bugs.webkit.org/show_bug.cgi?id=191146 Reviewed by Yusuke Suzuki. * jit/JIT.h: Changed is64BitType from a template class method to a template inner class. 2018-11-02 Keith Miller <keith_miller@apple.com> Assert JSValues can fit into a pointer when API casting https://bugs.webkit.org/show_bug.cgi?id=191220 Reviewed by Michael Saboff. * API/APICast.h: (toJS): (toJSForGC): (toRef): 2018-11-02 Michael Saboff <msaboff@apple.com> Rolling in r237753 with unreviewed build fix. Fixed issues with DECLARE_THROW_SCOPE placement. 2018-11-02 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r237753. Introduced JSC test failures Reverted changeset: "Running out of stack space not properly handled in RegExp::compile() and its callers" https://bugs.webkit.org/show_bug.cgi?id=191206 https://trac.webkit.org/changeset/237753 2018-11-02 Michael Saboff <msaboff@apple.com> Running out of stack space not properly handled in RegExp::compile() and its callers https://bugs.webkit.org/show_bug.cgi?id=191206 Reviewed by Filip Pizlo. Eliminated two RELEASE_ASSERT_NOT_REACHED() for errors returned by Yarr parsing code. Bubbled those errors up to where they are turned into the appropriate exceptions in matchInline(). If the errors are not due to syntax, we reset the RegExp state in case the parsing is tried with a smaller stack. * runtime/RegExp.cpp: (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/RegExp.h: * runtime/RegExpInlines.h: (JSC::RegExp::compileIfNecessary): (JSC::RegExp::matchInline): (JSC::RegExp::compileIfNecessaryMatchOnly): * runtime/RegExpObjectInlines.h: (JSC::RegExpObject::execInline): * yarr/YarrErrorCode.h: (JSC::Yarr::hasHardError): 2018-11-02 Keith Miller <keith_miller@apple.com> API should use wrapper object if address is 32-bit https://bugs.webkit.org/show_bug.cgi?id=191203 Reviewed by Filip Pizlo. * API/APICast.h: (toJS): (toJSForGC): (toRef): 2018-11-02 Tadeu Zagallo <tzagallo@apple.com> Metadata should not be copyable https://bugs.webkit.org/show_bug.cgi?id=191193 Reviewed by Keith Miller. We should only ever hold references to the entry in the metadata table. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finalizeLLIntInlineCaches): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * generator/Metadata.rb: 2018-11-02 Tadeu Zagallo <tzagallo@apple.com> REGRESSION(r237547): Exception handlers should be aware of wide opcodes when JIT is disabled https://bugs.webkit.org/show_bug.cgi?id=191175 Reviewed by Keith Miller. https://bugs.webkit.org/show_bug.cgi?id=191108 did not handle the case where JIT is not enabled * jit/JITExceptions.cpp: (JSC::genericUnwind): * llint/LLIntData.h: (JSC::LLInt::getWideCodePtr): 2018-11-01 Fujii Hironori <Hironori.Fujii@sony.com> Rename <wtf/unicode/UTF8.h> to <wtf/unicode/UTF8Conversion.h> in order to avoid conflicting with ICU's unicode/utf8.h https://bugs.webkit.org/show_bug.cgi?id=189693 Reviewed by Yusuke Suzuki. * API/JSClassRef.cpp: Replaced <wtf/unicode/UTF8.h> with <wtf/unicode/UTF8Conversion.h>. * API/JSStringRef.cpp: Ditto. * runtime/JSGlobalObjectFunctions.cpp: Ditto. * wasm/WasmParser.h: Ditto. 2018-11-01 Keith Miller <keith_miller@apple.com> Unreviewed, JavaScriptCore should only guarantee to produce a modulemap if we are building for iOSMac. * Configurations/JavaScriptCore.xcconfig: 2018-10-31 Devin Rousso <drousso@apple.com> Web Inspector: Canvas: create a setting for auto-recording newly created contexts https://bugs.webkit.org/show_bug.cgi?id=190856 Reviewed by Brian Burg. * inspector/protocol/Canvas.json: Add `setRecordingAutoCaptureFrameCount` command for setting the number of frames to record immediately after a context is created. * inspector/protocol/Recording.json: Add `creation` value for `Initiator` enum. 2018-10-31 Devin Rousso <drousso@apple.com> Web Inspector: display low-power enter/exit events in Timelines and Network node waterfalls https://bugs.webkit.org/show_bug.cgi?id=190641 <rdar://problem/45319049> Reviewed by Joseph Pecoraro. * inspector/protocol/DOM.json: Add `videoLowPowerChanged` event that is fired when `InspectorDOMAgent` is able to determine whether a video element's low power state has changed. 2018-10-31 Tadeu Zagallo <tzagallo@apple.com> Adjust inlining threshold for new bytecode format https://bugs.webkit.org/show_bug.cgi?id=191115 Reviewed by Saam Barati. The new format reduced the number of operands for many opcodes, which changed inlining decisions and impacted performance negatively. * runtime/Options.h: 2018-10-31 Tadeu Zagallo <tzagallo@apple.com> REGRESSION(r237547): Exception handlers should be aware of wide opcodes https://bugs.webkit.org/show_bug.cgi?id=191108 <rdar://problem/45690700> Reviewed by Saam Barati. When linking the handler, we need to check whether the target op_catch is wide or narrow in order to chose the right code pointer for the handler. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): 2018-10-31 Dominik Infuehr <dinfuehr@igalia.com> Align entries in metadata table https://bugs.webkit.org/show_bug.cgi?id=191062 Reviewed by Filip Pizlo. Entries in the metadata table need to be aligned on some 32-bit architectures. * bytecode/MetadataTable.h: (JSC::MetadataTable::forEach): * bytecode/Opcode.cpp: (JSC::metadataAlignment): * bytecode/Opcode.h: * bytecode/UnlinkedMetadataTableInlines.h: (JSC::UnlinkedMetadataTable::finalize): * generator/Section.rb: 2018-10-31 Jim Mason <jmason@ibinx.com> Static global 'fastHandlerInstalled' conditionally declared in WasmFaultSignalHandler.cpp https://bugs.webkit.org/show_bug.cgi?id=191063 Reviewed by Yusuke Suzuki. * wasm/WasmFaultSignalHandler.cpp: 2018-10-30 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC][LLInt] Compact LLInt ASM code by removing unnecessary instructions https://bugs.webkit.org/show_bug.cgi?id=191092 Reviewed by Saam Barati. Looking through LLIntAssembly.h, we can find several inefficiencies. This patch fixes the following things to tighten LLInt ASM code. 1. Remove unnecessary load instructions. Use jmp with BaseIndex directly. 2. Introduce strength reduction for mul instructions in offlineasm layer. This is now critical since mul instruction is executed in `metadata` operation in LLInt. If the given immediate is a power of two, we convert it to lshift instruction. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/instructions.rb: * offlineasm/x86.rb: 2018-10-30 Don Olmstead <don.olmstead@sony.com> [PlayStation] Enable JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=191072 Reviewed by Brent Fulgham. Add platform files for the PlayStation port. * PlatformPlayStation.cmake: Added. 2018-10-30 Alexey Proskuryakov <ap@apple.com> Clean up some obsolete MAX_ALLOWED macros https://bugs.webkit.org/show_bug.cgi?id=190916 Reviewed by Tim Horton. * API/JSManagedValue.mm: * API/JSVirtualMachine.mm: * API/JSWrapperMap.mm: 2018-10-30 Ross Kirsling <ross.kirsling@sony.com> useProbeOSRExit causes failures for Win64 DFG JIT https://bugs.webkit.org/show_bug.cgi?id=190656 Reviewed by Keith Miller. * assembler/ProbeContext.cpp: (JSC::Probe::executeProbe): If lowWatermark is expected to equal lowWatermarkFromVisitingDirtyPages *regardless* of the input param, then let's just call lowWatermarkFromVisitingDirtyPages instead. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): The result of VariableEventStream::reconstruct appears to be inappropriate for direct use as a stack pointer offset; mimic the non-probe case and use requiredRegisterCountForExit from DFGCommonData instead. (Also, stop redundantly setting the stack pointer twice in a row.) 2018-10-30 Yusuke Suzuki <yusukesuzuki@slowstart.org> "Unreviewed, partial rolling in r237254" https://bugs.webkit.org/show_bug.cgi?id=190340 This only adds Parser.{cpp,h}. And it is not used in this patch. It examines that the regression is related to exact Parser changes. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseInner): (JSC::Parser<LexerType>::parseSingleFunction): (JSC::Parser<LexerType>::parseFunctionInfo): (JSC::Parser<LexerType>::parseFunctionDeclaration): (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration): * parser/Parser.h: (JSC::Parser<LexerType>::parse): (JSC::parse): (JSC::parseFunctionForFunctionConstructor): 2018-10-29 Mark Lam <mark.lam@apple.com> Correctly detect string overflow when using the 'Function' constructor. https://bugs.webkit.org/show_bug.cgi?id=184883 <rdar://problem/36320331> Reviewed by Saam Barati. Added StringBuilder::hasOverflowed() checks, and throwing OutOfMemoryErrors if we detect an overflow. * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/JSGlobalObjectFunctions.cpp: (JSC::encode): (JSC::decode): * runtime/JSONObject.cpp: (JSC::Stringifier::stringify): (JSC::Stringifier::appendStringifiedValue): 2018-10-29 Tadeu Zagallo <tzagallo@apple.com> Unreviewed, fix JSC on arm64e after r237547 https://bugs.webkit.org/show_bug.cgi?id=187373 Unreviewed. Remove unused move guarded by POINTER_PROFILING that was trashing the metadata on arm64e. * llint/LowLevelInterpreter64.asm: 2018-10-29 Keith Miller <keith_miller@apple.com> JSC should explicitly list its modulemap file https://bugs.webkit.org/show_bug.cgi?id=191032 Reviewed by Saam Barati. The automagically generated module map file for JSC will include headers where they may not work out of the box. This patch makes it so we now export the same modulemap that used to be provided via the legacy system. * Configurations/JavaScriptCore.xcconfig: * JavaScriptCore.modulemap: Added. * JavaScriptCore.xcodeproj/project.pbxproj: 2018-10-29 Tim Horton <timothy_horton@apple.com> Modernize WebKit nibs and lprojs for localization's sake https://bugs.webkit.org/show_bug.cgi?id=190911 <rdar://problem/45349466> Reviewed by Dan Bernstein. * JavaScriptCore.xcodeproj/project.pbxproj: English->en 2018-10-29 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r237492. https://bugs.webkit.org/show_bug.cgi?id=191035 "It regresses JetStream 2 by 5% on some iOS devices" (Requested by saamyjoon on #webkit). Reverted changeset: "Unreviewed, partial rolling in r237254" https://bugs.webkit.org/show_bug.cgi?id=190340 https://trac.webkit.org/changeset/237492 2018-10-29 Tadeu Zagallo <tzagallo@apple.com> Add support for GetStack FlushedDouble https://bugs.webkit.org/show_bug.cgi?id=191012 <rdar://problem/45265141> Reviewed by Saam Barati. LowerDFGToB3::compileGetStack assumed that we would not emit GetStack for doubles, but it turns out it may arise from the PutStack sinking phase: if we sink a PutStack into a successor block, other predecessors will emit a GetStack followed by a Upsilon. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetStack): 2018-10-29 Tadeu Zagallo <tzagallo@apple.com> New bytecode format for JSC https://bugs.webkit.org/show_bug.cgi?id=187373 <rdar://problem/44186758> Reviewed by Filip Pizlo. Replace unlinked and linked bytecode with a new immutable bytecode that does not embed any addresses. Instructions can be encoded as narrow (1-byte operands) or wide (4-byte operands) and might contain an extra operand, the metadataID. The metadataID is used to access the instruction's mutable data in a side table in the CodeBlock (the MetadataTable). Bytecodes now must be structs declared in the new BytecodeList.rb. All bytecodes give names and types to all its operands. Additionally, reading a bytecode from the instruction stream requires decoding the whole bytecode, i.e. it's no longer possible to access arbitrary operands directly from the stream. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/MacroAssemblerCodeRef.h: (JSC::ReturnAddressPtr::ReturnAddressPtr): (JSC::ReturnAddressPtr::value const): (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr): (JSC::MacroAssemblerCodePtr::createFromExecutableAddress): * bytecode/ArithProfile.h: (JSC::ArithProfile::ArithProfile): * bytecode/ArrayAllocationProfile.h: (JSC::ArrayAllocationProfile::ArrayAllocationProfile): * bytecode/ArrayProfile.h: * bytecode/BytecodeBasicBlock.cpp: (JSC::isJumpTarget): (JSC::BytecodeBasicBlock::computeImpl): (JSC::BytecodeBasicBlock::compute): * bytecode/BytecodeBasicBlock.h: (JSC::BytecodeBasicBlock::leaderOffset const): (JSC::BytecodeBasicBlock::totalLength const): (JSC::BytecodeBasicBlock::offsets const): (JSC::BytecodeBasicBlock::BytecodeBasicBlock): (JSC::BytecodeBasicBlock::addLength): * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper<Block>::printLocationAndOp): (JSC::BytecodeDumper<Block>::dumpBytecode): (JSC::BytecodeDumper<Block>::dumpIdentifiers): (JSC::BytecodeDumper<Block>::dumpConstants): (JSC::BytecodeDumper<Block>::dumpExceptionHandlers): (JSC::BytecodeDumper<Block>::dumpSwitchJumpTables): (JSC::BytecodeDumper<Block>::dumpStringSwitchJumpTables): (JSC::BytecodeDumper<Block>::dumpBlock): * bytecode/BytecodeDumper.h: (JSC::BytecodeDumper::dumpOperand): (JSC::BytecodeDumper::dumpValue): (JSC::BytecodeDumper::BytecodeDumper): (JSC::BytecodeDumper::block const): * bytecode/BytecodeGeneratorification.cpp: (JSC::BytecodeGeneratorification::BytecodeGeneratorification): (JSC::BytecodeGeneratorification::enterPoint const): (JSC::BytecodeGeneratorification::instructions const): (JSC::GeneratorLivenessAnalysis::run): (JSC::BytecodeGeneratorification::run): (JSC::performGeneratorification): * bytecode/BytecodeGeneratorification.h: * bytecode/BytecodeGraph.h: (JSC::BytecodeGraph::blockContainsBytecodeOffset): (JSC::BytecodeGraph::findBasicBlockForBytecodeOffset): (JSC::BytecodeGraph::findBasicBlockWithLeaderOffset): (JSC::BytecodeGraph::BytecodeGraph): * bytecode/BytecodeKills.h: * bytecode/BytecodeList.json: Removed. * bytecode/BytecodeList.rb: Added. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::BytecodeLivenessAnalysis::dumpResults): * bytecode/BytecodeLivenessAnalysis.h: * bytecode/BytecodeLivenessAnalysisInlines.h: (JSC::isValidRegisterForLiveness): (JSC::BytecodeLivenessPropagation::stepOverInstruction): * bytecode/BytecodeRewriter.cpp: (JSC::BytecodeRewriter::applyModification): (JSC::BytecodeRewriter::execute): (JSC::BytecodeRewriter::adjustJumpTargetsInFragment): (JSC::BytecodeRewriter::insertImpl): (JSC::BytecodeRewriter::adjustJumpTarget): (JSC::BytecodeRewriter::adjustJumpTargets): * bytecode/BytecodeRewriter.h: (JSC::BytecodeRewriter::InsertionPoint::InsertionPoint): (JSC::BytecodeRewriter::Fragment::Fragment): (JSC::BytecodeRewriter::Fragment::appendInstruction): (JSC::BytecodeRewriter::BytecodeRewriter): (JSC::BytecodeRewriter::insertFragmentBefore): (JSC::BytecodeRewriter::insertFragmentAfter): (JSC::BytecodeRewriter::removeBytecode): (JSC::BytecodeRewriter::adjustAbsoluteOffset): (JSC::BytecodeRewriter::adjustJumpTarget): * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFromLLInt): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::estimatedSize): (JSC::CodeBlock::visitChildren): (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::finalizeLLIntInlineCaches): (JSC::CodeBlock::addJITAddIC): (JSC::CodeBlock::addJITMulIC): (JSC::CodeBlock::addJITSubIC): (JSC::CodeBlock::addJITNegIC): (JSC::CodeBlock::stronglyVisitStrongReferences): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow): (JSC::CodeBlock::hasOpDebugForLineAndColumn): (JSC::CodeBlock::getArrayProfile): (JSC::CodeBlock::updateAllArrayPredictions): (JSC::CodeBlock::predictedMachineCodeSize): (JSC::CodeBlock::tryGetValueProfileForBytecodeOffset): (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): (JSC::CodeBlock::valueProfileForBytecodeOffset): (JSC::CodeBlock::validate): (JSC::CodeBlock::outOfLineJumpOffset): (JSC::CodeBlock::outOfLineJumpTarget): (JSC::CodeBlock::arithProfileForBytecodeOffset): (JSC::CodeBlock::arithProfileForPC): (JSC::CodeBlock::couldTakeSpecialFastCase): (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): * bytecode/CodeBlock.h: (JSC::CodeBlock::addMathIC): (JSC::CodeBlock::outOfLineJumpOffset): (JSC::CodeBlock::bytecodeOffset): (JSC::CodeBlock::instructions const): (JSC::CodeBlock::instructionCount const): (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): (JSC::CodeBlock::metadata): (JSC::CodeBlock::metadataSizeInBytes): (JSC::CodeBlock::numberOfNonArgumentValueProfiles): (JSC::CodeBlock::totalNumberOfValueProfiles): * bytecode/CodeBlockInlines.h: Added. (JSC::CodeBlock::forEachValueProfile): (JSC::CodeBlock::forEachArrayProfile): (JSC::CodeBlock::forEachArrayAllocationProfile): (JSC::CodeBlock::forEachObjectAllocationProfile): (JSC::CodeBlock::forEachLLIntCallLinkInfo): * bytecode/Fits.h: Added. * bytecode/GetByIdMetadata.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): * bytecode/Instruction.h: (JSC::Instruction::Instruction): (JSC::Instruction::Impl::opcodeID const): (JSC::Instruction::opcodeID const): (JSC::Instruction::name const): (JSC::Instruction::isWide const): (JSC::Instruction::size const): (JSC::Instruction::is const): (JSC::Instruction::as const): (JSC::Instruction::cast): (JSC::Instruction::cast const): (JSC::Instruction::narrow const): (JSC::Instruction::wide const): * bytecode/InstructionStream.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp. (JSC::InstructionStream::InstructionStream): (JSC::InstructionStream::sizeInBytes const): * bytecode/InstructionStream.h: Added. (JSC::InstructionStream::BaseRef::BaseRef): (JSC::InstructionStream::BaseRef::operator=): (JSC::InstructionStream::BaseRef::operator-> const): (JSC::InstructionStream::BaseRef::ptr const): (JSC::InstructionStream::BaseRef::operator!= const): (JSC::InstructionStream::BaseRef::next const): (JSC::InstructionStream::BaseRef::offset const): (JSC::InstructionStream::BaseRef::isValid const): (JSC::InstructionStream::BaseRef::unwrap const): (JSC::InstructionStream::MutableRef::freeze const): (JSC::InstructionStream::MutableRef::operator->): (JSC::InstructionStream::MutableRef::ptr): (JSC::InstructionStream::MutableRef::operator Ref): (JSC::InstructionStream::MutableRef::unwrap): (JSC::InstructionStream::iterator::operator*): (JSC::InstructionStream::iterator::operator++): (JSC::InstructionStream::begin const): (JSC::InstructionStream::end const): (JSC::InstructionStream::at const): (JSC::InstructionStream::size const): (JSC::InstructionStreamWriter::InstructionStreamWriter): (JSC::InstructionStreamWriter::ref): (JSC::InstructionStreamWriter::seek): (JSC::InstructionStreamWriter::position): (JSC::InstructionStreamWriter::write): (JSC::InstructionStreamWriter::rewind): (JSC::InstructionStreamWriter::finalize): (JSC::InstructionStreamWriter::swap): (JSC::InstructionStreamWriter::iterator::operator*): (JSC::InstructionStreamWriter::iterator::operator++): (JSC::InstructionStreamWriter::begin): (JSC::InstructionStreamWriter::end): * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint): (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal): (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache): * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h: * bytecode/MetadataTable.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp. (JSC::MetadataTable::MetadataTable): (JSC::DeallocTable::withOpcodeType): (JSC::MetadataTable::~MetadataTable): (JSC::MetadataTable::sizeInBytes): * bytecode/MetadataTable.h: Copied from Source/JavaScriptCore/runtime/Watchdog.h. (JSC::MetadataTable::get): (JSC::MetadataTable::forEach): (JSC::MetadataTable::getImpl): * bytecode/Opcode.cpp: (JSC::metadataSize): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/OpcodeInlines.h: (JSC::isOpcodeShape): (JSC::getOpcodeType): * bytecode/OpcodeSize.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp. * bytecode/PreciseJumpTargets.cpp: (JSC::getJumpTargetsForInstruction): (JSC::computePreciseJumpTargetsInternal): (JSC::computePreciseJumpTargets): (JSC::recomputePreciseJumpTargets): (JSC::findJumpTargetsForInstruction): * bytecode/PreciseJumpTargets.h: * bytecode/PreciseJumpTargetsInlines.h: (JSC::jumpTargetForInstruction): (JSC::extractStoredJumpTargetsForInstruction): (JSC::updateStoredJumpTargetsForInstruction): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): * bytecode/SpecialPointer.cpp: (WTF::printInternal): * bytecode/SpecialPointer.h: * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::UnlinkedCodeBlock::visitChildren): (JSC::UnlinkedCodeBlock::estimatedSize): (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): (JSC::dumpLineColumnEntry): (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset const): (JSC::UnlinkedCodeBlock::setInstructions): (JSC::UnlinkedCodeBlock::instructions const): (JSC::UnlinkedCodeBlock::applyModification): (JSC::UnlinkedCodeBlock::addOutOfLineJumpTarget): (JSC::UnlinkedCodeBlock::outOfLineJumpOffset): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): (JSC::UnlinkedCodeBlock::propertyAccessInstructions const): (JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): (JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const): (JSC::UnlinkedCodeBlock::metadata): (JSC::UnlinkedCodeBlock::metadataSizeInBytes): (JSC::UnlinkedCodeBlock::outOfLineJumpOffset): (JSC::UnlinkedCodeBlock::replaceOutOfLineJumpTargets): * bytecode/UnlinkedInstructionStream.cpp: Removed. * bytecode/UnlinkedInstructionStream.h: Removed. * bytecode/UnlinkedMetadataTable.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h. * bytecode/UnlinkedMetadataTableInlines.h: Added. (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable): (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable): (JSC::UnlinkedMetadataTable::addEntry): (JSC::UnlinkedMetadataTable::sizeInBytes): (JSC::UnlinkedMetadataTable::finalize): (JSC::UnlinkedMetadataTable::link): (JSC::UnlinkedMetadataTable::unlink): * bytecode/VirtualRegister.cpp: (JSC::VirtualRegister::VirtualRegister): * bytecode/VirtualRegister.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::Label::setLocation): (JSC::Label::bind): (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeVarLexicalEnvironment): (JSC::BytecodeGenerator::emitEnter): (JSC::BytecodeGenerator::emitLoopHint): (JSC::BytecodeGenerator::emitJump): (JSC::BytecodeGenerator::emitCheckTraps): (JSC::BytecodeGenerator::rewind): (JSC::BytecodeGenerator::fuseCompareAndJump): (JSC::BytecodeGenerator::fuseTestAndJmp): (JSC::BytecodeGenerator::emitJumpIfTrue): (JSC::BytecodeGenerator::emitJumpIfFalse): (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall): (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply): (JSC::BytecodeGenerator::moveLinkTimeConstant): (JSC::BytecodeGenerator::moveEmptyValue): (JSC::BytecodeGenerator::emitMove): (JSC::BytecodeGenerator::emitUnaryOp): (JSC::BytecodeGenerator::emitBinaryOp): (JSC::BytecodeGenerator::emitToObject): (JSC::BytecodeGenerator::emitToNumber): (JSC::BytecodeGenerator::emitToString): (JSC::BytecodeGenerator::emitTypeOf): (JSC::BytecodeGenerator::emitInc): (JSC::BytecodeGenerator::emitDec): (JSC::BytecodeGenerator::emitEqualityOp): (JSC::BytecodeGenerator::emitProfileType): (JSC::BytecodeGenerator::emitProfileControlFlow): (JSC::BytecodeGenerator::pushLexicalScopeInternal): (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval): (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration): (JSC::BytecodeGenerator::emitOverridesHasInstance): (JSC::BytecodeGenerator::emitResolveScope): (JSC::BytecodeGenerator::emitGetFromScope): (JSC::BytecodeGenerator::emitPutToScope): (JSC::BytecodeGenerator::emitInstanceOf): (JSC::BytecodeGenerator::emitInstanceOfCustom): (JSC::BytecodeGenerator::emitInByVal): (JSC::BytecodeGenerator::emitInById): (JSC::BytecodeGenerator::emitTryGetById): (JSC::BytecodeGenerator::emitGetById): (JSC::BytecodeGenerator::emitDirectGetById): (JSC::BytecodeGenerator::emitPutById): (JSC::BytecodeGenerator::emitDirectPutById): (JSC::BytecodeGenerator::emitPutGetterById): (JSC::BytecodeGenerator::emitPutSetterById): (JSC::BytecodeGenerator::emitPutGetterSetter): (JSC::BytecodeGenerator::emitPutGetterByVal): (JSC::BytecodeGenerator::emitPutSetterByVal): (JSC::BytecodeGenerator::emitDeleteById): (JSC::BytecodeGenerator::emitGetByVal): (JSC::BytecodeGenerator::emitPutByVal): (JSC::BytecodeGenerator::emitDirectPutByVal): (JSC::BytecodeGenerator::emitDeleteByVal): (JSC::BytecodeGenerator::emitSuperSamplerBegin): (JSC::BytecodeGenerator::emitSuperSamplerEnd): (JSC::BytecodeGenerator::emitIdWithProfile): (JSC::BytecodeGenerator::emitUnreachable): (JSC::BytecodeGenerator::emitGetArgument): (JSC::BytecodeGenerator::emitCreateThis): (JSC::BytecodeGenerator::emitTDZCheck): (JSC::BytecodeGenerator::emitNewObject): (JSC::BytecodeGenerator::emitNewArrayBuffer): (JSC::BytecodeGenerator::emitNewArray): (JSC::BytecodeGenerator::emitNewArrayWithSpread): (JSC::BytecodeGenerator::emitNewArrayWithSize): (JSC::BytecodeGenerator::emitNewRegExp): (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): (JSC::BytecodeGenerator::emitNewDefaultConstructor): (JSC::BytecodeGenerator::emitNewFunction): (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded): (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitCallInTailPosition): (JSC::BytecodeGenerator::emitCallEval): (JSC::BytecodeGenerator::emitExpectedFunctionSnippet): (JSC::BytecodeGenerator::emitCallVarargs): (JSC::BytecodeGenerator::emitCallVarargsInTailPosition): (JSC::BytecodeGenerator::emitConstructVarargs): (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition): (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary): (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary): (JSC::BytecodeGenerator::emitCallDefineProperty): (JSC::BytecodeGenerator::emitReturn): (JSC::BytecodeGenerator::emitEnd): (JSC::BytecodeGenerator::emitConstruct): (JSC::BytecodeGenerator::emitStrcat): (JSC::BytecodeGenerator::emitToPrimitive): (JSC::BytecodeGenerator::emitGetScope): (JSC::BytecodeGenerator::emitPushWithScope): (JSC::BytecodeGenerator::emitGetParentScope): (JSC::BytecodeGenerator::emitDebugHook): (JSC::BytecodeGenerator::emitCatch): (JSC::BytecodeGenerator::emitThrow): (JSC::BytecodeGenerator::emitArgumentCount): (JSC::BytecodeGenerator::emitThrowStaticError): (JSC::BytecodeGenerator::beginSwitch): (JSC::prepareJumpTableForSwitch): (JSC::prepareJumpTableForStringSwitch): (JSC::BytecodeGenerator::endSwitch): (JSC::BytecodeGenerator::emitGetEnumerableLength): (JSC::BytecodeGenerator::emitHasGenericProperty): (JSC::BytecodeGenerator::emitHasIndexedProperty): (JSC::BytecodeGenerator::emitHasStructureProperty): (JSC::BytecodeGenerator::emitGetPropertyEnumerator): (JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName): (JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName): (JSC::BytecodeGenerator::emitToIndexString): (JSC::BytecodeGenerator::emitIsCellWithType): (JSC::BytecodeGenerator::emitIsObject): (JSC::BytecodeGenerator::emitIsNumber): (JSC::BytecodeGenerator::emitIsUndefined): (JSC::BytecodeGenerator::emitIsEmpty): (JSC::BytecodeGenerator::emitRestParameter): (JSC::BytecodeGenerator::emitRequireObjectCoercible): (JSC::BytecodeGenerator::emitYieldPoint): (JSC::BytecodeGenerator::emitYield): (JSC::BytecodeGenerator::emitGetAsyncIterator): (JSC::BytecodeGenerator::emitDelegateYield): (JSC::BytecodeGenerator::emitFinallyCompletion): (JSC::BytecodeGenerator::emitJumpIf): (JSC::ForInContext::finalize): (JSC::StructureForInContext::finalize): (JSC::IndexedForInContext::finalize): (JSC::StaticPropertyAnalysis::record): (JSC::BytecodeGenerator::emitToThis): * bytecompiler/BytecodeGenerator.h: (JSC::StructureForInContext::addGetInst): (JSC::BytecodeGenerator::recordOpcode): (JSC::BytecodeGenerator::addMetadataFor): (JSC::BytecodeGenerator::emitUnaryOp): (JSC::BytecodeGenerator::kill): (JSC::BytecodeGenerator::instructions const): (JSC::BytecodeGenerator::write): (JSC::BytecodeGenerator::withWriter): * bytecompiler/Label.h: (JSC::Label::Label): (JSC::Label::bind): * bytecompiler/NodesCodegen.cpp: (JSC::ArrayNode::emitBytecode): (JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount): (JSC::ApplyFunctionCallDotNode::emitBytecode): (JSC::BitwiseNotNode::emitBytecode): (JSC::BinaryOpNode::emitBytecode): (JSC::EqualNode::emitBytecode): (JSC::StrictEqualNode::emitBytecode): (JSC::emitReadModifyAssignment): (JSC::ForInNode::emitBytecode): (JSC::CaseBlockNode::emitBytecodeForBlock): (JSC::FunctionNode::emitBytecode): (JSC::ClassExprNode::emitBytecode): * bytecompiler/ProfileTypeBytecodeFlag.cpp: Copied from Source/JavaScriptCore/bytecode/VirtualRegister.cpp. (WTF::printInternal): * bytecompiler/ProfileTypeBytecodeFlag.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp. * bytecompiler/RegisterID.h: * bytecompiler/StaticPropertyAnalysis.h: (JSC::StaticPropertyAnalysis::create): (JSC::StaticPropertyAnalysis::StaticPropertyAnalysis): * bytecompiler/StaticPropertyAnalyzer.h: (JSC::StaticPropertyAnalyzer::createThis): (JSC::StaticPropertyAnalyzer::newObject): (JSC::StaticPropertyAnalyzer::putById): (JSC::StaticPropertyAnalyzer::mov): (JSC::StaticPropertyAnalyzer::kill): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addCall): (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): (JSC::DFG::ByteCodeParser::getArrayMode): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleVarargsCall): (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::handleCallVariant): (JSC::DFG::ByteCodeParser::handleVarargsInlining): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::handleMinMax): (JSC::DFG::ByteCodeParser::handleIntrinsicCall): (JSC::DFG::ByteCodeParser::handleDOMJITCall): (JSC::DFG::ByteCodeParser::handleIntrinsicGetter): (JSC::DFG::ByteCodeParser::handleDOMJITGetter): (JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad): (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor): (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::parseGetById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parseCodeBlock): (JSC::DFG::ByteCodeParser::handlePutByVal): (JSC::DFG::ByteCodeParser::handlePutAccessorById): (JSC::DFG::ByteCodeParser::handlePutAccessorByVal): (JSC::DFG::ByteCodeParser::handleNewFunc): (JSC::DFG::ByteCodeParser::handleNewFuncExp): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGCapabilities.h: (JSC::DFG::capabilityLevel): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareCatchOSREntry): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueAdd): (JSC::DFG::SpeculativeJIT::compileValueSub): (JSC::DFG::SpeculativeJIT::compileValueNegate): (JSC::DFG::SpeculativeJIT::compileArithMul): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd): (JSC::FTL::DFG::LowerDFGToB3::compileValueSub): (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub): (JSC::FTL::DFG::LowerDFGToB3::compileArithMul): (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * generate-bytecode-files: Removed. * generator/Argument.rb: Added. * generator/Assertion.rb: Added. * generator/DSL.rb: Added. * generator/Fits.rb: Added. * generator/GeneratedFile.rb: Added. * generator/Metadata.rb: Added. * generator/Opcode.rb: Added. * generator/OpcodeGroup.rb: Added. * generator/Options.rb: Added. * generator/Section.rb: Added. * generator/Template.rb: Added. * generator/Type.rb: Added. * generator/main.rb: Added. * interpreter/AbstractPC.h: * interpreter/CallFrame.cpp: (JSC::CallFrame::currentVPC const): (JSC::CallFrame::setCurrentVPC): * interpreter/CallFrame.h: (JSC::CallSiteIndex::CallSiteIndex): (JSC::ExecState::setReturnPC): * interpreter/Interpreter.cpp: (WTF::printInternal): * interpreter/Interpreter.h: * interpreter/InterpreterInlines.h: * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::dump const): * interpreter/VMEntryRecord.h: * jit/JIT.cpp: (JSC::JIT::JIT): (JSC::JIT::emitSlowCaseCall): (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): (JSC::JIT::compileWithoutLinking): (JSC::JIT::link): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_jless): (JSC::JIT::emit_op_jlesseq): (JSC::JIT::emit_op_jgreater): (JSC::JIT::emit_op_jgreatereq): (JSC::JIT::emit_op_jnless): (JSC::JIT::emit_op_jnlesseq): (JSC::JIT::emit_op_jngreater): (JSC::JIT::emit_op_jngreatereq): (JSC::JIT::emitSlow_op_jless): (JSC::JIT::emitSlow_op_jlesseq): (JSC::JIT::emitSlow_op_jgreater): (JSC::JIT::emitSlow_op_jgreatereq): (JSC::JIT::emitSlow_op_jnless): (JSC::JIT::emitSlow_op_jnlesseq): (JSC::JIT::emitSlow_op_jngreater): (JSC::JIT::emitSlow_op_jngreatereq): (JSC::JIT::emit_op_below): (JSC::JIT::emit_op_beloweq): (JSC::JIT::emit_op_jbelow): (JSC::JIT::emit_op_jbeloweq): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emit_op_mod): (JSC::JIT::emitSlow_op_mod): (JSC::JIT::emit_op_negate): (JSC::JIT::emitSlow_op_negate): (JSC::JIT::emitBitBinaryOpFastPath): (JSC::JIT::emit_op_bitand): (JSC::JIT::emit_op_bitor): (JSC::JIT::emit_op_bitxor): (JSC::JIT::emit_op_lshift): (JSC::JIT::emitRightShiftFastPath): (JSC::JIT::emit_op_rshift): (JSC::JIT::emit_op_urshift): (JSC::getOperandTypes): (JSC::JIT::emit_op_add): (JSC::JIT::emitSlow_op_add): (JSC::JIT::emitMathICFast): (JSC::JIT::emitMathICSlow): (JSC::JIT::emit_op_div): (JSC::JIT::emit_op_mul): (JSC::JIT::emitSlow_op_mul): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITCall.cpp: (JSC::JIT::emitPutCallResult): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileCallEval): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileTailCall): (JSC::JIT::compileOpCall): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::emit_op_call): (JSC::JIT::emit_op_tail_call): (JSC::JIT::emit_op_call_eval): (JSC::JIT::emit_op_call_varargs): (JSC::JIT::emit_op_tail_call_varargs): (JSC::JIT::emit_op_tail_call_forward_arguments): (JSC::JIT::emit_op_construct_varargs): (JSC::JIT::emit_op_construct): (JSC::JIT::emitSlow_op_call): (JSC::JIT::emitSlow_op_tail_call): (JSC::JIT::emitSlow_op_call_eval): (JSC::JIT::emitSlow_op_call_varargs): (JSC::JIT::emitSlow_op_tail_call_varargs): (JSC::JIT::emitSlow_op_tail_call_forward_arguments): (JSC::JIT::emitSlow_op_construct_varargs): (JSC::JIT::emitSlow_op_construct): * jit/JITDisassembler.cpp: (JSC::JITDisassembler::JITDisassembler): * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITInlines.h: (JSC::JIT::emitDoubleGetByVal): (JSC::JIT::emitLoadForArrayMode): (JSC::JIT::emitContiguousGetByVal): (JSC::JIT::emitArrayStorageGetByVal): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile): (JSC::JIT::sampleInstruction): (JSC::JIT::emitValueProfilingSiteIfProfiledOpcode): (JSC::JIT::emitValueProfilingSite): (JSC::JIT::jumpTarget): (JSC::JIT::copiedGetPutInfo): (JSC::JIT::copiedArithProfile): * jit/JITMathIC.h: (JSC::isProfileEmpty): (JSC::JITBinaryMathIC::JITBinaryMathIC): (JSC::JITUnaryMathIC::JITUnaryMathIC): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emit_op_instanceof_custom): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emit_op_throw): (JSC::JIT::compileOpStrictEq): (JSC::JIT::emit_op_stricteq): (JSC::JIT::emit_op_nstricteq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emit_op_jstricteq): (JSC::JIT::emit_op_jnstricteq): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_identity_with_profile): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_debug): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_enter): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_loop_hint): (JSC::JIT::emitSlow_op_loop_hint): (JSC::JIT::emit_op_check_traps): (JSC::JIT::emit_op_nop): (JSC::JIT::emit_op_super_sampler_begin): (JSC::JIT::emit_op_super_sampler_end): (JSC::JIT::emitSlow_op_check_traps): (JSC::JIT::emit_op_new_regexp): (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emit_op_new_func): (JSC::JIT::emit_op_new_generator_func): (JSC::JIT::emit_op_new_async_generator_func): (JSC::JIT::emit_op_new_async_func): (JSC::JIT::emitNewFuncExprCommon): (JSC::JIT::emit_op_new_func_exp): (JSC::JIT::emit_op_new_generator_func_exp): (JSC::JIT::emit_op_new_async_func_exp): (JSC::JIT::emit_op_new_async_generator_func_exp): (JSC::JIT::emit_op_new_array): (JSC::JIT::emit_op_new_array_with_size): (JSC::JIT::emit_op_has_structure_property): (JSC::JIT::privateCompileHasIndexedProperty): (JSC::JIT::emit_op_has_indexed_property): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emit_op_enumerator_structure_pname): (JSC::JIT::emit_op_enumerator_generic_pname): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): (JSC::JIT::emit_op_profile_control_flow): (JSC::JIT::emit_op_argument_count): (JSC::JIT::emit_op_get_rest_length): (JSC::JIT::emit_op_get_argument): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_to_this): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val_direct): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): (JSC::JIT::privateCompileGetByVal): (JSC::JIT::privateCompileGetByValWithCachedId): (JSC::JIT::privateCompilePutByVal): (JSC::JIT::privateCompilePutByValWithCachedId): (JSC::JIT::emitDoubleLoad): (JSC::JIT::emitContiguousLoad): (JSC::JIT::emitArrayStorageLoad): (JSC::JIT::emitDirectArgumentsGetByVal): (JSC::JIT::emitScopedArgumentsGetByVal): (JSC::JIT::emitIntTypedArrayGetByVal): (JSC::JIT::emitFloatTypedArrayGetByVal): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jit/RegisterSet.cpp: (JSC::RegisterSet::llintBaselineCalleeSaveRegisters): * jit/SlowPathCall.h: (JSC::JITSlowPathCall::JITSlowPathCall): * llint/LLIntData.cpp: (JSC::LLInt::initialize): (JSC::LLInt::Data::performAssertions): * llint/LLIntData.h: (JSC::LLInt::exceptionInstructions): (JSC::LLInt::opcodeMap): (JSC::LLInt::opcodeMapWide): (JSC::LLInt::getOpcode): (JSC::LLInt::getOpcodeWide): (JSC::LLInt::getWideCodePtr): * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_trace_operand): (JSC::LLInt::llint_trace_value): (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::entryOSR): (JSC::LLInt::setupGetByIdPrototypeCache): (JSC::LLInt::getByVal): (JSC::LLInt::handleHostCall): (JSC::LLInt::setUpCall): (JSC::LLInt::genericCall): (JSC::LLInt::varargsSetup): (JSC::LLInt::commonCallEval): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: (JSC::CLoopRegister::operator const Instruction*): (JSC::CLoop::execute): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/asm.rb: * offlineasm/ast.rb: * offlineasm/cloop.rb: * offlineasm/generate_offset_extractor.rb: * offlineasm/instructions.rb: * offlineasm/offsets.rb: * offlineasm/parser.rb: * offlineasm/transform.rb: * offlineasm/x86.rb: * parser/ResultType.h: (JSC::ResultType::dump const): (JSC::OperandTypes::first const): (JSC::OperandTypes::second const): (JSC::OperandTypes::dump const): * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): (JSC::updateArithProfileForUnaryArithOp): (JSC::updateArithProfileForBinaryArithOp): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::tryCachePutToScopeGlobal): (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): * runtime/ExceptionFuzz.cpp: (JSC::doExceptionFuzzing): * runtime/ExceptionFuzz.h: (JSC::doExceptionFuzzingIfEnabled): * runtime/GetPutInfo.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp. (JSC::GetPutInfo::dump const): (WTF::printInternal): * runtime/GetPutInfo.h: (JSC::GetPutInfo::operand const): * runtime/JSCPoison.h: * runtime/JSType.cpp: Added. (WTF::printInternal): * runtime/JSType.h: * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::StackFrame::displayName): * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame): * runtime/SlowPathReturnType.h: (JSC::encodeResult): (JSC::decodeResult): * runtime/VM.h: * runtime/Watchdog.h: * tools/HeapVerifier.cpp: 2018-10-27 Yusuke Suzuki <yusukesuzuki@slowstart.org> Unreviewed, partial rolling in r237254 https://bugs.webkit.org/show_bug.cgi?id=190340 We do not use the added function right now to investigate what is the reason of the regression. It also does not include any Parser.{h,cpp} changes to ensure that Parser.cpp's inlining decision seems culprit of the regression on iOS devices. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::fromGlobalCode): * bytecode/UnlinkedFunctionExecutable.h: * parser/SourceCodeKey.h: (JSC::SourceCodeKey::SourceCodeKey): (JSC::SourceCodeKey::operator== const): * runtime/CodeCache.cpp: (JSC::CodeCache::getUnlinkedGlobalCodeBlock): (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): * runtime/CodeCache.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::fromGlobalCode): * runtime/FunctionExecutable.h: 2018-10-26 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r237479 and r237484. https://bugs.webkit.org/show_bug.cgi?id=190978 broke JSC on iOS (Requested by tadeuzagallo on #webkit). Reverted changesets: "New bytecode format for JSC" https://bugs.webkit.org/show_bug.cgi?id=187373 https://trac.webkit.org/changeset/237479 "Gardening: Build fix after r237479." https://bugs.webkit.org/show_bug.cgi?id=187373 https://trac.webkit.org/changeset/237484 2018-10-26 Tadeu Zagallo <tzagallo@apple.com> Gardening: Build fix after r237479. https://bugs.webkit.org/show_bug.cgi?id=187373 Unreviewed. * Configurations/JSC.xcconfig: * JavaScriptCore.xcodeproj/project.pbxproj: * llint/LLIntData.cpp: (JSC::LLInt::initialize): 2018-10-26 Tadeu Zagallo <tzagallo@apple.com> New bytecode format for JSC https://bugs.webkit.org/show_bug.cgi?id=187373 <rdar://problem/44186758> Reviewed by Filip Pizlo. Replace unlinked and linked bytecode with a new immutable bytecode that does not embed any addresses. Instructions can be encoded as narrow (1-byte operands) or wide (4-byte operands) and might contain an extra operand, the metadataID. The metadataID is used to access the instruction's mutable data in a side table in the CodeBlock (the MetadataTable). Bytecodes now must be structs declared in the new BytecodeList.rb. All bytecodes give names and types to all its operands. Additionally, reading a bytecode from the instruction stream requires decoding the whole bytecode, i.e. it's no longer possible to access arbitrary operands directly from the stream. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * assembler/MacroAssemblerCodeRef.h: (JSC::ReturnAddressPtr::ReturnAddressPtr): (JSC::ReturnAddressPtr::value const): (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr): (JSC::MacroAssemblerCodePtr::createFromExecutableAddress): * bytecode/ArithProfile.h: (JSC::ArithProfile::ArithProfile): * bytecode/ArrayAllocationProfile.h: (JSC::ArrayAllocationProfile::ArrayAllocationProfile): * bytecode/ArrayProfile.h: * bytecode/BytecodeBasicBlock.cpp: (JSC::isJumpTarget): (JSC::BytecodeBasicBlock::computeImpl): (JSC::BytecodeBasicBlock::compute): * bytecode/BytecodeBasicBlock.h: (JSC::BytecodeBasicBlock::leaderOffset const): (JSC::BytecodeBasicBlock::totalLength const): (JSC::BytecodeBasicBlock::offsets const): (JSC::BytecodeBasicBlock::BytecodeBasicBlock): (JSC::BytecodeBasicBlock::addLength): * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper<Block>::printLocationAndOp): (JSC::BytecodeDumper<Block>::dumpBytecode): (JSC::BytecodeDumper<Block>::dumpIdentifiers): (JSC::BytecodeDumper<Block>::dumpConstants): (JSC::BytecodeDumper<Block>::dumpExceptionHandlers): (JSC::BytecodeDumper<Block>::dumpSwitchJumpTables): (JSC::BytecodeDumper<Block>::dumpStringSwitchJumpTables): (JSC::BytecodeDumper<Block>::dumpBlock): * bytecode/BytecodeDumper.h: (JSC::BytecodeDumper::dumpOperand): (JSC::BytecodeDumper::dumpValue): (JSC::BytecodeDumper::BytecodeDumper): (JSC::BytecodeDumper::block const): * bytecode/BytecodeGeneratorification.cpp: (JSC::BytecodeGeneratorification::BytecodeGeneratorification): (JSC::BytecodeGeneratorification::enterPoint const): (JSC::BytecodeGeneratorification::instructions const): (JSC::GeneratorLivenessAnalysis::run): (JSC::BytecodeGeneratorification::run): (JSC::performGeneratorification): * bytecode/BytecodeGeneratorification.h: * bytecode/BytecodeGraph.h: (JSC::BytecodeGraph::blockContainsBytecodeOffset): (JSC::BytecodeGraph::findBasicBlockForBytecodeOffset): (JSC::BytecodeGraph::findBasicBlockWithLeaderOffset): (JSC::BytecodeGraph::BytecodeGraph): * bytecode/BytecodeKills.h: * bytecode/BytecodeList.json: Removed. * bytecode/BytecodeList.rb: Added. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::BytecodeLivenessAnalysis::dumpResults): * bytecode/BytecodeLivenessAnalysis.h: * bytecode/BytecodeLivenessAnalysisInlines.h: (JSC::isValidRegisterForLiveness): (JSC::BytecodeLivenessPropagation::stepOverInstruction): * bytecode/BytecodeRewriter.cpp: (JSC::BytecodeRewriter::applyModification): (JSC::BytecodeRewriter::execute): (JSC::BytecodeRewriter::adjustJumpTargetsInFragment): (JSC::BytecodeRewriter::insertImpl): (JSC::BytecodeRewriter::adjustJumpTarget): (JSC::BytecodeRewriter::adjustJumpTargets): * bytecode/BytecodeRewriter.h: (JSC::BytecodeRewriter::InsertionPoint::InsertionPoint): (JSC::BytecodeRewriter::Fragment::Fragment): (JSC::BytecodeRewriter::Fragment::appendInstruction): (JSC::BytecodeRewriter::BytecodeRewriter): (JSC::BytecodeRewriter::insertFragmentBefore): (JSC::BytecodeRewriter::insertFragmentAfter): (JSC::BytecodeRewriter::removeBytecode): (JSC::BytecodeRewriter::adjustAbsoluteOffset): (JSC::BytecodeRewriter::adjustJumpTarget): * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFromLLInt): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::estimatedSize): (JSC::CodeBlock::visitChildren): (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::finalizeLLIntInlineCaches): (JSC::CodeBlock::addJITAddIC): (JSC::CodeBlock::addJITMulIC): (JSC::CodeBlock::addJITSubIC): (JSC::CodeBlock::addJITNegIC): (JSC::CodeBlock::stronglyVisitStrongReferences): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffset): (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow): (JSC::CodeBlock::hasOpDebugForLineAndColumn): (JSC::CodeBlock::getArrayProfile): (JSC::CodeBlock::updateAllArrayPredictions): (JSC::CodeBlock::predictedMachineCodeSize): (JSC::CodeBlock::tryGetValueProfileForBytecodeOffset): (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset): (JSC::CodeBlock::valueProfileForBytecodeOffset): (JSC::CodeBlock::validate): (JSC::CodeBlock::outOfLineJumpOffset): (JSC::CodeBlock::outOfLineJumpTarget): (JSC::CodeBlock::arithProfileForBytecodeOffset): (JSC::CodeBlock::arithProfileForPC): (JSC::CodeBlock::couldTakeSpecialFastCase): (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): * bytecode/CodeBlock.h: (JSC::CodeBlock::addMathIC): (JSC::CodeBlock::outOfLineJumpOffset): (JSC::CodeBlock::bytecodeOffset): (JSC::CodeBlock::instructions const): (JSC::CodeBlock::instructionCount const): (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): (JSC::CodeBlock::metadata): (JSC::CodeBlock::metadataSizeInBytes): (JSC::CodeBlock::numberOfNonArgumentValueProfiles): (JSC::CodeBlock::totalNumberOfValueProfiles): * bytecode/CodeBlockInlines.h: Added. (JSC::CodeBlock::forEachValueProfile): (JSC::CodeBlock::forEachArrayProfile): (JSC::CodeBlock::forEachArrayAllocationProfile): (JSC::CodeBlock::forEachObjectAllocationProfile): (JSC::CodeBlock::forEachLLIntCallLinkInfo): * bytecode/Fits.h: Added. * bytecode/GetByIdMetadata.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): * bytecode/Instruction.h: (JSC::Instruction::Instruction): (JSC::Instruction::Impl::opcodeID const): (JSC::Instruction::opcodeID const): (JSC::Instruction::name const): (JSC::Instruction::isWide const): (JSC::Instruction::size const): (JSC::Instruction::is const): (JSC::Instruction::as const): (JSC::Instruction::cast): (JSC::Instruction::cast const): (JSC::Instruction::narrow const): (JSC::Instruction::wide const): * bytecode/InstructionStream.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp. (JSC::InstructionStream::InstructionStream): (JSC::InstructionStream::sizeInBytes const): * bytecode/InstructionStream.h: Added. (JSC::InstructionStream::BaseRef::BaseRef): (JSC::InstructionStream::BaseRef::operator=): (JSC::InstructionStream::BaseRef::operator-> const): (JSC::InstructionStream::BaseRef::ptr const): (JSC::InstructionStream::BaseRef::operator!= const): (JSC::InstructionStream::BaseRef::next const): (JSC::InstructionStream::BaseRef::offset const): (JSC::InstructionStream::BaseRef::isValid const): (JSC::InstructionStream::BaseRef::unwrap const): (JSC::InstructionStream::MutableRef::freeze const): (JSC::InstructionStream::MutableRef::operator->): (JSC::InstructionStream::MutableRef::ptr): (JSC::InstructionStream::MutableRef::operator Ref): (JSC::InstructionStream::MutableRef::unwrap): (JSC::InstructionStream::iterator::operator*): (JSC::InstructionStream::iterator::operator++): (JSC::InstructionStream::begin const): (JSC::InstructionStream::end const): (JSC::InstructionStream::at const): (JSC::InstructionStream::size const): (JSC::InstructionStreamWriter::InstructionStreamWriter): (JSC::InstructionStreamWriter::ref): (JSC::InstructionStreamWriter::seek): (JSC::InstructionStreamWriter::position): (JSC::InstructionStreamWriter::write): (JSC::InstructionStreamWriter::rewind): (JSC::InstructionStreamWriter::finalize): (JSC::InstructionStreamWriter::swap): (JSC::InstructionStreamWriter::iterator::operator*): (JSC::InstructionStreamWriter::iterator::operator++): (JSC::InstructionStreamWriter::begin): (JSC::InstructionStreamWriter::end): * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint): (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal): (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache): * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h: * bytecode/MetadataTable.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp. (JSC::MetadataTable::MetadataTable): (JSC::DeallocTable::withOpcodeType): (JSC::MetadataTable::~MetadataTable): (JSC::MetadataTable::sizeInBytes): * bytecode/MetadataTable.h: Copied from Source/JavaScriptCore/runtime/Watchdog.h. (JSC::MetadataTable::get): (JSC::MetadataTable::forEach): (JSC::MetadataTable::getImpl): * bytecode/Opcode.cpp: (JSC::metadataSize): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/OpcodeInlines.h: (JSC::isOpcodeShape): (JSC::getOpcodeType): * bytecode/OpcodeSize.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp. * bytecode/PreciseJumpTargets.cpp: (JSC::getJumpTargetsForInstruction): (JSC::computePreciseJumpTargetsInternal): (JSC::computePreciseJumpTargets): (JSC::recomputePreciseJumpTargets): (JSC::findJumpTargetsForInstruction): * bytecode/PreciseJumpTargets.h: * bytecode/PreciseJumpTargetsInlines.h: (JSC::jumpTargetForInstruction): (JSC::extractStoredJumpTargetsForInstruction): (JSC::updateStoredJumpTargetsForInstruction): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFromLLInt): * bytecode/SpecialPointer.cpp: (WTF::printInternal): * bytecode/SpecialPointer.h: * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::UnlinkedCodeBlock::visitChildren): (JSC::UnlinkedCodeBlock::estimatedSize): (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): (JSC::dumpLineColumnEntry): (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset const): (JSC::UnlinkedCodeBlock::setInstructions): (JSC::UnlinkedCodeBlock::instructions const): (JSC::UnlinkedCodeBlock::applyModification): (JSC::UnlinkedCodeBlock::addOutOfLineJumpTarget): (JSC::UnlinkedCodeBlock::outOfLineJumpOffset): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): (JSC::UnlinkedCodeBlock::propertyAccessInstructions const): (JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): (JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const): (JSC::UnlinkedCodeBlock::metadata): (JSC::UnlinkedCodeBlock::metadataSizeInBytes): (JSC::UnlinkedCodeBlock::outOfLineJumpOffset): (JSC::UnlinkedCodeBlock::replaceOutOfLineJumpTargets): * bytecode/UnlinkedInstructionStream.cpp: Removed. * bytecode/UnlinkedInstructionStream.h: Removed. * bytecode/UnlinkedMetadataTable.h: Copied from Source/JavaScriptCore/bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h. * bytecode/UnlinkedMetadataTableInlines.h: Added. (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable): (JSC::UnlinkedMetadataTable::~UnlinkedMetadataTable): (JSC::UnlinkedMetadataTable::addEntry): (JSC::UnlinkedMetadataTable::sizeInBytes): (JSC::UnlinkedMetadataTable::finalize): (JSC::UnlinkedMetadataTable::link): (JSC::UnlinkedMetadataTable::unlink): * bytecode/VirtualRegister.cpp: (JSC::VirtualRegister::VirtualRegister): * bytecode/VirtualRegister.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::Label::setLocation): (JSC::Label::bind): (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeVarLexicalEnvironment): (JSC::BytecodeGenerator::emitEnter): (JSC::BytecodeGenerator::emitLoopHint): (JSC::BytecodeGenerator::emitJump): (JSC::BytecodeGenerator::emitCheckTraps): (JSC::BytecodeGenerator::rewind): (JSC::BytecodeGenerator::fuseCompareAndJump): (JSC::BytecodeGenerator::fuseTestAndJmp): (JSC::BytecodeGenerator::emitJumpIfTrue): (JSC::BytecodeGenerator::emitJumpIfFalse): (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall): (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply): (JSC::BytecodeGenerator::moveLinkTimeConstant): (JSC::BytecodeGenerator::moveEmptyValue): (JSC::BytecodeGenerator::emitMove): (JSC::BytecodeGenerator::emitUnaryOp): (JSC::BytecodeGenerator::emitBinaryOp): (JSC::BytecodeGenerator::emitToObject): (JSC::BytecodeGenerator::emitToNumber): (JSC::BytecodeGenerator::emitToString): (JSC::BytecodeGenerator::emitTypeOf): (JSC::BytecodeGenerator::emitInc): (JSC::BytecodeGenerator::emitDec): (JSC::BytecodeGenerator::emitEqualityOp): (JSC::BytecodeGenerator::emitProfileType): (JSC::BytecodeGenerator::emitProfileControlFlow): (JSC::BytecodeGenerator::pushLexicalScopeInternal): (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval): (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration): (JSC::BytecodeGenerator::emitOverridesHasInstance): (JSC::BytecodeGenerator::emitResolveScope): (JSC::BytecodeGenerator::emitGetFromScope): (JSC::BytecodeGenerator::emitPutToScope): (JSC::BytecodeGenerator::emitInstanceOf): (JSC::BytecodeGenerator::emitInstanceOfCustom): (JSC::BytecodeGenerator::emitInByVal): (JSC::BytecodeGenerator::emitInById): (JSC::BytecodeGenerator::emitTryGetById): (JSC::BytecodeGenerator::emitGetById): (JSC::BytecodeGenerator::emitDirectGetById): (JSC::BytecodeGenerator::emitPutById): (JSC::BytecodeGenerator::emitDirectPutById): (JSC::BytecodeGenerator::emitPutGetterById): (JSC::BytecodeGenerator::emitPutSetterById): (JSC::BytecodeGenerator::emitPutGetterSetter): (JSC::BytecodeGenerator::emitPutGetterByVal): (JSC::BytecodeGenerator::emitPutSetterByVal): (JSC::BytecodeGenerator::emitDeleteById): (JSC::BytecodeGenerator::emitGetByVal): (JSC::BytecodeGenerator::emitPutByVal): (JSC::BytecodeGenerator::emitDirectPutByVal): (JSC::BytecodeGenerator::emitDeleteByVal): (JSC::BytecodeGenerator::emitSuperSamplerBegin): (JSC::BytecodeGenerator::emitSuperSamplerEnd): (JSC::BytecodeGenerator::emitIdWithProfile): (JSC::BytecodeGenerator::emitUnreachable): (JSC::BytecodeGenerator::emitGetArgument): (JSC::BytecodeGenerator::emitCreateThis): (JSC::BytecodeGenerator::emitTDZCheck): (JSC::BytecodeGenerator::emitNewObject): (JSC::BytecodeGenerator::emitNewArrayBuffer): (JSC::BytecodeGenerator::emitNewArray): (JSC::BytecodeGenerator::emitNewArrayWithSpread): (JSC::BytecodeGenerator::emitNewArrayWithSize): (JSC::BytecodeGenerator::emitNewRegExp): (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): (JSC::BytecodeGenerator::emitNewDefaultConstructor): (JSC::BytecodeGenerator::emitNewFunction): (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded): (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitCallInTailPosition): (JSC::BytecodeGenerator::emitCallEval): (JSC::BytecodeGenerator::emitExpectedFunctionSnippet): (JSC::BytecodeGenerator::emitCallVarargs): (JSC::BytecodeGenerator::emitCallVarargsInTailPosition): (JSC::BytecodeGenerator::emitConstructVarargs): (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition): (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary): (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary): (JSC::BytecodeGenerator::emitCallDefineProperty): (JSC::BytecodeGenerator::emitReturn): (JSC::BytecodeGenerator::emitEnd): (JSC::BytecodeGenerator::emitConstruct): (JSC::BytecodeGenerator::emitStrcat): (JSC::BytecodeGenerator::emitToPrimitive): (JSC::BytecodeGenerator::emitGetScope): (JSC::BytecodeGenerator::emitPushWithScope): (JSC::BytecodeGenerator::emitGetParentScope): (JSC::BytecodeGenerator::emitDebugHook): (JSC::BytecodeGenerator::emitCatch): (JSC::BytecodeGenerator::emitThrow): (JSC::BytecodeGenerator::emitArgumentCount): (JSC::BytecodeGenerator::emitThrowStaticError): (JSC::BytecodeGenerator::beginSwitch): (JSC::prepareJumpTableForSwitch): (JSC::prepareJumpTableForStringSwitch): (JSC::BytecodeGenerator::endSwitch): (JSC::BytecodeGenerator::emitGetEnumerableLength): (JSC::BytecodeGenerator::emitHasGenericProperty): (JSC::BytecodeGenerator::emitHasIndexedProperty): (JSC::BytecodeGenerator::emitHasStructureProperty): (JSC::BytecodeGenerator::emitGetPropertyEnumerator): (JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName): (JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName): (JSC::BytecodeGenerator::emitToIndexString): (JSC::BytecodeGenerator::emitIsCellWithType): (JSC::BytecodeGenerator::emitIsObject): (JSC::BytecodeGenerator::emitIsNumber): (JSC::BytecodeGenerator::emitIsUndefined): (JSC::BytecodeGenerator::emitIsEmpty): (JSC::BytecodeGenerator::emitRestParameter): (JSC::BytecodeGenerator::emitRequireObjectCoercible): (JSC::BytecodeGenerator::emitYieldPoint): (JSC::BytecodeGenerator::emitYield): (JSC::BytecodeGenerator::emitGetAsyncIterator): (JSC::BytecodeGenerator::emitDelegateYield): (JSC::BytecodeGenerator::emitFinallyCompletion): (JSC::BytecodeGenerator::emitJumpIf): (JSC::ForInContext::finalize): (JSC::StructureForInContext::finalize): (JSC::IndexedForInContext::finalize): (JSC::StaticPropertyAnalysis::record): (JSC::BytecodeGenerator::emitToThis): * bytecompiler/BytecodeGenerator.h: (JSC::StructureForInContext::addGetInst): (JSC::BytecodeGenerator::recordOpcode): (JSC::BytecodeGenerator::addMetadataFor): (JSC::BytecodeGenerator::emitUnaryOp): (JSC::BytecodeGenerator::kill): (JSC::BytecodeGenerator::instructions const): (JSC::BytecodeGenerator::write): (JSC::BytecodeGenerator::withWriter): * bytecompiler/Label.h: (JSC::Label::Label): (JSC::Label::bind): * bytecompiler/NodesCodegen.cpp: (JSC::ArrayNode::emitBytecode): (JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount): (JSC::ApplyFunctionCallDotNode::emitBytecode): (JSC::BitwiseNotNode::emitBytecode): (JSC::BinaryOpNode::emitBytecode): (JSC::EqualNode::emitBytecode): (JSC::StrictEqualNode::emitBytecode): (JSC::emitReadModifyAssignment): (JSC::ForInNode::emitBytecode): (JSC::CaseBlockNode::emitBytecodeForBlock): (JSC::FunctionNode::emitBytecode): (JSC::ClassExprNode::emitBytecode): * bytecompiler/ProfileTypeBytecodeFlag.cpp: Copied from Source/JavaScriptCore/bytecode/VirtualRegister.cpp. (WTF::printInternal): * bytecompiler/ProfileTypeBytecodeFlag.h: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp. * bytecompiler/RegisterID.h: * bytecompiler/StaticPropertyAnalysis.h: (JSC::StaticPropertyAnalysis::create): (JSC::StaticPropertyAnalysis::StaticPropertyAnalysis): * bytecompiler/StaticPropertyAnalyzer.h: (JSC::StaticPropertyAnalyzer::createThis): (JSC::StaticPropertyAnalyzer::newObject): (JSC::StaticPropertyAnalyzer::putById): (JSC::StaticPropertyAnalyzer::mov): (JSC::StaticPropertyAnalyzer::kill): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addCall): (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): (JSC::DFG::ByteCodeParser::getArrayMode): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleVarargsCall): (JSC::DFG::ByteCodeParser::handleRecursiveTailCall): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::handleCallVariant): (JSC::DFG::ByteCodeParser::handleVarargsInlining): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::handleMinMax): (JSC::DFG::ByteCodeParser::handleIntrinsicCall): (JSC::DFG::ByteCodeParser::handleDOMJITCall): (JSC::DFG::ByteCodeParser::handleIntrinsicGetter): (JSC::DFG::ByteCodeParser::handleDOMJITGetter): (JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad): (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor): (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::parseGetById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parseCodeBlock): (JSC::DFG::ByteCodeParser::handlePutByVal): (JSC::DFG::ByteCodeParser::handlePutAccessorById): (JSC::DFG::ByteCodeParser::handlePutAccessorByVal): (JSC::DFG::ByteCodeParser::handleNewFunc): (JSC::DFG::ByteCodeParser::handleNewFuncExp): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGCapabilities.h: (JSC::DFG::capabilityLevel): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareCatchOSREntry): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueAdd): (JSC::DFG::SpeculativeJIT::compileValueSub): (JSC::DFG::SpeculativeJIT::compileValueNegate): (JSC::DFG::SpeculativeJIT::compileArithMul): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd): (JSC::FTL::DFG::LowerDFGToB3::compileValueSub): (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub): (JSC::FTL::DFG::LowerDFGToB3::compileArithMul): (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * generate-bytecode-files: Removed. * generator/Argument.rb: Added. * generator/Assertion.rb: Added. * generator/DSL.rb: Added. * generator/Fits.rb: Added. * generator/GeneratedFile.rb: Added. * generator/Metadata.rb: Added. * generator/Opcode.rb: Added. * generator/OpcodeGroup.rb: Added. * generator/Options.rb: Added. * generator/Section.rb: Added. * generator/Template.rb: Added. * generator/Type.rb: Added. * generator/main.rb: Added. * interpreter/AbstractPC.h: * interpreter/CallFrame.cpp: (JSC::CallFrame::currentVPC const): (JSC::CallFrame::setCurrentVPC): * interpreter/CallFrame.h: (JSC::CallSiteIndex::CallSiteIndex): (JSC::ExecState::setReturnPC): * interpreter/Interpreter.cpp: (WTF::printInternal): * interpreter/Interpreter.h: * interpreter/InterpreterInlines.h: * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::dump const): * interpreter/VMEntryRecord.h: * jit/JIT.cpp: (JSC::JIT::JIT): (JSC::JIT::emitSlowCaseCall): (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): (JSC::JIT::compileWithoutLinking): (JSC::JIT::link): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_jless): (JSC::JIT::emit_op_jlesseq): (JSC::JIT::emit_op_jgreater): (JSC::JIT::emit_op_jgreatereq): (JSC::JIT::emit_op_jnless): (JSC::JIT::emit_op_jnlesseq): (JSC::JIT::emit_op_jngreater): (JSC::JIT::emit_op_jngreatereq): (JSC::JIT::emitSlow_op_jless): (JSC::JIT::emitSlow_op_jlesseq): (JSC::JIT::emitSlow_op_jgreater): (JSC::JIT::emitSlow_op_jgreatereq): (JSC::JIT::emitSlow_op_jnless): (JSC::JIT::emitSlow_op_jnlesseq): (JSC::JIT::emitSlow_op_jngreater): (JSC::JIT::emitSlow_op_jngreatereq): (JSC::JIT::emit_op_below): (JSC::JIT::emit_op_beloweq): (JSC::JIT::emit_op_jbelow): (JSC::JIT::emit_op_jbeloweq): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emit_compareAndJump): (JSC::JIT::emit_compareUnsignedAndJump): (JSC::JIT::emit_compareUnsigned): (JSC::JIT::emit_compareAndJumpSlow): (JSC::JIT::emit_op_inc): (JSC::JIT::emit_op_dec): (JSC::JIT::emit_op_mod): (JSC::JIT::emitSlow_op_mod): (JSC::JIT::emit_op_negate): (JSC::JIT::emitSlow_op_negate): (JSC::JIT::emitBitBinaryOpFastPath): (JSC::JIT::emit_op_bitand): (JSC::JIT::emit_op_bitor): (JSC::JIT::emit_op_bitxor): (JSC::JIT::emit_op_lshift): (JSC::JIT::emitRightShiftFastPath): (JSC::JIT::emit_op_rshift): (JSC::JIT::emit_op_urshift): (JSC::getOperandTypes): (JSC::JIT::emit_op_add): (JSC::JIT::emitSlow_op_add): (JSC::JIT::emitMathICFast): (JSC::JIT::emitMathICSlow): (JSC::JIT::emit_op_div): (JSC::JIT::emit_op_mul): (JSC::JIT::emitSlow_op_mul): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITCall.cpp: (JSC::JIT::emitPutCallResult): (JSC::JIT::compileSetupFrame): (JSC::JIT::compileCallEval): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileTailCall): (JSC::JIT::compileOpCall): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::emit_op_call): (JSC::JIT::emit_op_tail_call): (JSC::JIT::emit_op_call_eval): (JSC::JIT::emit_op_call_varargs): (JSC::JIT::emit_op_tail_call_varargs): (JSC::JIT::emit_op_tail_call_forward_arguments): (JSC::JIT::emit_op_construct_varargs): (JSC::JIT::emit_op_construct): (JSC::JIT::emitSlow_op_call): (JSC::JIT::emitSlow_op_tail_call): (JSC::JIT::emitSlow_op_call_eval): (JSC::JIT::emitSlow_op_call_varargs): (JSC::JIT::emitSlow_op_tail_call_varargs): (JSC::JIT::emitSlow_op_tail_call_forward_arguments): (JSC::JIT::emitSlow_op_construct_varargs): (JSC::JIT::emitSlow_op_construct): * jit/JITDisassembler.cpp: (JSC::JITDisassembler::JITDisassembler): * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITInlines.h: (JSC::JIT::emitDoubleGetByVal): (JSC::JIT::emitLoadForArrayMode): (JSC::JIT::emitContiguousGetByVal): (JSC::JIT::emitArrayStorageGetByVal): (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile): (JSC::JIT::sampleInstruction): (JSC::JIT::emitValueProfilingSiteIfProfiledOpcode): (JSC::JIT::emitValueProfilingSite): (JSC::JIT::jumpTarget): (JSC::JIT::copiedGetPutInfo): (JSC::JIT::copiedArithProfile): * jit/JITMathIC.h: (JSC::isProfileEmpty): (JSC::JITBinaryMathIC::JITBinaryMathIC): (JSC::JITUnaryMathIC::JITUnaryMathIC): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_end): (JSC::JIT::emit_op_jmp): (JSC::JIT::emit_op_new_object): (JSC::JIT::emitSlow_op_new_object): (JSC::JIT::emit_op_overrides_has_instance): (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): (JSC::JIT::emit_op_instanceof_custom): (JSC::JIT::emit_op_is_empty): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_is_boolean): (JSC::JIT::emit_op_is_number): (JSC::JIT::emit_op_is_cell_with_type): (JSC::JIT::emit_op_is_object): (JSC::JIT::emit_op_ret): (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_not): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jneq_ptr): (JSC::JIT::emit_op_eq): (JSC::JIT::emit_op_jeq): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_neq): (JSC::JIT::emit_op_jneq): (JSC::JIT::emit_op_throw): (JSC::JIT::compileOpStrictEq): (JSC::JIT::emit_op_stricteq): (JSC::JIT::emit_op_nstricteq): (JSC::JIT::compileOpStrictEqJump): (JSC::JIT::emit_op_jstricteq): (JSC::JIT::emit_op_jnstricteq): (JSC::JIT::emitSlow_op_jstricteq): (JSC::JIT::emitSlow_op_jnstricteq): (JSC::JIT::emit_op_to_number): (JSC::JIT::emit_op_to_string): (JSC::JIT::emit_op_to_object): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_identity_with_profile): (JSC::JIT::emit_op_get_parent_scope): (JSC::JIT::emit_op_switch_imm): (JSC::JIT::emit_op_switch_char): (JSC::JIT::emit_op_switch_string): (JSC::JIT::emit_op_debug): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emit_op_enter): (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_to_this): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_check_tdz): (JSC::JIT::emitSlow_op_eq): (JSC::JIT::emitSlow_op_neq): (JSC::JIT::emitSlow_op_jeq): (JSC::JIT::emitSlow_op_jneq): (JSC::JIT::emitSlow_op_instanceof_custom): (JSC::JIT::emit_op_loop_hint): (JSC::JIT::emitSlow_op_loop_hint): (JSC::JIT::emit_op_check_traps): (JSC::JIT::emit_op_nop): (JSC::JIT::emit_op_super_sampler_begin): (JSC::JIT::emit_op_super_sampler_end): (JSC::JIT::emitSlow_op_check_traps): (JSC::JIT::emit_op_new_regexp): (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emit_op_new_func): (JSC::JIT::emit_op_new_generator_func): (JSC::JIT::emit_op_new_async_generator_func): (JSC::JIT::emit_op_new_async_func): (JSC::JIT::emitNewFuncExprCommon): (JSC::JIT::emit_op_new_func_exp): (JSC::JIT::emit_op_new_generator_func_exp): (JSC::JIT::emit_op_new_async_func_exp): (JSC::JIT::emit_op_new_async_generator_func_exp): (JSC::JIT::emit_op_new_array): (JSC::JIT::emit_op_new_array_with_size): (JSC::JIT::emit_op_has_structure_property): (JSC::JIT::privateCompileHasIndexedProperty): (JSC::JIT::emit_op_has_indexed_property): (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emit_op_enumerator_structure_pname): (JSC::JIT::emit_op_enumerator_generic_pname): (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): (JSC::JIT::emit_op_profile_control_flow): (JSC::JIT::emit_op_argument_count): (JSC::JIT::emit_op_get_rest_length): (JSC::JIT::emit_op_get_argument): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_to_this): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val_direct): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitPutByValWithCachedId): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_put_getter_by_id): (JSC::JIT::emit_op_put_setter_by_id): (JSC::JIT::emit_op_put_getter_setter_by_id): (JSC::JIT::emit_op_put_getter_by_val): (JSC::JIT::emit_op_put_setter_by_val): (JSC::JIT::emit_op_del_by_id): (JSC::JIT::emit_op_del_by_val): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id_direct): (JSC::JIT::emitSlow_op_get_by_id_direct): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emitSlow_op_get_by_id_with_this): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emit_op_in_by_id): (JSC::JIT::emitSlow_op_in_by_id): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): (JSC::JIT::emit_op_get_from_arguments): (JSC::JIT::emit_op_put_to_arguments): (JSC::JIT::privateCompileGetByVal): (JSC::JIT::privateCompileGetByValWithCachedId): (JSC::JIT::privateCompilePutByVal): (JSC::JIT::privateCompilePutByValWithCachedId): (JSC::JIT::emitDoubleLoad): (JSC::JIT::emitContiguousLoad): (JSC::JIT::emitArrayStorageLoad): (JSC::JIT::emitDirectArgumentsGetByVal): (JSC::JIT::emitScopedArgumentsGetByVal): (JSC::JIT::emitIntTypedArrayGetByVal): (JSC::JIT::emitFloatTypedArrayGetByVal): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jit/RegisterSet.cpp: (JSC::RegisterSet::llintBaselineCalleeSaveRegisters): * jit/SlowPathCall.h: (JSC::JITSlowPathCall::JITSlowPathCall): * llint/LLIntData.cpp: (JSC::LLInt::initialize): (JSC::LLInt::Data::performAssertions): * llint/LLIntData.h: (JSC::LLInt::exceptionInstructions): (JSC::LLInt::opcodeMap): (JSC::LLInt::opcodeMapWide): (JSC::LLInt::getOpcode): (JSC::LLInt::getOpcodeWide): (JSC::LLInt::getWideCodePtr): * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_trace_operand): (JSC::LLInt::llint_trace_value): (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::entryOSR): (JSC::LLInt::setupGetByIdPrototypeCache): (JSC::LLInt::getByVal): (JSC::LLInt::handleHostCall): (JSC::LLInt::setUpCall): (JSC::LLInt::genericCall): (JSC::LLInt::varargsSetup): (JSC::LLInt::commonCallEval): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: (JSC::CLoopRegister::operator const Instruction*): (JSC::CLoop::execute): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/asm.rb: * offlineasm/ast.rb: * offlineasm/cloop.rb: * offlineasm/generate_offset_extractor.rb: * offlineasm/instructions.rb: * offlineasm/offsets.rb: * offlineasm/parser.rb: * offlineasm/transform.rb: * offlineasm/x86.rb: * parser/ResultType.h: (JSC::ResultType::dump const): (JSC::OperandTypes::first const): (JSC::OperandTypes::second const): (JSC::OperandTypes::dump const): * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): (JSC::updateArithProfileForUnaryArithOp): (JSC::updateArithProfileForBinaryArithOp): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::tryCachePutToScopeGlobal): (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): * runtime/ExceptionFuzz.cpp: (JSC::doExceptionFuzzing): * runtime/ExceptionFuzz.h: (JSC::doExceptionFuzzingIfEnabled): * runtime/GetPutInfo.cpp: Copied from Source/JavaScriptCore/bytecode/SpecialPointer.cpp. (JSC::GetPutInfo::dump const): (WTF::printInternal): * runtime/GetPutInfo.h: (JSC::GetPutInfo::operand const): * runtime/JSCPoison.h: * runtime/JSType.cpp: Added. (WTF::printInternal): * runtime/JSType.h: * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::StackFrame::displayName): * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame): * runtime/SlowPathReturnType.h: (JSC::encodeResult): (JSC::decodeResult): * runtime/VM.h: * runtime/Watchdog.h: * tools/HeapVerifier.cpp: 2018-10-26 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r237445. https://bugs.webkit.org/show_bug.cgi?id=190972 Cause performance regression on iOS devices (Requested by yusukesuzuki on #webkit). Reverted changeset: "Unreviewed, partial rolling in r237254" https://bugs.webkit.org/show_bug.cgi?id=190340 https://trac.webkit.org/changeset/237445 2018-10-26 Mark Lam <mark.lam@apple.com> Fix missing edge cases with JSGlobalObjects having a bad time. https://bugs.webkit.org/show_bug.cgi?id=189028 <rdar://problem/45204939> Reviewed by Saam Barati. Consider the following scenario: let object O1 (of global G1) have an indexing type that is not SlowPut. let global G2 have a bad time. let object O2 (of global G2) be set as the prototype of O1. let object O3 (of global G2) have indexed accessors. In the existing code, if we set O3 as O2's prototype, we'll have a bug where O1 will not be made aware that that there are indexed accessors in its prototype chain. In this patch, we solve this issue by introducing a new invariant: A prototype chain is considered to possibly have indexed accessors if any object in the chain belongs to a global object that is having a bad time. We apply this invariant as follows: 1. Enhance JSGlobalObject::haveABadTime() to also check if other global objects are affected by it having a bad time. If so, it also ensures that those affected global objects have a bad time. The original code for JSGlobalObject::haveABadTime() uses a ObjectsWithBrokenIndexingFinder to find all objects affected by the global object having a bad time. We enhance ObjectsWithBrokenIndexingFinder to also check for the possibility that any global objects may be affected by other global objects having a bad time i.e. let g1 = global1 let g2 = global2 let o1 = an object in g1 let o2 = an object in g2 let g1 have a bad time g2 is affected if o1 is in the prototype chain of o2, and o2 may be a prototype. If the ObjectsWithBrokenIndexingFinder does find the possibility of other global objects being affected, it will abort its heap scan and let haveABadTime() take a slow path to do a more complete multi global object scan. The slow path works as follows: 1. Iterate the heap and record the graph of all global object dependencies. For each global object, record the list of other global objects that are affected by it. 2. Compute a list of global objects that need to have a bad time using the current global object dependency graph. 3. For each global object in the list of affected global objects, fire their HaveABadTime watchpoint and convert all their array structures to the SlowPut alternatives. 4. Re-run ObjectsWithBrokenIndexingFinder to find all objects that are affected by any of the globals in the list from (2). 2. Enhance Structure::mayInterceptIndexedAccesses() to also return true if the structure's global object is having a bad time. Note: there are 3 scenarios that we need to consider: let g1 = global1 let g2 = global2 let o1 = an object in g1 let o2 = an object in g2 Scenario 1: o2 is a prototype, and g1 has a bad time after o1 is inserted into the o2's prototype chain. Scenario 2: o2 is a prototype, and o1 is inserted into the o2's prototype chain after g1 has a bad time. Scenario 3: o2 is NOT a prototype, and o1 is inserted into the o2's prototype chain after g1 has a bad time. For scenario 1, when g1 has a bad time, we need to also make sure g2 has a bad time. This is handled by enhancement 1 above. For scenario 2, when o1 is inserted into o2's prototype chain, we need to check if o1's global object has a bad time. If so, then we need to make sure o2's global also has a bad time (because o2 is a prototype) and convert o2's storage type to SlowPut. This is handled by enhancement 2 above in conjunction with JSObject::setPrototypeDirect(). For scenario 3, when o1 is inserted into o2's prototype chain, we need to check if o1's global object has a bad time. If so, then we only need to convert o2's storage type to SlowPut (because o2 is NOT a prototype). This is handled by enhancement 2 above. 3. Also add $vm.isHavingABadTime(), $vm.createGlobalObject() to enable us to write some tests for this issue. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::fireWatchpointAndMakeAllArrayStructuresSlowPut): (JSC::JSGlobalObject::haveABadTime): * runtime/JSGlobalObject.h: * runtime/JSObject.h: (JSC::JSObject::mayInterceptIndexedAccesses): Deleted. * runtime/JSObjectInlines.h: (JSC::JSObject::mayInterceptIndexedAccesses): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::mayInterceptIndexedAccesses const): * tools/JSDollarVM.cpp: (JSC::functionHaveABadTime): (JSC::functionIsHavingABadTime): (JSC::functionCreateGlobalObject): (JSC::JSDollarVM::finishCreation): 2018-10-26 Keith Miller <keith_miller@apple.com> JSC xcconfig should set DEFINES_MODULE https://bugs.webkit.org/show_bug.cgi?id=190952 Reviewed by Mark Lam. This should mean that the JavaScriptCore.framework will have a module map. * Configurations/JavaScriptCore.xcconfig: 2018-10-25 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] havingABadTimeWatchpoint is not required in Array#indexOf optimization https://bugs.webkit.org/show_bug.cgi?id=190941 Reviewed by Saam Barati. While "Rest" operation fast path requires havingABadTimeWatchpoint since it allocates JSArray, Array#{indexOf,lastIndexOf} do not require it when we use the fast path for them. This patch removes watching on havingABadTimeWatchpoint in Array#indexOf. The test causing "havingABadTime" is already included in our test suites (e.g. array-indexof-have-a-bad-time.js). * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * runtime/JSArrayInlines.h: (JSC::JSArray::canDoFastIndexedAccess): * runtime/JSGlobalObject.h: * runtime/JSGlobalObjectInlines.h: (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable): (JSC::JSGlobalObject::isArrayPrototypeIndexedAccessFastAndNonObservable): Deleted. 2018-10-25 Yusuke Suzuki <yusukesuzuki@slowstart.org> Unreviewed, partial rolling in r237254 https://bugs.webkit.org/show_bug.cgi?id=190340 We do not use the added function right now to investigate what is the reason of the regression. If it causes the regression, it seems that Parser.cpp's inlining decision seems culprit. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::fromGlobalCode): * bytecode/UnlinkedFunctionExecutable.h: * parser/Parser.cpp: (JSC::Parser<LexerType>::parseInner): (JSC::Parser<LexerType>::parseSingleFunction): (JSC::Parser<LexerType>::parseFunctionInfo): (JSC::Parser<LexerType>::parseFunctionDeclaration): (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration): * parser/Parser.h: (JSC::Parser<LexerType>::parse): (JSC::parse): (JSC::parseFunctionForFunctionConstructor): * parser/ParserModes.h: * parser/ParserTokens.h: (JSC::JSTextPosition::JSTextPosition): (JSC::JSTokenLocation::JSTokenLocation): Deleted. * parser/SourceCodeKey.h: (JSC::SourceCodeKey::SourceCodeKey): (JSC::SourceCodeKey::operator== const): * runtime/CodeCache.cpp: (JSC::CodeCache::getUnlinkedGlobalCodeBlock): (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): * runtime/CodeCache.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::fromGlobalCode): * runtime/FunctionExecutable.h: 2018-10-25 Brent Fulgham <bfulgham@apple.com> Unreviewed build fix for Visual Studio 2017 * API/tests/testapi.c: (testMarkingConstraintsAndHeapFinalizers): (main): 2018-10-25 Devin Rousso <drousso@apple.com> Web Inspector: display fullscreen enter/exit events in Timelines and Network node waterfalls https://bugs.webkit.org/show_bug.cgi?id=189874 <rdar://problem/44700000> Reviewed by Joseph Pecoraro. * inspector/protocol/DOM.json: Allow `data` to be passed to the frontend with `didFireEvent`. 2018-10-25 Ross Kirsling <ross.kirsling@sony.com> Cleanup: inline constexpr is redundant as constexpr implies inline https://bugs.webkit.org/show_bug.cgi?id=190819 Reviewed by Mark Lam. * bytecode/ArrayProfile.h: (JSC::asArrayModes): * runtime/IndexingType.h: (JSC::isCopyOnWrite): * runtime/MathCommon.h: (JSC::maxSafeInteger): (JSC::minSafeInteger): * runtime/StackAlignment.h: (JSC::stackAlignmentBytes): (JSC::stackAlignmentRegisters): 2018-10-24 Megan Gardner <megan_gardner@apple.com> Turn on Conic Gradients https://bugs.webkit.org/show_bug.cgi?id=190810 Reviewed by Tim Horton. * Configurations/FeatureDefines.xcconfig: 2018-10-24 Michael Saboff <msaboff@apple.com> Increase executable memory pool from 64MB to 128MB for ARM64 https://bugs.webkit.org/show_bug.cgi?id=190453 Unreviewed, rolling back in r237024. The original change did impact ARES-6 performance by 4-8%. That will be investigated separately. 2018-10-22 Keith Rollin <krollin@apple.com> Use Location = "Relative to Build Products" rather than "Relative to Group" https://bugs.webkit.org/show_bug.cgi?id=190781 Reviewed by Alexey Proskuryakov. Almost all Derived Files are included in Xcode projects with the Location attribute set to "Relative to Group". While this currently works, the Derived Files can no longer be found when enabling XCBuild (which has stricter requirements). Fix this by setting the Location attribute to "Relative to Build Products". * JavaScriptCore.xcodeproj/project.pbxproj: 2018-10-22 Mark Lam <mark.lam@apple.com> DFGAbstractValue::m_arrayModes expects IndexingMode values, not IndexingType. https://bugs.webkit.org/show_bug.cgi?id=190515 <rdar://problem/45222379> Reviewed by Saam Barati. 1. Fixes calls to asArrayModes() to take a structure's IndexingMode instead of IndexingType. 2. DFG's compileNewArrayBuffer()'s HaveABadTime case was previously using the node's indexingType (instead of indexingMode) to choose the array structure to use for creating an array buffer with. This turns out to not be an issue because when the VM is in having a bad time, all the arrayStructureForIndexingTypeDuringAllocation structure pointers will point to the SlowPutArrayStorage structure anyway. However, to be strictly correct, we'll fix it to use the structure for the node's indexingMode. * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::mergeOSREntryValue): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::validate const): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): * dfg/DFGRegisteredStructureSet.cpp: (JSC::DFG::RegisteredStructureSet::arrayModesFromStructures const): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewArrayBuffer): 2018-10-19 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r237254. https://bugs.webkit.org/show_bug.cgi?id=190760 "It regresses JetStream 2 by 5% on some iOS devices" (Requested by saamyjoon on #webkit). Reverted changeset: "[JSC] JSC should have "parseFunction" to optimize Function constructor" https://bugs.webkit.org/show_bug.cgi?id=190340 https://trac.webkit.org/changeset/237254 2018-10-19 Saam Barati <sbarati@apple.com> vmCall should check if we exit before emitting an OSR exit due to exceptions https://bugs.webkit.org/show_bug.cgi?id=190740 <rdar://problem/45220139> Reviewed by Mark Lam. The bug we were seeing is the MovHint removal phase would eliminate a superfluous MovHint. This left a certain range of nodes in a state where they would not be able to reconstruct values for an OSR exit. This is OK, since this phase proved those nodes don't exit. However, some of these nodes may use the vmCall construct in FTLLower. vmCall used to unconditionally emit an exception check after each call. However, if such a call happens in the range of nodes where we can't exit, we would end up generating an invalid exit (and running with validateFTLOSRExitLiveness flag would find this issue). This patch makes vmCall check to see if the node can exit before emitting an exception check. A node not being able to exit implies that it can't exit for exceptions, therefore, by definition, it can't throw an exception. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::vmCall): 2018-10-19 Caio Lima <ticaiolima@gmail.com> [ESNext][BigInt] Implement support for "^" https://bugs.webkit.org/show_bug.cgi?id=186235 Reviewed by Yusuke Suzuki. This patch is introducing support for BigInt into bitwise xor operation. We are including only support into LLInt and Baseline. * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSBigInt.cpp: (JSC::JSBigInt::bitwiseXor): (JSC::JSBigInt::absoluteXor): * runtime/JSBigInt.h: 2018-10-19 Caio Lima <ticaiolima@gmail.com> [BigInt] Add ValueSub into DFG https://bugs.webkit.org/show_bug.cgi?id=186176 Reviewed by Yusuke Suzuki. We are introducing in this patch a new node called ValueSub. This node is necessary due to introduction of BigInt, making subtraction operations result in non-Number values in some cases. In such case, ValueSub is responsible to handle Untyped and BigInt operations. In addition, we are also creating a speculative path when both operands are BigInt. According to a simple BigInt subtraction microbenchmark, this represents a speedup of ~1.2x faster. big-int-simple-sub 14.6427+-0.5652 ^ 11.9559+-0.6485 ^ definitely 1.2247x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.h: (JSC::DFG::Graph::addSpeculationMode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueSub): (JSC::DFG::SpeculativeJIT::compileArithSub): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd): (JSC::FTL::DFG::LowerDFGToB3::compileValueSub): 2018-10-18 Alexey Proskuryakov <ap@apple.com> Switch from PLATFORM(IOS) to PLATFORM(IOS_FAMILY) https://bugs.webkit.org/show_bug.cgi?id=190729 Reviewed by Tim Horton. * API/JSBase.cpp: * API/JSWrapperMap.mm: * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::cacheFlush): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::cacheFlush): * assembler/AssemblerCommon.h: (JSC::isIOS): * heap/FullGCActivityCallback.cpp: (JSC::FullGCActivityCallback::doCollection): * heap/Heap.cpp: (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::updateAllocationLimits): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm: (Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget): * jit/ExecutableAllocator.cpp: (JSC::allowJIT): * jit/ExecutableAllocator.h: * jit/RegisterSet.cpp: (JSC::RegisterSet::reservedHardwareRegisters): (JSC::RegisterSet::calleeSaveRegisters): * jit/ThunkGenerators.cpp: * jsc.cpp: (main): * runtime/MathCommon.cpp: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::recomputeDependentOptions): * runtime/Options.h: 2018-10-18 Ross Kirsling <ross.kirsling@sony.com> delete expression should not throw without a reference https://bugs.webkit.org/show_bug.cgi?id=190637 Reviewed by Yusuke Suzuki. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseUnaryExpression): Eliminate non-spec-compliant switch case. 2018-10-18 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] JSC should have "parseFunction" to optimize Function constructor https://bugs.webkit.org/show_bug.cgi?id=190340 Reviewed by Mark Lam. The current Function constructor is suboptimal. We parse the piece of the same code three times to meet the spec requirement. (1) check parameters syntax, (2) check body syntax, and (3) parse the entire function. And to parse 1-3 correctly, we create two strings, the parameters and the entire function. This operation is really costly and ideally we should meet the above requirement by the one time parsing. To meet the above requirement, we add a special function for Parser, parseSingleFunction. This function takes `std::optional<int> functionConstructorParametersEndPosition` and check this end position is correct in the parser. For example, if we run the code, Function('/*', '*/){') According to the spec, this should produce '/*' parameter string and '*/){' body string. And parameter string should be syntax-checked by the parser, and raise the error since it is incorrect. Instead of doing that, in our implementation, we first create the entire string. function anonymous(/*) { */){ } And we parse it. At that time, we also pass the end position of the parameters to the parser. In the above case, the position of the `function anonymous(/*)' <> is passed. And in the parser, we check that the last token offset of the parameters is the given end position. This check allows us to raise the error correctly to the above example while we parse the entire function only once. And we do not need to create two strings too. This improves the performance of the Function constructor significantly. And web-tooling-benchmark/uglify-js is significantly sped up (28.2%). Before: uglify-js: 2.94 runs/s After: uglify-js: 3.77 runs/s * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::fromGlobalCode): * bytecode/UnlinkedFunctionExecutable.h: * parser/Parser.cpp: (JSC::Parser<LexerType>::parseInner): (JSC::Parser<LexerType>::parseSingleFunction): (JSC::Parser<LexerType>::parseFunctionInfo): (JSC::Parser<LexerType>::parseFunctionDeclaration): (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration): * parser/Parser.h: (JSC::Parser<LexerType>::parse): (JSC::parse): (JSC::parseFunctionForFunctionConstructor): * parser/ParserModes.h: * parser/ParserTokens.h: (JSC::JSTextPosition::JSTextPosition): (JSC::JSTokenLocation::JSTokenLocation): Deleted. * parser/SourceCodeKey.h: (JSC::SourceCodeKey::SourceCodeKey): (JSC::SourceCodeKey::operator== const): * runtime/CodeCache.cpp: (JSC::CodeCache::getUnlinkedGlobalCodeBlock): (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): * runtime/CodeCache.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::fromGlobalCode): * runtime/FunctionExecutable.h: 2018-10-18 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r237242. https://bugs.webkit.org/show_bug.cgi?id=190701 it breaks "stress/sampling-profiler-basic.js" (Requested by caiolima on #webkit). Reverted changeset: "[BigInt] Add ValueSub into DFG" https://bugs.webkit.org/show_bug.cgi?id=186176 https://trac.webkit.org/changeset/237242 2018-10-18 Takafumi Kubota <takafumi.kubota1012@sslab.ics.keio.ac.jp> Missing #pragma once in WasmOpcodeOrigin.h https://bugs.webkit.org/show_bug.cgi?id=190699 Reviewed by Yusuke Suzuki. This patch add ''#pragma once'' into WasmOpcodeOrigin.h to avoid the multiple inclusion that can happen in the unified build configuration. * wasm/WasmOpcodeOrigin.h: 2018-10-17 Wenson Hsieh <wenson_hsieh@apple.com> Enable the datalist element by default on iOS and macOS https://bugs.webkit.org/show_bug.cgi?id=190594 <rdar://problem/45281159> Reviewed by Ryosuke Niwa and Tim Horton. * Configurations/FeatureDefines.xcconfig: 2018-10-17 Caio Lima <ticaiolima@gmail.com> [BigInt] Add ValueSub into DFG https://bugs.webkit.org/show_bug.cgi?id=186176 Reviewed by Yusuke Suzuki. We are introducing in this patch a new node called ValueSub. This node is necessary due to introduction of BigInt, making subtraction operations result in non-Number values in some cases. In such case, ValueSub is responsible to handle Untyped and BigInt operations. In addition, we are also creating a speculative path when both operands are BigInt. According to a simple BigInt subtraction microbenchmark, this represents a speedup of ~1.2x faster. big-int-simple-sub 14.6427+-0.5652 ^ 11.9559+-0.6485 ^ definitely 1.2247x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.h: (JSC::DFG::Graph::addSpeculationMode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueSub): (JSC::DFG::SpeculativeJIT::compileArithSub): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd): (JSC::FTL::DFG::LowerDFGToB3::compileValueSub): 2018-10-17 Mark Lam <mark.lam@apple.com> The parser should not emit a ApplyFunctionCallDotNode for Reflect.apply. https://bugs.webkit.org/show_bug.cgi?id=190671 <rdar://problem/45201145> Reviewed by Saam Barati. The bytecode generator does not currently know how to inline Reflect.apply (see https://bugs.webkit.org/show_bug.cgi?id=190668). Hence, it's a waste of time to emit the ApplyFunctionCallDotNode since the function check against Function.apply that it will generate will always fail. Also fixed CallVariant::dump() to be able to handle dumping a non-executable callee. Reflect.apply used to trip this up. Any object with an apply property invoked as a function could also trip this up. This is now fixed. * bytecode/CallVariant.cpp: (JSC::CallVariant::dump const): * bytecompiler/NodesCodegen.cpp: (JSC::ApplyFunctionCallDotNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::makeFunctionCallNode): 2018-10-17 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r237024. https://bugs.webkit.org/show_bug.cgi?id=190673 "It regressed ARES6 on iOS devices by 4-8%" (Requested by saamyjoon on #webkit). Reverted changeset: "Increase executable memory pool from 64MB to 128MB for ARM64" https://bugs.webkit.org/show_bug.cgi?id=190453 https://trac.webkit.org/changeset/237024 2018-10-17 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Use WTF::Function instead of std::function https://bugs.webkit.org/show_bug.cgi?id=190665 Reviewed by Keith Miller. We should use WTF::Function as much as possible. It allocates memory from bmalloc instead of standard malloc. * runtime/JSNativeStdFunction.h: 2018-10-17 Keith Miller <keith_miller@apple.com> Remove debug logging from generate_offsets_extractor.rb https://bugs.webkit.org/show_bug.cgi?id=190667 Reviewed by Mark Lam. * offlineasm/generate_offset_extractor.rb: 2018-10-17 Keith Miller <keith_miller@apple.com> AI does not clear Phantom allocation nodes. https://bugs.webkit.org/show_bug.cgi?id=190694 Reviewed by Saam Barati. Phantom nodes claim to have a result so they should make sure they clear their abstract values. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): 2018-10-17 Keith Miller <keith_miller@apple.com> Unreviewed, fix windows build. * offlineasm/generate_offset_extractor.rb: 2018-10-17 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] More aggressively use `constexpr` in LowLevelInterpreter.asm for constant values https://bugs.webkit.org/show_bug.cgi?id=190659 Reviewed by Keith Miller. Asking the actual constant value to the JSC binary is always the best way to get the correct value. The value is correctly updated once the original value is changed. We would like to encourage this approach more in LowLevelInterpreter.asm. This patch expands the coverage of this approach. We make ObservedType, ResultType, and ArithProfile constexpr-friendly to produce the magic value used in LowLevelInterpreter.asm at compiling time. This change allows us to easily extend ArithProfile in the future to adopt BigInt efficiently. We additionally use `constexpr` for several constant values in LowLevelInterpreter.asm. * assembler/MaxFrameExtentForSlowPathCall.h: Use this value in LowLevelInterpreter.asm directly. We also make them constexpr. And we add CPU(ARM64E). * bytecode/ArithProfile.h: (JSC::ObservedType::ObservedType): (JSC::ObservedType::sawInt32 const): (JSC::ObservedType::isOnlyInt32 const): (JSC::ObservedType::sawNumber const): (JSC::ObservedType::isOnlyNumber const): (JSC::ObservedType::sawNonNumber const): (JSC::ObservedType::isOnlyNonNumber const): (JSC::ObservedType::isEmpty const): (JSC::ObservedType::bits const): (JSC::ObservedType::withInt32 const): (JSC::ObservedType::withNumber const): (JSC::ObservedType::withNonNumber const): (JSC::ObservedType::withoutNonNumber const): (JSC::ObservedType::operator== const): (JSC::ArithProfile::ArithProfile): (JSC::ArithProfile::fromInt): (JSC::ArithProfile::observedUnaryInt): (JSC::ArithProfile::observedUnaryNumber): (JSC::ArithProfile::observedBinaryIntInt): (JSC::ArithProfile::observedBinaryNumberInt): (JSC::ArithProfile::observedBinaryIntNumber): (JSC::ArithProfile::observedBinaryNumberNumber): (JSC::ArithProfile::lhsObservedType const): (JSC::ArithProfile::rhsObservedType const): (JSC::ArithProfile::bits const): Make ObservedType and ArithProfile constexpr-friendly. * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): Make several ASSERTs to STATIC_ASSERTs. Remove some unnecessary checks. * llint/LLIntOffsetsExtractor.cpp: * llint/LowLevelInterpreter.asm: Remove unused constant values. Use constexpr more and more aggressively. * parser/ResultType.h: (JSC::ResultType::ResultType): (JSC::ResultType::isInt32 const): (JSC::ResultType::definitelyIsNumber const): (JSC::ResultType::definitelyIsString const): (JSC::ResultType::definitelyIsBoolean const): (JSC::ResultType::definitelyIsBigInt const): (JSC::ResultType::mightBeNumber const): (JSC::ResultType::isNotNumber const): (JSC::ResultType::mightBeBigInt const): (JSC::ResultType::isNotBigInt const): (JSC::ResultType::nullType): (JSC::ResultType::booleanType): (JSC::ResultType::numberType): (JSC::ResultType::numberTypeIsInt32): (JSC::ResultType::stringOrNumberType): (JSC::ResultType::addResultType): (JSC::ResultType::stringType): (JSC::ResultType::bigIntType): (JSC::ResultType::unknownType): (JSC::ResultType::forAdd): (JSC::ResultType::forLogicalOp): (JSC::ResultType::forBitOp): (JSC::ResultType::bits const): Make ResultType constexpr-friendly. * runtime/JSCJSValue.h: Use offsetof instead of OBJECT_OFFSETOF. It is OK since EncodedValueDescriptor is POD. This change makes TagOffset and PayloadOffset macros constexpr-friendly while OBJECT_OFFSETOF cannot be used in constexpr since it uses reinterpret_cast. 2018-10-17 Keith Miller <keith_miller@apple.com> Unreviewed revert Fujii's revert in r237214 with new WinCairo build fix. 2018-10-16 Mark Lam <mark.lam@apple.com> GetIndexedPropertyStorage can GC. https://bugs.webkit.org/show_bug.cgi?id=190625 <rdar://problem/45309366> Reviewed by Saam Barati. This is because if the ArrayMode type is String, the DFG and FTL will be emitting a call to operationResolveRope, and operationResolveRope can GC. This patch updates doesGC() to reflect this. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): 2018-10-16 Fujii Hironori <Hironori.Fujii@sony.com> Unreviewed, rolling out r237188, r237189, and r237197. It breaks WinCairo Debug builds and Release LayoutTests Reverted changesets: https://bugs.webkit.org/show_bug.cgi?id=189708 https://trac.webkit.org/changeset/237188 "Unreviewed, forgot to add untracked files." https://trac.webkit.org/changeset/237189 "isASTErroneous in offlineasm should de-macroify before looking for Errors" https://bugs.webkit.org/show_bug.cgi?id=190634 https://trac.webkit.org/changeset/237197 2018-10-16 Devin Rousso <drousso@apple.com> Web Inspector: Canvas: capture previously saved states and add them to the recording payload https://bugs.webkit.org/show_bug.cgi?id=190473 Reviewed by Joseph Pecoraro. * inspector/protocol/Recording.json: Add `states` key to `InitialState` object. 2018-10-16 Keith Miller <keith_miller@apple.com> isASTErroneous in offlineasm should de-macroify before looking for Errors https://bugs.webkit.org/show_bug.cgi?id=190634 Reviewed by Mark Lam. If a macro isn't usable in a configuration it might still cause us to think the ast is invalid. This change runs the de-macroifier before looking for errors. Also, it adds a missing include to Printer.h. * assembler/Printer.h: * offlineasm/settings.rb: 2018-10-16 Justin Michaud <justin_michaud@apple.com> Implement feature flag and bindings for CSS Painting API https://bugs.webkit.org/show_bug.cgi?id=190237 Reviewed by Ryosuke Niwa. * Configurations/FeatureDefines.xcconfig: 2018-10-16 Keith Miller <keith_miller@apple.com> Unreviewed, forgot to add untracked files. * llint/LLIntSettingsExtractor.cpp: Added. (main): * offlineasm/generate_settings_extractor.rb: Added. 2018-10-16 Keith Miller <keith_miller@apple.com> Unreviewed, reland https://bugs.webkit.org/show_bug.cgi?id=189708 with build fix. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * llint/LLIntOffsetsExtractor.cpp: (JSC::LLIntOffsetsExtractor::dummy): * offlineasm/generate_offset_extractor.rb: * offlineasm/offsets.rb: * offlineasm/settings.rb: 2018-10-16 Keith Miller <keith_miller@apple.com> Unreviewed, add missing include. * runtime/BasicBlockLocation.h: 2018-10-15 Keith Miller <keith_miller@apple.com> Support arm64 CPUs with a 32-bit address space https://bugs.webkit.org/show_bug.cgi?id=190273 Reviewed by Michael Saboff. This patch adds support for arm64_32 in the LLInt. In order to make this work we needed to add a new type that reflects the size of a cpu register. This type is called CPURegister or UCPURegister for the unsigned version. Most places that used void* or intptr_t to refer to a register have been changed to use this new type. * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/ARM64Assembler.h: (JSC::isInt): (JSC::is4ByteAligned): (JSC::PairPostIndex::PairPostIndex): (JSC::PairPreIndex::PairPreIndex): (JSC::ARM64Assembler::readPointer): (JSC::ARM64Assembler::readCallTarget): (JSC::ARM64Assembler::computeJumpType): (JSC::ARM64Assembler::linkCompareAndBranch): (JSC::ARM64Assembler::linkConditionalBranch): (JSC::ARM64Assembler::linkTestAndBranch): (JSC::ARM64Assembler::loadRegisterLiteral): (JSC::ARM64Assembler::loadStoreRegisterPairPostIndex): (JSC::ARM64Assembler::loadStoreRegisterPairPreIndex): (JSC::ARM64Assembler::loadStoreRegisterPairOffset): (JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal): (JSC::isInt7): Deleted. (JSC::isInt11): Deleted. * assembler/CPU.h: (JSC::isAddress64Bit): (JSC::isAddress32Bit): * assembler/MacroAssembler.h: (JSC::MacroAssembler::shouldBlind): * assembler/MacroAssemblerARM64.cpp: (JSC::MacroAssemblerARM64::collectCPUFeatures): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load): (JSC::MacroAssemblerARM64::store): (JSC::MacroAssemblerARM64::isInIntRange): Deleted. * assembler/Printer.h: * assembler/ProbeContext.h: (JSC::Probe::CPUState::gpr): (JSC::Probe::CPUState::spr): (JSC::Probe::Context::gpr): (JSC::Probe::Context::spr): * b3/B3ConstPtrValue.h: * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::isArgValidForRep): * b3/air/AirArg.h: (JSC::B3::Air::Arg::stackSlot const): (JSC::B3::Air::Arg::special const): * b3/air/testair.cpp: * b3/testb3.cpp: (JSC::B3::testStoreConstantPtr): (JSC::B3::testInterpreter): (JSC::B3::testAddShl32): (JSC::B3::testLoadBaseIndexShift32): * bindings/ScriptFunctionCall.cpp: (Deprecated::ScriptCallArgumentHandler::appendArgument): * bindings/ScriptFunctionCall.h: * bytecode/CodeBlock.cpp: (JSC::roundCalleeSaveSpaceAsVirtualRegisters): * dfg/DFGOSRExit.cpp: (JSC::DFG::restoreCalleeSavesFor): (JSC::DFG::saveCalleeSavesFor): (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * disassembler/UDis86Disassembler.cpp: (JSC::tryToDisassembleWithUDis86): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileWeakMapGet): * heap/MachineStackMarker.cpp: (JSC::copyMemory): * interpreter/CallFrame.h: (JSC::ExecState::returnPC const): (JSC::ExecState::hasReturnPC const): (JSC::ExecState::clearReturnPC): (JSC::ExecState::returnPCOffset): (JSC::ExecState::isGlobalExec const): (JSC::ExecState::setReturnPC): * interpreter/CalleeBits.h: (JSC::CalleeBits::boxWasm): (JSC::CalleeBits::isWasm const): (JSC::CalleeBits::asWasmCallee const): * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const): * interpreter/VMEntryRecord.h: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::clearStackFrame): * jit/RegisterAtOffset.h: (JSC::RegisterAtOffset::offsetAsIndex const): * jit/RegisterAtOffsetList.cpp: (JSC::RegisterAtOffsetList::RegisterAtOffsetList): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntOfflineAsmConfig.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/asm.rb: * offlineasm/ast.rb: * offlineasm/backends.rb: * offlineasm/parser.rb: * offlineasm/x86.rb: * runtime/BasicBlockLocation.cpp: (JSC::BasicBlockLocation::dumpData const): (JSC::BasicBlockLocation::emitExecuteCode const): * runtime/BasicBlockLocation.h: * runtime/HasOwnPropertyCache.h: * runtime/JSBigInt.cpp: (JSC::JSBigInt::inplaceMultiplyAdd): (JSC::JSBigInt::digitDiv): * runtime/JSBigInt.h: * runtime/JSObject.h: * runtime/Options.cpp: (JSC::jitEnabledByDefault): * runtime/Options.h: * runtime/RegExp.cpp: (JSC::RegExp::printTraceData): * runtime/SamplingProfiler.cpp: (JSC::CFrameWalker::walk): * runtime/SlowPathReturnType.h: (JSC::encodeResult): (JSC::decodeResult): * tools/SigillCrashAnalyzer.cpp: (JSC::SigillCrashAnalyzer::dumpCodeBlock): 2018-10-15 Justin Fan <justin_fan@apple.com> Add WebGPU 2018 feature flag and experimental feature flag https://bugs.webkit.org/show_bug.cgi?id=190509 Reviewed by Dean Jackson. Re-add ENABLE_WEBGPU, an experimental feature flag, and a RuntimeEnabledFeature for the 2018 WebGPU prototype. * Configurations/FeatureDefines.xcconfig: 2018-10-15 Timothy Hatcher <timothy@apple.com> Add support for prefers-color-scheme media query https://bugs.webkit.org/show_bug.cgi?id=190499 rdar://problem/45212025 Reviewed by Dean Jackson. * Configurations/FeatureDefines.xcconfig: Added ENABLE_DARK_MODE_CSS. 2018-10-15 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r237084, r237088, r237098, and r237114. https://bugs.webkit.org/show_bug.cgi?id=190602 Breaks internal builds. (Requested by ryanhaddad on #webkit). Reverted changesets: "Separate configuration extraction from offset extraction" https://bugs.webkit.org/show_bug.cgi?id=189708 https://trac.webkit.org/changeset/237084 "Gardening: Build fix after r237084." https://bugs.webkit.org/show_bug.cgi?id=189708 https://trac.webkit.org/changeset/237088 "Gardening: Build fix after r237084." https://bugs.webkit.org/show_bug.cgi?id=189708 https://trac.webkit.org/changeset/237098 "REGRESSION (r237084): JavaScriptCore fails to build on Linux" https://trac.webkit.org/changeset/237114 2018-10-15 Keith Miller <keith_miller@apple.com> BytecodeDumper should print all switch labels https://bugs.webkit.org/show_bug.cgi?id=190596 Reviewed by Saam Barati. Right now the bytecode dumper only prints the default target not any of the non-default targets. * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper<Block>::dumpBytecode): 2018-10-15 Saam barati <sbarati@apple.com> Emit fjcvtzs on ARM64E on Darwin https://bugs.webkit.org/show_bug.cgi?id=184023 Reviewed by Yusuke Suzuki and Filip Pizlo. ARMv8.3 introduced the fjcvtzs instruction which does double->int32 conversion using the semantics defined by JavaScript: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801g/hko1477562192868.html This patch teaches JSC to use that instruction when possible. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::fjcvtzs): (JSC::ARM64Assembler::fjcvtzsInsn): * assembler/MacroAssemblerARM64.cpp: (JSC::MacroAssemblerARM64::collectCPUFeatures): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::supportsDoubleToInt32ConversionUsingJavaScriptSemantics): (JSC::MacroAssemblerARM64::convertDoubleToInt32UsingJavaScriptSemantics): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueToInt32): * disassembler/ARM64/A64DOpcode.cpp: * disassembler/ARM64/A64DOpcode.h: (JSC::ARM64Disassembler::A64DOpcode::appendInstructionName): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32): * jit/JITRightShiftGenerator.cpp: (JSC::JITRightShiftGenerator::generateFastPath): * runtime/MathCommon.h: (JSC::toInt32): 2018-10-15 Saam Barati <sbarati@apple.com> JSArray::shiftCountWithArrayStorage is wrong when an array has holes https://bugs.webkit.org/show_bug.cgi?id=190262 <rdar://problem/44986241> Reviewed by Mark Lam. We would take the fast path for shiftCountWithArrayStorage when the array hasHoles(). However, the code for this was wrong. It'd incorrectly update ArrayStorage::m_numValuesInVector. Since the hasHoles() for ArrayStorage path is never taken in JetStream 2, this patch just removes that from the fast path. Instead, we just fallback to the slow path when hasHoles(). If we find evidence that this matters for real use cases, we can figure out a way to make the fast path work. * runtime/JSArray.cpp: (JSC::JSArray::shiftCountWithArrayStorage): 2018-10-15 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r237054. https://bugs.webkit.org/show_bug.cgi?id=190593 "this regressed JetStream 2 by 6% on iOS" (Requested by saamyjoon on #webkit). Reverted changeset: "[JSC] JSC should have "parseFunction" to optimize Function constructor" https://bugs.webkit.org/show_bug.cgi?id=190340 https://trac.webkit.org/changeset/237054 2018-10-14 David Kilzer <ddkilzer@apple.com> REGRESSION (r237084): JavaScriptCore fails to build on Linux <https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10949> * llint/LLIntSettingsExtractor.cpp: Attempt to fix build by including <stdio.h>. 2018-10-15 Alex Christensen <achristensen@webkit.org> Shrink more enum classes https://bugs.webkit.org/show_bug.cgi?id=190540 Reviewed by Chris Dumez. * runtime/ConsoleTypes.h: 2018-10-15 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Disable DOMJIT on 32bit architecture https://bugs.webkit.org/show_bug.cgi?id=190387 Reviewed by Mark Lam. We disable DOMJIT on 32bit architecture due to exhaustion of registers. * runtime/Options.h: 2018-10-15 Alex Christensen <achristensen@webkit.org> Include EnumTraits.h less https://bugs.webkit.org/show_bug.cgi?id=190535 Reviewed by Chris Dumez. * runtime/ConsoleTypes.h: 2018-10-14 Mark Lam <mark.lam@apple.com> Gardening: Build fix after r237084. https://bugs.webkit.org/show_bug.cgi?id=189708 Unreviewd. * llint/LLIntOffsetsExtractor.cpp: 2018-10-14 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Remove Option::useAsyncIterator https://bugs.webkit.org/show_bug.cgi?id=190567 Reviewed by Saam Barati. Async iterator is enabled by default at 2017-08-09. It is already shipped in several releases, and we can think that it is already mature. Let's drop the option `Option::useAsyncIterator`. * Configurations/FeatureDefines.xcconfig: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): (JSC::BytecodeGenerator::emitNewFunction): * parser/ASTBuilder.h: (JSC::ASTBuilder::createFunctionMetadata): * parser/Parser.cpp: (JSC::Parser<LexerType>::parseForStatement): (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration): (JSC::Parser<LexerType>::parseClass): (JSC::Parser<LexerType>::parseProperty): (JSC::Parser<LexerType>::parseAsyncFunctionExpression): * runtime/Options.h: 2018-10-14 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Remove Options::useObjectRestSpread https://bugs.webkit.org/show_bug.cgi?id=190568 Reviewed by Saam Barati. Options::useObjectRestSpread is enabled by default at 2017-06-27. It is already shipped in several releases, and we can think that it is mature. Let's drop Options::useObjectRestSpread() flag. * parser/Parser.cpp: (JSC::Parser<LexerType>::Parser): (JSC::Parser<LexerType>::parseDestructuringPattern): (JSC::Parser<LexerType>::parseProperty): * parser/Parser.h: * runtime/Options.h: 2018-10-13 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] JSON.stringify can accept call-with-no-arguments https://bugs.webkit.org/show_bug.cgi?id=190343 Reviewed by Mark Lam. JSON.stringify can accept `JSON.stringify()` call (call-with-no-arguments) according to the spec[1]. Instead of throwing an error, we should take the first argument as `undefined` if it is not given. [1]: https://tc39.github.io/ecma262/#sec-json.stringify * runtime/JSONObject.cpp: (JSC::JSONProtoFuncStringify): 2018-10-12 Tadeu Zagallo <tzagallo@apple.com> Gardening: Build fix after r237084. https://bugs.webkit.org/show_bug.cgi?id=189708 Unreviewd. * JavaScriptCore.xcodeproj/project.pbxproj: 2018-10-12 Tadeu Zagallo <tzagallo@apple.com> Separate configuration extraction from offset extraction https://bugs.webkit.org/show_bug.cgi?id=189708 Reviewed by Keith Miller. Instead of generating a file with all offsets for every combination of configurations, we first generate a file with only the configuration indices and pass that to the offset extractor. The offset extractor then only generates the offsets for valid configurations * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * llint/LLIntOffsetsExtractor.cpp: (JSC::LLIntOffsetsExtractor::dummy): * llint/LLIntSettingsExtractor.cpp: Added. (main): * offlineasm/generate_offset_extractor.rb: * offlineasm/generate_settings_extractor.rb: Added. * offlineasm/offsets.rb: * offlineasm/settings.rb: 2018-10-12 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r237063. Caused layout test fast/dom/Window/window-postmessage-clone- deep-array.html to fail on macOS and iOS Debug bots. Reverted changeset: "[JSC] Remove gcc warnings on mips and armv7" https://bugs.webkit.org/show_bug.cgi?id=188598 https://trac.webkit.org/changeset/237063 2018-10-11 Guillaume Emont <guijemont@igalia.com> [JSC] Remove gcc warnings on mips and armv7 https://bugs.webkit.org/show_bug.cgi?id=188598 Reviewed by Mark Lam. Fix many gcc/clang warnings that are false positives, mostly alignment issues. * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printMemory): Use bitwise_cast instead of reinterpret_cast. * assembler/testmasm.cpp: (JSC::floatOperands): marked as potentially unused as it is not used on all platforms. (JSC::testProbeModifiesStackValues): modifiedFlags is not used on mips, so don't declare it. * bytecode/CodeBlock.h: Make ScriptExecutable::prepareForExecution() return an std::optional<Exception*> instead of a JSObject*. * interpreter/Interpreter.cpp: (JSC::Interpreter::executeProgram): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): (JSC::Interpreter::execute): (JSC::Interpreter::executeModuleProgram): Update calling code for the prototype change of ScriptExecutable::prepareForExecution(). * jit/JITOperations.cpp: Same as for Interpreter.cpp. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setUpCall): Same as for Interpreter.cpp. * runtime/JSBigInt.cpp: (JSC::JSBigInt::dataStorage): Use bitwise_cast instead of reinterpret_cast. * runtime/ScriptExecutable.cpp: * runtime/ScriptExecutable.h: Make ScriptExecutable::prepareForExecution() return an std::optional<Exception*> instead of a JSObject*. * tools/JSDollarVM.cpp: (JSC::codeBlockFromArg): Use bitwise_cast instead of reinterpret_cast. 2018-10-11 Yusuke Suzuki <yusukesuzuki@slowstart.org> Use currentStackPointer more https://bugs.webkit.org/show_bug.cgi?id=190503 Reviewed by Saam Barati. * runtime/VM.cpp: (JSC::VM::committedStackByteCount): 2018-10-08 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] JSC should have "parseFunction" to optimize Function constructor https://bugs.webkit.org/show_bug.cgi?id=190340 Reviewed by Mark Lam. The current Function constructor is suboptimal. We parse the piece of the same code three times to meet the spec requirement. (1) check parameters syntax, (2) check body syntax, and (3) parse the entire function. And to parse 1-3 correctly, we create two strings, the parameters and the entire function. This operation is really costly and ideally we should meet the above requirement by the one time parsing. To meet the above requirement, we add a special function for Parser, parseSingleFunction. This function takes `std::optional<int> functionConstructorParametersEndPosition` and check this end position is correct in the parser. For example, if we run the code, Function('/*', '*/){') According to the spec, this should produce '/*' parameter string and '*/){' body string. And parameter string should be syntax-checked by the parser, and raise the error since it is incorrect. Instead of doing that, in our implementation, we first create the entire string. function anonymous(/*) { */){ } And we parse it. At that time, we also pass the end position of the parameters to the parser. In the above case, the position of the `function anonymous(/*)' <> is passed. And in the parser, we check that the last token offset of the parameters is the given end position. This check allows us to raise the error correctly to the above example while we parse the entire function only once. And we do not need to create two strings too. This improves the performance of the Function constructor significantly. And web-tooling-benchmark/uglify-js is significantly sped up (28.2%). Before: uglify-js: 2.94 runs/s After: uglify-js: 3.77 runs/s * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::fromGlobalCode): * bytecode/UnlinkedFunctionExecutable.h: * parser/Parser.cpp: (JSC::Parser<LexerType>::parseInner): (JSC::Parser<LexerType>::parseSingleFunction): (JSC::Parser<LexerType>::parseFunctionInfo): (JSC::Parser<LexerType>::parseFunctionDeclaration): (JSC::Parser<LexerType>::parseAsyncFunctionDeclaration): (JSC::Parser<LexerType>::parseClass): (JSC::Parser<LexerType>::parsePropertyMethod): (JSC::Parser<LexerType>::parseGetterSetter): (JSC::Parser<LexerType>::parseFunctionExpression): (JSC::Parser<LexerType>::parseAsyncFunctionExpression): (JSC::Parser<LexerType>::parseArrowFunctionExpression): * parser/Parser.h: (JSC::Parser<LexerType>::parse): (JSC::parse): (JSC::parseFunctionForFunctionConstructor): * parser/ParserModes.h: * parser/ParserTokens.h: (JSC::JSTextPosition::JSTextPosition): (JSC::JSTokenLocation::JSTokenLocation): Deleted. * parser/SourceCodeKey.h: (JSC::SourceCodeKey::SourceCodeKey): (JSC::SourceCodeKey::operator== const): * runtime/CodeCache.cpp: (JSC::CodeCache::getUnlinkedGlobalCodeBlock): (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable): * runtime/CodeCache.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/FunctionExecutable.cpp: (JSC::FunctionExecutable::fromGlobalCode): * runtime/FunctionExecutable.h: 2018-10-11 Ross Kirsling <ross.kirsling@sony.com> Fix non-existent define `CPU(JSVALUE64)` https://bugs.webkit.org/show_bug.cgi?id=190479 Reviewed by Yusuke Suzuki. * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsImpl): Correct CPU(JSVALUE64) to USE(JSVALUE64). 2018-10-11 Keith Rollin <krollin@apple.com> CURRENT_ARCH should not be used in Run Script phase. https://bugs.webkit.org/show_bug.cgi?id=190407 <rdar://problem/45133556> Reviewed by Alexey Proskuryakov. CURRENT_ARCH is used in a number of Xcode Run Script phases. However, CURRENT_ARCH is not well-defined during this phase (and may even have the value "undefined") since this phase is run just once per build rather than once per supported architecture. Migrate away from CURRENT_ARCH in favor of ARCHS, either by iterating over ARCHS and performing an operation for each value, or by picking the first entry in ARCHS and using that as a representative value. * JavaScriptCore.xcodeproj/project.pbxproj: Store LLIntDesiredOffsets.h into a directory with a name based on ARCHS rather than CURRENT_ARCH. 2018-10-10 Mark Lam <mark.lam@apple.com> Changes towards allowing use of the ASAN detect_stack_use_after_return option. https://bugs.webkit.org/show_bug.cgi?id=190405 <rdar://problem/45131464> Reviewed by Michael Saboff. The ASAN detect_stack_use_after_return option checks for use of stack variables after they have been freed. It does this by allocating relevant stack variables in heap memory (instead of on the stack) if the code ever takes the address of those stack variables. Unfortunately, this is a common idiom that we use to compute the approximate stack pointer value. As a result, on such ASAN runs, the computed approximate stack pointer value will point into the heap instead of the stack. This breaks the VM's expectations and wreaks havoc. To fix this, we use the newly introduced WTF::currentStackPointer() instead of taking the address of stack variables. We also need to enhance ExceptionScopes to be able to work with ASAN detect_stack_use_after_return which will allocated the scope in the heap. We work around this by passing the current stack pointer of the instantiating calling frame into the scope constructor, and using that for the position check in ~ThrowScope() instead. The above is only a start towards enabling ASAN detect_stack_use_after_return on the VM. There are still other issues to be resolved before we can run with this ASAN option. * runtime/CatchScope.h: * runtime/ExceptionEventLocation.h: (JSC::ExceptionEventLocation::ExceptionEventLocation): * runtime/ExceptionScope.h: (JSC::ExceptionScope::stackPosition const): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/ThrowScope.cpp: (JSC::ThrowScope::~ThrowScope): * runtime/ThrowScope.h: * runtime/VM.h: (JSC::VM::needExceptionCheck const): (JSC::VM::isSafeToRecurse const): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse const): 2018-10-10 Devin Rousso <drousso@apple.com> Web Inspector: create special Network waterfall for media events https://bugs.webkit.org/show_bug.cgi?id=189773 <rdar://problem/44626605> Reviewed by Joseph Pecoraro. * inspector/protocol/DOM.json: Add `didFireEvent` event that is fired when specific event listeners added by `InspectorInstrumentation::addEventListenersToNode` are fired. 2018-10-10 Michael Saboff <msaboff@apple.com> Increase executable memory pool from 64MB to 128MB for ARM64 https://bugs.webkit.org/show_bug.cgi?id=190453 Reviewed by Saam Barati. * jit/ExecutableAllocator.cpp: 2018-10-10 Devin Rousso <drousso@apple.com> Web Inspector: notify the frontend when a canvas has started recording via console.record https://bugs.webkit.org/show_bug.cgi?id=190306 Reviewed by Brian Burg. * inspector/protocol/Canvas.json: Add `recordingStarted` event. * inspector/protocol/Recording.json: Add `Initiator` enum for determining who started the recording. 2018-10-10 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Rename createXXX to tryCreateXXX if it can return RefPtr https://bugs.webkit.org/show_bug.cgi?id=190429 Reviewed by Saam Barati. Some createXXX functions can fail. But sometimes the caller does not perform error checking. To make it explicit that these functions can fail, we rename these functions from createXXX to tryCreateXXX. In this patch, we focus on non-JS-managed factory functions. If the factory function does not fail, it should return Ref<>. Otherwise, it should be named as tryCreateXXX and it should return RefPtr<>. This patch mainly focuses on TypedArray factory functions. Previously, these functions are `RefPtr<XXXArray> create(...)`. This patch changes them to `RefPtr<XXXArray> tryCreate(...)`. And we also introduce `Ref<XXXArray> create(...)` function which internally performs RELEASE_ASSERT on the result of `tryCreate(...)`. And we also convert OpaqueJSString::create to OpaqueJSString::tryCreate since it can fail. This change actually finds one place which does not perform any null checkings while it uses `RefPtr<> create(...)` function. * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject<Parent>::getOwnPropertySlot): (JSC::JSCallbackObject<Parent>::put): (JSC::JSCallbackObject<Parent>::putByIndex): (JSC::JSCallbackObject<Parent>::deleteProperty): (JSC::JSCallbackObject<Parent>::callbackGetter): * API/JSClassRef.h: (StaticValueEntry::StaticValueEntry): * API/JSContext.mm: (-[JSContext evaluateScript:withSourceURL:]): (-[JSContext setName:]): * API/JSContextRef.cpp: (JSGlobalContextCopyName): (JSContextCreateBacktrace): * API/JSObjectRef.cpp: (JSObjectCopyPropertyNames): * API/JSScriptRef.cpp: * API/JSStringRef.cpp: (JSStringCreateWithCharactersNoCopy): * API/JSValue.mm: (+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]): (+[JSValue valueWithNewErrorFromMessage:inContext:]): (+[JSValue valueWithNewSymbolFromDescription:inContext:]): (performPropertyOperation): (-[JSValue invokeMethod:withArguments:]): (containerValueToObject): (objectToValueWithoutCopy): (objectToValue): * API/JSValueRef.cpp: (JSValueCreateJSONString): (JSValueToStringCopy): * API/OpaqueJSString.cpp: (OpaqueJSString::tryCreate): (OpaqueJSString::create): Deleted. * API/OpaqueJSString.h: * API/glib/JSCContext.cpp: (evaluateScriptInContext): * API/glib/JSCValue.cpp: (jsc_value_new_string_from_bytes): * ftl/FTLLazySlowPath.h: (JSC::FTL::LazySlowPath::createGenerator): * ftl/FTLLazySlowPathCall.h: (JSC::FTL::createLazyCallGenerator): * ftl/FTLOSRExit.cpp: (JSC::FTL::OSRExitDescriptor::emitOSRExit): (JSC::FTL::OSRExitDescriptor::emitOSRExitLater): (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle): * ftl/FTLOSRExit.h: * ftl/FTLPatchpointExceptionHandle.cpp: (JSC::FTL::PatchpointExceptionHandle::create): (JSC::FTL::PatchpointExceptionHandle::createHandle): * ftl/FTLPatchpointExceptionHandle.h: * heap/EdenGCActivityCallback.h: (JSC::GCActivityCallback::tryCreateEdenTimer): (JSC::GCActivityCallback::createEdenTimer): Deleted. * heap/FullGCActivityCallback.h: (JSC::GCActivityCallback::tryCreateFullTimer): (JSC::GCActivityCallback::createFullTimer): Deleted. * heap/GCActivityCallback.h: * heap/Heap.cpp: (JSC::Heap::Heap): * inspector/AsyncStackTrace.cpp: (Inspector::AsyncStackTrace::create): * inspector/AsyncStackTrace.h: * jsc.cpp: (fillBufferWithContentsOfFile): * runtime/ArrayBuffer.h: * runtime/GenericTypedArrayView.h: * runtime/GenericTypedArrayViewInlines.h: (JSC::GenericTypedArrayView<Adaptor>::create): (JSC::GenericTypedArrayView<Adaptor>::tryCreate): (JSC::GenericTypedArrayView<Adaptor>::createUninitialized): (JSC::GenericTypedArrayView<Adaptor>::tryCreateUninitialized): (JSC::GenericTypedArrayView<Adaptor>::subarray const): * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::possiblySharedImpl): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView<Adaptor>::possiblySharedTypedImpl): (JSC::JSGenericTypedArrayView<Adaptor>::unsharedTypedImpl): * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::create): (JSC::Wasm::Memory::tryCreate): * wasm/WasmMemory.h: * wasm/WasmTable.cpp: (JSC::Wasm::Table::tryCreate): (JSC::Wasm::Table::create): Deleted. * wasm/WasmTable.h: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::create): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory): * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::constructJSWebAssemblyMemory): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::constructJSWebAssemblyTable): 2018-10-09 Devin Rousso <drousso@apple.com> Web Inspector: show redirect requests in Network and Timelines tabs https://bugs.webkit.org/show_bug.cgi?id=150005 <rdar://problem/5378164> Reviewed by Joseph Pecoraro. * inspector/protocol/Network.json: Add missing fields to `ResourceTiming`. 2018-10-09 Claudio Saavedra <csaavedra@igalia.com> [WPE] Explicitly link against gmodule where used https://bugs.webkit.org/show_bug.cgi?id=190398 Reviewed by Michael Catanzaro. * PlatformWPE.cmake: 2018-10-08 Justin Fan <justin_fan@apple.com> WebGPU: Rename old WebGPU prototype to WebMetal https://bugs.webkit.org/show_bug.cgi?id=190325 <rdar://problem/44990443> Reviewed by Dean Jackson. Rename WebGPU prototype files to WebMetal in preparation for implementing the new (Oct 2018) WebGPU interface. * Configurations/FeatureDefines.xcconfig: * inspector/protocol/Canvas.json: * inspector/scripts/codegen/generator.py: 2018-10-08 Aditya Keerthi <akeerthi@apple.com> Make <input type=color> a runtime enabled (on-by-default) feature https://bugs.webkit.org/show_bug.cgi?id=189162 Reviewed by Wenson Hsieh and Tim Horton. * Configurations/FeatureDefines.xcconfig: 2018-10-08 Devin Rousso <drousso@apple.com> Web Inspector: group media network entries by the node that triggered the request https://bugs.webkit.org/show_bug.cgi?id=189606 <rdar://problem/44438527> Reviewed by Brian Burg. * inspector/protocol/Network.json: Add an optional `nodeId` field to the `Initiator` object that is set it is possible to determine which ancestor node triggered the load. It may not correspond directly to the node with the href/src, as that url may only be used by an ancestor for loading. 2018-10-07 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC][Linux] Use non-truncated name for JIT workers in Linux https://bugs.webkit.org/show_bug.cgi?id=190339 Reviewed by Mark Lam. The current thread names are meaningless in Linux environment. We do not want to have truncated name in Linux: we want to have clear name in Linux. Instead, we should have the name for Linux separately from the name used in the non-Linux environments. This patch adds FTLWorker, DFGWorker, and JITWorker names for Linux environment. * dfg/DFGWorklist.cpp: (JSC::DFG::createWorklistName): (JSC::DFG::Worklist::Worklist): (JSC::DFG::Worklist::create): (JSC::DFG::ensureGlobalDFGWorklist): (JSC::DFG::ensureGlobalFTLWorklist): * dfg/DFGWorklist.h: * jit/JITWorklist.cpp: 2018-10-07 Yusuke Suzuki <yusukesuzuki@slowstart.org> Name Heap threads https://bugs.webkit.org/show_bug.cgi?id=190337 Reviewed by Mark Lam. Name heap threads as "Heap Helper Thread". In Linux, we name it "HeapHelper" since Linux does not accept the name longer than 15. We do not want to use the short name for non-Linux environment. And we want to have clear name in Linux: truncated name is not good. So, having the two names is the only way. * heap/HeapHelperPool.cpp: (JSC::heapHelperPool): 2018-10-07 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Avoid creating ProgramExecutable in checkSyntax https://bugs.webkit.org/show_bug.cgi?id=190332 Reviewed by Mark Lam. uglify-js in web-tooling-benchmark executes massive number of Function constructor calls. In Function constructor code, we perform checkSyntax for body and parameters. So fast checkSyntax is important when the performance of Function constructor matters. Current checkSyntax code unnecessarily allocates ProgramExecutable. This patch removes this allocation and improves the benchmark score slightly. Before: uglify-js: 2.87 runs/s After: uglify-js: 2.94 runs/s * runtime/Completion.cpp: (JSC::checkSyntaxInternal): (JSC::checkSyntax): * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::checkSyntax): Deleted. * runtime/ProgramExecutable.h: 2018-10-06 Caio Lima <ticaiolima@gmail.com> [ESNext][BigInt] Implement support for "|" https://bugs.webkit.org/show_bug.cgi?id=186229 Reviewed by Yusuke Suzuki. This patch is introducing support for BigInt into bitwise "or" operator. In addition, we are also introducing 2 new DFG nodes, named "ArithBitOr" and "ValueBitOr", to replace "BitOr" node. The idea is to follow the difference that we make on Arith<op> and Value<op>, where ArithBitOr handles cases when the operands are Int32 and ValueBitOr handles the remaining cases. We are also changing op_bitor to use ValueProfile. We are using ValueProfile during DFG generation to emit "ArithBitOr" when outcome prediction is Int32. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::arithProfileForPC): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitBinaryOp): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo): (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: (JSC::DFG::bitwiseOp): * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueBitwiseOp): (JSC::DFG::SpeculativeJIT::compileBitwiseOp): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::bitOp): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileValueBitOr): (JSC::FTL::DFG::LowerDFGToB3::compileArithBitOr): (JSC::FTL::DFG::LowerDFGToB3::compileBitOr): Deleted. * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_bitor): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSBigInt.cpp: (JSC::JSBigInt::bitwiseAnd): (JSC::JSBigInt::bitwiseOr): (JSC::JSBigInt::absoluteBitwiseOp): (JSC::JSBigInt::absoluteAddOne): * runtime/JSBigInt.h: 2018-10-05 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Use new extra memory reporting in SparseArrayMap https://bugs.webkit.org/show_bug.cgi?id=190278 Reviewed by Keith Miller. This patch switches the extra memory reporting mechanism from deprecatedReportExtraMemory to reportExtraMemoryAllocated & reportExtraMemoryVisited in SparseArrayMap. * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayValueMap::add): (JSC::SparseArrayValueMap::visitChildren): 2018-10-05 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC][Linux] Support Perf JITDump logging https://bugs.webkit.org/show_bug.cgi?id=189893 Reviewed by Mark Lam. This patch adds Linux `perf` command's JIT Dump support. It allows JSC to tell perf about JIT code information. We add a command line option, `--logJITCodeForPerf`, which dumps `jit-%pid.dump` in the current directory. By using this dump and perf.data output, we can annotate JIT code with profiling information. $ echo "(function f() { var s = 0; for (var i = 0; i < 1000000000; i++) { s += i; } return s; })();" > test.js $ perf record -k mono ../../WebKitBuild/perf/Release/bin/jsc test.js --logJITCodeForPerf=true [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.182 MB perf.data (4346 samples) ] $ perf inject --jit -i perf.data -o perf.jit.data $ perf report -i perf.jit.data * Sources.txt: * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::finalizeCodeWithDisassemblyImpl): * assembler/LinkBuffer.h: (JSC::LinkBuffer::finalizeCodeWithDisassembly): * assembler/PerfLog.cpp: Added. (JSC::PerfLog::singleton): (JSC::generateTimestamp): (JSC::getCurrentThreadID): (JSC::PerfLog::PerfLog): (JSC::PerfLog::write): (JSC::PerfLog::flush): (JSC::PerfLog::log): * assembler/PerfLog.h: Added. * jit/ExecutableAllocator.cpp: (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): * runtime/Options.cpp: (JSC::Options::isAvailable): * runtime/Options.h: 2018-10-05 Mark Lam <mark.lam@apple.com> Gardening: Build fix after r236880. https://bugs.webkit.org/show_bug.cgi?id=190317 Unreviewed. * jit/ExecutableAllocator.h: 2018-10-05 Mark Lam <mark.lam@apple.com> performJITMemcpy() should handle the case when the executable allocator is not initialized yet. https://bugs.webkit.org/show_bug.cgi?id=190317 <rdar://problem/45039398> Reviewed by Saam Barati. When SeparatedWXHeaps is in use, jitWriteThunkGenerator() will call performJITMemcpy() to copy memory before the JIT fixed memory pool is initialize. Before r236864, performJITMemcpy() would just do a memcpy in that case. We need to restore the equivalent behavior. * jit/ExecutableAllocator.cpp: (JSC::isJITPC): * jit/ExecutableAllocator.h: (JSC::performJITMemcpy): 2018-10-05 Carlos Eduardo Ramalho <cadubentzen@gmail.com> [WPE][JSC] Use Unified Sources for Platform-specific sources https://bugs.webkit.org/show_bug.cgi?id=190300 Reviewed by Yusuke Suzuki. Currently the GTK port already used Unified Sources with the same source files. As WPE has conditional code using gmodule, we need to add GLIB_GMODULE_LIBRARIES to the list of libraries to link with. * PlatformWPE.cmake: * SourcesWPE.txt: Added. * shell/PlatformWPE.cmake: 2018-10-05 Mike Gorse <mgorse@alum.wpi.edu> [GTK] build fails with python 3 if LANG and LC_TYPE are unset https://bugs.webkit.org/show_bug.cgi?id=190258 Reviewed by Konstantin Tokarev. * Scripts/cssmin.py: Set stdout to UTF-8 on python 3. * Scripts/generateIntlCanonicalizeLanguage.py: Open files with encoding=UTF-8 on Python 3. * yarr/generateYarrCanonicalizeUnicode: Ditto. * yarr/generateYarrUnicodePropertyTables.py: Ditto. 2018-10-04 Mark Lam <mark.lam@apple.com> Move start/EndOfFixedExecutableMemoryPool pointers into the FixedVMPoolExecutableAllocator object. https://bugs.webkit.org/show_bug.cgi?id=190295 <rdar://problem/19197193> Reviewed by Saam Barati. This allows us to use the tagging logic already baked into MacroAssemblerCodePtr instead of needing to use our own custom version here. * jit/ExecutableAllocator.cpp: (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): (JSC::FixedVMPoolExecutableAllocator::memoryStart): (JSC::FixedVMPoolExecutableAllocator::memoryEnd): (JSC::FixedVMPoolExecutableAllocator::isJITPC): (JSC::ExecutableAllocator::allocate): (JSC::startOfFixedExecutableMemoryPoolImpl): (JSC::endOfFixedExecutableMemoryPoolImpl): (JSC::isJITPC): * jit/ExecutableAllocator.h: 2018-10-04 Mark Lam <mark.lam@apple.com> Disable Options::useWebAssemblyFastMemory() on linux if ASAN signal handling is not disabled. https://bugs.webkit.org/show_bug.cgi?id=190283 <rdar://problem/45015752> Reviewed by Keith Miller. * runtime/Options.cpp: (JSC::Options::initialize): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::enableFastMemory): 2018-10-03 Ross Kirsling <ross.kirsling@sony.com> [JSC] print() changes CRLF to CRCRLF on Windows https://bugs.webkit.org/show_bug.cgi?id=190228 Reviewed by Mark Lam. * jsc.cpp: (main): Ultimately, this is just the normal behavior of printf in text mode on Windows. Since we're reading in files as binary, we need to be printing out as binary too (just as we do in DumpRenderTree and ImageDiff.) 2018-10-03 Saam barati <sbarati@apple.com> lowXYZ in FTLLower should always filter the type of the incoming edge https://bugs.webkit.org/show_bug.cgi?id=189939 <rdar://problem/44407030> Reviewed by Michael Saboff. For example, the FTL may know more about data flow than AI in certain programs, and it needs to inform AI of these data flow properties to appease the assertion we have in AI that a node must perform type checks on its child nodes. For example, consider this program: ``` bb#1 a: Phi // Let's say it has an Int32 result, so it goes into the int32 hash table in FTLLower Branch(..., #2, #3) bb#2 ArrayifyToStructure(Cell:@a) // This modifies @a to have the its previous type union the type of some structure set. Jump(#3) bb#3 c: Add(Int32:@something, Int32:@a) ``` When the Add node does lowInt32() for @a, FTL lower used to just grab it from the int32 hash table without filtering the AbstractValue. However, the parent node is asking for a type check to happen, so we must inform AI of this "type check" if we want to appease the assertion that all nodes perform type checks for their edges that semantically perform type checks. This patch makes it so we filter the AbstractValue in the lowXYZ even if FTLLower proved the value must be XYZ. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compilePhi): (JSC::FTL::DFG::LowerDFGToB3::simulatedTypeCheck): (JSC::FTL::DFG::LowerDFGToB3::lowInt32): (JSC::FTL::DFG::LowerDFGToB3::lowCell): (JSC::FTL::DFG::LowerDFGToB3::lowBoolean): 2018-10-03 Michael Saboff <msaboff@apple.com> Command line jsc should report memory footprint in bytes https://bugs.webkit.org/show_bug.cgi?id=190267 Reviewed by Mark Lam. Change to leave the footprint values from the system unmodified. * jsc.cpp: (JSCMemoryFootprint::finishCreation): 2018-10-03 Mark Lam <mark.lam@apple.com> Suppress unreachable code warning for LLIntAssembly.h code. https://bugs.webkit.org/show_bug.cgi?id=190263 <rdar://problem/44986532> Reviewed by Saam Barati. This is needed because LLIntAssembly.h is template generated from LowLevelInterpreter asm files, and may contain dead code which are harmless, but will trip up the warning. We should suppress the warning so that it doesn't break builds. * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): 2018-10-03 Dan Bernstein <mitz@apple.com> JavaScriptCore part of [Xcode] Update some build settings as recommended by Xcode 10 https://bugs.webkit.org/show_bug.cgi?id=190250 Reviewed by Alex Christensen. * API/tests/Regress141275.mm: (-[JSTEvaluator _sourcePerform]): Addressed newly-enabled CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF by making the self-retaining explicit. * API/tests/testapi.cpp: (testCAPIViaCpp): Addressed newly-enabled CLANG_WARN_UNREACHABLE_CODE by breaking out of the loop instead of returning from the lambda. * Configurations/Base.xcconfig: Enabled CLANG_WARN_COMMA, CLANG_WARN_UNREACHABLE_CODE, CLANG_WARN_DEPRECATED_OBJC_IMPLEMENTATIONS, CLANG_WARN_OBJC_IMPLICIT_RETAIN_SELF, and CLANG_ANALYZER_LOCALIZABILITY_NONLOCALIZED. * JavaScriptCore.xcodeproj/project.pbxproj: Removed a duplicate reference to UnlinkedFunctionExecutable.h, and let Xcode update the project file. * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printAllRegisters): Addressed newly-enabled CLANG_WARN_COMMA by replacing some commas with semicolons. 2018-10-03 Mark Lam <mark.lam@apple.com> Make string MaxLength for all WTF and JS strings consistently equal to INT_MAX. https://bugs.webkit.org/show_bug.cgi?id=190187 <rdar://problem/42512909> Reviewed by Michael Saboff. Allowing different max string lengths at each level opens up opportunities for bugs to creep in. With 2 different max length values, it is more difficult to keep the story straight on how we do overflow / bounds checks at each place in the code. It's also difficult to tell if a seemingly valid check at the WTF level will have bad ramifications at the JSC level. Also, it's also not meaningful to support a max length > INT_MAX. To eliminate this class of bugs, we'll standardize on a MaxLength of INT_MAX at all levels. We'll also standardize the way we do length overflow checks on using CheckedArithmetic, and add some asserts to document the assumptions of the code. * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): - Fix OOM error handling which crashed a test after the new MaxLength was applied. * runtime/JSString.h: (JSC::JSString::finishCreation): (JSC::JSString::createHasOtherOwner): (JSC::JSString::setLength): * runtime/JSStringInlines.h: (JSC::jsMakeNontrivialString): * runtime/Operations.h: (JSC::jsString): 2018-10-03 Koby Boyango <koby.b@mce-sys.com> [JSC] Add a C++ callable overload of objectConstructorSeal https://bugs.webkit.org/show_bug.cgi?id=190137 Reviewed by Yusuke Suzuki. * runtime/ObjectConstructor.cpp: * runtime/ObjectConstructor.h: 2018-10-02 Dominik Infuehr <dinfuehr@igalia.com> Fix Disassembler-output on ARM Thumb2 https://bugs.webkit.org/show_bug.cgi?id=190203 On ARMv7 with Thumb2 addresses have bit 0 set to 1 to force execution in thumb mode for jumps and calls. The actual machine instructions are still aligned to 2-bytes though. Use dataLocation() as start address for disassembling since it unsets the thumb bit. Until now the disassembler would start at the wrong address (off by 1), resulting in the wrong disassembled machine instructions. Reviewed by Mark Lam. * disassembler/CapstoneDisassembler.cpp: (JSC::tryToDisassemble): 2018-10-02 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Add stub of ExecutableAllocator used when JIT is disabled https://bugs.webkit.org/show_bug.cgi?id=190215 Reviewed by Mark Lam. When ENABLE(JIT) is disabled, we do not use JIT. But we ExecutableAllocator is still available since it is guarded by ENABLE(ASSEMBLER). ENABLE(ASSEMBLER) is necessary for LLInt ASM interpreter since our MacroAssembler tells machine architecture information. Eventually, we would like to decouple this machine architecture information from MacroAssembler. But for now, we use ENABLE(ASSEMBLER) for LLInt ASM interpreter even if JIT is disabled by ENABLE(JIT). To ensure any executable memory allocation is not done, we add a stub of ExecutableAllocator for non-JIT configurations. This does not have any functionality allocating executable memory, thus any accidental operation cannot attempt to allocate executable memory if ENABLE(JIT) = OFF. * jit/ExecutableAllocator.cpp: (JSC::ExecutableAllocator::initializeAllocator): (JSC::ExecutableAllocator::singleton): * jit/ExecutableAllocator.h: (JSC::ExecutableAllocator::isValid const): (JSC::ExecutableAllocator::underMemoryPressure): (JSC::ExecutableAllocator::memoryPressureMultiplier): (JSC::ExecutableAllocator::dumpProfile): (JSC::ExecutableAllocator::allocate): (JSC::ExecutableAllocator::isValidExecutableMemory): (JSC::ExecutableAllocator::committedByteCount): (JSC::ExecutableAllocator::getLock const): (JSC::performJITMemcpy): 2018-10-01 Dean Jackson <dino@apple.com> Remove CSS Animation Triggers https://bugs.webkit.org/show_bug.cgi?id=190175 <rdar://problem/44925626> Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2018-10-02 Caio Lima <ticaiolima@gmail.com> [BigInt] BigInt.proptotype.toString is broken when radix is power of 2 https://bugs.webkit.org/show_bug.cgi?id=190033 Reviewed by Yusuke Suzuki. The implementation of JSBigInt::toStringToGeneric doesn't handle power of 2 radix when JSBigInt length is >= 2. To handle such cases, we implemented JSBigInt::toStringBasePowerOfTwo that follows the algorithm that groups bits using mask of (2 ^ n) - 1 to extract every digit. * runtime/JSBigInt.cpp: (JSC::JSBigInt::toString): (JSC::JSBigInt::toStringBasePowerOfTwo): * runtime/JSBigInt.h: 2018-10-01 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Add branchIfNaN and branchIfNotNaN https://bugs.webkit.org/show_bug.cgi?id=190122 Reviewed by Mark Lam. Add AssemblyHelpers::{branchIfNaN, branchIfNotNaN} to make code more readable. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): (JSC::DFG::SpeculativeJIT::compileDoubleRep): (JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand): (JSC::DFG::SpeculativeJIT::compileSpread): (JSC::DFG::SpeculativeJIT::compileNewArray): (JSC::DFG::SpeculativeJIT::speculateRealNumber): (JSC::DFG::SpeculativeJIT::speculateDoubleRepReal): (JSC::DFG::SpeculativeJIT::compileNormalizeMapKey): (JSC::DFG::SpeculativeJIT::compileHasIndexedProperty): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::purifyNaN): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchIfNaN): (JSC::AssemblyHelpers::branchIfNotNaN): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitDoubleLoad): (JSC::JIT::emitFloatTypedArrayGetByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGenericContiguousPutByVal): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): 2018-10-01 Mark Lam <mark.lam@apple.com> Function.toString() should also copy the source code Functions that are class definitions. https://bugs.webkit.org/show_bug.cgi?id=190186 <rdar://problem/44733360> Reviewed by Saam Barati. Previously, if the Function is a class definition, functionProtoFuncToString() would create a String using StringView::toStringWithoutCopying(), and use that String to make a JSString. This is not a problem if the underlying SourceProvider (that backs the characters in that StringView) is immortal. However, this is not always the case in practice. This patch fixes this issue by changing functionProtoFuncToString() to create the String using StringView::toString() instead, which makes a copy of the underlying characters buffer. This detaches the resultant JSString from the SourceProvider characters buffer that it was created from, and ensure that the underlying characters buffer of the string will be alive for the entire lifetime of the JSString. * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncToString): 2018-10-01 Keith Miller <keith_miller@apple.com> Create a RELEASE_AND_RETURN macro for ExceptionScopes https://bugs.webkit.org/show_bug.cgi?id=190163 Reviewed by Mark Lam. The new RELEASE_AND_RETURN does all the work for cases where you want to return the result of some expression without explicitly checking for an exception. This is much like the existing RETURN_IF_EXCEPTION macro. * dfg/DFGOperations.cpp: (JSC::DFG::newTypedArrayWithSize): * interpreter/Interpreter.cpp: (JSC::eval): * jit/JITOperations.cpp: (JSC::getByVal): * jsc.cpp: (functionDollarAgentReceiveBroadcast): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setUpCall): (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::varargsSetup): * profiler/ProfilerDatabase.cpp: (JSC::Profiler::Database::toJSON const): * runtime/AbstractModuleRecord.cpp: (JSC::AbstractModuleRecord::hostResolveImportedModule): * runtime/ArrayConstructor.cpp: (JSC::constructArrayWithSizeQuirk): * runtime/ArrayPrototype.cpp: (JSC::getProperty): (JSC::fastJoin): (JSC::arrayProtoFuncToString): (JSC::arrayProtoFuncToLocaleString): (JSC::arrayProtoFuncJoin): (JSC::arrayProtoFuncPop): (JSC::arrayProtoPrivateFuncConcatMemcpy): * runtime/BigIntConstructor.cpp: (JSC::toBigInt): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::opInByVal): * runtime/ConstructData.cpp: (JSC::construct): * runtime/DateConstructor.cpp: (JSC::dateParse): * runtime/DatePrototype.cpp: (JSC::dateProtoFuncToPrimitiveSymbol): * runtime/DirectArguments.h: * runtime/ErrorConstructor.cpp: (JSC::Interpreter::constructWithErrorConstructor): * runtime/ErrorPrototype.cpp: (JSC::errorProtoFuncToString): * runtime/ExceptionScope.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunction): * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncToString): * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments<Type>::defineOwnProperty): * runtime/GetterSetter.cpp: (JSC::callGetter): * runtime/IntlCollatorConstructor.cpp: (JSC::IntlCollatorConstructorFuncSupportedLocalesOf): * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorFuncCompare): (JSC::IntlCollatorPrototypeFuncResolvedOptions): * runtime/IntlDateTimeFormatConstructor.cpp: (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatFuncFormatDateTime): (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions): * runtime/IntlNumberFormatConstructor.cpp: (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatFuncFormatNumber): (JSC::IntlNumberFormatPrototypeFuncFormatToParts): (JSC::IntlNumberFormatPrototypeFuncResolvedOptions): * runtime/IntlObject.cpp: (JSC::intlNumberOption): * runtime/IntlObjectInlines.h: (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor): * runtime/IntlPluralRules.cpp: (JSC::IntlPluralRules::resolvedOptions): * runtime/IntlPluralRulesConstructor.cpp: (JSC::IntlPluralRulesConstructorFuncSupportedLocalesOf): * runtime/IntlPluralRulesPrototype.cpp: (JSC::IntlPluralRulesPrototypeFuncSelect): (JSC::IntlPluralRulesPrototypeFuncResolvedOptions): * runtime/JSArray.cpp: (JSC::JSArray::defineOwnProperty): (JSC::JSArray::put): (JSC::JSArray::setLength): (JSC::JSArray::unshiftCountWithAnyIndexingType): * runtime/JSArrayBufferPrototype.cpp: (JSC::arrayBufferProtoGetterFuncByteLength): (JSC::sharedArrayBufferProtoGetterFuncByteLength): * runtime/JSArrayInlines.h: (JSC::toLength): * runtime/JSBoundFunction.cpp: (JSC::boundFunctionCall): (JSC::boundFunctionConstruct): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSCJSValueInlines.h: (JSC::JSValue::toIndex const): (JSC::JSValue::toPropertyKey const): (JSC::JSValue::get const): (JSC::JSValue::getPropertySlot const): (JSC::JSValue::getOwnPropertySlot const): (JSC::JSValue::equalSlowCaseInline): * runtime/JSDataView.cpp: (JSC::JSDataView::put): (JSC::JSDataView::defineOwnProperty): * runtime/JSFunction.cpp: (JSC::JSFunction::put): (JSC::JSFunction::defineOwnProperty): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewWithArguments): (JSC::constructGenericTypedArrayView): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView<Adaptor>::set): (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::speciesConstruct): (JSC::genericTypedArrayViewProtoFuncJoin): (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::put): * runtime/JSGlobalObjectFunctions.cpp: (JSC::decode): (JSC::globalFuncEval): (JSC::globalFuncProtoGetter): * runtime/JSInternalPromise.cpp: (JSC::JSInternalPromise::then): * runtime/JSModuleEnvironment.cpp: (JSC::JSModuleEnvironment::put): * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::provideFetch): (JSC::JSModuleLoader::loadAndEvaluateModule): (JSC::JSModuleLoader::loadModule): (JSC::JSModuleLoader::linkAndEvaluateModule): (JSC::JSModuleLoader::requestImportModule): (JSC::JSModuleLoader::getModuleNamespaceObject): (JSC::moduleLoaderRequestedModules): * runtime/JSONObject.cpp: (JSC::Stringifier::stringify): (JSC::Stringifier::toJSON): (JSC::Walker::walk): (JSC::JSONProtoFuncStringify): * runtime/JSObject.cpp: (JSC::ordinarySetSlow): (JSC::JSObject::putInlineSlow): (JSC::JSObject::toPrimitive const): (JSC::JSObject::hasInstance): (JSC::JSObject::toNumber const): (JSC::JSObject::defineOwnIndexedProperty): (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage): (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage): (JSC::JSObject::defineOwnNonIndexProperty): * runtime/JSObject.h: (JSC::JSObject::get const): * runtime/JSObjectInlines.h: (JSC::JSObject::getPropertySlot const): (JSC::JSObject::putInlineForJSObject): * runtime/MapConstructor.cpp: (JSC::constructMap): * runtime/NativeErrorConstructor.cpp: (JSC::Interpreter::constructWithNativeErrorConstructor): * runtime/ObjectConstructor.cpp: (JSC::constructObject): (JSC::objectConstructorGetPrototypeOf): (JSC::objectConstructorGetOwnPropertyDescriptor): (JSC::objectConstructorGetOwnPropertyDescriptors): (JSC::objectConstructorGetOwnPropertyNames): (JSC::objectConstructorGetOwnPropertySymbols): (JSC::objectConstructorKeys): (JSC::objectConstructorDefineProperty): (JSC::objectConstructorDefineProperties): (JSC::objectConstructorCreate): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncToLocaleString): (JSC::objectProtoFuncToString): * runtime/Operations.cpp: (JSC::jsAddSlowCase): * runtime/Operations.h: (JSC::jsString): (JSC::jsLess): (JSC::jsLessEq): * runtime/ParseInt.h: (JSC::toStringView): * runtime/ProxyConstructor.cpp: (JSC::constructProxyObject): * runtime/ProxyObject.cpp: (JSC::ProxyObject::toStringName): (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::getOwnPropertySlotCommon): (JSC::ProxyObject::performPut): (JSC::ProxyObject::putByIndexCommon): (JSC::performProxyCall): (JSC::performProxyConstruct): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::performPreventExtensions): (JSC::ProxyObject::performIsExtensible): (JSC::ProxyObject::performDefineOwnProperty): (JSC::ProxyObject::performSetPrototype): (JSC::ProxyObject::performGetPrototype): * runtime/ReflectObject.cpp: (JSC::reflectObjectConstruct): (JSC::reflectObjectDefineProperty): (JSC::reflectObjectGet): (JSC::reflectObjectGetOwnPropertyDescriptor): (JSC::reflectObjectGetPrototypeOf): (JSC::reflectObjectOwnKeys): (JSC::reflectObjectSet): * runtime/RegExpConstructor.cpp: (JSC::constructRegExp): * runtime/RegExpObject.cpp: (JSC::RegExpObject::defineOwnProperty): (JSC::RegExpObject::matchGlobal): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncTestFast): (JSC::regExpProtoFuncExec): (JSC::regExpProtoFuncToString): * runtime/ScriptExecutable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): * runtime/SetConstructor.cpp: (JSC::constructSet): * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayValueMap::putEntry): (JSC::SparseArrayEntry::put): * runtime/StringConstructor.cpp: (JSC::stringFromCharCode): (JSC::stringFromCodePoint): * runtime/StringObject.cpp: (JSC::StringObject::put): (JSC::StringObject::putByIndex): (JSC::StringObject::defineOwnProperty): * runtime/StringPrototype.cpp: (JSC::jsSpliceSubstrings): (JSC::jsSpliceSubstringsWithSeparators): (JSC::removeUsingRegExpSearch): (JSC::replaceUsingRegExpSearch): (JSC::operationStringProtoFuncReplaceRegExpEmptyStr): (JSC::replaceUsingStringSearch): (JSC::repeatCharacter): (JSC::replace): (JSC::stringProtoFuncReplaceUsingRegExp): (JSC::stringProtoFuncReplaceUsingStringSearch): (JSC::stringProtoFuncSplitFast): (JSC::stringProtoFuncToLowerCase): (JSC::stringProtoFuncToUpperCase): (JSC::toLocaleCase): (JSC::trimString): (JSC::stringProtoFuncIncludes): (JSC::builtinStringIncludesInternal): (JSC::normalize): (JSC::stringProtoFuncNormalize): * runtime/SymbolPrototype.cpp: (JSC::symbolProtoFuncToString): (JSC::symbolProtoFuncValueOf): * tools/JSDollarVM.cpp: (WTF::functionWasmStreamingParserAddBytes): (JSC::functionGetPrivateProperty): * wasm/js/WebAssemblyCompileErrorConstructor.cpp: (JSC::constructJSWebAssemblyCompileError): * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::constructJSWebAssemblyModule): (JSC::WebAssemblyModuleConstructor::createModule): * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::constructJSWebAssemblyTable): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::callWebAssemblyWrapperFunction): 2018-10-01 Koby Boyango <koby.b@mce-sys.com> [JSC] Add a JSONStringify overload that receives a JSValue space https://bugs.webkit.org/show_bug.cgi?id=190131 Reviewed by Yusuke Suzuki. * runtime/JSONObject.cpp: * runtime/JSONObject.h: 2018-10-01 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r236647. https://bugs.webkit.org/show_bug.cgi?id=190124 Breaking test stress/big-int-to-string.js (Requested by caiolima_ on #webkit). Reverted changeset: "[BigInt] BigInt.proptotype.toString is broken when radix is power of 2" https://bugs.webkit.org/show_bug.cgi?id=190033 https://trac.webkit.org/changeset/236647 2018-10-01 Yusuke Suzuki <yusukesuzuki@slowstart.org> [WebAssembly] Move type conversion code of JSToWasm return type to JS wasm wrapper https://bugs.webkit.org/show_bug.cgi?id=189498 Reviewed by Saam Barati. To call JS-to-Wasm code we need to convert the result value from wasm function to the JS type. Previously this is done by callWebAssemblyFunction by using swtich over signature.returnType(). But since we know the value of `signature.returnType()` at compiling phase, we can emit a small conversion code directly to JSToWasm glue and remove this switch from callWebAssemblyFunction. In JSToWasm glue code, we do not have tag registers. So we use DoNotHaveTagRegisters in boxInt32 and boxDouble. Since boxDouble does not have DoNotHaveTagRegisters version, we add an implementation for that. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::boxDouble): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): 2018-09-30 Caio Lima <ticaiolima@gmail.com> [BigInt] BigInt.proptotype.toString is broken when radix is power of 2 https://bugs.webkit.org/show_bug.cgi?id=190033 Reviewed by Yusuke Suzuki. The implementation of JSBigInt::toStringToGeneric doesn't handle power of 2 radix when JSBigInt length is >= 2. To handle such cases, we implemented JSBigInt::toStringBasePowerOfTwo that follows the algorithm that groups bits using mask of (2 ^ n) - 1 to extract every digit. * runtime/JSBigInt.cpp: (JSC::JSBigInt::toString): (JSC::JSBigInt::toStringBasePowerOfTwo): * runtime/JSBigInt.h: 2018-09-28 Caio Lima <ticaiolima@gmail.com> [ESNext][BigInt] Implement support for "&" https://bugs.webkit.org/show_bug.cgi?id=186228 Reviewed by Yusuke Suzuki. This patch introduces support of BigInt into bitwise "&" operation. We are also introducing the ValueBitAnd DFG node, that is responsible to take care of JIT for non-Int32 operands. With the introduction of this new node, we renamed the BitAnd node to ArithBitAnd. The ArithBitAnd follows the behavior of ArithAdd and other arithmetic nodes, where the Arith<op> version always results in Number (in the case of ArithBitAnd, its is always an Int32). * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitBinaryOp): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo): (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueBitwiseOp): (JSC::DFG::SpeculativeJIT::compileBitwiseOp): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::bitOp): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileValueBitAnd): (JSC::FTL::DFG::LowerDFGToB3::compileArithBitAnd): (JSC::FTL::DFG::LowerDFGToB3::compileBitAnd): Deleted. * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emitBitBinaryOpFastPath): (JSC::JIT::emit_op_bitand): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSBigInt.cpp: (JSC::JSBigInt::JSBigInt): (JSC::JSBigInt::initialize): (JSC::JSBigInt::createZero): (JSC::JSBigInt::createFrom): (JSC::JSBigInt::bitwiseAnd): (JSC::JSBigInt::absoluteBitwiseOp): (JSC::JSBigInt::absoluteAnd): (JSC::JSBigInt::absoluteOr): (JSC::JSBigInt::absoluteAndNot): (JSC::JSBigInt::absoluteAddOne): (JSC::JSBigInt::absoluteSubOne): * runtime/JSBigInt.h: * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::toBigIntOrInt32 const): 2018-09-28 Mark Lam <mark.lam@apple.com> Gardening: speculative build fix. <rdar://problem/44869924> Not reviewed. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): 2018-09-28 Guillaume Emont <guijemont@igalia.com> [JSC] [Armv7] Add a copy function argument to MacroAssemblerARMv7::link() and pass it down to the assembler's linking functions. https://bugs.webkit.org/show_bug.cgi?id=190080 Reviewed by Mark Lam. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::link): (JSC::ARMv7Assembler::linkJumpT1): (JSC::ARMv7Assembler::linkJumpT2): (JSC::ARMv7Assembler::linkJumpT3): (JSC::ARMv7Assembler::linkJumpT4): (JSC::ARMv7Assembler::linkConditionalJumpT4): (JSC::ARMv7Assembler::linkBX): (JSC::ARMv7Assembler::linkConditionalBX): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::link): 2018-09-27 Saam barati <sbarati@apple.com> Verify the contents of AssemblerBuffer on arm64e https://bugs.webkit.org/show_bug.cgi?id=190057 <rdar://problem/38916630> Reviewed by Mark Lam. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::ARM64Assembler): (JSC::ARM64Assembler::fillNops): (JSC::ARM64Assembler::link): (JSC::ARM64Assembler::linkJumpOrCall): (JSC::ARM64Assembler::linkCompareAndBranch): (JSC::ARM64Assembler::linkConditionalBranch): (JSC::ARM64Assembler::linkTestAndBranch): (JSC::ARM64Assembler::unlinkedCode): Deleted. * assembler/ARMAssembler.h: (JSC::ARMAssembler::fillNops): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::unlinkedCode): Deleted. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::emitNops): (JSC::AbstractMacroAssembler::AbstractMacroAssembler): * assembler/AssemblerBuffer.h: (JSC::ARM64EHash::ARM64EHash): (JSC::ARM64EHash::update): (JSC::ARM64EHash::hash const): (JSC::ARM64EHash::randomSeed const): (JSC::AssemblerBuffer::AssemblerBuffer): (JSC::AssemblerBuffer::putShort): (JSC::AssemblerBuffer::putIntUnchecked): (JSC::AssemblerBuffer::putInt): (JSC::AssemblerBuffer::hash const): (JSC::AssemblerBuffer::data const): (JSC::AssemblerBuffer::putIntegralUnchecked): (JSC::AssemblerBuffer::append): Deleted. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::fillNops): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::jumpsToLink): (JSC::MacroAssemblerARM64::link): (JSC::MacroAssemblerARM64::unlinkedCode): Deleted. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::jumpsToLink): (JSC::MacroAssemblerARMv7::unlinkedCode): Deleted. * assembler/X86Assembler.h: (JSC::X86Assembler::fillNops): 2018-09-27 Mark Lam <mark.lam@apple.com> ByValInfo should not use integer offsets. https://bugs.webkit.org/show_bug.cgi?id=190070 <rdar://problem/44803430> Reviewed by Saam Barati. Also moved some fields around to allow the ByValInfo struct to be more densely packed. * bytecode/ByValInfo.h: (JSC::ByValInfo::ByValInfo): * jit/JIT.cpp: (JSC::JIT::link): * jit/JITOpcodes.cpp: (JSC::JIT::privateCompileHasIndexedProperty): * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileHasIndexedProperty): * jit/JITPropertyAccess.cpp: (JSC::JIT::privateCompileGetByVal): (JSC::JIT::privateCompileGetByValWithCachedId): (JSC::JIT::privateCompilePutByVal): (JSC::JIT::privateCompilePutByValWithCachedId): 2018-09-27 Saam barati <sbarati@apple.com> DFG::OSRExit::m_patchableCodeOffset should not be an int https://bugs.webkit.org/show_bug.cgi?id=190066 <rdar://problem/39498244> Reviewed by Mark Lam. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::linkOSRExits): (JSC::DFG::JITCompiler::link): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::codeLocationForRepatch const): (JSC::DFG::OSRExit::compileOSRExit): (JSC::DFG::OSRExit::setPatchableCodeOffset): Deleted. (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump const): Deleted. (JSC::DFG::OSRExit::correctJump): Deleted. * dfg/DFGOSRExit.h: * dfg/DFGOSRExitCompilationInfo.h: 2018-09-27 Saam barati <sbarati@apple.com> Don't use int offsets in StructureStubInfo https://bugs.webkit.org/show_bug.cgi?id=190064 <rdar://problem/44784719> Reviewed by Mark Lam. * bytecode/InlineAccess.cpp: (JSC::linkCodeInline): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::slowPathCallLocation): (JSC::StructureStubInfo::doneLocation): (JSC::StructureStubInfo::slowPathStartLocation): * jit/JITInlineCacheGenerator.cpp: (JSC::JITInlineCacheGenerator::finalize): 2018-09-27 Mark Lam <mark.lam@apple.com> DFG::OSREntry::m_machineCodeOffset should be a CodeLocation. https://bugs.webkit.org/show_bug.cgi?id=190054 <rdar://problem/44803543> Reviewed by Saam Barati. * dfg/DFGJITCode.h: (JSC::DFG::JITCode::appendOSREntryData): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGOSREntry.cpp: (JSC::DFG::OSREntryData::dumpInContext const): (JSC::DFG::prepareOSREntry): * dfg/DFGOSREntry.h: * runtime/JSCPtrTag.h: 2018-09-27 Mark Lam <mark.lam@apple.com> JITMathIC should not use integer offsets into machine code. https://bugs.webkit.org/show_bug.cgi?id=190030 <rdar://problem/44803307> Reviewed by Saam Barati. We'll replace them with CodeLocation smart pointers instead. * jit/JITMathIC.h: (JSC::isProfileEmpty): 2018-09-26 Mark Lam <mark.lam@apple.com> Options::useSeparatedWXHeap() should always be false when ENABLE(FAST_JIT_PERMISSIONS) && CPU(ARM64E). https://bugs.webkit.org/show_bug.cgi?id=190022 <rdar://problem/44800928> Reviewed by Saam Barati. * jit/ExecutableAllocator.cpp: (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps): * jit/ExecutableAllocator.h: (JSC::performJITMemcpy): * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2018-09-26 Mark Lam <mark.lam@apple.com> Assert that performJITMemcpy() is always called with instruction size aligned addresses on ARM64. https://bugs.webkit.org/show_bug.cgi?id=190016 <rdar://problem/44802875> Reviewed by Saam Barati. Also assert in performJITMemcpy() that the entire buffer to be copied will fit in JIT memory. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::fillNops): (JSC::ARM64Assembler::replaceWithVMHalt): (JSC::ARM64Assembler::replaceWithJump): (JSC::ARM64Assembler::replaceWithLoad): (JSC::ARM64Assembler::replaceWithAddressComputation): (JSC::ARM64Assembler::setPointer): (JSC::ARM64Assembler::repatchInt32): (JSC::ARM64Assembler::repatchCompact): (JSC::ARM64Assembler::linkJumpOrCall): (JSC::ARM64Assembler::linkCompareAndBranch): (JSC::ARM64Assembler::linkConditionalBranch): (JSC::ARM64Assembler::linkTestAndBranch): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): (JSC::LinkBuffer::linkCode): * jit/ExecutableAllocator.h: (JSC::performJITMemcpy): 2018-09-25 Keith Miller <keith_miller@apple.com> Move Symbol API to SPI https://bugs.webkit.org/show_bug.cgi?id=189946 Reviewed by Michael Saboff. Some of the property access methods on JSValue needed to be moved to a category so that SPI overloads don't result in a compiler error for internal users. Additionally, this patch does not move the new enum entry for Symbols in the JSType enumeration. * API/JSObjectRef.h: * API/JSObjectRefPrivate.h: * API/JSValue.h: * API/JSValuePrivate.h: * API/JSValueRef.h: 2018-09-26 Keith Miller <keith_miller@apple.com> We should zero unused property storage when rebalancing array storage. https://bugs.webkit.org/show_bug.cgi?id=188151 Reviewed by Michael Saboff. In unshiftCountSlowCase we sometimes will move property storage to the right even when net adding elements. This can happen because we "balance" the pre/post-capacity in that code so we need to zero the unused property storage. * runtime/JSArray.cpp: (JSC::JSArray::unshiftCountSlowCase): 2018-09-26 Yusuke Suzuki <yusukesuzuki@slowstart.org> Unreviewed, add scope verification handling https://bugs.webkit.org/show_bug.cgi?id=189780 * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncIndexOf): (JSC::arrayProtoFuncLastIndexOf): 2018-09-26 Koby Boyango <koby.b@mce.systems> [JSC] offlineasm parser should handle CRLF in asm files https://bugs.webkit.org/show_bug.cgi?id=189949 Reviewed by Mark Lam. * offlineasm/parser.rb: 2018-09-20 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Optimize Array#lastIndexOf https://bugs.webkit.org/show_bug.cgi?id=189780 Reviewed by Saam Barati. Optimize Array#lastIndexOf as the same to Array#indexOf. We add a fast path for JSArray with contiguous storage. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncLastIndexOf): 2018-09-25 Saam Barati <sbarati@apple.com> Calls to baselineCodeBlockForOriginAndBaselineCodeBlock in operationMaterializeObjectInOSR should actually pass in the baseline CodeBlock https://bugs.webkit.org/show_bug.cgi?id=189940 <rdar://problem/43640987> Reviewed by Mark Lam. We were calling baselineCodeBlockForOriginAndBaselineCodeBlock with the FTL CodeBlock. There is nothing semantically wrong with doing that (except for poor naming), however, the poor naming here led us to make a real semantic mistake. We wanted the baseline CodeBlock's constant pool, but we were accessing the FTL CodeBlock's constant pool accidentally. We need to access the baseline CodeBlock's constant pool when we update the NewArrayBuffer constant value. * bytecode/InlineCallFrame.h: (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): 2018-09-25 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Stricter block syntax in generated ObjC protocol interfaces https://bugs.webkit.org/show_bug.cgi?id=189962 <rdar://problem/44648287> Reviewed by Brian Burg. * inspector/scripts/codegen/generate_objc_header.py: (ObjCHeaderGenerator._callback_block_for_command): If there are no return parameters include "void" in the block signature. * inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result: * inspector/scripts/tests/generic/expected/domain-availability.json-result: * inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result: * inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result: * inspector/scripts/tests/generic/expected/worker-supported-domains.json-result: * inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result: Rebaseline test results. 2018-09-24 Joseph Pecoraro <pecoraro@apple.com> Remove AUTHORS and THANKS files which are stale https://bugs.webkit.org/show_bug.cgi?id=189941 Reviewed by Darin Adler. Included mentions below so their names are still in ChangeLogs. * AUTHORS: Removed. Harri Porten (porten@kde.org) and Peter Kelly (pmk@post.com). These authors remain mentioned in copyrights in source files. * THANKS: Removed. Richard Moore <rich@kde.org> - for filling the Math object with some life Daegeun Lee <realking@mizi.com> - for pointing out some bugs and providing much code for the String and Date object. Marco Pinelli <pinmc@libero.it> - for his patches Christian Kirsch <ck@held.mind.de> - for his contribution to the Date object 2018-09-24 Fujii Hironori <Hironori.Fujii@sony.com> Rename WTF_COMPILER_GCC_OR_CLANG to WTF_COMPILER_GCC_COMPATIBLE https://bugs.webkit.org/show_bug.cgi?id=189733 Reviewed by Michael Catanzaro. * assembler/ARM64Assembler.h: * assembler/ARMAssembler.h: (JSC::ARMAssembler::cacheFlush): * assembler/MacroAssemblerARM.cpp: (JSC::isVFPPresent): * assembler/MacroAssemblerARM64.cpp: * assembler/MacroAssemblerARMv7.cpp: * assembler/MacroAssemblerMIPS.cpp: * assembler/MacroAssemblerX86Common.cpp: * heap/HeapCell.cpp: * heap/HeapCell.h: * jit/HostCallReturnValue.h: * jit/JIT.h: * jit/JITOperations.cpp: * jit/ThunkGenerators.cpp: * runtime/ArrayConventions.cpp: (JSC::clearArrayMemset): * runtime/JSBigInt.cpp: (JSC::JSBigInt::digitDiv): 2018-09-24 Saam Barati <sbarati@apple.com> Array.prototype.indexOf fast path needs to ensure the length is still valid after performing effects https://bugs.webkit.org/show_bug.cgi?id=189922 <rdar://problem/44651275> Reviewed by Mark Lam. The implementation was first getting the length to iterate up to, then getting the starting index. However, getting the starting index may perform effects. e.g, it could change the length of the array. This changes it so we verify the length is still valid. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncIndexOf): 2018-09-24 Tadeu Zagallo <tzagallo@apple.com> offlineasm: fix macro scoping https://bugs.webkit.org/show_bug.cgi?id=189902 Reviewed by Mark Lam. In the code below, the reference to `f` in `g`, which should refer to the outer macro definition will instead refer to the f argument of the anonymous macro passed to `g`. That leads to this code failing to compile (f expected 0 args but got 1). ``` macro f(x) move x, t0 end macro g(fn) fn(macro () f(42) end) end g(macro(f) f() end) ``` * offlineasm/ast.rb: * offlineasm/transform.rb: 2018-09-24 Tadeu Zagallo <tzagallo@apple.com> Add forEach method for iterating CodeBlock's ValueProfiles https://bugs.webkit.org/show_bug.cgi?id=189897 Reviewed by Mark Lam. Add method to abstract how we find ValueProfiles in a CodeBlock in preparation for https://bugs.webkit.org/show_bug.cgi?id=189785, when ValueProfiles will be stored in the MetadataTable. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): (JSC::CodeBlock::updateAllValueProfilePredictions): (JSC::CodeBlock::shouldOptimizeNow): (JSC::CodeBlock::dumpValueProfiles): * bytecode/CodeBlock.h: (JSC::CodeBlock::forEachValueProfile): (JSC::CodeBlock::numberOfArgumentValueProfiles): (JSC::CodeBlock::valueProfileForArgument): (JSC::CodeBlock::numberOfValueProfiles): (JSC::CodeBlock::valueProfile): (JSC::CodeBlock::totalNumberOfValueProfiles): Deleted. (JSC::CodeBlock::getFromAllValueProfiles): Deleted. * tools/HeapVerifier.cpp: (JSC::HeapVerifier::validateJSCell): 2018-09-24 Saam barati <sbarati@apple.com> ArgumentsEliminationPhase should snip basic blocks after proven OSR exits https://bugs.webkit.org/show_bug.cgi?id=189682 <rdar://problem/43557315> Reviewed by Mark Lam. Otherwise, if we have code like this: ``` a: Arguments b: GetButterfly(@a) c: ForceExit d: GetArrayLength(@a, @b) ``` it will get transformed into this invalid DFG IR: ``` a: PhantomArguments b: Check(@a) c: ForceExit d: GetArrayLength(@a, @b) ``` And we will fail DFG validation since @b does not have a result. The fix is to just remove all nodes after the ForceExit and plant an Unreachable after it. So the above code program will now turn into this: ``` a: PhantomArguments b: Check(@a) c: ForceExit e: Unreachable ``` * dfg/DFGArgumentsEliminationPhase.cpp: 2018-09-22 Saam barati <sbarati@apple.com> The sampling should not use Strong<CodeBlock> in its machineLocation field https://bugs.webkit.org/show_bug.cgi?id=189319 Reviewed by Filip Pizlo. The sampling profiler has a CLI mode where we gather information about inline call frames. That data structure was using a Strong<CodeBlock>. We were constructing this Strong<CodeBlock> during GC concurrently to processing all the Strong handles. This is a bug since we end up corrupting that data structure. This patch fixes this by just making this data structure use the sampling profiler's mechanism for holding onto and properly visiting heap pointers. * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::InspectorScriptProfilerAgent::trackingComplete): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::processUnverifiedStackTraces): (JSC::SamplingProfiler::reportTopFunctions): (JSC::SamplingProfiler::reportTopBytecodes): These CLI helpers needed a DeferGC otherwise we may end up deadlocking when we cause a GC to happen while already holding the sampling profiler's lock. 2018-09-21 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Enable LLInt ASM interpreter on X64 and ARM64 in non JIT configuration https://bugs.webkit.org/show_bug.cgi?id=189778 Reviewed by Keith Miller. LLInt ASM interpreter is 2x and 15% faster than CLoop interpreter on Linux and macOS respectively. We would like to enable it for non JIT configurations in X86_64 and ARM64. This patch enables LLInt for non JIT builds in X86_64 and ARM64 architectures. Previously, we switch LLInt ASM interpreter and CLoop by using ENABLE(JIT) configuration. But it is wrong in the new scenario since we have a build configuration that uses LLInt ASM interpreter and JIT is disabled. We introduce ENABLE(C_LOOP) option, which represents that we use CLoop. And we replace ENABLE(JIT) with ENABLE(C_LOOP) if the previous ENABLE(JIT) is essentially just related to LLInt ASM interpreter and not related to JIT. We also replace some ENABLE(JIT) configurations with ENABLE(ASSEMBLER). ENABLE(ASSEMBLER) is now enabled even if we disable JIT since MacroAssembler has machine register information that is used in LLInt ASM interpreter. * API/tests/PingPongStackOverflowTest.cpp: (testPingPongStackOverflow): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MaxFrameExtentForSlowPathCall.h: * bytecode/CallReturnOffsetToBytecodeOffset.h: Removed. It is no longer used. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/CodeBlock.h: (JSC::CodeBlock::calleeSaveRegisters const): (JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters): (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters): (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters): * bytecode/Opcode.h: (JSC::padOpcodeName): * heap/Heap.cpp: (JSC::Heap::gatherJSStackRoots): (JSC::Heap::stopThePeriphery): * interpreter/CLoopStack.cpp: * interpreter/CLoopStack.h: * interpreter/CLoopStackInlines.h: * interpreter/EntryFrame.h: * interpreter/Interpreter.cpp: (JSC::Interpreter::Interpreter): (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const): * interpreter/Interpreter.h: * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::calleeSaveRegisters): * interpreter/VMEntryRecord.h: * jit/ExecutableAllocator.h: * jit/FPRInfo.h: (WTF::printInternal): * jit/GPRInfo.cpp: * jit/GPRInfo.h: (WTF::printInternal): * jit/HostCallReturnValue.cpp: (JSC::getHostCallReturnValueWithExecState): Moved. They are used in LLInt ASM interpreter too. * jit/HostCallReturnValue.h: * jit/JITOperations.cpp: (JSC::getHostCallReturnValueWithExecState): Deleted. * jit/JITOperationsMSVC64.cpp: * jit/Reg.cpp: * jit/Reg.h: * jit/RegisterAtOffset.cpp: * jit/RegisterAtOffset.h: * jit/RegisterAtOffsetList.cpp: * jit/RegisterAtOffsetList.h: * jit/RegisterMap.h: * jit/RegisterSet.cpp: * jit/RegisterSet.h: * jit/TempRegisterSet.cpp: * jit/TempRegisterSet.h: * llint/LLIntCLoop.cpp: * llint/LLIntCLoop.h: * llint/LLIntData.cpp: (JSC::LLInt::initialize): (JSC::LLInt::Data::performAssertions): * llint/LLIntData.h: * llint/LLIntOfflineAsmConfig.h: * llint/LLIntOpcode.h: * llint/LLIntPCRanges.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LLIntThunks.cpp: * llint/LowLevelInterpreter.cpp: * llint/LowLevelInterpreter.h: * runtime/JSCJSValue.h: * runtime/MachineContext.h: * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::processUnverifiedStackTraces): Enable SamplingProfiler for LLInt ASM interpreter with non JIT configuration. * runtime/TestRunnerUtils.cpp: (JSC::optimizeNextInvocation): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::getHostFunction): (JSC::VM::updateSoftReservedZoneSize): (JSC::sanitizeStackForVM): (JSC::VM::committedStackByteCount): * runtime/VM.h: * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): (JSC::VM::isSafeToRecurseSoft const): 2018-09-21 Keith Miller <keith_miller@apple.com> Add Promise SPI https://bugs.webkit.org/show_bug.cgi?id=189809 Reviewed by Saam Barati. The Patch adds new SPI to create promises. It's mostly SPI because I want to see how internal users react to it before we make it public. This patch adds a couple of new Obj-C SPI methods. The first creates a new promise using the same API that JS does where the user provides an executor callback. If an exception is raised in/to that callback the promise is automagically rejected. The other methods create a pre-resolved or rejected promise as this appears to be a common way to initialize a promise. I was also considering adding a second version of executor API where it would catch specific Obj-C exceptions. This would work by taking a Class paramter and checking isKindOfClass: on the exception. I decided against this as nothing else in our API handles Obj-C exceptions. I'm pretty sure the VM will end up in a corrupt state if an Obj-C exception unwinds through JS frames. This patch adds a new C function that will create a "deferred" promise. A deferred promise is a style of creating promise/futures where the resolve and reject functions are passed as outputs of a function. I went with this style for the C SPI because we don't have any concept of forwarding exceptions in the C API. In order to make the C API work I refactored a bit of the promise code so that we can call a static method on JSDeferredPromise and just get the components without allocating an extra cell wrapper. * API/JSContext.mm: (+[JSContext currentCallee]): * API/JSObjectRef.cpp: (JSObjectMakeDeferredPromise): * API/JSObjectRefPrivate.h: * API/JSValue.mm: (+[JSValue valueWithNewPromiseInContext:fromExecutor:]): (+[JSValue valueWithNewPromiseResolvedWithResult:inContext:]): (+[JSValue valueWithNewPromiseRejectedWithReason:inContext:]): * API/JSValuePrivate.h: Added. * API/JSVirtualMachine.mm: * API/JSVirtualMachinePrivate.h: * API/tests/testapi.c: (main): * API/tests/testapi.cpp: (APIContext::operator JSC::ExecState*): (TestAPI::failed const): (TestAPI::check): (TestAPI::basicSymbol): (TestAPI::symbolsTypeof): (TestAPI::symbolsGetPropertyForKey): (TestAPI::symbolsSetPropertyForKey): (TestAPI::symbolsHasPropertyForKey): (TestAPI::symbolsDeletePropertyForKey): (TestAPI::promiseResolveTrue): (TestAPI::promiseRejectTrue): (testCAPIViaCpp): (TestAPI::run): Deleted. * API/tests/testapi.mm: (testObjectiveCAPIMain): (promiseWithExecutor): (promiseRejectOnJSException): (promiseCreateResolved): (promiseCreateRejected): (parallelPromiseResolveTest): (testObjectiveCAPI): * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/JSInternalPromiseDeferred.cpp: (JSC::JSInternalPromiseDeferred::create): * runtime/JSPromise.h: * runtime/JSPromiseConstructor.cpp: (JSC::constructPromise): * runtime/JSPromiseDeferred.cpp: (JSC::JSPromiseDeferred::createDeferredData): (JSC::JSPromiseDeferred::create): (JSC::JSPromiseDeferred::finishCreation): (JSC::newPromiseCapability): Deleted. * runtime/JSPromiseDeferred.h: (JSC::JSPromiseDeferred::promise const): (JSC::JSPromiseDeferred::resolve const): (JSC::JSPromiseDeferred::reject const): 2018-09-21 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r236359. Broke the Windows build. Reverted changeset: "Add Promise SPI" https://bugs.webkit.org/show_bug.cgi?id=189809 https://trac.webkit.org/changeset/236359 2018-09-21 Mark Lam <mark.lam@apple.com> JSRopeString::resolveRope() wrongly assumes that tryGetValue() passes it a valid ExecState. https://bugs.webkit.org/show_bug.cgi?id=189855 <rdar://problem/44680181> Reviewed by Filip Pizlo. tryGetValue() always passes a nullptr to JSRopeString::resolveRope() for the ExecState* argument. This is intentional so that resolveRope() does not throw in the event of an OutOfMemory error. Hence, JSRopeString::resolveRope() should get the VM from the cell instead of via the ExecState. Also removed an obsolete and unused field in JSString. * runtime/JSString.cpp: (JSC::JSRopeString::resolveRope const): (JSC::JSRopeString::outOfMemory const): * runtime/JSString.h: (JSC::JSString::tryGetValue const): 2018-09-21 Michael Saboff <msaboff@apple.com> Add functions to measure memory footprint to JSC https://bugs.webkit.org/show_bug.cgi?id=189768 Reviewed by Saam Barati. Rolling this back in again. Provide system memory metrics for the current process to aid in memory reduction measurement and tuning using native JS tests. * jsc.cpp: (MemoryFootprint::now): (MemoryFootprint::resetPeak): (GlobalObject::finishCreation): (JSCMemoryFootprint::JSCMemoryFootprint): (JSCMemoryFootprint::createStructure): (JSCMemoryFootprint::create): (JSCMemoryFootprint::finishCreation): (JSCMemoryFootprint::addProperty): (functionResetMemoryPeak): 2018-09-21 Keith Miller <keith_miller@apple.com> Add Promise SPI https://bugs.webkit.org/show_bug.cgi?id=189809 Reviewed by Saam Barati. The Patch adds new SPI to create promises. It's mostly SPI because I want to see how internal users react to it before we make it public. This patch adds a couple of new Obj-C SPI methods. The first creates a new promise using the same API that JS does where the user provides an executor callback. If an exception is raised in/to that callback the promise is automagically rejected. The other methods create a pre-resolved or rejected promise as this appears to be a common way to initialize a promise. I was also considering adding a second version of executor API where it would catch specific Obj-C exceptions. This would work by taking a Class paramter and checking isKindOfClass: on the exception. I decided against this as nothing else in our API handles Obj-C exceptions. I'm pretty sure the VM will end up in a corrupt state if an Obj-C exception unwinds through JS frames. This patch adds a new C function that will create a "deferred" promise. A deferred promise is a style of creating promise/futures where the resolve and reject functions are passed as outputs of a function. I went with this style for the C SPI because we don't have any concept of forwarding exceptions in the C API. In order to make the C API work I refactored a bit of the promise code so that we can call a static method on JSDeferredPromise and just get the components without allocating an extra cell wrapper. * API/JSContext.mm: (+[JSContext currentCallee]): * API/JSObjectRef.cpp: (JSObjectMakeDeferredPromise): * API/JSObjectRefPrivate.h: * API/JSValue.mm: (+[JSValue valueWithNewPromiseInContext:fromExecutor:]): (+[JSValue valueWithNewPromiseResolvedWithResult:inContext:]): (+[JSValue valueWithNewPromiseRejectedWithReason:inContext:]): * API/JSValuePrivate.h: Added. * API/JSVirtualMachine.mm: * API/JSVirtualMachinePrivate.h: * API/tests/testapi.c: (main): * API/tests/testapi.cpp: (APIContext::operator JSC::ExecState*): (TestAPI::failed const): (TestAPI::check): (TestAPI::basicSymbol): (TestAPI::symbolsTypeof): (TestAPI::symbolsGetPropertyForKey): (TestAPI::symbolsSetPropertyForKey): (TestAPI::symbolsHasPropertyForKey): (TestAPI::symbolsDeletePropertyForKey): (TestAPI::promiseResolveTrue): (TestAPI::promiseRejectTrue): (testCAPIViaCpp): (TestAPI::run): Deleted. * API/tests/testapi.mm: (testObjectiveCAPIMain): (promiseWithExecutor): (promiseRejectOnJSException): (promiseCreateResolved): (promiseCreateRejected): (parallelPromiseResolveTest): (testObjectiveCAPI): * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/JSInternalPromiseDeferred.cpp: (JSC::JSInternalPromiseDeferred::create): * runtime/JSPromise.h: * runtime/JSPromiseConstructor.cpp: (JSC::constructPromise): * runtime/JSPromiseDeferred.cpp: (JSC::JSPromiseDeferred::createDeferredData): (JSC::JSPromiseDeferred::create): (JSC::JSPromiseDeferred::finishCreation): (JSC::newPromiseCapability): Deleted. * runtime/JSPromiseDeferred.h: (JSC::JSPromiseDeferred::promise const): (JSC::JSPromiseDeferred::resolve const): (JSC::JSPromiseDeferred::reject const): 2018-09-21 Truitt Savell <tsavell@apple.com> Rebaseline tests after changes in https://trac.webkit.org/changeset/236321/webkit https://bugs.webkit.org/show_bug.cgi?id=156674 Unreviewed Test Gardening * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: 2018-09-21 Mike Gorse <mgorse@suse.com> Build tools should work when the /usr/bin/python is python3 https://bugs.webkit.org/show_bug.cgi?id=156674 Reviewed by Michael Catanzaro. * Scripts/cssmin.py: * Scripts/generate-js-builtins.py: (do_open): (generate_bindings_for_builtins_files): * Scripts/generateIntlCanonicalizeLanguage.py: * Scripts/jsmin.py: (JavascriptMinify.minify.write): (JavascriptMinify): (JavascriptMinify.minify): * Scripts/make-js-file-arrays.py: (chunk): (main): * Scripts/wkbuiltins/__init__.py: * Scripts/wkbuiltins/builtins_generate_combined_header.py: (generate_section_for_global_private_code_name_macro): * Scripts/wkbuiltins/builtins_generate_internals_wrapper_header.py: (BuiltinsInternalsWrapperHeaderGenerator.__init__): * Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py: (BuiltinsInternalsWrapperImplementationGenerator.__init__): * Scripts/wkbuiltins/builtins_model.py: (BuiltinFunction.__lt__): (BuiltinsCollection.copyrights): (BuiltinsCollection._parse_functions): * disassembler/udis86/ud_opcode.py: (UdOpcodeTables.pprint.printWalk): * generate-bytecode-files: * inspector/scripts/codegen/__init__.py: * inspector/scripts/codegen/cpp_generator.py: * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py: (CppAlternateBackendDispatcherHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: (CppBackendDispatcherHeaderGenerator.domains_to_generate): (CppBackendDispatcherHeaderGenerator.generate_output): (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain): * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py: (CppBackendDispatcherImplementationGenerator.domains_to_generate): (CppBackendDispatcherImplementationGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py: (CppFrontendDispatcherHeaderGenerator.domains_to_generate): (CppFrontendDispatcherHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py: (CppFrontendDispatcherImplementationGenerator.domains_to_generate): (CppFrontendDispatcherImplementationGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: (CppProtocolTypesHeaderGenerator.generate_output): (CppProtocolTypesHeaderGenerator._generate_forward_declarations): * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: (CppProtocolTypesImplementationGenerator.generate_output): (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain): (CppProtocolTypesImplementationGenerator._generate_enum_mapping_and_conversion_methods): (CppProtocolTypesImplementationGenerator._generate_open_field_names): (CppProtocolTypesImplementationGenerator._generate_builders_for_domain): (CppProtocolTypesImplementationGenerator._generate_assertion_for_object_declaration): * inspector/scripts/codegen/generate_js_backend_commands.py: (JSBackendCommandsGenerator.should_generate_domain): (JSBackendCommandsGenerator.domains_to_generate): (JSBackendCommandsGenerator.generate_output): (JSBackendCommandsGenerator.generate_domain): * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py: (ObjCBackendDispatcherHeaderGenerator.domains_to_generate): (ObjCBackendDispatcherHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py: (ObjCBackendDispatcherImplementationGenerator.domains_to_generate): (ObjCBackendDispatcherImplementationGenerator.generate_output): (ObjCBackendDispatcherImplementationGenerator._generate_success_block_for_command): * inspector/scripts/codegen/generate_objc_configuration_header.py: * inspector/scripts/codegen/generate_objc_configuration_implementation.py: * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py: (ObjCFrontendDispatcherImplementationGenerator.domains_to_generate): (ObjCFrontendDispatcherImplementationGenerator.generate_output): (ObjCFrontendDispatcherImplementationGenerator._generate_event): * inspector/scripts/codegen/generate_objc_header.py: (ObjCHeaderGenerator.generate_output): (ObjCHeaderGenerator._generate_type_interface): * inspector/scripts/codegen/generate_objc_internal_header.py: (ObjCInternalHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py: (ObjCProtocolTypeConversionsHeaderGenerator.domains_to_generate): (ObjCProtocolTypeConversionsHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py: (ObjCProtocolTypeConversionsImplementationGenerator.domains_to_generate): * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator.domains_to_generate): (ObjCProtocolTypesImplementationGenerator.generate_output): (ObjCProtocolTypesImplementationGenerator.generate_type_implementation): (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members): * inspector/scripts/codegen/generator.py: (Generator.non_supplemental_domains): (Generator.open_fields): (Generator.calculate_types_requiring_shape_assertions): (Generator._traverse_and_assign_enum_values): (Generator.stylized_name_for_enum_value): * inspector/scripts/codegen/models.py: (find_duplicates): * inspector/scripts/codegen/objc_generator.py: * wasm/generateWasm.py: (opcodeIterator): * yarr/generateYarrCanonicalizeUnicode: * yarr/generateYarrUnicodePropertyTables.py: * yarr/hasher.py: (stringHash): 2018-09-21 Tomas Popela <tpopela@redhat.com> [ARM] Build broken on armv7hl after r235517 https://bugs.webkit.org/show_bug.cgi?id=189831 Reviewed by Yusuke Suzuki. Add missing implementation of patchebleBranch8() for traditional ARM. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::patchableBranch8): 2018-09-20 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r236293. Internal build still broken. Reverted changeset: "Add functions to measure memory footprint to JSC" https://bugs.webkit.org/show_bug.cgi?id=189768 https://trac.webkit.org/changeset/236293 2018-09-20 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Heap::reportExtraMemoryVisited shows contention if we have many JSString https://bugs.webkit.org/show_bug.cgi?id=189558 Reviewed by Mark Lam. When running web-tooling-benchmark postcss test on Linux JSCOnly port, we get the following result in `perf report`. 10.95% AutomaticThread libJavaScriptCore.so.1.0.0 [.] JSC::Heap::reportExtraMemoryVisited This is because postcss produces bunch of JSString, which require reportExtraMemoryVisited calls in JSString::visitChildren. And since reportExtraMemoryVisited attempts to update atomic counter, if we have bunch of marking threads, it becomes super contended. This patch reduces the frequency of updating the atomic counter. Each SlotVisitor has per-SlotVisitor m_extraMemorySize counter. And we propagate this value to the global atomic counter when rebalance happens. We also reduce HeapCell::heap() access by using `vm.heap`. * heap/SlotVisitor.cpp: (JSC::SlotVisitor::didStartMarking): (JSC::SlotVisitor::propagateExternalMemoryVisitedIfNecessary): (JSC::SlotVisitor::drain): (JSC::SlotVisitor::performIncrementOfDraining): * heap/SlotVisitor.h: * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::reportExtraMemoryVisited): * runtime/JSString.cpp: (JSC::JSRopeString::resolveRopeToAtomicString const): (JSC::JSRopeString::resolveRope const): * runtime/JSString.h: (JSC::JSString::finishCreation): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finishCreation): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::finishCreation): 2018-09-20 Michael Saboff <msaboff@apple.com> Add functions to measure memory footprint to JSC https://bugs.webkit.org/show_bug.cgi?id=189768 Reviewed by Saam Barati. Rolling this back in. Provide system memory metrics for the current process to aid in memory reduction measurement and tuning using native JS tests. * jsc.cpp: (MemoryFootprint::now): (MemoryFootprint::resetPeak): (GlobalObject::finishCreation): (JSCMemoryFootprint::JSCMemoryFootprint): (JSCMemoryFootprint::createStructure): (JSCMemoryFootprint::create): (JSCMemoryFootprint::finishCreation): (JSCMemoryFootprint::addProperty): (functionResetMemoryPeak): 2018-09-20 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r236235. Breaks internal builds. Reverted changeset: "Add functions to measure memory footprint to JSC" https://bugs.webkit.org/show_bug.cgi?id=189768 https://trac.webkit.org/changeset/236235 2018-09-20 Fujii Hironori <Hironori.Fujii@sony.com> [Win][Clang] JITMathIC.h: error: missing 'template' keyword prior to dependent template name 'retagged' https://bugs.webkit.org/show_bug.cgi?id=189730 Reviewed by Saam Barati. Clang for Windows can't compile the workaround for MSVC quirk in generateOutOfLine. * jit/JITMathIC.h: (generateOutOfLine): Append "&& !COMPILER(CLANG)" to "#if COMPILER(MSVC)". 2018-09-19 Yusuke Suzuki <yusukesuzuki@slowstart.org> [JSC] Optimize Array#indexOf in C++ runtime https://bugs.webkit.org/show_bug.cgi?id=189507 Reviewed by Saam Barati. C++ Array#indexOf runtime function takes so much time in babylon benchmark in web-tooling-benchmark. While our DFG and FTL has Array#indexOf optimization and actually it is working well, C++ Array#indexOf is called significant amount of time before tiering up, and it takes 6.74% of jsc main thread samples according to perf command in Linux. This is because C++ Array#indexOf is too generic and misses the chance to optimize JSArray cases. This patch adds JSArray fast path for Array#indexOf. If we know that indexed access to the given JSArray is non-observable and indexing type is good for the fast path, we go to the fast path. This makes sampling of Array#indexOf 3.83% in babylon web-tooling-benchmark. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncIndexOf): * runtime/JSArray.h: * runtime/JSArrayInlines.h: (JSC::JSArray::canDoFastIndexedAccess): (JSC::toLength): * runtime/JSCJSValueInlines.h: (JSC::JSValue::JSValue): * runtime/JSGlobalObject.h: * runtime/JSGlobalObjectInlines.h: (JSC::JSGlobalObject::isArrayPrototypeIndexedAccessFastAndNonObservable): (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable): * runtime/MathCommon.h: (JSC::canBeStrictInt32): (JSC::canBeInt32): 2018-09-19 Michael Saboff <msaboff@apple.com> Add functions to measure memory footprint to JSC https://bugs.webkit.org/show_bug.cgi?id=189768 Reviewed by Saam Barati. Provide system memory metrics for the current process to aid in memory reduction measurement and tuning using native JS tests. * jsc.cpp: (MemoryFootprint::now): (MemoryFootprint::resetPeak): (GlobalObject::finishCreation): (JSCMemoryFootprint::JSCMemoryFootprint): (JSCMemoryFootprint::createStructure): (JSCMemoryFootprint::create): (JSCMemoryFootprint::finishCreation): (JSCMemoryFootprint::addProperty): (functionResetMemoryPeak): 2018-09-19 Saam barati <sbarati@apple.com> CheckStructureOrEmpty should pass in a tempGPR to emitStructureCheck since it may jump over that code https://bugs.webkit.org/show_bug.cgi?id=189703 Reviewed by Mark Lam. This fixes a crash that a TypeProfiler change revealed. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2018-09-19 Saam barati <sbarati@apple.com> AI rule for MultiPutByOffset executes its effects in the wrong order https://bugs.webkit.org/show_bug.cgi?id=189757 <rdar://problem/43535257> Reviewed by Michael Saboff. The AI rule for MultiPutByOffset was executing effects in the wrong order. It first executed the transition effects and the effects on the base, and then executed the filtering effects on the value being stored. However, you can end up with the wrong type when the base and the value being stored are the same. E.g, in a program like `o.f = o`. These effects need to happen in the opposite order, modeling what happens in the runtime executing of MultiPutByOffset. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): 2018-09-18 Mark Lam <mark.lam@apple.com> Ensure that ForInContexts are invalidated if their loop local is over-written. https://bugs.webkit.org/show_bug.cgi?id=189571 <rdar://problem/44402277> Reviewed by Saam Barati. Instead of hunting down every place in the BytecodeGenerator that potentially needs to invalidate an enclosing ForInContext (if one exists), we simply iterate the bytecode range of the loop body when the ForInContext is popped, and invalidate the context if we ever find the loop temp variable over-written. This has 2 benefits: 1. It ensures that every type of opcode that can write to the loop temp will be handled appropriately, not just the op_mov that we've hunted down. 2. It avoids us having to check the BytecodeGenerator's m_forInContextStack every time we emit an op_mov (or other opcodes that can write to a local) even when we're not inside a for-in loop. JSC benchmarks show that that this change is performance neutral. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::pushIndexedForInScope): (JSC::BytecodeGenerator::popIndexedForInScope): (JSC::BytecodeGenerator::pushStructureForInScope): (JSC::BytecodeGenerator::popStructureForInScope): (JSC::ForInContext::finalize): (JSC::StructureForInContext::finalize): (JSC::IndexedForInContext::finalize): (JSC::BytecodeGenerator::invalidateForInContextForLocal): Deleted. * bytecompiler/BytecodeGenerator.h: (JSC::ForInContext::ForInContext): (JSC::ForInContext::bodyBytecodeStartOffset const): (JSC::StructureForInContext::StructureForInContext): (JSC::IndexedForInContext::IndexedForInContext): * bytecompiler/NodesCodegen.cpp: (JSC::PostfixNode::emitResolve): (JSC::PrefixNode::emitResolve): (JSC::ReadModifyResolveNode::emitBytecode): (JSC::AssignResolveNode::emitBytecode): (JSC::EmptyLetExpression::emitBytecode): (JSC::ForInNode::emitLoopHeader): (JSC::ForOfNode::emitBytecode): (JSC::BindingNode::bindValue const): (JSC::AssignmentElementNode::bindValue const): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): 2018-09-17 Devin Rousso <drousso@apple.com> Web Inspector: generate CSSKeywordCompletions from backend values https://bugs.webkit.org/show_bug.cgi?id=189041 Reviewed by Joseph Pecoraro. * inspector/protocol/CSS.json: Include an optional `aliases` array and `inherited` boolean for `CSSPropertyInfo`. 2018-09-17 Saam barati <sbarati@apple.com> We must convert ProfileType to CheckStructureOrEmpty instead of CheckStructure https://bugs.webkit.org/show_bug.cgi?id=189676 <rdar://problem/39682897> Reviewed by Michael Saboff. Because the incoming value may be TDZ, CheckStructure may end up crashing. Since the Type Profile does not currently record TDZ values in any of its data structures, this is not a semantic change in how it will show you data. It just fixes crashes when we emit a CheckStructure and the incoming value is TDZ. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::convertToCheckStructureOrEmpty): 2018-09-17 Darin Adler <darin@apple.com> Use OpaqueJSString rather than JSRetainPtr inside WebKit https://bugs.webkit.org/show_bug.cgi?id=189652 Reviewed by Saam Barati. * API/JSCallbackObjectFunctions.h: Removed an uneeded include of JSStringRef.h. * API/JSContext.mm: (-[JSContext evaluateScript:withSourceURL:]): Use OpaqueJSString::create rather than JSStringCreateWithCFString, simplifying the code and also obviating the need for explicit JSStringRelease. (-[JSContext setName:]): Ditto. * API/JSStringRef.cpp: (JSStringIsEqualToUTF8CString): Use adoptRef rather than explicit JSStringRelease. It seems that additional optimization is possible, obviating the need to allocate an OpaqueJSString, but that's true almost everywhere else in this patch, too. * API/JSValue.mm: (+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]): Use OpaqueJSString::create and adoptRef as appropriate. (+[JSValue valueWithNewErrorFromMessage:inContext:]): Ditto. (+[JSValue valueWithNewSymbolFromDescription:inContext:]): Ditto. (performPropertyOperation): Ditto. (-[JSValue invokeMethod:withArguments:]): Ditto. (valueToObjectWithoutCopy): Ditto. (containerValueToObject): Ditto. (valueToString): Ditto. (objectToValueWithoutCopy): Ditto. (objectToValue): Ditto. 2018-09-08 Darin Adler <darin@apple.com> Streamline JSRetainPtr, fix leaks of JSString and JSGlobalContext https://bugs.webkit.org/show_bug.cgi?id=189455 Reviewed by Keith Miller. * API/JSObjectRef.cpp: (OpaqueJSPropertyNameArray): Use Ref<OpaqueJSString> instead of JSRetainPtr<JSStringRef>. (JSObjectCopyPropertyNames): Remove now-unneeded use of leakRef and adopt constructor. (JSPropertyNameArrayGetNameAtIndex): Use ptr() instead of get() since the array elements are now Ref. * API/JSRetainPtr.h: While JSRetainPtr is written as a template, it only works for two specific unrelated types, JSStringRef and JSGlobalContextRef. Simplified the default constructor using data member initialization. Prepared to make the adopt constructor private (got everything compiling that way, then made it public again so that Apple internal software will still build). Got rid of unneeded templated constructor and assignment operator, since it's not relevant since there is no inheritance between JSRetainPtr template types. Added WARN_UNUSED_RETURN to leakRef as in RefPtr and RetainPtr. Added move constructor and move assignment operator for slightly better performance. Simplified implementations of various member functions so they are more obviously correct, by using leakPtr in more of them and using std::exchange to make the flow of values more obvious. * API/JSValue.mm: (+[JSValue valueWithNewSymbolFromDescription:inContext:]): Added a missing JSStringRelease to fix a leak. * API/tests/CustomGlobalObjectClassTest.c: (customGlobalObjectClassTest): Added a JSGlobalContextRelease to fix a leak. (globalObjectSetPrototypeTest): Ditto. (globalObjectPrivatePropertyTest): Ditto. * API/tests/ExecutionTimeLimitTest.cpp: (testResetAfterTimeout): Added a call to JSStringRelease to fix a leak. (testExecutionTimeLimit): Ditto, lots more. * API/tests/FunctionOverridesTest.cpp: (testFunctionOverrides): Added a call to JSStringRelease to fix a leak. * API/tests/JSObjectGetProxyTargetTest.cpp: (testJSObjectGetProxyTarget): Added a call to JSGlobalContextRelease to fix a leak. * API/tests/PingPongStackOverflowTest.cpp: (testPingPongStackOverflow): Added calls to JSGlobalContextRelease and JSStringRelease to fix leaks. * API/tests/testapi.c: (throwException): Added. Helper function for repeated idiom where we want to throw an exception, but with additional JSStringRelease calls so we don't have to leak just to keep the code simpler to read. (MyObject_getProperty): Use throwException. (MyObject_setProperty): Ditto. (MyObject_deleteProperty): Ditto. (isValueEqualToString): Added. Helper function for an idiom where we check if something is a string and then if it's equal to a particular string constant, but a version that has an additional JSStringRelease call so we don't have to leak just to keep the code simpler to read. (MyObject_callAsFunction): Use isValueEqualToString and throwException. (MyObject_callAsConstructor): Ditto. (MyObject_hasInstance): Ditto. (globalContextNameTest): Added a JSGlobalContextRelease to fix a leak. (testMarkingConstraintsAndHeapFinalizers): Ditto. 2018-09-14 Saam barati <sbarati@apple.com> Don't dump OSRAvailabilityData in Graph::dump because a stale Availability may point to a Node that is already freed https://bugs.webkit.org/show_bug.cgi?id=189628 <rdar://problem/39481690> Reviewed by Mark Lam. An Availability may point to a Node. And that Node may be removed from the graph, e.g, it's freed and its memory is no longer owned by Graph. This patch makes it so we no longer dump this metadata by default. If this metadata is interesting to you, you'll need to go in and change Graph::dump to dump the needed metadata. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): 2018-09-14 Mark Lam <mark.lam@apple.com> Refactor some ForInContext code for better encapsulation. https://bugs.webkit.org/show_bug.cgi?id=189626 <rdar://problem/44466415> Reviewed by Keith Miller. 1. Add a ForInContext::m_type field to store the context type. This does not increase the class size, but eliminates the need for a virtual call to get the type. Note: we still need a virtual destructor because we'll be mingling IndexedForInContexts and StructureForInContexts in the BytecodeGenerator::m_forInContextStack. 2. Add ForInContext::isIndexedForInContext() and ForInContext::isStructureForInContext() convenience methods. 3. Add ForInContext::asIndexedForInContext() and ForInContext::asStructureForInContext() to do the casting to the subclass types. This ensures that we'll properly assert that the casting is legal. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitGetByVal): (JSC::BytecodeGenerator::popIndexedForInScope): (JSC::BytecodeGenerator::popStructureForInScope): * bytecompiler/BytecodeGenerator.h: (JSC::ForInContext::type const): (JSC::ForInContext::isIndexedForInContext const): (JSC::ForInContext::isStructureForInContext const): (JSC::ForInContext::asIndexedForInContext): (JSC::ForInContext::asStructureForInContext): (JSC::ForInContext::ForInContext): (JSC::StructureForInContext::StructureForInContext): (JSC::IndexedForInContext::IndexedForInContext): (JSC::ForInContext::~ForInContext): Deleted. 2018-09-14 Devin Rousso <webkit@devinrousso.com> Web Inspector: Record actions performed on ImageBitmapRenderingContext https://bugs.webkit.org/show_bug.cgi?id=181341 Reviewed by Joseph Pecoraro. * inspector/protocol/Recording.json: * inspector/scripts/codegen/generator.py: 2018-09-14 Mike Gorse <mgorse@suse.com> builtins directory causes name conflict on Python 3 https://bugs.webkit.org/show_bug.cgi?id=189552 Reviewed by Michael Catanzaro. * CMakeLists.txt: builtins -> wkbuiltins. * DerivedSources.make: builtins -> wkbuiltins. * Scripts/generate-js-builtins.py: import wkbuiltins, rather than builtins. * Scripts/wkbuiltins/__init__.py: Renamed from Source/JavaScriptCore/Scripts/builtins/__init__.py. * Scripts/wkbuiltins/builtins_generate_combined_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_combined_header.py. * Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_internals_wrapper_implementation.py. * Scripts/wkbuiltins/builtins_generate_separate_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_separate_header.py. * Scripts/wkbuiltins/builtins_generate_separate_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_separate_implementation.py. * Scripts/wkbuiltins/builtins_generate_wrapper_header.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_wrapper_header.py. * Scripts/wkbuiltins/builtins_generate_wrapper_implementation.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generate_wrapper_implementation.py. * Scripts/wkbuiltins/builtins_generator.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_generator.py. * Scripts/wkbuiltins/builtins_model.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_model.py. * Scripts/wkbuiltins/builtins_templates.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins_templates.py. * Scripts/wkbuiltins/wkbuiltins.py: Renamed from Source/JavaScriptCore/Scripts/builtins/builtins.py. * JavaScriptCore.xcodeproj/project.pbxproj: Update for the renaming. 2018-09-13 Yusuke Suzuki <yusukesuzuki@slowstart.org> [WebAssembly] Inline WasmContext accessor functions https://bugs.webkit.org/show_bug.cgi?id=189416 Reviewed by Saam Barati. WasmContext accessor functions are very small while it resides in the critical path of JS to Wasm function call. This patch makes them inline to improve performance. This change improves a small benchmark (calling JS to Wasm function 1e7 times) from 320ms to 270ms. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * interpreter/CallFrame.cpp: * jit/AssemblyHelpers.cpp: * wasm/WasmB3IRGenerator.cpp: * wasm/WasmContextInlines.h: Renamed from Source/JavaScriptCore/wasm/WasmContext.cpp. (JSC::Wasm::Context::useFastTLS): (JSC::Wasm::Context::load const): (JSC::Wasm::Context::store): * wasm/WasmMemoryInformation.cpp: * wasm/WasmModuleParser.cpp: Include <wtf/SHA1.h> due to changes of unified source combinations. * wasm/js/JSToWasm.cpp: * wasm/js/WebAssemblyFunction.cpp: 2018-09-12 David Kilzer <ddkilzer@apple.com> Move JavaScriptCore files to match Xcode project hierarchy <https://webkit.org/b/189574> Reviewed by Filip Pizlo. * API/JSAPIValueWrapper.cpp: Rename from Source/JavaScriptCore/runtime/JSAPIValueWrapper.cpp. * API/JSAPIValueWrapper.h: Rename from Source/JavaScriptCore/runtime/JSAPIValueWrapper.h. * CMakeLists.txt: Update for new path to generateYarrUnicodePropertyTables.py, hasher.py and JSAPIValueWrapper.h. * DerivedSources.make: Ditto. Add missing dependency on hasher.py captured by CMakeLists.txt. * JavaScriptCore.xcodeproj/project.pbxproj: Update for new file reference paths. Add hasher.py library to project. * Sources.txt: Update for new path to JSAPIValueWrapper.cpp. * runtime/JSImmutableButterfly.h: Add missing includes after changes to Sources.txt and regenerating unified sources. * runtime/RuntimeType.h: Ditto. * yarr/generateYarrUnicodePropertyTables.py: Rename from Source/JavaScriptCore/Scripts/generateYarrUnicodePropertyTables.py. * yarr/hasher.py: Rename from Source/JavaScriptCore/Scripts/hasher.py. 2018-09-12 David Kilzer <ddkilzer@apple.com> Let Xcode have its way with the JavaScriptCore project * JavaScriptCore.xcodeproj/project.pbxproj: 2018-09-12 Guillaume Emont <guijemont@igalia.com> Add IGNORE_WARNING_.* macros https://bugs.webkit.org/show_bug.cgi?id=188996 Reviewed by Michael Catanzaro. * API/JSCallbackObject.h: * API/tests/testapi.c: * assembler/LinkBuffer.h: (JSC::LinkBuffer::finalizeCodeWithDisassembly): * b3/B3LowerToAir.cpp: * b3/B3Opcode.cpp: * b3/B3Type.h: * b3/B3TypeMap.h: * b3/B3Width.h: * b3/air/AirArg.cpp: * b3/air/AirArg.h: * b3/air/AirCode.h: * bytecode/Opcode.h: (JSC::padOpcodeName): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateNumber): (JSC::DFG::SpeculativeJIT::speculateMisc): * dfg/DFGSpeculativeJIT64.cpp: * ftl/FTLOutput.h: * jit/CCallHelpers.h: (JSC::CCallHelpers::calculatePokeOffset): * llint/LLIntData.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::slowPathLogF): * runtime/ConfigFile.cpp: (JSC::ConfigFile::canonicalizePaths): * runtime/JSDataViewPrototype.cpp: * runtime/JSGenericTypedArrayViewConstructor.h: * runtime/JSGenericTypedArrayViewPrototype.h: * runtime/Options.cpp: (JSC::Options::setAliasedOption): * tools/CodeProfiling.cpp: * wasm/WasmSections.h: * wasm/generateWasmValidateInlinesHeader.py: == Rolled over to ChangeLog-2018-09-11 ==