2019-10-03 Alan Coon <alancoon@apple.com> Cherry-pick r249538. rdar://problem/55911485 LazyClassStructure::setConstructor should not store the constructor to the global object https://bugs.webkit.org/show_bug.cgi?id=201484 <rdar://problem/50400451> Reviewed by Yusuke Suzuki. JSTests: * stress/web-assembly-constructors-should-not-override-global-object-property.js: Added. Source/JavaScriptCore: LazyClassStructure::setConstructor sets the constructor as a property of the global object. This became a problem when it started being used for WebAssembly constructors, such as Module and Instance, since they are properties of the WebAssembly object, not the global object. That resulted in properties of the global object replaced whenever a lazy WebAssembly constructor was first accessed. e.g. globalThis.Module = x; WebAssembly.Module; globalThis.Module === WebAssembly.Module; * runtime/LazyClassStructure.cpp: (JSC::LazyClassStructure::Initializer::setConstructor): * runtime/LazyClassStructure.h: * runtime/Lookup.h: (JSC::reifyStaticProperty): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249538 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-05 Tadeu Zagallo <tzagallo@apple.com> LazyClassStructure::setConstructor should not store the constructor to the global object https://bugs.webkit.org/show_bug.cgi?id=201484 <rdar://problem/50400451> Reviewed by Yusuke Suzuki. LazyClassStructure::setConstructor sets the constructor as a property of the global object. This became a problem when it started being used for WebAssembly constructors, such as Module and Instance, since they are properties of the WebAssembly object, not the global object. That resulted in properties of the global object replaced whenever a lazy WebAssembly constructor was first accessed. e.g. globalThis.Module = x; WebAssembly.Module; globalThis.Module === WebAssembly.Module; * runtime/LazyClassStructure.cpp: (JSC::LazyClassStructure::Initializer::setConstructor): * runtime/LazyClassStructure.h: * runtime/Lookup.h: (JSC::reifyStaticProperty): 2019-09-30 Babak Shafiei <bshafiei@apple.com> Cherry-pick r250058. rdar://problem/55826329 Phantom insertion phase may disagree with arguments forwarding about live ranges https://bugs.webkit.org/show_bug.cgi?id=200715 <rdar://problem/54301717> Reviewed by Yusuke Suzuki. JSTests: * stress/phantom-insertion-live-range-should-agree-with-arguments-forwarding.js: Added. (main.v23): (main.try.v43): (main.): (main): Source/JavaScriptCore: The issue is that Phantom insertion phase was disagreeing about live ranges from the arguments forwarding phase. The effect is that Phantom insertion would insert a Phantom creating a longer live range than what arguments forwarding was analyzing. Arguments forwarding will look for the last DFG use or the last bytecode use of a variable it wants to eliminate. It then does an interference analysis to ensure that nothing clobbers other variables it needs to recover the sunken allocation during OSR exit. Phantom insertion works by ordering the program into OSR exit epochs. If a value was used in the current epoch, there is no need to insert a phantom for it. We determine where we might need a Phantom by looking at bytecode kills. In this analysis, we have a mapping from bytecode local to DFG node. However, we sometimes forgot to remove the entry when a local is killed. So, if the first kill of a variable is in the same OSR exit epoch, we won't insert a Phantom by design. However, if the variable gets killed again, we might errantly insert a Phantom for the prior variable which should've already been killed. The solution is to clear the entry in our mapping when a variable is killed. The program in question was like this: 1: DirectArguments ... 2: MovHint(@1, loc1) // arguments forwarding treats this as the final kill for @1 ... clobber things needed for recovery ... Arguments elimination would transform the program since between @1 and @2, nothing clobbers values needed for exit and nothing escapes @1. The program becomes: 1: PhantomDirectArguments ... 2: MovHint(@1, loc1) // arguments forwarding treats this as the final kill for @1 ... clobber things needed for recovery of @1 ... Phantom insertion would then transform the program into: 1: PhantomDirectArguments ... 2: MovHint(@1, loc1) // arguments forwarding treats this as the final kill for @1 ... clobber things needed for recovery of @1 ... 3: Phantom(@1) ... This is wrong because Phantom insertion and arguments forwarding must agree on live ranges, otherwise the interference analysis performed by arguments forwarding will not correctly analyze up until where the value might be recovered. * dfg/DFGPhantomInsertionPhase.cpp: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250058 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-18 Saam Barati <sbarati@apple.com> Phantom insertion phase may disagree with arguments forwarding about live ranges https://bugs.webkit.org/show_bug.cgi?id=200715 <rdar://problem/54301717> Reviewed by Yusuke Suzuki. The issue is that Phantom insertion phase was disagreeing about live ranges from the arguments forwarding phase. The effect is that Phantom insertion would insert a Phantom creating a longer live range than what arguments forwarding was analyzing. Arguments forwarding will look for the last DFG use or the last bytecode use of a variable it wants to eliminate. It then does an interference analysis to ensure that nothing clobbers other variables it needs to recover the sunken allocation during OSR exit. Phantom insertion works by ordering the program into OSR exit epochs. If a value was used in the current epoch, there is no need to insert a phantom for it. We determine where we might need a Phantom by looking at bytecode kills. In this analysis, we have a mapping from bytecode local to DFG node. However, we sometimes forgot to remove the entry when a local is killed. So, if the first kill of a variable is in the same OSR exit epoch, we won't insert a Phantom by design. However, if the variable gets killed again, we might errantly insert a Phantom for the prior variable which should've already been killed. The solution is to clear the entry in our mapping when a variable is killed. The program in question was like this: 1: DirectArguments ... 2: MovHint(@1, loc1) // arguments forwarding treats this as the final kill for @1 ... clobber things needed for recovery ... Arguments elimination would transform the program since between @1 and @2, nothing clobbers values needed for exit and nothing escapes @1. The program becomes: 1: PhantomDirectArguments ... 2: MovHint(@1, loc1) // arguments forwarding treats this as the final kill for @1 ... clobber things needed for recovery of @1 ... Phantom insertion would then transform the program into: 1: PhantomDirectArguments ... 2: MovHint(@1, loc1) // arguments forwarding treats this as the final kill for @1 ... clobber things needed for recovery of @1 ... 3: Phantom(@1) ... This is wrong because Phantom insertion and arguments forwarding must agree on live ranges, otherwise the interference analysis performed by arguments forwarding will not correctly analyze up until where the value might be recovered. * dfg/DFGPhantomInsertionPhase.cpp: 2019-09-30 Babak Shafiei <bshafiei@apple.com> Cherry-pick r249926. rdar://problem/55826870 [JSC] Perform check again when we found non-BMP characters https://bugs.webkit.org/show_bug.cgi?id=201647 Reviewed by Yusuke Suzuki. JSTests: * stress/regexp-unicode-surrogate-pair-increment-should-involve-length-check.js: Added. * stress/regexp-unicode-within-string.js: Updated test to eliminate the bogus print(). (testRegExpInbounds): Source/JavaScriptCore: We need to check for end of input for non-BMP characters when matching a character class that contains both BMP and non-BMP characters. In advanceIndexAfterCharacterClassTermMatch() we were checking for end of input for both BMP and non-BMP characters. For BMP characters, this check is redundant. After moving the check to after the "is BMP check", we need to decrement index after reaching the failure label to back out the index++ for the first surrogate of the non-BMP character. Added the same kind of check in generateCharacterClassOnce(). In that case, we have pre-checked the first character (surrogate) for a non-BMP codepoint, so we just need to check for end of input before we increment for the second surrogate. While writing tests, I found an off by one error in backtrackCharacterClassGreedy() and changed the loop to check the count at loop top instead of loop bottom. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::advanceIndexAfterCharacterClassTermMatch): (JSC::Yarr::YarrGenerator::generateCharacterClassOnce): (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy): (JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy): (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249926 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-16 Michael Saboff <msaboff@apple.com> [JSC] Perform check again when we found non-BMP characters https://bugs.webkit.org/show_bug.cgi?id=201647 Reviewed by Yusuke Suzuki. We need to check for end of input for non-BMP characters when matching a character class that contains both BMP and non-BMP characters. In advanceIndexAfterCharacterClassTermMatch() we were checking for end of input for both BMP and non-BMP characters. For BMP characters, this check is redundant. After moving the check to after the "is BMP check", we need to decrement index after reaching the failure label to back out the index++ for the first surrogate of the non-BMP character. Added the same kind of check in generateCharacterClassOnce(). In that case, we have pre-checked the first character (surrogate) for a non-BMP codepoint, so we just need to check for end of input before we increment for the second surrogate. While writing tests, I found an off by one error in backtrackCharacterClassGreedy() and changed the loop to check the count at loop top instead of loop bottom. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::advanceIndexAfterCharacterClassTermMatch): (JSC::Yarr::YarrGenerator::generateCharacterClassOnce): (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy): (JSC::Yarr::YarrGenerator::backtrackCharacterClassGreedy): (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy): 2019-09-30 Babak Shafiei <bshafiei@apple.com> Cherry-pick r249777. rdar://problem/55826876 JSC crashes due to stack overflow while building RegExp https://bugs.webkit.org/show_bug.cgi?id=201649 Reviewed by Yusuke Suzuki. JSTests: New regression test. * stress/regexp-bol-optimize-out-of-stack.js: Added. (test): (catch): Source/JavaScriptCore: Check for running out of stack when we are optimizing RegExp containing BOL terms or other deep copying of disjunctions. * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::copyDisjunction): (JSC::Yarr::YarrPatternConstructor::copyTerm): (JSC::Yarr::YarrPatternConstructor::error): (JSC::Yarr::YarrPattern::compile): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249777 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-11 Michael Saboff <msaboff@apple.com> JSC crashes due to stack overflow while building RegExp https://bugs.webkit.org/show_bug.cgi?id=201649 Reviewed by Yusuke Suzuki. Check for running out of stack when we are optimizing RegExp containing BOL terms or other deep copying of disjunctions. * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::copyDisjunction): (JSC::Yarr::YarrPatternConstructor::copyTerm): (JSC::Yarr::YarrPatternConstructor::error): (JSC::Yarr::YarrPattern::compile): 2019-09-30 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248951. rdar://problem/55826863 [JSC] incorrent JIT lead to StackOverflow https://bugs.webkit.org/show_bug.cgi?id=197823 Reviewed by Tadeu Zagallo. JSTests: New test. * stress/bound-function-stack-overflow.js: Added. (foo): (catch): Source/JavaScriptCore: Added stack overflow check to the bound function thunk generator. Added a new C++ operation throwStackOverflowErrorFromThunk() to throw the error. * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/ThunkGenerators.cpp: (JSC::boundThisNoArgsFunctionCallGenerator): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248951 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-21 Michael Saboff <msaboff@apple.com> [JSC] incorrent JIT lead to StackOverflow https://bugs.webkit.org/show_bug.cgi?id=197823 Reviewed by Tadeu Zagallo. Added stack overflow check to the bound function thunk generator. Added a new C++ operation throwStackOverflowErrorFromThunk() to throw the error. * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/ThunkGenerators.cpp: (JSC::boundThisNoArgsFunctionCallGenerator): 2019-09-30 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248796. rdar://problem/55826874 [Re-land] ProxyObject should not be allow to access its target's private properties. https://bugs.webkit.org/show_bug.cgi?id=200739 <rdar://problem/53972768> Reviewed by Yusuke Suzuki. JSTests: * stress/proxy-should-not-be-allowed-to-access-private-properties-of-target.js: Copied from JSTests/stress/proxy-should-not-be-allowed-to-access-private-properties-of-target.js. * stress/proxy-with-private-symbols.js: Source/JavaScriptCore: Re-landing this after r200829 which resolves the test262 failure uncovered by this patch. * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::performPut): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::performDefineOwnProperty): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248796 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-16 Mark Lam <mark.lam@apple.com> [Re-land] ProxyObject should not be allow to access its target's private properties. https://bugs.webkit.org/show_bug.cgi?id=200739 <rdar://problem/53972768> Reviewed by Yusuke Suzuki. Re-landing this after r200829 which resolves the test262 failure uncovered by this patch. * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::performPut): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::performDefineOwnProperty): 2019-09-30 Babak Shafiei <bshafiei@apple.com> Cherry-pick r247799. rdar://problem/55826880 performJITMemcpy should be PACed with a non-zero diversifier when passed and called via a pointer. https://bugs.webkit.org/show_bug.cgi?id=200100 <rdar://problem/53474939> Reviewed by Yusuke Suzuki. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::CopyFunction::CopyFunction): (JSC::ARM64Assembler::CopyFunction::operator()): - I choose to use ptrauth_auth_function() here instead of retagCodePtr() because retagCodePtr() would auth, assert, and re-pac the pointer. This is needed in general because retagCodePtr() doesn't know that you will consume the pointer immediately (and therefore crash imminently if a failed auth is encountered). Since we know here that we will call with the auth'ed pointer immediately, we can skip the assert. This also has the benefit of letting Clang do a peephole optimization to emit a blrab instruction with the intended diversifier, instead of emitting multiple instructions to auth the pointer into a C function, and then using a blraaz to do a C function call. (JSC::ARM64Assembler::linkJumpOrCall): (JSC::ARM64Assembler::linkCompareAndBranch): (JSC::ARM64Assembler::linkConditionalBranch): (JSC::ARM64Assembler::linkTestAndBranch): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): * runtime/JSCPtrTag.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247799 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-24 Mark Lam <mark.lam@apple.com> performJITMemcpy should be PACed with a non-zero diversifier when passed and called via a pointer. https://bugs.webkit.org/show_bug.cgi?id=200100 <rdar://problem/53474939> Reviewed by Yusuke Suzuki. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::CopyFunction::CopyFunction): (JSC::ARM64Assembler::CopyFunction::operator()): - I choose to use ptrauth_auth_function() here instead of retagCodePtr() because retagCodePtr() would auth, assert, and re-pac the pointer. This is needed in general because retagCodePtr() doesn't know that you will consume the pointer immediately (and therefore crash imminently if a failed auth is encountered). Since we know here that we will call with the auth'ed pointer immediately, we can skip the assert. This also has the benefit of letting Clang do a peephole optimization to emit a blrab instruction with the intended diversifier, instead of emitting multiple instructions to auth the pointer into a C function, and then using a blraaz to do a C function call. (JSC::ARM64Assembler::linkJumpOrCall): (JSC::ARM64Assembler::linkCompareAndBranch): (JSC::ARM64Assembler::linkConditionalBranch): (JSC::ARM64Assembler::linkTestAndBranch): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): * runtime/JSCPtrTag.h: 2019-09-27 Alan Coon <alancoon@apple.com> Cherry-pick r250440. rdar://problem/55800893 OSR exit shouldn't bother updating get_by_id array profiles that have changed modes https://bugs.webkit.org/show_bug.cgi?id=202324 <rdar://problem/52669110> Reviewed by Yusuke Suzuki. This is an optimization that avoids polluting the array profile. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): (JSC::DFG::OSRExit::compileExit): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250440 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-27 Keith Miller <keith_miller@apple.com> OSR exit shouldn't bother updating get_by_id array profiles that have changed modes https://bugs.webkit.org/show_bug.cgi?id=202324 <rdar://problem/52669110> Reviewed by Yusuke Suzuki. This is an optimization that avoids polluting the array profile. * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): (JSC::DFG::OSRExit::compileExit): 2019-09-23 Alan Coon <alancoon@apple.com> Cherry-pick r250116. rdar://problem/55608003 [JSC] DFG op_call_varargs should not assume that one-previous-local of freeReg is usable https://bugs.webkit.org/show_bug.cgi?id=202014 Reviewed by Saam Barati. JSTests: * stress/call-varargs-inlining-should-not-clobber-previous-to-free-register.js: Added. (__v0): Source/JavaScriptCore: Let's look into the bytecode generated by the test. [ 0] enter [ 1] get_scope loc4 [ 3] mov loc5, loc4 [ 6] check_traps [ 7] mov loc6, callee [ 10] create_direct_arguments loc7 [ 12] to_this this [ 15] mov loc8, loc7 [ 18] mov loc9, loc6 [ 21] mov loc12, Undefined(const0) [ 24] get_by_id loc11, loc6, 0 [ 29] jneq_ptr loc11, ApplyFunction, 18(->47) [ 34] mov loc11, loc6 [ 37] call_varargs loc11, loc11, this, loc8, loc13, 0 [ 45] jmp 17(->62) [ 47] mov loc16, loc6 [ 50] mov loc15, this [ 53] mov loc14, loc8 [ 56] call loc11, loc11, 3, 22 ... call_varargs uses loc13 as firstFreeReg (first usable bottom register in the current stack-frame to spread variadic arguments after this). This is correct. And call_varargs uses |this| as this argument for the call_varargs. This |this| argument is not in a region starting from loc13. And it is not in the previous place to loc13 (|this| is not loc12). On the other hand, DFG::ByteCodeParser's inlining path is always assuming that the previous to firstFreeReg is usable and part of arguments. But this is wrong. loc12 in the above bytecode is used for `[ 56] call loc11, loc11, 3, 22`'s argument later, and this call assumes that loc12 is not clobbered by call_varargs. But DFG and FTL clobbers it. The test is recursively calling the same function, and we inline the same function one-level. And stack-overflow error happens when inlined CallForwardVarargs (from op_call_varargs) is called. FTL recovers the frames, and at this point, outer function's loc12 is recovered to garbage since LoadVarargs clobbers it. And we eventually use it and crash. 60:<!0:-> LoadVarargs(Check:Untyped:Kill:@30, MustGen, start = loc13, count = loc15, machineStart = loc7, machineCount = loc9, offset = 0, mandatoryMinimum = 0, limit = 2, R:World, W:Stack(-16),Stack(-14),Stack(-13),Heap, Exits, ClobbersExit, bc#37, ExitValid) This LoadVarargs clobbers loc12, loc13, and loc15 while loc12 is used. In all the tiers, op_call_varargs first allocates enough region to hold varargs including |this|. And we store |this| value to a correct place. DFG should not assume that the previous register to firstFreeReg is used for |this|. This patch fixes DFG::ByteCodeParser's stack region calculation for op_call_varargs inlining. And we rename maxNumArguments to maxArgumentCountIncludingThis to represent that `maxArgumentCountIncludingThis` includes |this| count. * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::setMaxArgumentCountIncludingThis): (JSC::CallLinkInfo::setMaxNumArguments): Deleted. * bytecode/CallLinkInfo.h: (JSC::CallLinkInfo::addressOfMaxArgumentCountIncludingThis): (JSC::CallLinkInfo::maxArgumentCountIncludingThis): (JSC::CallLinkInfo::addressOfMaxNumArguments): Deleted. (JSC::CallLinkInfo::maxNumArguments): Deleted. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): (JSC::CallLinkStatus::dump const): * bytecode/CallLinkStatus.h: (JSC::CallLinkStatus::maxArgumentCountIncludingThis const): (JSC::CallLinkStatus::maxNumArguments const): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleVarargsInlining): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct): * jit/JITCall.cpp: (JSC::JIT::compileSetupFrame): * jit/JITCall32_64.cpp: (JSC::JIT::compileSetupFrame): * jit/JITOperations.cpp: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@250116 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-19 Yusuke Suzuki <ysuzuki@apple.com> [JSC] DFG op_call_varargs should not assume that one-previous-local of freeReg is usable https://bugs.webkit.org/show_bug.cgi?id=202014 Reviewed by Saam Barati. Let's look into the bytecode generated by the test. [ 0] enter [ 1] get_scope loc4 [ 3] mov loc5, loc4 [ 6] check_traps [ 7] mov loc6, callee [ 10] create_direct_arguments loc7 [ 12] to_this this [ 15] mov loc8, loc7 [ 18] mov loc9, loc6 [ 21] mov loc12, Undefined(const0) [ 24] get_by_id loc11, loc6, 0 [ 29] jneq_ptr loc11, ApplyFunction, 18(->47) [ 34] mov loc11, loc6 [ 37] call_varargs loc11, loc11, this, loc8, loc13, 0 [ 45] jmp 17(->62) [ 47] mov loc16, loc6 [ 50] mov loc15, this [ 53] mov loc14, loc8 [ 56] call loc11, loc11, 3, 22 ... call_varargs uses loc13 as firstFreeReg (first usable bottom register in the current stack-frame to spread variadic arguments after this). This is correct. And call_varargs uses |this| as this argument for the call_varargs. This |this| argument is not in a region starting from loc13. And it is not in the previous place to loc13 (|this| is not loc12). On the other hand, DFG::ByteCodeParser's inlining path is always assuming that the previous to firstFreeReg is usable and part of arguments. But this is wrong. loc12 in the above bytecode is used for `[ 56] call loc11, loc11, 3, 22`'s argument later, and this call assumes that loc12 is not clobbered by call_varargs. But DFG and FTL clobbers it. The test is recursively calling the same function, and we inline the same function one-level. And stack-overflow error happens when inlined CallForwardVarargs (from op_call_varargs) is called. FTL recovers the frames, and at this point, outer function's loc12 is recovered to garbage since LoadVarargs clobbers it. And we eventually use it and crash. 60:<!0:-> LoadVarargs(Check:Untyped:Kill:@30, MustGen, start = loc13, count = loc15, machineStart = loc7, machineCount = loc9, offset = 0, mandatoryMinimum = 0, limit = 2, R:World, W:Stack(-16),Stack(-14),Stack(-13),Heap, Exits, ClobbersExit, bc#37, ExitValid) This LoadVarargs clobbers loc12, loc13, and loc15 while loc12 is used. In all the tiers, op_call_varargs first allocates enough region to hold varargs including |this|. And we store |this| value to a correct place. DFG should not assume that the previous register to firstFreeReg is used for |this|. This patch fixes DFG::ByteCodeParser's stack region calculation for op_call_varargs inlining. And we rename maxNumArguments to maxArgumentCountIncludingThis to represent that `maxArgumentCountIncludingThis` includes |this| count. * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::setMaxArgumentCountIncludingThis): (JSC::CallLinkInfo::setMaxNumArguments): Deleted. * bytecode/CallLinkInfo.h: (JSC::CallLinkInfo::addressOfMaxArgumentCountIncludingThis): (JSC::CallLinkInfo::maxArgumentCountIncludingThis): (JSC::CallLinkInfo::addressOfMaxNumArguments): Deleted. (JSC::CallLinkInfo::maxNumArguments): Deleted. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): (JSC::CallLinkStatus::dump const): * bytecode/CallLinkStatus.h: (JSC::CallLinkStatus::maxArgumentCountIncludingThis const): (JSC::CallLinkStatus::maxNumArguments const): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleVarargsInlining): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct): * jit/JITCall.cpp: (JSC::JIT::compileSetupFrame): * jit/JITCall32_64.cpp: (JSC::JIT::compileSetupFrame): * jit/JITOperations.cpp: 2019-09-17 Alan Coon <alancoon@apple.com> Cherry-pick r249911. rdar://problem/55461405 JSObject::putInlineSlow should not ignore "__proto__" for Proxy https://bugs.webkit.org/show_bug.cgi?id=200386 <rdar://problem/53854946> Reviewed by Yusuke Suzuki. JSTests: * stress/proxy-__proto__-in-prototype-chain.js: Added. * stress/proxy-property-replace-structure-transition.js: Added. Source/JavaScriptCore: We used to ignore '__proto__' in putInlineSlow when the object in question was Proxy. There is no reason for this, and it goes against the spec. So I've removed that condition. This also has the effect that it fixes an assertion firing inside our inline caching code which dictates that for a property replace that the base value's structure must be equal to the structure when we grabbed the structure prior to the put operation. The old code caused a weird edge case where we broke this invariant. * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249911 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-09-16 Saam Barati <sbarati@apple.com> JSObject::putInlineSlow should not ignore "__proto__" for Proxy https://bugs.webkit.org/show_bug.cgi?id=200386 <rdar://problem/53854946> Reviewed by Yusuke Suzuki. We used to ignore '__proto__' in putInlineSlow when the object in question was Proxy. There is no reason for this, and it goes against the spec. So I've removed that condition. This also has the effect that it fixes an assertion firing inside our inline caching code which dictates that for a property replace that the base value's structure must be equal to the structure when we grabbed the structure prior to the put operation. The old code caused a weird edge case where we broke this invariant. * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): 2019-09-04 Mark Lam <mark.lam@apple.com> Cherry-pick 249345. rdar://problem/55000994 2019-08-30 Mark Lam <mark.lam@apple.com> Fix a bug in SlotVisitor::reportZappedCellAndCrash() and also capture more information. https://bugs.webkit.org/show_bug.cgi?id=201345 Reviewed by Yusuke Suzuki. This patch fixes a bug where SlotVisitor::reportZappedCellAndCrash() was using the wrong pointer for capture the cell headerWord and zapReason. As a result, we get junk for those 2 values. Previously, we were only capturing the upper 32-bits of the cell header slot, and the lower 32-bit of the next slot in the zapped cell. We now capture the full 64-bits of both slots. If the second slot did not contain a zapReason as we expect, the upper 32-bits might give us a clue as to what type of value the slot contains. This patch also adds capturing of the found MarkedBlock address for the zapped cell, as well as some state bit values. * heap/SlotVisitor.cpp: (JSC::SlotVisitor::reportZappedCellAndCrash): 2019-09-04 Mark Lam <mark.lam@apple.com> Cherry-pick 248143, 248162. rdar://problem/55000992 Also deleted an unused function. This is needed to resolve a merge conflict for this patch. * heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::zap): Deleted. * heap/MarkedBlock.h: (JSC::MarkedBlock::Handle::zap): Deleted. 2019-08-02 Mark Lam <mark.lam@apple.com> Gardening: build fix. https://bugs.webkit.org/show_bug.cgi?id=200149 <rdar://problem/53570112> Not reviewed. * assembler/CPU.cpp: (JSC::hwPhysicalCPUMax): 2019-08-01 Mark Lam <mark.lam@apple.com> Add crash diagnostics for debugging unexpected zapped cells. https://bugs.webkit.org/show_bug.cgi?id=200149 <rdar://problem/53570112> Reviewed by Yusuke Suzuki. Add a check for zapped cells in SlotVisitor::appendToMarkStack() and SlotVisitor::visitChildren(). If a zapped cell is detected, we will crash with some diagnostic info. To facilitate this, we've made the following changes: 1. Changed FreeCell to preserve the 1st 8 bytes. This is fine to do because all cells are at least 16 bytes long. 2. Changed HeapCell::zap() to only zap the structureID. Leave the rest of the cell header info intact (including the cell JSType). 3. Changed HeapCell::zap() to record the reason for zapping the cell. We stash the reason immediately after the first 8 bytes. This is the same location as FreeCell::scrambledNext. However, since a cell is not expected to be zapped and on the free list at the same time, it is also fine to do this. 4. Added a few utility functions to MarkedBlock for checking if a cell points into the block. 5. Added VMInspector and JSDollarVM utilities to dump in-use subspace hashes. 6. Added some comments to document the hashes of known subspaces. 7. Added Options::dumpZappedCellCrashData() to make this check conditional. We use this option to disable this check for slower machines so that their PLT5 performance is not impacted. * assembler/CPU.cpp: (JSC::hwL3CacheSize): (JSC::hwPhysicalCPUMax): * assembler/CPU.h: (JSC::hwL3CacheSize): (JSC::hwPhysicalCPUMax): * heap/FreeList.h: (JSC::FreeCell::offsetOfScrambledNext): * heap/HeapCell.h: (JSC::HeapCell::zap): (JSC::HeapCell::isZapped const): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::stopAllocating): * heap/MarkedBlock.h: (JSC::MarkedBlock::Handle::start const): (JSC::MarkedBlock::Handle::end const): (JSC::MarkedBlock::Handle::contains const): * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::specializedSweep): * heap/MarkedSpace.h: (JSC::MarkedSpace::forEachSubspace): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::appendToMarkStack): (JSC::SlotVisitor::visitChildren): (JSC::SlotVisitor::reportZappedCellAndCrash): * heap/SlotVisitor.h: * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator): * runtime/Options.cpp: (JSC::Options::initialize): * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::VM): * tools/JSDollarVM.cpp: (JSC::functionDumpSubspaceHashes): (JSC::JSDollarVM::finishCreation): * tools/VMInspector.cpp: (JSC::VMInspector::dumpSubspaceHashes): * tools/VMInspector.h: 2019-09-03 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r248824. rdar://problem/55001142 [JSC] WebAssembly BBQ should switch compile mode for size of modules https://bugs.webkit.org/show_bug.cgi?id=200807 Reviewed by Mark Lam. Some webpages use very large Wasm module, and it exhausts all executable memory in ARM64 devices since the size of executable memory region is 128MB. The long term solution should be introducing Wasm interpreter. But as a short term solution, we introduce heuristics switching back to BBQ B3 at the sacrifice of start-up time, since BBQ Air bloats such lengthy code, and thereby consumes a large amount of executable memory. Currently, I picked 10MB since the reported website is using 11MB wasm module. * runtime/Options.h: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::parseAndCompileAir): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunctions): * wasm/WasmModuleInformation.h: * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseCode): * wasm/WasmStreamingParser.cpp: (JSC::Wasm::StreamingParser::parseCodeSectionSize): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248824 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-17 Yusuke Suzuki <ysuzuki@apple.com> [JSC] WebAssembly BBQ should switch compile mode for size of modules https://bugs.webkit.org/show_bug.cgi?id=200807 Reviewed by Mark Lam. Some webpages use very large Wasm module, and it exhausts all executable memory in ARM64 devices since the size of executable memory region is 128MB. The long term solution should be introducing Wasm interpreter. But as a short term solution, we introduce heuristics switching back to BBQ B3 at the sacrifice of start-up time, since BBQ Air bloats such lengthy code, and thereby consumes a large amount of executable memory. Currently, I picked 10MB since the reported website is using 11MB wasm module. * runtime/Options.h: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::parseAndCompileAir): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunctions): * wasm/WasmModuleInformation.h: * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseCode): * wasm/WasmStreamingParser.cpp: (JSC::Wasm::StreamingParser::parseCodeSectionSize): 2019-09-03 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r248793. rdar://problem/55001191 [JSC] Promise.prototype.finally should accept non-promise objects https://bugs.webkit.org/show_bug.cgi?id=200829 Reviewed by Mark Lam. JSTests: * stress/promise-finally-should-accept-non-promise-objects.js: Added. (shouldBe): (Thenable): (Thenable.prototype.then): Source/JavaScriptCore: According to the Promise.prototype.finally spec step 2[1], we should check @isObject instead of @isPromise, since Promise.prototype.finally should accept thenable objects that are defined by user libraries (like, bluebird for example). This patch changes this check to the specified one. [1]: https://tc39.es/proposal-promise-finally/ * builtins/PromisePrototype.js: (finally): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248793 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-16 Yusuke Suzuki <ysuzuki@apple.com> [JSC] Promise.prototype.finally should accept non-promise objects https://bugs.webkit.org/show_bug.cgi?id=200829 Reviewed by Mark Lam. According to the Promise.prototype.finally spec step 2[1], we should check @isObject instead of @isPromise, since Promise.prototype.finally should accept thenable objects that are defined by user libraries (like, bluebird for example). This patch changes this check to the specified one. [1]: https://tc39.es/proposal-promise-finally/ * builtins/PromisePrototype.js: (finally): 2019-08-18 Babak Shafiei <bshafiei@apple.com> Cherry-pick r248800. rdar://problem/54454996 CodeBlock destructor should clear all of its watchpoints. https://bugs.webkit.org/show_bug.cgi?id=200792 <rdar://problem/53947800> Reviewed by Yusuke Suzuki. JSTests: * stress/codeblock-should-clear-watchpoints-on-destruction.js: Added. Source/JavaScriptCore: We need to clear the watchpoints explicitly (just like we do in CodeBlock::jettison()) because the JITCode may outlive the CodeBlock for a while. For example, the JITCode is ref'd in Interpreter::execute(JSC::CallFrameClosure&) like so: JSValue result = closure.functionExecutable->generatedJITCodeForCall()->execute(&vm, closure.protoCallFrame); The call to generatedJITCodeForCall() returns a Ref<JITCode> with the underlying JITCode ref'd. Hence, while the interpreter frame is still on the stack, the executing JITCode instance will have a non-zero refCount, and be kept alive even though its CodeBlock may have already been destructed. Note: the Interpreter execute() methods aren't the only ones who would ref the JITCode: ExecutableBase also holds a RefPtr<JITCode> m_jitCodeForCall and RefPtr<JITCode> m_jitCodeForConstruct. But a CodeBlock will be uninstalled before it gets destructed. Hence, the uninstallation will deref the JITCode before we get to the CodeBlock destructor. That said, we should be aware that a JITCode's refCount is not always 1 after the JIT installs it into the CodeBlock, and it should not be assumed to be so. For this patch, I also audited all Watchpoint subclasses to ensure that we are clearing all the relevant watchpoints in the CodeBlock destructor. Here is the list of audited Watchpoints: CodeBlockJettisoningWatchpoint AdaptiveStructureWatchpoint AdaptiveInferredPropertyValueWatchpoint - these are held in the DFG::CommonData, and is tied to JITCode's life cycle. - they need to be cleared eagerly in CodeBlock's destructor. LLIntPrototypeLoadAdaptiveStructureWatchpoint - stored in m_llintGetByIdWatchpointMap in the CodeBlock. - this will be automatically cleared on CodeBlock destruction. The following does not reference CodeBlock: FunctionRareData::AllocationProfileClearingWatchpoint - stored in FunctionRareData and will be cleared automatically on FunctionRareData destruction. - only references the owner FunctionRareData. ObjectToStringAdaptiveStructureWatchpoint ObjectToStringAdaptiveInferredPropertyValueWatchpoint - stored in StructureRareData and will be cleared automatically on StructureRareData destruction. ObjectPropertyChangeAdaptiveWatchpoint - stored in JSGlobalObject, and will be cleared automatically on JSGlobalObject destruction. - only references the owner JSGlobalObject. StructureStubClearingWatchpoint - stored in WatchpointsOnStructureStubInfo and will be cleared automatically on WatchpointsOnStructureStubInfo destruction. PropertyWatchpoint StructureWatchpoint - embedded in AdaptiveInferredPropertyValueWatchpointBase, which is extended as AdaptiveInferredPropertyValueWatchpoint, ObjectPropertyChangeAdaptiveWatchpoint, and ObjectToStringAdaptiveInferredPropertyValueWatchpoint. - life cycle is handled by those 3 subclasses. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::~CodeBlock): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248800 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-16 Mark Lam <mark.lam@apple.com> CodeBlock destructor should clear all of its watchpoints. https://bugs.webkit.org/show_bug.cgi?id=200792 <rdar://problem/53947800> Reviewed by Yusuke Suzuki. We need to clear the watchpoints explicitly (just like we do in CodeBlock::jettison()) because the JITCode may outlive the CodeBlock for a while. For example, the JITCode is ref'd in Interpreter::execute(JSC::CallFrameClosure&) like so: JSValue result = closure.functionExecutable->generatedJITCodeForCall()->execute(&vm, closure.protoCallFrame); The call to generatedJITCodeForCall() returns a Ref<JITCode> with the underlying JITCode ref'd. Hence, while the interpreter frame is still on the stack, the executing JITCode instance will have a non-zero refCount, and be kept alive even though its CodeBlock may have already been destructed. Note: the Interpreter execute() methods aren't the only ones who would ref the JITCode: ExecutableBase also holds a RefPtr<JITCode> m_jitCodeForCall and RefPtr<JITCode> m_jitCodeForConstruct. But a CodeBlock will be uninstalled before it gets destructed. Hence, the uninstallation will deref the JITCode before we get to the CodeBlock destructor. That said, we should be aware that a JITCode's refCount is not always 1 after the JIT installs it into the CodeBlock, and it should not be assumed to be so. For this patch, I also audited all Watchpoint subclasses to ensure that we are clearing all the relevant watchpoints in the CodeBlock destructor. Here is the list of audited Watchpoints: CodeBlockJettisoningWatchpoint AdaptiveStructureWatchpoint AdaptiveInferredPropertyValueWatchpoint - these are held in the DFG::CommonData, and is tied to JITCode's life cycle. - they need to be cleared eagerly in CodeBlock's destructor. LLIntPrototypeLoadAdaptiveStructureWatchpoint - stored in m_llintGetByIdWatchpointMap in the CodeBlock. - this will be automatically cleared on CodeBlock destruction. The following does not reference CodeBlock: FunctionRareData::AllocationProfileClearingWatchpoint - stored in FunctionRareData and will be cleared automatically on FunctionRareData destruction. - only references the owner FunctionRareData. ObjectToStringAdaptiveStructureWatchpoint ObjectToStringAdaptiveInferredPropertyValueWatchpoint - stored in StructureRareData and will be cleared automatically on StructureRareData destruction. ObjectPropertyChangeAdaptiveWatchpoint - stored in JSGlobalObject, and will be cleared automatically on JSGlobalObject destruction. - only references the owner JSGlobalObject. StructureStubClearingWatchpoint - stored in WatchpointsOnStructureStubInfo and will be cleared automatically on WatchpointsOnStructureStubInfo destruction. PropertyWatchpoint StructureWatchpoint - embedded in AdaptiveInferredPropertyValueWatchpointBase, which is extended as AdaptiveInferredPropertyValueWatchpoint, ObjectPropertyChangeAdaptiveWatchpoint, and ObjectToStringAdaptiveInferredPropertyValueWatchpoint. - life cycle is handled by those 3 subclasses. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::~CodeBlock): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248271. rdar://problem/54237771 JSC: assertion failure in SpeculativeJIT::compileGetByValOnIntTypedArray https://bugs.webkit.org/show_bug.cgi?id=199997 Reviewed by Saam Barati. JSTests: New test. * stress/typedarray-no-alreadyChecked-assert.js: Added. (checkIntArray): (checkFloatArray): Source/JavaScriptCore: No need to ASSERT(node->arrayMode().alreadyChecked(...)) in SpeculativeJIT::compileGetByValOnIntTypedArray() and compileGetByValOnFloatTypedArray() as the abstract interpreter is conservative and can insert a CheckStructureOrEmpty which will fail the ASSERT as it checks for the SpecType of the array and not for SpecEmpty. If we added a check for the SpecEmpty in the ASSERT, there are cases where it won't be set. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248271 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-05 Michael Saboff <msaboff@apple.com> JSC: assertion failure in SpeculativeJIT::compileGetByValOnIntTypedArray https://bugs.webkit.org/show_bug.cgi?id=199997 Reviewed by Saam Barati. No need to ASSERT(node->arrayMode().alreadyChecked(...)) in SpeculativeJIT::compileGetByValOnIntTypedArray() and compileGetByValOnFloatTypedArray() as the abstract interpreter is conservative and can insert a CheckStructureOrEmpty which will fail the ASSERT as it checks for the SpecType of the array and not for SpecEmpty. If we added a check for the SpecEmpty in the ASSERT, there are cases where it won't be set. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): 2019-08-13 Alan Coon <alancoon@apple.com> Cherry-pick r248149. rdar://problem/54237692 GetterSetter type confusion during DFG compilation https://bugs.webkit.org/show_bug.cgi?id=199903 Reviewed by Mark Lam. JSTests: * stress/cse-propagated-constant-may-not-follow-structure-restrictions.js: Added. Source/JavaScriptCore: In AI, we are strongly assuming that GetGetter's child constant value should be GetterSetter if it exists. However, this can be wrong since nobody ensures that. AI assumed so because the control-flow and preceding CheckStructure ensures that. But this preceding check can be eliminated if the node becomes (at runtime) unreachable. Let's consider the following graph. 129:<!0:-> PutByOffset(KnownCell:@115, KnownCell:@115, Check:Untyped:@124, MustGen, id5{length}, 0, W:NamedProperties(5), ClobbersExit, bc#154, ExitValid) 130:<!0:-> PutStructure(KnownCell:@115, MustGen, %C8:Object -> %C3:Object, ID:7726, R:JSObject_butterfly, W:JSCell_indexingType,JSCell_structureID,JSCell_typeInfoFlags,JSCell_typeInfoType, ClobbersExit, bc#154, ExitInvalid) ... 158:<!0:-> GetLocal(Check:Untyped:@197, JS|MustGen|UseAsOther, Final, loc7(R<Final>/FlushedCell), R:Stack(-8), bc#187, ExitValid) predicting Final 210:< 1:-> DoubleRep(Check:NotCell:@158, Double|PureInt, BytecodeDouble, Exits, bc#187, ExitValid) ... 162:<!0:-> CheckStructure(Cell:@158, MustGen, [%Ad:Object], R:JSCell_structureID, Exits, bc#192, ExitValid) 163:< 1:-> GetGetterSetterByOffset(KnownCell:@158, KnownCell:@158, JS|UseAsOther, OtherCell, id5{length}, 0, R:NamedProperties(5), Exits, bc#192, ExitValid) 164:< 1:-> GetGetter(KnownCell:@163, JS|UseAsOther, Function, R:GetterSetter_getter, Exits, bc#192, ExitValid) At @163 and @164, AI proves that @158's AbstractValue is None because @210's edge filters out Cells @158 is a cell. But we do not invalidate graph status as "Invalid" even if edge filters out all possible value. This is because the result of edge can be None in a valid program. For example, we can put a dependency edge between a consuming node and a producing node, where the producing node is just like a check and it does not produce a value actually. So, @163 and @164 are not invalidated. This is totally fine in our compiler pipeline right now. But after that, global CSE phase found that @115 and @158 are same and @129 dominates @158. As a result, we can replace GetGetter child's @163 with @124. Since CheckStructure is already removed (and now, at runtime, @163 and @164 are never executed), we do not have any structure guarantee on @158 and the result of @163. This means that @163's CSE result can be non-GetterSetter value. 124:< 2:-> JSConstant(JS|UseAsOther, Final, Weak:Object: 0x1199e82a0 with butterfly 0x0 (Structure %B4:Object), StructureID: 49116, bc#0, ExitValid) ... 126:< 2:-> GetGetter(KnownCell:Kill:@124, JS|UseAsOther, Function, R:GetterSetter_getter, Exits, bc#192, ExitValid) AI filters out @124's non-cell values. But @126 can get non-GetterSetter cell at AI phase. But our AI code is like the following. JSValue base = forNode(node->child1()).m_value; if (base) { GetterSetter* getterSetter = jsCast<GetterSetter*>(base); ... Then, jsCast casts the above object with GetterSetter accidentally. In general, DFG AI can get a proven constant value, which could not be shown at runtime. This happens if the processing node is unreachable at runtime while the graph is not invalid yet, because preceding edge filters already filter out all the possible execution. DFG AI already considered about this possibility, and it attempts to fold a node into a constant only when the constant input matches against the expected one. But several DFG nodes are not handling this correctly: GetGetter, GetSetter, and SkipScope. In this patch, we use `jsDynamicCast` to ensure that the constant input matches against the expected (foldable) one, and fold it only when the expectation is met. We also remove DFG::Node::castConstant and its use. We should not rely on the constant folded value based on graph's control-flow. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGNode.h: (JSC::DFG::Node::castConstant): Deleted. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248149 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-01 Yusuke Suzuki <ysuzuki@apple.com> GetterSetter type confusion during DFG compilation https://bugs.webkit.org/show_bug.cgi?id=199903 Reviewed by Mark Lam. In AI, we are strongly assuming that GetGetter's child constant value should be GetterSetter if it exists. However, this can be wrong since nobody ensures that. AI assumed so because the control-flow and preceding CheckStructure ensures that. But this preceding check can be eliminated if the node becomes (at runtime) unreachable. Let's consider the following graph. 129:<!0:-> PutByOffset(KnownCell:@115, KnownCell:@115, Check:Untyped:@124, MustGen, id5{length}, 0, W:NamedProperties(5), ClobbersExit, bc#154, ExitValid) 130:<!0:-> PutStructure(KnownCell:@115, MustGen, %C8:Object -> %C3:Object, ID:7726, R:JSObject_butterfly, W:JSCell_indexingType,JSCell_structureID,JSCell_typeInfoFlags,JSCell_typeInfoType, ClobbersExit, bc#154, ExitInvalid) ... 158:<!0:-> GetLocal(Check:Untyped:@197, JS|MustGen|UseAsOther, Final, loc7(R<Final>/FlushedCell), R:Stack(-8), bc#187, ExitValid) predicting Final 210:< 1:-> DoubleRep(Check:NotCell:@158, Double|PureInt, BytecodeDouble, Exits, bc#187, ExitValid) ... 162:<!0:-> CheckStructure(Cell:@158, MustGen, [%Ad:Object], R:JSCell_structureID, Exits, bc#192, ExitValid) 163:< 1:-> GetGetterSetterByOffset(KnownCell:@158, KnownCell:@158, JS|UseAsOther, OtherCell, id5{length}, 0, R:NamedProperties(5), Exits, bc#192, ExitValid) 164:< 1:-> GetGetter(KnownCell:@163, JS|UseAsOther, Function, R:GetterSetter_getter, Exits, bc#192, ExitValid) At @163 and @164, AI proves that @158's AbstractValue is None because @210's edge filters out Cells @158 is a cell. But we do not invalidate graph status as "Invalid" even if edge filters out all possible value. This is because the result of edge can be None in a valid program. For example, we can put a dependency edge between a consuming node and a producing node, where the producing node is just like a check and it does not produce a value actually. So, @163 and @164 are not invalidated. This is totally fine in our compiler pipeline right now. But after that, global CSE phase found that @115 and @158 are same and @129 dominates @158. As a result, we can replace GetGetter child's @163 with @124. Since CheckStructure is already removed (and now, at runtime, @163 and @164 are never executed), we do not have any structure guarantee on @158 and the result of @163. This means that @163's CSE result can be non-GetterSetter value. 124:< 2:-> JSConstant(JS|UseAsOther, Final, Weak:Object: 0x1199e82a0 with butterfly 0x0 (Structure %B4:Object), StructureID: 49116, bc#0, ExitValid) ... 126:< 2:-> GetGetter(KnownCell:Kill:@124, JS|UseAsOther, Function, R:GetterSetter_getter, Exits, bc#192, ExitValid) AI filters out @124's non-cell values. But @126 can get non-GetterSetter cell at AI phase. But our AI code is like the following. JSValue base = forNode(node->child1()).m_value; if (base) { GetterSetter* getterSetter = jsCast<GetterSetter*>(base); ... Then, jsCast casts the above object with GetterSetter accidentally. In general, DFG AI can get a proven constant value, which could not be shown at runtime. This happens if the processing node is unreachable at runtime while the graph is not invalid yet, because preceding edge filters already filter out all the possible execution. DFG AI already considered about this possibility, and it attempts to fold a node into a constant only when the constant input matches against the expected one. But several DFG nodes are not handling this correctly: GetGetter, GetSetter, and SkipScope. In this patch, we use `jsDynamicCast` to ensure that the constant input matches against the expected (foldable) one, and fold it only when the expectation is met. We also remove DFG::Node::castConstant and its use. We should not rely on the constant folded value based on graph's control-flow. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGNode.h: (JSC::DFG::Node::castConstant): Deleted. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation): 2019-08-12 Alan Coon <alancoon@apple.com> Apply patch. rdar://problem/54171876 2019-08-12 Maciej Stachowiak <mjs@apple.com> Branch build fix for r248494 * runtime/ClassInfo.h: METHOD_TABLE_ENTRY was called WTF_METHOD_TABLE_ENTRY on the branch. 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248494. rdar://problem/54171876 Universal XSS in JSObject::putInlineSlow and JSValue::putToPrimitive https://bugs.webkit.org/show_bug.cgi?id=199864 Reviewed by Saam Barati. Source/JavaScriptCore: Our JSObject::put implementation is not correct in term of the spec. Our [[Put]] implementation is something like this. JSObject::put(object): if (can-do-fast-path(object)) return fast-path(object); // slow-path do { object-put-check-and-setter-calls(object); // (1) object = object->prototype; } while (is-object(object)); return do-put(object); Since JSObject::put is registered in the methodTable, the derived classes can override it. Some of classes are adding extra checks to this put. Derived::put(object): if (do-extra-check(object)) fail return JSObject::put(object) The problem is that Derived::put is only called when the |this| object is the Derived class. When traversing [[Prototype]] in JSObject::put, at (1), we do not perform the extra checks added in Derived::put even if `object` is Derived one. This means that we skip the check. Currently, JSObject::put and WebCore checking mechanism are broken. JSObject::put should call getOwnPropertySlot at (1) to perform the additional checks. This behavior is matching against the spec. However, currently, our JSObject::getOwnPropertySlot does not propagate setter information. This is required to cache cacheable [[Put]] at (1) for CustomValue, CustomAccessor, and Accessors. We also need to reconsider how to integrate static property setters to this mechanism. So, basically, this involves large refactoring to renew our JSObject::put and JSObject::getOwnPropertySlot. To work-around for now, we add a new TypeInfo flag, HasPutPropertySecurityCheck . And adding this flag to DOM objects that implements the addition checks. We also add doPutPropertySecurityCheck method hook to perform the check in JSObject. When we found this flag at (1), we perform doPutPropertySecurityCheck to properly perform the checks. Since our JSObject::put code is old and it does not match against the spec now, we should refactor it largely. This is tracked separately in [1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=200562 * runtime/ClassInfo.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSCell.cpp: (JSC::JSCell::doPutPropertySecurityCheck): * runtime/JSCell.h: * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): (JSC::JSObject::getOwnPropertyDescriptor): * runtime/JSObject.h: (JSC::JSObject::doPutPropertySecurityCheck): * runtime/JSTypeInfo.h: (JSC::TypeInfo::hasPutPropertySecurityCheck const): Source/WebCore: Test: http/tests/security/cross-frame-access-object-put-optimization.html * bindings/js/JSDOMWindowCustom.cpp: (WebCore::JSDOMWindow::doPutPropertySecurityCheck): * bindings/js/JSLocationCustom.cpp: (WebCore::JSLocation::doPutPropertySecurityCheck): * bindings/scripts/CodeGeneratorJS.pm: (GenerateHeader): * bindings/scripts/test/JS/JSTestActiveDOMObject.h: LayoutTests: * http/tests/security/cross-frame-access-object-put-optimization-expected.txt: Added. * http/tests/security/cross-frame-access-object-put-optimization.html: Added. * http/tests/security/resources/cross-frame-iframe-for-object-put-optimization-test.html: Added. git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248494 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-09 Yusuke Suzuki <ysuzuki@apple.com> Universal XSS in JSObject::putInlineSlow and JSValue::putToPrimitive https://bugs.webkit.org/show_bug.cgi?id=199864 Reviewed by Saam Barati. Our JSObject::put implementation is not correct in term of the spec. Our [[Put]] implementation is something like this. JSObject::put(object): if (can-do-fast-path(object)) return fast-path(object); // slow-path do { object-put-check-and-setter-calls(object); // (1) object = object->prototype; } while (is-object(object)); return do-put(object); Since JSObject::put is registered in the methodTable, the derived classes can override it. Some of classes are adding extra checks to this put. Derived::put(object): if (do-extra-check(object)) fail return JSObject::put(object) The problem is that Derived::put is only called when the |this| object is the Derived class. When traversing [[Prototype]] in JSObject::put, at (1), we do not perform the extra checks added in Derived::put even if `object` is Derived one. This means that we skip the check. Currently, JSObject::put and WebCore checking mechanism are broken. JSObject::put should call getOwnPropertySlot at (1) to perform the additional checks. This behavior is matching against the spec. However, currently, our JSObject::getOwnPropertySlot does not propagate setter information. This is required to cache cacheable [[Put]] at (1) for CustomValue, CustomAccessor, and Accessors. We also need to reconsider how to integrate static property setters to this mechanism. So, basically, this involves large refactoring to renew our JSObject::put and JSObject::getOwnPropertySlot. To work-around for now, we add a new TypeInfo flag, HasPutPropertySecurityCheck . And adding this flag to DOM objects that implements the addition checks. We also add doPutPropertySecurityCheck method hook to perform the check in JSObject. When we found this flag at (1), we perform doPutPropertySecurityCheck to properly perform the checks. Since our JSObject::put code is old and it does not match against the spec now, we should refactor it largely. This is tracked separately in [1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=200562 * runtime/ClassInfo.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSCell.cpp: (JSC::JSCell::doPutPropertySecurityCheck): * runtime/JSCell.h: * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): (JSC::JSObject::getOwnPropertyDescriptor): * runtime/JSObject.h: (JSC::JSObject::doPutPropertySecurityCheck): * runtime/JSTypeInfo.h: (JSC::TypeInfo::hasPutPropertySecurityCheck const): 2019-08-12 Alan Coon <alancoon@apple.com> Cherry-pick r248027. rdar://problem/53836556 [JSC] Emit write barrier after storing instead of before storing https://bugs.webkit.org/show_bug.cgi?id=200193 Reviewed by Saam Barati. I reviewed tricky GC-related code including visitChildren and manual writeBarrier, and I found that we have several problems with write-barriers. 1. Some write-barriers are emitted before stores happen Some code like LazyProperty emits write-barrier before we store the value. This is wrong since JSC has concurrent collector. Let's consider the situation like this. 1. Cell "A" is not marked yet 2. Write-barrier is emitted onto "A" 3. Concurrent collector scans "A" 4. Store to "A"'s field happens 5. (4)'s field is not rescaned We should emit write-barrier after stores. This patch places write-barriers after stores happen. 2. Should emit write-barrier after the stored fields are reachable from the owner. We have code that is logically the same to the following. ``` auto data = std::make_unique<XXX>(); data->m_field.set(vm, owner, value); storeStoreBarrier(); owner->m_data = WTFMove(data); ``` This is not correct. When write-barrier is emitted, the owner cannot reach to the field that is stored. The actual example is AccessCase. We are emitting write-barriers with owner when creating AccessCase, but this is not effective until this AccessCase is chained to StructureStubInfo, which is reachable from CodeBlock. I don't think this is actually an issue because currently AccessCase generation is guarded by CodeBlock->m_lock. And CodeBlock::visitChildren takes this lock. But emitting a write-barrier at the right place is still better. This patch places write-barriers when StructureStubInfo::addAccessCase is called. Speculative GC fix, it was hard to reproduce the crash since we need to control concurrent collector and main thread's scheduling in an instruction-level. * bytecode/BytecodeList.rb: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::considerCaching): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::setupGetByIdPrototypeCache): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/LazyPropertyInlines.h: (JSC::ElementType>::setMayBeNull): * runtime/RegExpCachedResult.h: (JSC::RegExpCachedResult::record): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248027 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-30 Yusuke Suzuki <ysuzuki@apple.com> [JSC] Emit write barrier after storing instead of before storing https://bugs.webkit.org/show_bug.cgi?id=200193 Reviewed by Saam Barati. I reviewed tricky GC-related code including visitChildren and manual writeBarrier, and I found that we have several problems with write-barriers. 1. Some write-barriers are emitted before stores happen Some code like LazyProperty emits write-barrier before we store the value. This is wrong since JSC has concurrent collector. Let's consider the situation like this. 1. Cell "A" is not marked yet 2. Write-barrier is emitted onto "A" 3. Concurrent collector scans "A" 4. Store to "A"'s field happens 5. (4)'s field is not rescaned We should emit write-barrier after stores. This patch places write-barriers after stores happen. 2. Should emit write-barrier after the stored fields are reachable from the owner. We have code that is logically the same to the following. ``` auto data = std::make_unique<XXX>(); data->m_field.set(vm, owner, value); storeStoreBarrier(); owner->m_data = WTFMove(data); ``` This is not correct. When write-barrier is emitted, the owner cannot reach to the field that is stored. The actual example is AccessCase. We are emitting write-barriers with owner when creating AccessCase, but this is not effective until this AccessCase is chained to StructureStubInfo, which is reachable from CodeBlock. I don't think this is actually an issue because currently AccessCase generation is guarded by CodeBlock->m_lock. And CodeBlock::visitChildren takes this lock. But emitting a write-barrier at the right place is still better. This patch places write-barriers when StructureStubInfo::addAccessCase is called. Speculative GC fix, it was hard to reproduce the crash since we need to control concurrent collector and main thread's scheduling in an instruction-level. * bytecode/BytecodeList.rb: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::considerCaching): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::setupGetByIdPrototypeCache): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/LazyPropertyInlines.h: (JSC::ElementType>::setMayBeNull): * runtime/RegExpCachedResult.h: (JSC::RegExpCachedResult::record): 2019-08-09 Alan Coon <alancoon@apple.com> Cherry-pick r248462. rdar://problem/54144119 [Win] Fix internal build https://bugs.webkit.org/show_bug.cgi?id=200519 Reviewed by Alex Christensen. Source/JavaScriptCore: The script 'generate-js-builtins.py' cannot be found when building WebCore. Copy the JavaScriptCore Scripts folder after building JSC. * JavaScriptCore.vcxproj/JavaScriptCore.proj: Source/WebKitLegacy/win: Switch to the String::wideCharacers method, since its return type is compatible with the Win32 api. * WebDownloadCFNet.cpp: (WebDownload::didFinish): git-svn-id: https://svn.webkit.org/repository/webkit/trunk@248462 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-08-08 Per Arne Vollan <pvollan@apple.com> [Win] Fix internal build https://bugs.webkit.org/show_bug.cgi?id=200519 Reviewed by Alex Christensen. The script 'generate-js-builtins.py' cannot be found when building WebCore. Copy the JavaScriptCore Scripts folder after building JSC. * JavaScriptCore.vcxproj/JavaScriptCore.proj: 2019-08-06 Alan Coon <alancoon@apple.com> Apply patch. rdar://problem/53992160 2019-08-06 Per Arne Vollan <pvollan@apple.com> [Win] Fix AppleWin build https://bugs.webkit.org/show_bug.cgi?id=200414 Reviewed by Brent Fulgham. * CMakeLists.txt: * PlatformWin.cmake: * shell/CMakeLists.txt: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247714. rdar://problem/53647616 [bmalloc] Each IsoPage gets 1MB VA because VMHeap::tryAllocateLargeChunk rounds up https://bugs.webkit.org/show_bug.cgi?id=200024 Reviewed by Saam Barati. Source/bmalloc: When we allocate IsoHeap's page, we reused VMHeap::tryAllocateLargeChunk. However, this function is originally designed to be used for Large allocation in bmalloc (e.g. allocating Chunk in bmalloc). As a result, this function rounds up the requested size with 1MB (bmalloc::chunkSize). As a result, all IsoHeap's 16KB page gets 1MB VA while it just uses 16KB of the allocated region. This leads to VA exhaustion since IsoHeap now uses 64x VA than we expected! This patch fixes the above VA exhaustion issue by allocating a page by using tryVMAllocate. When allocating a page, we start using a VM tag for IsoHeap. We discussed at e-mail and we decided reusing a VM tag previously assigned to CLoop Stack since this is less profitable. Since this tag is not Malloc-related tag, Leaks tool can scan memory region conservatively without registering allocated region into Zone, which was previously done in VMHeap and that's why we reused VMHeap for IsoHeap. * bmalloc/BVMTags.h: * bmalloc/IsoPage.cpp: (bmalloc::IsoPageBase::allocatePageMemory): * bmalloc/IsoTLS.cpp: (bmalloc::IsoTLS::ensureEntries): * bmalloc/VMAllocate.h: (bmalloc::vmAllocate): Source/JavaScriptCore: Discussed and we decided to use this VM tag for IsoHeap instead of CLoop stack. * interpreter/CLoopStack.cpp: (JSC::CLoopStack::CLoopStack): Source/WebCore: Changed how we interpret VM tags. Add IsoHeap VM tag support, and rename WebAssembly tag to Gigacage tag. * page/ResourceUsageData.h: * page/ResourceUsageOverlay.h: * page/cocoa/ResourceUsageOverlayCocoa.mm: (WebCore::HistoricResourceUsageData::HistoricResourceUsageData): * page/cocoa/ResourceUsageThreadCocoa.mm: (WebCore::displayNameForVMTag): (WebCore::categoryForVMTag): Source/WTF: Start using a VM tag for IsoHeap instead of CLoop Stack. * wtf/OSAllocator.h: * wtf/VMTags.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247714 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-22 Yusuke Suzuki <ysuzuki@apple.com> [bmalloc] Each IsoPage gets 1MB VA because VMHeap::tryAllocateLargeChunk rounds up https://bugs.webkit.org/show_bug.cgi?id=200024 Reviewed by Saam Barati. Discussed and we decided to use this VM tag for IsoHeap instead of CLoop stack. * interpreter/CLoopStack.cpp: (JSC::CLoopStack::CLoopStack): 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247713. rdar://problem/53648241 Turn off Wasm fast memory on iOS https://bugs.webkit.org/show_bug.cgi?id=200016 <rdar://problem/53417726> Reviewed by Yusuke Suzuki. We turned them on when we disabled Gigacage on iOS. However, we re-enabled Gigacage on iOS, but forgot to turn wasm fast memories back off. * runtime/Options.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247713 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-22 Saam Barati <sbarati@apple.com> Turn off Wasm fast memory on iOS https://bugs.webkit.org/show_bug.cgi?id=200016 <rdar://problem/53417726> Reviewed by Yusuke Suzuki. We turned them on when we disabled Gigacage on iOS. However, we re-enabled Gigacage on iOS, but forgot to turn wasm fast memories back off. * runtime/Options.h: 2019-07-29 Alan Coon <alancoon@apple.com> Cherry-pick r247703. rdar://problem/53647465 [JSC] Make DFG Local CSE and AI conservative for huge basic block https://bugs.webkit.org/show_bug.cgi?id=199929 <rdar://problem/49309924> Reviewed by Filip Pizlo. In CNN page, the main thread hangs several seconds. On less-powerful devices (like iPhone7), it hangs for ~11 seconds. This is not an acceptable behavior. The reason of this is that the DFG compiler takes too long time in the compilation for a particular function. It takes 8765 ms even in powerful x64 machine! DFG compiler is concurrent one. However, when GC requires all the peripheral threads to be stopped, the main thread needs to wait for the DFG compiler's stop. DFG compiler stops at GC safepoints, and they are inserted between DFG phases. So, if some of DFG phases take very long time, the main thread is blocked during that. As a result, the main thread is blocked due to this pathological compilation. By measuring the time taken in each DFG phase, we found that our AI and CSE phase have a problem having quadratic complexity for # of DFG nodes in a basic block. In this patch, we add a threshold for # of DFG nodes in a basic block. If a basic block exceeds this threshold, we use conservative but O(1) algorithm for AI and Local CSE phase. We did not add this threshold for Global CSE since FTL has another bytecode cost threshold which prevents us from compiling the large functions. But on the other hand, DFG should compile them because DFG is intended to be a fast compiler even for a bit larger CodeBlock. We first attempted to reduce the threshold for DFG compilation. We are using 100000 bytecode cost for DFG compilation and it is very large. However, we found that bytecode cost is not the problem in CNN page. The problematic function has 67904 cost, and it takes 8765 ms in x64 machine. However, JetStream2/octane-zlib has 61949 function and it only takes ~400 ms. This difference comes from the # of DFG nodes in a basic block. The problematic function has 43297 DFG nodes in one basic block and it makes AI and Local CSE super time-consuming. Rather than relying on the bytecode cost which a bit indirectly related to this pathological compile-time, we should look into # of DFG nodes in a basic block which is more directly related to this problem. And we also found that 61949's Octane-zlib function is very critical for performance. This fact makes a bit hard to pick a right threshold: 67904 causes the problem, and 61949 must be compiled. This is why this patch is introducing conservative analysis instead of adjusting the threshold for DFG. This patch has two changes. 1. DFG AI has structure transition tracking which has quadratic complexity Structure transition tracking takes very long time since its complexity is O(N^2) where N is # of DFG nodes in a basic block. CNN has very pathological script and it shows 43297 DFG nodes. We should reduce the complexity of this algorithm. For now, we just say "structures are clobbered" if # of DFG nodes in a basic block exceeds the threshold (20000). We could improve the current algorithm from O(N^2) to O(2N) without being conservative, and I'm tracking this in [1]. 2. DFG Local CSE has quadratic complexity Local CSE's clobbering iterates all the impure heap values to remove the clobbered one. Since # of impure heap values tend to be proportional to # of DFG nodes we visited, each CSE for a basic block gets O(N^2) complexity. To avoid this, we introduce HugeMap. This has the same interface to LargeMap and SmallMap in CSE, but its clobbering implementation just clears the map completely. We can further make this O(N) without introducing conservative behavior by using epochs. For now, we do not see such a huge basic block in JetStream2 and Speedometer2 so I'll track it in a separate bug[2]. This patch reduces the compilation time from ~11 seconds to ~200 ms. [1]: https://bugs.webkit.org/show_bug.cgi?id=199959 [2]: https://bugs.webkit.org/show_bug.cgi?id=200014 * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransition): (JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransitions): * dfg/DFGCSEPhase.cpp: * runtime/Options.h: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247703 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-20 Yusuke Suzuki <ysuzuki@apple.com> [JSC] Make DFG Local CSE and AI conservative for huge basic block https://bugs.webkit.org/show_bug.cgi?id=199929 <rdar://problem/49309924> Reviewed by Filip Pizlo. In CNN page, the main thread hangs several seconds. On less-powerful devices (like iPhone7), it hangs for ~11 seconds. This is not an acceptable behavior. The reason of this is that the DFG compiler takes too long time in the compilation for a particular function. It takes 8765 ms even in powerful x64 machine! DFG compiler is concurrent one. However, when GC requires all the peripheral threads to be stopped, the main thread needs to wait for the DFG compiler's stop. DFG compiler stops at GC safepoints, and they are inserted between DFG phases. So, if some of DFG phases take very long time, the main thread is blocked during that. As a result, the main thread is blocked due to this pathological compilation. By measuring the time taken in each DFG phase, we found that our AI and CSE phase have a problem having quadratic complexity for # of DFG nodes in a basic block. In this patch, we add a threshold for # of DFG nodes in a basic block. If a basic block exceeds this threshold, we use conservative but O(1) algorithm for AI and Local CSE phase. We did not add this threshold for Global CSE since FTL has another bytecode cost threshold which prevents us from compiling the large functions. But on the other hand, DFG should compile them because DFG is intended to be a fast compiler even for a bit larger CodeBlock. We first attempted to reduce the threshold for DFG compilation. We are using 100000 bytecode cost for DFG compilation and it is very large. However, we found that bytecode cost is not the problem in CNN page. The problematic function has 67904 cost, and it takes 8765 ms in x64 machine. However, JetStream2/octane-zlib has 61949 function and it only takes ~400 ms. This difference comes from the # of DFG nodes in a basic block. The problematic function has 43297 DFG nodes in one basic block and it makes AI and Local CSE super time-consuming. Rather than relying on the bytecode cost which a bit indirectly related to this pathological compile-time, we should look into # of DFG nodes in a basic block which is more directly related to this problem. And we also found that 61949's Octane-zlib function is very critical for performance. This fact makes a bit hard to pick a right threshold: 67904 causes the problem, and 61949 must be compiled. This is why this patch is introducing conservative analysis instead of adjusting the threshold for DFG. This patch has two changes. 1. DFG AI has structure transition tracking which has quadratic complexity Structure transition tracking takes very long time since its complexity is O(N^2) where N is # of DFG nodes in a basic block. CNN has very pathological script and it shows 43297 DFG nodes. We should reduce the complexity of this algorithm. For now, we just say "structures are clobbered" if # of DFG nodes in a basic block exceeds the threshold (20000). We could improve the current algorithm from O(N^2) to O(2N) without being conservative, and I'm tracking this in [1]. 2. DFG Local CSE has quadratic complexity Local CSE's clobbering iterates all the impure heap values to remove the clobbered one. Since # of impure heap values tend to be proportional to # of DFG nodes we visited, each CSE for a basic block gets O(N^2) complexity. To avoid this, we introduce HugeMap. This has the same interface to LargeMap and SmallMap in CSE, but its clobbering implementation just clears the map completely. We can further make this O(N) without introducing conservative behavior by using epochs. For now, we do not see such a huge basic block in JetStream2 and Speedometer2 so I'll track it in a separate bug[2]. This patch reduces the compilation time from ~11 seconds to ~200 ms. [1]: https://bugs.webkit.org/show_bug.cgi?id=199959 [2]: https://bugs.webkit.org/show_bug.cgi?id=200014 * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransition): (JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransitions): * dfg/DFGCSEPhase.cpp: * runtime/Options.h: 2019-07-24 Alan Coon <alancoon@apple.com> Apply patch. rdar://problem/53483188 Disable ENABLE_LAYOUT_FORMATTING_CONTEXT https://bugs.webkit.org/show_bug.cgi?id=200038 <rdar://problem/53457282> Reviewed by Zalan Bujtas. This feature is not complete. It is enabled for the trunk, but needs to be disabled in branches for shipping products. Source/JavaScriptCore: * Configurations/FeatureDefines.xcconfig: Source/WebCore: No new tests -- this change does not add any new functionality. * Configurations/FeatureDefines.xcconfig: Source/WebCore/PAL: * Configurations/FeatureDefines.xcconfig: Source/WebKit: * Configurations/FeatureDefines.xcconfig: Source/WebKitLegacy/mac: * Configurations/FeatureDefines.xcconfig: Tools: * TestWebKitAPI/Configurations/FeatureDefines.xcconfig: 2019-07-23 Keith Rollin <krollin@apple.com> Disable ENABLE_LAYOUT_FORMATTING_CONTEXT https://bugs.webkit.org/show_bug.cgi?id=200038 <rdar://problem/53457282> Reviewed by Zalan Bujtas. This feature is not complete. It is enabled for the trunk, but needs to be disabled in branches for shipping products. * Configurations/FeatureDefines.xcconfig: 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247532. rdar://problem/53228435 ArgumentsEliminationPhase should insert KillStack nodes before PutStack nodes that it adds. https://bugs.webkit.org/show_bug.cgi?id=199821 <rdar://problem/52452328> Reviewed by Filip Pizlo. JSTests: * stress/arguments-elimination-should-insert-KillStacks-before-added-PutStacks.js: Added. Source/JavaScriptCore: Excluding the ArgumentsEliminationPhase, PutStack nodes are converted from SetLocal nodes in the SSAConversionPhase. SetLocal nodes are always preceded by MovHint nodes, and the SSAConversionPhase always inserts a KillStack node before a MovHint node. Hence, a PutStack node is always preceded by a KillStack node. However, the ArgumentsEliminationPhase can convert LoadVarargs nodes into a series of one or more PutStacks nodes, and it prepends MovHint nodes before the PutStack nodes. However, it neglects to prepend KillStack nodes as well. Since the ArgumentsEliminationPhase runs after the SSAConversionPhase, the PutStack nodes added during ArgumentsElimination will not be preceded by KillStack nodes. This patch fixes this by inserting a KillStack in the ArgumentsEliminationPhase before it inserts a MovHint and a PutStack node. Consider this test case which can manifest the above issue as a crash: function inlinee(value) { ... let tmp = value + 1; } function reflect() { return inlinee.apply(undefined, arguments); } function test(arr) { let object = inlinee.apply(undefined, arr); // Uses a lot of SetArgumentMaybe nodes. reflect(); // Calls with a LoadVararg, which gets converted into a PutStack of a constant. } In this test case, we have a scenario where a SetArgumentMaybe's stack slot is reused as the stack slot for a PutStack later. Here, the PutStack will put a constant undefined value. Coincidentally, the SetArgumentMaybe may also initialize that stack slot to a constant undefined value. Note that by the time the PutStack executes, the SetArgumentMaybe's stack slot is dead. The liveness of these 2 values are distinct. However, because we were missing a KillStack before the PutStack, OSR availability analysis gets misled into thinking that the PutStack constant value is still in the stack slot because the value left there by the SetArgumentMaybe hasn't been killed off yet. As a result, OSR exit code will attempt to recover the PutStack's undefined constant by loading from the stack slot instead of materializing it. Since SetArgumentMaybe may not actually initialize the stack slot, we get a crash in OSR exit when we try to recover the PutStack constant value from the stack slot, and end up using what ever junk value we read from there. Fixing the ArgumentsEliminationPhase to insert KillStack before the PutStack removes this conflation of the PutStack's constant value with the SetArgumentMaybe's constant value in the same stack slot. And, OSR availability analysis will no longer be misled to load the PutStack's constant value from the stack, but will materialize the constant instead. * dfg/DFGArgumentsEliminationPhase.cpp: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247532 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-17 Mark Lam <mark.lam@apple.com> ArgumentsEliminationPhase should insert KillStack nodes before PutStack nodes that it adds. https://bugs.webkit.org/show_bug.cgi?id=199821 <rdar://problem/52452328> Reviewed by Filip Pizlo. Excluding the ArgumentsEliminationPhase, PutStack nodes are converted from SetLocal nodes in the SSAConversionPhase. SetLocal nodes are always preceded by MovHint nodes, and the SSAConversionPhase always inserts a KillStack node before a MovHint node. Hence, a PutStack node is always preceded by a KillStack node. However, the ArgumentsEliminationPhase can convert LoadVarargs nodes into a series of one or more PutStacks nodes, and it prepends MovHint nodes before the PutStack nodes. However, it neglects to prepend KillStack nodes as well. Since the ArgumentsEliminationPhase runs after the SSAConversionPhase, the PutStack nodes added during ArgumentsElimination will not be preceded by KillStack nodes. This patch fixes this by inserting a KillStack in the ArgumentsEliminationPhase before it inserts a MovHint and a PutStack node. Consider this test case which can manifest the above issue as a crash: function inlinee(value) { ... let tmp = value + 1; } function reflect() { return inlinee.apply(undefined, arguments); } function test(arr) { let object = inlinee.apply(undefined, arr); // Uses a lot of SetArgumentMaybe nodes. reflect(); // Calls with a LoadVararg, which gets converted into a PutStack of a constant. } In this test case, we have a scenario where a SetArgumentMaybe's stack slot is reused as the stack slot for a PutStack later. Here, the PutStack will put a constant undefined value. Coincidentally, the SetArgumentMaybe may also initialize that stack slot to a constant undefined value. Note that by the time the PutStack executes, the SetArgumentMaybe's stack slot is dead. The liveness of these 2 values are distinct. However, because we were missing a KillStack before the PutStack, OSR availability analysis gets misled into thinking that the PutStack constant value is still in the stack slot because the value left there by the SetArgumentMaybe hasn't been killed off yet. As a result, OSR exit code will attempt to recover the PutStack's undefined constant by loading from the stack slot instead of materializing it. Since SetArgumentMaybe may not actually initialize the stack slot, we get a crash in OSR exit when we try to recover the PutStack constant value from the stack slot, and end up using what ever junk value we read from there. Fixing the ArgumentsEliminationPhase to insert KillStack before the PutStack removes this conflation of the PutStack's constant value with the SetArgumentMaybe's constant value in the same stack slot. And, OSR availability analysis will no longer be misled to load the PutStack's constant value from the stack, but will materialize the constant instead. * dfg/DFGArgumentsEliminationPhase.cpp: 2019-07-17 Kocsen Chung <kocsen_chung@apple.com> Cherry-pick r247474. rdar://problem/53229615 JSGlobalObject type macros should support feature flags and WeakRef should have one https://bugs.webkit.org/show_bug.cgi?id=199601 Reviewed by Mark Lam. Source/JavaScriptCore: This patch refactors the various builtin type macros to have a parameter, which is the feature flag enabling it. Since most builtin types are enabled by default this patch adds a new global bool typeExposedByDefault for clarity. Note, because static hash tables have no concept of feature flags we can't use feature flags with lazy properties. This is probably not a big deal as features that are off by default won't be allocated anywhere we care about memory usage anyway. * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::stringObjectStructure const): (JSC::JSGlobalObject::bigIntObjectStructure const): Deleted. * runtime/Options.h: * wasm/js/JSWebAssembly.cpp: Tools: JSC options need to be set before the window is created for the test. * DumpRenderTree/mac/DumpRenderTree.mm: (resetWebViewToConsistentStateBeforeTesting): * DumpRenderTree/win/DumpRenderTree.cpp: (setJSCOptions): (resetWebViewToConsistentStateBeforeTesting): LayoutTests: Add JSC option requirements for WeakRef tests. * js/script-tests/weakref-async-is-collected.js: * js/script-tests/weakref-eventually-collects-values.js: * js/script-tests/weakref-microtasks-dont-collect.js: * js/script-tests/weakref-weakset-consistency.js: * js/weakref-async-is-collected.html: * js/weakref-eventually-collects-values.html: * js/weakref-microtasks-dont-collect.html: * js/weakref-weakset-consistency.html: git-svn-id: https://svn.webkit.org/repository/webkit/trunk@247474 268f45cc-cd09-0410-ab3c-d52691b4dbfc 2019-07-15 Keith Miller <keith_miller@apple.com> JSGlobalObject type macros should support feature flags and WeakRef should have one https://bugs.webkit.org/show_bug.cgi?id=199601 Reviewed by Mark Lam. This patch refactors the various builtin type macros to have a parameter, which is the feature flag enabling it. Since most builtin types are enabled by default this patch adds a new global bool typeExposedByDefault for clarity. Note, because static hash tables have no concept of feature flags we can't use feature flags with lazy properties. This is probably not a big deal as features that are off by default won't be allocated anywhere we care about memory usage anyway. * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::stringObjectStructure const): (JSC::JSGlobalObject::bigIntObjectStructure const): Deleted. * runtime/Options.h: * wasm/js/JSWebAssembly.cpp: 2019-07-15 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, attempt to fix production builds after r247403. * JavaScriptCore.xcodeproj/project.pbxproj: 2019-07-15 Tadeu Zagallo <tzagallo@apple.com> Concurrent GC should not rely on current phase to determine if it's safe to steal conn https://bugs.webkit.org/show_bug.cgi?id=199786 <rdar://problem/52505197> Reviewed by Saam Barati. In r246507, we fixed a race condition in the concurrent GC where the mutator might steal the conn from the collector thread while it transitions from the End phase to NotRunning. However, that fix was not sufficient. In the case that the mutator steals the conn, and the execution interleaves long enough for the mutator to progress to a different collection phase, the collector will resume in a phase other than NotRunning, and hence the check added to NotRunning will not suffice. To fix that, we add a new variable to track whether the collector thread is running (m_collectorThreadIsRunning) and use it to determine whether it's safe to steal the conn, rather than relying on m_currentPhase. * heap/Heap.cpp: (JSC::Heap::runNotRunningPhase): (JSC::Heap::requestCollection): * heap/Heap.h: 2019-07-12 Keith Miller <keith_miller@apple.com> Add API to get all the dependencies of a given JSScript https://bugs.webkit.org/show_bug.cgi?id=199746 Reviewed by Saam Barati. The method only returns the dependencies if the module was actually evaluated. Technically, we know what the dependencies are at the satisfy phase but for API simplicity we only provide that information if the module graph was complete enough to at least run. This patch also fixes an issue where we would allow import specifiers that didn't start "./" or "/". For reference, We have this restriction to be consistent with the web/node. The restriction exists in order to preserve namespace for builtin-modules. Lastly, this patch makes it so that we copy all scripts in the API/tests/testapiScripts directory so they don't have to be individually added to the xcode project. * API/JSAPIGlobalObject.mm: (JSC::computeValidImportSpecifier): (JSC::JSAPIGlobalObject::moduleLoaderResolve): (JSC::JSAPIGlobalObject::moduleLoaderImportModule): * API/JSContext.mm: (-[JSContext dependencyIdentifiersForModuleJSScript:]): * API/JSContextPrivate.h: * API/JSScript.h: * API/tests/testapi.mm: (testFetchWithTwoCycle): (testFetchWithThreeCycle): (testModuleBytecodeCache): (+[JSContextFileLoaderDelegate newContext]): (-[JSContextFileLoaderDelegate fetchModuleScript:]): (-[JSContextFileLoaderDelegate findScriptForKey:]): (-[JSContextFileLoaderDelegate context:fetchModuleForIdentifier:withResolveHandler:andRejectHandler:]): (testDependenciesArray): (testDependenciesEvaluationError): (testDependenciesSyntaxError): (testDependenciesBadImportId): (testDependenciesMissingImport): (testObjectiveCAPI): * API/tests/testapiScripts/dependencyListTests/badModuleImportId.js: Added. * API/tests/testapiScripts/dependencyListTests/bar.js: Added. * API/tests/testapiScripts/dependencyListTests/dependenciesEntry.js: Added. * API/tests/testapiScripts/dependencyListTests/foo.js: Added. * API/tests/testapiScripts/dependencyListTests/missingImport.js: Added. * API/tests/testapiScripts/dependencyListTests/referenceError.js: Added. * API/tests/testapiScripts/dependencyListTests/syntaxError.js: Added. * API/tests/testapiScripts/testapi-function-overrides.js: Renamed from Source/JavaScriptCore/API/tests/testapi-function-overrides.js. * API/tests/testapiScripts/testapi.js: Renamed from Source/JavaScriptCore/API/tests/testapi.js. * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/ModuleLoader.js: (dependencyKeysIfEvaluated): * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::dependencyKeysIfEvaluated): * runtime/JSModuleLoader.h: * shell/CMakeLists.txt: 2019-07-12 Justin Michaud <justin_michaud@apple.com> B3 should reduce (integer) Sub(Neg(x), y) to Neg(Add(x, y)) https://bugs.webkit.org/show_bug.cgi?id=196371 Reviewed by Keith Miller. Adding these strength reductions gives 2x a (x86) and 3x (arm64) performance improvement on the microbenchmark. * b3/B3ReduceStrength.cpp: * b3/testb3.cpp: (JSC::B3::testSubSub): (JSC::B3::testSubSub2): (JSC::B3::testSubAdd): (JSC::B3::testSubFirstNeg): (JSC::B3::run): 2019-07-12 Caio Lima <ticaiolima@gmail.com> [BigInt] Add ValueBitLShift into DFG https://bugs.webkit.org/show_bug.cgi?id=192664 Reviewed by Saam Barati. This patch is splitting the `BitLShift` into `ArithBitLShift` and `ValueBitLShift` to handle BigInt speculation more efficiently during DFG and FTL layers. Following the same approach of other `ValueBitOps`, `ValueBitLShift` handles Untyped and BigInt speculations, while `ArithBitLShift` handles number and boolean operands and always results into Int32. * bytecode/BytecodeList.rb: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/Opcode.h: * dfg/DFGAbstractInterpreter.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantBinaryBitwiseOp): (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): We moved `BitLShift` constant fold rules to a new method `handleConstantBinaryBitwiseOp` to be reused by `ArithBitLShift` and `ValueBitLShift`. This also enables support of constant folding on other bitwise operations like `ValueBitAnd`, `ValueBitOr` and `ValueBitXor`, when their binary use kind is UntypedUse. Such cases can happen on those nodes because fixup phase is conservative. * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo): (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicGetter): (JSC::DFG::ByteCodeParser::parseBlock): We parse `op_lshift` as `ArithBitLShift` when its operands are numbers. Otherwise, we fallback to `ValueBitLShift` and rely on fixup phase to convert `ValueBitLShift` into `ArithBitLShift` when possible. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): `ArithBitLShift` has the same clobberize rules as former `BitLShift`. `ValueBitLShift` only clobberize world when it is UntypedUse. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): `ValueBitLShift` can GC when `BigIntUse` because it allocates new JSBigInts to perform this operation. It also can GC on UntypedUse because of observable user code. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): `ValueBitLShift` and `ArithBitLShift` has the same fixup rules of other binary bitwise operations. In the case of `ValueBitLShift` We check if we should speculate on BigInt or Untyped and fallback to `ArithBitLShift` when both cheks fail. * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: We updated `operationValueBitLShift` to handle BigInt cases. Also, we added `operationBitLShiftBigInt` that is used when we compile `ValueBitLValueBitLShift(BigIntUse)`. * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: `ValueBitLShift`'s prediction propagation rules differs from other bitwise operations, because using only heap prediction for this node causes significant performance regression on Octane's zlib and mandreel. The reason is because of cases where a function is compiled but the instruction `op_lshift` was never executed before. If we use `getPrediction()` we will emit a `ForceOSRExit`, resulting in more OSR than desired. To solve such issue, we are then using `getPredictionWithoutOSR()` and falling back to `getHeapPrediction()` only on cases where we can't rely on node's input types. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueLShiftOp): (JSC::DFG::SpeculativeJIT::compileShiftOp): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::shiftOp): * 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::compileArithBitLShift): (JSC::FTL::DFG::LowerDFGToB3::compileValueBitLShift): (JSC::FTL::DFG::LowerDFGToB3::compileBitLShift): Deleted. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): 2019-07-12 Keith Miller <keith_miller@apple.com> getIndexQuickly should be const https://bugs.webkit.org/show_bug.cgi?id=199747 Reviewed by Yusuke Suzuki. * runtime/Butterfly.h: (JSC::Butterfly::indexingPayload const): (JSC::Butterfly::arrayStorage const): (JSC::Butterfly::contiguousInt32 const): (JSC::Butterfly::contiguousDouble const): (JSC::Butterfly::contiguous const): * runtime/JSObject.h: (JSC::JSObject::canGetIndexQuickly const): (JSC::JSObject::getIndexQuickly const): (JSC::JSObject::tryGetIndexQuickly const): (JSC::JSObject::canGetIndexQuickly): Deleted. (JSC::JSObject::getIndexQuickly): Deleted. 2019-07-11 Justin Michaud <justin_michaud@apple.com> Add b3 macro lowering for CheckMul on arm64 https://bugs.webkit.org/show_bug.cgi?id=199251 Reviewed by Robin Morisset. - Lower CheckMul for 32-bit arguments on arm64 into a mul and then an overflow check. - Add a new opcode to air on arm64 for smull (multiplySignExtend32). - Fuse sign extend 32 + mul into smull (taking two 32-bit arguments and producing 64 bits). - 1.25x speedup on power of two microbenchmark, 1.15x speedup on normal constant microbenchmark, and no change on the no-constant benchmark. Also, skip some of the b3 tests that were failing before this patch so that the new tests can run to completion. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::multiplySignExtend32): * assembler/testmasm.cpp: (JSC::testMul32SignExtend): (JSC::run): * b3/B3LowerMacros.cpp: * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.cpp: (JSC::B3::testMulArgs32SignExtend): (JSC::B3::testMulImm32SignExtend): (JSC::B3::testMemoryFence): (JSC::B3::testStoreFence): (JSC::B3::testLoadFence): (JSC::B3::testPinRegisters): (JSC::B3::run): 2019-07-11 Yusuke Suzuki <ysuzuki@apple.com> Unreviewed, revert r243617. https://bugs.webkit.org/show_bug.cgi?id=196341 Mark pointed out that JSVirtualMachine can be gone in the other thread while we are executing GC constraint-solving. This patch does not account that JavaScriptCore.framework is multi-thread safe: JSVirtualMachine wrapper can be destroyed, and [JSVirtualMachine dealloc] can be executed in any threads while the VM is retained and used in the other thread (e.g. destroyed from AutoReleasePool in some thread). * API/JSContext.mm: (-[JSContext initWithVirtualMachine:]): (-[JSContext dealloc]): (-[JSContext initWithGlobalContextRef:]): (-[JSContext wrapperMap]): (+[JSContext contextWithJSGlobalContextRef:]): * API/JSVirtualMachine.mm: (initWrapperCache): (wrapperCache): (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]): (+[JSVMWrapperCache wrapperForJSContextGroupRef:]): (-[JSVirtualMachine initWithContextGroupRef:]): (-[JSVirtualMachine dealloc]): (+[JSVirtualMachine virtualMachineWithContextGroupRef:]): (-[JSVirtualMachine contextForGlobalContextRef:]): (-[JSVirtualMachine addContext:forGlobalContextRef:]): (scanExternalObjectGraph): (scanExternalRememberedSet): * API/JSVirtualMachineInternal.h: * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::setWrapperMap): (JSC::JSGlobalObject::setAPIWrapper): Deleted. (JSC::JSGlobalObject::apiWrapper const): Deleted. * runtime/VM.h: 2019-07-10 Tadeu Zagallo <tzagallo@apple.com> Optimize join of large empty arrays https://bugs.webkit.org/show_bug.cgi?id=199636 Reviewed by Mark Lam. Replicate the behavior of `str.repeat(count)` when performing `new Array(count + 1).join(str)`. I added two new microbenchmarks: - large-empty-array-join, which does not use the result of the join and runs ~44x faster and uses ~18x less memory. - large-empty-array-join-resolve-rope, which uses the result of the join and runs 2x faster. baseline diff large-empty-array-join 2713.9698+-72.7621 ^ 61.2335+-10.4836 ^ definitely 44.3217x faster large-empty-array-join-resolve-string 26.5517+-0.3995 ^ 12.9309+-0.5516 ^ definitely 2.0533x faster large-empty-array-join memory usage with baseline (dirty): 733012 kB current_mem 756824 kB lifetime_peak large-empty-array-join memory usage with diff (dirty): 41904 kB current_mem 41972 kB lifetime_peak Additionally, I ran JetStream2, sunspider and v8-spider and all were neutral. * runtime/ArrayPrototype.cpp: (JSC::fastJoin): 2019-07-08 Keith Miller <keith_miller@apple.com> Enable Intl.PluralRules and Intl.NumberFormatToParts by default https://bugs.webkit.org/show_bug.cgi?id=199288 Reviewed by Yusuke Suzuki. These features have been around for a while. We should turn them on by default. * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::finishCreation): * runtime/IntlObject.cpp: (JSC::IntlObject::finishCreation): Deleted. * runtime/IntlObject.h: * runtime/Options.h: 2019-07-08 Antoine Quint <graouts@apple.com> [Pointer Events] Enable only on the most recent version of the supported iOS family https://bugs.webkit.org/show_bug.cgi?id=199562 <rdar://problem/52766511> Reviewed by Dean Jackson. * Configurations/FeatureDefines.xcconfig: 2019-07-06 Michael Saboff <msaboff@apple.com> switch(String) needs to check for exceptions when resolving the string https://bugs.webkit.org/show_bug.cgi?id=199541 Reviewed by Mark Lam. Added exception checks for resolved Strings in switch processing for all tiers. * dfg/DFGOperations.cpp: * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): 2019-07-05 Mark Lam <mark.lam@apple.com> ArgumentsEliminationPhase::eliminateCandidatesThatInterfere() should not decrement nodeIndex pass zero. https://bugs.webkit.org/show_bug.cgi?id=199533 <rdar://problem/52669111> Reviewed by Filip Pizlo. * dfg/DFGArgumentsEliminationPhase.cpp: 2019-07-05 Yusuke Suzuki <ysuzuki@apple.com> Unreviewed, fix build failure on ARM64_32 https://bugs.webkit.org/show_bug.cgi?id=182434 Implicit narrowing from uint64_t to uint32_t happens. We should explicitly narrow it because we already checked the `length` is <= UINT32_MAX. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSpeciesCreate): 2019-07-05 Alexey Shvayka <shvaikalesh@gmail.com> [JSC] Clean up ArraySpeciesCreate https://bugs.webkit.org/show_bug.cgi?id=182434 Reviewed by Yusuke Suzuki. We have duplicate code in arraySpeciesCreate, filter, map, concatSlowPath of ArrayPrototype.js and speciesConstructArray of ArrayPrototype.cpp. This patch fixes cross-realm Array constructor detection in native speciesConstructArray, upgrades `length` type to correctly handle large integers, and exposes it as @arraySpeciesCreate. Also removes now unused @isArrayConstructor private function. Native speciesConstructArray is preferred because it has fast path via speciesWatchpointIsValid. Thoroughly benchmarked: this change progresses ARES-6 by 0-1%. * builtins/ArrayPrototype.js: (filter): (map): (globalPrivate.concatSlowPath): (globalPrivate.arraySpeciesCreate): Deleted. * builtins/BuiltinNames.h: * runtime/ArrayConstructor.cpp: (JSC::arrayConstructorPrivateFuncIsArrayConstructor): Deleted. * runtime/ArrayConstructor.h: * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSpeciesCreate): * runtime/ArrayPrototype.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): 2019-07-05 Tadeu Zagallo <tzagallo@apple.com> Unreviewed, change the value used to scribble Heap::m_worldState https://bugs.webkit.org/show_bug.cgi?id=199498 Follow-up after r247160. The value used to scribble should have the conn bit set. * heap/Heap.cpp: (JSC::Heap::~Heap): 2019-07-05 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r247115. Breaks lldbWebKitTester (and by extension, test-webkitpy) Reverted changeset: "[WHLSL] Standard library is too big to directly include in WebCore" https://bugs.webkit.org/show_bug.cgi?id=198186 https://trac.webkit.org/changeset/247115 2019-07-05 Tadeu Zagallo <tzagallo@apple.com> Scribble Heap::m_worldState on destructor https://bugs.webkit.org/show_bug.cgi?id=199498 Reviewed by Sam Weinig. The worldState is dumped when we crash due to a failed checkConn, and this will make it clear if the heap has already been destroyed. * heap/Heap.cpp: (JSC::Heap::~Heap): 2019-07-03 Sam Weinig <weinig@apple.com> Adopt simple structured bindings in more places https://bugs.webkit.org/show_bug.cgi?id=199247 Reviewed by Alex Christensen. Replaces simple uses of std::tie() with structured bindings. Does not touch uses of std::tie() that are not initial declarations, use std::ignore or in case where the binding is captured by a lambda, as structured bindings don't work for those cases yet. * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::doWork): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): * wasm/js/JSWebAssemblyHelpers.h: (JSC::createSourceBufferFromValue): * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyValidateFunc): 2019-07-03 Keith Miller <keith_miller@apple.com> PACCage should first cage leaving PAC bits intact then authenticate https://bugs.webkit.org/show_bug.cgi?id=199372 Reviewed by Saam Barati. This ordering prevents someone from taking a signed pointer from outside the gigacage and using it in a struct that expects a caged pointer. Previously, the PACCaging just double checked that the PAC bits were valid for the original pointer. +---------------------------+ | | | | | "PAC" | "base" | "offset" +----+ | | | | | +---------------------------+ | Caging | | | | | v | +---------------------------+ | | | | | | Bit Merge | 00000 | base | "offset" | | | | | | | +---------------------------+ | | | | v | Bit Merge +---------------------------+ | | | | | | | "PAC" | base | "offset" +<--------+ | | | | +---------------------------+ | | | Authenticate | v +---------------------------+ | | | | | Auth | base | "offset" | | | | | +---------------------------+ The above ascii art graph shows how the PACCage system works. The key take away is that even if someone passes in a valid, signed pointer outside the cage it will still fail to authenticate as the "base" bits will change before authentication. * assembler/MacroAssemblerARM64E.h: * assembler/testmasm.cpp: (JSC::testCagePreservesPACFailureBit): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cageConditionally): * llint/LowLevelInterpreter64.asm: 2019-07-03 Paulo Matos <pmatos@igalia.com> Refactoring of architectural Register Information https://bugs.webkit.org/show_bug.cgi?id=198604 Reviewed by Keith Miller. The goal of this patch is to centralize the register information per platform but access it in a platform independent way. The patch as been implemented for all known platforms: ARM64, ARMv7, MIPS, X86 and X86_64. Register information has been centralized in an architecture per-file: each file is called assembler/<arch>Registers.h. RegisterInfo.h is used as a forwarding header to choose which register information to load. assembler/<arch>Assembler.h and jit/RegisterSet.cpp use this information in a platform independent way. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::gprName): Use register names from register info file. (JSC::ARM64Assembler::sprName): likewise. (JSC::ARM64Assembler::fprName): likewise. * assembler/ARM64Registers.h: Added. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::gprName): Use register names from register info file. (JSC::ARMv7Assembler::sprName): likewise. (JSC::ARMv7Assembler::fprName): likewise. * assembler/ARMv7Registers.h: Added. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::gprName): Use register names from register info file. (JSC::MIPSAssembler::sprName): likewise. (JSC::MIPSAssembler::fprName): likewise. * assembler/MIPSRegisters.h: Added. * assembler/RegisterInfo.h: Added. * assembler/X86Assembler.h: (JSC::X86Assembler::gprName): Use register names from register info file. (JSC::X86Assembler::sprName): likewise. (JSC::X86Assembler::fprName): likewise. * assembler/X86Registers.h: Added. * assembler/X86_64Registers.h: Added. * jit/GPRInfo.h: Fix typo in comment (s/basline/baseline). * jit/RegisterSet.cpp: (JSC::RegisterSet::reservedHardwareRegisters): Use register properties from register info file. (JSC::RegisterSet::calleeSaveRegisters): likewise. 2019-07-02 Michael Saboff <msaboff@apple.com> Exception from For..of loop destructured assignment eliminates TDZ checks in subsequent code https://bugs.webkit.org/show_bug.cgi?id=199395 Reviewed by Filip Pizlo. For destructuring assignmests, the assignment might throw a reference error if the RHS cannot be coerced. The current bytecode generated for such assignments optimizes out the TDZ check after the coercible check. By saving the current state of the TDZ stack before processing the setting of target destructured values and then restoring afterwards, we won't optimize out later TDZ check(s). A similar change of saving / restoring the TDZ stack where exceptions might happen was done for for..in loops in change set r232219. * bytecompiler/NodesCodegen.cpp: (JSC::ObjectPatternNode::bindValue const): 2019-07-02 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r247041. https://bugs.webkit.org/show_bug.cgi?id=199425 broke some iOS arm64e tests (Requested by keith_miller on #webkit). Reverted changeset: "PACCage should first cage leaving PAC bits intact then authenticate" https://bugs.webkit.org/show_bug.cgi?id=199372 https://trac.webkit.org/changeset/247041 2019-07-02 Keith Miller <keith_miller@apple.com> Frozen Arrays length assignment should throw in strict mode https://bugs.webkit.org/show_bug.cgi?id=199365 Reviewed by Yusuke Suzuki. * runtime/JSArray.cpp: (JSC::JSArray::put): 2019-07-02 Paulo Matos <pmatos@linki.tools> Fix typo in if/else block and remove dead assignment https://bugs.webkit.org/show_bug.cgi?id=199352 Reviewed by Alexey Proskuryakov. * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPattern::dumpPattern): Fix typo in if/else block and remove dead assignment 2019-07-02 Keith Miller <keith_miller@apple.com> PACCage should first cage leaving PAC bits intact then authenticate https://bugs.webkit.org/show_bug.cgi?id=199372 Reviewed by Saam Barati. This ordering prevents someone from taking a signed pointer from outside the gigacage and using it in a struct that expects a caged pointer. Previously, the PACCaging just double checked that the PAC bits were valid for the original pointer. +---------------------------+ | | | | | "PAC" | "base" | "offset" +----+ | | | | | +---------------------------+ | Caging | | | | | v | +---------------------------+ | | | | | | Bit Merge | 00000 | base | "offset" | | | | | | | +---------------------------+ | | | | v | Bit Merge +---------------------------+ | | | | | | | "PAC" | base | "offset" +<--------+ | | | | +---------------------------+ | | | Authenticate | v +---------------------------+ | | | | | Auth | base | "offset" | | | | | +---------------------------+ The above ascii art graph shows how the PACCage system works. The key take away is that even if someone passes in a valid, signed pointer outside the cage it will still fail to authenticate as the "base" bits will change before authentication. * assembler/MacroAssemblerARM64E.h: * assembler/testmasm.cpp: (JSC::testCagePreservesPACFailureBit): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cageConditionally): * llint/LowLevelInterpreter64.asm: 2019-07-01 Justin Michaud <justin_michaud@apple.com> [Wasm-References] Disable references by default https://bugs.webkit.org/show_bug.cgi?id=199390 Reviewed by Saam Barati. * runtime/Options.h: 2019-07-01 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r246946. Caused JSC test crashes on arm64 Reverted changeset: "Add b3 macro lowering for CheckMul on arm64" https://bugs.webkit.org/show_bug.cgi?id=199251 https://trac.webkit.org/changeset/246946 2019-06-28 Justin Michaud <justin_michaud@apple.com> Add b3 macro lowering for CheckMul on arm64 https://bugs.webkit.org/show_bug.cgi?id=199251 Reviewed by Robin Morisset. - Lower CheckMul for 32-bit arguments on arm64 into a mul and then an overflow check. - Add a new opcode to air on arm64 for smull (multiplySignExtend32). - Fuse sign extend 32 + mul into smull (taking two 32-bit arguments and producing 64 bits). - 1.25x speedup on power of two microbenchmark, 1.15x speedup on normal constant microbenchmark, and no change on the no-constant benchmark. Also, skip some of the b3 tests that were failing before this patch so that the new tests can run to completion. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::multiplySignExtend32): * assembler/testmasm.cpp: (JSC::testMul32SignExtend): (JSC::run): * b3/B3LowerMacros.cpp: * b3/B3LowerToAir.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.cpp: (JSC::B3::testMulArgs32SignExtend): (JSC::B3::testMulImm32SignExtend): (JSC::B3::testMemoryFence): (JSC::B3::testStoreFence): (JSC::B3::testLoadFence): (JSC::B3::testPinRegisters): (JSC::B3::run): 2019-06-28 Konstantin Tokarev <annulen@yandex.ru> Remove traces of ENABLE_ICONDATABASE remaining after its removal in 219733 https://bugs.webkit.org/show_bug.cgi?id=199317 Reviewed by Michael Catanzaro. While IconDatabase and all code using it was removed, ENABLE_ICONDATABASE still exists as build option and C++ macro. * Configurations/FeatureDefines.xcconfig: 2019-06-27 Mark Lam <mark.lam@apple.com> FTL keepAlive()'s patchpoint should also declare that it reads HeapRange::top(). https://bugs.webkit.org/show_bug.cgi?id=199291 Reviewed by Yusuke Suzuki and Filip Pizlo. The sole purpose of keepAlive() is to communicate to B3 that an LValue needs to be kept alive past the last opportunity for a GC. The only way we can get a GC is via a function call. Hence, what keepAlive() really needs to communicate is that the LValue needs to be kept alive past the last function call. Function calls read and write HeapRange::top(). Currently, B3 does not shuffle writes. Hence, simply inserting the keepAlive() after the calls that can GC is sufficient. But to be strictly correct, keepAlive() should also declare that it reads HeapRange::top(). This will guarantee that the keepAlive patchpoint won't ever be moved before the function call should B3 gain the ability to shuffle writes in the future. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::keepAlive): 2019-06-27 Beth Dakin <bdakin@apple.com> Upstream use of MACCATALYST https://bugs.webkit.org/show_bug.cgi?id=199245 rdar://problem/51687723 Reviewed by Tim Horton. * Configurations/Base.xcconfig: * Configurations/FeatureDefines.xcconfig: * Configurations/JavaScriptCore.xcconfig: * Configurations/SDKVariant.xcconfig: 2019-06-27 Saam Barati <sbarati@apple.com> Make WEBGPU enabled only on Mojave and later. Rubber-stamped by Myles C. Maxfield. * Configurations/FeatureDefines.xcconfig: 2019-06-27 Don Olmstead <don.olmstead@sony.com> [FTW] Build JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=199254 Reviewed by Brent Fulgham. * PlatformFTW.cmake: Added. 2019-06-27 Konstantin Tokarev <annulen@yandex.ru> Use JSC_GLIB_API_ENABLED instead of USE(GLIB) as a compile-time check for GLib JSC API https://bugs.webkit.org/show_bug.cgi?id=199270 Reviewed by Michael Catanzaro. This change allows building code with enabled USE(GLIB) but without GLib JSC API. * heap/Heap.cpp: (JSC::Heap::releaseDelayedReleasedObjects): * heap/Heap.h: * heap/HeapInlines.h: 2019-06-27 Devin Rousso <drousso@apple.com> Web Inspector: throw an error if console.count/console.countReset is called with an object that throws an error from toString https://bugs.webkit.org/show_bug.cgi?id=199252 Reviewed by Joseph Pecoraro. Parse the arguments passed to `console.count` and `console.countReset` before sending it to the `ConsoleClient` so that an error can be thrown if the first argument doesn't `toString` nicely (e.g. without throwing an error). Generate call stacks for `console.countReset` to match other `console` methods. Also do this for `console.time`, `console.timeLog`, and `console.timeEnd`. Limit the call stack to only have the top frame, so no unnecessary/extra data is sent to the frontend (right now, only the call location is displayed). Rename `title` to `label` for `console.time`, `console.timeLog`, and `console.timeEnd` to better match the spec. * runtime/ConsoleClient.h: * runtime/ConsoleObject.cpp: (JSC::valueOrDefaultLabelString): (JSC::consoleProtoFuncCount): (JSC::consoleProtoFuncCountReset): (JSC::consoleProtoFuncTime): (JSC::consoleProtoFuncTimeLog): (JSC::consoleProtoFuncTimeEnd): * inspector/JSGlobalObjectConsoleClient.h: * inspector/JSGlobalObjectConsoleClient.cpp: (Inspector::JSGlobalObjectConsoleClient::count): (Inspector::JSGlobalObjectConsoleClient::countReset): (Inspector::JSGlobalObjectConsoleClient::time): (Inspector::JSGlobalObjectConsoleClient::timeLog): (Inspector::JSGlobalObjectConsoleClient::timeEnd): * inspector/agents/InspectorConsoleAgent.h: * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::startTiming): (Inspector::InspectorConsoleAgent::logTiming): (Inspector::InspectorConsoleAgent::stopTiming): (Inspector::InspectorConsoleAgent::count): (Inspector::InspectorConsoleAgent::countReset): (Inspector::InspectorConsoleAgent::getCounterLabel): Deleted. * inspector/ConsoleMessage.h: * inspector/ConsoleMessage.cpp: (Inspector::ConsoleMessage::ConsoleMessage): Allow `ConsoleMessage`s to be created with both `ScriptArguments` and a `ScriptCallStack`. 2019-06-27 Fujii Hironori <Hironori.Fujii@sony.com> [CMake] Bump cmake_minimum_required version to 3.10 https://bugs.webkit.org/show_bug.cgi?id=199181 Reviewed by Don Olmstead. * CMakeLists.txt: 2019-06-26 Basuke Suzuki <Basuke.Suzuki@sony.com> [RemoteInspector] Add address argument to listen for RemoteInspectorServer Socket implementation. https://bugs.webkit.org/show_bug.cgi?id=199035 Reviewed by Ross Kirsling. Added new argument `address` to start listening. * inspector/remote/socket/RemoteInspectorServer.cpp: (Inspector::RemoteInspectorServer::start): * inspector/remote/socket/RemoteInspectorServer.h: * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp: (Inspector::Socket::listen): * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp: (Inspector::Socket::listen): 2019-06-26 Keith Miller <keith_miller@apple.com> speciesConstruct needs to throw if the result is a DataView https://bugs.webkit.org/show_bug.cgi?id=199231 Reviewed by Mark Lam. Previously, we only checked that the result was a JSArrayBufferView, which can include DataViews. This is incorrect as the result should be only be a TypedArray. * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::speciesConstruct): 2019-06-26 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Implement console.countReset https://bugs.webkit.org/show_bug.cgi?id=199200 Reviewed by Devin Rousso. * inspector/JSGlobalObjectConsoleClient.cpp: (Inspector::JSGlobalObjectConsoleClient::countReset): * inspector/JSGlobalObjectConsoleClient.h: * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::getCounterLabel): (Inspector::InspectorConsoleAgent::count): (Inspector::InspectorConsoleAgent::countReset): * inspector/agents/InspectorConsoleAgent.h: * runtime/ConsoleClient.h: * runtime/ConsoleObject.cpp: (JSC::ConsoleObject::finishCreation): (JSC::consoleProtoFuncCountReset): 2019-06-26 Keith Miller <keith_miller@apple.com> remove unneeded didBecomePrototype() calls https://bugs.webkit.org/show_bug.cgi?id=199221 Reviewed by Saam Barati. Since we now set didBecomePrototype in Structure::create we don't need to set it expliticly in most of our finishCreation methods. The only exception to this is object prototype, which we set as the prototype of function prototype late (via setPrototypeWithoutTransition). * inspector/JSInjectedScriptHostPrototype.cpp: (Inspector::JSInjectedScriptHostPrototype::finishCreation): * inspector/JSJavaScriptCallFramePrototype.cpp: (Inspector::JSJavaScriptCallFramePrototype::finishCreation): * runtime/ArrayIteratorPrototype.cpp: (JSC::ArrayIteratorPrototype::finishCreation): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): * runtime/AsyncFromSyncIteratorPrototype.cpp: (JSC::AsyncFromSyncIteratorPrototype::finishCreation): * runtime/AsyncFunctionPrototype.cpp: (JSC::AsyncFunctionPrototype::finishCreation): * runtime/AsyncGeneratorFunctionPrototype.cpp: (JSC::AsyncGeneratorFunctionPrototype::finishCreation): * runtime/AsyncGeneratorPrototype.cpp: (JSC::AsyncGeneratorPrototype::finishCreation): * runtime/AsyncIteratorPrototype.cpp: (JSC::AsyncIteratorPrototype::finishCreation): * runtime/GeneratorFunctionPrototype.cpp: (JSC::GeneratorFunctionPrototype::finishCreation): * runtime/GeneratorPrototype.cpp: (JSC::GeneratorPrototype::finishCreation): * runtime/IteratorPrototype.cpp: (JSC::IteratorPrototype::finishCreation): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/MapIteratorPrototype.cpp: (JSC::MapIteratorPrototype::finishCreation): * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/ObjectPrototype.cpp: (JSC::ObjectPrototype::finishCreation): * runtime/RegExpStringIteratorPrototype.cpp: (JSC::RegExpStringIteratorPrototype::finishCreation): * runtime/SetIteratorPrototype.cpp: (JSC::SetIteratorPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): * runtime/StringIteratorPrototype.cpp: (JSC::StringIteratorPrototype::finishCreation): * runtime/WeakMapPrototype.cpp: (JSC::WeakMapPrototype::finishCreation): * runtime/WeakObjectRefPrototype.cpp: (JSC::WeakObjectRefPrototype::finishCreation): * runtime/WeakSetPrototype.cpp: (JSC::WeakSetPrototype::finishCreation): 2019-06-25 Keith Miller <keith_miller@apple.com> Structure::create should call didBecomePrototype() https://bugs.webkit.org/show_bug.cgi?id=196315 Reviewed by Filip Pizlo. Structure::create should also assert that the indexing type makes sense for the prototype being used. * runtime/JSObject.h: * runtime/Structure.cpp: (JSC::Structure::isValidPrototype): (JSC::Structure::changePrototypeTransition): * runtime/Structure.h: (JSC::Structure::create): Deleted. * runtime/StructureInlines.h: (JSC::Structure::create): (JSC::Structure::setPrototypeWithoutTransition): 2019-06-25 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Implement console.timeLog https://bugs.webkit.org/show_bug.cgi?id=199184 Reviewed by Devin Rousso. * inspector/JSGlobalObjectConsoleClient.cpp: (Inspector::JSGlobalObjectConsoleClient::timeLog): * inspector/JSGlobalObjectConsoleClient.h: * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::logTiming): (Inspector::InspectorConsoleAgent::stopTiming): * inspector/agents/InspectorConsoleAgent.h: * runtime/ConsoleClient.h: * runtime/ConsoleObject.cpp: (JSC::ConsoleObject::finishCreation): (JSC::consoleProtoFuncTimeLog): 2019-06-25 Michael Catanzaro <mcatanzaro@igalia.com> REGRESSION(r245586): static assertion failed: Match result and EncodedMatchResult should be the same size https://bugs.webkit.org/show_bug.cgi?id=198518 Reviewed by Keith Miller. r245586 made some bad assumptions about the size of size_t, which we can solve using the CPU(ADDRESS32) guard that I didn't know about. This solution was developed by Mark Lam and Keith Miller. I'm just preparing the patch. * runtime/MatchResult.h: 2019-06-24 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r246714. https://bugs.webkit.org/show_bug.cgi?id=199179 revert to do patch in a different way. (Requested by keith_mi_ on #webkit). Reverted changeset: "All prototypes should call didBecomePrototype()" https://bugs.webkit.org/show_bug.cgi?id=196315 https://trac.webkit.org/changeset/246714 2019-06-24 Alexey Shvayka <shvaikalesh@gmail.com> Add Array.prototype.{flat,flatMap} to unscopables https://bugs.webkit.org/show_bug.cgi?id=194322 Reviewed by Keith Miller. * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): 2019-06-24 Mark Lam <mark.lam@apple.com> ArraySlice needs to keep the source array alive. https://bugs.webkit.org/show_bug.cgi?id=197374 <rdar://problem/50304429> Reviewed by Michael Saboff and Filip Pizlo. The implementation of the FTL ArraySlice intrinsics may GC while allocating the result array and its butterfly. Previously, ArraySlice already keeps the source butterfly alive in order to copy from it to the new butterfly after the allocation. Unfortunately, this is not enough. We also need to keep the source array alive so that GC will scan the values in the butterfly as well. Note: the butterfly does not have a visitChildren() method to do this scan. It's the parent object's responsibility to do the scanning. This patch fixes this by introducing a keepAlive() utility method, and we use it to keep the source array alive while allocating the result array and butterfly. keepAlive() works by using a patchpoint to communicate to B3 that a value (the source array in this case) is still in use. It also uses a fence to keep B3 from relocating the patchpoint, which may defeat the fix. For the DFG's SpeculativeJIT::compileArraySlice(), we may have lucked out and the source array cell is kept alive. This patch makes it explicit that we should keep its cell alive till after the result array has been allocated. For the Baseline JIT and LLInt, we use the arrayProtoFuncSlice() runtime function and there is no issue because the source array (in "thisObj") is in the element copying loop that follows the allocation of the result array. However, for documentation purposes, this patch adds a call to HeapCell::use() to indicate that the source array need to kept alive at least until after the allocation of the result array. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArraySlice): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArraySlice): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::keepAlive): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSlice): 2019-06-22 Robin Morisset <rmorisset@apple.com> and Yusuke Suzuki <ysuzuki@apple.com> All prototypes should call didBecomePrototype() https://bugs.webkit.org/show_bug.cgi?id=196315 Reviewed by Saam Barati. Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor. I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't create structures with invalid prototypes. It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation(). Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype. * runtime/BigIntPrototype.cpp: (JSC::BigIntPrototype::finishCreation): * runtime/BooleanPrototype.cpp: (JSC::BooleanPrototype::finishCreation): * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): * runtime/ErrorConstructor.cpp: (JSC::ErrorConstructor::finishCreation): * runtime/ErrorPrototype.cpp: (JSC::ErrorPrototype::finishCreation): * runtime/FunctionConstructor.cpp: (JSC::FunctionConstructor::finishCreation): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::finishCreation): * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototype::finishCreation): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototype::finishCreation): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::finishCreation): * runtime/IntlPluralRulesPrototype.cpp: (JSC::IntlPluralRulesPrototype::finishCreation): * runtime/JSArrayBufferPrototype.cpp: (JSC::JSArrayBufferPrototype::finishCreation): * runtime/JSDataViewPrototype.cpp: (JSC::JSDataViewPrototype::finishCreation): * runtime/JSGenericTypedArrayViewPrototypeInlines.h: (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation): * runtime/JSGlobalObject.cpp: (JSC::createConsoleProperty): * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototype::finishCreation): * runtime/JSTypedArrayViewConstructor.cpp: (JSC::JSTypedArrayViewConstructor::finishCreation): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): * runtime/NumberPrototype.cpp: (JSC::NumberPrototype::finishCreation): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): * runtime/Structure.cpp: (JSC::Structure::isValidPrototype): (JSC::Structure::changePrototypeTransition): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::setPrototypeWithoutTransition): * runtime/SymbolPrototype.cpp: (JSC::SymbolPrototype::finishCreation): * wasm/js/WebAssemblyCompileErrorPrototype.cpp: (JSC::WebAssemblyCompileErrorPrototype::finishCreation): * wasm/js/WebAssemblyInstancePrototype.cpp: (JSC::WebAssemblyInstancePrototype::finishCreation): * wasm/js/WebAssemblyLinkErrorPrototype.cpp: (JSC::WebAssemblyLinkErrorPrototype::finishCreation): * wasm/js/WebAssemblyMemoryPrototype.cpp: (JSC::WebAssemblyMemoryPrototype::finishCreation): * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::WebAssemblyModulePrototype::finishCreation): * wasm/js/WebAssemblyPrototype.cpp: (JSC::WebAssemblyPrototype::finishCreation): * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation): * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::WebAssemblyTablePrototype::finishCreation): 2019-06-22 Yusuke Suzuki <ysuzuki@apple.com> [JSC] Strict, Sloppy and Arrow functions should have different classInfo https://bugs.webkit.org/show_bug.cgi?id=197631 Reviewed by Saam Barati. If a constructor inherits a builtin class, it creates a Structure which is subclassing the builtin class. This is done by using InternalFunction::createSubclassStructure. But to accelerate the common cases, we cache the created structure in InternalFunctionAllocationProfile. Whether the cache is valid is checked by comparing classInfo of the cached structure and the given base structure. This implicitly assume that each builtin class's InternalFunction creates an instance based on one structure. However, Function constructor is an exception: Function constructor creates an instance which has different structures based on a parameter. If a strict code is given (e.g. "'use strict'"), it creates a function instance with strict function structure. As a result, InternalFunctionAllocationProfile incorrectly caches the structure. Consider the following code. class A extends Function { }; let a = new A("'use strict'"); let b = new A(""); While `a` and `b` should have different structures, `A` caches the structure for `a`, and reuse it even the given code is not a strict code. This is problematic: We are separating structures of strict, sloppy, and arrow functions because they have different properties. However, in the above case, a and b have the same structure while they have different properties. So it causes incorrect structure-based caching in JSC. One of the example is HasOwnPropertyCache. In this patch, we introduce JSStrictFunction, JSSloppyFunction, and JSArrowFunction classes and classInfos. This design works well and already partially accepted for JSGeneratorFunction, JSAsyncGeneratorFunction, and JSAsyncFunction. Each structure now has a different classInfo so that InternalFunctionAllocationProfile correctly caches and invalidates the cached one based on the classInfo. Since we already have different structures for these instances, and DFG and FTL optimizations are based on JSFunctionType (not classInfo), introducing these three classInfo do not break the optimization. Note that structures on ArrayConstructor does not cause the same problem. It only uses Undecided indexing typed array structure in InternalFunctionAllocationProfile, and once haveABadTime happens, it clears InternalFunctionAllocationProfile. * runtime/JSAsyncFunction.h: This subspaceFor is not necessary since it is defined in JSFunction. And we already ensure that sizeof(JSAsyncFunction) == sizeof(JSFunction). * runtime/JSAsyncGeneratorFunction.cpp: * runtime/JSAsyncGeneratorFunction.h: Ditto. * runtime/JSFunction.cpp: * runtime/JSFunction.h: * runtime/JSGeneratorFunction.h: Ditto. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): 2019-06-22 Yusuke Suzuki <ysuzuki@apple.com> [JSC] ClassExpr should not store result in the middle of evaluation https://bugs.webkit.org/show_bug.cgi?id=199106 Reviewed by Tadeu Zagallo. Let's consider the case, let a = class A { static get[a=0x12345678]() { } }; When evaluating `class A` expression, we should not use the local register for `let a` until we finally store it to that register. Otherwise, `a=0x12345678` will override it. Out BytecodeGenerator does that this by using tempDestination and finalDestination, but we did not do that in ClassExprNode. This patch leverages tempDestination and finalDestination to store `class A` result finally, while we attempt to reduce mov. * bytecompiler/NodesCodegen.cpp: (JSC::ClassExprNode::emitBytecode): 2019-06-21 Sihui Liu <sihui_liu@apple.com> openDatabase should return an empty object when WebSQL is disabled https://bugs.webkit.org/show_bug.cgi?id=198805 Reviewed by Geoffrey Garen. * runtime/JSFunction.cpp: (JSC::JSFunction::createFunctionThatMasqueradesAsUndefined): * runtime/JSFunction.h: 2019-06-21 Alexey Shvayka <shvaikalesh@gmail.com> Remove extra check in RegExp @matchSlow https://bugs.webkit.org/show_bug.cgi?id=198846 Reviewed by Joseph Pecoraro. Type of RegExp `exec` result is already asserted in @regExpExec. * builtins/RegExpPrototype.js: (globalPrivate.matchSlow): Remove isObject check. 2019-06-20 Justin Michaud <justin_michaud@apple.com> [WASM-References] Add extra tests for Wasm references + fix element parsing and subtyping bugs https://bugs.webkit.org/show_bug.cgi?id=199044 Reviewed by Saam Barati. Fix parsing table indices from the element section. The byte that we previously read as the table index actually tells us how to parse the table index. Fix some areas where we got the isSubtype check wrong, causing funcrefs to not be considred anyrefs. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::unify): * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseElement): * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::unify): 2019-06-18 Darin Adler <darin@apple.com> Tidy up the remaining bits of the AtomicString to AtomString rename https://bugs.webkit.org/show_bug.cgi?id=198990 Reviewed by Michael Catanzaro. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage): Use flagIsAtom. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): Ditto. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): Ditto. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty): Ditto. (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent): Ditto. 2019-06-19 Alexey Shvayka <shvaikalesh@gmail.com> Optimize `resolve` method lookup in Promise static methods https://bugs.webkit.org/show_bug.cgi?id=198864 Reviewed by Yusuke Suzuki. Lookup `resolve` method only once in Promise.{all,allSettled,race}. (https://github.com/tc39/ecma262/pull/1506) Already implemented in V8. * builtins/PromiseConstructor.js: 2019-06-19 Tadeu Zagallo <tzagallo@apple.com> Some of the ASSERTs in CachedTypes.cpp should be RELEASE_ASSERTs https://bugs.webkit.org/show_bug.cgi?id=199030 Reviewed by Mark Lam. These assertions represent strong assumptions that the cache makes so it's not safe to keep executing if they fail. * runtime/CachedTypes.cpp: (JSC::Encoder::malloc): (JSC::Encoder::Page::alignEnd): (JSC::Decoder::ptrForOffsetFromBase): (JSC::Decoder::handleForEnvironment const): (JSC::Decoder::setHandleForEnvironment): (JSC::CachedPtr::get const): (JSC::CachedOptional::encode): (JSC::CachedOptional::decodeAsPtr const): Deleted. 2019-06-19 Adrian Perez de Castro <aperez@igalia.com> [WPE][GTK] Fix build with unified sources disabled https://bugs.webkit.org/show_bug.cgi?id=198752 Reviewed by Michael Catanzaro. * runtime/WeakObjectRefConstructor.h: Add missing inclusion of InternalFunction.h and forward declaration of WeakObjectRefPrototype. * wasm/js/WebAssemblyFunction.cpp: Add missing inclusion of JSWebAssemblyHelpers.h 2019-06-19 Justin Michaud <justin_michaud@apple.com> [WASM-References] Rename anyfunc to funcref https://bugs.webkit.org/show_bug.cgi?id=198983 Reviewed by Yusuke Suzuki. Anyfunc should become funcref since it was renamed in the spec. We should also support the string 'anyfunc' in the table constructor since this is the only non-binary-format place where it is exposed to users. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::gFuncref): (JSC::Wasm::AirIRGenerator::tmpForType): (JSC::Wasm::AirIRGenerator::emitCCall): (JSC::Wasm::AirIRGenerator::moveOpForValueType): (JSC::Wasm::AirIRGenerator::AirIRGenerator): (JSC::Wasm::AirIRGenerator::addLocal): (JSC::Wasm::AirIRGenerator::addConstant): (JSC::Wasm::AirIRGenerator::addRefFunc): (JSC::Wasm::AirIRGenerator::addReturn): (JSC::Wasm::AirIRGenerator::gAnyfunc): Deleted. * wasm/WasmCallingConvention.h: (JSC::Wasm::CallingConventionAir::marshallArgument const): (JSC::Wasm::CallingConventionAir::setupCall const): * wasm/WasmExceptionType.h: * wasm/WasmFormat.h: (JSC::Wasm::isValueType): (JSC::Wasm::isSubtype): (JSC::Wasm::TableInformation::wasmType const): * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser<Context>::parseExpression): * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseTableHelper): (JSC::Wasm::SectionParser::parseElement): (JSC::Wasm::SectionParser::parseInitExpr): * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::addRefFunc): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/WasmToJS.cpp: (JSC::Wasm::wasmToJS): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): (JSC::WebAssemblyFunction::jsCallEntrypointSlow): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::constructJSWebAssemblyTable): * wasm/wasm.json: 2019-06-19 Fujii Hironori <Hironori.Fujii@sony.com> [CMake][Win] CombinedDomains.json is generated twice in JavaScriptCore_CopyPrivateHeaders and JavaScriptCore projects https://bugs.webkit.org/show_bug.cgi?id=198853 Reviewed by Don Olmstead. JavaScriptCore_CopyPrivateHeaders target needs to have a direct or indirect dependency of JavaScriptCore target for CMake Visual Studio generator to eliminate duplicated custom commands. * CMakeLists.txt: Added JavaScriptCore as a dependency of JavaScriptCore_CopyPrivateHeaders. 2019-06-18 Yusuke Suzuki <ysuzuki@apple.com> [JSC] JSLock should be WebThread aware https://bugs.webkit.org/show_bug.cgi?id=198911 Reviewed by Geoffrey Garen. Since WebKitLegacy content rendering is done in WebThread instead of the main thread in iOS, user of WebKitLegacy (e.g. UIWebView) needs to grab the WebThread lock (which is a recursive lock) in the main thread when touching the WebKitLegacy content. But, WebKitLegacy can expose JSContext for the web view. And we can interact with the JS content through JavaScriptCore APIs. However, since WebThread is a concept in WebCore, JavaScriptCore APIs do not grab the WebThread lock. As a result, WebKitLegacy web content can be modified from the main thread without grabbing the WebThread lock through JavaScriptCore APIs. This patch makes JSC aware of WebThread: JSLock grabs the WebThread lock before grabbing JS's lock. While this seems layering violation, we already have many USE(WEB_THREAD) and WebThread aware code in WTF. Eventually, we should move WebThread code from WebCore to WTF since JSC and WTF need to be aware of WebThread. But, for now, we just use the function pointer exposed by WebCore. Since both JSLock and the WebThread lock are recursive locks, nested locking is totally OK. The possible problem is the order of locking. We ensure that we always grab locks in (1) the WebThread lock and (2) JSLock order. In JSLock, we take the WebThread lock, but we do not unlock it. This is how we use the WebThread lock: the WebThread lock is released automatically when RunLoop finishes the current cycle, and in WebKitLegacy, we do not call unlocking function of the WebThread lock except for some edge cases. * API/JSVirtualMachine.mm: (-[JSVirtualMachine isWebThreadAware]): * API/JSVirtualMachineInternal.h: * runtime/JSLock.cpp: (JSC::JSLockHolder::JSLockHolder): (JSC::JSLock::lock): (JSC::JSLockHolder::init): Deleted. * runtime/JSLock.h: (JSC::JSLock::makeWebThreadAware): (JSC::JSLock::isWebThreadAware const): 2019-06-18 Justin Michaud <justin_michaud@apple.com> [WASM-References] Add support for Table.size, grow and fill instructions https://bugs.webkit.org/show_bug.cgi?id=198761 Reviewed by Yusuke Suzuki. Add support for Table.size, grow and fill instructions. This also required adding support for two-byte opcodes to the ops generator. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::gAnyref): (JSC::Wasm::AirIRGenerator::tmpForType): (JSC::Wasm::AirIRGenerator::addTableSize): (JSC::Wasm::AirIRGenerator::addTableGrow): (JSC::Wasm::AirIRGenerator::addTableFill): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addTableSize): (JSC::Wasm::B3IRGenerator::addTableGrow): (JSC::Wasm::B3IRGenerator::addTableFill): * wasm/WasmExceptionType.h: * wasm/WasmFormat.h: (JSC::Wasm::TableInformation::wasmType const): * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser<Context>::parseExpression): (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression): * wasm/WasmInstance.cpp: (JSC::Wasm::doWasmTableGrow): (JSC::Wasm::doWasmTableFill): * wasm/WasmInstance.h: * wasm/WasmTable.cpp: (JSC::Wasm::Table::grow): * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::addTableSize): (JSC::Wasm::Validate::addTableGrow): (JSC::Wasm::Validate::addTableFill): * wasm/generateWasmOpsHeader.py: (opcodeMacroizer): (ExtTableOpType): * wasm/wasm.json: 2019-06-18 Keith Miller <keith_miller@apple.com> Unreviewed, fix signature of currentWeakRefVersion to return an uintptr_t. * runtime/VM.h: (JSC::VM::currentWeakRefVersion const): 2019-06-18 Justin Michaud <justin_michaud@apple.com> [WASM-References] Add support for multiple tables https://bugs.webkit.org/show_bug.cgi?id=198760 Reviewed by Saam Barati. Support multiple wasm tables. We turn tableInformation into a tables array, and update all of the existing users to give a table index. The array of Tables in Wasm::Instance is hung off the tail to make it easier to use from jit code. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::AirIRGenerator): (JSC::Wasm::AirIRGenerator::addTableGet): (JSC::Wasm::AirIRGenerator::addTableSet): (JSC::Wasm::AirIRGenerator::addCallIndirect): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::addTableGet): (JSC::Wasm::B3IRGenerator::addTableSet): (JSC::Wasm::B3IRGenerator::addCallIndirect): * wasm/WasmExceptionType.h: * wasm/WasmFormat.h: (JSC::Wasm::Element::Element): * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser<Context>::parseExpression): (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression): * wasm/WasmInstance.cpp: (JSC::Wasm::Instance::Instance): (JSC::Wasm::Instance::create): (JSC::Wasm::Instance::extraMemoryAllocated const): (JSC::Wasm::Instance::table): (JSC::Wasm::Instance::setTable): * wasm/WasmInstance.h: (JSC::Wasm::Instance::updateCachedMemory): (JSC::Wasm::Instance::offsetOfGlobals): (JSC::Wasm::Instance::offsetOfTablePtr): (JSC::Wasm::Instance::allocationSize): (JSC::Wasm::Instance::table): Deleted. (JSC::Wasm::Instance::setTable): Deleted. (JSC::Wasm::Instance::offsetOfTable): Deleted. * wasm/WasmModuleInformation.h: (JSC::Wasm::ModuleInformation::tableCount const): * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseImport): (JSC::Wasm::SectionParser::parseTableHelper): (JSC::Wasm::SectionParser::parseTable): (JSC::Wasm::SectionParser::parseElement): * wasm/WasmTable.h: (JSC::Wasm::Table::owner const): * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::addTableGet): (JSC::Wasm::Validate::addTableSet): (JSC::Wasm::Validate::addCallIndirect): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): (JSC::JSWebAssemblyInstance::visitChildren): * wasm/js/JSWebAssemblyInstance.h: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/wasm.json: 2019-06-18 Alexey Shvayka <shvaikalesh@gmail.com> [ESNExt] String.prototype.matchAll https://bugs.webkit.org/show_bug.cgi?id=186694 Reviewed by Yusuke Suzuki. Implement String.prototype.matchAll. (https://tc39.es/ecma262/#sec-string.prototype.matchall) Also rename @globalPrivate @constructor functions and C++ variables holding them. Shipping in Chrome since version 73. Shipping in Firefox since version 67. * CMakeLists.txt: * DerivedSources-input.xcfilelist: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/wkbuiltins/builtins_generate_combined_header.py: (get_var_name): (generate_section_for_global_private_code_name_macro): * Sources.txt: * builtins/ArrayPrototype.js: (globalPrivate.ArrayIterator): (values): (keys): (entries): (globalPrivate.createArrayIterator): Deleted. * builtins/AsyncFromSyncIteratorPrototype.js: (globalPrivate.createAsyncFromSyncIterator): (globalPrivate.AsyncFromSyncIterator): (globalPrivate.AsyncFromSyncIteratorConstructor): Deleted. * builtins/BuiltinNames.h: * builtins/MapPrototype.js: (globalPrivate.MapIterator): (values): (keys): (entries): (globalPrivate.createMapIterator): Deleted. * builtins/RegExpPrototype.js: (globalPrivate.RegExpStringIterator): (overriddenName.string_appeared_here.matchAll): * builtins/RegExpStringIteratorPrototype.js: Added. (next): * builtins/SetPrototype.js: (globalPrivate.SetIterator): (values): (entries): (globalPrivate.createSetIterator): Deleted. * builtins/StringPrototype.js: (matchAll): * builtins/TypedArrayPrototype.js: (values): (keys): (entries): * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): * runtime/RegExpStringIteratorPrototype.cpp: Added. (JSC::RegExpStringIteratorPrototype::finishCreation): * runtime/RegExpStringIteratorPrototype.h: Added. * runtime/StringPrototype.cpp: 2019-06-18 Keith Miller <keith_miller@apple.com> Add support for WeakRef https://bugs.webkit.org/show_bug.cgi?id=198710 Reviewed by Yusuke Suzuki. Add support for WeakRefs which are now at stage 3 (https://tc39.es/proposal-weakrefs). This patch doesn't add support for FinalizationGroups, which I'll add in another patch. Some other things of interest. Per the spec, we cannot collect a weak refs target unless it has not been dereffed (or created) in the current microtask turn. i.e. WeakRefs are only allowed to be collected at the end of a drain of the Microtask queue. My understanding for this behavior is to reduce implementation dependence on specific GC behavior in a given browser. We track if a WeakRef is retaining its target by using a version number on each WeakRef as well as on the VM. Whenever a WeakRef is derefed we update its version number to match the VM's then WriteBarrier ourselves. During marking if the VM and the WeakRef have the same version number, the target is visited. * JavaScriptCore.xcodeproj/project.pbxproj: * Sources.txt: * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizers): * jsc.cpp: (GlobalObject::finishCreation): (functionReleaseWeakRefs): * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: * runtime/JSGlobalObject.h: * runtime/JSWeakObjectRef.cpp: Added. (JSC::JSWeakObjectRef::finishCreation): (JSC::JSWeakObjectRef::visitChildren): (JSC::JSWeakObjectRef::finalizeUnconditionally): (JSC::JSWeakObjectRef::toStringName): * runtime/JSWeakObjectRef.h: Added. * runtime/VM.cpp: (JSC::VM::drainMicrotasks): * runtime/VM.h: (JSC::VM::setOnEachMicrotaskTick): (JSC::VM::finalizeSynchronousJSExecution): (JSC::VM::currentWeakRefVersion const): * runtime/WeakObjectRefConstructor.cpp: Added. (JSC::WeakObjectRefConstructor::finishCreation): (JSC::WeakObjectRefConstructor::WeakObjectRefConstructor): (JSC::callWeakRef): (JSC::constructWeakRef): * runtime/WeakObjectRefConstructor.h: Added. (JSC::WeakObjectRefConstructor::create): (JSC::WeakObjectRefConstructor::createStructure): * runtime/WeakObjectRefPrototype.cpp: Added. (JSC::WeakObjectRefPrototype::finishCreation): (JSC::getWeakRef): (JSC::protoFuncWeakRefDeref): * runtime/WeakObjectRefPrototype.h: Added. 2019-06-18 Tadeu Zagallo <tzagallo@apple.com> Add missing mutator fence in compileNewFunction https://bugs.webkit.org/show_bug.cgi?id=198849 <rdar://problem/51733890> Reviewed by Saam Barati. Follow-up after r246553. Saam pointed out that we still need a mutator fence before allocating the FunctionRareData, since the allocation might trigger a slow path call. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): 2019-06-18 Tadeu Zagallo <tzagallo@apple.com> DFG code should not reify the names of builtin functions with private names https://bugs.webkit.org/show_bug.cgi?id=198849 <rdar://problem/51733890> Reviewed by Filip Pizlo. Builtin functions that have a private name call setHasReifiedName from finishCreation. When compiled with DFG and FTL, that does not get called and the function ends up reifying its name. In order to fix that, we initialize FunctionRareData and set m_hasReifiedName to true from compileNewFunction in both DFG and FTL. * bytecode/InternalFunctionAllocationProfile.h: (JSC::InternalFunctionAllocationProfile::offsetOfStructure): * bytecode/ObjectAllocationProfile.h: (JSC::ObjectAllocationProfileWithPrototype::offsetOfPrototype): * bytecode/UnlinkedFunctionExecutable.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): * runtime/FunctionExecutable.h: * runtime/FunctionRareData.h: * runtime/JSFunction.cpp: (JSC::JSFunction::finishCreation): * runtime/JSFunction.h: * runtime/JSFunctionInlines.h: (JSC::JSFunction::isAnonymousBuiltinFunction const): 2019-06-18 Keith Miller <keith_miller@apple.com> MaybeParseAsGeneratorForScope sometimes loses track of its scope ref https://bugs.webkit.org/show_bug.cgi?id=198969 <rdar://problem/51620714> Reviewed by Tadeu Zagallo. Sometimes if the parser has enough nested scopes MaybeParseAsGeneratorForScope can lose track of the ScopeRef it should be tracking. This is because the parser sometimes relocates its ScopeRefs. To fix this MaybeParseAsGeneratorForScope should hold the scope ref it's watching. * parser/Parser.cpp: (JSC::Scope::MaybeParseAsGeneratorForScope::MaybeParseAsGeneratorForScope): (JSC::Scope::MaybeParseAsGeneratorForScope::~MaybeParseAsGeneratorForScope): 2019-06-17 Justin Michaud <justin_michaud@apple.com> Validate that table element type is funcref if using an element section https://bugs.webkit.org/show_bug.cgi?id=198910 Reviewed by Yusuke Suzuki. Add missing validation when attempting to add an element section to an anyref table. * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseElement): 2019-06-17 Tadeu Zagallo <tzagallo@apple.com> Concurrent GC should check the conn before starting a new collection cycle https://bugs.webkit.org/show_bug.cgi?id=198913 <rdar://problem/49515149> Reviewed by Filip Pizlo. Heap::requestCollection tries to steal the conn as an optimization to avoid waking up the collector thread if it's idle. We determine if the collector is idle by ensuring that there are no pending collections and that the current GC phase is NotRunning. However, that's not safe immediately after the concurrent GC has finished processing the last pending request. The collector thread will runEndPhase and immediately start runNotRunningPhase, without checking if it still has the conn. If the mutator has stolen the conn in the mean time, this will lead to both threads collecting concurrently, and eventually we'll crash in checkConn, since the collector is running but doesn't have the conn anymore. To solve this, we check if we still have the conn after holding the lock in runNotRunningPhase, in case the mutator has stolen the conn. Ideally, we wouldn't let the mutator steal the conn in the first place, but that doesn't seem trivial to determine. * heap/Heap.cpp: (JSC::Heap::runNotRunningPhase): 2019-06-17 Yusuke Suzuki <ysuzuki@apple.com> [JSC] Introduce DisposableCallSiteIndex to enforce type-safety https://bugs.webkit.org/show_bug.cgi?id=197378 Reviewed by Saam Barati. Some of CallSiteIndex are disposable. This is because some of CallSiteIndex are allocated and freed at runtime (not DFG/FTL compile time). The example is CallSiteIndex for exception handler in GCAwareJITStubRoutineWithExceptionHandler. If we do not allocate and free CallSiteIndex, we will create a new CallSiteIndex continuously and leak memory. The other CallSiteIndex are not simply disposable because the ownership model is not unique one. They can be shared between multiple clients. But not disposing them is OK because they are static one: they are allocated when compiling DFG/FTL, and we do not allocate such CallSiteIndex at runtime. To make this difference explicit and avoid disposing non-disposable CallSiteIndex accidentally, we introduce DisposableCallSiteIndex type, and enforce type-safety to some degree. We also correctly update the DisposableCallSiteIndex => CodeOrigin table when we are reusing the previously used DisposableCallSiteIndex. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::newExceptionHandlingCallSiteIndex): (JSC::CodeBlock::removeExceptionHandlerForCallSite): * bytecode/CodeBlock.h: * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationState::callSiteIndexForExceptionHandling): (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: (JSC::AccessGenerationState::callSiteIndexForExceptionHandling): Deleted. * dfg/DFGCommonData.cpp: (JSC::DFG::CommonData::addUniqueCallSiteIndex): (JSC::DFG::CommonData::addDisposableCallSiteIndex): (JSC::DFG::CommonData::removeDisposableCallSiteIndex): (JSC::DFG::CommonData::removeCallSiteIndex): Deleted. * dfg/DFGCommonData.h: * interpreter/CallFrame.h: (JSC::DisposableCallSiteIndex::DisposableCallSiteIndex): (JSC::DisposableCallSiteIndex::fromCallSiteIndex): * jit/GCAwareJITStubRoutine.cpp: (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler): (JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount): (JSC::createJITStubRoutine): * jit/GCAwareJITStubRoutine.h: * jit/JITInlineCacheGenerator.h: 2019-06-17 Justin Michaud <justin_michaud@apple.com> [WASM-References] Add support for Funcref in parameters and return types https://bugs.webkit.org/show_bug.cgi?id=198157 Reviewed by Yusuke Suzuki. Add support for funcref in parameters, globals, and in table.get/set. When converting a JSValue to a funcref (nee anyfunc), we first make sure it is an exported wasm function or null. We also add support for Ref.func. Anywhere a Ref.func is used, (statically) we construct a JS wrapper for it so that we never need to construct JSValues when handling references. This should make threads easier to implement. Finally, we add some missing bounds checks for table.get/set. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::tmpForType): (JSC::Wasm::AirIRGenerator::moveOpForValueType): (JSC::Wasm::AirIRGenerator::AirIRGenerator): (JSC::Wasm::AirIRGenerator::addLocal): (JSC::Wasm::AirIRGenerator::addConstant): (JSC::Wasm::AirIRGenerator::addRefFunc): (JSC::Wasm::AirIRGenerator::addTableSet): (JSC::Wasm::AirIRGenerator::setGlobal): (JSC::Wasm::AirIRGenerator::addReturn): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addLocal): (JSC::Wasm::B3IRGenerator::addTableSet): (JSC::Wasm::B3IRGenerator::addRefFunc): (JSC::Wasm::B3IRGenerator::setGlobal): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunctions): * wasm/WasmCallingConvention.h: (JSC::Wasm::CallingConventionAir::marshallArgument const): (JSC::Wasm::CallingConventionAir::setupCall const): * wasm/WasmExceptionType.h: * wasm/WasmFormat.h: (JSC::Wasm::isValueType): (JSC::Wasm::isSubtype): * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser<Context>::parseExpression): (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression): * wasm/WasmInstance.cpp: (JSC::Wasm::Instance::Instance): (JSC::Wasm::Instance::getFunctionWrapper const): (JSC::Wasm::Instance::setFunctionWrapper): * wasm/WasmInstance.h: * wasm/WasmModuleInformation.h: (JSC::Wasm::ModuleInformation::referencedFunctions const): (JSC::Wasm::ModuleInformation::addReferencedFunction const): * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseGlobal): (JSC::Wasm::SectionParser::parseInitExpr): * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::addTableGet): (JSC::Wasm::Validate::addTableSet): (JSC::Wasm::Validate::addRefIsNull): (JSC::Wasm::Validate::addRefFunc): (JSC::Wasm::Validate::setLocal): (JSC::Wasm::Validate::addCall): (JSC::Wasm::Validate::addCallIndirect): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/JSWebAssemblyHelpers.h: (JSC::isWebAssemblyHostFunction): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::visitChildren): * wasm/js/JSWebAssemblyRuntimeError.cpp: (JSC::createJSWebAssemblyRuntimeError): * wasm/js/JSWebAssemblyRuntimeError.h: * wasm/js/WasmToJS.cpp: (JSC::Wasm::handleBadI64Use): (JSC::Wasm::wasmToJS): (JSC::Wasm::emitWasmToJSException): * wasm/js/WasmToJS.h: * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): (JSC::WebAssemblyFunction::jsCallEntrypointSlow): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): * wasm/wasm.json: 2019-06-16 Darin Adler <darin@apple.com> Rename AtomicString to AtomString https://bugs.webkit.org/show_bug.cgi?id=195276 Reviewed by Michael Catanzaro. * many files: Let do-webcore-rename do the renaming. 2019-06-16 Yusuke Suzuki <ysuzuki@apple.com> [JSC] Grown region of WasmTable should be initialized with null https://bugs.webkit.org/show_bug.cgi?id=198903 Reviewed by Saam Barati. Grown region of Wasmtable is now empty. We should initialize it with null. We also rename Wasm::Table::visitChildren to Wasm::Table::visitAggregate to align to the naming convention. * wasm/WasmTable.cpp: (JSC::Wasm::Table::grow): (JSC::Wasm::Table::visitAggregate): (JSC::Wasm::Table::visitChildren): Deleted. * wasm/WasmTable.h: * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::visitChildren): 2019-06-14 Keith Miller <keith_miller@apple.com> Restore PAC based cage. https://bugs.webkit.org/show_bug.cgi?id=198872 Rubber-stamped by Saam Barati. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::bitFieldInsert64): * assembler/MacroAssemblerARM64E.h: * assembler/testmasm.cpp: (JSC::testCagePreservesPACFailureBit): (JSC::run): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds): (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage): (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToB3::caged): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cageWithoutUntagging): (JSC::AssemblyHelpers::cageConditionally): (JSC::AssemblyHelpers::cage): Deleted. * jit/JITPropertyAccess.cpp: (JSC::JIT::emitIntTypedArrayGetByVal): (JSC::JIT::emitFloatTypedArrayGetByVal): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/instructions.rb: * offlineasm/registers.rb: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::AirIRGenerator::addCallIndirect): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::B3IRGenerator::addCallIndirect): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::jsCallEntrypointSlow): 2019-06-13 Yusuke Suzuki <ysuzuki@apple.com> Yarr bytecode compilation failure should be gracefully handled https://bugs.webkit.org/show_bug.cgi?id=198700 Reviewed by Michael Saboff. Currently, we assume that Yarr bytecode compilation does not fail. But in fact it can fail. We should gracefully handle this failure as a runtime error, as we did for parse errors in [1]. We also harden Yarr's consumed character calculation by using Checked. [1]: https://bugs.webkit.org/show_bug.cgi?id=185755 * inspector/ContentSearchUtilities.cpp: (Inspector::ContentSearchUtilities::findMagicComment): * runtime/RegExp.cpp: (JSC::RegExp::byteCodeCompileIfNecessary): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/RegExpInlines.h: (JSC::RegExp::matchInline): * yarr/YarrErrorCode.cpp: (JSC::Yarr::errorMessage): (JSC::Yarr::errorToThrow): * yarr/YarrErrorCode.h: * yarr/YarrInterpreter.cpp: (JSC::Yarr::ByteCompiler::ByteCompiler): (JSC::Yarr::ByteCompiler::compile): (JSC::Yarr::ByteCompiler::atomCharacterClass): (JSC::Yarr::ByteCompiler::atomBackReference): (JSC::Yarr::ByteCompiler::atomParenthesesOnceBegin): (JSC::Yarr::ByteCompiler::atomParenthesesTerminalBegin): (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternBegin): (JSC::Yarr::ByteCompiler::atomParentheticalAssertionBegin): (JSC::Yarr::ByteCompiler::popParenthesesStack): (JSC::Yarr::ByteCompiler::closeAlternative): (JSC::Yarr::ByteCompiler::closeBodyAlternative): (JSC::Yarr::ByteCompiler::alternativeBodyDisjunction): (JSC::Yarr::ByteCompiler::alternativeDisjunction): (JSC::Yarr::ByteCompiler::emitDisjunction): 2019-06-12 Yusuke Suzuki <ysuzuki@apple.com> [JSC] Polymorphic call stub's slow path should restore callee saves before performing tail call https://bugs.webkit.org/show_bug.cgi?id=198770 Reviewed by Saam Barati. Polymorphic call stub is a bit specially patched in JS call site. Typical JS call site for tail calls are the following. if (callee == patchableCallee) { restore callee saves for tail call prepare for tail call jump to the target function } restore callee saves for slow path call the slow path function And linking patches patchableCallee, target function, and slow path function. But polymorphic call stub patches the above `if` statement with the jump to the stub. jump to the polymorphic call stub This is because polymorphic call stub wants to use CallFrameShuffler to get scratch registers. As a result, "restore callee saves for tail call" thing needs to be done in the polymorphic call stubs. While it is correctly done for the major cases, we have `slowPath` skips, and that path missed restoring callee saves. This skip happens if the callee is non JSCell or non JS function, so typically, InternalFunction is handled in that path. This patch does that skips after restoring callee saves. * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::CallLinkInfo): * bytecode/CallLinkInfo.h: (JSC::CallLinkInfo::setUpCall): (JSC::CallLinkInfo::calleeGPR): (JSC::CallLinkInfo::setCalleeGPR): Deleted. * jit/Repatch.cpp: (JSC::revertCall): (JSC::linkVirtualFor): (JSC::linkPolymorphicCall): * jit/Repatch.h: * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): 2019-06-12 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r246322. https://bugs.webkit.org/show_bug.cgi?id=198796 "It's a huge page load regression on iOS" (Requested by saamyjoon on #webkit). Reverted changeset: "Roll out PAC cage" https://bugs.webkit.org/show_bug.cgi?id=198726 https://trac.webkit.org/changeset/246322 2019-06-11 Alexey Shvayka <shvaikalesh@gmail.com> JSC should throw if proxy set returns falsish in strict mode context https://bugs.webkit.org/show_bug.cgi?id=177398 Reviewed by Yusuke Suzuki. Throw TypeError exception if Proxy's `set` trap returns falsy value. (step 6.c of https://tc39.es/ecma262/#sec-putvalue) * runtime/ProxyObject.cpp: (JSC::ProxyObject::performPut): (JSC::ProxyObject::put): (JSC::ProxyObject::putByIndexCommon): * runtime/ProxyObject.h: 2019-06-11 Alexey Shvayka <shvaikalesh@gmail.com> Error message for non-callable Proxy `construct` trap is misleading https://bugs.webkit.org/show_bug.cgi?id=198637 Reviewed by Saam Barati. Just like other traps, Proxy `construct` trap is invoked with [[Call]], not [[Construct]]. * runtime/ProxyObject.cpp: (JSC::performProxyConstruct): Tweak error message. 2019-06-10 Tadeu Zagallo <tzagallo@apple.com> AI BitURShift's result should not be unsigned https://bugs.webkit.org/show_bug.cgi?id=198689 <rdar://problem/51550063> Reviewed by Saam Barati. Treating BitURShift's result as unsigned in the abstract interpreter incorrectly overflows it. This breaks the DFG and FTL, since they assume that BitURShift's result is an int32 value, but get a double constant from AI. Since the result will be converted to unsigned by UInt32ToNumber, all we have to do is store the result as a signed int32. * dfg/DFGAbstractInterpreterInlines.h: 2019-06-11 Michael Catanzaro <mcatanzaro@igalia.com> Unreviewed build warning fixes Silence -Wreturn-type warning * wasm/WasmTable.cpp: (JSC::Wasm::Table::tryCreate): 2019-06-11 Saam Barati <sbarati@apple.com> Roll out PAC cage https://bugs.webkit.org/show_bug.cgi?id=198726 Reviewed by Keith Miller. This patch rolls out: r245064, r245145, r245168, r245313, r245432, r245622. The resulting state we're in is we have Gigacage enabled on arm64. There is no more PAC caging. We're doing this because there are performance issues with PAC caging that we haven't resolved yet. * assembler/CPU.h: (JSC::isARM64E): Deleted. * assembler/MacroAssemblerARM64E.h: (JSC::MacroAssemblerARM64E::tagArrayPtr): Deleted. (JSC::MacroAssemblerARM64E::untagArrayPtr): Deleted. (JSC::MacroAssemblerARM64E::removeArrayPtrTag): Deleted. * b3/B3LowerToAir.cpp: * b3/B3PatchpointSpecial.cpp: (JSC::B3::PatchpointSpecial::admitsStack): * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::forEachArgImpl): (JSC::B3::StackmapSpecial::isArgValidForRep): * b3/B3Validate.cpp: * b3/B3ValueRep.cpp: (JSC::B3::ValueRep::addUsedRegistersTo const): (JSC::B3::ValueRep::dump const): (WTF::printInternal): * b3/B3ValueRep.h: (JSC::B3::ValueRep::ValueRep): (JSC::B3::ValueRep::isReg const): * dfg/DFGOperations.cpp: (JSC::DFG::newTypedArrayWithSize): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds): (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage): (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage): (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset): (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet): (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet): (JSC::FTL::DFG::LowerDFGToB3::caged): (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered): (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr): Deleted. (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag): Deleted. * heap/ConservativeRoots.cpp: (JSC::ConservativeRoots::genericAddPointer): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cageConditionally): * jit/IntrinsicEmitter.cpp: (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitDirectArgumentsGetByVal): (JSC::JIT::emitIntTypedArrayGetByVal): (JSC::JIT::emitFloatTypedArrayGetByVal): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * jit/PolymorphicCallStubRoutine.cpp: (JSC::PolymorphicCallNode::clearCallLinkInfo): * jit/RegisterSet.h: * llint/LowLevelInterpreter64.asm: * runtime/ArrayBuffer.cpp: (JSC::SharedArrayBufferContents::SharedArrayBufferContents): (JSC::SharedArrayBufferContents::~SharedArrayBufferContents): (JSC::ArrayBufferContents::ArrayBufferContents): (JSC::ArrayBufferContents::destroy): (JSC::ArrayBufferContents::tryAllocate): (JSC::ArrayBufferContents::makeShared): (JSC::ArrayBufferContents::copyTo): * runtime/ArrayBuffer.h: (JSC::SharedArrayBufferContents::data const): (JSC::ArrayBufferContents::data const): (JSC::ArrayBuffer::data): (JSC::ArrayBuffer::data const): (JSC::ArrayBuffer::byteLength const): * runtime/ArrayBufferView.cpp: (JSC::ArrayBufferView::ArrayBufferView): * runtime/ArrayBufferView.h: (JSC::ArrayBufferView::baseAddress const): (JSC::ArrayBufferView::setRangeImpl): (JSC::ArrayBufferView::getRangeImpl): (JSC::ArrayBufferView::byteLength const): Deleted. * runtime/CachedTypes.cpp: (JSC::CachedScopedArgumentsTable::encode): (JSC::CachedScopedArgumentsTable::decode const): * runtime/CagedBarrierPtr.h: (JSC::CagedBarrierPtr::CagedBarrierPtr): (JSC::CagedBarrierPtr::set): (JSC::CagedBarrierPtr::get const): (JSC::CagedBarrierPtr::getMayBeNull const): (JSC::CagedBarrierPtr::operator== const): (JSC::CagedBarrierPtr::operator!= const): (JSC::CagedBarrierPtr::operator bool const): (JSC::CagedBarrierPtr::setWithoutBarrier): (JSC::CagedBarrierPtr::operator* const): (JSC::CagedBarrierPtr::operator-> const): (JSC::CagedBarrierPtr::operator[] const): (JSC::CagedBarrierPtr::getUnsafe const): Deleted. (JSC::CagedBarrierPtr::at const): Deleted. * runtime/DataView.cpp: (JSC::DataView::DataView): * runtime/DataView.h: (JSC::DataView::get): (JSC::DataView::set): * runtime/DirectArguments.cpp: (JSC::DirectArguments::visitChildren): (JSC::DirectArguments::overrideThings): (JSC::DirectArguments::unmapArgument): * runtime/DirectArguments.h: * runtime/GenericArguments.h: * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments<Type>::visitChildren): (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor): (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor): (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor): * runtime/GenericTypedArrayView.h: * runtime/GenericTypedArrayViewInlines.h: (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView): * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext): (JSC::JSArrayBufferView::JSArrayBufferView): (JSC::JSArrayBufferView::finalize): (JSC::JSArrayBufferView::slowDownAndWasteMemory): * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::ConstructionContext::vector const): (JSC::JSArrayBufferView::isNeutered): (JSC::JSArrayBufferView::vector const): (JSC::JSArrayBufferView::hasVector const): Deleted. * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized): (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize): (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): * runtime/Options.h: * runtime/ScopedArgumentsTable.cpp: (JSC::ScopedArgumentsTable::clone): (JSC::ScopedArgumentsTable::setLength): * runtime/ScopedArgumentsTable.h: * runtime/SymbolTable.h: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::AirIRGenerator::addCallIndirect): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::B3IRGenerator::addCallIndirect): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::complete): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/WasmInstance.h: (JSC::Wasm::Instance::cachedMemory const): (JSC::Wasm::Instance::updateCachedMemory): * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::Memory): (JSC::Wasm::Memory::~Memory): (JSC::Wasm::Memory::grow): (JSC::Wasm::Memory::dump const): * wasm/WasmMemory.h: (JSC::Wasm::Memory::memory const): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::jsCallEntrypointSlow): 2019-06-10 Basuke Suzuki <Basuke.Suzuki@sony.com> [WinCairo] Remove build warning from RemoteInspector. https://bugs.webkit.org/show_bug.cgi?id=198724 Reviewed by Joseph Pecoraro. In `RemoteInspectorConnectionClient.h`, an interface was defined with empty implementation. This method is to be overwritten by sub classes so that parameter name is important so they are commented out rather than just removing from the definition. * inspector/remote/RemoteInspector.h: 2019-06-10 Sam Weinig <weinig@apple.com> Remove Dashboard support https://bugs.webkit.org/show_bug.cgi?id=198615 Reviewed by Ryosuke Niwa. * Configurations/FeatureDefines.xcconfig: 2019-06-10 Devin Rousso <drousso@apple.com> Web Automation: add notifications for when remote automation is enabled/disabled https://bugs.webkit.org/show_bug.cgi?id=198703 <rdar://problem/50588975> Reviewed by Timothy Hatcher. * inspector/remote/RemoteInspectorConstants.h: 2019-06-10 Yusuke Suzuki <ysuzuki@apple.com> Unreviewed, build fix for non-DFG configurations, part 2 https://bugs.webkit.org/show_bug.cgi?id=198023 * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finalizeUnconditionally): 2019-06-10 Yusuke Suzuki <ysuzuki@apple.com> Unreviewed, build fix for non-DFG configurations https://bugs.webkit.org/show_bug.cgi?id=198023 * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finalizeUnconditionally): 2019-06-10 Yusuke Suzuki <ysuzuki@apple.com> [JSC] UnlinkedCodeBlock should be eventually jettisoned in VM mini mode https://bugs.webkit.org/show_bug.cgi?id=198023 Reviewed by Saam Barati. While CodeBlock is periodically jettisoned, UnlinkedCodeBlock and UnlinkedFunctionExecutable can be retained almost forever in certain type of applications. When we execute a program, which has UnlinkedProgramCodeBlock retained in CodeCache. And UnlinkedProgramCodeBlock holds array of UnlinkedFunctionExecutable. And UnlinkedFunctionExecutables hold UnlinkedFunctionCodeBlocks once it is generated. So eventually, this tree gets larger and larger until we purge UnlinkedProgramCodeBlock from CodeCache. This is OK in the browser case. We navigate to various other pages, and UnlinkedProgramCodeBlocks should eventually be pruned from CodeCache with the new ones. So this tree won't be retained forever. But the behavior is different in the other applications that do not have navigations. If they only have one program which holds all, we basically retain this tree during executing this application. The same thing can happen in web applications which does not have navigation and keeps alive for a long time. Once we hit CodeCache limit by periodically executing a new script, we will hit the uppermost of memory footprint. But until that, we increase our memory footprint. However, destroying these UnlinkedCodeBlocks and UnlinkedFunctionExecutables causes a tricky problem. In the browser environment, navigation can happen at any time. So even if the given UnlinkedCodeBlock seems unused in the current page, it can be used when navigating to a new page which is under the same domain. One example is initializing function in a script. It is only executed once per page. So once it is executed, it seems that this UnlinkedCodeBlock is unused. But this will be used when we navigate to a new page. Pruning code blocks based on usage could cause performance regression. But if our VM is mini VM mode, the story is different. In mini VM mode, we focus on memory footprint rather than performance e.g. daemons. The daemon never reuse these CodeCache since we do not have the navigation. This patch logically makes UnlinkedFunctionExecutable -> UnlinkedCodeBlock reference weak when VM is mini mode. If UnlinkedCodeBlock is used in previous GC cycle, we retain it. But if it is not used, and if UnlinkedFunctionExecutable is only the cell keeping UnlinkedCodeBlock alive, we destroy it. It is a heuristic. In a super pathological case, it could increase memory footprint. Consider the following example. UnlinkedFunctionExecutable(A1) -> UnlinkedCodeBlock(B1) -> UnlinkedFunctionExecutable(C1) -> UnlinkedCodeBlock(D1) ^ CodeBlock(E1) We could delete A1, B1, and C1 while keeping D1. But if we eventually re-execute the same code corresponding to A1, B1, C1, they will be newly created, and we will create duplicate UnlinkedCodeBlock and instructions stream for D1. UnlinkedCodeBlock(D1) ^ CodeBlock(E1) UnlinkedFunctionExecutable(A2) -> UnlinkedCodeBlock(B2) -> UnlinkedFunctionExecutable(C2) -> UnlinkedCodeBlock(D2) But this does not happen in practice and even it happens, we eventually discard D1 and D2 since CodeBlock E1 will be jettisoned anyway. So in practice, we do not see memory footprint increase. We tested it in Gmail and the target application, but both said memory footprint reduction (30 MB / 400 MB and 1 MB /6 MB). While this affects on performance much on tests which has navigation (1-3 % regression in Speedometer2, note that JetStream2 does not show regression in x64, while it is not enabling mini mode), we do not apply this to non mini mode VM until we come up with a good strategy to fasten performance of re-generation. Personally I think flushing destroyed UnlinkedCodeBlock to the disk sounds promising. If UnlinkedCodeBlock is generated from bytecode cache, we do not make UnlinkedFunctionExecutable -> UnlinkedCodeBlock link weak because the decoder of the bytecode cache assumes that generated JSCells won't be destroyed while the parent cells of that cell are live. This is true in the current implementation, and this assumption will be broken with this patch. So, for now, we do not make this link weak. Currently, our target application does not use bytecode cache so it is OK. This patch also introduce simple heuristic. We are counting UnlinkedCodeBlock's age. And once the age becomes maximum size, we make UnlinkedFunctionExecutable -> UnlinkedCodeBlock link weak. We also use execution counter information to reset this age: CodeBlock will reset undelying UnlinkedCodeBlock's age if it has executed While this heuristic is quite simple, it has some effect in practice. Basically what happens with this heuristic is that UnlinkedFunctionExecutable -> UnlinkedCodeBlock link strong. When GC happens, we are executing some CodeBlocks, which become live. And ScriptExecutables -> UnlinkedFunctionExecutables held by this CodeBlock become also live. Then UnlinkedFunctionExecutables can mark the child UnlinkedCodeBlocks if it is not so old. If some of parent UnlinkedFunctionExecutable becomes dead, child UnlinkedCodeBlocks tends to be dead unless some live CodeBlock holds it. But it is OK for a first heuristics since this means that parent code block is now considered old, reachable UnlinkedCodeBlock will be used when the parent is executed again. So destroying the tree is OK even if the tree may include some new UnlinkedCodeBlock. While we could make more sophisticated mechanism to manage these lifetime, I think this is a good starting point. Based on measurement, we pick 7 as a maximum age. If we pick 0, we can get more memory reduction (1 - 1.5 MB!), while we ends up reparsing codes so many times. It seems that 7 can reduce fair amount of memory while doing small # of reparsing on average (usually, 1, 2. Sometimes, 100. But not 300, which is the case in 0). If we want to get more memory reduction for the sake of performance, we could decrease this age limit. Since we do not have an automated script right now so it is a bit difficult to measure memory footprint precisely. But manual testing shows that this patch improves memory footprint of our target application from about 6.5 MB to about 5.9 MB. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finalizeUnconditionally): * bytecode/CodeBlock.h: * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::UnlinkedCodeBlock::visitChildren): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::age const): (JSC::UnlinkedCodeBlock::resetAge): * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): (JSC::UnlinkedFunctionExecutable::visitChildren): (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor): (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks): (JSC::UnlinkedFunctionExecutable::finalizeUnconditionally): * bytecode/UnlinkedFunctionExecutable.h: * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizers): * runtime/CachedTypes.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): * runtime/CodeSpecializationKind.h: * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::isInMiniMode): Deleted. * runtime/VM.h: (JSC::VM::isInMiniMode): (JSC::VM::useUnlinkedCodeBlockJettisoning): 2019-06-10 Timothy Hatcher <timothy@apple.com> Integrate dark mode support for iOS. https://bugs.webkit.org/show_bug.cgi?id=198687 rdar://problem/51545643 Reviewed by Tim Horton. * Configurations/FeatureDefines.xcconfig: 2019-06-10 Adrian Perez de Castro <aperez@igalia.com> [JSC] Linker fails when unified sources are not in use https://bugs.webkit.org/show_bug.cgi?id=198722 Reviewed by Keith Miller. Added missing inclusions of headers in several files which make use of inline functions. * b3/B3AtomicValue.cpp: * b3/B3BlockInsertionSet.cpp: * b3/B3FenceValue.cpp: * b3/B3LowerMacrosAfterOptimizations.cpp: * b3/B3PureCSE.cpp: * b3/B3StackmapValue.cpp: * b3/B3SwitchValue.cpp: * b3/B3UseCounts.cpp: * b3/B3VariableValue.cpp: * b3/B3WasmAddressValue.cpp: * b3/B3WasmBoundsCheckValue.cpp: * ftl/FTLCompile.cpp: * wasm/WasmSectionParser.cpp: * wasm/WasmTable.cpp: * wasm/WasmValidate.cpp: 2019-06-10 Keith Miller <keith_miller@apple.com> Make new Symbol/Promise API public https://bugs.webkit.org/show_bug.cgi?id=198709 Reviewed by Saam Barati. We also need to #ifdef some tests when building for older platforms because the signatures for some methods are outdated on those platforms. * API/JSObjectRef.h: * API/JSObjectRefPrivate.h: * API/JSValue.h: * API/JSValuePrivate.h: * API/JSValueRef.h: * API/tests/testapi.mm: (testObjectiveCAPIMain): 2019-06-09 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r246150, r246160, and r246166. https://bugs.webkit.org/show_bug.cgi?id=198698 Regresses page loading time on iOS 13 (Requested by keith_m__ on #webkit). Reverted changesets: "Reenable Gigacage on ARM64." https://bugs.webkit.org/show_bug.cgi?id=198453 https://trac.webkit.org/changeset/246150 "Unrevied build fix for FTL without Gigacage." https://trac.webkit.org/changeset/246160 "Fix typo in cageWithoutUntagging" https://bugs.webkit.org/show_bug.cgi?id=198617 https://trac.webkit.org/changeset/246166 2019-06-09 Yusuke Suzuki <ysuzuki@apple.com> [JSC] Use mergePrediction in ValuePow prediction propagation https://bugs.webkit.org/show_bug.cgi?id=198648 Reviewed by Saam Barati. We are accidentally using setPrediction. This is wrong since prediction propagation (not processInvariant) must extend the speculation types to ensure we eventually reach to the fixed point. setPrediction can discard previously configured predictions, can lead to oscillation potentially. Use mergePrediction instead. * dfg/DFGPredictionPropagationPhase.cpp: 2019-06-07 Tadeu Zagallo <tzagallo@apple.com> AI should get GetterSetter structure from the base's GlobalObject for GetGetterSetterByOffset https://bugs.webkit.org/show_bug.cgi?id=198581 <rdar://problem/51099753> Reviewed by Saam Barati. For GetGetterSetterByOffset, when the abstract interpreter fails to read the property from the object, it gets the GetterSetter structure from the CodeBlock's global object. However, that's not correct, since the global object for the base object might differ from the CodeBlock's. Instead, we try to get the global object from the base, when it's a constant object. Otherwise, we can't infer the value and only set the type. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): 2019-06-06 Devin Rousso <drousso@apple.com> Web Inspector: create CommandLineAPIHost lazily like the other agents https://bugs.webkit.org/show_bug.cgi?id=196047 <rdar://problem/49087835> Reviewed by Timothy Hatcher. * inspector/InjectedScriptManager.h: * inspector/InjectedScriptManager.cpp: (Inspector::InjectedScriptManager::connect): Added. 2019-06-06 Keith Miller <keith_miller@apple.com> Fix typo in cageWithoutUntagging https://bugs.webkit.org/show_bug.cgi?id=198617 Reviewed by Saam Barati. * assembler/testmasm.cpp: (JSC::testCagePreservesPACFailureBit): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage): (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cageWithoutUntagging): (JSC::AssemblyHelpers::cageConditionally): (JSC::AssemblyHelpers::cageWithoutUntaging): Deleted. 2019-06-06 Alexey Shvayka <shvaikalesh@gmail.com> JSON.parse throws incorrect exception when called w/o arguments https://bugs.webkit.org/show_bug.cgi?id=198574 Reviewed by Yusuke Suzuki. Always coerce first argument to string and attempt to parse it. (steps 1-2 of https://tc39.github.io/ecma262/#sec-json.parse) * runtime/JSONObject.cpp: (JSC::JSONProtoFuncParse): Remove argumentCount check. 2019-06-06 Keith Miller <keith_miller@apple.com> Unrevied build fix for FTL without Gigacage. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::caged): 2019-06-06 Michael Catanzaro <mcatanzaro@igalia.com> aarch64: ‘JSC::ARM64Assembler::LinkRecord::<unnamed union>::RealTypes::m_compareRegister’ is too small to hold all values of ‘JSC::ARM64Assembler::RegisterID’ {aka ‘enum JSC::ARM64Registers::RegisterID’} https://bugs.webkit.org/show_bug.cgi?id=198014 Reviewed by Yusuke Suzuki. When building for aarch64, there is a huge warning spam here. It's impossible to see any other warnings. This has been ongoing for so long I've begun to suspect that nobody works on this architecture. Anyway, the problem is because we need eight bits to store all possible RegisterID values, but the bitfield is only six bits wide. Fix it. The COMPILE_ASSERT checking the size of this struct is still happy, so I presume the change is OK. * assembler/ARM64Assembler.h: 2019-06-06 Keith Miller <keith_miller@apple.com> Reenable Gigacage on ARM64. https://bugs.webkit.org/show_bug.cgi?id=198453 Reviewed by Michael Saboff. This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the old Gigacage however, arm64e uses both Gigacaging and PAC. In order to ensure the PAC bits are not stripped in the caging process we use the bit field insert instruction to take the low bits from caging and the high bits from the PAC authentication. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::bitFieldInsert64): * assembler/MacroAssemblerARM64E.h: * assembler/testmasm.cpp: (JSC::testCagePreservesPACFailureBit): (JSC::run): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds): (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage): (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToB3::caged): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::cageWithoutUntaging): (JSC::AssemblyHelpers::cageConditionally): (JSC::AssemblyHelpers::cage): Deleted. * jit/JITPropertyAccess.cpp: (JSC::JIT::emitIntTypedArrayGetByVal): (JSC::JIT::emitFloatTypedArrayGetByVal): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/instructions.rb: * offlineasm/registers.rb: * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::AirIRGenerator::addCallIndirect): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::B3IRGenerator::addCallIndirect): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/js/JSToWasm.cpp: (JSC::Wasm::createJSToWasmWrapper): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::jsCallEntrypointSlow): 2019-06-06 Michael Saboff <msaboff@apple.com> [ARM64E]: Add disassembler support for authenticated instructions https://bugs.webkit.org/show_bug.cgi?id=198562 Reviewed by Keith Miller. Added support for all the instructions supported in ARM64EAssembler.h. * disassembler/ARM64/A64DOpcode.cpp: (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format): (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format): (JSC::ARM64Disassembler::A64DOpcodeHint::format): (JSC::ARM64Disassembler::A64DOpcodeHint::opName): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::format): (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpName): (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::format): * disassembler/ARM64/A64DOpcode.h: (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::opNameIndex): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opName): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opNum): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::mBit): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::sBit): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::wBit): (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::immediate10): (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpCode): (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op2): (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op3): (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op4): (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::mBit): (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::rm): (JSC::ARM64Disassembler::A64DOpcodeHint::opName): Deleted. 2019-06-05 Justin Michaud <justin_michaud@apple.com> [WASM-References] Add support for Anyref tables, Table.get and Table.set (for Anyref only). https://bugs.webkit.org/show_bug.cgi?id=198398 Reviewed by Saam Barati. Create a new table subtype called FuncRefTable (note: Anyfunc was renamed to Funcref in the references spec). Table now write-barriers and visits its children's wrapper objects. FuncRefTable caches some extra data to support calling from wasm. A JSWebAssemblyTable is required to set an anyref element, but this is only because we need to write barrier it (so it should not restrict how we implement threads). This patch does, however, restrict the implementation of function references to require every Ref.func to have an associated wrapper. This can be done statically, so this too should not restrict our threads implementation. * wasm/WasmAirIRGenerator.cpp: (JSC::Wasm::AirIRGenerator::addTableGet): (JSC::Wasm::AirIRGenerator::addTableSet): (JSC::Wasm::AirIRGenerator::addCallIndirect): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addLocal): (JSC::Wasm::B3IRGenerator::addTableGet): (JSC::Wasm::B3IRGenerator::addTableSet): (JSC::Wasm::B3IRGenerator::addCallIndirect): * wasm/WasmFormat.h: (JSC::Wasm::TableInformation::TableInformation): (JSC::Wasm::TableInformation::type const): * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser<Context>::parseExpression): (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression): * wasm/WasmSectionParser.cpp: (JSC::Wasm::SectionParser::parseTableHelper): * wasm/WasmTable.cpp: (JSC::Wasm::Table::Table): (JSC::Wasm::Table::tryCreate): (JSC::Wasm::Table::grow): (JSC::Wasm::Table::clear): (JSC::Wasm::Table::set): (JSC::Wasm::Table::get): (JSC::Wasm::Table::visitChildren): (JSC::Wasm::FuncRefTable::FuncRefTable): (JSC::Wasm::FuncRefTable::setFunction): (JSC::Wasm::Table::~Table): Deleted. (JSC::Wasm::Table::clearFunction): Deleted. (JSC::Wasm::Table::setFunction): Deleted. * wasm/WasmTable.h: (JSC::Wasm::Table::length const): (JSC::Wasm::Table::type const): (JSC::Wasm::Table::setOwner): (JSC::Wasm::FuncRefTable::offsetOfFunctions): (JSC::Wasm::FuncRefTable::offsetOfInstances): (JSC::Wasm::Table::offsetOfFunctions): Deleted. (JSC::Wasm::Table::offsetOfInstances): Deleted. * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::addTableGet): (JSC::Wasm::Validate::addTableSet): (JSC::Wasm::Validate::addCallIndirect): * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::JSWebAssemblyTable): (JSC::JSWebAssemblyTable::finishCreation): (JSC::JSWebAssemblyTable::visitChildren): (JSC::JSWebAssemblyTable::grow): (JSC::JSWebAssemblyTable::get): (JSC::JSWebAssemblyTable::set): (JSC::JSWebAssemblyTable::clear): (JSC::JSWebAssemblyTable::getFunction): Deleted. (JSC::JSWebAssemblyTable::clearFunction): Deleted. (JSC::JSWebAssemblyTable::setFunction): Deleted. * wasm/js/JSWebAssemblyTable.h: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::constructJSWebAssemblyTable): * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::webAssemblyTableProtoFuncGet): (JSC::webAssemblyTableProtoFuncSet): * wasm/wasm.json: 2019-06-05 Justin Michaud <justin_michaud@apple.com> WebAssembly: pow functions returns 0 when exponent 1.0 or -1.0 https://bugs.webkit.org/show_bug.cgi?id=198106 Reviewed by Saam Barati. Fix bug caused by using fcsel sX instead of fcsel dX on an f64 value in moveDoubleConditionally32. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::moveDoubleConditionally32): 2019-06-05 Alex Christensen <achristensen@webkit.org> Progress towards resurrecting Mac CMake build https://bugs.webkit.org/show_bug.cgi?id=197132 Reviewed by Don Olmstead. * API/JSScript.mm: (-[JSScript readCache]): (-[JSScript sourceCode]): (-[JSScript jsSourceCode]): (-[JSScript writeCache:]): * CMakeLists.txt: == Rolled over to ChangeLog-2019-06-05 ==