2016-09-14 Babak Shafiei Merge r205882. rdar://problem/28233331 2016-09-13 Mark Lam DFG NewArrayBuffer node should watch for "have a bad time" state change. https://bugs.webkit.org/show_bug.cgi?id=161927 Reviewed by Geoffrey Garen. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): 2016-09-13 Babak Shafiei Merge r205895. rdar://problem/28287070 2016-09-13 Michael Saboff Promises aren't resolved properly when making a ObjC API callback https://bugs.webkit.org/show_bug.cgi?id=161929 Reviewed by Geoffrey Garen. When we go to call out to an Objective C function registered via the API, we first drop all JSC locks to make the call. As part of dropping the locks, we drain the microtask queue that is used among other things for handling deferred promise resolution. The DropAllLocks scope class that drops the locks while in scope, resets the current thread's AtomicStringTable to the default table. This is wrong for two reasons, first it happens before we drain the microtask queue and second it isn't needed as JSLock::willReleaseLock() restores the current thread's AtomicStringTable to the table before the lock was acquired. In fact, the manipulation of the current thread's AtomicStringTable is already properly handled as a stack in JSLock::didAcquireLock() and willReleaseLock(). Therefore the manipulation of the AtomicStringTable in DropAllLocks constructor and destructor should be removed. * API/tests/testapi.mm: (testObjectiveCAPIMain): Added a new test. * runtime/JSLock.cpp: (JSC::JSLock::DropAllLocks::DropAllLocks): (JSC::JSLock::DropAllLocks::~DropAllLocks): 2016-09-09 Babak Shafiei Merge r204403. rdar://problem/27991568 2016-08-11 Mark Lam OverridesHasInstance should not branch across register allocations. https://bugs.webkit.org/show_bug.cgi?id=160792 Reviewed by Benjamin Poulain. The OverrideHasInstance node has a branch test that is emitted conditionally. It also has a bug where it allocated a register after this branch, which is not allowed and would fail an assertion introduced in https://trac.webkit.org/r145931. From the ChangeLog for r145931: "This [assertion that register allocations are not branched around] protects against the case where an allocation could have spilled register contents to free up a register and that spill only occurs on one path of many through the code. A subsequent fill of the spilled register may load garbage." Because the branch isn't always emitted, this bug has gone unnoticed until now. This patch fixes this issue by pre-allocating the registers before emitting the branch in OverrideHasInstance. Note: this issue is only present in DFGSpeculativeJIT64.cpp. The 32-bit version is doing it right. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2016-09-09 Babak Shafiei Merge r204485. rdar://problem/27991572 2016-08-15 Mark Lam Make JSValue::strictEqual() handle failures to resolve JSRopeStrings. https://bugs.webkit.org/show_bug.cgi?id=160832 Reviewed by Geoffrey Garen. Currently, JSValue::strictEqualSlowCaseInline() (and peers) will blindly try to access the StringImpl of a JSRopeString that fails to resolve its rope. As a result, we'll crash with null pointer dereferences. We can fix this by introducing a JSString::equal() method that will do the equality comparison, but is aware of the potential failures to resolve ropes. JSValue::strictEqualSlowCaseInline() (and peers) will now call JSString::equal() instead of accessing the underlying StringImpl directly. Also added some exception checks. * JavaScriptCore.xcodeproj/project.pbxproj: * jit/JITOperations.cpp: * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncIndexOf): (JSC::arrayProtoFuncLastIndexOf): * runtime/JSCJSValueInlines.h: (JSC::JSValue::equalSlowCaseInline): (JSC::JSValue::strictEqualSlowCaseInline): * runtime/JSString.cpp: (JSC::JSString::equalSlowCase): * runtime/JSString.h: * runtime/JSStringInlines.h: Added. (JSC::JSString::equal): 2016-09-09 Babak Shafiei Merge r203381. rdar://problem/27860536 2016-07-18 Anders Carlsson WebKit nightly fails to build on macOS Sierra https://bugs.webkit.org/show_bug.cgi?id=159902 rdar://problem/27365672 Reviewed by Tim Horton. * icu/unicode/ucurr.h: Added. Add ucurr.h from ICU. 2016-09-09 Babak Shafiei Merge r205192. rdar://problem/28097740 2016-08-30 Alex Christensen Fix WebInspectorUI in internal Windows build https://bugs.webkit.org/show_bug.cgi?id=161221 rdar://problem/28019023 Reviewed by Brent Fulgham and Joseph Pecoraro. * JavaScriptCore.vcxproj/JavaScriptCore.proj: 2016-08-30 Babak Shafiei Merge r204570. rdar://problem/27991567 2016-08-17 Mark Lam Remove an invalid assertion in the DFG backend's GetById emitter. https://bugs.webkit.org/show_bug.cgi?id=160925 Reviewed by Filip Pizlo. The DFG backend's GetById assertion that the node's prediction not be SpecNone is just plain wrong. It assumes that we can never have a GetById node without a type prediction, but this is not true. The following test case proves otherwise: function foo() { "use strict"; return --arguments["callee"]; } Will remove the assertion. Nothing else needs to change as the DFG is working correctly without the assertion. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2016-08-30 Babak Shafiei Merge r204388. rdar://problem/27991576 2016-08-11 Mark Lam The jsc shell's Element host constructor should throw if it fails to construct an object. https://bugs.webkit.org/show_bug.cgi?id=160773 Reviewed by Saam Barati. The Element object is a test object provided in the jsc shell for testing use only. JavaScriptCore expects host constructors to either throw an error or return a constructed object. Element has a host constructor that did not obey this contract. As a result, the following statement will fail a RELEASE_ASSERT: new (Element.bind()) This is now fixed. * jsc.cpp: (functionCreateElement): 2016-08-30 Babak Shafiei Merge r204362. rdar://problem/27991421 2016-08-10 Michael Saboff Baseline GetByVal and PutByVal for cache ID stubs need to handle exceptions https://bugs.webkit.org/show_bug.cgi?id=160749 Reviewed by Filip Pizlo. We were emitting "callOperation()" calls in emitGetByValWithCachedId() and emitPutByValWithCachedId() without linking the exception checks created by the code emitted. This manifested itself in various ways depending on the processor. This is due to what the destination is for an unlinked branch. On X86, an unlinked branch goes tot he next instructions. On ARM64, we end up with an infinite loop as we branch to the same instruction. On ARM we branch to 0 as the branch is to an absolute address of 0. Now we save the exception handler address for the original generated function and link the exception cases for these by-val stubs to this handler. * bytecode/ByValInfo.h: (JSC::ByValInfo::ByValInfo): Added the address of the exception handler we should link to. * jit/JIT.cpp: (JSC::JIT::link): Compute the linked exception handler address and pass it to the ByValInfo constructor. (JSC::JIT::privateCompileExceptionHandlers): Make sure that we generate the exception handler if we have any by-val handlers. * jit/JIT.h: Added a label for the exception handler. We'll link this later for the by value handlers. * jit/JITPropertyAccess.cpp: (JSC::JIT::privateCompileGetByValWithCachedId): (JSC::JIT::privateCompilePutByValWithCachedId): Link exception branches to the exception handler for the main function. 2016-08-30 Babak Shafiei Merge r204360. rdar://problem/27991577 2016-08-10 Mark Lam DFG's flushForTerminal() needs to add PhantomLocals for bytecode live locals. https://bugs.webkit.org/show_bug.cgi?id=160755 Reviewed by Filip Pizlo. If the DFG sees that an inlined function will result in an OSR exit every time, it will treat all downstream blocks as dead. However, it still needs to keep locals that are alive in the bytecode alive for the compiled function so that those locals are properly written to the stack by the OSR exit ramp. The existing code neglected to do this. This patch remedies this issue. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::flushDirect): (JSC::DFG::ByteCodeParser::addFlushOrPhantomLocal): (JSC::DFG::ByteCodeParser::phantomLocalDirect): (JSC::DFG::ByteCodeParser::flushForTerminal): 2016-08-30 Babak Shafiei Merge r203952. rdar://problem/27991571 2016-07-30 Mark Lam Assertion failure while setting the length of an ArrayClass array. https://bugs.webkit.org/show_bug.cgi?id=160381 Reviewed by Filip Pizlo. When setting large length values, we're currently treating ArrayClass as a ContiguousIndexingType array. This results in an assertion failure. This is now fixed. There are currently only 2 places where we create arrays with indexing type ArrayClass: ArrayPrototype and RuntimeArray. The fix in JSArray:;setLength() takes care of ArrayPrototype. RuntimeArray already checks for the setting of its length property, and will throw a RangeError. Hence, there's no change is needed for the RuntimeArray. Instead, I added some test cases ensure that the check and throw behavior does not change without notice. * runtime/JSArray.cpp: (JSC::JSArray::setLength): * tests/stress/array-setLength-on-ArrayClass-with-large-length.js: Added. (toString): (assertEqual): * tests/stress/array-setLength-on-ArrayClass-with-small-length.js: Added. (toString): (assertEqual): 2016-08-30 Babak Shafiei Merge r203853. rdar://problem/27991580 2016-07-28 Mark Lam ASSERTION FAILED in errorProtoFuncToString() when Error name is a single char string. https://bugs.webkit.org/show_bug.cgi?id=160324 Reviewed by Keith Miller. The issue is that errorProtoFuncToString() was using jsNontrivialString() to generate the error string even when the name string can be a single character string. This is incorrect. We should be using jsString() instead. * runtime/ErrorPrototype.cpp: (JSC::errorProtoFuncToString): * tests/stress/errors-with-simple-names-or-messages-should-not-crash-toString.js: Added. 2016-08-30 Babak Shafiei Merge r203834. rdar://problem/27991582 2016-07-28 Mark Lam StringView should have an explicit m_is8Bit field. https://bugs.webkit.org/show_bug.cgi?id=160282 Reviewed by Benjamin Poulain. * tests/stress/string-joining-long-strings-should-not-crash.js: Added. (catch): 2016-08-30 Babak Shafiei Merge r203802. rdar://problem/27991569 2016-07-27 Benjamin Poulain [JSC] Fix a bunch of use-after-free of DFG::Node https://bugs.webkit.org/show_bug.cgi?id=160228 Reviewed by Mark Lam. FTL had a few places where we use a node after it has been deleted. The dangling pointers come from the SSA liveness information kept on the basic blocks. This patch fixes the issues I could find and adds liveness invalidation to help finding dependencies like these. * dfg/DFGBasicBlock.h: (JSC::DFG::BasicBlock::SSAData::invalidate): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::run): Constant folding phase was deleting nodes in the loop over basic blocks. The problem is the deleted nodes can be referenced by other blocks. When the abstract interpreter was manipulating the abstract values of those it was doing so on the dead nodes. * dfg/DFGConstantHoistingPhase.cpp: Just invalidation. Nothing wrong here since the useless nodes were kept live while iterating the blocks. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::killBlockAndItsContents): (JSC::DFG::Graph::killUnreachableBlocks): (JSC::DFG::Graph::invalidateNodeLiveness): * dfg/DFGGraph.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): We had a lot of use-after-free in LCIM because we were using the stale live nodes deleted by previous phases. 2016-08-30 Babak Shafiei Merge r203798. rdar://problem/27991578 2016-07-27 Keith Miller concatAppendOne should allocate using the indexing type of the array if it cannot merge https://bugs.webkit.org/show_bug.cgi?id=160261 Reviewed by Mark Lam. Before, if we could not merge the indexing types for copying, we would allocate the the array as ArrayWithUndecided. Instead, we should allocate an array with the original array's indexing type. * runtime/ArrayPrototype.cpp: (JSC::concatAppendOne): * tests/stress/concat-append-one-with-sparse-array.js: Added. 2016-08-17 Babak Shafiei Merge r204572. rdar://problem/27889416 2016-08-17 Geoffrey Garen Fixed a potential bug in MarkedArgumentBuffer. https://bugs.webkit.org/show_bug.cgi?id=160948 Reviewed by Oliver Hunt. I haven't been able to produce an observable test case after some trying. * runtime/ArgList.cpp: (JSC::MarkedArgumentBuffer::addMarkSet): New helper function -- I broke this out from existing code for clarity, but the behavior is the same. (JSC::MarkedArgumentBuffer::expandCapacity): Ditto. (JSC::MarkedArgumentBuffer::slowAppend): Always addMarkSet() on the slow path. This is faster than the old linear scan, and I think it might avoid cases the old scan could miss. * runtime/ArgList.h: (JSC::MarkedArgumentBuffer::append): Account for the case where someone has called clear() or removeLast(). (JSC::MarkedArgumentBuffer::mallocBase): No behavior change -- but it's clearer to test the buffers directly instead of inferring what they might be based on capacity. 2016-08-11 Keith Miller Merge r203972. 2016-08-01 Keith Miller We should not keep the JavaScript tests inside the Source/JavaScriptCore/ directory. https://bugs.webkit.org/show_bug.cgi?id=160372 Rubber stamped by Geoffrey Garen. This patch moves all the JavaScript tests from Source/JavaScriptCore/tests to a new top level directory, JSTests. Having the tests in the Source directory was both confusing an inconvenient for people that just want to checkout the source code of WebKit. Since there is no other obvious place to put all the JavaScript tests a new top level directory seemed the most sensible. * tests/: Deleted. 2016-07-31 Yusuke Suzuki Merge r204010. rdar://problem/27534844 2016-08-01 Filip Pizlo REGRESSION (r203990): JSC Debug test stress/arity-check-ftl-throw.js failing https://bugs.webkit.org/show_bug.cgi?id=160438 Reviewed by Mark Lam. In r203990 I fixed a bug where CommonSlowPaths.h/arityCheckFor() was basically failing at catching stack overflow due to large parameter count. It would only catch regular old stack overflow, like if the frame pointer was already past the limit. This had a secondary problem: unfortunately all of our tests for what happens when you overflow the stack due to large parameter count were not going down that path at all, so we haven't had test coverage for this in ages. There were bugs in all tiers of the engine when handling this case. We need to be able to roll back the topCallFrame on paths that are meant to throw an exception from the caller. Otherwise, we'd crash in StackVisitor because it would see a busted stack frame. Rolling back like this "just works" except when the caller is the VM entry frame. I had some choices here. I could have forced anyone who is rolling back to always skip VM entry frames. They can't do it in a way that changes the value of VM::topVMEntryFrame, which is what a stack frame roll back normally does, since exception unwinding needs to see the current value of topVMEntryFrame. So, we have a choice to either try to magically avoid all of the paths that look at topCallFrame, or give topCallFrame a state that unambiguously signals that we are sitting right on top of a VM entry frame without having succeeded at making a JS call. The only place that really needs to know is StackVisitor, which wants to start scanning at topCallFrame. To signal this, I could have either made topCallFrame point to the real top JS call frame without also rolling back topVMEntryFrame, or I could make topCallFrame == topVMEntryFrame. The latter felt somehow cleaner. I filed a bug (https://bugs.webkit.org/show_bug.cgi?id=160441) for converting topCallFrame to a void*, which would give us a chance to harden the rest of the engine against this case. * interpreter/StackVisitor.cpp: (JSC::StackVisitor::StackVisitor): We may do ShadowChicken processing, which invokes StackVisitor, when we have topCallFrame pointing at topVMEntryFrame. This teaches StackVisitor how to handle this case. I believe that StackVisitor is the only place that needs to be taught about this at this time, because it's one of the few things that access topCallFrame along this special path. * jit/JITOperations.cpp: Roll back the top call frame. * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): Roll back the top call frame. 2016-08-01 Babak Shafiei Merge r203990. rdar://problem/27534844 2016-08-01 Filip Pizlo Rationalize varargs stack overflow checks https://bugs.webkit.org/show_bug.cgi?id=160425 Reviewed by Michael Saboff. * ftl/FTLLink.cpp: (JSC::FTL::link): AboveOrEqual 0 is a tautology. The code meant GreaterThanOrEqual, since the error code is -1. * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::arityCheckFor): Use roundUpToMultipleOf(), which is almost certainly what we meant when we said %. 2016-07-28 Babak Shafiei Merge r203851. rdar://problem/27299339 2016-07-28 Michael Saboff ARM64: Fused left shift with a right shift can create NaNs from integers https://bugs.webkit.org/show_bug.cgi?id=160329 Reviewed by Geoffrey Garen. When we fuse a left shift and a right shift of integers where the shift amounts are the same and the size of the quantity being shifted is 8 bits, we rightly generate a sign extend byte instruction. On ARM64, we were sign extending to a 64 bit quantity, when we really wanted to sign extend to a 32 bit quantity. Checking the ARM64 marco assembler and we were extending to 64 bits for all four combinations of zero / sign and 8 / 16 bits. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::zeroExtend16To32): (JSC::MacroAssemblerARM64::signExtend16To32): (JSC::MacroAssemblerARM64::zeroExtend8To32): (JSC::MacroAssemblerARM64::signExtend8To32): * tests/stress/regress-160329.js: New test added. (narrow): 2016-07-28 Babak Shafiei Merge r203793. rdar://problem/27572612 2016-07-27 Saam Barati We don't optimize for-in properly in baseline JIT (maybe other JITs too) with an object with symbols https://bugs.webkit.org/show_bug.cgi?id=160211 Reviewed by Geoffrey Garen. The fast for-in iteration mode assumes all inline/out-of-line properties can be iterated in linear order. This is not true if we have Symbols because Symbols should not be iterated by for-in. * runtime/Structure.cpp: (JSC::Structure::add): * tests/stress/symbol-should-not-break-for-in.js: Added. (assert): (foo): 2016-07-28 Babak Shafiei Merge r203790. rdar://problem/27328525 2016-07-27 Mark Lam The second argument for Function.prototype.apply should be array-like or null/undefined. https://bugs.webkit.org/show_bug.cgi?id=160212 Reviewed by Filip Pizlo. The spec for Function.prototype.apply says its second argument can only be null, undefined, or must be array-like. See https://tc39.github.io/ecma262/#sec-function.prototype.apply and https://tc39.github.io/ecma262/#sec-createlistfromarraylike. Our previous implementation was not handling this correctly for SymbolType. This is now fixed. * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): * tests/stress/apply-second-argument-must-be-array-like.js: Added. 2016-07-22 Babak Shafiei Merge r203488. rdar://problem/27439330 2016-07-20 Filip Pizlo FTL snippet generators should be able to request a different register for output and input https://bugs.webkit.org/show_bug.cgi?id=160010 rdar://problem/27439330 Reviewed by Saam Barati. The BitOr and BitXor snippet generators have problems if the register for the right input is the same as the register for the result. We could fix those generators, but I'm not convinced that the other snippet generators don't have this bug. So, the approach that this patch takes is to teach the FTL to request that B3 to use a different register for the result than for any input to the snippet patchpoint. Air already has the ability to let any instruction do an EarlyDef, which means exactly this. But B3 did not expose this via ValueRep. This patch exposes this in ValueRep as SomeEarlyRegister. That's most of the change. This adds a testb3 test for SomeEarlyRegister and a regression test for this particular problem. The regression test failed on trunk JSC before this. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::lower): * b3/B3PatchpointSpecial.cpp: (JSC::B3::PatchpointSpecial::forEachArg): (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): (JSC::B3::ValueRep::dump): (WTF::printInternal): * b3/B3ValueRep.h: (JSC::B3::ValueRep::ValueRep): (JSC::B3::ValueRep::reg): (JSC::B3::ValueRep::isAny): (JSC::B3::ValueRep::isReg): (JSC::B3::ValueRep::isSomeRegister): Deleted. * b3/testb3.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet): (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet): (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet): * tests/stress/ftl-bit-xor-right-result-interference.js: Added. 2016-07-19 Babak Shafiei Merge r203419. 2016-07-19 Anders Carlsson WebCore-7602.1.42 fails to build: error: private field 'm_vm' is not used https://bugs.webkit.org/show_bug.cgi?id=159944 rdar://problem/27420308 Reviewed by Dan Bernstein. Wrap the m_vm declaration and initialization in conditional guards. * Scripts/builtins/builtins_generate_internals_wrapper_header.py: (generate_members): * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py: (BuiltinsInternalsWrapperImplementationGenerator.generate_constructor): Add guards. * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Update expected results. 2016-07-18 Babak Shafiei Merge r203351. 2016-07-18 Keith Miller Fix bad assertions in genericTypedArrayViewPrivateFuncSubarrayCreate https://bugs.webkit.org/show_bug.cgi?id=159882 Reviewed by Mark Lam. According the spec toInteger can return values we don't consider ints. Such as, -0 and +/-Infinity. This broke some assertions in genericTypedArrayViewPrivateFuncSubarrayCreate. * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate): * tests/stress/typedarray-subarray.js: 2016-07-18 Babak Shafiei Merge patch for rdar://problem/27360961. 2016-06-23 Dean Jackson Disable some features on safari-602-branch. * Configurations/FeatureDefines.xcconfig: 2016-07-18 Babak Shafiei Merge r203353. 2016-07-18 Youenn Fablet REGRESSION(r202975): --minimal build is broken https://bugs.webkit.org/show_bug.cgi?id=159765 Reviewed by Chris Dumez. Covered partially by builtin generated test code. Updating generator to add a global compilation guard around the code that generates all global internal properties. Split the generate_methods function in two, one dedicated to the visit method and the second one dedicated to the initialize method. * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py: (BuiltinsInternalsWrapperImplementationGenerator.generate_section_for_object): Use splitted generation functions. (BuiltinsInternalsWrapperImplementationGenerator.generate_visit_method): Response to generate the visit method. (BuiltinsInternalsWrapperImplementationGenerator._generate_initialize_static_globals): Responsible to generate the code to initialize the internal globals. This code is put in a global compilation guard in case all internals are compiled out by specific builds. (BuiltinsInternalsWrapperImplementationGenerator): (BuiltinsInternalsWrapperImplementationGenerator.generate_initialize_method): Responsible to generate the initialize method. (BuiltinsInternalsWrapperImplementationGenerator.generate_methods): Deleted. * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Copyright change. * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto. * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto. * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto. * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Reflects partially the built-in generator change. 2016-07-16 Filip Pizlo DFG CSE is broken for MultiGetByOffset https://bugs.webkit.org/show_bug.cgi?id=159858 Reviewed by Saam Barati. This disabled CSE for MultiGetByOffset. I opened bug 159859 for the long-term fix, which would teach CSE (and other passes also) how to decay a removed MultiGetByOffset to a CheckStructure. Since we currently just decay MultiGetByOffset to Check, we forget the structure checks. So, if we CSE a MultiGetByOffset that checks for one set of structures with a heap access on the same property and base that checks for different structures, then we will forget some structure checks that we had previously. It's unsound to forget checks in DFG IR. This bug mostly manifested as a high-volume crash at Unreachable in FTL, because we'd prove that the code after the MultiGetByOffset was unreachable due to the structure checks and then CSE would remove everything but the Unreachable. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): Remove the def() for MultiGetByOffset to disable CSE for this node for now. * tests/stress/cse-multi-get-by-offset-remove-checks.js: Added. This used to fail with FTL enabled. (Cons1): (Cons2): (Cons3): (foo): (bar): 2016-07-17 Yusuke Suzuki [JSC] Enable test262 module tests https://bugs.webkit.org/show_bug.cgi?id=159854 Reviewed by Saam Barati. This patch enables test262 module tests. Before this patch, the modules tests in test262 do not work fine. This patch fixes the following 2 things. 1. Test harness Before this patch, there is only one global switch "-m" in jsc shell. So we cannot load the test262 test harness before evaluating the module tests. This patch adds a new option, "--module-file=". It is similar to "--strict-file=". When we specify the file with "--module-file=", it is evaluated as a module, while the other files are evaluated by following the JSC's default manner. This option allows us to load the test harness files into the global context before loading the module tests. 2. Module's asynchronous errors Before this patch, the errors caused in the module evaluation are not handled as the same to the usual sync files. In synchronous execution, we have "--exception=" option to pass the expected exception to the JSC shell. But this option does not work in the module evaluation. This patch correctly handles this expected exception in the module evaluation promise's fulfill and reject handlers. And we fix the YAML file. Now the recorded :fail and :normal are the correct test results for the module tests. * jsc.cpp: (Script::Script): (checkUncaughtException): (runWithScripts): (printUsageStatement): (CommandLine::parseArguments): (dumpException): Deleted. * tests/test262.yaml: 2016-07-17 Yusuke Suzuki [JSC] Mask TrustedImm32 to 8bit in MacroAssembler for 8bit operations https://bugs.webkit.org/show_bug.cgi?id=159334 Reviewed by Filip Pizlo. Previously, in 8bit operations (like add8, compare8, test8, branch8, branchTest8 etc.), we require that the given TrustedImm32 is in range of 8bit. While achieving this in the manual MacroAssembler calling is easy, in Air, we don't guarantee that the higher bit of the 8bit argument is cleared. So the current assertions are invalid. This patch relaxes the above restriction. By removing this assertion, 8bit operations can take arbitrary 32bit imms. And only lower 8bit are effective when emitting the code in these methods. * assembler/MacroAssembler.h: (JSC::MacroAssembler::branchTest8): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::store8): (JSC::MacroAssemblerARM::branch8): (JSC::MacroAssemblerARM::branchTest8): (JSC::MacroAssemblerARM::compare8): (JSC::MacroAssemblerARM::test8): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::store8): (JSC::MacroAssemblerARM64::branch8): (JSC::MacroAssemblerARM64::branchTest8): (JSC::MacroAssemblerARM64::compare8): (JSC::MacroAssemblerARM64::test8): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::store8): (JSC::MacroAssemblerARMv7::branch8): (JSC::MacroAssemblerARMv7::branchTest8): (JSC::MacroAssemblerARMv7::compare8): (JSC::MacroAssemblerARMv7::test8): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::store8): (JSC::MacroAssemblerMIPS::branch8): (JSC::MacroAssemblerMIPS::compare8): (JSC::MacroAssemblerMIPS::branchTest8): (JSC::MacroAssemblerMIPS::test8): * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::store8): (JSC::MacroAssemblerSH4::branchTest8): (JSC::MacroAssemblerSH4::branch8): (JSC::MacroAssemblerSH4::compare8): (JSC::MacroAssemblerSH4::test8): * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::store8): (JSC::MacroAssemblerX86::branch8): (JSC::MacroAssemblerX86::branchTest8): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::add8): (JSC::MacroAssemblerX86Common::store8): (JSC::MacroAssemblerX86Common::branch8): (JSC::MacroAssemblerX86Common::branchTest8): (JSC::MacroAssemblerX86Common::compare8): (JSC::MacroAssemblerX86Common::test8): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::store8): (JSC::MacroAssemblerX86_64::branch8): (JSC::MacroAssemblerX86_64::branchTest8): 2016-07-16 Chris Dumez Unreviewed, rolling out r203318. Regressed most JS Benchmarks on MacBook Air by ~2% (7% on SunSpider) Reverted changeset: "[JSC] Change some parameters based on a random search" https://bugs.webkit.org/show_bug.cgi?id=158514 http://trac.webkit.org/changeset/203318 2016-07-15 Benjamin Poulain [JSC] Convert the remaining createOutOfMemoryError()+throwException() into throwOutOfMemoryError() https://bugs.webkit.org/show_bug.cgi?id=159665 Reviewed by Saam Barati. * API/JSTypedArray.cpp: (createTypedArray): * runtime/Error.cpp: (JSC::createOutOfMemoryError): * runtime/Error.h: * runtime/ExceptionHelpers.cpp: (JSC::throwOutOfMemoryError): * runtime/JSArrayBufferConstructor.cpp: (JSC::constructArrayBuffer): * runtime/JSArrayBufferPrototype.cpp: (JSC::arrayBufferProtoFuncSlice): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::create): (JSC::JSGenericTypedArrayView::createUninitialized): 2016-07-15 Benjamin Poulain [JSC] Change some parameters based on a random search https://bugs.webkit.org/show_bug.cgi?id=158514 Reviewed by Saam Barati. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::optimizationThresholdScalingFactor): * runtime/Options.h: 2016-07-15 Mark Lam Assertion failures and crashes with missing TDZ checks for catch-node bindings. https://bugs.webkit.org/show_bug.cgi?id=158797 Reviewed by Saam Barati. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitPushCatchScope): (JSC::BytecodeGenerator::emitPopCatchScope): * tests/stress/catch-clause-should-be-under-tdz1.js: Added. * tests/stress/catch-clause-should-be-under-tdz2.js: Added. * tests/stress/catch-clause-should-be-under-tdz3.js: Added. * tests/stress/catch-clause-should-be-under-tdz4.js: Added. * tests/stress/catch-clause-should-be-under-tdz5.js: Added. 2016-07-15 Geoffrey Garen Added a makeRef helper https://bugs.webkit.org/show_bug.cgi?id=159835 Reviewed by Andreas Kling. Anders told me to! * inspector/InjectedScriptHost.cpp: (Inspector::InjectedScriptHost::wrapper): 2016-07-15 Mark Lam FunctionOverride's parseClause() needs to keep the CString instance in scope while its data is being used. https://bugs.webkit.org/show_bug.cgi?id=159828 Reviewed by Saam Barati. Otherwise, we'll have a use after free. This issue was caught when running an ASan debug build of testapi. * tools/FunctionOverrides.cpp: (JSC::parseClause): 2016-07-15 Keith Miller %TypedArray%.prototype.indexOf is coercing non-integers or non-floats to numbers wrongly https://bugs.webkit.org/show_bug.cgi?id=159400 Reviewed by Geoffrey Garen. This patch fixes coercion of non-numbers in indexOf/lastIndexOf. Additionally, this patch fixes an issue with includes where it would not check that the buffer remained non-neutered after calling the toInteger() function. Lastly, some extra release asserts have been added in some places to inform us of any issues in the future. Additionally, this patch changes bool toNativeFromDouble to Optional toNativeFromDoubleWithoutCoercion. This makes it a little clearer what the function does and also removes the return argument. The only behavior change is that the function no longer coerces non-numbers into numbers. That behavior was unused (maybe unintended), however. * runtime/JSGenericTypedArrayView.h: (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValueWithoutCoercion): (JSC::JSGenericTypedArrayView::sort): (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue): Deleted. * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncCopyWithin): (JSC::genericTypedArrayViewProtoFuncIncludes): (JSC::genericTypedArrayViewProtoFuncIndexOf): (JSC::genericTypedArrayViewProtoFuncLastIndexOf): * runtime/ToNativeFromValue.h: (JSC::toNativeFromValueWithoutCoercion): (JSC::toNativeFromValue): Deleted. * runtime/TypedArrayAdaptors.h: (JSC::IntegralTypedArrayAdaptor::toNativeFromInt32WithoutCoercion): (JSC::IntegralTypedArrayAdaptor::toNativeFromUint32WithoutCoercion): (JSC::IntegralTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion): (JSC::FloatTypedArrayAdaptor::toNativeFromInt32WithoutCoercion): (JSC::FloatTypedArrayAdaptor::toNativeFromDoubleWithoutCoercion): (JSC::Uint8ClampedAdaptor::toNativeFromInt32WithoutCoercion): (JSC::Uint8ClampedAdaptor::toNativeFromDoubleWithoutCoercion): (JSC::IntegralTypedArrayAdaptor::toNativeFromInt32): Deleted. (JSC::IntegralTypedArrayAdaptor::toNativeFromUint32): Deleted. (JSC::IntegralTypedArrayAdaptor::toNativeFromDouble): Deleted. (JSC::FloatTypedArrayAdaptor::toNativeFromInt32): Deleted. (JSC::FloatTypedArrayAdaptor::toNativeFromDouble): Deleted. (JSC::Uint8ClampedAdaptor::toNativeFromInt32): Deleted. (JSC::Uint8ClampedAdaptor::toNativeFromDouble): Deleted. * tests/stress/resources/typedarray-test-helper-functions.js: * tests/stress/typedarray-functions-with-neutered.js: (callWithArgs): * tests/stress/typedarray-includes.js: Added. * tests/stress/typedarray-indexOf.js: * tests/stress/typedarray-lastIndexOf.js: 2016-07-15 Csaba Osztrogonác Add new functions to ARMAssembler after r202214 https://bugs.webkit.org/show_bug.cgi?id=159713 Reviewed by Saam Barati. * assembler/ARMAssembler.h: (JSC::ARMAssembler::fillNops): * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::patchableBranch32): (JSC::MacroAssemblerARM::internalCompare32): 2016-07-15 Mark Lam Stack overflow error for deeply nested classes. https://bugs.webkit.org/show_bug.cgi?id=157086 Reviewed by Geoffrey Garen. Changed the StructureStubClearingWatchpoint destructor to iteratively destruct its chain of next StructureStubClearingWatchpoints instead of recursively doing so. The added deep-StructureStubClearingWatchpoint-destructor-recursion.js test produces a crash before the fix is applied, but takes about 14 minutes to run. Hence, it is skipped. * bytecode/StructureStubClearingWatchpoint.cpp: (JSC::StructureStubClearingWatchpoint::~StructureStubClearingWatchpoint): * tests/stress/deep-StructureStubClearingWatchpoint-destructor-recursion.js: Added. 2016-07-15 Csaba Osztrogonác Fix expectations in test262.yaml https://bugs.webkit.org/show_bug.cgi?id=159810 Reviewed by Keith Miller. * tests/test262.yaml: 2016-07-15 Csaba Osztrogonác [ARM] Disable Inline Caching on ARMv7 traditional until proper fix https://bugs.webkit.org/show_bug.cgi?id=159759 Reviewed by Saam Barati. * jit/Repatch.cpp: (JSC::forceICFailure): 2016-07-14 Keith Miller Add Test262 test files and yaml Rubber Stamped by Benjamin Poulain. This patch adds all the test262 test files and the yaml that drives run-jsc-stress-tests. * tests/test262.yaml: Added. Yaml file to drive the test262 test suite with our driver. * tests/test262/LICENSE: Added. License for the test262 test suite. * tests/test262/harness/: Added. Harness directory for the test262 tests. * tests/test262/test/: Added. Directory with all the actual test files. 2016-07-14 Joseph Pecoraro Return the correct value from Heap::externalMemorySize https://bugs.webkit.org/show_bug.cgi?id=159797 Reviewed by Timothy Hatcher. * heap/Heap.h: (JSC::Heap::externalMemorySize): We should have been returning m_externalMemorySize which is a subset of m_extraMemorySize. In practice the difference can be small. A major difference in "extra memory size" may be from deprecated memory size and array buffer sizes. 2016-07-14 Saam Barati It should be a syntax error to have a 'use strict' directive inside a function that has a non-simple parameter list https://bugs.webkit.org/show_bug.cgi?id=159790 Reviewed by Geoffrey Garen. Is is a syntax error for a function's parameter list to be non-simple and for the function to also contain a 'use strict' directive. See section 14.2.1 of the spec: https://tc39.github.io/ecma262/#sec-arrow-function-definitions-static-semantics-early-errors * parser/Parser.cpp: (JSC::Parser::parseSourceElements): (JSC::Parser::parseFormalParameters): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::strictMode): (JSC::Scope::isValidStrictMode): (JSC::Scope::shadowsArguments): (JSC::Scope::setHasNonSimpleParameterList): (JSC::Scope::hasNonSimpleParameterList): (JSC::Scope::copyCapturedVariablesToVector): 2016-07-14 Geoffrey Garen ASSERTION FAILED: : this != replacement() https://bugs.webkit.org/show_bug.cgi?id=159779 Reviewed by Michael Saboff. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::jettison): If we jettison during GC, and our owner is dead, we choose not to replace ourselves. (See https://bugs.webkit.org/show_bug.cgi?id=159588.) So, it's possible to invalidate and still be our owner's CodeBlock. Relax our ASSERT to allow for this. 2016-07-14 Mark Lam JSONObject Walker::walk must save array length before processing array elements. https://bugs.webkit.org/show_bug.cgi?id=153485 Reviewed by Darin Adler and Michael Saboff. According to https://tc39.github.io/ecma262/#sec-internalizejsonproperty, JSON.parse() should cache the length of an array and use the cached length when iterating array elements (see section 24.3.1.1 2.b.iii). * runtime/JSONObject.cpp: (JSC::Walker::walk): * tests/stress/JSON-parse-should-cache-array-lengths.js: Added. (toString): (shouldBe): (test): (test2): 2016-07-14 Julien Brianceau [mips] Handle properly unaligned halfword load https://bugs.webkit.org/show_bug.cgi?id=153226 Reviewed by Michael Catanzaro. Waiting for the kernel to silently fix-up unaligned accesses is not efficient, so let's provide an implementation of load16Unaligned in mips macro assembler. Performance improvement seen with SunSpider's regexp-dna test. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::load16Unaligned): (JSC::MacroAssemblerMIPS::load32WithUnalignedHalfWords): 2016-07-14 Youenn Fablet DOM value iterable interfaces should use Array prototype methods https://bugs.webkit.org/show_bug.cgi?id=159296 Reviewed by Chris Dumez and Mark Lam. * JavaScriptCore.xcodeproj/project.pbxproj: Marking some header files as private so that they can be included in WebCore. * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): copying iterable methods (entries, forEach, keys and values) to private slots. 2016-07-13 Csaba Osztrogonác Fix the magic numbers for ARM traditional in InlineAccess.h https://bugs.webkit.org/show_bug.cgi?id=159708 Reviewed by Saam Barati. * bytecode/InlineAccess.h: (JSC::InlineAccess::sizeForPropertyAccess): (JSC::InlineAccess::sizeForPropertyReplace): (JSC::InlineAccess::sizeForLengthAccess): 2016-07-13 Michael Saboff YARR uses mixture of int and unsigned values to index into subject string https://bugs.webkit.org/show_bug.cgi?id=159744 Reviewed by Benjamin Poulain. In most cases, we refer to characters in subject strings using a negative index from the number of "checked" characters in a subject string. The required length is compared against the actual length and then we use that required length as the checked amount. For example, when matching the string of 4 digits in the RegExp /abc \d{4}/, we know that need 8 characters in the subject string. We refer to the digits part of the expression from an already checked index of 8 and use negative offsets of -4 through -1. In many cases we used a signed int for the negative offsets. There are other cases where we used unsigned values as the amount of negative offset to use when accessing subject characters. Changed all occurrances of character offsets to unsigned or Checked Arithmetic unsigned values. Note that the pre-existing Checked class is used in other places to check for under/overflow with arithmetic operations. Those unsigned offsets are always the number of characters before (negative) from the current checked character offset. Also added some asserts for cases where arithmetic is not protected by other checks or with Checked<> wrapped values. In the case of the JIT, subject characters are accessed using base with scaled index and offset addressing. The MacroAssembler provides this addressing using the BaseIndex struct. The offset for this struct is a 32 bit signed quantity. Since we only care about negative offsets, we really only have 31 bits. Changed the generation of a BaseOffset address to handle the case when the offset and scaled combination will exceed the 31 bits of negative offset. This is done by moving the base value into a temp register and biasing the temp base and offset to smaller values so that we can emit instructions that can reference characters without exceeding the 31 bits of negative offset. To abstract the character address generation, put the base with scaled index and offset into one function and used that function everywhere the YARR JIT wants to access subject characters. Also consilidated a few cases where we were generating inline what readCharacter() does. Usually this was due to using a different index register. Added a new regression test. * tests/stress/regress-159744.js: Added regression test. (testRegExp): * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::recordParenthesesMatch): (JSC::Yarr::Interpreter::resetMatches): (JSC::Yarr::Interpreter::matchParenthesesOnceEnd): (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd): (JSC::Yarr::ByteCompiler::closeBodyAlternative): (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd): (JSC::Yarr::ByteCompiler::atomParenthesesOnceEnd): (JSC::Yarr::ByteCompiler::atomParenthesesTerminalEnd): (JSC::Yarr::ByteCompiler::emitDisjunction): * yarr/YarrInterpreter.h: (JSC::Yarr::ByteTerm::ByteTerm): (JSC::Yarr::ByteTerm::BOL): (JSC::Yarr::ByteTerm::UncheckInput): (JSC::Yarr::ByteTerm::EOL): (JSC::Yarr::ByteTerm::WordBoundary): (JSC::Yarr::ByteTerm::BackReference): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::notAtEndOfInput): (JSC::Yarr::YarrGenerator::negativeOffsetIndexedAddress): (JSC::Yarr::YarrGenerator::readCharacter): (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals): (JSC::Yarr::YarrGenerator::storeToFrame): (JSC::Yarr::YarrGenerator::generateAssertionBOL): (JSC::Yarr::YarrGenerator::backtrackAssertionBOL): (JSC::Yarr::YarrGenerator::generateAssertionEOL): (JSC::Yarr::YarrGenerator::matchAssertionWordchar): (JSC::Yarr::YarrGenerator::generateAssertionWordBoundary): (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce): (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed): (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy): (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy): (JSC::Yarr::YarrGenerator::generateCharacterClassOnce): (JSC::Yarr::YarrGenerator::generateCharacterClassFixed): (JSC::Yarr::YarrGenerator::generateCharacterClassGreedy): (JSC::Yarr::YarrGenerator::backtrackCharacterClassNonGreedy): (JSC::Yarr::YarrGenerator::generate): (JSC::Yarr::YarrGenerator::backtrack): (JSC::Yarr::YarrGenerator::YarrGenerator): * yarr/YarrPattern.h: (JSC::Yarr::PatternTerm::PatternTerm): 2016-07-13 Keith Miller Crashes with detached ArrayBuffers https://bugs.webkit.org/show_bug.cgi?id=157088 Reviewed by Filip Pizlo. TypedArray.prototype.fill was incorrect because it should perform ToNumber coercion each time it tries to store the object. Currently, we only perform the coercion once at the beginning of the loop. If we find that we need to improve the performance of this function, we can add a faster C++ path back that only handles the primitive case. This patch also moves the isNeutered() checks from put and putByIndex into setIndex. This fixes an issue where setIndex might store to a no longer valid offset. * builtins/TypedArrayPrototype.js: (globalPrivate.typedArrayClampArgumentToStartOrEnd): (fill): * runtime/JSGenericTypedArrayView.h: (JSC::JSGenericTypedArrayView::setIndexQuickly): (JSC::JSGenericTypedArrayView::setIndex): (JSC::JSGenericTypedArrayView::setRangeToValue): Deleted. * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::put): Deleted. (JSC::JSGenericTypedArrayView::putByIndex): Deleted. * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncFill): Deleted. * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): (JSC::typedArrayViewProtoFuncFill): Deleted. * tests/stress/typedarray-fill.js: * tests/stress/typedarray-functions-with-neutered.js: (defaultForArg): (test2): (checkArgumentsForType): Deleted. (checkArguments): Deleted. 2016-07-13 Michael Saboff Some bad unicode regex escapes aren't flagged as errors https://bugs.webkit.org/show_bug.cgi?id=158080 Reviewed by Saam Barati. If we have a partial unicode escape, eg /\u{1/u or /\u12|abc/u, we didn't check for the closing '}' and processed the unicode escape with the hex value provided. Added a check that we properly terminated a \u{} unicode escape. If we fail that check and there isn't a prior error, we record that we have an invalid unicode escape. The next existing line in the code will terminate parsing and bubble up the error. * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): 2016-07-13 Chris Dumez Unreviewed, rolling out r203199. Broke the build Reverted changeset: "Crashes with detached ArrayBuffers" https://bugs.webkit.org/show_bug.cgi?id=157088 http://trac.webkit.org/changeset/203199 2016-07-13 Keith Miller Crashes with detached ArrayBuffers https://bugs.webkit.org/show_bug.cgi?id=157088 Reviewed by Filip Pizlo. TypedArray.prototype.fill was incorrect because it should perform ToNumber coercion each time it tries to store the object. Currently, we only perform the coercion once at the beginning of the loop. If we find that we need to improve the performance of this function, we can add a faster C++ path back that only handles the primitive case. This patch also moves the isNeutered() checks from put and putByIndex into setIndex. This fixes an issue where setIndex might store to a no longer valid offset. * builtins/TypedArrayPrototype.js: (globalPrivate.typedArrayClampArgumentToStartOrEnd): (fill): * runtime/JSGenericTypedArrayView.h: (JSC::JSGenericTypedArrayView::setIndexQuickly): (JSC::JSGenericTypedArrayView::setIndex): (JSC::JSGenericTypedArrayView::setRangeToValue): Deleted. * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::put): Deleted. (JSC::JSGenericTypedArrayView::putByIndex): Deleted. * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncFill): Deleted. * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): (JSC::typedArrayViewProtoFuncFill): Deleted. * tests/stress/typedarray-fill.js: * tests/stress/typedarray-functions-with-neutered.js: (defaultForArg): (test2): (checkArgumentsForType): Deleted. (checkArguments): Deleted. 2016-07-13 Enrica Casucci Update supported platforms in xcconfig files to match the sdk names. https://bugs.webkit.org/show_bug.cgi?id=159728 Reviewed by Tim Horton. * Configurations/Base.xcconfig: 2016-07-13 Csaba Osztrogonác CLoop buildfix after r203142 https://bugs.webkit.org/show_bug.cgi?id=159706 Unreviewed buildfix. * interpreter/CLoopStack.cpp: (JSC::CLoopStack::isSafeToRecurse): * interpreter/CLoopStack.h: * interpreter/CLoopStackInlines.h: (JSC::CLoopStack::isSafeToRecurse): Deleted. 2016-07-12 Benjamin Poulain [JSC] Array.prototype.join() fails some conformance tests https://bugs.webkit.org/show_bug.cgi?id=159657 Reviewed by Saam Barati. There were a couple of failures: -separator.toString() was called *before* we get the length and process ToLength() on it. -We were using toUInt32() on length instead of ToLength(), failing on big integers and various negative numbers. Additionally, I replaced the "fast" ArrayStorage path by a fully generic implementation that does not depends on StringJoiner. The reason is StringJoiner was doing poorly on sparse objects in certain cases. If you have a sparse object with a length > INT_MAX but very few indices defined, and you join on the empty string, it should be possible to join the array (albeit very slowly). With StringJoiner, we fail because we try to allocate > INT_MAX empty strings in a contiguous vector. * runtime/ArrayPrototype.cpp: (JSC::slowJoin): (JSC::canUseFastJoin): (JSC::fastJoin): (JSC::arrayProtoFuncJoin): (JSC::join): Deleted. * runtime/JSArray.h: (JSC::toLength): 2016-07-12 Mark Lam Gardening: C Loop build fix after r203142. Not reviewed. * interpreter/CLoopStackInlines.h: (JSC::CLoopStack::isSafeToRecurse): 2016-07-12 Commit Queue Unreviewed, rolling out r203131. https://bugs.webkit.org/show_bug.cgi?id=159698 This change caused an existing LayoutTest to time out on debug testers (Requested by ryanhaddad on #webkit). Reverted changeset: "[JSC] Array.prototype.join() fails some conformance tests" https://bugs.webkit.org/show_bug.cgi?id=159657 http://trac.webkit.org/changeset/203131 2016-07-12 Mark Lam We should use different stack limits for stack checks from JS and host code. https://bugs.webkit.org/show_bug.cgi?id=159442 Reviewed by Geoffrey Garen. We have 2 stack reservedZoneSizes: 1. Options::softReservedZoneSize() 2. Options::reservedZoneSize() Respectively, there are used to define 2 stack limits based on these reserved zone sizes: 1. VM::m_softStackLimit 2. VM::m_stackLimit Options::reservedZoneSize() is the amount of the stack space that JSC guarantees to the VM and client host code for it's use. Host code that has well known stack usage characteristics (i.e. doesn't call arbitrary code) may do stack checks against the VM::m_stackLimit limit (which is computed using Options::reservedZoneSize()). Options::softReservedZoneSize() is a more conservative amount of reserved stack space. This is used to compute the VM::m_softStackLimit limit. Any code that is difficult to have its stack usage characterized (i.e. may call arbitrary code) may need more stack space for its work. Hence, these should do stack checks against the VM::m_softStackLimit limit. JS code and host code that may call into JS code falls into the category of code that may call arbitrary code. Hence, they should do stack checks against the VM::m_softStackLimit limit. Accordingly, the VM now provides 2 recursion check functions: 1. VM::isSafeToRecurseSoft() will do a stack check against VM::m_softStackLimit. In addition, for C Loop builds, VM::isSafeToRecurseSoft() will also check the CLoopStack against VM::m_cloopStackLimit. 2. VM::isSafeToRecurse() will do a stack check against VM::m_stackLimit. Also added a promise-infinite-recursion-should-not-crash.js test. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitNodeInTailPosition): (JSC::BytecodeGenerator::emitNodeInConditionContext): * interpreter/CLoopStack.cpp: (JSC::CLoopStack::grow): * interpreter/CLoopStack.h: (JSC::CLoopStack::size): * interpreter/CLoopStackInlines.h: (JSC::CLoopStack::ensureCapacityFor): (JSC::CLoopStack::isSafeToRecurse): (JSC::CLoopStack::topOfFrameFor): * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * parser/Parser.cpp: * runtime/Options.h: * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::getOwnPropertySlotCommon): (JSC::ProxyObject::performPut): (JSC::performProxyCall): (JSC::performProxyConstruct): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::performPreventExtensions): (JSC::ProxyObject::performIsExtensible): (JSC::ProxyObject::performDefineOwnProperty): (JSC::ProxyObject::performGetOwnPropertyNames): (JSC::ProxyObject::performSetPrototype): (JSC::ProxyObject::performGetPrototype): * runtime/RegExp.cpp: (JSC::RegExp::finishCreation): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/StringRecursionChecker.h: (JSC::StringRecursionChecker::performCheck): * runtime/VM.cpp: (JSC::VM::setStackPointerAtVMEntry): (JSC::VM::updateSoftReservedZoneSize): (JSC::preCommitStackMemory): (JSC::VM::updateStackLimits): (JSC::VM::updateStackLimit): Deleted. * runtime/VM.h: (JSC::VM::stackLimit): (JSC::VM::softStackLimit): (JSC::VM::addressOfSoftStackLimit): (JSC::VM::setCLoopStackLimit): (JSC::VM::isSafeToRecurse): (JSC::VM::lastStackTop): (JSC::VM::setException): * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): (JSC::VM::isSafeToRecurseSoft): (JSC::VM::shouldTriggerTermination): * tests/stress/promise-infinite-recursion-should-not-crash.js: Added. (testPromise): (promiseFunc): * yarr/YarrPattern.cpp: 2016-07-12 Per Arne Vollan [Win] Fix for build error when trying to version stamp dll. https://bugs.webkit.org/show_bug.cgi?id=159692 Reviewed by Brent Fulgham. Use correct path to version stamp script. * CMakeLists.txt: 2016-07-12 Benjamin Poulain [JSC] Array.prototype.join() fails some conformance tests https://bugs.webkit.org/show_bug.cgi?id=159657 Reviewed by Saam Barati. There were a couple of failures: -separator.toString() was called *before* we get the length and process ToLength() on it. -We were using toUInt32() on length instead of ToLength(), failing on big integers and various negative numbers. Additionally, I replaced the "fast" ArrayStorage path by a fully generic implementation that does not depends on StringJoiner. The reason is StringJoiner was doing poorly on sparse objects in certain cases. If you have a sparse object with a length > INT_MAX but very few indices defined, and you join on the empty string, it should be possible to join the array (albeit very slowly). With StringJoiner, we fail because we try to allocate > INT_MAX empty strings in a contiguous vector. * runtime/ArrayPrototype.cpp: (JSC::slowJoin): (JSC::canUseFastJoin): (JSC::fastJoin): (JSC::arrayProtoFuncJoin): (JSC::join): Deleted. * runtime/JSArray.h: (JSC::toLength): 2016-07-12 Mark Lam More stack limit and reserved zone renaming. https://bugs.webkit.org/show_bug.cgi?id=159690 Rubber-stamped by Geoffrey Garen. We should rename the following: osStackLimitWithReserve => softStackLimit reservedZoneSize => softReservedZoneSize errorModeReservedZoneSize => reservedZoneSize * API/tests/PingPongStackOverflowTest.cpp: (testPingPongStackOverflow): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * interpreter/CLoopStack.cpp: (JSC::CLoopStack::CLoopStack): (JSC::CLoopStack::grow): (JSC::CLoopStack::releaseExcessCapacity): (JSC::CLoopStack::addToCommittedByteCount): (JSC::CLoopStack::setSoftReservedZoneSize): (JSC::CLoopStack::setReservedZoneSize): Deleted. * interpreter/CLoopStack.h: (JSC::CLoopStack::size): * interpreter/CLoopStackInlines.h: (JSC::CLoopStack::shrink): * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ErrorHandlingScope.cpp: (JSC::ErrorHandlingScope::ErrorHandlingScope): (JSC::ErrorHandlingScope::~ErrorHandlingScope): * runtime/ErrorHandlingScope.h: * runtime/Options.h: * runtime/RegExp.cpp: (JSC::RegExp::finishCreation): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::setStackPointerAtVMEntry): (JSC::VM::updateSoftReservedZoneSize): (JSC::VM::updateStackLimit): (JSC::VM::updateReservedZoneSize): Deleted. * runtime/VM.h: (JSC::VM::stackPointerAtVMEntry): (JSC::VM::softReservedZoneSize): (JSC::VM::softStackLimit): (JSC::VM::addressOfSoftStackLimit): (JSC::VM::cloopStackLimit): (JSC::VM::setCLoopStackLimit): (JSC::VM::isSafeToRecurse): (JSC::VM::reservedZoneSize): Deleted. (JSC::VM::osStackLimitWithReserve): Deleted. (JSC::VM::addressOfOSStackLimitWithReserve): Deleted. * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): * wasm/WASMFunctionCompiler.h: (JSC::WASMFunctionCompiler::startFunction): 2016-07-12 Gyuyoung Kim Remove ENABLE_CSS3_TEXT_LINE_BREAK flag https://bugs.webkit.org/show_bug.cgi?id=159671 Reviewed by Csaba Osztrogonác. ENABLE_CSS3_TEXT_LINE_BREAK feature was implemented without guards. https://bugs.webkit.org/show_bug.cgi?id=89235 So this guard can be removed in build scripts. * Configurations/FeatureDefines.xcconfig: 2016-07-12 Per Arne Vollan [Win] DLLs are missing version information. https://bugs.webkit.org/show_bug.cgi?id=159349 Reviewed by Brent Fulgham. Generate autoversion.h and run perl version stamp utility. * CMakeLists.txt: 2016-07-11 Caio Lima ECMAScript 2016: %TypedArray%.prototype.includes implementation https://bugs.webkit.org/show_bug.cgi?id=159385 Reviewed by Benjamin Poulain. This patch implements the ECMAScript 2016: %TypedArray%.prototype.includes following spec 22.2.3.14 https://tc39.github.io/ecma262/2016/#sec-%typedarray%.prototype.includes * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncIncludes): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::typedArrayViewProtoFuncIncludes): (JSC::JSTypedArrayViewPrototype::finishCreation): 2016-07-11 Benjamin Poulain [JSC] Array.from() and Array.of() try to build objects even if "this" is not a constructor https://bugs.webkit.org/show_bug.cgi?id=159604 Reviewed by Yusuke Suzuki. The spec says IsConstructor(), we were just checking if "this" is any function. * builtins/ArrayConstructor.js: (of): (from): 2016-07-11 Keith Miller defineProperty on a index of a TypedArray should throw if configurable https://bugs.webkit.org/show_bug.cgi?id=159653 Reviewed by Saam Barati. When I fixed this before I misread the spec and thought it said we should throw if the descriptor said the proprety is not configurable. This is the opposite. We should throw if the descriptor says the property is configurable. * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::defineOwnProperty): * tests/stress/typedarray-access-monomorphic-neutered.js: * tests/stress/typedarray-access-neutered.js: * tests/stress/typedarray-configure-index.js: Added. (assert): (assertThrows): (makeDescriptor): (test): 2016-07-11 Saam Barati some paths in Array.prototype.splice don't account for the array not having certain indexed properties https://bugs.webkit.org/show_bug.cgi?id=159641 Reviewed by Filip Pizlo and Keith Miller. Array.prototype.splice was incorrectly putting properties on the result array even if the |this| array didn't have those properties. This is not the behavior of the spec. However, this could also cause a crash because we can construct a program where we would putByIndex on a typed array where the value we are putting is JSValue(). This is bad because the typed array will try to convert JSValue() into an integer. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSplice): * tests/stress/array-prototype-splice-making-typed-array.js: Added. (assert): (test): 2016-07-11 Mark Lam Refactor JSStack to only be the stack data structure for the C Loop. https://bugs.webkit.org/show_bug.cgi?id=159545 Reviewed by Geoffrey Garen. Changes made: 1. Renamed JSStack to CLoopStack. 2. Made all of CLoopStack code to conditional on #if !ENABLE(JIT) i.e. they will only be in effect for the C Loop build. 3. Changed clients of JSStack to use new equivalent VM APIs: a. JSStack::ensureCapacityFor() => VM::ensureStackCapacityFor() b. JSStack::committedByteCount() => VM::committedStackByteCount() 4. Made VM::updateReservedZoneSize() call CLoopStack::setReservedZoneSize() instead of calling it from all the clients of VM::updateReservedZoneSize(). 5. Removed all unnecessary references to JSStack. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MaxFrameExtentForSlowPathCall.h: * bytecode/BytecodeConventions.h: * dfg/DFGGraph.h: * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * ftl/FTLOSREntry.cpp: (JSC::FTL::prepareOSREntry): * heap/Heap.cpp: (JSC::Heap::finalizeUnconditionalFinalizers): (JSC::Heap::willStartIterating): (JSC::Heap::gatherJSStackRoots): (JSC::Heap::stack): Deleted. * heap/Heap.h: * interpreter/CLoopStack.cpp: Copied from Source/JavaScriptCore/interpreter/JSStack.cpp. (JSC::commitSize): (JSC::CLoopStack::CLoopStack): (JSC::CLoopStack::~CLoopStack): (JSC::CLoopStack::grow): (JSC::CLoopStack::gatherConservativeRoots): (JSC::CLoopStack::sanitizeStack): (JSC::CLoopStack::releaseExcessCapacity): (JSC::CLoopStack::addToCommittedByteCount): (JSC::CLoopStack::setReservedZoneSize): (JSC::CLoopStack::committedByteCount): (JSC::JSStack::JSStack): Deleted. (JSC::JSStack::~JSStack): Deleted. (JSC::JSStack::growSlowCase): Deleted. (JSC::JSStack::gatherConservativeRoots): Deleted. (JSC::JSStack::sanitizeStack): Deleted. (JSC::JSStack::releaseExcessCapacity): Deleted. (JSC::JSStack::addToCommittedByteCount): Deleted. (JSC::JSStack::setReservedZoneSize): Deleted. (JSC::JSStack::lowAddress): Deleted. (JSC::JSStack::highAddress): Deleted. (JSC::JSStack::committedByteCount): Deleted. * interpreter/CLoopStack.h: Copied from Source/JavaScriptCore/interpreter/JSStack.h. (JSC::CLoopStack::containsAddress): (JSC::CLoopStack::lowAddress): (JSC::CLoopStack::highAddress): (JSC::CLoopStack::reservationTop): (JSC::JSStack::containsAddress): Deleted. (JSC::JSStack::lowAddress): Deleted. (JSC::JSStack::highAddress): Deleted. (JSC::JSStack::reservationTop): Deleted. * interpreter/CLoopStackInlines.h: Copied from Source/JavaScriptCore/interpreter/JSStackInlines.h. (JSC::CLoopStack::ensureCapacityFor): (JSC::CLoopStack::topOfFrameFor): (JSC::CLoopStack::topOfStack): (JSC::CLoopStack::shrink): (JSC::CLoopStack::setCLoopStackLimit): (JSC::JSStack::ensureCapacityFor): Deleted. (JSC::JSStack::topOfFrameFor): Deleted. (JSC::JSStack::topOfStack): Deleted. (JSC::JSStack::shrink): Deleted. (JSC::JSStack::grow): Deleted. (JSC::JSStack::setCLoopStackLimit): Deleted. * interpreter/CallFrame.cpp: (JSC::CallFrame::unsafeCallSiteIndex): (JSC::CallFrame::currentVPC): (JSC::CallFrame::stack): Deleted. * interpreter/CallFrame.h: (JSC::ExecState::callerFrameAndPC): (JSC::ExecState::unsafeCallerFrameAndPC): * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): (JSC::sizeFrameForForwardArguments): (JSC::sizeFrameForVarargs): (JSC::Interpreter::Interpreter): * interpreter/Interpreter.h: (JSC::Interpreter::cloopStack): (JSC::Interpreter::getOpcode): (JSC::Interpreter::isCallBytecode): (JSC::Interpreter::stack): Deleted. * interpreter/JSStack.cpp: Removed. * interpreter/JSStack.h: Removed. * interpreter/JSStackInlines.h: Removed. * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::dump): * jit/JIT.h: * jit/JITOperations.cpp: * jit/JSInterfaceJIT.h: * jit/SpecializedThunkJIT.h: * jit/ThunkGenerators.cpp: * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::llint_stack_check_at_vm_entry): * llint/LLIntThunks.cpp: * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::arityCheckFor): * runtime/ErrorHandlingScope.cpp: (JSC::ErrorHandlingScope::ErrorHandlingScope): (JSC::ErrorHandlingScope::~ErrorHandlingScope): * runtime/JSGlobalObject.h: * runtime/MemoryStatistics.cpp: (JSC::globalMemoryStatistics): * runtime/StackAlignment.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::updateReservedZoneSize): (JSC::sanitizeStackForVM): (JSC::VM::committedStackByteCount): * runtime/VM.h: (JSC::VM::reservedZoneSize): (JSC::VM::osStackLimitWithReserve): (JSC::VM::addressOfOSStackLimitWithReserve): * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): (JSC::VM::shouldTriggerTermination): 2016-07-11 Keith Miller STP TypedArray.subarray 5x slowdown compared to 9.1 https://bugs.webkit.org/show_bug.cgi?id=156404 Reviewed by Geoffrey Garen. This patch moves the species constructor work for %TypedArray%.prototype.subarray to a js wrapper. By moving the species constructor work to JS we are able to completely optimize it out in DFG. The actual work of creating a TypedArray is still done in C++ since we are able to avoid calling into the constructor, which is expensive. This patch also changes the error message when a %TypedArray%.prototype function is passed a non-typed array this value. Finally, we used to check that the this value had not been detached, however, this behavior was incorrect. * builtins/BuiltinNames.h: * builtins/TypedArrayPrototype.js: (globalPrivate.typedArraySpeciesConstructor): (subarray): * runtime/ConstructData.cpp: (JSC::construct): * runtime/ConstructData.h: * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate): (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::typedArrayViewPrivateFuncLength): (JSC::typedArrayViewPrivateFuncSubarrayCreate): (JSC::JSTypedArrayViewPrototype::finishCreation): (JSC::typedArrayViewProtoFuncSubarray): Deleted. * runtime/JSTypedArrayViewPrototype.h: 2016-07-11 Yusuke Suzuki REGRESSION(r202992): JSC varargs tests are broken https://bugs.webkit.org/show_bug.cgi?id=159616 Reviewed by Csaba Osztrogonác. The substitution miss in r202992 causes varargs tests failures in GTK port. * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): 2016-07-10 Yusuke Suzuki [ES6] Promise.{all,race} no longer use @@species https://bugs.webkit.org/show_bug.cgi?id=159615 Reviewed by Keith Miller. As per the latest ES draft, Promise.{all,race} no longer use @@species. So, this patch drops FIXMEs. * builtins/PromiseConstructor.js: (all): (race): * tests/stress/ignore-promise-species.js: Added. (shouldBe): (DerivedPromise.prototype.get Symbol): (DerivedPromise): 2016-07-10 Commit Queue Unreviewed, rolling out r203037. https://bugs.webkit.org/show_bug.cgi?id=159614 The JSC tests are breaking in elcapitan-debug-tests-jsc and elcapitan-release-tests-jsc (Requested by caiolima on #webkit). Reverted changeset: "ECMAScript 2016: %TypedArray%.prototype.includes implementation" https://bugs.webkit.org/show_bug.cgi?id=159385 http://trac.webkit.org/changeset/203037 2016-07-10 Caio Lima ECMAScript 2016: %TypedArray%.prototype.includes implementation https://bugs.webkit.org/show_bug.cgi?id=159385 Reviewed by Benjamin Poulain. This patch implements the ECMAScript 2016: %TypedArray%.prototype.includes following spec 22.2.3.14 https://tc39.github.io/ecma262/2016/#sec-%typedarray%.prototype.includes * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncIncludes): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::typedArrayViewProtoFuncIncludes): (JSC::JSTypedArrayViewPrototype::finishCreation): 2016-07-09 Filip Pizlo REGRESSION(201900): validation failure for GetByOffset/PutByOffset in VALIDATE((node), node->child1().node() == node->child2().node() || node->child1()->result() == NodeResultStorage) https://bugs.webkit.org/show_bug.cgi?id=159603 Reviewed by Keith Miller. This removes an incorrect validation rule and replaces it with a FIXME about how to make this aspect of IR easier to validate soundly. It's not valid to assert that two children of a node are the same. It should always be valid to take: Foo(@x, @x) and turn it into: a: ValueRep(@x) b: ValueRep(@x) Foo(@a, @b) or even something like: y: Identity(@y) Foo(@x, @y) That's because it should be possible to rewire any data flow edge something that produces an equivalent value. The validation rule that this patch removes meant that such rewirings were invalid on GetByOffset/PutByOffset. FixupPhase did such a rewiring sometimes. * dfg/DFGValidate.cpp: * tests/stress/get-by-offset-double.js: Added. 2016-07-09 Keith Miller appendMemcpy might fail in concatAppendOne https://bugs.webkit.org/show_bug.cgi?id=159601 Reviewed by Mark Lam. There are multiple reasons why we might fail appendMemcpy. One reason, which I suspect was the source of the crashes, is that one of the Array prototypes has an indexed property. This patch consolidates the two old cases by just creating an array then attempting to memcpy append. If that fails, we fall back to moveElements. * runtime/ArrayPrototype.cpp: (JSC::concatAppendOne): * tests/stress/concat-with-holesMustForwardToPrototype.js: Added. (arrayEq): 2016-07-09 Benjamin Poulain [JSC] Fix the Template Raw Value of \ (escape) + LineTerminatorSequence https://bugs.webkit.org/show_bug.cgi?id=159595 Reviewed by Yusuke Suzuki. The spec (https://tc39.github.io/ecma262/#sec-static-semantics-tv-and-trv) says: "The TRV of LineContinuation::\LineTerminatorSequence is the sequence consisting of the code unit value 0x005C followed by the code units of TRV of LineTerminatorSequence." We were not normalizing the LineTerminatorSequence in that case, but it should be as it is the TRV of LineTerminatorSequence. * parser/Lexer.cpp: (JSC::Lexer::parseTemplateLiteral): * tests/stress/tagged-templates-raw-strings.js: 2016-07-08 Saam Barati We may add a ReadOnly property without setting the corresponding bit on Structure https://bugs.webkit.org/show_bug.cgi?id=159542 Reviewed by Benjamin Poulain. The reason this usually is OK is due to happenstance. Often, instances that putDirectWithoutTransition also happen to have a static property table. Having a static property table causes the HasReadOnlyOrGetterSetterPropertiesExcludingProto on the structure to be set. However, there are times where an object calls putDirectWithoutTransition, and it doesn't have a static property hash table. The fix is simple, putDirectWithTransition needs to set the HasReadOnlyOrGetterSetterPropertiesExcludingProto if it puts a ReadOnly property. * runtime/JSObject.h: (JSC::JSObject::putDirectWithoutTransition): * tests/stress/proper-property-store-with-prototype-property-that-is-not-writable.js: Added. (assert): 2016-07-08 Michael Saboff ASSERTION FAILED: Heap::isMarked(cell) in SlotVisitor::appendToMarkStack(JSC::JSCell *) https://bugs.webkit.org/show_bug.cgi?id=159588 Reviewed by Geoffrey Garen. We were jettisoning a CodeBlock during GC that won't survive and its owning script won't survive either. We can't install any code on the owning script as that involves a write barrier that will "pull" the script back into the remembered set. Badness would ensue. Added an early return in CodeBlock::jettison() when we are garbage collecting and the owning script isn't marked. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::jettison): 2016-07-08 Mark Lam Move CallFrame header info from JSStack.h to CallFrame.h https://bugs.webkit.org/show_bug.cgi?id=159549 Reviewed by Geoffrey Garen. CallFrame.h is a much better location for CallFrame header info. Replaced CallFrame::init() with ExecState::initGlobalExec() because normal CallFrames are setup by a different mechanism now. Only the globalExec is still using it. So, might as well change it to be specifically for the globalExec. Removed the use of JSStack::containsAddress() in ExecState::initGlobalExec() because it is not relevant to the globalExec. Also removed some unused code: JSStack::gatherConservativeRoots() and JSStack::sanitizeStack() is never called for JIT builds. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generateImpl): * bytecode/VirtualRegister.h: (JSC::VirtualRegister::isValid): (JSC::VirtualRegister::isLocal): (JSC::VirtualRegister::isArgument): (JSC::VirtualRegister::isHeader): (JSC::VirtualRegister::isConstant): (JSC::VirtualRegister::toLocal): (JSC::VirtualRegister::toArgument): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitConstruct): * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::thisRegister): (JSC::CallArguments::argumentRegister): (JSC::CallArguments::stackOffset): (JSC::CallArguments::argumentCountIncludingThis): (JSC::CallArguments::argumentsNode): (JSC::BytecodeGenerator::registerFor): * bytecompiler/NodesCodegen.cpp: (JSC::emitHomeObjectForCallee): (JSC::emitGetSuperFunctionForConstruct): (JSC::CallArguments::CallArguments): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGArgumentsUtilities.cpp: (JSC::DFG::argumentsInvolveStackSlot): (JSC::DFG::emitCodeToGetArgumentsArrayLength): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::get): (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult): (JSC::DFG::ByteCodeParser::getArgumentCount): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::isLiveInBytecode): * dfg/DFGGraph.h: (JSC::DFG::Graph::forAllLocalsLiveInBytecode): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileEntry): (JSC::DFG::JITCompiler::compileSetupRegistersForEntry): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::emitStoreCallSiteIndex): * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExitCompiler.cpp: (JSC::DFG::OSRExitCompiler::emitRestoreArguments): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGOSRExitCompilerCommon.h: (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk): * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitGetLength): (JSC::DFG::SpeculativeJIT::emitGetCallee): (JSC::DFG::SpeculativeJIT::emitGetArgumentStart): (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): * dfg/DFGThunks.cpp: (JSC::DFG::osrEntryThunkGenerator): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal): (JSC::FTL::DFG::LowerDFGToB3::compileGetCallee): (JSC::FTL::DFG::LowerDFGToB3::compileGetArgumentCountIncludingThis): (JSC::FTL::DFG::LowerDFGToB3::compileGetScope): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue): (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength): (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee): (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart): (JSC::FTL::DFG::LowerDFGToB3::callPreflight): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLSlowPathCall.h: (JSC::FTL::callOperation): * interpreter/CallFrame.cpp: (JSC::ExecState::initGlobalExec): (JSC::CallFrame::callSiteBitsAreBytecodeOffset): (JSC::CallFrame::callSiteAsRawBits): (JSC::CallFrame::unsafeCallSiteAsRawBits): (JSC::CallFrame::callSiteIndex): (JSC::CallFrame::setCurrentVPC): (JSC::CallFrame::callSiteBitsAsBytecodeOffset): * interpreter/CallFrame.h: (JSC::CallSiteIndex::CallSiteIndex): (JSC::ExecState::calleeAsValue): (JSC::ExecState::callee): (JSC::ExecState::unsafeCallee): (JSC::ExecState::codeBlock): (JSC::ExecState::unsafeCodeBlock): (JSC::ExecState::scope): (JSC::ExecState::setCallerFrame): (JSC::ExecState::setScope): (JSC::ExecState::argumentCount): (JSC::ExecState::argumentCountIncludingThis): (JSC::ExecState::argumentOffset): (JSC::ExecState::argumentOffsetIncludingThis): (JSC::ExecState::offsetFor): (JSC::ExecState::noCaller): (JSC::ExecState::setArgumentCountIncludingThis): (JSC::ExecState::setCallee): (JSC::ExecState::setCodeBlock): (JSC::ExecState::setReturnPC): (JSC::ExecState::argIndexForRegister): (JSC::ExecState::callerFrameAndPC): (JSC::ExecState::unsafeCallerFrameAndPC): (JSC::ExecState::init): Deleted. * interpreter/Interpreter.cpp: (JSC::Interpreter::dumpRegisters): * interpreter/Interpreter.h: (JSC::calleeFrameForVarargs): * interpreter/JSStack.h: (JSC::JSStack::containsAddress): (JSC::JSStack::gatherConservativeRoots): Deleted. (JSC::JSStack::sanitizeStack): Deleted. * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::jitAssertArgumentCountSane): (JSC::AssemblyHelpers::emitRandomThunk): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::restoreReturnAddressBeforeReturn): (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr): (JSC::AssemblyHelpers::emitGetFromCallFrameHeader32): (JSC::AssemblyHelpers::emitGetFromCallFrameHeader64): (JSC::AssemblyHelpers::emitPutToCallFrameHeader): (JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue): (JSC::AssemblyHelpers::calleeFrameSlot): * jit/CCallHelpers.cpp: (JSC::CCallHelpers::logShadowChickenProloguePacket): * jit/CCallHelpers.h: (JSC::CCallHelpers::prepareForTailCallSlow): * jit/CallFrameShuffler.cpp: (JSC::CallFrameShuffler::CallFrameShuffler): (JSC::CallFrameShuffler::dump): (JSC::CallFrameShuffler::extendFrameIfNeeded): (JSC::CallFrameShuffler::prepareForSlowPath): (JSC::CallFrameShuffler::prepareForTailCall): (JSC::CallFrameShuffler::prepareAny): * jit/CallFrameShuffler.h: (JSC::CallFrameShuffler::snapshot): (JSC::CallFrameShuffler::setCalleeJSValueRegs): (JSC::CallFrameShuffler::assumeCalleeIsCell): (JSC::CallFrameShuffler::numLocals): (JSC::CallFrameShuffler::getOld): (JSC::CallFrameShuffler::setOld): (JSC::CallFrameShuffler::firstOld): (JSC::CallFrameShuffler::lastOld): (JSC::CallFrameShuffler::isValidOld): (JSC::CallFrameShuffler::argCount): (JSC::CallFrameShuffler::getNew): * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileSetupVarargsFrame): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCall): * jit/JITCall32_64.cpp: (JSC::JIT::compileSetupVarargsFrame): (JSC::JIT::compileCallEvalSlowCase): (JSC::JIT::compileOpCall): * jit/JITInlines.h: (JSC::JIT::getConstantOperand): (JSC::JIT::emitPutIntToCallFrameHeader): (JSC::JIT::updateTopCallFrame): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_get_scope): (JSC::JIT::emit_op_argument_count): (JSC::JIT::emit_op_get_rest_length): * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): (JSC::JIT::emit_op_get_scope): * jit/JSInterfaceJIT.h: (JSC::JSInterfaceJIT::emitJumpIfNotType): (JSC::JSInterfaceJIT::emitGetFromCallFrameHeaderPtr): (JSC::JSInterfaceJIT::emitPutToCallFrameHeader): (JSC::JSInterfaceJIT::emitPutCellToCallFrameHeader): * jit/SetupVarargsFrame.cpp: (JSC::emitSetVarargsFrame): (JSC::emitSetupVarargsFrameFastCase): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::SpecializedThunkJIT): * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): (JSC::arityFixupGenerator): (JSC::boundThisNoArgsFunctionCallGenerator): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::genericCall): (JSC::LLInt::varargsSetup): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::arityCheckFor): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: * runtime/StackAlignment.h: (JSC::roundArgumentCountToAlignFrame): (JSC::roundLocalRegisterCountForFramePointerOffset): (JSC::logStackAlignmentRegisters): * wasm/WASMFunctionCompiler.h: (JSC::WASMFunctionCompiler::startFunction): (JSC::WASMFunctionCompiler::endFunction): (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer): (JSC::WASMFunctionCompiler::callAndUnboxResult): * wasm/WASMFunctionSyntaxChecker.h: (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall): 2016-07-08 Chris Dumez Object.defineProperty() should maintain existing getter / setter if not overridden in the new descriptor https://bugs.webkit.org/show_bug.cgi?id=159576 Reviewed by Mark Lam. Object.defineProperty() should maintain existing getter / setter if not overridden in the new descriptor. Previously, if the property is a had a custom getter / setter, and if the new descriptor only had a setter (or only a getter), JSC would clear the existing getter (or setter). This behavior did not match the EcmaScript specification or Firefox / Chrome. This patch fixes the issue. This fixes searching and search suggestions on www.iciba.com. * runtime/JSObject.cpp: (JSC::validateAndApplyPropertyDescriptor): 2016-07-08 Michael Saboff Dumping the object graph doesn't work with verbose GC logging https://bugs.webkit.org/show_bug.cgi?id=159569 Reviewed by Mark Lam. The current object graph logging code tries to revisits the graph. This doesn't work correctly and asking around it isn't used. The only way to dump the true object graph is to log while we GC and that has obvious performance implications. Therefore I eliminated GCLogging::dumpObjectGraph() and related code. * heap/GCLogging.cpp: (JSC::GCLogging::levelAsString): (JSC::LoggingFunctor::LoggingFunctor): Deleted. (JSC::LoggingFunctor::~LoggingFunctor): Deleted. (JSC::LoggingFunctor::operator()): Deleted. (JSC::LoggingFunctor::log): Deleted. (JSC::LoggingFunctor::reviveCells): Deleted. (JSC::LoggingFunctor::returnValue): Deleted. (JSC::GCLogging::dumpObjectGraph): Deleted. * heap/Heap.cpp: (JSC::Heap::didFinishCollection): 2016-07-08 Keith Miller speculateTypedArrayIsNotNeutered has an inverted speculation https://bugs.webkit.org/show_bug.cgi?id=159571 Reviewed by Mark Lam. For some confusing reason FTLLowerDFGToB3 takes the condition the speculation wants to be false. This issue caused typedarray-access-monomorphic-neutered.js to fail on the bots. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered): 2016-07-08 Mark Lam Rename jsCPUStackLimit to osStackLimitWithReserve and jsEmulatedStackLimit to cloopStackLimit. https://bugs.webkit.org/show_bug.cgi?id=159544 Reviewed by Geoffrey Garen. This patch does the following refactoring: 1. Rename jsCPUStackLimit to osStackLimitWithReserve. 2. Rename jsEmulatedStackLimit to cloopStackLimit. 2. Remove llintStackLimit (which previously is either an alias for jsCPUStackLimit or jsEmulatedStackLimit depending on whether we have a JIT or C Loop build). Instead, we'll change the LLINT to conditionally use the osStackLimitWithReserve or cloopStackLimit. There are no semantic changes. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::growSlowCase): (JSC::JSStack::lowAddress): (JSC::JSStack::highAddress): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::ensureCapacityFor): (JSC::JSStack::shrink): (JSC::JSStack::grow): (JSC::JSStack::setCLoopStackLimit): (JSC::JSStack::setJSEmulatedStackLimit): Deleted. * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/RegExp.cpp: (JSC::RegExp::finishCreation): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/VM.cpp: (JSC::VM::updateStackLimit): * runtime/VM.h: (JSC::VM::reservedZoneSize): (JSC::VM::osStackLimitWithReserve): (JSC::VM::addressOfOSStackLimitWithReserve): (JSC::VM::cloopStackLimit): (JSC::VM::setCLoopStackLimit): (JSC::VM::isSafeToRecurse): (JSC::VM::jsCPUStackLimit): Deleted. (JSC::VM::addressOfJSCPUStackLimit): Deleted. (JSC::VM::jsEmulatedStackLimit): Deleted. (JSC::VM::setJSEmulatedStackLimit): Deleted. * wasm/WASMFunctionCompiler.h: (JSC::WASMFunctionCompiler::startFunction): 2016-07-08 Commit Queue Unreviewed, rolling out r202799. https://bugs.webkit.org/show_bug.cgi?id=159568 Caused build failure (Requested by perarne on #webkit). Reverted changeset: "[Win] DLLs are missing version information." https://bugs.webkit.org/show_bug.cgi?id=159349 http://trac.webkit.org/changeset/202799 2016-07-08 Youenn Fablet Built-in generator should generate files with a default copyright https://bugs.webkit.org/show_bug.cgi?id=159561 Reviewed by Alex Christensen. * Scripts/builtins/builtins_model.py: (BuiltinsCollection._parse_copyright_lines): Adding default copyright to the parsed copyrights. * Scripts/builtins/builtins_templates.py: (BuiltinsGeneratorTemplates): Adding a default copyright. * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: Rebasing with added default copyright. * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: Ditto. * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: Ditto. * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: Ditto. * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: Ditto. * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: Ditto. * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: Ditto. * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Ditto. * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto. * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto. * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto. * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Ditto. 2016-07-08 Keith Miller TypedArrays need more isNeutered checks. https://bugs.webkit.org/show_bug.cgi?id=159231 Reviewed by Filip Pizlo. According to the ES6 spec if a user tries to get, set, or define a property on a neutered TypedArray we should throw an exception. Currently, if a user tries to get an out of bounds access on a TypedArray we will always OSR. This makes handling the exception easy as all we need to do is make out of bounds gets in PolymorphicAccess go to the slow path, which will then throw the appropriate exception. For the case of set, we need ensure we don't OSR on each out of bounds put since, for some confusing reason, people do this. Thus, for GetByVal in the DFG/FTL if the user accesses out of bounds we then need to check if the view has been neutered. If it is neutered then we will OSR. Additionally, this patch adds a bunch of isNeutered checks to various prototype functions for TypedArray, which are needed for correctness. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): * dfg/DFGSpeculativeJIT.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * runtime/JSArrayBufferView.h: * runtime/JSCJSValue.h: (JSC::encodedJSUndefined): (JSC::encodedJSValue): * runtime/JSGenericTypedArrayView.h: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::throwNeuteredTypedArrayTypeError): (JSC::JSGenericTypedArrayView::getOwnPropertySlot): (JSC::JSGenericTypedArrayView::put): (JSC::JSGenericTypedArrayView::defineOwnProperty): (JSC::JSGenericTypedArrayView::deleteProperty): (JSC::JSGenericTypedArrayView::getOwnPropertySlotByIndex): (JSC::JSGenericTypedArrayView::putByIndex): (JSC::JSGenericTypedArrayView::deletePropertyByIndex): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncCopyWithin): (JSC::genericTypedArrayViewProtoFuncFill): (JSC::genericTypedArrayViewProtoFuncIndexOf): (JSC::genericTypedArrayViewProtoFuncJoin): (JSC::genericTypedArrayViewProtoFuncLastIndexOf): (JSC::genericTypedArrayViewProtoFuncSlice): (JSC::genericTypedArrayViewProtoFuncSubarray): * tests/stress/fold-typed-array-properties.js: * tests/stress/typedarray-access-monomorphic-neutered.js: Added. (check): (test): (testFTL): * tests/stress/typedarray-access-neutered.js: Added. (check): (test): * tests/stress/typedarray-functions-with-neutered.js: (defaultForArg): (callWithArgs): (checkArgumentsForType): (checkArguments): * tests/stress/typedarray-view-string-properties-neutered.js: Added. (call): (test): 2016-07-08 Youenn Fablet Generate WebCore builtin wrapper files https://bugs.webkit.org/show_bug.cgi?id=159461 Reviewed by Brian Burg. Updating builtin generator to generate wrapper files used in WebCore (See WebCore change log). Rebasing builtins generator test results according generator changes by activating wrapper file generation for WebCore builtins tests. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/builtins/builtins.py: Adding new generators. * Scripts/builtins/builtins_generate_internals_wrapper_header.py: Added to generate WebCoreJSBuiltinInternals.h. * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py: Added to generate WebCoreJSBuiltinInternals.cpp. * Scripts/builtins/builtins_generate_wrapper_header.py: Added to generate WebCoreJSBuiltins.h. * Scripts/builtins/builtins_generate_wrapper_implementation.py: Added to generate WebCoreJSBuiltins.cpp. * Scripts/generate-js-builtins.py: Adding new option to activate generation of the wrapper files. (generate_bindings_for_builtins_files): * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: 2016-07-07 Joseph Pecoraro padStart/padEnd with Infinity produces unexpected result https://bugs.webkit.org/show_bug.cgi?id=159543 Reviewed by Benjamin Poulain. * builtins/GlobalOperations.js: (globalPrivate.toLength): Fix style. * builtins/StringPrototype.js: (padStart): (padEnd): After all observable operations, and after empty string has been handled, throw an out of memory error if the resulting string would be greater than the maximum string size. * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js: (shouldThrow): Deleted. * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js: (shouldThrow): (testMeta): * tests/es6/String.prototype_methods_String.prototype.padEnd.js: (shouldThrow): (TestToLength): (TestMemoryLimits): (TestMeta): Deleted. * tests/es6/String.prototype_methods_String.prototype.padStart.js: (shouldThrow): (TestToLength): (TestMemoryLimits): Replace incorrect shouldThrow(..., errorType) with explicit shouldThrow(..., errorMessage). The old shouldThrow would incorrectly succeed if the expected error type was just "Error". Now we explicitly check the error message. 2016-07-07 Benjamin Poulain [JSC] String.prototype[Symbol.iterator] needs a name https://bugs.webkit.org/show_bug.cgi?id=159541 Reviewed by Yusuke Suzuki. A man needs a name. Spec: https://tc39.github.io/ecma262/#sec-string.prototype-@@iterator * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): 2016-07-07 Michael Saboff REGRESSION(184445): Need to insert a StoreBarrier when we don't know child's epoch https://bugs.webkit.org/show_bug.cgi?id=159537 Reviewed by Benjamin Poulain. We weren't checking the case of a child node with a null epoch. The problem surfaces when the base node of a PutByVal variant has a non-null epoch, because it represents an allocation in the current function, while the child of the same node has an unknown epoch. Added a check that the child node is not null before comparing the epochs of the base and child nodes. The added test creates the problem circumstance by doing a full GC to place an array in remembered space, allocating a new object followed by an eden GC. The new object is only referenced by the array and therefore won't be visited Without the store barrier. The test may crash or more likely get the wrong answer with the bug. * dfg/DFGStoreBarrierInsertionPhase.cpp: * tests/stress/regress-159537.js: Added test. (MyNumber): (MyNumber.prototype.plusOne): (bar): (foo): (test): 2016-07-07 Joseph Pecoraro Unexpected "Out of memory" error for "x".repeat(-1) https://bugs.webkit.org/show_bug.cgi?id=159529 Reviewed by Benjamin Poulain. * builtins/StringPrototype.js: (globalPrivate.repeatSlowPath): (repeat): Move the @toInteger and range checking to the always path, since the spec does say it should always happen. Also remove the duplication of the fast path here. * runtime/StringPrototype.cpp: (JSC::repeatCharacter): Remove unused function. (JSC::stringProtoFuncRepeatCharacter): ASSERT if given a negative number. This is a private function only used internally. * tests/stress/string-repeat-edge-cases.js: (shouldThrow): Update expected error message. 2016-07-07 Benjamin Poulain [JSC] Array.prototype[Symbol.unscopables] should have the "includes" property https://bugs.webkit.org/show_bug.cgi?id=159504 Reviewed by Keith Miller. The property "includes" was missing. Spec: https://tc39.github.io/ecma262/#sec-array.prototype-@@unscopables * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): * tests/stress/unscopables.js: 2016-07-07 Saam Barati ToThis constant folding in DFG is incorrect when the structure indicates that toThis is overridden https://bugs.webkit.org/show_bug.cgi?id=159501 Reviewed by Mark Lam. We *cannot* constant fold ToThis when the structure of an object indicates that toThis() is overridden. isToThisAnIdentity() inside AbstractInterpreterInlines accidentally wrote the opposite rule. The rule was written as we can constant fold ToThis only when toThis() is overridden. To fix the bug, we must write the rule as isToThisAnIdentity() can only be true as long as the structure set indicates that no structures override toThis(). We could probably get more clever in the future and notice when we're dealing with a constant |this| values. For example, a ToThis might occur on a constant JSLexicalEnvironment. We could implement the rules of JSLexicalEnvironment's toThis() implementation inside AI/constant folding. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::isToThisAnIdentity): * tests/stress/to-this-on-constant-lexical-environment.js: Added. (foo.bar): (foo.inner): (foo): 2016-07-07 Benjamin Poulain [JSC] Array.prototype.includes uses ToInt32 instead of ToInteger on the index argument https://bugs.webkit.org/show_bug.cgi?id=159505 Reviewed by Mark Lam. The code was using (value)|0 which is effectively a ToInt32. This fails on large integers and +-Infinity. Spec: https://tc39.github.io/ecma262/#sec-array.prototype.includes * builtins/ArrayPrototype.js: (includes): 2016-07-07 Benjamin Poulain [JSC] String.prototype.normalize should have a length of zero https://bugs.webkit.org/show_bug.cgi?id=159506 Reviewed by Yusuke Suzuki. Spec: https://tc39.github.io/ecma262/#sec-string.prototype.normalize The argument is optional, the length should be zero. * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): 2016-07-07 Csaba Osztrogonác [ARMv7] REGRESSION(r197655): ASSERTION FAILED: (cond == Zero) || (cond == NonZero) https://bugs.webkit.org/show_bug.cgi?id=159419 Reviewed by Benjamin Poulain. Allow Signed and PositiveOrZero conditions too because tst instruction updates N and Z flags. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::branchTest32): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branchTest32): Add assertions to avoid possible bugs in the future. 2016-07-06 Youenn Fablet Builtin generator should use pragma once for header files https://bugs.webkit.org/show_bug.cgi?id=159462 Reviewed by Alex Christensen. * Scripts/builtins/builtins_generate_combined_header.py: (BuiltinsCombinedHeaderGenerator.generate_output): * Scripts/builtins/builtins_generate_separate_header.py: (BuiltinsSeparateHeaderGenerator.generate_output): * Scripts/builtins/builtins_templates.py: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: 2016-07-06 Benjamin Poulain [JSC] Unify how we throw TypeError from C++ https://bugs.webkit.org/show_bug.cgi?id=159500 Reviewed by Saam Barati. Throwing a TypeError is an uncommon case. We should minimize the impact on the call sites. This patch does that by: -Replace the 2 calls createTypeError()->throwException() by throwTypeError(). -Use ASCIILiteral when possible. -Add an overload of throwTypeError() taking ASCIILiteral directly (that way, the String creation and destruction is done by the callee). On x86_64, this reduces the __TEXT__ segment by 29kb. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension): * inspector/JSJavaScriptCallFrame.cpp: (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * runtime/DatePrototype.cpp: (JSC::dateProtoFuncToJSON): * runtime/Error.cpp: (JSC::throwConstructorCannotBeCalledAsFunctionTypeError): (JSC::throwTypeError): * runtime/Error.h: (JSC::throwVMTypeError): * runtime/JSArrayBufferPrototype.cpp: (JSC::arrayBufferProtoFuncSlice): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): (JSC::JSValue::toStringSlowCase): * runtime/JSCJSValueInlines.h: (JSC::toPreferredPrimitiveType): * runtime/JSDataViewPrototype.cpp: (JSC::getData): (JSC::setData): * runtime/JSFunction.cpp: (JSC::JSFunction::defineOwnProperty): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewFromIterator): (JSC::constructGenericTypedArrayViewWithArguments): (JSC::constructGenericTypedArrayView): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::speciesConstruct): (JSC::genericTypedArrayViewProtoFuncSet): (JSC::genericTypedArrayViewProtoFuncCopyWithin): (JSC::genericTypedArrayViewProtoFuncIndexOf): (JSC::genericTypedArrayViewProtoFuncLastIndexOf): (JSC::genericTypedArrayViewProtoFuncSubarray): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncProtoGetter): (JSC::globalFuncProtoSetter): * runtime/JSONObject.cpp: (JSC::Stringifier::appendStringifiedValue): * runtime/JSObject.cpp: (JSC::JSObject::setPrototypeWithCycleCheck): (JSC::callToPrimitiveFunction): (JSC::JSObject::ordinaryToPrimitive): (JSC::JSObject::defaultHasInstance): (JSC::validateAndApplyPropertyDescriptor): * runtime/JSTypedArrayViewConstructor.cpp: (JSC::constructTypedArrayView): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::typedArrayViewPrivateFuncLength): (JSC::typedArrayViewProtoFuncSet): (JSC::typedArrayViewProtoFuncCopyWithin): (JSC::typedArrayViewProtoFuncFill): (JSC::typedArrayViewProtoFuncLastIndexOf): (JSC::typedArrayViewProtoFuncIndexOf): (JSC::typedArrayViewProtoFuncJoin): (JSC::typedArrayViewProtoGetterFuncBuffer): (JSC::typedArrayViewProtoGetterFuncLength): (JSC::typedArrayViewProtoGetterFuncByteLength): (JSC::typedArrayViewProtoGetterFuncByteOffset): (JSC::typedArrayViewProtoFuncReverse): (JSC::typedArrayViewProtoFuncSubarray): (JSC::typedArrayViewProtoFuncSlice): * runtime/ObjectConstructor.cpp: (JSC::toPropertyDescriptor): (JSC::objectConstructorDefineProperty): (JSC::objectConstructorDefineProperties): (JSC::objectConstructorCreate): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncDefineGetter): (JSC::objectProtoFuncDefineSetter): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncCompile): * runtime/Symbol.cpp: (JSC::Symbol::toNumber): 2016-07-06 Saam Barati InlineAccess::sizeForLengthAccess() is wrong on some platforms because it should also consider "length" not being array length https://bugs.webkit.org/show_bug.cgi?id=159429 Reviewed by Filip Pizlo. The calculation inside sizeForLengthAccess() was not taking into account that an access to a "length" property might not be an array length access. sizeForLengthAccess() should always have enough room for a regular self property accesses. This only changes how much of a nop sled we emit if array length access size is smaller than self access size. This matters on ARM64. * bytecode/InlineAccess.h: (JSC::InlineAccess::sizeForPropertyAccess): (JSC::InlineAccess::sizeForPropertyReplace): (JSC::InlineAccess::sizeForLengthAccess): 2016-07-06 Commit Queue Unreviewed, rolling out r198928 and r198985. https://bugs.webkit.org/show_bug.cgi?id=159478 "It's breaking some websites" (Requested by saamyjoon on #webkit). Reverted changesets: "[ES6] Disallow var assignments in for-in loops" https://bugs.webkit.org/show_bug.cgi?id=155451 http://trac.webkit.org/changeset/198928 "Unreviewed, turn ES6 for-in loop test success" https://bugs.webkit.org/show_bug.cgi?id=155451 http://trac.webkit.org/changeset/198985 2016-07-05 Mark Lam Rename VM stack limit fields to better describe their purpose. https://bugs.webkit.org/show_bug.cgi?id=159451 Reviewed by Keith Miller. This is in preparation for an upcoming patch that changes what stack limit values are used under various circumstances. This patch aims to do some minimal work to rename the fields so that it will be easier to reason about the upcoming patch. In this patch, we make the following changes: 1. Rename VM::m_stackLimit to VM::m_jsCPUStackLimit. 2. VM::m_jsStackLimit used to have an overloaded meaning: a. For JIT builds, m_jsStackLimit is synonymous with m_stackLimit. b. For C Loop builds, m_jsStackLimit is a separate pointer that points to the emulated JS stack that the C Loop uses. In place of m_jsStackLimit, this patch introduces 2 new fields: VM::m_jsEmulatedStackLimit and VM::m_llintStackLimit. m_llintStackLimit is the limit that the LLInt assembly uses for its stack check. m_llintStackLimit behaves like the old m_jsStackLimit in that: a. For JIT builds, m_llintStackLimit is synonymous with m_jsCPUStackLimit. b. For C Loop builds, m_llintStackLimit is synonymous with m_jsEmulatedStackLimit. m_jsEmulatedStackLimit is used for the emulated stack that the C Loop uses. 3. Rename the following methods to match the above: VM::stackLimit() ==> VM::jsCPUStackLimit() VM::addressOfStackLimit() ==> VM::addressOfJSCPUStackLimit() VM::jsStackLimit() ==> VM::jsEmulatedStackLimit() VM::setJSStackLimit() ==> VM::setJSEmulatedStackLimit() JSStack::setStackLimit() ==> JSStack::setEmulatedStackLimit() 4. With change (2) and (3), the limits will be used as follows: a. VM code doing stack recursion checks will only use m_jsCPUStackLimit. b. JIT code will only use m_jsCPUStackLimit. c. C Loop emulated stack code in JSStack will only use m_jsEmulatedStackLimit. Note: the part of JSStack that operates on a JIT build will use m_jsCPUStackLimit as expected. d. LLINT assembly code will only use m_llintStackLimit. This patch only contains the above refactoring changes. There is no behavior change. * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::growSlowCase): (JSC::JSStack::lowAddress): (JSC::JSStack::highAddress): * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::ensureCapacityFor): (JSC::JSStack::shrink): (JSC::JSStack::grow): (JSC::JSStack::setJSEmulatedStackLimit): (JSC::JSStack::setStackLimit): Deleted. * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/RegExp.cpp: (JSC::RegExp::finishCreation): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::updateStackLimit): * runtime/VM.h: (JSC::VM::reservedZoneSize): (JSC::VM::jsCPUStackLimit): (JSC::VM::addressOfJSCPUStackLimit): (JSC::VM::jsEmulatedStackLimit): (JSC::VM::setJSEmulatedStackLimit): (JSC::VM::isSafeToRecurse): (JSC::VM::jsStackLimit): Deleted. (JSC::VM::setJSStackLimit): Deleted. (JSC::VM::stackLimit): Deleted. (JSC::VM::addressOfStackLimit): Deleted. * wasm/WASMFunctionCompiler.h: (JSC::WASMFunctionCompiler::startFunction): 2016-07-05 Saam Barati StackVisitor::unwindToMachineCodeBlockFrame() may unwind past a VM entry frame when catching an exception and the frame has inlined tail calls https://bugs.webkit.org/show_bug.cgi?id=159448 Reviewed by Mark Lam. Consider the following stack trace: (machine) foo -> VM entry frame -> (machine) bar -> (inlined tailcall) baz If an exception is thrown at 'baz', we will do exception unwinding, which will eventually call unwindToMachineCodeBlockFrame() which will call gotoNextFrame() on the 'baz' frame. The next logical frame for 'baz' is 'foo' because 'bar' tail called 'baz' even though there is a machine frame for 'bar' on the stack. This is a bug. unwindToMachineCodeBlockFrame() should not care about the next logical frame, it just wants to move StackVisitor's state to the current machine frame. The bug here is that we would end up unwinding past the VM entry frame which can have all kinds of terrible consequences. This bug fixes unwindToMachineCodeBlockFrame() by having it not rely on gotoNextFrame() and instead using its own mechanism for setting the StackVisotor's state to the current machine frame. * interpreter/StackVisitor.cpp: (JSC::StackVisitor::unwindToMachineCodeBlockFrame): * tests/stress/dont-unwind-past-vm-entry-frame.js: Added. (let.p.new.Proxy): (let.p.new.Proxy.apply): (bar): (let.good): (getItem): (start): 2016-07-05 Joseph Pecoraro RELEASE_ASSERT(!thisObject) in ObjCCallbackFunctionImpl::call when calling JSExport ObjC Constructor without operator new https://bugs.webkit.org/show_bug.cgi?id=159446 Reviewed by Mark Lam. Treat ObjC JSExport init constructors like ES6 Class Constructors and throw a TypeError when called without 'new'. * API/ObjCCallbackFunction.mm: (JSC::ObjCCallbackFunctionImpl::type): (JSC::objCCallbackFunctionCallAsFunction): When calling an init method as a function instead of construction throw a TypeError. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): Improve error message. * API/tests/testapi.mm: (testObjectiveCAPIMain): Test we get an exception when calling an ObjC constructor without 'new'. 2016-07-05 Mark Lam Remove some unneeded #include "CachedCall.h". https://bugs.webkit.org/show_bug.cgi?id=159449 Reviewed by Saam Barati. * runtime/ArrayPrototype.cpp: * runtime/JSArray.cpp: * runtime/MapPrototype.cpp: * runtime/SetPrototype.cpp: 2016-07-05 Geoffrey Garen Crash @ bankofamerica.com, University of Vienna https://bugs.webkit.org/show_bug.cgi?id=159439 Reviewed by Saam Barati. * ftl/FTLLink.cpp: (JSC::FTL::link): Do check for stack overflow in the arity mismatch thunk because it can happen. Don't store a CallSiteIndex because we haven't stored a CodeBlock yet, and our stack frame is not fully constructed, so it would be an error for any client to try to load this value (and operationCallArityCheck does not load this value). * tests/stress/arity-check-ftl-throw.js: Added. New test case for stressing a stack overflow with arity mismatch. Sadly, after hours of fiddling, I can't seem to get this to fail in trunk. Still, it's good to have some more testing in this area. 2016-07-05 Benjamin Poulain [JSC] The prototype cycle checks throws the wrong error type https://bugs.webkit.org/show_bug.cgi?id=159393 Reviewed by Geoffrey Garen. We were supposed to throw the TypeError: -https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__ * runtime/JSObject.cpp: (JSC::JSObject::setPrototypeWithCycleCheck): 2016-07-05 Saam Barati our parsing for "use strict" is wrong when we first parse other directives that are not "use strict" but are located in a place where "use strict" would be valid https://bugs.webkit.org/show_bug.cgi?id=159376 Reviewed by Benjamin Poulain. Our strict mode detection algorithm used to break if we ever saw a directive that is not "use strict" but is syntactically located in a location where our parser looks for "use strict". It broke as follows: If a function started with a non "use strict" string literal, we will allow "use strict" to be in any arbitrary statement inside the top level block in the function body. For example, this meant that if we parsed a sequence of string literals, followed by arbitrary statements, followed by "use strict", we would parse the function as if it's in strict mode. This is the wrong behavior with respect to the spec. This has consequences in other ways that break invariants of the language. For example, we used to allow functions that are lexically nested inside what we deemed a strict function to be non-strict. This used to fire an assertion if we ever skipped over that function using the source provider cache, but it worked just fine in release builds. This patch fixes this bug. * parser/Parser.cpp: (JSC::Parser::parseSourceElements): (JSC::Parser::parseStatement): * tests/stress/ensure-proper-strict-mode-parsing.js: Added. (foo.bar): (foo): (bar.foo): (bar): (bar.call.undefined.this.throw.new.Error.string_appeared_here.baz): (baz.call.undefined.undefined.throw.new.Error.string_appeared_here.jaz): (jaz.call.undefined.this.throw.new.Error.string_appeared_here.vaz): 2016-07-05 Saam Barati reportAbandonedObjectGraph should report abandoned bytes based on capacity() so it works even if a GC has never happened https://bugs.webkit.org/show_bug.cgi?id=159222 Reviewed by Geoffrey Garen. When reportAbandonedObjectGraph() was called before the first GC, it used to not indicate to the GC timers that we have memory that needs to be collected because the calculation was based on m_sizeAfterLastCollect (which was zero). This patch makes the calculation based on capacity() which is a valid number even before the first GC. * heap/Heap.cpp: (JSC::Heap::reportAbandonedObjectGraph): (JSC::Heap::protect): (JSC::Heap::didAbandon): Deleted. * heap/Heap.h: (JSC::Heap::jitStubRoutines): 2016-07-05 Csaba Osztrogonác Typo fix after r202214 https://bugs.webkit.org/show_bug.cgi?id=159416 Reviewed by Saam Barati. * bytecode/InlineAccess.h: 2016-07-03 Per Arne Vollan [Win] DLLs are missing version information. https://bugs.webkit.org/show_bug.cgi?id=159349 Reviewed by Brent Fulgham. Run perl version stamp utility. * CMakeLists.txt: 2016-07-01 Yusuke Suzuki [JSC] MacroAssemblerX86::branch8 should accept unsigned 8bit value https://bugs.webkit.org/show_bug.cgi?id=159334 Reviewed by Benjamin Poulain. As described in branchTest8 functions, byte in TrustedImm32 is not well defined. So the assertion here should be a little permissive; accepting -128 to 255. This assertion is originally fired when executing misc-bugs-847389-jpeg2000 benchmark in Debug build. So this patch includes misc-bugs-847389-jpeg2000 benchmark. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::branchTest8): (JSC::MacroAssemblerX86Common::branch8): * b3/testb3.cpp: (JSC::B3::testBranch8WithLoad8ZIndex): (JSC::B3::run): 2016-07-03 Benjamin Poulain [JSC] __lookupGetter__ and __lookupSetter__ should not ignore exceptions https://bugs.webkit.org/show_bug.cgi?id=159390 Reviewed by Mark Lam. See: -https://tc39.github.io/ecma262/#sec-object.prototype.__lookupGetter__ -https://tc39.github.io/ecma262/#sec-object.prototype.__lookupSetter__ They are both supposed to be regular [[GetOwnProperty]]. * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncLookupGetter): (JSC::objectProtoFuncLookupSetter): 2016-07-03 Saam Barati BytecodeGenerator::getVariablesUnderTDZ is too conservative https://bugs.webkit.org/show_bug.cgi?id=159387 Reviewed by Filip Pizlo. We were too conservative in the following type of programs: ``` { { let x; ... } let x; } ``` We used to report "x" as under TDZ when calling getVariablesUnderTDZ at the "...", even though "x" is not under TDZ. This patch removes this conservatism and makes the algorithm precise. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::getVariablesUnderTDZ): * bytecompiler/BytecodeGenerator.h: 2016-07-03 Filip Pizlo FTL should refer to B3 types directly https://bugs.webkit.org/show_bug.cgi?id=159389 Reviewed by Saam Barati. When we used LLVM, types were objects that were allocated by the LLVMContext. We had to remember pointers to them or else call through the C API every time we wanted the type. We stored the type pointers inside FTL::CommonValues. But in B3, types are just members of an enum. We don't have to remember pointers to them. This change replaces all prior uses of things like "m_out.int32" with just "Int32", and likewise for m_out.boolean, m_out.int64, m_out.intPtr, m_out.floatType, m_out.doubleType, and m_out.voidType. We still use FTL::CommonValues for common constants that we have pre-hoisted. Hopefully we will come up with a better story for those eventually, since that's still kinda ugly. * ftl/FTLCommonValues.cpp: (JSC::FTL::CommonValues::CommonValues): * ftl/FTLCommonValues.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::createPhiVariables): (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep): (JSC::FTL::DFG::LowerDFGToB3::compileBooleanToNumber): (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): (JSC::FTL::DFG::LowerDFGToB3::compileToThis): (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd): (JSC::FTL::DFG::LowerDFGToB3::compileStrCat): (JSC::FTL::DFG::LowerDFGToB3::compileArithMinOrMax): (JSC::FTL::DFG::LowerDFGToB3::compileArithPow): (JSC::FTL::DFG::LowerDFGToB3::compileArithRound): (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): (JSC::FTL::DFG::LowerDFGToB3::compileGetById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis): (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis): (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage): (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset): (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorById): (JSC::FTL::DFG::LowerDFGToB3::compilePutGetterSetterById): (JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorByVal): (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush): (JSC::FTL::DFG::LowerDFGToB3::compileArrayPop): (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments): (JSC::FTL::DFG::LowerDFGToB3::compileCreateScopedArguments): (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments): (JSC::FTL::DFG::LowerDFGToB3::compileCopyRest): (JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength): (JSC::FTL::DFG::LowerDFGToB3::compileNewObject): (JSC::FTL::DFG::LowerDFGToB3::compileNewArray): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize): (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToB3::compileToNumber): (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor): (JSC::FTL::DFG::LowerDFGToB3::compileToPrimitive): (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt): (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode): (JSC::FTL::DFG::LowerDFGToB3::compileGetByOffset): (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset): (JSC::FTL::DFG::LowerDFGToB3::compilePutByOffset): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileSwitch): (JSC::FTL::DFG::LowerDFGToB3::compileIsString): (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): (JSC::FTL::DFG::LowerDFGToB3::compileIsObject): (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull): (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction): (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject): (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView): (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf): (JSC::FTL::DFG::LowerDFGToB3::compileIn): (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance): (JSC::FTL::DFG::LowerDFGToB3::compileCheckTypeInfoFlags): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom): (JSC::FTL::DFG::LowerDFGToB3::compileCountExecution): (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty): (JSC::FTL::DFG::LowerDFGToB3::compileHasGenericProperty): (JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty): (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname): (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumerableLength): (JSC::FTL::DFG::LowerDFGToB3::compileGetPropertyEnumerator): (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorStructurePname): (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorGenericPname): (JSC::FTL::DFG::LowerDFGToB3::compileToIndexString): (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureImmediate): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::compileSetFunctionName): (JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32): (JSC::FTL::DFG::LowerDFGToB3::checkInferredType): (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements): (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage): (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage): (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl): (JSC::FTL::DFG::LowerDFGToB3::getById): (JSC::FTL::DFG::LowerDFGToB3::compare): (JSC::FTL::DFG::LowerDFGToB3::compileResolveScope): (JSC::FTL::DFG::LowerDFGToB3::compileGetDynamicVar): (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject): (JSC::FTL::DFG::LowerDFGToB3::speculateTruthyObject): (JSC::FTL::DFG::LowerDFGToB3::nonSpeculativeCompare): (JSC::FTL::DFG::LowerDFGToB3::stringsEqual): (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject): (JSC::FTL::DFG::LowerDFGToB3::allocateObject): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket): (JSC::FTL::DFG::LowerDFGToB3::boolify): (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined): (JSC::FTL::DFG::LowerDFGToB3::contiguousPutByValOutOfBounds): (JSC::FTL::DFG::LowerDFGToB3::buildSwitch): (JSC::FTL::DFG::LowerDFGToB3::switchStringSlow): (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32): (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32): (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToJSValue): (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToInt52): (JSC::FTL::DFG::LowerDFGToB3::unboxInt32): (JSC::FTL::DFG::LowerDFGToB3::boxInt32): (JSC::FTL::DFG::LowerDFGToB3::isCellOrMisc): (JSC::FTL::DFG::LowerDFGToB3::unboxDouble): (JSC::FTL::DFG::LowerDFGToB3::boxDouble): (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52): (JSC::FTL::DFG::LowerDFGToB3::doubleToStrictInt52): (JSC::FTL::DFG::LowerDFGToB3::convertDoubleToInt32): (JSC::FTL::DFG::LowerDFGToB3::callCheck): (JSC::FTL::DFG::LowerDFGToB3::crash): * ftl/FTLOutput.cpp: (JSC::FTL::Output::bitCast): 2016-07-02 Filip Pizlo DFG LICM needs to go all-in on the idea that some loops can't be LICMed https://bugs.webkit.org/show_bug.cgi?id=159388 Reviewed by Mark Lam. Some time ago I acknowledged that LICM required loops to meet certain requirements that may get broken by the time we do LICM, like that the terminal of the pre-header is ExitOK. It used to be that we just ignored that requirement and would hoist anyway, but since r189126 we've stopped hoisting out of loops that don't have ExitOK. We also added tests for the case that the pre-header doesn't exist or is invalid. It turns out that this patch didn't go far enough: even though it made LICM avoid loops that had an invalid pre-header, the part that updated the AI state in nested loops still assumed that these loops had valid pre-headers. We would crash in null dereference in that loop if a nested loop had an invalid pre-header. The fix is simple: don't update the AI state of nested loops that don't have pre-headers, since we won't try to hoist out of those loops anyway. * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::attemptHoist): * tests/stress/licm-no-pre-header-nested.js: Added. This would always crash before this fix. (foo): * tests/stress/licm-pre-header-cannot-exit-nested.js: Added. This was a failed attempt at a test, but I figure it's good to have weird code anyway. (foo): (valueOf): 2016-06-30 Filip Pizlo Scopes that are not under TDZ should still push their variables onto the TDZ stack so that lifting TDZ doesn't bypass that scope https://bugs.webkit.org/show_bug.cgi?id=159332 rdar://problem/27018958 Reviewed by Saam Barati. This fixes an instacrash in this code: try{}catch(e){}print(e);let e; We lift TDZ for "e" in "catch (e){}", but since that scope doesn't push anything onto the TDZ stack, we lift TDZ from "let e". The problem is that we weren't tracking the set of variables that do not have TDZ. We need to track them to "block" the traversal that lifts TDZ. This change fixes this issue by using a map that tracks all known variables, and tells you if they are under TDZ or not. * bytecode/CodeBlock.h: (JSC::CodeBlock::numParameters): * bytecode/CodeOrigin.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::Label::setLocation): (JSC::Variable::dump): (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::pushLexicalScopeInternal): (JSC::BytecodeGenerator::popLexicalScope): (JSC::BytecodeGenerator::popLexicalScopeInternal): (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration): (JSC::BytecodeGenerator::variable): (JSC::BytecodeGenerator::needsTDZCheck): (JSC::BytecodeGenerator::liftTDZCheckIfPossible): (JSC::BytecodeGenerator::pushTDZVariables): (JSC::BytecodeGenerator::getVariablesUnderTDZ): (JSC::BytecodeGenerator::endGenerator): (WTF::printInternal): * bytecompiler/BytecodeGenerator.h: (JSC::Variable::isConst): (JSC::Variable::setIsReadOnly): * interpreter/CallFrame.h: (JSC::ExecState::topOfFrame): * tests/stress/lift-tdz-bypass-catch.js: Added. (foo): (catch): 2016-07-01 Benjamin Poulain [JSC] RegExp.compile is not returning the regexp when it succeed https://bugs.webkit.org/show_bug.cgi?id=159381 Reviewed by Mark Lam. Spec: -https://tc39.github.io/ecma262/#sec-regexp.prototype.compile -https://tc39.github.io/ecma262/#sec-regexpinitialize * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncCompile): 2016-07-01 Saam Barati fix "ASSERTION FAILED: currentOffset() >= currentLineStartOffset()" https://bugs.webkit.org/show_bug.cgi?id=158572 Reviewed by Mark Lam. There is a bug in our lexer when we notice the pattern: ``` // some comment here``` Our code will say that the token for the comment is a semicolon. This is the correct semantics, however, it would give the semicolon a start offset of the comment, but it will give its line start offset the newline after the comment. This breaks the invariant in the lexer/parser that the offset for the current line starting point must be less than or equal to than the start offset of any token on that line. This invariant was broken because the line start offset was greater than the token start offset. To maintain this invariant, we claim that the semicolon token is located where the comment starts, and that its line start offset is the line start offset for the line with the comment on it. There are other solutions that maintain this invariant, but this solution provides the best error messages. * parser/Lexer.cpp: (JSC::Lexer::lex): * parser/Parser.h: (JSC::Parser::internalSaveLexerState): * tests/stress/obscure-error-message-dont-crash.js: Added. (try.eval.or.catch): 2016-07-01 Benjamin Poulain __defineGetter__/__defineSetter__ should throw exceptions https://bugs.webkit.org/show_bug.cgi?id=142934 Reviewed by Mark Lam. * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncDefineGetter): (JSC::objectProtoFuncDefineSetter): 2016-07-01 Jon Davis Moved Web Animations and Resource Timing feature entries to WebCore. https://bugs.webkit.org/show_bug.cgi?id=159356 Reviewed by Timothy Hatcher. * features.json: 2016-07-01 Benjamin Poulain [JSC] Date.toGMTString should be the Date.toUTCString function https://bugs.webkit.org/show_bug.cgi?id=159318 Reviewed by Mark Lam. See https://tc39.github.io/ecma262/#sec-date.prototype.togmtstring * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): (JSC::dateProtoFuncToGMTString): Deleted. 2016-07-01 Mark Lam Update JSC_functionOverrides to handle the new SourceCode strings that have params. https://bugs.webkit.org/show_bug.cgi?id=159321 Reviewed by Geoffrey Garen. And add tests so that this won't fail silently and bit rot anymore. * API/tests/FunctionOverridesTest.cpp: Added. (testFunctionOverrides): * API/tests/FunctionOverridesTest.h: Added. * API/tests/testapi-function-overrides.js: Added. * API/tests/testapi.c: (main): * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::link): * shell/PlatformWin.cmake: * tools/FunctionOverrides.cpp: (JSC::FunctionOverrides::FunctionOverrides): (JSC::FunctionOverrides::reinstallOverrides): (JSC::initializeOverrideInfo): (JSC::FunctionOverrides::initializeOverrideFor): * tools/FunctionOverrides.h: (JSC::FunctionOverrides::clear): 2016-07-01 Caio Lima ES6: Implement HasRestrictedGlobalProperty when checking for global lexical tier conflicts https://bugs.webkit.org/show_bug.cgi?id=148763 Reviewed by Saam Barati I've implemented the ES6 spec 8.1.1.4.14 (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-hasrestrictedglobalproperty) that defines when a global property can be shadowed. Added some test cases into global-lexical-redeclare-variable.js * runtime/Executable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): * tests/stress/global-lexical-redeclare-variable.js: (catch): * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/eighth.js: Added. * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/nineth.js: Added. * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/seventh.js: Added. * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/sixth.js: * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/tenth.js: Added. 2016-07-01 Youenn Fablet Add a runtime flag for DOM iterators https://bugs.webkit.org/show_bug.cgi?id=159300 Reviewed by Alex Christensen. * runtime/CommonIdentifiers.h: 2016-06-30 Joseph Pecoraro Web Inspector: Wrong function name next to scope https://bugs.webkit.org/show_bug.cgi?id=158210 Reviewed by Timothy Hatcher. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: Add DebuggerLocation. A helper for describing a unique location. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::setConstantRegisters): When compiled with debug info, add a SymbolTable rare data pointer back to the CodeBlock. This will be used later to get JSScope debug info if Web Inspector pauses. * runtime/SymbolTable.h: * runtime/SymbolTable.cpp: (JSC::SymbolTable::cloneScopePart): (JSC::SymbolTable::prepareForTypeProfiling): (JSC::SymbolTable::uniqueIDForVariable): (JSC::SymbolTable::uniqueIDForOffset): (JSC::SymbolTable::globalTypeSetForOffset): (JSC::SymbolTable::globalTypeSetForVariable): Rename rareData and include a CodeBlock pointer. (JSC::SymbolTable::rareDataCodeBlock): (JSC::SymbolTable::setRareDataCodeBlock): Setter and getter for the rare data. It should only be set once. (JSC::SymbolTable::visitChildren): Visit the rare data code block if we have one. * runtime/JSSymbolTableObject.h: * runtime/JSSymbolTableObject.cpp: (JSC::JSSymbolTableObject::deleteProperty): (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames): Give JSSymbolTable its own class info. JSWithScope was unexpectedly inheriting from JSSymbolTable since it did not have its own and was using JSScope's class info. Also do a bit of cleanup. * debugger/DebuggerLocation.cpp: Added. (JSC::DebuggerLocation::DebuggerLocation): * debugger/DebuggerLocation.h: Added. (JSC::DebuggerLocation::DebuggerLocation): Construction from a ScriptExecutable. * runtime/JSScope.cpp: (JSC::JSScope::symbolTable): * runtime/JSScope.h: * debugger/DebuggerScope.h: * debugger/DebuggerScope.cpp: (JSC::DebuggerScope::name): (JSC::DebuggerScope::location): Name and location for a scope. This uses: JSScope -> SymbolTable -> CodeBlock -> Executable * inspector/protocol/Debugger.json: * inspector/InjectedScriptSource.js: (InjectedScript.CallFrameProxy.prototype._wrapScopeChain): (InjectedScript.CallFrameProxy._createScopeJson): * inspector/JSJavaScriptCallFrame.cpp: (Inspector::valueForScopeType): (Inspector::valueForScopeLocation): (Inspector::JSJavaScriptCallFrame::scopeDescriptions): (Inspector::JSJavaScriptCallFrame::scopeType): Deleted. * inspector/JSJavaScriptCallFrame.h: * inspector/JSJavaScriptCallFramePrototype.cpp: (Inspector::JSJavaScriptCallFramePrototype::finishCreation): (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions): (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted. Simplify this code to build the objects we will send across the protocol to descript a Scope. 2016-06-30 Saam Barati missing exception checks in arrayProtoFuncReverse https://bugs.webkit.org/show_bug.cgi?id=159319 Reviewed by Filip Pizlo. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncToString): (JSC::arrayProtoFuncReverse): 2016-06-30 Saam Barati get_by_id_with_this does not trigger a to_this in caller. https://bugs.webkit.org/show_bug.cgi?id=159226 Reviewed by Keith Miller. This is a bug if the caller is in sloppy mode and the callee is in strict mode. This can't happen with ES6 classes because they're all in strict mode, but it can happen with method syntax on an object literal. The caller must to_this on |this| when it knows that it performs super property accesses. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * tests/stress/super-property-access-object-literal-to-this-2.js: Added. (assert): (test): (let.o1.get foo): (let.o2.a): (let.o2.aa): * tests/stress/super-property-access-object-literal-to-this.js: Added. (assert): (test): (let.o1.get foo): (let.o2.a): (let.o2.aa): (let.o2.b): (let.o2.bb): * tests/stress/super-property-access-to-this.js: Added. (assert): (test): (Base.prototype.get foo): (Base): (Child.prototype.a): (Child.prototype.b): (Child): 2016-06-30 Saam Barati We need to to_this when an inner arrow function uses 'this' https://bugs.webkit.org/show_bug.cgi?id=159290 Reviewed by Geoffrey Garen. We put the |this| value into the closure object when there is an arrow function that uses |this|. However, an arrow function using |this| wasn't causing the creator of the closure that holds |this| to to_this its value before putting it in the closure. That's a huge bug because it means some arrow functions can capture the raw |this| value, which might be a JSLexicalEnvironment. This patch fixes this by adding an easy to check to see if any inner arrow functions use |this|, and if any do, it will to_this the |this| value. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * tests/stress/to-this-before-arrow-function-closes-over-this-that-starts-as-lexical-environment.js: Added. (assert): (obj): (foo.capture): (foo.wrapper.let.x.): (foo2.capture): (foo2.wrapper.let.x.): (foo2.wrapper.bar): 2016-06-29 Filip Pizlo Generators violate bytecode liveness validation https://bugs.webkit.org/show_bug.cgi?id=159279 Reviewed by Yusuke Suzuki. Fix a liveness bug found by Basic. The problem is that resume's intended liveness rule is: "live-in is just the token argument", but the liveness analysis thought that the rule was "live-in is live-out minus defs plus live-at-catch". Clearly these two rules are quite different. The way this sort of worked before is that we would define the defs of resume as being equal to our prediction of what the live-outs would be. We did this in the hope that we would subtract all live-outs. But, this misses the live-at-catch part. So, this change adds another hack to neutralize live-at-catch. This would make a lot more sense if we wrote a new liveness analysis that was just for generator conversion. It could reuse BytecodeUseDef but otherwise it would be a new thing. It would be easy to write crazy rules for save/resume in such an analysis, especially if that analysis rewrote the bytecode. We could then just have an op_yield that is a no-op. We would just record the live-outs of op_yield and use that for rewriting the code in terms of a switch statement. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::stepOverInstruction): (JSC::BytecodeLivenessAnalysis::dumpResults): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): 2016-06-30 Commit Queue Unreviewed, rolling out r202659. https://bugs.webkit.org/show_bug.cgi?id=159305 The test for this change times out on mac-wk2 debug and caused an existing test to crash. (Requested by ryanhaddad on #webkit). Reverted changeset: "Web Inspector: Wrong function name next to scope" https://bugs.webkit.org/show_bug.cgi?id=158210 http://trac.webkit.org/changeset/202659 2016-06-30 Benjamin Poulain [JSC] Date.setYear() misses timeClip() https://bugs.webkit.org/show_bug.cgi?id=159289 Reviewed by Geoffrey Garen. * runtime/DatePrototype.cpp: (JSC::dateProtoFuncSetYear): 2016-06-30 Joseph Pecoraro and Yusuke Suzuki [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values https://bugs.webkit.org/show_bug.cgi?id=154022 Reviewed by Filip Pizlo. We aim at optimizing @toInteger operation. While it still has an unoptimized part[1], this patch should be a first step. We introduce the @toNumber builtin intrinsic operation. This converts the given value to the JS number by emitting op_to_number bytecode. Previously @toInteger called C++ @Number constructor for that purpose. And in DFG, op_to_number is converted to DFG ToNumber node. During DFG, we attempt to convert this to edge filtering and Identity, but if we fail, we just fall back to calling the C++ function. To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS. Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number. But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable. By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger. ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation. This value profiling is provided from either NumberConstructor's call operation or op_to_number. The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit. And ASMBench/n-body.c also shows stable ~2% progression. [1]: https://bugs.webkit.org/show_bug.cgi?id=153738 * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/BuiltinNames.h: * builtins/GlobalObject.js: (globalPrivate.isFinite): (globalPrivate.isNaN): (globalPrivate.toInteger): Deleted. (globalPrivate.toLength): Deleted. (globalPrivate.isDictionary): Deleted. (globalPrivate.speciesGetter): Deleted. (globalPrivate.speciesConstructor): Deleted. * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js. (globalPrivate.toInteger): (globalPrivate.toLength): (globalPrivate.isDictionary): (globalPrivate.speciesGetter): (globalPrivate.speciesConstructor): * builtins/NumberConstructor.js: Added. (isFinite): (isNaN): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::finishCreation): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitUnaryOp): (JSC::BytecodeGenerator::emitUnaryOpProfiled): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitToNumber): * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber): (JSC::UnaryPlusNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::attemptToInlineCall): (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): (JSC::DFG::ByteCodeParser::parseBlock): We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode. According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupToNumber): * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: Always on the heap prediction. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since it may be reuse the argument registers and it can break the argument registers before using them to call the operation. Currently, we allocate the additional temporary register for that scratch register. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node. This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes the spills to call the operation. The example of the actually emitted code is the following. 76: ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48) predicting DoubleimpurenanTopEmpty 0x7f986d5fe693: test %rax, %r14 0x7f986d5fe696: jz 0x7f986d5fe6a1 0x7f986d5fe69c: jmp 0x7f986d5fe6d1 0x7f986d5fe6a1: mov %rax, %rsi 0x7f986d5fe6a4: mov %rbp, %rdi 0x7f986d5fe6a7: mov $0x2, 0x24(%rbp) 0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11 0x7f986d5fe6b8: call *%r11 0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11 0x7f986d5fe6c5: mov (%r11), %r11 0x7f986d5fe6c8: test %r11, %r11 0x7f986d5fe6cb: jnz 0x7f986d5fe88c It effectively removes the unnecessary spill to call the operation! * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileToNumber): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchIfNumber): (JSC::AssemblyHelpers::branchIfNotNumber): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_to_number): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_to_number): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * parser/Nodes.h: (JSC::UnaryOpNode::opcodeID): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncIsNaN): Deleted. (JSC::globalFuncIsFinite): Deleted. * runtime/JSGlobalObjectFunctions.h: * runtime/MathCommon.h: (JSC::maxSafeInteger): (JSC::minSafeInteger): * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::finishCreation): (JSC::numberConstructorFuncIsFinite): Deleted. (JSC::numberConstructorFuncIsNaN): Deleted. * runtime/NumberConstructor.h: * tests/stress/Number-isNaN-basics.js: Added. (numberIsNaNOnInteger): (testNumberIsNaNOnIntegers): (verifyNumberIsNaNOnIntegerWithOtherTypes): (numberIsNaNOnDouble): (testNumberIsNaNOnDoubles): (verifyNumberIsNaNOnDoublesWithOtherTypes): (numberIsNaNNoArguments): (numberIsNaNTooManyArguments): (testNumberIsNaNOnConstants): (numberIsNaNStructTransition): (Number.isNaN): * tests/stress/global-is-finite.js: Added. (shouldBe): * tests/stress/global-is-nan.js: Added. (shouldBe): * tests/stress/global-isNaN-basics.js: Added. (isNaNOnInteger): (testIsNaNOnIntegers): (verifyIsNaNOnIntegerWithOtherTypes): (isNaNOnDouble): (testIsNaNOnDoubles): (verifyIsNaNOnDoublesWithOtherTypes): (verifyIsNaNOnCoercedTypes): (isNaNNoArguments): (isNaNTooManyArguments): (testIsNaNOnConstants): (isNaNTypeCoercionSideEffects): (i.value.isNaNTypeCoercionSideEffects.valueOf): (isNaNStructTransition): (isNaN): * tests/stress/number-is-finite.js: Added. (shouldBe): (test2): (test3): * tests/stress/number-is-nan.js: Added. (shouldBe): (test2): (test3): * tests/stress/to-number-basics.js: Added. (shouldBe): * tests/stress/to-number-convert-identity-without-execution.js: Added. (shouldBe): (object.valueOf): (valueOf): * tests/stress/to-number-int52.js: Added. (shouldBe): (object.valueOf): * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added. (shouldBe): (object.valueOf): (valueOf): * tests/stress/to-number-intrinsic-int52.js: Added. (shouldBe): (object.valueOf): * tests/stress/to-number-intrinsic-object-without-execution.js: Added. (shouldBe): (object.valueOf): * tests/stress/to-number-intrinsic-value-profiling.js: Added. (shouldBe): (object.valueOf): * tests/stress/to-number-object-without-execution.js: Added. (shouldBe): (object.valueOf): * tests/stress/to-number-object.js: Added. (shouldBe): (test12): (object1.valueOf): (test2): (test22): (object2.valueOf): (test3): (test32): (object3.valueOf): * tests/stress/to-number-value-profiling.js: Added. (shouldBe): (object.valueOf): 2016-06-29 Benjamin Poulain Fix the debug build after r202667 * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): The putDirect was missing the Accessor flag for the GetterSetter. 2016-06-29 Michael Saboff REGRESSION(200114): Netflix app does not see ChromeCast https://bugs.webkit.org/show_bug.cgi?id=159287 Reviewed by Benjamin Poulain. Change set 200114 changed the behavior of how we check for whether or not we wrap Objective C init methods in JavaScript constructors. The prior method checked the version of JavaScriptCore that was linked with the application. If the application was not directly linked with JavaScriptCore the prior method indicated that we shouldn't create constructors. The new method uses the SDK the application was compiled with. Using the new method, an application compiled with iOS SDK 8.0 or greater would create constructors and not export init methods to JavaScript. The problem is that an existing application that hasn't been recompiled will get a different answer using the new method. We need to come up with a method that works in a compatible way with existing programs, but provides a newly compiled program with the "is built with SDK N or greater" check. Added back the prior check of the version of JavaScriptCore the program was directly linked against. However we only use this check if we directly linked with JavaScriptCore. Otherwise we fall through to check against the SDK the program was built with. Changed the iOS SDK version we check against to be the new version of iOS, iOS 10. This provides compatible behavior for existing programs. It may be the case that some of those programs may require changes when they are rebuilt with the iOS 10 SDK or later. * API/JSWrapperMap.mm: (supportsInitMethodConstructors): 2016-06-29 Benjamin Poulain [JSC] Minor TypedArray fixes https://bugs.webkit.org/show_bug.cgi?id=159286 Reviewed by Keith Miller. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::finishCreation): See https://tc39.github.io/ecma262/#sec-%typedarray% * runtime/JSTypedArrayViewPrototype.cpp: (JSC::typedArrayViewPrivateFuncLength): See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype.length (JSC::typedArrayViewProtoGetterFuncToStringTag): Yep, that's odd. See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype-@@tostringtag (JSC::JSTypedArrayViewPrototype::finishCreation): See the last paragraph of https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects 2016-06-29 Joseph Pecoraro Web Inspector: API View of Native DOM APIs looks poor (TypeErrors for native getters) https://bugs.webkit.org/show_bug.cgi?id=158334 Reviewed by Timothy Hatcher. * inspector/InjectedScriptSource.js: (InjectedScript.prototype._getProperties): (InjectedScript.prototype._propertyDescriptors): Do not create fake value property descriptors for native accessors unless requested. This means, getProperties for a native prototype should return accessors for native accessors just like it does for normal non-native accessors (getters/setters). (InjectedScript.prototype.getProperties): Do not produce fake value accessors for native accessors. (InjectedScript.prototype.getDisplayableProperties): (InjectedScript.RemoteObject.prototype._generatePreview): Do produce fake value accessors for native accessors. 2016-06-29 Saam barati JSGlobalLexicalEnvironment needs a toThis implementation https://bugs.webkit.org/show_bug.cgi?id=159285 Reviewed by Mark Lam. This was a huge oversight of my original implementation. It gave users of the language direct access to the JSGlobalLexicalEnvironment object. * runtime/JSGlobalLexicalEnvironment.cpp: (JSC::JSGlobalLexicalEnvironment::isConstVariable): (JSC::JSGlobalLexicalEnvironment::toThis): * runtime/JSGlobalLexicalEnvironment.h: (JSC::JSGlobalLexicalEnvironment::isEmpty): * tests/stress/global-lexical-environment-to-this.js: Added. (assert): (let.f): (let.fStrict): 2016-06-29 Joseph Pecoraro Web Inspector: Wrong function name next to scope https://bugs.webkit.org/show_bug.cgi?id=158210 Reviewed by Brian Burg. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: Add DebuggerLocation. A helper for describing a unique location. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::setConstantRegisters): When compiled with debug info, add a SymbolTable rare data pointer back to the CodeBlock. This will be used later to get JSScope debug info if Web Inspector pauses. * runtime/SymbolTable.h: * runtime/SymbolTable.cpp: (JSC::SymbolTable::cloneScopePart): (JSC::SymbolTable::prepareForTypeProfiling): (JSC::SymbolTable::uniqueIDForVariable): (JSC::SymbolTable::uniqueIDForOffset): (JSC::SymbolTable::globalTypeSetForOffset): (JSC::SymbolTable::globalTypeSetForVariable): Rename rareData and include a CodeBlock pointer. (JSC::SymbolTable::rareDataCodeBlock): (JSC::SymbolTable::setRareDataCodeBlock): Setter and getter for the rare data. It should only be set once. (JSC::SymbolTable::visitChildren): Visit the rare data code block if we have one. * debugger/DebuggerLocation.cpp: Added. (JSC::DebuggerLocation::DebuggerLocation): * debugger/DebuggerLocation.h: Added. (JSC::DebuggerLocation::DebuggerLocation): Construction from a ScriptExecutable. * runtime/JSScope.cpp: (JSC::JSScope::symbolTable): * runtime/JSScope.h: * debugger/DebuggerScope.h: * debugger/DebuggerScope.cpp: (JSC::DebuggerScope::name): (JSC::DebuggerScope::location): Name and location for a scope. This uses: JSScope -> SymbolTable -> CodeBlock -> Executable * inspector/protocol/Debugger.json: * inspector/InjectedScriptSource.js: (InjectedScript.CallFrameProxy.prototype._wrapScopeChain): (InjectedScript.CallFrameProxy._createScopeJson): * inspector/JSJavaScriptCallFrame.cpp: (Inspector::valueForScopeType): (Inspector::valueForScopeLocation): (Inspector::JSJavaScriptCallFrame::scopeDescriptions): (Inspector::JSJavaScriptCallFrame::scopeType): Deleted. * inspector/JSJavaScriptCallFrame.h: * inspector/JSJavaScriptCallFramePrototype.cpp: (Inspector::JSJavaScriptCallFramePrototype::finishCreation): (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions): (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted. Simplify this code to build the objects we will send across the protocol to descript a Scope. 2016-06-29 Saam barati We don't emit TDZ checks for call_eval https://bugs.webkit.org/show_bug.cgi?id=159277 Reviewed by Benjamin Poulain. This is a problem if you're trying to call a TDZ variable that is named 'eval'. * bytecompiler/NodesCodegen.cpp: (JSC::EvalFunctionCallNode::emitBytecode): * tests/stress/variable-named-eval-under-tdz.js: Added. (shouldThrowTDZ): (test): (test.foo): (throw.new.Error): 2016-06-29 Mark Lam Add support for collecting cumulative LLINT stats via a JSC_llintStatsFile option. https://bugs.webkit.org/show_bug.cgi?id=159274 Reviewed by Keith Miller. * jsc.cpp: (main): * llint/LLIntData.cpp: (JSC::LLInt::initialize): (JSC::LLInt::Data::finalizeStats): (JSC::LLInt::compareStats): (JSC::LLInt::Data::dumpStats): (JSC::LLInt::Data::ensureStats): (JSC::LLInt::Data::loadStats): (JSC::LLInt::Data::resetStats): (JSC::LLInt::Data::saveStats): * llint/LLIntData.h: (JSC::LLInt::Data::opcodeStats): * runtime/Options.cpp: (JSC::Options::isAvailable): (JSC::recomputeDependentOptions): (JSC::Options::initialize): * runtime/Options.h: 2016-06-29 Saam barati Destructuring variable declaration is missing a validation of the syntax of a sub production when there is a rhs https://bugs.webkit.org/show_bug.cgi?id=159267 Reviewed by Mark Lam. We were parsing something without checking if it had a syntax error. This is wrong for many reasons, but it could actually cause a crash in a debug build if you parsed particular programs. * parser/Parser.cpp: (JSC::Parser::parseVariableDeclarationList): 2016-06-29 Joseph Pecoraro Web Inspector: Show Shadow Root type in DOM Tree https://bugs.webkit.org/show_bug.cgi?id=159236 Reviewed by Timothy Hatcher. * inspector/protocol/DOM.json: Include optional shadowRootType property for DOMNodes. 2016-06-29 Commit Queue Unreviewed, rolling out r202627. https://bugs.webkit.org/show_bug.cgi?id=159266 patch is broken on arm (Requested by keith_miller on #webkit). Reverted changeset: "LLInt should support other types of prototype GetById caching." https://bugs.webkit.org/show_bug.cgi?id=158083 http://trac.webkit.org/changeset/202627 2016-06-29 Benjamin Poulain [JSC] Fix small issues of TypedArray prototype https://bugs.webkit.org/show_bug.cgi?id=159248 Reviewed by Saam Barati. First, TypedArray's toString and Array's toString should be the same function. I moved the function to GlobalObject and each array type gets it as needed. Then TypedArray length was supposed to be configurable. I removed the "DontDelete" flag accordingly. * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::arrayProtoToStringFunction): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): 2016-06-29 Caio Lima LLInt should support other types of prototype GetById caching. https://bugs.webkit.org/show_bug.cgi?id=158083 Recently, we started supporting prototype load caching for get_by_id in the LLInt. This patch is expading the caching strategy to enable cache the prototype accessor and custom acessors. Similarly to the get_by_id_proto_load bytecode, we are adding new bytecodes called get_by_id_proto_accessor that uses the calculated offset of a object to call a getter function and get_by_id_proto_custom that stores the pointer to the custom function and call them directly from LowLevelInterpreter. Reviewed by Keith Miller * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::printGetByIdOp): (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::finalizeLLIntInlineCaches): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setupGetByIdPrototypeCache): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2016-06-28 Commit Queue Unreviewed, rolling out r202580. https://bugs.webkit.org/show_bug.cgi?id=159245 Caused all WKTR tests to fail on GuardMalloc and Production only for unknown reasons, investigating offline. (Requested by brrian on #webkit). Reverted changeset: "RunLoop::Timer should use constructor templates instead of class templates" https://bugs.webkit.org/show_bug.cgi?id=159153 http://trac.webkit.org/changeset/202580 2016-06-28 Keith Miller We should not crash there is a finally inside a for-in loop https://bugs.webkit.org/show_bug.cgi?id=159243 Reviewed by Benjamin Poulain. Previously we would swap the m_forInContext with an empty vector then attempt to shrink the size of m_forInContext by the amount we expected. This meant that if there was more than one ForInContext on the stack and we wanted to pop exactly one off we would crash. This patch makes ForInContexts RefCounted so they can be duplicated into other vectors. It also has ForInContexts copy the entire stack rather than do the swap that we did before. This makes ForInContexts work the same as the other contexts. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitComplexPopScopes): (JSC::BytecodeGenerator::pushIndexedForInScope): (JSC::BytecodeGenerator::pushStructureForInScope): * bytecompiler/BytecodeGenerator.h: * tests/stress/finally-for-in.js: Added. (repeat): (createSimple): 2016-06-28 Saam Barati Assertion failure or crash when accessing let-variable in TDZ with eval with a function in it that returns let variable https://bugs.webkit.org/show_bug.cgi?id=158796 Reviewed by Michael Saboff. There was a bug where some functions inside of an eval were omitting a necessary TDZ check. This obviously leads to bad things because a variable under TDZ is the null pointer. The eval's bytecode was generated with the correct TDZ set, but it created all its functions before pushing that TDZ set onto the stack. That's a mistake. Those functions need to be created with that TDZ set. The solution is simple, the TDZ set that the eval is created with needs to be pushed onto the TDZ stack before the eval creates any functions. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * tests/stress/variable-under-tdz-eval-tricky.js: Added. (assert): (throw.new.Error): (assert.try.underTDZ): 2016-06-28 Michael Saboff REGRESSION (r200946): Improper backtracking from last alternative in sticky patterns https://bugs.webkit.org/show_bug.cgi?id=159233 Reviewed by Mark Lam. Jump to fail exit code when the last alternative of a sticky pattern fails. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::backtrack): 2016-06-28 Saam Barati some Watchpoints' ::fireInternal method will call operations that might GC where the GC will cause the watchpoint itself to destruct https://bugs.webkit.org/show_bug.cgi?id=159198 Reviewed by Filip Pizlo. Firing a watchpoint may cause a GC to happen. This GC could destroy various Watchpoints themselves while they're in the process of firing. It's not safe for most Watchpoints to be destructed while they're in the middle of firing. This GC could also destroy the WatchpointSet itself, and it's not in a safe state to be destroyed. WatchpointSet::fireAllWatchpoints now defers gc for a while. This prevents a GC from destructing any Watchpoints while they're in the process of firing. This bug was being hit by the stress GC bots because we would destruct a particular Watchpoint while it was firing, and then we would access its field after it had already been destroyed. This was causing all kinds of weird symptoms. Also, this was easier to catch when running with guard malloc because the first access after destruction would lead to a crash. * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp: (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecode/VariableWriteFireDetail.cpp: (JSC::VariableWriteFireDetail::dump): (JSC::VariableWriteFireDetail::touch): * bytecode/VariableWriteFireDetail.h: * bytecode/Watchpoint.cpp: (JSC::WatchpointSet::add): (JSC::WatchpointSet::fireAllSlow): (JSC::WatchpointSet::fireAllWatchpoints): (JSC::InlineWatchpointSet::add): (JSC::InlineWatchpointSet::fireAll): (JSC::InlineWatchpointSet::inflateSlow): * bytecode/Watchpoint.h: (JSC::WatchpointSet::startWatching): (JSC::WatchpointSet::fireAll): (JSC::WatchpointSet::touch): (JSC::WatchpointSet::invalidate): (JSC::WatchpointSet::isBeingWatched): (JSC::WatchpointSet::offsetOfState): (JSC::WatchpointSet::addressOfSetIsNotEmpty): (JSC::InlineWatchpointSet::startWatching): (JSC::InlineWatchpointSet::fireAll): (JSC::InlineWatchpointSet::invalidate): (JSC::InlineWatchpointSet::touch): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * dfg/DFGOperations.cpp: * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * jsc.cpp: (WTF::Masquerader::create): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/ArrayBufferNeuteringWatchpoint.cpp: (JSC::ArrayBufferNeuteringWatchpoint::fireAll): * runtime/FunctionRareData.cpp: (JSC::FunctionRareData::clear): * runtime/InferredType.cpp: (JSC::InferredType::willStoreValueSlow): (JSC::InferredType::makeTopSlow): (JSC::InferredType::set): (JSC::InferredType::removeStructure): (JSC::InferredType::InferredStructureWatchpoint::fireInternal): * runtime/InferredValue.cpp: (JSC::InferredValue::notifyWriteSlow): (JSC::InferredValue::ValueCleanup::finalizeUnconditionally): * runtime/InferredValue.h: (JSC::InferredValue::notifyWrite): (JSC::InferredValue::invalidate): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::haveABadTime): * runtime/JSSymbolTableObject.h: (JSC::symbolTablePutTouchWatchpointSet): (JSC::symbolTablePutInvalidateWatchpointSet): * runtime/Structure.cpp: (JSC::Structure::didCachePropertyReplacement): (JSC::Structure::startWatchingInternalProperties): (JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire): (JSC::DeferredStructureTransitionWatchpointFire::add): (JSC::Structure::didTransitionFromThisStructure): (JSC::Structure::prototypeForLookup): * runtime/StructureInlines.h: (JSC::Structure::didReplaceProperty): (JSC::Structure::propertyReplacementWatchpointSet): * runtime/SymbolTable.h: (JSC::SymbolTableEntry::isDontEnum): (JSC::SymbolTableEntry::disableWatching): * runtime/VM.cpp: (JSC::VM::addImpureProperty): (JSC::enableProfilerWithRespectToCount): 2016-06-28 Filip Pizlo JSRopeString should use release asserts, not debug asserts, about substring bounds https://bugs.webkit.org/show_bug.cgi?id=159227 Reviewed by Saam Barati. According to my experiments this change costs nothing. That's not surprising since the most common way to construct a rope these days is inlined into the JIT, which does its own safety checks. This makes us crash sooner rather than corrupting memory. * runtime/JSString.h: 2016-06-28 Brian Burg RunLoop::Timer should use constructor templates instead of class templates https://bugs.webkit.org/show_bug.cgi?id=159153 Reviewed by Alex Christensen. Remove the RunLoop::Timer class template argument, and pass its constructor a reference to `this` instead of a pointer to `this`. * inspector/agents/InspectorHeapAgent.cpp: (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask): 2016-06-28 Joseph Pecoraro Web Inspector: selectElement.options shows unexpected entries in console (named indexes beyond collection length) https://bugs.webkit.org/show_bug.cgi?id=159192 Reviewed by Timothy Hatcher. * inspector/InjectedScriptSource.js: (InjectedScript.prototype.arrayIndexPropertyNames): Start with an empty array because we just push valid indexes. (InjectedScript.prototype._propertyDescriptors): Avoid the >100 length requirement, and always treat the array-like objects the same. The frontend currently doesn't show named indexes for arrays anyways, so they would have been unused. 2016-06-28 Per Arne Vollan [Win] Skip failing INTL test. https://bugs.webkit.org/show_bug.cgi?id=159141 Reviewed by Brent Fulgham. INTL is not enabled on Windows. * tests/stress/intl-constructors-with-proxy.js: (shouldBe): 2016-06-28 Joonghun Park [JSC] Fix build break since r202502 - 2 https://bugs.webkit.org/show_bug.cgi?id=159194 Reviewed by Gyuyoung Kim. Fix about the error message below. error: control reaches end of non-void function [-Werror=return-type] * b3/B3TypeMap.h: add #pragma GCC diagnostic ignored "-Wreturn-type". 2016-06-28 Joonghun Park [JSC] Fix build break since r202502 https://bugs.webkit.org/show_bug.cgi?id=159194 Reviewed by Alex Christensen. Fix about the error message below. error: control reaches end of non-void function [-Werror=return-type] * b3/B3TypeMap.h: (JSC::B3::TypeMap::at): add missing ASSERT_NOT_REACHED(). 2016-06-27 Keith Miller Fix bad assert in StructureRareData::setObjectToStringValue https://bugs.webkit.org/show_bug.cgi?id=159171 Reviewed by Mark Lam. We should not have expected the generateConditionsForPrototypePropertyHit would succeed. There are many reasons it might fail including that there is a proxy somewhere on the prototype chain of the object. * runtime/StructureRareData.cpp: (JSC::StructureRareData::setObjectToStringValue): * tests/stress/object-toString-with-proxy.js: Added. (get target): 2016-06-27 Filip Pizlo Crashing at an unreachable code trap in FTL should give more information https://bugs.webkit.org/show_bug.cgi?id=159177 Reviewed by Saam Barati. This stuffs information into registers so that we have some chance of seeing what happened by looking at the register dumps. * assembler/AbortReason.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::ftlUnreachable): (JSC::FTL::DFG::LowerDFGToB3::compileBlock): (JSC::FTL::DFG::LowerDFGToB3::crash): 2016-06-27 Filip Pizlo Clean up resetting reachability in B3/Air https://bugs.webkit.org/show_bug.cgi?id=159170 Reviewed by Geoffrey Garen. When I fixed bug 159165, I took the brute force approach. I still used the B3::resetReachability() method, and changed the callback to record the set of deleted values instead of deleting them eagerly. But this means tracking the set of deleted values, even though resetReachability() already internally tracks the set of deleted blocks. You can find out if a value is deleted by asking if its owning block was deleted. So, this change refactors B3::resetReachability() into a new helper called B3::recomputePredecessors(). This new helper skips the block deletion step, and lets the client delete blocks. This lets Air delete blocks the same way that it did before, and it lets B3 use the isBlockDead() method (which is a glorified proxy for block->predecessors().isEmpty()) to track which values are deleted. This allows B3 to turn Upsilons that point to dead Phis into Nops before deleting the blocks. This shouldn't affect performance or anything real. It just makes the code cleaner. * b3/B3BasicBlockUtils.h: (JSC::B3::updatePredecessorsAfter): (JSC::B3::recomputePredecessors): (JSC::B3::isBlockDead): (JSC::B3::resetReachability): Deleted. * b3/B3Procedure.cpp: (JSC::B3::Procedure::resetReachability): (JSC::B3::Procedure::invalidateCFG): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::resetReachability): (JSC::B3::Air::Code::dump): 2016-06-27 Brian Burg Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page https://bugs.webkit.org/show_bug.cgi?id=159075 Reviewed by Filip Pizlo. This change caused JSC stress tests to all hit an assertion in RunLoop. We should use RunLoop::current() to create the RunLoop::Timer since JSC-only clients like testapi and jsc don't ever call initializeMainRunLoop(). * inspector/agents/InspectorHeapAgent.cpp: (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask): 2016-06-27 Filip Pizlo B3::Procedure::resetReachability() can create dangling references from Upsilons to Phis https://bugs.webkit.org/show_bug.cgi?id=159165 Reviewed by Mark Lam. You can delete an unreachable block that has a Phi but some prior block may still have an Upsilon pointing to that Phi. This can happen if the Upsilon precedes a Check that always exits or it can happen if we remove some successor of a block and this block had an Upsilon for one of the removed successors. These things are valid IR even if they are not canonical. Our policy for not-canonical-but-valid IR is that the compiler should still emit valid code in the end. The solution is to have Procedure::resetReachability() turn those Upsilons into Nops. * b3/B3Procedure.cpp: (JSC::B3::Procedure::resetReachability): Fix the bug. * b3/B3Validate.h: * b3/testb3.cpp: (JSC::B3::testResetReachabilityDanglingReference): Add a test. This always crashes prior to this change. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::killUnreachableBlocks): Add a FIXME about a possible similar bug. 2016-06-27 Keith Miller Add comment to Module feature in features.json https://bugs.webkit.org/show_bug.cgi?id=159159 Reviewed by Saam Barati. * features.json: 2016-06-27 Keith Miller Update features.json for ES6 completed features. https://bugs.webkit.org/show_bug.cgi?id=159152 Reviewed by Mark Lam. * features.json: 2016-06-25 Filip Pizlo B3 should not use Nops when deleting unreachable code https://bugs.webkit.org/show_bug.cgi?id=159120 rdar://problem/26500743 Reviewed by Michael Saboff. Prior to this change, transformations that obviated the need for some value could choose from these ways to kill it: - replaceWithIdentity() if we're replacing with another value. - replaceWithNop() if the type is Void or if we know that we'll fix any users of this value. - deleteValue() if the code is unreachable. The bug here is that reduceStrength() was being clever about how to get rid of a value. reduceStrength() may find a Check that must always exit. The goal is to remove any code dominated by the Check. But it would be awkward to eagerly delete all of the blocks dominated by this one. So this code took a much simpler approach: it would replaceWithNop() for all of the values in this block after the Check and it would replace the terminal with Oops. But this corrupts the IR in a subtle way: some of those values may have been non-Void but now they are Nops so they are Void. reduceStrength() will not yet realize that the blocks dominated by the one with the Check are unreachable, so it will run all sorts of optimizations on those blocks. This could have probably manifested as many different kinds of badness, but the way I found out about this issue was through a crash in IntRange::top(Type) when inlined into ReduceStrength::rangeFor(). We'd die in a switch statement over a child's type. We could fix this by making rangeFor() tolerate Void. But I think that this would be dangerous. There could easily be other places in reduceStrength() that assume that value's children are non-Void. So, this change fixes the Check optimization and adds mechanisms to prevent other optimizations from breaking the children-are-not-Void rule. This introduces two high-level changes: - It's no longer legal to replaceWithNop() if the value is not Void. This change alone would cause reduceStrength() to instacrash in its Check optimization. Almost all other uses of replaceWithNop() were already following this rule, so they were fine. One other place was using replaceWithNop() on non-Void values after arranging for them to no longer have any parents. That was changed to call replaceWithNopIgnoringType(), which doesn't have any type assertions. - For reduceStrength() there is a new Value::replaceWithBottom() method that works with Void or non-Void and behaves like you would want replaceWithNop() to behave: if you know that the code is unreachable then it produces something that is guaranteed to be deleted by later optimizations, and if it's not unreachable, then it's guaranteed to be compiled to something harmless and cheap. This means replacing the value with an identity that points to a bottom constant (the 0 for whatever type we have), or just replacing it with Nop if it's Void. This also adds a test case for the reason why we do this: we may have two blocks, where the first block unconditionally exits while dominating the second block. The second block references values in the part of the first block that is unreachable. In trunk, this test would assert in ReduceStrength::rangeFor() because the CheckAdd in the second block would reference a Nop in the first block. This fixes a high volume crash in ReduceStrength::rangeFor(). This crash was very confusing. Even though we were crashing at a RELEASE_ASSERT_NOT_REACHED() in a switch statement in IntRange::top(Type), clang was merging that trap with the trap it used for Vector OOB. The top of the stack in crash dumps looked like: JSC::B3::(anonymous namespace)::ReduceStrength::rangeFor(JSC::B3::Value*, unsigned int) + 4477 (Vector.h:655) Where Vector.h:655 is: OverflowHandler::overflowed(); But this crash was not at Vector.h:655. It was at B3ReduceStrength.cpp:121. The two lines are both traps, so they got merged despite differences in debug info. This bug would have been so much easier to fix if I had the right line number. * b3/B3BottomProvider.h: Added. This is a utility for creating bottom values. (JSC::B3::BottomProvider::BottomProvider): (JSC::B3::BottomProvider::operator()): * b3/B3InsertionSet.cpp: Optimized adding bottom values a bit. We will no longer create pointless duplicates. (JSC::B3::InsertionSet::insertBottom): (JSC::B3::InsertionSet::execute): (JSC::B3::InsertionSet::bottomForType): * b3/B3InsertionSet.h: * b3/B3MoveConstants.cpp: Use replaceWithNopIgnoringType() because we *know* that we can replaceWithNop even for non-Void. * b3/B3Procedure.h: * b3/B3ReduceStrength.cpp: Use replaceWithBottom(). * b3/B3ReduceStrength.h: * b3/B3TypeMap.h: I figured if I wrote type-casing code like this once then I'd never want to write it again. * b3/B3Value.cpp: (JSC::B3::Value::replaceWithIdentity): (JSC::B3::Value::replaceWithNop): (JSC::B3::Value::replaceWithNopIgnoringType): * b3/B3Value.h: * b3/B3ValueInlines.h: (JSC::B3::Value::replaceWithBottom): This is the new method of killing unreachable code. (JSC::B3::Value::as): * b3/testb3.cpp: Add new tests! (JSC::B3::testLateRegister): (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock): (JSC::B3::zero): (JSC::B3::run): 2016-06-27 Joseph Pecoraro REGRESSION: Web Inspector: Text search broken in resources with https://bugs.webkit.org/show_bug.cgi?id=159110 Reviewed by Brian Burg. * inspector/ContentSearchUtilities.cpp: (Inspector::ContentSearchUtilities::lineEndings): The frontend moved to only treated newlines as line endings in the TextEditor. The backend however was looking for many different types of line endings (\r\n, \r, \n). This caused the line endings to ultimately differ between the frontend and the backend, so the frontend couldn't find the lines that the backend was claiming search results were on. Change the backend to only look for \n line endings. 2016-06-27 Brian Burg Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page https://bugs.webkit.org/show_bug.cgi?id=159075 Reviewed by Timothy Hatcher. Move the asynchronous work to a task class that can be cancelled when the heap agent is reset, disabled or destroyed. * inspector/agents/InspectorHeapAgent.cpp: (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask): (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection): (Inspector::SendGarbageCollectionEventsTask::reset): (Inspector::SendGarbageCollectionEventsTask::timerFired): Added. This holds onto GarbageCollectionData that needs to be sent asynchronously. It uses the RunLoop variant of Timer and can queue multiple collections to be sent. The data vector is guarded with a lock so that garbageCollected() can safely add collection data from a non-main thread while the main thread sends out events. (Inspector::InspectorHeapAgent::InspectorHeapAgent): (Inspector::InspectorHeapAgent::~InspectorHeapAgent): (Inspector::InspectorHeapAgent::disable): Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction. (Inspector::InspectorHeapAgent::didGarbageCollect): Add the collection data to the task, which will dispatch an event for it asynchronously. * inspector/agents/InspectorHeapAgent.h: 2016-06-27 Michael Saboff ES6 Change: Unify handling of RegExp CharacterClassEscapes \w and \W and Word Asserts \b and \B https://bugs.webkit.org/show_bug.cgi?id=158505 Reviewed by Geoffrey Garen. This change makes it so that the CharacterClassEscape \w matches the inverse of \W and vice versa for unicode, ignore case RegExp's. Before this change, both /\w/ui and /\W/ui RegExp's would match the characters k, K, s, S, \u017f (Latin Small Letter Long S) and \u212a (Kelvin Sign). This was due to how the ES6 standard defined matching of character classes specifically that the abstract operation "Canonicalize()" is called for the character to be matched AND for the characters in the character class we are matching against. This change is to make \W always be the inverse of \w. It is still the case that the characters that match against \w changes depending on a regular expression's flags. The only real changes occur for regular expressions with both the unicode and ignore case flags set. Updated the character class generator to make nonwordUnicodeIgnoreCaseChar not include k, K, s, S, \u017f and \u212a. Changed BytecodePattern.wordcharCharacterClass to use the correct word character class for the flags. Simplfied character class set up in in the pattern to use m_pattern.wordUnicodeIgnoreCaseCharCharacterClass and invert as appropriate when unicode and ignore case are both set. * create_regex_tables: * yarr/YarrInterpreter.h: (JSC::Yarr::BytecodePattern::BytecodePattern): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass): 2016-06-25 Keith Miller DFGByteCodeParsing does not handle calling the Object constructor with no arguments correctly https://bugs.webkit.org/show_bug.cgi?id=159117 Reviewed by Saam Barati. DFGByteCodeParsing always assumed there would be an argument to the Object constructor. This is clearly not always the case and we should be able to handle it. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): * tests/stress/indirect-call-object-constructor-with-no-arguments.js: Added. (let.foo.Object.test): 2016-06-24 Filip Pizlo B3 should die sooner if a Value has the wrong number of children https://bugs.webkit.org/show_bug.cgi?id=159108 Reviewed by Mark Lam. I've been looking at a bug (rdar://problem/26500743) that's about a Vector OOB crash in ReduceStrength::rangeFor(). The only Vector accesses are to Value::m_children, and all of the accesses in rangeFor() are for child(0) or child(1) of binary arithmetic opcodes. Clearly those should never go out-of-bounds. Maybe we have horrible memory corruption. Or maybe some path creates a Value with the wrong number of children, and that path is not tested by any of our tests. This patch adds release assertions that will catch the latter. I've tested this a lot. It's not a regression on our benchmarks. * b3/B3Opcode.h: * b3/B3Value.cpp: (JSC::B3::Value::dumpMeta): (JSC::B3::Value::typeFor): (JSC::B3::Value::badOpcode): (JSC::B3::Value::checkOpcode): Deleted. * b3/B3Value.h: 2016-06-24 Mark Lam [JSC] Error prototypes are called on remote scripts. https://bugs.webkit.org/show_bug.cgi?id=52192 Reviewed by Keith Miller. Added a sanitizedToString() to the Error instance object so that it can be used to get an error string without invoking getters and proxies. * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::finishCreation): (JSC::ErrorInstance::sanitizedToString): * runtime/ErrorInstance.h: (JSC::ErrorInstance::createStructure): (JSC::ErrorInstance::runtimeTypeForCause): (JSC::ErrorInstance::clearRuntimeTypeForCause): 2016-06-24 Commit Queue Unreviewed, rolling out r202443. https://bugs.webkit.org/show_bug.cgi?id=159105 Introduced memory corruption crashes (Requested by ap on #webkit). Reverted changeset: "Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page" https://bugs.webkit.org/show_bug.cgi?id=159075 http://trac.webkit.org/changeset/202443 2016-06-24 Brian Burg Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page https://bugs.webkit.org/show_bug.cgi?id=159075 Reviewed by Joseph Pecoraro. Move the asynchronous work to a task class that can be cancelled when the heap agent is reset, disabled or destroyed. * inspector/agents/InspectorHeapAgent.cpp: (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask): (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection): (Inspector::SendGarbageCollectionEventsTask::reset): (Inspector::SendGarbageCollectionEventsTask::timerFired): Added. This holds onto GarbageCollection objects that need to be sent asynchronously. It uses the RunLoop variant of Timer and can queue multiple pending objects to be sent. (Inspector::InspectorHeapAgent::InspectorHeapAgent): (Inspector::InspectorHeapAgent::~InspectorHeapAgent): (Inspector::InspectorHeapAgent::disable): Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction. (Inspector::InspectorHeapAgent::didGarbageCollect): Send the object to the task to be dispatched asynchronously. * inspector/agents/InspectorHeapAgent.h: 2016-06-24 Commit Queue Unreviewed, rolling out r202413. https://bugs.webkit.org/show_bug.cgi?id=159097 Broke many JSC tests (Requested by ap on #webkit). Reverted changeset: "[JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values" https://bugs.webkit.org/show_bug.cgi?id=154022 http://trac.webkit.org/changeset/202413 2016-06-23 Benjamin Poulain OOM Assertion failure in Array.prototype.toString https://bugs.webkit.org/show_bug.cgi?id=158793 Reviewed by Saam Barati. JSString::create() taking a StringImpl was using a signed integer for the length of the string. The problem is StringImpl uses an unsigned integer. When a large string was passed to JSString, the signed integer would be negative and crash JSString. * runtime/JSString.h: (JSC::JSString::create): 2016-06-23 Joseph Pecoraro and Yusuke Suzuki [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values https://bugs.webkit.org/show_bug.cgi?id=154022 Reviewed by Filip Pizlo. We aim at optimizing @toInteger operation. While it still has an unoptimized part[1], this patch should be a first step. We introduce the @toNumber builtin intrinsic operation. This converts the given value to the JS number by emitting op_to_number bytecode. Previously @toInteger called C++ @Number constructor for that purpose. And in DFG, op_to_number is converted to DFG ToNumber node. During DFG, we attempt to convert this to edge filtering and Identity, but if we fail, we just fall back to calling the C++ function. To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS. Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number. But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable. By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger. ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation. This value profiling is provided from either NumberConstructor's call operation or op_to_number. The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit. And ASMBench/n-body.c also shows stable ~2% progression. [1]: https://bugs.webkit.org/show_bug.cgi?id=153738 * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/BuiltinNames.h: * builtins/GlobalObject.js: (globalPrivate.isFinite): (globalPrivate.isNaN): (globalPrivate.toInteger): Deleted. (globalPrivate.toLength): Deleted. (globalPrivate.isDictionary): Deleted. (globalPrivate.speciesGetter): Deleted. (globalPrivate.speciesConstructor): Deleted. * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js. (globalPrivate.toInteger): (globalPrivate.toLength): (globalPrivate.isDictionary): (globalPrivate.speciesGetter): (globalPrivate.speciesConstructor): * builtins/NumberConstructor.js: Added. (isFinite): (isNaN): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::finishCreation): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitUnaryOp): (JSC::BytecodeGenerator::emitUnaryOpProfiled): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitToNumber): * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber): (JSC::UnaryPlusNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::attemptToInlineCall): (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): (JSC::DFG::ByteCodeParser::parseBlock): We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode. According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupToNumber): ToNumber tells its predicted type by its heap prediction. So the fixup phase need to consider about it. If the heap prediction is Int32, we should attempt to convert the child value to Int32. Without this, misc-bugs-847389-jpeg2000 in assorted tests poses 53% regression. * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: Alway rely on the heap prediction. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since it may be reuse the argument registers and it can break the argument registers before using them to call the operation. Currently, we allocate the additional temporary register for that scratch register. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node. This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes the spills to call the operation. The example of the actually emitted code is the following. 76: ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48) predicting DoubleimpurenanTopEmpty 0x7f986d5fe693: test %rax, %r14 0x7f986d5fe696: jz 0x7f986d5fe6a1 0x7f986d5fe69c: jmp 0x7f986d5fe6d1 0x7f986d5fe6a1: mov %rax, %rsi 0x7f986d5fe6a4: mov %rbp, %rdi 0x7f986d5fe6a7: mov $0x2, 0x24(%rbp) 0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11 0x7f986d5fe6b8: call *%r11 0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11 0x7f986d5fe6c5: mov (%r11), %r11 0x7f986d5fe6c8: test %r11, %r11 0x7f986d5fe6cb: jnz 0x7f986d5fe88c It effectively removes the unnecessary spill to call the operation! * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileToNumber): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchIfNumber): (JSC::AssemblyHelpers::branchIfNotNumber): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_to_number): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_to_number): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * parser/Nodes.h: (JSC::UnaryOpNode::opcodeID): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncIsNaN): Deleted. (JSC::globalFuncIsFinite): Deleted. * runtime/JSGlobalObjectFunctions.h: * runtime/MathCommon.h: (JSC::maxSafeInteger): (JSC::minSafeInteger): * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::finishCreation): (JSC::numberConstructorFuncIsFinite): Deleted. (JSC::numberConstructorFuncIsNaN): Deleted. * runtime/NumberConstructor.h: * tests/stress/Number-isNaN-basics.js: Added. (numberIsNaNOnInteger): (testNumberIsNaNOnIntegers): (verifyNumberIsNaNOnIntegerWithOtherTypes): (numberIsNaNOnDouble): (testNumberIsNaNOnDoubles): (verifyNumberIsNaNOnDoublesWithOtherTypes): (numberIsNaNNoArguments): (numberIsNaNTooManyArguments): (testNumberIsNaNOnConstants): (numberIsNaNStructTransition): (Number.isNaN): * tests/stress/global-is-finite.js: Added. (shouldBe): * tests/stress/global-is-nan.js: Added. (shouldBe): * tests/stress/global-isNaN-basics.js: Added. (isNaNOnInteger): (testIsNaNOnIntegers): (verifyIsNaNOnIntegerWithOtherTypes): (isNaNOnDouble): (testIsNaNOnDoubles): (verifyIsNaNOnDoublesWithOtherTypes): (verifyIsNaNOnCoercedTypes): (isNaNNoArguments): (isNaNTooManyArguments): (testIsNaNOnConstants): (isNaNTypeCoercionSideEffects): (i.value.isNaNTypeCoercionSideEffects.valueOf): (isNaNStructTransition): (isNaN): * tests/stress/number-is-finite.js: Added. (shouldBe): (test2): (test3): * tests/stress/number-is-nan.js: Added. (shouldBe): (test2): (test3): * tests/stress/to-number-basics.js: Added. (shouldBe): * tests/stress/to-number-convert-identity-without-execution.js: Added. (shouldBe): (object.valueOf): (valueOf): * tests/stress/to-number-int52.js: Added. (shouldBe): (object.valueOf): * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added. (shouldBe): (object.valueOf): (valueOf): * tests/stress/to-number-intrinsic-int52.js: Added. (shouldBe): (object.valueOf): * tests/stress/to-number-intrinsic-object-without-execution.js: Added. (shouldBe): (object.valueOf): * tests/stress/to-number-intrinsic-value-profiling.js: Added. (shouldBe): (object.valueOf): * tests/stress/to-number-object-without-execution.js: Added. (shouldBe): (object.valueOf): * tests/stress/to-number-object.js: Added. (shouldBe): (test12): (object1.valueOf): (test2): (test22): (object2.valueOf): (test3): (test32): (object3.valueOf): * tests/stress/to-number-value-profiling.js: Added. (shouldBe): (object.valueOf): 2016-06-23 Saam Barati DFGSpeculativeJIT's m_slowPathLambdas should restore the current node field and DFG OSR entry functions should use DeferGCForAWhile instead of DeferGC https://bugs.webkit.org/show_bug.cgi?id=159064 Reviewed by Filip Pizlo. The DFG has a list of m_slowPathLambdas that are code generators it emits amongst its slow paths. These lambdas, however, did not update the m_currentNode field. This caused us to use whatever Node happened to be used as the currentNode at the time we call the slowPathLambda. This means the wrong CallSiteIndex was stored into the call frame when we made a call. This may lead to a crash if the CallSiteIndex corresponds to the wrong CodeOrigin. For example, the wrong CodeOrigin could have an InlineCallFrame with a calleeRecovery that will not be in sync with the current stack state. Trying to recover that callee will often lead to a crash. The solution is to update m_currentNode to the DFG::Node* it corresponds to when emitting these slowPathLambdas. I found this bug because we were inside this bad state when calling an operation that happened to have a DeferGC. When this DeferGC actually GCed, it would take a StackTrace, which would lead to a crash because we were updating ShadowChicken with vm.topCallFrame. It just so happened that the CallSiteIndex in the call frame in this program corresponded to an InlineCallFrame with a calleeRecover. However, this CallSiteIndex didn't correspond to the actual state of execution of the program. I'm adding new options to make reproducing DeferGC related bugs easier by making DeferGC force a GC according to some probability. To always have DeferGC force a GC, you can set that probability to 1. There is a second bug that I discovered after solving the above bug. We were using DeferGC instead of DeferGCForAWhile in the OSR entry related functions in the DFG. This would cause us to take a stack trace when the call frame was in an inconsistent state. For example, the operation would call FTL::prepareOSREntry, which would replace the DFG CodeBlock in the call frame with the FTL CodeBlock. However, we wouldn't update the CallSiteIndex to correspond to an FTL CallSiteIndex. This would lead to a crash when taking a stack trace. The solution is to prevent stack traces from being taken when the program is in this state by using DeferGCForAWhie instead of DeferGC. * dfg/DFGOperations.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::addSlowPathGenerator): (JSC::DFG::SpeculativeJIT::runSlowPathGenerators): * dfg/DFGSpeculativeJIT.h: * heap/Heap.h: * heap/HeapInlines.h: (JSC::Heap::collectIfNecessaryOrDefer): (JSC::Heap::collectAccordingToDeferGCProbability): (JSC::Heap::decrementDeferralDepthAndGCIfNeeded): (JSC::Heap::markListSet): * runtime/Options.cpp: (JSC::recomputeDependentOptions): (JSC::Options::initialize): * runtime/Options.h: * tests/stress/slow-path-generator-updating-current-node-dfg.js: Added. (foo): (bar): 2016-06-23 Filip Pizlo Failing baseline JIT compilation of a code block and then trying to compile it from OSR from DFG/FTL will corrupt the CodeBlock https://bugs.webkit.org/show_bug.cgi?id=158806 Reviewed by Saam Barati. If we try to compile a CodeBlock that we already tried compiling in the past then we need to clean up the data structures that were partly filled in by the failed compile. That causes some races, since the DFG may be trying to parse those data structures while we are clearing them. This patch introduces such a clean-up (CodeBlock::resetJITData()) and fixes the races. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::getStubInfoMap): (JSC::CodeBlock::getCallLinkInfoMap): (JSC::CodeBlock::getByValInfoMap): (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex): (JSC::CodeBlock::resetJITData): (JSC::CodeBlock::visitOSRExitTargets): (JSC::CodeBlock::setSteppingMode): (JSC::CodeBlock::addRareCaseProfile): (JSC::CodeBlock::rareCaseProfileForBytecodeOffset): (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset): (JSC::CodeBlock::resultProfileForBytecodeOffset): (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): (JSC::CodeBlock::couldTakeSpecialFastCase): (JSC::CodeBlock::ensureResultProfile): * bytecode/CodeBlock.h: (JSC::CodeBlock::getFromAllValueProfiles): (JSC::CodeBlock::numberOfRareCaseProfiles): (JSC::CodeBlock::numberOfResultProfiles): (JSC::CodeBlock::numberOfArrayProfiles): (JSC::CodeBlock::arrayProfiles): (JSC::CodeBlock::addRareCaseProfile): Deleted. (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted. (JSC::CodeBlock::couldTakeSpecialFastCase): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::methodOfGettingAValueProfileFor): * jit/JIT.cpp: (JSC::JIT::link): * jit/JITWorklist.cpp: (JSC::JITWorklist::compileNow): 2016-06-23 Joseph Pecoraro Web Inspector: Memory Timeline sometimes shows impossible value for bmalloc size (underflowed) https://bugs.webkit.org/show_bug.cgi?id=158110 Reviewed by Andreas Kling. * heap/Heap.cpp: (JSC::Heap::willStartCollection): (JSC::Heap::didFinishCollection): * heap/Heap.h: (JSC::Heap::externalMemorySize): * heap/HeapInlines.h: (JSC::Heap::reportExternalMemoryVisited): Keep count of external memory we visit. * heap/SlotVisitor.h: * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::reportExternalMemoryVisited): Report external memory visited like we do extra memory, since it will be some subset of extra memory that is external. 2016-06-23 Joseph Pecoraro Web Inspector: Snapshots should be cleared at some point https://bugs.webkit.org/show_bug.cgi?id=157907 Reviewed by Timothy Hatcher. * heap/HeapSnapshotBuilder.h: * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::resetNextAvailableObjectIdentifier): Provide a way to reset the object identifier counter. * inspector/agents/InspectorHeapAgent.h: * inspector/agents/InspectorHeapAgent.cpp: (Inspector::InspectorHeapAgent::clearHeapSnapshots): Make clearHeapSnapshots protected, so it can be called from a a PageHeapAgent on page navigations. 2016-06-22 Saam barati TypeProfiler and TypeProfilerLog don't play nicely with the concurrent JIT https://bugs.webkit.org/show_bug.cgi?id=159037 Reviewed by Benjamin Poulain. The primary focus of this patch is to make the concurrent baseline JIT work with the type profiler. We were clearing the type profiler log on the background baseline compiler thread which lead to bad things happening. This patch fixes this by processing the log before we launch the compile on a background thread. Secondly, I audited the type profiler code inside the DFG, and found that we were doing some racy things. I haven't seen any crashes because of these things, but it is possible that they exist. We were grabbing a RefPtr to a TypeSet, even though TypeSet was RefCounted and not ThreadSafeRefCounted. This patch makes TypeSet ThreadSafeRefCounted. We were also copying a StructureSet while the execution thread could be augmenting the StructureSet. This patch puts changes to TypeSet's StructureSet behind a ConcurrentJITLock. I've also added two more large running tests that run with the type profiler enabled. These are here just to catch any major bugs in the type profiler implementation. * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): (JSC::JIT::privateCompile): (JSC::JIT::privateCompileExceptionHandlers): (JSC::JIT::doMainThreadPreparationBeforeCompile): (JSC::JIT::frameRegisterCountFor): * jit/JIT.h: (JSC::JIT::compile): * jit/JITWorklist.cpp: (JSC::JITWorklist::Plan::Plan): (JSC::JITWorklist::Plan::compileInThread): * runtime/TypeSet.cpp: (JSC::TypeSet::addTypeInformation): (JSC::TypeSet::invalidateCache): * runtime/TypeSet.h: (JSC::TypeSet::create): (JSC::TypeSet::isEmpty): (JSC::TypeSet::seenTypes): (JSC::TypeSet::structureSet): * tests/typeProfiler/deltablue-for-of.js: Added. * tests/typeProfiler/getter-richards.js: Added. 2016-06-22 Keith Miller We should have a DFG intrinsic that checks if a value is a TypedArrayView https://bugs.webkit.org/show_bug.cgi?id=159048 Reviewed by Saam Barati. This patch adds a new DFG Intrinsic that checks if a value is a TypedArrayView. The intrinsic, IsTypedArrayView, works in the same way that the other Is DFG nodes work. Additionally, a new builtin function isTypedArrayView has been added. These changes are needed to fix regressions in %TypedArray%.prototype.subarray. * builtins/BuiltinNames.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView): (JSC::FTL::DFG::LowerDFGToB3::isTypedArrayView): * runtime/Intrinsic.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::typedArrayViewPrivateFuncIsTypedArrayView): * runtime/JSTypedArrayViewPrototype.h: * tests/stress/istypedarrayview-intrinsic.js: Added. (makeFn): (typedArrays.forEach): (let.test): (test): 2016-06-21 Anders Carlsson Fix build. * Configurations/FeatureDefines.xcconfig: 2016-06-21 Geoffrey Garen Options::useImmortalObjects is not safe for conservative GC https://bugs.webkit.org/show_bug.cgi?id=158999 Reviewed by Geoffrey Garen. useImmortalObjects set the mark bit to keep an object from being reallocated. This had the negative side-effect of convincing the conservative marker that the object was a valid and live cell, which would cause us to visit garbage. * heap/Heap.cpp: (JSC::Heap::didFinishCollection): (JSC::Heap::resumeCompilerThreads): (JSC::Heap::setFullActivityCallback): (JSC::Heap::markDeadObjects): Deleted. * heap/Heap.h: Don't set the mark bit on a dead object. That's a bug in a conservative GC. * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::retire): New helper. (JSC::MarkedAllocator::reset): Automatically retire old blocks when we're doing the immortal objects thing. This has the effect of preserving memory for debugging because we never recycle a previously allocated block. 2016-06-21 Anders Carlsson Begin moving the Apple Pay code to the open source repository https://bugs.webkit.org/show_bug.cgi?id=158998 Reviewed by Tim Horton. * Configurations/FeatureDefines.xcconfig: Add ENABLE_APPLE_PAY. 2016-06-21 Saam Barati CodeBlock::shrinkToFit is racy https://bugs.webkit.org/show_bug.cgi?id=158994 Reviewed by Filip Pizlo. To see why this is racy, consider the following scenario: - CodeBlock A is link()ing its baseline compile. - CodeBlock B is inlining A, and asks A for a result profile in DFGBytecodeParser. - The race occurs when the link() step of the baseline compile calls shrinkToFit on its m_resultProfiles field without grabbing a lock. This leads to a bad time because the DFG compile will be reading from that vector as it's getting changed by the baseline link() method. This race has always existed, though the move to a concurrent baseline JIT has made it more likely to occur. The solution is to have CodeBlock::shrinkToFit grab its lock before shrinking the vector. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::shrinkToFit): 2016-06-21 David Kilzer Migrate testair & testb3 settings from Xcode project to ToolExecutable.xcconfig Reviewed by Andy Estes. * Configurations/ToolExecutable.xcconfig: (CODE_SIGN_ENTITLEMENTS_ios_testair): Add from Xcode project. * JavaScriptCore.xcodeproj/project.pbxproj: (CODE_SIGN_ENTITLEMENTS_ios_testair): Move to ToolExecutable.xcconfig. (PRODUCT_NAME): Remove. This variable is already set for both testair and testb3 since those build configurations use ToolExecutable.xcconfig as a base. 2016-06-21 Saam Barati LLInt doesn't throw stack exception overflow from parent frame https://bugs.webkit.org/show_bug.cgi?id=158962 Reviewed by Filip Pizlo. All JIT tiers will throw stack overflow exceptions from the parent frame. The LLInt, on the other hand, did not use to. I've changed the LLInt to be consistent with the JITs. The reason I found this bug is because we had a test that would give different results depending on if the function was compiled in the baseline or the LLInt. Since Filip recently landed the concurrent baseline JIT patch, this otherwise deterministic test became dependent on it being compiled in the LLInt or one of the JIT tiers. I've added a new test that is deterministic because it runs the test with --useJIT=false. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * tests/stress/llint-stack-overflow-location.js: Added. (stackTraceDescription): (foo): (catch): 2016-06-21 David Kilzer CODE_SIGN_ENTITLEMENTS should be applied to iOS Simulator builds Reviewed by Dan Bernstein. * Configurations/JSC.xcconfig: (CODE_SIGN_ENTITLEMENTS): Change [sdk=iphoneos*] to [sdk=iphone*] to apply setting to iOS Simulator as well. * Configurations/ToolExecutable.xcconfig: (CODE_SIGN_ENTITLEMENTS): Ditto. 2016-06-21 Keith Miller It should be easy to add a private global helper function for builtins https://bugs.webkit.org/show_bug.cgi?id=158893 Reviewed by Mark Lam. This patch does two things. First it moves all the builtin names out of CommonIdentifiers and into BuiltinNames. This means that adding a new function to the Builtins does not require rebuilding all of JavaScriptCore. This patch also adds a new decorator to our builtins @privateGlobal that will automatically put the function on the global object. The name of the property will be the same as the private name of the function. This patch, also, removes the JSArrayIterator.h/.cpp files as they no longer appear to be used in any real way. Finally, the builtins tests have been rebaselined. It appears this has not been done for a while so the expected files contain other changes. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/builtins/builtins_generate_combined_header.py: (BuiltinsCombinedHeaderGenerator.generate_output): (generate_section_for_code_name_macro): (generate_section_for_global_private_code_name_macro): * Scripts/builtins/builtins_model.py: (BuiltinFunction.__init__): (BuiltinFunction.fromString): * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: * builtins/ArrayIteratorPrototype.js: * builtins/ArrayPrototype.js: * builtins/BuiltinNames.h: * builtins/GeneratorPrototype.js: * builtins/GlobalObject.js: * builtins/PromiseOperations.js: * builtins/RegExpPrototype.js: * builtins/StringPrototype.js: * bytecode/BytecodeIntrinsicRegistry.cpp: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded): (JSC::BytecodeGenerator::expectedFunctionForIdentifier): (JSC::BytecodeGenerator::emitGetTemplateObject): (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope): (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope): (JSC::BytecodeGenerator::emitGeneratorStateChange): * bytecompiler/NodesCodegen.cpp: (JSC::emitHomeObjectForCallee): (JSC::emitPutHomeObject): (JSC::FunctionNode::emitBytecode): * dfg/DFGOperations.cpp: * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::subtype): (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted. * parser/Lexer.cpp: (JSC::Lexer::parseIdentifier): (JSC::Lexer::parseIdentifier): * parser/Nodes.h: * parser/Parser.cpp: (JSC::Parser::createGeneratorParameters): (JSC::Parser::parseExportDeclaration): * runtime/ArrayIteratorPrototype.cpp: * runtime/ArrayIteratorPrototype.h: * runtime/ArrayPrototype.cpp: * runtime/CommonIdentifiers.cpp: (JSC::CommonIdentifiers::CommonIdentifiers): Deleted. * runtime/CommonIdentifiers.h: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/IntlDateTimeFormat.cpp: * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeGetterFormat): (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototypeGetterFormat): (JSC::IntlNumberFormatPrototypeFuncResolvedOptions): * runtime/IntlObjectInlines.h: (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor): * runtime/JSArrayIterator.cpp: Removed. (JSC::JSArrayIterator::finishCreation): Deleted. (JSC::JSArrayIterator::kind): Deleted. (JSC::JSArrayIterator::iteratedValue): Deleted. * runtime/JSArrayIterator.h: Removed. (JSC::JSArrayIterator::createStructure): Deleted. (JSC::JSArrayIterator::create): Deleted. (JSC::JSArrayIterator::JSArrayIterator): Deleted. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::finishCreation): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSInternalPromise.cpp: * runtime/JSInternalPromiseDeferred.cpp: (JSC::JSInternalPromiseDeferred::create): * runtime/JSPromise.cpp: (JSC::JSPromise::finishCreation): (JSC::JSPromise::result): * runtime/JSPromiseDeferred.cpp: (JSC::JSPromiseDeferred::create): * runtime/JSStringIterator.cpp: (JSC::JSStringIterator::finishCreation): (JSC::JSStringIterator::iteratedValue): (JSC::JSStringIterator::clone): * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): * runtime/ReflectObject.cpp: (JSC::ReflectObject::finishCreation): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): * runtime/TypedArrayInlines.h: 2016-06-20 Yusuke Suzuki [JSC] Use bytecode intrinsic to expose Module's loading status to builtin JS https://bugs.webkit.org/show_bug.cgi?id=158871 Reviewed by Sam Weinig. Now JSC has bytecode intrinsic system. Use it instead of exposing status values through the loader's properties. * builtins/ModuleLoaderObject.js: (newRegistryEntry): (fulfillFetch): (fulfillTranslate): (commitInstantiated): (requestFetch): (requestTranslate): (requestInstantiate): (requestResolveDependencies.): (requestResolveDependencies): (requestLink): (link): (provide): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * runtime/ModuleLoaderObject.cpp: (JSC::ModuleLoaderObject::finishCreation): Deleted. 2016-06-20 Commit Queue Unreviewed, rolling out r202248. https://bugs.webkit.org/show_bug.cgi?id=158960 breaks builds on the simulator (Requested by keith_mi_ on #webkit). Reverted changeset: "It should be easy to add a private global helper function for builtins" https://bugs.webkit.org/show_bug.cgi?id=158893 http://trac.webkit.org/changeset/202248 2016-06-20 Keith Miller It should be easy to add a private global helper function for builtins https://bugs.webkit.org/show_bug.cgi?id=158893 Reviewed by Mark Lam. This patch does two things. First it moves all the builtin names out of CommonIdentifiers and into BuiltinNames. This means that adding a new function to the Builtins does not require rebuilding all of JavaScriptCore. This patch also adds a new decorator to our builtins @privateGlobal that will automatically put the function on the global object. The name of the property will be the same as the private name of the function. This patch, also, removes the JSArrayIterator.h/.cpp files as they no longer appear to be used in any real way. Finally, the builtins tests have been rebaselined. It appears this has not been done for a while so the expected files contain other changes. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/builtins/builtins_generate_combined_header.py: (BuiltinsCombinedHeaderGenerator.generate_output): (generate_section_for_code_name_macro): (generate_section_for_global_private_code_name_macro): * Scripts/builtins/builtins_model.py: (BuiltinFunction.__init__): (BuiltinFunction.fromString): * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: * builtins/ArrayIteratorPrototype.js: * builtins/ArrayPrototype.js: * builtins/BuiltinNames.h: * builtins/GeneratorPrototype.js: * builtins/GlobalObject.js: * builtins/PromiseOperations.js: * builtins/RegExpPrototype.js: * builtins/StringPrototype.js: * bytecode/BytecodeIntrinsicRegistry.cpp: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded): (JSC::BytecodeGenerator::expectedFunctionForIdentifier): (JSC::BytecodeGenerator::emitGetTemplateObject): (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope): (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope): (JSC::BytecodeGenerator::emitGeneratorStateChange): * bytecompiler/NodesCodegen.cpp: (JSC::emitHomeObjectForCallee): (JSC::emitPutHomeObject): (JSC::FunctionNode::emitBytecode): * dfg/DFGOperations.cpp: * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::subtype): (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted. * parser/Lexer.cpp: (JSC::Lexer::parseIdentifier): (JSC::Lexer::parseIdentifier): * parser/Nodes.h: * parser/Parser.cpp: (JSC::Parser::createGeneratorParameters): (JSC::Parser::parseExportDeclaration): * runtime/ArrayIteratorPrototype.cpp: * runtime/ArrayIteratorPrototype.h: * runtime/ArrayPrototype.cpp: * runtime/CommonIdentifiers.cpp: (JSC::CommonIdentifiers::CommonIdentifiers): Deleted. * runtime/CommonIdentifiers.h: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/IntlDateTimeFormat.cpp: * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeGetterFormat): (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototypeGetterFormat): (JSC::IntlNumberFormatPrototypeFuncResolvedOptions): * runtime/IntlObjectInlines.h: (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor): * runtime/JSArrayIterator.cpp: Removed. (JSC::JSArrayIterator::finishCreation): Deleted. (JSC::JSArrayIterator::kind): Deleted. (JSC::JSArrayIterator::iteratedValue): Deleted. * runtime/JSArrayIterator.h: Removed. (JSC::JSArrayIterator::createStructure): Deleted. (JSC::JSArrayIterator::create): Deleted. (JSC::JSArrayIterator::JSArrayIterator): Deleted. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::finishCreation): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSInternalPromise.cpp: * runtime/JSInternalPromiseDeferred.cpp: (JSC::JSInternalPromiseDeferred::create): * runtime/JSPromise.cpp: (JSC::JSPromise::finishCreation): (JSC::JSPromise::result): * runtime/JSPromiseDeferred.cpp: (JSC::JSPromiseDeferred::create): * runtime/JSStringIterator.cpp: (JSC::JSStringIterator::finishCreation): (JSC::JSStringIterator::iteratedValue): (JSC::JSStringIterator::clone): * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): * runtime/ReflectObject.cpp: (JSC::ReflectObject::finishCreation): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): * runtime/TypedArrayInlines.h: 2016-06-20 Filip Pizlo LLInt64 Float64 get_by_val doesn't purify NaN https://bugs.webkit.org/show_bug.cgi?id=158956 Reviewed by Michael Saboff. * llint/LowLevelInterpreter64.asm: Fix the bug. * tests/stress/float64-array-nan-inlined.js: Make this test also run in LLInt-only mode to catch this bug. 2016-06-20 Keith Rollin Remove RefPtr::release() and change calls sites to use WTFMove() https://bugs.webkit.org/show_bug.cgi?id=158369 Reviewed by Chris Dumez. RefPtr::release() releases its managed pointer awkwardly. It's more direct and clearer to use WTFMove to transfer ownership of the managed pointer. As part of this cleanup, also change a lot of explicit data types to 'auto'. * API/JSObjectRef.cpp: (JSClassCreate): * API/JSScriptRef.cpp: * API/JSValueRef.cpp: (JSValueToStringCopy): * bytecompiler/StaticPropertyAnalyzer.h: (JSC::StaticPropertyAnalyzer::newObject): (JSC::StaticPropertyAnalyzer::mov): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::invalidate): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * inspector/InspectorValues.cpp: (Inspector::InspectorValue::parseJSON): * inspector/agents/InspectorAgent.cpp: (Inspector::InspectorAgent::activateExtraDomain): (Inspector::InspectorAgent::activateExtraDomains): * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::breakpointActionProbe): * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::receivedSetupMessage): * jit/Repatch.cpp: (JSC::linkPolymorphicCall): * runtime/GenericTypedArrayViewInlines.h: (JSC::GenericTypedArrayView::create): (JSC::GenericTypedArrayView::createUninitialized): * runtime/JSArrayBufferConstructor.cpp: (JSC::constructArrayBuffer): * runtime/PropertyNameArray.h: (JSC::PropertyNameArray::releaseData): * runtime/Structure.cpp: (JSC::Structure::toStructureShape): * runtime/TypeSet.cpp: (JSC::StructureShape::merge): * tools/FunctionOverrides.cpp: (JSC::initializeOverrideInfo): 2016-06-20 Joseph Pecoraro Web Inspector: console.profile should use the new Sampling Profiler https://bugs.webkit.org/show_bug.cgi?id=153499 Reviewed by Timothy Hatcher. Currently console.profile/profileEnd behave slightly differently between JSContext and Web inspection. Unifying will be part of: Generalize the concept of Instruments on the backend Both JSContext and Web inspection keep track of active profiles started and stopped via console.profile/profileEnd. JSContext inspection sends its programmatic start/stop via the ScriptProfiler domain. Web inspection sends its programmatic start/stop via the Timeline domain, and also will start/stop backend list of Instruments. The functional differences between these is that for JSContext inspection, console.profile only starts/stops the ScriptProfiler domain, and does not auto-start other instruments. This isn't really a problem right now given the instruments available for JSContext inspection; but it will be nice to unify as we add more instruments. Also, JSContext inspection won't have "Profile (name)" records in its Events view, since those are currently generated only by the Web's Timeline domain. * inspector/protocol/ScriptProfiler.json: * inspector/protocol/Timeline.json: Events to inform the frontend of programmatic start/stop. * debugger/Debugger.h: * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::breakpointsActive): (Inspector::InspectorDebuggerAgent::isPaused): * inspector/agents/InspectorDebuggerAgent.h: Expose breakpoints active state, since programmatic recording will temporarily disabled breakpoints if needed. * inspector/JSGlobalObjectConsoleClient.cpp: (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient): (Inspector::JSGlobalObjectConsoleClient::profile): (Inspector::JSGlobalObjectConsoleClient::profileEnd): (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile): (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile): * inspector/JSGlobalObjectConsoleClient.h: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): * inspector/agents/InspectorScriptProfilerAgent.h: JSContext implementation of console.profile/profileEnd. 2016-06-19 Saam Barati We should be able to generate more types of ICs inline https://bugs.webkit.org/show_bug.cgi?id=158719 Reviewed by Filip Pizlo. This patch changes how we emit code for *byId ICs inline. We no longer keep data labels to patch structure checks, etc. Instead, we just regenerate the entire IC into a designated region of code that the Baseline/DFG/FTL JIT will emit inline. This makes it much simpler to patch inline ICs. All that's needed to patch an inline IC is to memcpy the code from a macro assembler inline using LinkBuffer. This architecture will be easy to extend into other forms of ICs, such as one for add, in the future. To support this change, I've reworked the fields inside StructureStubInfo. It now has one field that is the CodeLocationLabel of the start of the inline IC. Then it has a few ints that track deltas to other locations in the IC such as the slow path start, slow path call, the ICs 'done' location. We used to perform math on these ints in a bunch of different places. I've consolidated that math into methods inside StructureStubInfo. To generate inline ICs, I've implemented a new class called InlineAccess. InlineAccess is stateless: it just has a bunch of static methods for generating code into the inline region specified by StructureStubInfo. Repatch will now decide when it wants to generate such an inline IC, and it will ask InlineAccess to do so. I've implemented three types of inline ICs to begin with (extending this in the future should be easy): - Self property loads (both inline and out of line offsets). - Self property replace (both inline and out of line offsets). - Array length on specific array types. (An easy extension would be to implement JSString length.) To know how much inline space to reserve, I've implemented a method that stubs out the various inline cache shapes and dumps their size. This is used to determine how much space to save inline. When InlineAccess ends up generating more code than can fit inline, we will fall back to generating code with PolymorphicAccess instead. To make generating code into already allocated executable memory efficient, I've made AssemblerData have 128 bytes of inline storage. This saves us a malloc when splatting code into the inline region. This patch also tidies up LinkBuffer's API for generating into already allocated executable memory. Now, when generating code that has less size than the already allocated space, LinkBuffer will fill the extra space with nops. Also, if branch compaction shrinks the code, LinkBuffer will add a nop sled at the end of the shrunken code to take up the entire allocated size. This looks like it could be a 1% octane progression. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::nop): (JSC::ARM64Assembler::fillNops): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::nopw): (JSC::ARMv7Assembler::nopPseudo16): (JSC::ARMv7Assembler::nopPseudo32): (JSC::ARMv7Assembler::fillNops): (JSC::ARMv7Assembler::dmbSY): * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::addLinkTask): (JSC::AbstractMacroAssembler::emitNops): (JSC::AbstractMacroAssembler::AbstractMacroAssembler): * assembler/AssemblerBuffer.h: (JSC::AssemblerData::AssemblerData): (JSC::AssemblerData::operator=): (JSC::AssemblerData::~AssemblerData): (JSC::AssemblerData::buffer): (JSC::AssemblerData::grow): (JSC::AssemblerData::isInlineBuffer): (JSC::AssemblerBuffer::AssemblerBuffer): (JSC::AssemblerBuffer::ensureSpace): (JSC::AssemblerBuffer::codeSize): (JSC::AssemblerBuffer::setCodeSize): (JSC::AssemblerBuffer::label): (JSC::AssemblerBuffer::debugOffset): (JSC::AssemblerBuffer::releaseAssemblerData): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): (JSC::LinkBuffer::linkCode): (JSC::LinkBuffer::allocate): (JSC::LinkBuffer::performFinalization): (JSC::LinkBuffer::shrink): Deleted. * assembler/LinkBuffer.h: (JSC::LinkBuffer::LinkBuffer): (JSC::LinkBuffer::debugAddress): (JSC::LinkBuffer::size): (JSC::LinkBuffer::wasAlreadyDisassembled): (JSC::LinkBuffer::didAlreadyDisassemble): (JSC::LinkBuffer::applyOffset): (JSC::LinkBuffer::code): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::patchableBranch32): (JSC::MacroAssemblerARM64::patchableBranch64): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::patchableBranch32): (JSC::MacroAssemblerARMv7::patchableBranchPtrWithPatch): * assembler/X86Assembler.h: (JSC::X86Assembler::nop): (JSC::X86Assembler::fillNops): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::printGetByIdCacheStatus): * bytecode/InlineAccess.cpp: Added. (JSC::InlineAccess::dumpCacheSizesAndCrash): (JSC::linkCodeInline): (JSC::InlineAccess::generateSelfPropertyAccess): (JSC::getScratchRegister): (JSC::hasFreeRegister): (JSC::InlineAccess::canGenerateSelfPropertyReplace): (JSC::InlineAccess::generateSelfPropertyReplace): (JSC::InlineAccess::isCacheableArrayLength): (JSC::InlineAccess::generateArrayLength): (JSC::InlineAccess::rewireStubAsJump): * bytecode/InlineAccess.h: Added. (JSC::InlineAccess::sizeForPropertyAccess): (JSC::InlineAccess::sizeForPropertyReplace): (JSC::InlineAccess::sizeForLengthAccess): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::initGetByIdSelf): (JSC::StructureStubInfo::initArrayLength): (JSC::StructureStubInfo::initPutByIdReplace): (JSC::StructureStubInfo::deref): (JSC::StructureStubInfo::aboutToDie): (JSC::StructureStubInfo::propagateTransitions): (JSC::StructureStubInfo::containsPC): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::considerCaching): (JSC::StructureStubInfo::slowPathCallLocation): (JSC::StructureStubInfo::doneLocation): (JSC::StructureStubInfo::slowPathStartLocation): (JSC::StructureStubInfo::patchableJumpForIn): (JSC::StructureStubInfo::valueRegs): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileIn): (JSC::FTL::DFG::LowerDFGToB3::getById): * jit/JITInlineCacheGenerator.cpp: (JSC::JITByIdGenerator::finalize): (JSC::JITByIdGenerator::generateFastCommon): (JSC::JITGetByIdGenerator::JITGetByIdGenerator): (JSC::JITGetByIdGenerator::generateFastPath): (JSC::JITPutByIdGenerator::JITPutByIdGenerator): (JSC::JITPutByIdGenerator::generateFastPath): (JSC::JITPutByIdGenerator::slowPathFunction): (JSC::JITByIdGenerator::generateFastPathChecks): Deleted. * jit/JITInlineCacheGenerator.h: (JSC::JITByIdGenerator::reportSlowPathCall): (JSC::JITByIdGenerator::slowPathBegin): (JSC::JITByIdGenerator::slowPathJump): (JSC::JITGetByIdGenerator::JITGetByIdGenerator): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id): * jit/Repatch.cpp: (JSC::repatchCall): (JSC::tryCacheGetByID): (JSC::repatchGetByID): (JSC::appropriateGenericPutByIdFunction): (JSC::tryCachePutByID): (JSC::repatchPutByID): (JSC::tryRepatchIn): (JSC::repatchIn): (JSC::linkSlowFor): (JSC::resetGetByID): (JSC::resetPutByID): (JSC::resetIn): (JSC::repatchByIdSelfAccess): Deleted. (JSC::resetGetByIDCheckAndLoad): Deleted. (JSC::resetPutByIDCheckAndLoad): Deleted. (JSC::replaceWithJump): Deleted. 2016-06-19 Filip Pizlo REGRESSION(concurrent baseline JIT): Kraken/ai-astar runs 20% slower https://bugs.webkit.org/show_bug.cgi?id=158906 Reviewed by Benjamin Poulain. The concurrent baseline JIT was a 2-3% progression on JSBench, possibly a 1% progression on PLT3, but a 2-5% regression on Kraken. This patch fixes the Kraken regression without affecting the other tests. The problem is that Kraken/ai-astar's initialization code had a ginormous piece of init code that took about 16ms to compile in baseline. There's no good way to avoid letting it tier-up into baseline since it has a compute loop. The time it takes to run this code is never measured. The concurrent baseline JIT caused us to schedule the compilation of this huge code rather than doing it eagerly. This meant that after initialization was done and we started actually running real stuff, all of the real stuff's compiles would be convoyed behind this super-expensive baseline compile. Note that DFG and FTL compiles convoy behind baseline compiles, since you can't schedule a DFG compile for a code block until that code block is in baseline. This uses the simplest fix: if we are thinking about scheduling some compile and the thread is busy, do the compile on the main thread instead. This doesn't completely eliminate the ai-astar regression (we still have a 4% regression on that test) but it now results in concurrent baseline JIT being an overall progression on Kraken as a whole (1% on my machine). This is because concurrent baseline appears to help on other tests. In the future, we could fix this even better by allowing the JITWorklist to spawn more threads or by being smarter about baseline compilation. I think it's nasty that if a giant piece of initialization code ends in a compute loop, we compile all of the code instead of just the loop. It's also gross that a constant-like object creation expression will result in so much code. It would result in less code if we allowed ourselves to do a bit more static reasoning about object literals. But for now, I think that this is a great way to recover the Kraken regression while still keeping the other progressions from concurrent baseline. * jit/JITWorklist.cpp: (JSC::JITWorklist::Plan::Plan): (JSC::JITWorklist::Plan::compileInThread): (JSC::JITWorklist::Plan::finalize): (JSC::JITWorklist::Plan::codeBlock): (JSC::JITWorklist::Plan::isFinishedCompiling): (JSC::JITWorklist::Plan::compileNow): (JSC::JITWorklist::JITWorklist): (JSC::JITWorklist::compileLater): (JSC::JITWorklist::compileNow): (JSC::JITWorklist::runThread): (JSC::JITWorklist::Plan::isFinalized): Deleted. * jit/JITWorklist.h: 2016-06-17 Commit Queue Unreviewed, rolling out r202152. https://bugs.webkit.org/show_bug.cgi?id=158897 The new test is very unstable, timing out frequently (Requested by ap on #webkit). Reverted changeset: "Web Inspector: console.profile should use the new Sampling Profiler" https://bugs.webkit.org/show_bug.cgi?id=153499 http://trac.webkit.org/changeset/202152 2016-06-14 Filip Pizlo Baseline JIT should be concurrent https://bugs.webkit.org/show_bug.cgi?id=158755 Reviewed by Geoffrey Garen. This makes the baseline JIT concurrent. We want it to be concurrent because it takes up about 1% of PLT3 and 10% of JSBench (though the JSBench number might be down from recent optimizations). The idea is really simple: I separated the compile and link phases of JIT::privateCompile(), and arranged to call the compile phase from another thread. This doesn't reuse the old DFG::Worklist code, because that code does things we don't need (like compilation plan cancellation to allow GC to interleave with compilations) and is structured in a way that would have required more changes to the baseline JIT. Also, I think that code uses the wrong API, and as a result, clients of that API have a bad time. For example, it's never clear who has the responsibility of setting the JIT thresholds and the DFG::Worklist goes to great lengths to try to help its client set those things correctly, but since it doesn't set them directly, the client then has to have additional complex logic to combine what it learned from the Worklist and what it knows to set the thresholds. This patch takes a simpler approach: the JITWorklist takes complete control over scheduling compilations. It's like a combination of DFG::Worklist and operationOptimize(). Because the baseline JIT runs quickly, we can take some shortcuts. The JITWorklist requires that all of its plans complete before a GC begins. This ensures that we don't have to worry about interactions between the concurrent baseline JIT and the GC. I needed to do a bunch of minor changes to the JIT to handle the races that emerged. For example, I needed to do things to opcodes that read profiling both in the main path code generator and the slow path one. One trick I used was to create a copy of the instruction stream and provide that for anyone interested in the original value of the profiles. Most code still uses the CodeBlock's instruction stream because it may emit JIT code that points at the stream. This also fixes a LLInt bug in prototype caching. This bug was revealed by this change because more of our LayoutTests now run in LLInt. This looks like it might be a ~1% Octane speed-up (on command line) and a ~0.7% PLT3 speed-up. This also looks like a ~2% JSBench speed-up. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * debugger/Debugger.cpp: (JSC::Debugger::setSteppingMode): (JSC::Debugger::toggleBreakpoint): (JSC::Debugger::clearBreakpoints): (JSC::Debugger::clearDebuggerRequests): * dfg/DFGOSRExitPreparation.cpp: (JSC::DFG::prepareCodeOriginForOSRExit): * heap/Heap.cpp: (JSC::Heap::didFinishIterating): (JSC::Heap::completeAllJITPlans): (JSC::Heap::deleteAllCodeBlocks): (JSC::Heap::collectImpl): (JSC::Heap::completeAllDFGPlans): Deleted. * heap/Heap.h: * heap/HeapInlines.h: (JSC::Heap::forEachCodeBlock): * jit/JIT.cpp: (JSC::JIT::emitNotifyWrite): (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): (JSC::JIT::compileWithoutLinking): (JSC::JIT::link): (JSC::JIT::privateCompile): (JSC::JIT::privateCompileExceptionHandlers): * jit/JIT.h: (JSC::JIT::compile): (JSC::JIT::getSlowCase): (JSC::JIT::linkSlowCase): (JSC::JIT::linkDummySlowCase): * jit/JITInlines.h: (JSC::JIT::emitTagBool): (JSC::JIT::originalInstruction): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitSlow_op_put_to_scope): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_resolve_scope): (JSC::JIT::emitSlow_op_resolve_scope): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): * jit/JITWorklist.cpp: Added. (JSC::JITWorklist::Plan::Plan): (JSC::JITWorklist::Plan::compileInThread): (JSC::JITWorklist::Plan::finalize): (JSC::JITWorklist::Plan::codeBlock): (JSC::JITWorklist::Plan::vm): (JSC::JITWorklist::Plan::isFinishedCompiling): (JSC::JITWorklist::Plan::isFinalized): (JSC::JITWorklist::JITWorklist): (JSC::JITWorklist::~JITWorklist): (JSC::JITWorklist::completeAllForVM): (JSC::JITWorklist::poll): (JSC::JITWorklist::compileLater): (JSC::JITWorklist::compileNow): (JSC::JITWorklist::runThread): (JSC::JITWorklist::finalizePlans): (JSC::JITWorklist::instance): * jit/JITWorklist.h: Added. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::tryCachePutToScopeGlobal): (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): * runtime/VM.cpp: (JSC::VM::~VM): 2016-06-16 Joseph Pecoraro Web Inspector: console.profile should use the new Sampling Profiler https://bugs.webkit.org/show_bug.cgi?id=153499 Reviewed by Timothy Hatcher. Currently console.profile/profileEnd behave slightly differently between JSContext and Web inspection. Unifying will be part of: Generalize the concept of Instruments on the backend Both JSContext and Web inspection keep track of active profiles started and stopped via console.profile/profileEnd. JSContext inspection sends its programmatic start/stop via the ScriptProfiler domain. Web inspection sends its programmatic start/stop via the Timeline domain, and also will start/stop backend list of Instruments. The functional differences between these is that for JSContext inspection, console.profile only starts/stops the ScriptProfiler domain, and does not auto-start other instruments. This isn't really a problem right now given the instruments available for JSContext inspection; but it will be nice to unify as we add more instruments. Also, JSContext inspection won't have "Profile (name)" records in its Events view, since those are currently generated only by the Web's Timeline domain. * inspector/protocol/ScriptProfiler.json: * inspector/protocol/Timeline.json: Events to inform the frontend of programmatic start/stop. * debugger/Debugger.h: * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::breakpointsActive): (Inspector::InspectorDebuggerAgent::isPaused): * inspector/agents/InspectorDebuggerAgent.h: Expose breakpoints active state, since programmatic recording will temporarily disabled breakpoints if needed. * inspector/JSGlobalObjectConsoleClient.cpp: (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient): (Inspector::JSGlobalObjectConsoleClient::profile): (Inspector::JSGlobalObjectConsoleClient::profileEnd): (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile): (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile): * inspector/JSGlobalObjectConsoleClient.h: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted): (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped): * inspector/agents/InspectorScriptProfilerAgent.h: JSContext implementation of console.profile/profileEnd. 2016-06-16 Filip Pizlo Kraken/stanford-crypto-pbkdf2.js sometimes crashes with an OSR assertion in FTL https://bugs.webkit.org/show_bug.cgi?id=158850 Reviewed by Keith Miller. Bytecode liveness was incorrectly claiming that all tail-deleted locals are live! That's crazy! We never noticed this because extending OSR liveness is usually not a showstopper and until recently we didn't have a lot of tail-call test cases to play with. Well, we do now, thanks to the increasing reliance on tail calls in our builtins. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::localsLiveInBytecode): Fix the bug and add some optional tracing. Also restructure the code so that we don't break to return true, since that's counterintuitive. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::buildExitArguments): Make this assertion print more useful information. 2016-06-16 Mark Lam Add collecting of LLINT slow path stats. https://bugs.webkit.org/show_bug.cgi?id=158829 Reviewed by Keith Miller. * llint/LLIntData.cpp: (JSC::LLInt::Data::dumpStats): * llint/LLIntData.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2016-06-15 Keith Miller Add support for Symbol.isConcatSpreadable (round 2) https://bugs.webkit.org/show_bug.cgi?id=158769 Reviewed by Mark Lam. This patch adds support for Symbol.isConcatSpreadable. In order to do so, it was necessary to move the Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to a builtin performant. First, this patch adds a new Bytecode intrinsic, isJSArray, that checks if the value is a JSArray object. Specifically, isJSArray checks that the array object is a normal instance of JSArray and not a RuntimeArray or Array.prototype. isJSArray can also be converted into a constant by the DFG if we are able to prove that the incomming value is already a JSArray. In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage or were undecided. Now the memcpy code covers the following additional three cases: 1) One array is undecided and the other does not have array storage 2) One array is Int32 and the other is contiguous (we map this into a contiguous array). 3) The this value is an array and first argument is a non-array that does not have Symbol.isConcatSpreadable set. This patch also adds a new fast path for concat with more than one array argument by using memcpy to append values onto the result array. This works roughly the same as the two array fast path using the same methodology to decide if we can memcpy the other butterfly into the result butterfly. * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/ArrayPrototype.js: (concatSlowPath): (concat): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitIsJSArray): * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_isJSArray): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::compileIsJSArray): (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): (JSC::FTL::DFG::LowerDFGToB3::isArray): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_is_jsarray): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_is_jsarray): * jit/JITOperations.h: * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArrayConstructor.h: (JSC::isArrayConstructor): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): (JSC::speciesWatchpointsValid): (JSC::speciesConstructArray): (JSC::moveElements): (JSC::concatAppendOne): (JSC::arrayProtoFuncConcat): Deleted. * runtime/ArrayPrototype.h: * runtime/CommonIdentifiers.h: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/IndexingType.h: (JSC::indexingTypeForValue): * runtime/JSArray.cpp: (JSC::JSArray::appendMemcpy): (JSC::JSArray::fastConcatWith): Deleted. * runtime/JSArray.h: (JSC::JSArray::createStructure): (JSC::isJSArray): (JSC::JSArray::fastConcatType): Deleted. * runtime/JSArrayInlines.h: Added. (JSC::JSArray::mergeIndexingTypeForCopying): (JSC::JSArray::canFastCopy): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSObject.cpp: (JSC::JSObject::convertUndecidedForValue): * runtime/JSType.h: * runtime/ObjectConstructor.h: (JSC::constructObject): * tests/es6.yaml: * tests/stress/array-concat-spread-object.js: Added. (arrayEq): * tests/stress/array-concat-spread-proxy-exception-check.js: Added. (arrayEq): * tests/stress/array-concat-spread-proxy.js: Added. (arrayEq): * tests/stress/array-concat-with-slow-indexingtypes.js: Added. (arrayEq): * tests/stress/array-species-config-array-constructor.js: 2016-06-15 Mark Lam Assertion failure when returning incomplete property descriptor from proxy trap. https://bugs.webkit.org/show_bug.cgi?id=157078 Reviewed by Saam Barati. If the proxy returns a descriptor that expects a value but does not specify one, we should use undefined for the value. * runtime/ProxyObject.cpp: (JSC::ProxyObject::performInternalMethodGetOwnProperty): * tests/stress/proxy-returning-incomplete-property-descriptor.js: Added. (truthiness): (compare): (shouldBe): (test): (get test): 2016-06-15 Keith Miller Unreviewed, fix typo in test and move tests to the correct files. * tests/stress/multi-get-by-offset-proto-or-unset.js: * tests/stress/multi-get-by-offset-proto-self-or-unset.js: 2016-06-15 Keith Miller DFGByteCodeParser should be able to infer the value of unset properties in MultiGetByOffset https://bugs.webkit.org/show_bug.cgi?id=158802 Reviewed by Filip Pizlo. This patch adds support for unset properties in MultiGetByOffset. Since MultiGetByOffset already supports constant values this patch just adds a constant case where the fetched value is undefined. Fortunately (or unfortunately) we don't support object allocation sinking for constant cases of MultiGetByOffset, which means we don't need to adjust any in that phase. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::planLoad): (JSC::DFG::ByteCodeParser::handleGetById): * dfg/DFGMultiGetByOffsetData.h: * tests/stress/multi-get-by-offset-proto-or-unset.js: Added. (foo): * tests/stress/multi-get-by-offset-proto-self-or-unset.js: Added. (foo): * tests/stress/multi-get-by-offset-self-or-unset.js: Added. (foo): 2016-06-15 Chris Dumez Unreviewed GCC build fix after r202098. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::thresholdForJIT): 2016-06-14 Geoffrey Garen compilation policy should adapt to past behavior https://bugs.webkit.org/show_bug.cgi?id=158759 Reviewed by Saam Barati. This looks like a ~9% speedup on JSBench. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::~CodeBlock): Record when a CodeBlock dies without ever making it to DFG. (JSC::CodeBlock::thresholdForJIT): CodeBlocks that make it to DFG should compile sooner; CodeBlocks that don't should compile later. The goal is to use past behavior, in addition to execution counts, to determine whether compilation is profitable. (JSC::CodeBlock::jitAfterWarmUp): (JSC::CodeBlock::jitSoon): Apply the thresholdForJIT rule. * bytecode/CodeBlock.h: Moved some code into the .cpp file so I could change stuff without recompiling. (JSC::CodeBlock::jitAfterWarmUp): Deleted. (JSC::CodeBlock::jitSoon): Deleted. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::didOptimize): (JSC::UnlinkedCodeBlock::setDidOptimize): Added a piece of data to track whether we made it to DFG. * jit/JITOperations.cpp: Record when we make it to DFG. 2016-06-15 Konstantin Tokarev Only Mac port needs ObjC API for JSC. https://bugs.webkit.org/show_bug.cgi?id=158780 Reviewed by Philippe Normand. * API/JSBase.h: Removed !defined(BUILDING_GTK__) 2016-06-15 Keith Miller DFGByteCodeParser should be able to infer a property is unset from the Baseline inline cache. https://bugs.webkit.org/show_bug.cgi?id=158774 Reviewed by Filip Pizlo. This patch allows the DFGByteCodeParser to speculatively convert a property access into a constant if that access was always a miss in the Baseline inline cache. This patch does not add support for MultiGetByOffset and unset properties. That functionality will come a future patch. * bytecode/ComplexGetStatus.cpp: (JSC::ComplexGetStatus::computeFor): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/GetByIdVariant.h: (JSC::GetByIdVariant::isPropertyUnset): * bytecode/PutByIdVariant.h: (JSC::PutByIdVariant::isPropertyUnset): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::load): (JSC::DFG::ByteCodeParser::handleGetById): * tests/stress/undefined-access-then-self-change.js: Added. (foo): 2016-06-15 Yusuke Suzuki [JSC] Move calling convention flags to WTF https://bugs.webkit.org/show_bug.cgi?id=158661 Reviewed by Keith Miller. Due to some calling convention flags and JIT_OPERATION flags, MathCommon.h includes MacroAssemblerCodeRef and JITOperations.h. But MacroAssembler and JIT part should not be necessary for the MathCommon component. As with other calling convention flags like JSC_HOST_CALL, these flags should be in WTF. * assembler/MacroAssemblerCodeRef.h: * jit/JITOperations.h: Add wtf/Platform.h inclusion driven by the Windows port build failure. * runtime/MathCommon.h: 2016-06-15 Romain Bellessort Enabling Shadow DOM for all platforms https://bugs.webkit.org/show_bug.cgi?id=158738 Reviewed by Ryosuke Niwa. Removed Shadow DOM from options (enabled by default) * Configurations/FeatureDefines.xcconfig: 2016-06-14 Caio Lima The parser doesn't properly parse "super" when default parameter is an arrow function. https://bugs.webkit.org/show_bug.cgi?id=157872. Reviewed by Saam Barati. The "super" member or "super()" could not be used when default parameter is an arrow function, resuling in sytax error. It happened because the "closestOrdinaryFunctionScope" was not being initialized properly before "parseFunctionParameters" step and the condition "functionSuperBinding == SuperBinding::NotNeeded" or "functionConstructorKind != ConstructorKind::Derived" on "Parser::parseMemberExpression" step were being true resulting in SyntaxError. * parser/Parser.cpp: (JSC::Parser::parseFunctionInfo): setting "functionScope->setExpectedSuperBinding(expectedSuperBinding)" and "functionScope->setConstructorKind(constructorKind)" before "parseFunctionParameters" step. 2016-06-14 Joseph Pecoraro Web Inspector: Rename Timeline.setAutoCaptureInstruments to Timeline.setInstruments https://bugs.webkit.org/show_bug.cgi?id=158762 Reviewed by Timothy Hatcher. Rename the protocol methods since the backend may use the instruments for purposes other then auto-capture, such as programmatic capture via console.profile. * inspector/protocol/Timeline.json: 2016-06-14 David Kilzer Document the native format of JSChar type Reviewed by Darin Adler. * API/JSStringRef.h: (typedef JSChar): Update documentation. 2016-06-14 Keith Miller The Array species constructor watchpoints should be created the first time they are needed rather than on creation https://bugs.webkit.org/show_bug.cgi?id=158754 Reviewed by Benjamin Poulain. We use adaptive watchpoints for some Array prototype functions to ensure that the user has not overridden the value of the Array.prototype.constructor or Array[Symbol.species]. This patch changes when the Array species constructor watchpoints are initialized. Before, those watchpoints would be created when the global object is initialized. This had the advantage that it did not require validating the constructor and Symbol.species properties. On the other hand, it also meant that if the user were to reconfigure properties Array.prototype, which would cause the structure of the property to become an uncachable dictionary, prior to running code that the watchpoints would be invalidated. It turns out that JSBench amazon, for instance, does reconfigure some of Array.prototype's properties. This patch initializes the watchpoints the first time they are needed. Since we only initialize once we also flatten the structure of Array and Array.prototype. * runtime/ArrayPrototype.cpp: (JSC::speciesConstructArray): (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint): (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): (JSC::ArrayPrototype::setConstructor): Deleted. * runtime/ArrayPrototype.h: (JSC::ArrayPrototype::speciesWatchpointStatus): (JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::speciesGetterSetter): (JSC::JSGlobalObject::arrayConstructor): * tests/stress/array-symbol-species-lazy-watchpoints.js: Added. (test): (arrayEq): (A): 2016-06-14 Keith Miller REGRESSION(202002-202014): 845 32-bit JSC Stress Test failures https://bugs.webkit.org/show_bug.cgi?id=158737 Reviewed by Filip Pizlo. When the this child and arguments child for the varargs nodes was switched I missed one case in the 32-bit build. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): 2016-06-13 Gavin & Ellie Barraclough setUpStaticFunctionSlot does not handle Builtin|Accessor properties https://bugs.webkit.org/show_bug.cgi?id=158637 Reviewed by Geoff Garen. setUpStaticFunctionSlot contains a duplicate copy of the body of the function reifyStaticProperty - however it is missing handling for Accessor type under Builtin functions. Fix the bug by de-duplicating - setUpStaticFunctionSlot should just call reifyStaticProperty. * runtime/Lookup.cpp: (JSC::setUpStaticFunctionSlot): - should just call reifyStaticProperty. * runtime/Lookup.h: (JSC::lookupPut): (JSC::reifyStaticProperty): - changed reifyStaticProperty to take PropertyName. 2016-06-13 Gavin & Ellie Barraclough JSBoundSlotBaseFunction no longer binds slot base https://bugs.webkit.org/show_bug.cgi?id=157978 Reviewed by Geoff Garen. This class is basically currently named after a bug. We should never have been binding function to slot bases - this was not ever correct behavior. This was fixed earlier in the year, but there is still some cruft including the class name to clean up. - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction - removed m_boundSlotBase - don't retain the original slot base (we were not really using it anyway). - ASSERT customGetterSetter->getter/setter are non-null, rather than checking. - Store the PropertyName such that we can pass this to the getter (we're currently reperforming the String->Identifier conversion every time). - Removed JSFunction::lookUpOrCreateNativeExecutable - this is just overhead, and not used consistently. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/JSBoundSlotBaseFunction.cpp: Removed. * runtime/JSBoundSlotBaseFunction.h: Removed. - JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction * runtime/JSCustomGetterSetterFunction.cpp: Copied from Source/JavaScriptCore/runtime/JSBoundSlotBaseFunction.cpp. (JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall): - made a static function on JSCustomGetterSetterFunction such that accessor to member properties could be made private. Call variant of callCustomSetter that does not require slotBase, ASSERT getter/setter present, pass stored PropertyName to getter. (JSC::JSCustomGetterSetterFunction::JSCustomGetterSetterFunction): - renamed, store propertyName. (JSC::JSCustomGetterSetterFunction::create): - use same function name to Executable as is being passed to Function::finishCreation. (JSC::JSCustomGetterSetterFunction::visitChildren): (JSC::JSCustomGetterSetterFunction::finishCreation): - removed m_boundSlotBase. * runtime/JSCustomGetterSetterFunction.h: Copied from Source/JavaScriptCore/runtime/JSBoundSlotBaseFunction.h. (JSC::JSCustomGetterSetterFunction::customGetterSetter): (JSC::JSCustomGetterSetterFunction::isSetter): - made private. (JSC::JSCustomGetterSetterFunction::propertyName): - new accessor. (JSC::JSBoundSlotBaseFunction::boundSlotBase): Deleted. - removed. * runtime/JSFunction.cpp: (JSC::JSFunction::create): (JSC::JSFunction::lookUpOrCreateNativeExecutable): Deleted. - removed lookUpOrCreateNativeExecutable. This inconsistently used wrapper was providing no value, only bloat. * runtime/JSFunction.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::customGetterSetterFunctionStructure): (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): Deleted. - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc. * runtime/JSNativeStdFunction.cpp: (JSC::JSNativeStdFunction::create): - removed lookUpOrCreateNativeExecutable. * runtime/JSObject.cpp: (JSC::getCustomGetterSetterFunctionForGetterSetter): (JSC::JSObject::getOwnPropertyDescriptor): (JSC::getBoundSlotBaseFunctionForGetterSetter): Deleted. - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc. * runtime/VM.h: - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc. 2016-06-13 Saam Barati The sampling profiler should further protect itself against certain forms of sampling bias that arise due to the sampling interval being in sync with some other system process https://bugs.webkit.org/show_bug.cgi?id=158678 Reviewed by Benjamin Poulain. I first became aware of this problem when I read this paper: http://plv.colorado.edu/papers/mytkowicz-pldi10.pdf To provide background for this change, I'll quote a paragraph from section 6.2: "One statically sound method for collecting random samples is to collect a sample at every t + r milliseconds, where t is the desired sampling interval and r is a random number between −t and t. One might think that sampling every t seconds is enough (i.e., drop the r component) but it is not: specifically, if a profiler samples every t seconds, the sampling rate would be synchronized with any program or system activity that occurs at regular time intervals [17]. For example, if the thread scheduler switches between threads every 10ms and our sampling interval was also 10ms, then we may always take samples immediately after a thread switch. Because performance is often different immediately after a thread switch than at other points (e.g., due to cache and TLB warm-up effects) we would get biased data. The random component, r, guards against such situations." * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::timerLoop): 2016-06-13 Oliver Hunt DFG Validation fails when performing a concatenation with only a single entry https://bugs.webkit.org/show_bug.cgi?id=158699 Reviewed by Saam Barati. Fairly simple short circuiting of a single replacement template string without any padding to be planted as a simple to string rather than op_strcat. * bytecompiler/NodesCodegen.cpp: (JSC::TemplateLiteralNode::emitBytecode): * tests/stress/template-literal.js: (testSingleNode): 2016-06-13 Filip Pizlo FTL::Output methods should be out-of-line whenever possible https://bugs.webkit.org/show_bug.cgi?id=158704 Reviewed by Benjamin Poulain. These methods turn into a non-trivial amount of code because of the template-based B3 API. Inlining them didn't achieve any performance advantages for the FTL, but it did make the code larger. This outlines most methods in FTL::Output. It makes FTL::LowerDFGToB3 smaller and it doesn't change performance. * ftl/FTLOutput.cpp: (JSC::FTL::Output::appendTo): (JSC::FTL::Output::framePointer): (JSC::FTL::Output::lockedStackSlot): (JSC::FTL::Output::constBool): (JSC::FTL::Output::constInt32): (JSC::FTL::Output::constInt64): (JSC::FTL::Output::constDouble): (JSC::FTL::Output::phi): (JSC::FTL::Output::add): (JSC::FTL::Output::sub): (JSC::FTL::Output::mul): (JSC::FTL::Output::div): (JSC::FTL::Output::chillDiv): (JSC::FTL::Output::mod): (JSC::FTL::Output::chillMod): (JSC::FTL::Output::neg): (JSC::FTL::Output::doubleAdd): (JSC::FTL::Output::doubleSub): (JSC::FTL::Output::doubleMul): (JSC::FTL::Output::doubleDiv): (JSC::FTL::Output::doubleMod): (JSC::FTL::Output::bitAnd): (JSC::FTL::Output::bitOr): (JSC::FTL::Output::bitXor): (JSC::FTL::Output::shl): (JSC::FTL::Output::aShr): (JSC::FTL::Output::lShr): (JSC::FTL::Output::bitNot): (JSC::FTL::Output::logicalNot): (JSC::FTL::Output::ctlz32): (JSC::FTL::Output::doubleAbs): (JSC::FTL::Output::doubleCeil): (JSC::FTL::Output::doubleFloor): (JSC::FTL::Output::doubleTrunc): (JSC::FTL::Output::doubleSin): (JSC::FTL::Output::doubleCos): (JSC::FTL::Output::doublePow): (JSC::FTL::Output::doublePowi): (JSC::FTL::Output::doubleSqrt): (JSC::FTL::Output::doubleLog): (JSC::FTL::Output::hasSensibleDoubleToInt): (JSC::FTL::Output::doubleToUInt): (JSC::FTL::Output::signExt32To64): (JSC::FTL::Output::zeroExt): (JSC::FTL::Output::intToDouble): (JSC::FTL::Output::unsignedToDouble): (JSC::FTL::Output::castToInt32): (JSC::FTL::Output::doubleToFloat): (JSC::FTL::Output::floatToDouble): (JSC::FTL::Output::load): (JSC::FTL::Output::load8SignExt32): (JSC::FTL::Output::baseIndex): (JSC::FTL::Output::equal): (JSC::FTL::Output::notEqual): (JSC::FTL::Output::above): (JSC::FTL::Output::aboveOrEqual): (JSC::FTL::Output::below): (JSC::FTL::Output::belowOrEqual): (JSC::FTL::Output::greaterThan): (JSC::FTL::Output::greaterThanOrEqual): (JSC::FTL::Output::lessThan): (JSC::FTL::Output::lessThanOrEqual): (JSC::FTL::Output::doubleEqual): (JSC::FTL::Output::doubleEqualOrUnordered): (JSC::FTL::Output::doubleNotEqualOrUnordered): (JSC::FTL::Output::doubleLessThan): (JSC::FTL::Output::doubleLessThanOrEqual): (JSC::FTL::Output::doubleGreaterThan): (JSC::FTL::Output::doubleGreaterThanOrEqual): (JSC::FTL::Output::doubleNotEqualAndOrdered): (JSC::FTL::Output::doubleLessThanOrUnordered): (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered): (JSC::FTL::Output::doubleGreaterThanOrUnordered): (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered): (JSC::FTL::Output::isZero32): (JSC::FTL::Output::notZero32): (JSC::FTL::Output::isZero64): (JSC::FTL::Output::notZero64): (JSC::FTL::Output::select): (JSC::FTL::Output::jump): (JSC::FTL::Output::branch): (JSC::FTL::Output::check): (JSC::FTL::Output::ret): (JSC::FTL::Output::unreachable): (JSC::FTL::Output::speculate): (JSC::FTL::Output::speculateAdd): (JSC::FTL::Output::speculateSub): (JSC::FTL::Output::speculateMul): (JSC::FTL::Output::patchpoint): (JSC::FTL::Output::trap): (JSC::FTL::Output::anchor): (JSC::FTL::Output::bitCast): (JSC::FTL::Output::fround): * ftl/FTLOutput.h: (JSC::FTL::Output::setOrigin): (JSC::FTL::Output::origin): (JSC::FTL::Output::constIntPtr): (JSC::FTL::Output::doubleNeg): (JSC::FTL::Output::zeroExtPtr): (JSC::FTL::Output::load32NonNegative): (JSC::FTL::Output::isNull): (JSC::FTL::Output::notNull): (JSC::FTL::Output::testIsZeroPtr): (JSC::FTL::Output::testNonZeroPtr): (JSC::FTL::Output::call): (JSC::FTL::Output::operation): (JSC::FTL::Output::branch): (JSC::FTL::Output::switchInstruction): (JSC::FTL::Output::addIncomingToPhi): (JSC::FTL::Output::framePointer): Deleted. (JSC::FTL::Output::constBool): Deleted. (JSC::FTL::Output::constInt32): Deleted. (JSC::FTL::Output::constInt64): Deleted. (JSC::FTL::Output::constDouble): Deleted. (JSC::FTL::Output::phi): Deleted. (JSC::FTL::Output::add): Deleted. (JSC::FTL::Output::sub): Deleted. (JSC::FTL::Output::mul): Deleted. (JSC::FTL::Output::div): Deleted. (JSC::FTL::Output::chillDiv): Deleted. (JSC::FTL::Output::mod): Deleted. (JSC::FTL::Output::chillMod): Deleted. (JSC::FTL::Output::doubleAdd): Deleted. (JSC::FTL::Output::doubleSub): Deleted. (JSC::FTL::Output::doubleMul): Deleted. (JSC::FTL::Output::doubleDiv): Deleted. (JSC::FTL::Output::doubleMod): Deleted. (JSC::FTL::Output::bitAnd): Deleted. (JSC::FTL::Output::bitOr): Deleted. (JSC::FTL::Output::bitXor): Deleted. (JSC::FTL::Output::shl): Deleted. (JSC::FTL::Output::aShr): Deleted. (JSC::FTL::Output::lShr): Deleted. (JSC::FTL::Output::ctlz32): Deleted. (JSC::FTL::Output::addWithOverflow32): Deleted. (JSC::FTL::Output::subWithOverflow32): Deleted. (JSC::FTL::Output::mulWithOverflow32): Deleted. (JSC::FTL::Output::addWithOverflow64): Deleted. (JSC::FTL::Output::subWithOverflow64): Deleted. (JSC::FTL::Output::mulWithOverflow64): Deleted. (JSC::FTL::Output::doubleAbs): Deleted. (JSC::FTL::Output::doubleCeil): Deleted. (JSC::FTL::Output::doubleFloor): Deleted. (JSC::FTL::Output::doubleSin): Deleted. (JSC::FTL::Output::doubleCos): Deleted. (JSC::FTL::Output::doublePow): Deleted. (JSC::FTL::Output::doubleSqrt): Deleted. (JSC::FTL::Output::doubleLog): Deleted. (JSC::FTL::Output::signExt32To64): Deleted. (JSC::FTL::Output::zeroExt): Deleted. (JSC::FTL::Output::intToDouble): Deleted. (JSC::FTL::Output::castToInt32): Deleted. (JSC::FTL::Output::doubleToFloat): Deleted. (JSC::FTL::Output::floatToDouble): Deleted. (JSC::FTL::Output::equal): Deleted. (JSC::FTL::Output::notEqual): Deleted. (JSC::FTL::Output::above): Deleted. (JSC::FTL::Output::aboveOrEqual): Deleted. (JSC::FTL::Output::below): Deleted. (JSC::FTL::Output::belowOrEqual): Deleted. (JSC::FTL::Output::greaterThan): Deleted. (JSC::FTL::Output::greaterThanOrEqual): Deleted. (JSC::FTL::Output::lessThan): Deleted. (JSC::FTL::Output::lessThanOrEqual): Deleted. (JSC::FTL::Output::doubleEqual): Deleted. (JSC::FTL::Output::doubleEqualOrUnordered): Deleted. (JSC::FTL::Output::doubleNotEqualOrUnordered): Deleted. (JSC::FTL::Output::doubleLessThan): Deleted. (JSC::FTL::Output::doubleLessThanOrEqual): Deleted. (JSC::FTL::Output::doubleGreaterThan): Deleted. (JSC::FTL::Output::doubleGreaterThanOrEqual): Deleted. (JSC::FTL::Output::doubleNotEqualAndOrdered): Deleted. (JSC::FTL::Output::doubleLessThanOrUnordered): Deleted. (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered): Deleted. (JSC::FTL::Output::doubleGreaterThanOrUnordered): Deleted. (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered): Deleted. (JSC::FTL::Output::isZero32): Deleted. (JSC::FTL::Output::notZero32): Deleted. (JSC::FTL::Output::isZero64): Deleted. (JSC::FTL::Output::notZero64): Deleted. (JSC::FTL::Output::select): Deleted. (JSC::FTL::Output::extractValue): Deleted. (JSC::FTL::Output::jump): Deleted. (JSC::FTL::Output::ret): Deleted. (JSC::FTL::Output::unreachable): Deleted. (JSC::FTL::Output::speculate): Deleted. (JSC::FTL::Output::speculateAdd): Deleted. (JSC::FTL::Output::speculateSub): Deleted. (JSC::FTL::Output::speculateMul): Deleted. (JSC::FTL::Output::patchpoint): Deleted. (JSC::FTL::Output::trap): Deleted. (JSC::FTL::Output::anchor): Deleted. (JSC::FTL::Output::bitCast): Deleted. (JSC::FTL::Output::fround): Deleted. 2016-06-13 Keith Miller Unreviewed, Cloop build fix. * bytecode/BytecodeList.json: 2016-06-12 Keith Miller Add new builtin opcode tailCallForwardArguments https://bugs.webkit.org/show_bug.cgi?id=158666 Reviewed by Filip Pizlo. We should support the ability to have a builtin forward its arguments to a helper without allocating an arguments object. This patch adds a new bytecode intrinsic @tailCallForwardArguments that takes two values. The first is the target of the call and the second is the new this value. This opcode will tail call to the passed function without triggering an allocation of an arguments object for the caller function. In the LLInt and Baseline this function acts the same way a normal tail call does. The bytecode will allocate a new stack frame copying all the arguments of the caller function into the new frame, along with the new this. Then when the actual call happens the new frame is copied over the caller frame. While this is not necessary, it allows the target function to have more arguments than the caller function via arity fixup. Once we get to the DFG we reuse existing DFG Nodes for forwarding arguments, although there were some minor changes. This patch swaps the meaning of the second and third children for each DFG varargs node, exchanging the argmuments and this child, respectively. It also makes the arguments child for each varargs node, as well as the ForwardVarargs node optional. If the optional child is missing, then forwarding node assumes that the arguments for the node's inlineCallFrame should be used instead. Finally, when inlining the target of an inlined op_tail_call_forward_arguments we make sure the arguments of the forwarding function are marked as non-unboxable since this would normally be done by the caller's create arguments object node, which does not exist in this case. * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CallLinkInfo.h: (JSC::CallLinkInfo::callTypeFor): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::finishCreation): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition): (JSC::BytecodeGenerator::emitCallVarargs): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_tailCallForwardArguments): (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleVarargsCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasArgumentsChild): (JSC::DFG::Node::argumentsChild): * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileForwardVarargs): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGVarargsForwardingPhase.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs): * interpreter/Interpreter.cpp: (JSC::sizeFrameForForwardArguments): (JSC::setupForwardArgumentsFrame): (JSC::setupForwardArgumentsFrameAndSetThis): * interpreter/Interpreter.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileSetupVarargsFrame): (JSC::JIT::compileOpCall): (JSC::JIT::compileOpCallSlowCase): (JSC::JIT::emit_op_tail_call_forward_arguments): (JSC::JIT::emitSlow_op_tail_call_forward_arguments): * jit/JITCall32_64.cpp: (JSC::JIT::emitSlow_op_tail_call_forward_arguments): (JSC::JIT::emit_op_tail_call_forward_arguments): (JSC::JIT::compileSetupVarargsFrame): (JSC::JIT::compileOpCall): * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::varargsSetup): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * tests/stress/tailCallForwardArguments.js: Added. (putFuncToPrivateName.createBuiltin): (putFuncToPrivateName): (createTailCallForwardingFuncWith): (baz): (baz2): (baz3): (let.bodyText): (baz4): (baz5): (arrayEq): 2016-06-13 Yusuke Suzuki Unreviewed, follow up patch for r201964 https://bugs.webkit.org/show_bug.cgi?id=158619 Fix typo in the comment. * runtime/MathCommon.h: (JSC::toInt32): 2016-06-13 Mark Lam Add a mechanism for collecting LLINT stats. https://bugs.webkit.org/show_bug.cgi?id=158668 Reviewed by Filip Pizlo. This patch will add a mechanism for collecting the stats on LLINT opcode execution counts. The changes made to enable this are: 1. Refactored how Options availability work so that we can add a new category: Configurable (in addition to the pre-existing Normal and Restricted availability). Normal options - always available. Restricted options - only available on debug builds. Configurable options - depends on #define flag options. This change is necessary so that: a. we won't have to rebuild the world when we want to enable that #define flag to make that Configurable option available. b. when the #define flag is disabled, the option will be invisible to the user. With this, we add our first configurable option, JSC_reportLLIntStats, which is dependent on the ENABLE_LLINT_STATS flag. See next. 2. Added the ENABLE_LLINT_STATS flag in LLIntCommon.h. To enable LLINT stats collection, we'll need to set this flag to a non-zero value, and rebuilding the project. By design, this will only require a minimal set of files to be rebuilt. ENABLE_LLINT_STATS is 0 (i.e. disabled) by default. 3. Added a slow path callback to the LLINT's traceExecution() macro, to call _llint_count_opcode(), which in turns counts the opcode. This callback will only be built into the LLINT if ENABLE_LLINT_STATS is non-zero. 4. Added s_opcodeStatsArray to LLInt::Data. This is where the stats are recorded and stored. 5. Added calls to LLInt::Data::dumpStats() in jsc.cpp and DumpRenderTree.mm to dump the LLINT stats if enabled. If enabled, the LLINT stats will be sorted and dumped (via dataLog) before the programs terminate. * interpreter/Interpreter.h: * jsc.cpp: (main): * llint/LLIntCommon.h: * llint/LLIntData.cpp: (JSC::LLInt::initialize): (JSC::LLInt::Data::dumpStats): * llint/LLIntData.h: (JSC::LLInt::Data::opcodeStats): * llint/LLIntOfflineAsmConfig.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_crash): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * runtime/Options.cpp: (JSC::parse): (JSC::Options::isAvailable): (JSC::overrideOptionWithHeuristic): (JSC::scaleJITPolicy): (JSC::Options::initialize): (JSC::Options::setOptionWithoutAlias): (JSC::Options::dumpAllOptions): (JSC::Options::dumpOption): * runtime/Options.h: (JSC::Option::Option): (JSC::Option::operator!=): (JSC::Option::id): 2016-06-11 Mark Lam Minimize the amount of memcpy done for allocating Error stacks. https://bugs.webkit.org/show_bug.cgi?id=158664 Reviewed by Darin Adler. Currently, Vector are being copied around multiple times in the process of creating Error stacks. This patch avoids this unnecessary copying by: 1. Sizing the StackFrame vector correctly to begin with, and skipping undesirable top frames before filling in the vector. 2. Using perfect forwarding or passing by reference to pass the vector data around instead of copying the vectors. 3. Changing the Exception object to take a Vector instead of a RefCountedArray. This patch has passed the JSC and layout tests. Benchmarks show that perf is neutral. * API/tests/testapi.mm: (testObjectiveCAPI): * inspector/ScriptCallStackFactory.cpp: (Inspector::createScriptCallStackFromException): * interpreter/Interpreter.cpp: (JSC::GetStackTraceFunctor::GetStackTraceFunctor): (JSC::GetStackTraceFunctor::operator()): (JSC::Interpreter::getStackTrace): (JSC::Interpreter::stackTraceAsString): (JSC::findExceptionHandler): * interpreter/Interpreter.h: * runtime/Error.cpp: (JSC::addErrorInfoAndGetBytecodeOffset): * runtime/Exception.cpp: (JSC::Exception::finishCreation): * runtime/Exception.h: (JSC::Exception::valueOffset): (JSC::Exception::value): (JSC::Exception::stack): (JSC::Exception::didNotifyInspectorOfThrow): (JSC::Exception::setDidNotifyInspectorOfThrow): 2016-06-11 Mark Lam Tests that overflows the stack should not be run with the sampling profiler. https://bugs.webkit.org/show_bug.cgi?id=158663 Reviewed by Saam Barati. The sampling profiler will be sampling the whole stack, and the amount of memory churn will make this tests time out, especially with debug builds. Hence, let's not run the test with the sampling profiler configuration. * tests/stress/mutual-tail-call-no-stack-overflow.js: (shouldThrow): 2016-06-10 Yusuke Suzuki Unreviewed, attempt to fix r201964 failure on Apple ports https://bugs.webkit.org/show_bug.cgi?id=158619 Reviewed by Mark Lam. Add Private attributes to MathCommon.h. * JavaScriptCore.xcodeproj/project.pbxproj: 2016-06-10 Yusuke Suzuki [JSC] Inline JSC::toInt32 to improve kraken https://bugs.webkit.org/show_bug.cgi?id=158619 Reviewed by Mark Lam. Several kraken benchmarks show that JSC::toInt32 is frequently called. For example, stanford-crypto-pbkdf2 reports that the hottest runtime function is JSC::toInt32. The data is below (taken by Linux perf tools). 5.50% jsc libJavaScriptCore.so.1.0.0 [.] _ZN3JSC7toInt32Ed 3.96% jsc libJavaScriptCore.so.1.0.0 [.] _ZN3JSC20arrayProtoFuncConcatEPNS_9ExecStateE 2.48% jsc libJavaScriptCore.so.1.0.0 [.] _ZN3JSC19arrayProtoFuncSliceEPNS_9ExecStateE 1.69% jsc libJavaScriptCore.so.1.0.0 [.] _ZNK3JSC9Structure27holesMustForwardToPrototypeERNS_2VME This is because of CommonSlowPaths' bit operations's JSValue::toInt32. Due to the slow path, in `value | 0`, `value` may be a double number value. In that case, JSC::toInt32 is called. While JSC::toIn32 is hot, the function itself is very small. It's worth inlining. This change offers the following kraken improvements. baseline patched Kraken: audio-beat-detection 47.492+-1.701 46.657+-1.232 might be 1.0179x faster stanford-crypto-aes 43.669+-0.210 ^ 42.862+-0.115 ^ definitely 1.0188x faster stanford-crypto-ccm 45.213+-1.424 44.490+-1.290 might be 1.0162x faster stanford-crypto-pbkdf2 107.665+-0.581 ^ 106.229+-0.807 ^ definitely 1.0135x faster This patch only focused on the call to toInt32 from the runtime functions. So JSC::toInt32 calls from the baseline / DFG remain. We ensure that JIT code uses operationToInt32 instead of JSC::toInt32 since JSC::toInt32 is now marked as ALWAYS_INLINE. Linux perf profiler also finds that this `operationToInt32` is frequently called in the above benchmarks. It may be good to introduce asm emit for that instead of calling JSC::toInt32 operation in the separated patch. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32): (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32): * runtime/JSCJSValue.cpp: (JSC::toInt32): Deleted. * runtime/JSCJSValueInlines.h: * runtime/MathCommon.cpp: (JSC::operationToInt32): * runtime/MathCommon.h: (JSC::toInt32): 2016-06-10 Filip Pizlo The backend should be happy to compile Unreachable even if AI didn't prove it to be unreachable https://bugs.webkit.org/show_bug.cgi?id=158631 Reviewed by Keith Miller. We've been slowly making the DFG Unreachable opcode behave like a grown-up. When we first added it, it was a hack for Throw, and we could always rely on AI proving that Unreachable was not reachable. But then we started using Unreachable as a proper Unreachable opcode, like Oops in B3 for example, which has a more nuanced meaning: you use it whenever you emit code that *you* know will not return, and you need some way of terminating the basic block. The DFG is not a proof-carrying compiler, and it never will be. So, when you have proved that something is not reachable, you should be able to use Unreachable even if there is no guarantee that the compiler will later be able to replicate your proof. This means that the backend may find itself compiling Unreachable because AI did not prove that it was unreachable. Prior to this change, we would crash compiling Unreachable because we would rely on AI preventing us from reaching Unreachable in the backend. But that's silly! We don't want users of Unreachable to have to also convince AI that their Unreachable is really Unreachable. This fixes crashes on real websites. I couldn't work out how to turn them into a reduced test. * assembler/AbortReason.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitInvalidationPoint): (JSC::DFG::SpeculativeJIT::unreachable): (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar): (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable): (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject): 2016-06-09 Alex Christensen Clean up JavaScriptCore.vcxproj directory after switching to CMake. * JavaScriptCore.vcxproj/LLInt: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntAssembly: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props: Removed. * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: Removed. * JavaScriptCore.vcxproj/jsc: Removed. * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Removed. * JavaScriptCore.vcxproj/jsc/DLLLauncherWinCairo.props: Removed. * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Removed. * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Removed. * JavaScriptCore.vcxproj/jsc/jscCommon.props: Removed. * JavaScriptCore.vcxproj/jsc/jscDebug.props: Removed. * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj: Removed. * JavaScriptCore.vcxproj/jsc/jscLauncherPostBuild.cmd: Removed. * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd: Removed. * JavaScriptCore.vcxproj/jsc/jscLauncherPreLink.cmd: Removed. * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: Removed. * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd: Removed. * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: Removed. * JavaScriptCore.vcxproj/jsc/jscProduction.props: Removed. * JavaScriptCore.vcxproj/jsc/jscRelease.props: Removed. * JavaScriptCore.vcxproj/testRegExp: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPostBuild.cmd: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreLink.cmd: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props: Removed. * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: Removed. * JavaScriptCore.vcxproj/testapi: Removed. * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Removed. * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters: Removed. * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Removed. * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Removed. * JavaScriptCore.vcxproj/testapi/testapiDebug.props: Removed. * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Removed. * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj: Removed. * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd: Removed. * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd: Removed. * JavaScriptCore.vcxproj/testapi/testapiLauncherPreLink.cmd: Removed. * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd: Removed. * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd: Removed. * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: Removed. * JavaScriptCore.vcxproj/testapi/testapiProduction.props: Removed. * JavaScriptCore.vcxproj/testapi/testapiRelease.props: Removed. * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Removed. * shell/DLLLauncherMain.cpp: Copied from JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp. * shell/PlatformWin.cmake: 2016-06-09 Filip Pizlo Rare failure in stress/v8-deltablue-strict.js.ftl-eager https://bugs.webkit.org/show_bug.cgi?id=158591 Reviewed by Saam Barati. This is a simple and sensible fix to an amazing compiler bug that previously only manifested rarely in the v8-deltablue-strict test. It required on average 1000 runs while the system was under load for the bug to manifest. Fortunately, the bug is 100% repro with concurrent JIT disabled in the new "constant-fold-multi-get-by-offset-to-get-by-offset-on- prototype-and-sink-allocation.js" test. The problem here is that we were allowing ourselves to be super sloppy with the meaning of the two children of GetByOffset, and to a lesser extent, PutByOffset. The first two children of these nodes have these meanings: child1: the storage from which to load (or to which to store) child2: the logical object base Normally, child1 == child2, but child1 may point to a node that vends the storage pointer in case we are using multiple indirections to get to the property. That's fairly common. Where this gets nutty is that we don't validate the behavior of child1. Previously, the DFG::Validate phase would accept code that had child1 point to one object and child2 point to another object. That's bad because then, analyses will assume that we're loading from one object while we are actually loading from another. One of the fixes is to make Validate smarter about this, so that future problems with this get caught sooner. The actual bug was in ConstantFoldingPhase. When we first wrote ConstantFoldingPhase's logic for converting GetByIds and MultiGetByOffsets to GetByOffset, we assumed that this was only for non-prototype loads. This was becuase the logic was originally written based on a static GetByIdStatus analysis, which does not handle prototypes. So, as a shortcut, we would convert the GetById (or MultiGetByOffset) to a GetByOffset by doing this shuffling of children: child1 got the storage pointer, which might be a new GetButterfly node that we created. child2 got the old value of child1. The bug was introduced when I later made it possible for a monomorphic prototype MultiGetByOffset to be converted to a GetByOffset. Then this algorithm would mean that: child1 got either a pointer to the prototype or a storage pointer derived from the prototype. child2 got the old value of child1, which was a pointer to the base object (i.e. not the prototype). This happens super rarely because most prototype loads that we can statically reason about also happen to load constants, so we don't convert to GetByOffset at all. You need the strange combination of a MultiGetByOffset (not GetById or GetByOffset) on some prototypes and some static reasoning about the base so that we can convert it to a GetByOffset, but not enough static reasoning that we can convert it to a constant. Even if the bad thing happened, then this is not enough for it to cause symptons. If we did nothing else - like none of the other optimizations succeeded - then this would be OK because the backend will emit code based on child1, which is right. But disaster strikes when the code otherwise looks sane enough for ObjectAllocationSinkingPhase to kick in. This phase operates on child2, as any good phase should: child1 is only interesting for knowing *how* to load, not *what* we are loading. The phase is right to ignore child1. So the phase would assume that we are loading the prototype property ("f" in the new test or "addToGraph" in deltablue) from the sunken base object allocation in the inlined constructor. The base object has no such property, but the phase conservatively assumes that it does indeed have such a property. That's just how the phase does things: it is very abstract and general, so it assumes that the set of properties on an allocation is the set of properties that accesses to the allocation speak of. Clearly, this GetByOffset was speaking of the property as being on the allocation. When sinking completed, it would convert the GetByOffset to the sunken (a.k.a. promoted) property. But nobody stored to this property on the allocation, so we'd get the bottom value, which is 1927. Why 1927? I don't remember anymore, but apparently I chose it. It helped here - when I started seeing that value come up, it took a quick grep to realize that this was the object allocation sinking phase's bottom value. The real fix to the bug is to make Node::convertToGetByOffset() take an explicit new base since its clients will use it to potentially create a load on a different object than the base of the original operation, as in the relatively new MultiGetByOffset(prototype)->GetByOffset optimization. As far as I know, the PutByOffset code did not have the same bug because we don't have any optimizations that turn a PutById or MultiPutByOffset into a PutByOffset on anything but the base object. But the logical bug is definitely there: there's code in ConstantFoldingPhase that claims to be able to convert any node to a PutByOffset on any base, but it actually silently reuses the original node's child1 as the logical base (i.e. child2). This patch makes all of this stuff explicit. You can't make this mistake anymore. * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::emitGetByOffset): (JSC::DFG::ConstantFoldingPhase::emitPutByOffset): * dfg/DFGNode.h: (JSC::DFG::Node::convertToGetStack): (JSC::DFG::Node::convertToGetByOffset): (JSC::DFG::Node::convertToMultiGetByOffset): (JSC::DFG::Node::convertToPutByOffset): * dfg/DFGValidate.cpp: * tests/stress/constant-fold-multi-get-by-offset-to-get-by-offset-on-prototype-and-sink-allocation.js: Added. (ThingA): (ThingB): (foo): (bar): * tests/stress/sink-to-impossible-multi-get-by-offset-on-prototypes.js: Added. (ThingA): (ThingB): (ThingC): (bar): (foo): 2016-06-09 Mark Lam Make some methods const. https://bugs.webkit.org/show_bug.cgi?id=158594 Reviewed by Benjamin Poulain. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::columnNumberForBytecodeOffset): (JSC::CodeBlock::expressionRangeForBytecodeOffset): * bytecode/CodeBlock.h: * bytecode/ExpressionRangeInfo.h: (JSC::ExpressionRangeInfo::encodeFatColumnMode): (JSC::ExpressionRangeInfo::decodeFatLineMode): (JSC::ExpressionRangeInfo::decodeFatColumnMode): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): (JSC::UnlinkedCodeBlock::getLineAndColumn): (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::createRareDataIfNecessary): * interpreter/Interpreter.cpp: (JSC::Interpreter::isOpcode): (JSC::StackFrame::computeLineAndColumn): (JSC::StackFrame::toString): * interpreter/Interpreter.h: (JSC::StackFrame::isNative): 2016-06-09 Michael Saboff ES6: Reusing function name as a parameter name shouldn't throw Syntax Error https://bugs.webkit.org/show_bug.cgi?id=158575 Reviewed by Benjamin Poulain. The check for a parameter with a duplicate name doesn't take into account the type of the prior variable. Added a check that the duplicate is also a parameter. See the relevant spec section at: http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors * parser/Parser.h: (JSC::Scope::declareParameter): 2016-06-09 Chris Dumez Unreviewed, rolling out r201836, r201845, and r201848. Looks like a 1-2% PLT regression on iOS Reverted changesets: "[JSC] Change some parameters based on a random search" https://bugs.webkit.org/show_bug.cgi?id=158514 http://trac.webkit.org/changeset/201836 "Tempory fix for the debug bots" http://trac.webkit.org/changeset/201845 "Change thresholdForOptimizeSoon to match thresholdForOptimizeAfterWarmUp" http://trac.webkit.org/changeset/201848 2016-06-09 Commit Queue Unreviewed, rolling out r201810. https://bugs.webkit.org/show_bug.cgi?id=158563 breaks build without ENABLE_WEB_ANIMATION (Requested by mcatanzaro on #webkit). Reverted changeset: "[web-animations] Add Animatable, AnimationEffect, KeyframeEffect and Animation interface" https://bugs.webkit.org/show_bug.cgi?id=156096 http://trac.webkit.org/changeset/201810 2016-06-08 Gavin & Ellie Barraclough JSObject::reifyAllStaticProperties cleanup https://bugs.webkit.org/show_bug.cgi?id=158543 Reviewed by Mark Lam. - JSObject & Structure contain fields labeled 'staticFunctionsReified', however reification now affects all properties, not just functions. Rename to 'staticPropertiesReified'. - reifyAllStaticProperties relies on a 'hasStaticProperties' method on ClassInfo that walks the ClassInfo inheritance chain looking for static property tables. We can now more efficiently get this information from TypeInfo. - reifyAllStaticProperties triggers a 'toUncacheableDictionaryTransition'; this is overzealous, cacheable dictionary is sufficient - this is what we do in the case of DOM prototype property reification (see 'reifyStaticProperties' in Lookup.h). (Changing this with an eye on switching DOM prototype property reification to use JSObject:: reifyAllStaticProperties, rather than having its own special purpose code path.) * runtime/ClassInfo.h: (JSC::ClassInfo::hasStaticProperties): Deleted. - deprecated by TypeInfo::hasStaticPropertyTable. * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): (JSC::JSObject::deleteProperty): (JSC::JSObject::getOwnNonIndexPropertyNames): - staticFunctionsReified -> staticPropertiesReified (JSC::JSObject::reifyAllStaticProperties): - hasStaticProperties -> TypeInfo::hasStaticPropertyTable - toUncacheableDictionaryTransition -> toCacheableDictionaryTransition - staticFunctionsReified -> staticPropertiesReified * runtime/JSObject.h: (JSC::JSObject::staticPropertiesReified): (JSC::JSObject::staticFunctionsReified): Deleted. * runtime/Lookup.cpp: (JSC::setUpStaticFunctionSlot): * runtime/Lookup.h: (JSC::getStaticPropertySlotFromTable): (JSC::replaceStaticPropertySlot): * runtime/Structure.cpp: (JSC::Structure::Structure): * runtime/Structure.h: - staticFunctionsReified -> staticPropertiesReified 2016-06-08 Benjamin Poulain Change thresholdForOptimizeSoon to match thresholdForOptimizeAfterWarmUp Unreviewed. This adds back the assertion removed in r201845. Making those threshold equal is completely perf neutral (on Haswell rMBP with 20 runs). * runtime/Options.cpp: (JSC::Options::initialize): * runtime/Options.h: 2016-06-08 Benjamin Poulain Tempory fix for the debug bots Unreviewed. * runtime/Options.cpp: (JSC::Options::initialize): Weaken an assertion while I test values for thresholdForOptimizeSoon. 2016-06-08 Benjamin Poulain [JSC] Change some parameters based on a random search https://bugs.webkit.org/show_bug.cgi?id=158514 Reviewed by Filip Pizlo. Over the weekend, I left an iMac running the JSC benchmarks while changing a bunch of parameters. The parameters were changed randomly, with a random deviation from the original value. To converge toward good values, the range was subject to exponential annealing over time. The values in this patch is the best outcome my iMac could find over the weekend. It is about 1% better on the Haswell machines I tested. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::optimizationThresholdScalingFactor): * runtime/Options.h: 2016-06-08 Gavin Barraclough Remove removeDirect https://bugs.webkit.org/show_bug.cgi?id=158516 Reviewed by Ryosuke Niwa. removeDirect is typically used as a subroutine of deleteProperty, but is also available to call directly. Having this functionality factored out to a separate routine is a bad idea on a couple of fronts: - for the main use within deleteProperty there is redundancy (presence of the property was being checked twice) and inconsistency (the two functions returned different results in the case of a nonexistent property; the result from removeDirect was never observed). - all uses of removeDirect are in practical terms incorrect. removeDirect had the advantage of ignoring the configurable (DontDelete) attributes, but this is achievable using the DeletePropertyMode setting - and the disadvantage of failing delete static table properties. Last uses were one that was removed in bug #158295 (where failure to delete static properties was a problem), and as addressed in this patch removeDirect is being used to implement runtime enabled features. This only works because we currently force reification of all properties on the DOM prototype objects, so in effect there are no static properties. In order to make the code robust such that runtime enabled features would still work even if we were not reifying static properties (a change we may want to make) we should be calling deleteProperty in this case too. * runtime/JSObject.cpp: (JSC::JSObject::deleteProperty): - incorporated removeDirect functionality, added comments & ASSERT. (JSC::JSObject::removeDirect): Deleted. - removed. * runtime/JSObject.h: - removed removeDirect. 2016-06-08 Mark Lam Simplify Interpreter::StackFrame. https://bugs.webkit.org/show_bug.cgi?id=158498 Reviewed by Saam Barati. Previously, Interpreter::StackFrame (which is used to capture info for Error.stack) eagerly extracts info out of CodeBlock and duplicates the work that CodeBlock does to compute line and column numbers (amongst other things). This patch does away with the eager extraction and only stashes the CodeBlock pointer in the Interpreter::StackFrame. Instead, Interpreter::StackFrame will provide methods for computing the desired values on request later. One difference in implementation: the old StackFrame offers a sourceURL and a friendlySourceURL(). The only difference between the 2 is that for native functions, sourceURL returns an empty string, and friendlySourceURL() returns "[native code]". This is how it affects the clients of StackFrame: - In the old code, the Error object's addErrorInfoAndGetBytecodeOffset() and the inspector's createScriptCallStackFromException() would check if sourceURL is empty. If so, they will use this as an indicator to use alternate source info in the Error object e.g. url and line numbers from the parser that produced a SyntaxError. - In the new implementation, StackFrame only has a sourceURL() function that behaves like the old friendlySourceURL(). The client code which were relying on sourceURL being empty, will now explicitly check if the StackFrame is for native code using a new isNative() query in addition to the sourceURL being empty. This achieve functional parity with the old behavior. Also fix Error.cpp's addErrorInfoAndGetBytecodeOffset() to take a bytecodeOffset pointer instead of a reference. The bytecodeOffset arg is supposed to be optional, but was implemented in a unclear way. This change clarifies it. * inspector/ScriptCallStackFactory.cpp: (Inspector::createScriptCallStackFromException): * interpreter/Interpreter.cpp: (JSC::StackFrame::sourceID): (JSC::StackFrame::sourceURL): (JSC::StackFrame::functionName): (JSC::eval): (JSC::Interpreter::isOpcode): (JSC::StackFrame::computeLineAndColumn): (JSC::StackFrame::toString): (JSC::GetStackTraceFunctor::operator()): (JSC::StackFrame::friendlySourceURL): Deleted. (JSC::StackFrame::friendlyFunctionName): Deleted. (JSC::getStackFrameCodeType): Deleted. (JSC::StackFrame::expressionInfo): Deleted. * interpreter/Interpreter.h: (JSC::StackFrame::isNative): * runtime/Error.cpp: (JSC::addErrorInfoAndGetBytecodeOffset): (JSC::addErrorInfo): * runtime/Error.h: * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::finishCreation): 2016-06-08 Keith Miller We should be able to lookup symbols by identifier in builtins https://bugs.webkit.org/show_bug.cgi?id=158530 Reviewed by Mark Lam. This patch allows us to lookup the value of a symbol property on a object by identifier in builtins. Before, it was only possible to do so if we were directly emitting the bytecodes, such as in a for-of loop looking for Symbol.iterator. As we tier up we convert the builtin's get_by_val symbol lookups into get_by_id lookups. However, there is still a significant performance difference between get_by_id and get_by_val in the LLInt, where this transformation does not take place. In order to make this work we hijack BuiltinNames' m_publicToPrivateMap so that it points the @Symbol to the appropriate vm symbol. This way when we lex the identifier it will become the appropriate symbol's identifier. Currently, if the symbol is used to name a property in an object literal we will not keep a cache of the Symbol objects we have already seen. We could add a map for symbols but since we can only load symbols by identifier in builtins its likely not worth it. Additionally, even in builtins it is extremely rare to use Symbols in object literals. * builtins/ArrayConstructor.js: (from): * builtins/ArrayPrototype.js: (filter): (map): * builtins/BuiltinNames.h: (JSC::BuiltinNames::BuiltinNames): * builtins/BuiltinUtils.h: * builtins/GlobalObject.js: (speciesConstructor): * builtins/StringPrototype.js: (match): (intrinsic.StringPrototypeReplaceIntrinsic.replace): (search): (split): * builtins/TypedArrayConstructor.js: (from): * builtins/TypedArrayPrototype.js: (map): (filter): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): Deleted. * bytecode/BytecodeIntrinsicRegistry.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitLoad): * parser/Parser.cpp: (JSC::Parser::parseInner): 2016-06-08 Rawinder Singh [web-animations] Add Animatable, AnimationEffect, KeyframeEffect and Animation interface https://bugs.webkit.org/show_bug.cgi?id=156096 Reviewed by Dean Jackson. Adds: - Animatable interface and implementation of getAnimations in Element - Interface and implementation for Document getAnimations method. - AnimationEffect interface and class stub. - KeyframeEffect interface and constructor implementation. - 'Animation' interface, constructor and query methods for effect and timeline. - Remove runtime condition on Web animation interfaces (compile time flag is specified). * runtime/CommonIdentifiers.h: 2016-06-08 Chris Dumez self.hasOwnProperty() does not work inside Web workers https://bugs.webkit.org/show_bug.cgi?id=158446 Reviewed by Geoffrey Garen. Add a factory function to JSProxy to create a JSProxy without a target. Also make the setTarget() method public so that the target can now be set after creation. This is needed so that we can create a proxy for JSWorkerGlobalScope, then create the JSWorkerGlobalScope object, passing it the proxy and finally set the target on the proxy. * runtime/JSProxy.h: (JSC::JSProxy::create): 2016-06-07 Filip Pizlo Add result validation to JSAir https://bugs.webkit.org/show_bug.cgi?id=158493 Reviewed by Saam Barati. Add a ::jsHash() method to some things, to compute a hash code that is suitable for comparing a C++ Code to a JSAir Code. This is different from existing hashing functionality because it errs on the side of easy reproducibility from JS rather than speed. * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::isCompatibleType): (JSC::B3::Air::Arg::jsHash): (JSC::B3::Air::Arg::dump): * b3/air/AirArg.h: (JSC::B3::Air::Arg::asDoubleCondition): (JSC::B3::Air::Arg::isInvertible): (JSC::B3::Air::Arg::isUnsignedCond): (JSC::B3::Air::Arg::Arg): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::addFastTmp): (JSC::B3::Air::Code::jsHash): * b3/air/AirCode.h: (JSC::B3::Air::Code::lastPhaseName): * b3/air/AirDumpAsJS.cpp: (JSC::B3::Air::dumpAsJS): * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): * b3/air/AirInst.cpp: (JSC::B3::Air::Inst::hasArgEffects): (JSC::B3::Air::Inst::jsHash): (JSC::B3::Air::Inst::dump): * b3/air/AirInst.h: * b3/air/AirStackSlot.cpp: (JSC::B3::Air::StackSlot::setOffsetFromFP): (JSC::B3::Air::StackSlot::jsHash): (JSC::B3::Air::StackSlot::dump): * b3/air/AirStackSlot.h: * b3/air/opcode_generator.rb: 2016-06-07 Mark Lam Need an exception check after constructEmptyArray(). https://bugs.webkit.org/show_bug.cgi?id=158411 Reviewed by Saam Barati. Added an exception check after each call to constructEmptyArray(). * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::getInternalProperties): (Inspector::JSInjectedScriptHost::weakMapEntries): (Inspector::JSInjectedScriptHost::weakSetEntries): (Inspector::JSInjectedScriptHost::iteratorEntries): * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::functionsOnStack): * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::addSequenceProperties): * profiler/ProfilerCompilation.cpp: (JSC::Profiler::Compilation::toJS): * profiler/ProfilerDatabase.cpp: (JSC::Profiler::Database::toJS): * profiler/ProfilerOSRExitSite.cpp: (JSC::Profiler::OSRExitSite::toJS): * profiler/ProfilerOriginStack.cpp: (JSC::Profiler::OriginStack::toJS): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncConcat): (JSC::arrayProtoFuncSlice): (JSC::arrayProtoFuncSplice): * runtime/LiteralParser.cpp: (JSC::LiteralParser::parse): * runtime/ModuleLoaderObject.cpp: (JSC::moduleLoaderObjectRequestedModules): * runtime/ObjectConstructor.cpp: (JSC::ownPropertyKeys): * runtime/RegExpObject.cpp: (JSC::collectMatches): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncSplitFast): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncSplitFast): * runtime/TemplateRegistry.cpp: (JSC::TemplateRegistry::getTemplateObject): * tests/stress/regress-158411.js: Added. 2016-06-07 Filip Pizlo Implement Air::allocateStack() in ES6 to see how much of a bad idea that is https://bugs.webkit.org/show_bug.cgi?id=158318 Reviewed by Saam Barati. Most of these changes are to support dumpAsJS(). But I also found some duplicate and dead code while rewriting it to JS. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirAllocateStack.cpp: * b3/air/AirArg.h: (JSC::B3::Air::Arg::isSomeImm): (JSC::B3::Air::Arg::isAddr): (JSC::B3::Air::Arg::tmpIndex): (JSC::B3::Air::Arg::isValidImmForm): (JSC::B3::Air::Arg::withOffset): Deleted. This was dead code. * b3/air/AirArgInlines.h: It turns out that Inst has a ForEach thing that duplicated some of the logic of ArgThingHelper, so I just made ArgThingHelper more powerful. (JSC::B3::Air::ArgThingHelper::forEach): (JSC::B3::Air::ArgThingHelper::is): (JSC::B3::Air::ArgThingHelper::as): (JSC::B3::Air::ArgThingHelper::forEachFast): (JSC::B3::Air::ArgThingHelper::forEach): (JSC::B3::Air::Arg::is): * b3/air/AirDumpAsJS.cpp: Added. (JSC::B3::Air::dumpAsJS): * b3/air/AirDumpAsJS.h: Added. * b3/air/AirFixObviousSpills.cpp: * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): * b3/air/AirInstInlines.h: (JSC::B3::Air::Inst::forEach): (JSC::B3::Air::Inst::extraClobberedRegs): (JSC::B3::Air::ForEach::forEach): Deleted. This was doing what ArgThingHelper would have done but not as well. (JSC::B3::Air::ForEach::forEach): Deleted. (JSC::B3::Air::ForEach::forEach): Deleted. * b3/air/AirLogRegisterPressure.cpp: * b3/air/AirReportUsedRegisters.cpp: * b3/air/AirSpillEverything.cpp: * b3/air/opcode_generator.rb: Make this dump opcode.js, which is like what it dumps for C++. * jit/Reg.cpp: (JSC::Reg::debugName): (JSC::Reg::dump): * jit/Reg.h: (JSC::Reg::hash): * jsc.cpp: Fix jsc so that it reports the filename and line number of parser errors. (dumpException): * parser/ParserError.h: Make it easier to debug this code. (WTF::printInternal): * runtime/Options.h: 2016-06-07 Keith Rollin Remove all uses of PassRefPtr in WTF https://bugs.webkit.org/show_bug.cgi?id=157596 Reviewed by Chris Dumez. Update calls to interfaces that no longer take or return PassRefPtrs. * runtime/JSString.cpp: (JSC::JSRopeString::resolveRope): * runtime/JSString.h: (JSC::JSString::JSString): (JSC::jsSubstring): * runtime/PrivateName.h: (JSC::PrivateName::PrivateName): * runtime/SmallStrings.cpp: (JSC::SmallStringsStorage::SmallStringsStorage): * runtime/StringConstructor.cpp: (JSC::stringFromCharCodeSlowCase): * runtime/StringPrototype.cpp: (JSC::jsSpliceSubstrings): (JSC::jsSpliceSubstringsWithSeparators): (JSC::replaceUsingStringSearch): (JSC::repeatCharacter): (JSC::stringProtoFuncFontsize): (JSC::stringProtoFuncLink): (JSC::normalize): 2016-06-07 Saam barati InvalidationPointInjectionPhase creates bogus InvalidationPoints that may even be inserted when it's not OK to exit https://bugs.webkit.org/show_bug.cgi?id=158499 Reviewed by Mark Lam and Benjamin Poulain. InvalidationPointInjectionPhase forgot to clear m_originThatHadFire before analyzing the current block it's analyzing. This meant that the phase allowed a residual m_originThatHadFire that was set from the previous block to effect a completely unrelated block. This is usually harmless, but sometimes we would insert an InvalidationPoint at a point in the graph when exiting is invalid. This would cause a crash. * dfg/DFGInvalidationPointInjectionPhase.cpp: (JSC::DFG::InvalidationPointInjectionPhase::run): * tests/stress/dont-crash-on-bad-invalidation-point.js: Added. (dontCrash): 2016-06-07 Saam Barati operationProcessTypeProfilerLogDFG doesn't update topCallFrame https://bugs.webkit.org/show_bug.cgi?id=158428 Reviewed by Mark Lam. * dfg/DFGOperations.cpp: 2016-06-07 Mark Lam calculatedDisplayName() and friends actually need a VM& and not a ExecState/CallFrame. https://bugs.webkit.org/show_bug.cgi?id=158488 Reviewed by Geoffrey Garen. calculatedDisplayName() (and some of its friends) actually just need a VM&. Their work has nothing to do with an ExecState at all. This patch will make that clear by changing these functions to take a VM& arg instead of an ExecState* or CallFrame*. Also removed the JS_EXPORT_PRIVATE attribute from Interpreter::StackFrame::toString(). The JS_EXPORT_PRIVATE attribute was a holdover from the days when WebInspector was entirely in WebCore. It is no longer needed. * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::functionName): * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::functionDetails): * inspector/ScriptCallStackFactory.cpp: (Inspector::createScriptCallStackFromException): * interpreter/CallFrame.cpp: (JSC::CallFrame::friendlyFunctionName): * interpreter/Interpreter.cpp: (JSC::StackFrame::friendlySourceURL): (JSC::StackFrame::friendlyFunctionName): (JSC::StackFrame::expressionInfo): (JSC::StackFrame::toString): (JSC::Interpreter::stackTraceAsString): * interpreter/Interpreter.h: * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::functionName): * runtime/InternalFunction.cpp: (JSC::InternalFunction::name): (JSC::InternalFunction::displayName): (JSC::InternalFunction::getCallData): (JSC::InternalFunction::calculatedDisplayName): * runtime/InternalFunction.h: (JSC::InternalFunction::createStructure): * runtime/JSFunction.cpp: (JSC::JSFunction::name): (JSC::JSFunction::displayName): (JSC::JSFunction::calculatedDisplayName): (JSC::JSFunction::getConstructData): (JSC::getCalculatedDisplayName): * runtime/JSFunction.h: (JSC::JSFunction::executable): * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): 2016-06-07 Yusuke Suzuki [JSC] Do not allocate unnecessary UTF-8 string for encodeXXX functions https://bugs.webkit.org/show_bug.cgi?id=158416 Reviewed by Darin Adler and Geoffrey Garen. Previously, encodeXXX functions first allocate new UTF-8 string, and generate (& allocate) the results from this UTF-8 string. It is costly since this UTF-8 string is always wasted. In this patch, we generate the results without this UTF-8 string. We precisely implement ECMA262's Encode abstract operation[1]. This optimized encodeXXX functions provide great improvement in kraken stanford-crypto-sha256-iterative since it frequently calls these functions. We can see 6 - 7% improvements. baseline patched stanford-crypto-sha256-iterative 37.952+-0.155 ^ 35.484+-0.265 ^ definitely 1.0695x faster [1]: https://tc39.github.io/ecma262/#sec-encode * runtime/JSGlobalObjectFunctions.cpp: (JSC::toSafeView): Use this helper function to retrieve JSString::SafeView. (JSC::makeCharacterBitmap): (JSC::encode): In encode, we reserve N length buffer at first. This is important when the length of the given string is long enough, preventing frequent unnecessary buffer reallocations. This reserving contributes to 1% kraken stanford-crypto-sha256-iterative progression. (JSC::decode): Previously, Bitmap accidentally includes \0. And instead of removing this \0, we checked character != 0. This patch fixes it for the Bitmap not to include \0. (JSC::globalFuncParseInt): (JSC::globalFuncEscape): (JSC::globalFuncUnescape): * tests/stress/encode-decode-ascii.js: Added. (shouldBe): * tests/stress/encode-decode-unicode.js: Added. (shouldBe): (isLowSurrogate): (isHighSurrogate): (isSurrogate): * tests/stress/encode-decode-uri-component-surrogates.js: Added. (shouldBe): (toHighSurrogate): (toLowSurrogate): * tests/stress/encode-decode-uri-surrogates.js: Added. (shouldBe): (toHighSurrogate): (toLowSurrogate): * tests/stress/encode-decode-zero.js: Added. (shouldBe): * tests/stress/escape-unescape-surrogates.js: Added. (shouldBe): (toHighSurrogate): (toLowSurrogate): 2016-06-07 Ting-Wei Lan [GTK] Include locale.h before using LC_ALL https://bugs.webkit.org/show_bug.cgi?id=158470 Reviewed by Darin Adler. * jsc.cpp: 2016-06-07 Joseph Pecoraro Unskip generator related stress tests https://bugs.webkit.org/show_bug.cgi?id=158461 Reviewed by Darin Adler. * tests/stress/generator-methods.js: * tests/stress/generator-syntax.js: * tests/stress/yield-and-line-terminator.js: * tests/stress/yield-label-generator.js: * tests/stress/yield-named-accessors-generator.js: * tests/stress/yield-named-variable-generator.js: * tests/stress/yield-out-of-generator.js: 2016-06-06 Joseph Pecoraro Fix typo in test name trailing-comma-in-function-paramters.js https://bugs.webkit.org/show_bug.cgi?id=158462 Reviewed by Mark Lam. * tests/stress/trailing-comma-in-function-parameters.js: Renamed from Source/JavaScriptCore/tests/stress/trailing-comma-in-function-paramters.js. 2016-06-06 Andreas Kling REGRESSION(r197595): 2% JSBench regression on iPhone 5. Unreviewed rollout. * runtime/VM.cpp: (JSC::VM::deleteAllRegExpCode): Deleted. * runtime/VM.h: 2016-06-06 Michael Saboff octal and binary parsing is wrong for some programs https://bugs.webkit.org/show_bug.cgi?id=158437 Reviewed by Saam Barati. When there is an error parsing an binary or octal literal, we need to clear the returnValue of any residual value. This is because the processing of returnValue happens before the syntax check for the extra character. Without clearing returnValue, we end trying to categorize the value as an INTEGER or DOUBLE token. If the value happens to be an impure NaN, we ASSERT. * parser/Lexer.cpp: (JSC::Lexer::parseBinary): (JSC::Lexer::parseOctal): * tests/stress/regress-158437.js: New test. 2016-06-06 Mark Lam 32-bit JSC stress test failing: stress/recursive-try-catch.js.ftl-no-cjit-validate-sampling-profiler https://bugs.webkit.org/show_bug.cgi?id=158362 Reviewed by Michael Saboff. The test does infinite recursion until it overflows the stack. That means the sampling profiler will have to capture excessively large samples, which in turn makes it run very slowly. This is what causes the test time out. The fix is to not run the test with the sampling profiler. * tests/stress/recursive-try-catch.js: 2016-06-06 Andreas Kling Don't reportAbandonedObjectGraph() after throwing out linked code or RegExps. Unreviewed. This is a speculative change for iOS performance bots. The calls to reportAbandonedObjectGraph were basically redundant, since mainframe navigation will cause GC acceleration anyway via ScriptController. This appears successful at recovering the ~0.7% regression I could reproduce locally on newer hardware but it's a bit too noisy to say for sure. * runtime/VM.cpp: (JSC::VM::deleteAllLinkedCode): (JSC::VM::deleteAllRegExpCode): 2016-06-06 Skachkov Oleksandr [ESNext] Trailing commas in function parameters. https://bugs.webkit.org/show_bug.cgi?id=158020 Reviewed by Keith Miller. ESNext allow to add trailing commas in function parameters and function arguments. Link to spec - https://jeffmo.github.io/es-trailing-function-commas Example of using - (function (a, b,) { return a + b; })(1,2,); * parser/Parser.cpp: (JSC::Parser::parseFormalParameters): (JSC::Parser::parseArguments): * tests/stress/trailing-comma-in-function-paramters.js: Added. 2016-06-05 Gavin & Ellie Barraclough Deprecate remaining uses of Lookup getStatic*, use HasStaticPropertyTable instead. https://bugs.webkit.org/show_bug.cgi?id=158178 Reviewed by Darin Adler. As of bug #158059 most JSC static table property access no longer requires getOwnPropertySlot to be overridden. Port remaining calls to the getStatic* functions in Lookup.h over to the new mechanism. Deprecate getStatic* functions in Lookup.h * runtime/Lookup.h: (JSC::getStaticPropertySlot): Deleted. (JSC::getStaticFunctionSlot): Deleted. (JSC::getStaticValueSlot): Deleted. - No longer required. Static table access now via JSObject. 2016-06-06 Guillaume Emont [jsc][mips] Implement absDouble() https://bugs.webkit.org/show_bug.cgi?id=158206 Reviewed by Mark Lam. Implement absDouble() for MIPS. This is needed because Math.pow() uses it since r200208. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::absd): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::absDouble): 2016-06-03 Oliver Hunt RegExp unicode parsing reads an extra character before failing https://bugs.webkit.org/show_bug.cgi?id=158376 Reviewed by Saam Barati. This was a probably harmless bug, but keeps triggering assertions for me locally. Essentially we'd see a parse error, set the error type, but then carry on parsing. In debug builds this asserts, in release builds you are pretty safe unless you're exceptionally unlucky with where the error occurs. * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): 2016-06-06 Guillaume Emont [jsc][mips] fix JIT::emit_op_log_shadow_chicken_prologue/_tail https://bugs.webkit.org/show_bug.cgi?id=158209 Reviewed by Mark Lam. On MIPS, changes GPRInfo::nonArgGPR0 to be regT4 instead of regT0, since the code of JIT::emit_op_log_shadow_chicken_prologue/_tail() expects nonArgGPR0 to be a different register from regT0 and regT2. * jit/GPRInfo.h: 2016-06-06 Chris Dumez Crash under JSObject::getOwnPropertyDescriptor() https://bugs.webkit.org/show_bug.cgi?id=158382 Reviewed by Mark Lam. * runtime/JSObject.h: (JSC::JSObject::putDirectInternal): We were crashing under getOwnPropertyDescriptor() because the CustomAccessor was not properly reset on window.statusbar when setting it to false (which is allowed because the property is marked as [Replaceable] in the IDL). We now property reset the CustomAccessor flag in putDirectInternal() when needed. This fixes the crash. 2016-06-06 Gyuyoung Kim [EFL] Move efl include paths to JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES https://bugs.webkit.org/show_bug.cgi?id=158418 Reviewed by Csaba Osztrogonác. In Source/JavaScriptCore/PlatformEfl.cmake, we don't use JavaScriptCore_SYSTEM_INCLUDE_DIRECTORIES for efl include paths. * PlatformEfl.cmake: * tests/stress/encode-decode-ascii.js: Added. (shouldBe): * tests/stress/encode-decode-unicode.js: Added. (shouldBe): (isLowSurrogate): (isHighSurrogate): (isSurrogate): * tests/stress/encode-decode-uri-component-surrogates.js: Added. (shouldBe): (toHighSurrogate): (toLowSurrogate): * tests/stress/encode-decode-uri-surrogates.js: Added. (shouldBe): (toHighSurrogate): (toLowSurrogate): * tests/stress/encode-decode-zero.js: Added. (shouldBe): * tests/stress/escape-unescape-surrogates.js: Added. (shouldBe): (toHighSurrogate): (toLowSurrogate): 2016-06-05 Yusuke Suzuki Change ProxyObject.[[Get]] not to use custom accessor https://bugs.webkit.org/show_bug.cgi?id=157080 Reviewed by Darin Adler. This patch focuses on introducing the second part of the followings. But to do so, first and third parts are necessary. 1. Insert missing exception checks for getPropertySlot. While getPropertySlot can perform user-observable behavior if the slot is not VMInquiry, several places miss exeption checks. For example, ProxyObject's hasProperty already can throw any errors. Looking through the code, we found several missing error checks after hasProperty, but this will be fixed in the separated patch[1]. 2. Do not use custom accessor to implement ProxyObject's [[Get]]. The caller already allows getOwnPropertySlot to throw an exception if the type is not VMInquiry. So instead of using custom accessor, we simply implement it directly in the ProxyObject's method. 3. Strip slotBase from custom accessor. The custom accessor should not be bound to the specific slot base[2], since it is just an accessor. There is an alternative design: makeing this custom accessor to custom value accessor and accept both the slot base and the receiver instead of allowing throwing an error from getOwnPropertySlot. But we take the first design that allows getPropertySlot to throw an error, since hasProperty (that does not call getValue of the custom getters) can already throw any errors. To query the property with the non-user-observable way, we already provided the way for that: use VMInquiry and isTaintedByProxy() instead. Tests just ensure that the current semantics works correctly after this patch. And this patch is performance neutral. Later, we will attempt to rename "thisValue" to "receiver"[3]. [1]: https://bugs.webkit.org/show_bug.cgi?id=158398 [2]: https://bugs.webkit.org/show_bug.cgi?id=157978 [3]: https://bugs.webkit.org/show_bug.cgi?id=158397 * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::staticFunctionGetter): (JSC::JSCallbackObject::callbackGetter): * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generateImpl): * dfg/DFGOperations.cpp: * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * jsc.cpp: (WTF::ImpureGetter::getOwnPropertySlot): (WTF::CustomGetter::customGetter): (WTF::RuntimeArray::lengthGetter): (GlobalObject::finishCreation): (GlobalObject::moduleLoaderFetch): (functionGetGetterSetter): (functionRun): (functionLoad): (functionLoadString): (functionReadFile): (functionCheckSyntax): (functionLoadWebAssembly): (functionLoadModule): (functionCreateBuiltin): (functionCheckModuleSyntax): (dumpException): (runWithScripts): (runInteractive): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSBoundSlotBaseFunction.cpp: (JSC::boundSlotBaseFunctionCall): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::getPropertySlot): * runtime/JSCellInlines.h: (JSC::ExecState::vm): This change is super important for performance. We add several `exec->hadException()` calls into the super hot path, like JSC::operationGetByIdOptimize. Without this change, we call ExecState::vm() and it is not inlined. This causes 1 - 2% performance regression in Octane PDFJS. * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): * runtime/JSFunction.h: * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewWithArguments): * runtime/JSModuleNamespaceObject.cpp: (JSC::callbackGetter): * runtime/JSONObject.cpp: (JSC::Stringifier::Holder::appendNextProperty): Here's UNLIKELY is important for Kraken's json-stringify-tinderbox. Without it, we can observe 0.5% regression. (JSC::Walker::walk): * runtime/JSObject.h: (JSC::JSObject::getPropertySlot): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncToString): * runtime/PropertySlot.cpp: (JSC::PropertySlot::customGetter): * runtime/PropertySlot.h: (JSC::PropertySlot::thisValue): * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performGet): (JSC::ProxyObject::getOwnPropertySlotCommon): * runtime/ProxyObject.h: * runtime/RegExpConstructor.cpp: (JSC::regExpConstructorDollar): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): * tests/stress/get-from-scope-dynamic-onto-proxy.js: Added. (shouldBe): (shouldThrow.handler.has): (handler.has): (try.handler.has): * tests/stress/operation-in-throw-error.js: Added. (testCase.handler.has): (testCase): * tests/stress/proxy-and-json-stringify.js: Added. (shouldThrow): * tests/stress/proxy-and-typed-array.js: Added. * tests/stress/proxy-json-path.js: Added. * tests/stress/proxy-with-statement.js: Added. 2016-06-03 Gavin & Ellie Barraclough Deprecate remaining uses of Lookup getStatic*, use HasStaticPropertyTable instead. https://bugs.webkit.org/show_bug.cgi?id=158178 Reviewed by Darin Adler. As of bug #158059 most JSC static table property access no longer requires getOwnPropertySlot to be overridden. Port remaining calls to the getStatic* functions in Lookup.h over to the new mechanism. Part 1: Switch JSGlobalObject & JSDOMWindow to use HasStaticPropertyTable. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::getOwnPropertySlot): - Override is still required for symbol table, but regular property access is now via Base::getOwnPropertySlot. * runtime/JSGlobalObject.h: - add HasStaticPropertyTable to structureFlags. 2016-06-03 Benjamin Poulain Eager FTL failure for strict comparison of NaN with number check https://bugs.webkit.org/show_bug.cgi?id=158368 Reviewed by Darin Adler. DoupleRep with a RealNumberUse starts by handling double then falls back to Int32 if the unboxed double is NaN. Before handling integers, the code is checking if the input is indeed an int32. The problem was that this check failed to account for NaN as an original input of the DoubleRep. The call to isNotInt32() filter the doubles checks because that was handled by the previous block. The problem is the previous block handles any double except NaN. If the original input was NaN, the masking by "~SpecFullDouble" filter that possibility and isNotInt32() fails to test that case. This patch fixes the issue by changing the filter to SpecDoubleReal. The type SpecDoubleReal does not include the NaN types. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep): * tests/stress/double-rep-real-number-use-on-nan.js: Added. To ensure the isNotInt32() does not test anything, we want proven numbers as input. The (+value) are there to enforce a ToNumber() which in turn give us a proven Number type. 2016-06-03 Benjamin Poulain JSON.stringify replacer function calls with numeric array indices https://bugs.webkit.org/show_bug.cgi?id=158262 rdar://problem/26613876 Reviewed by Saam Barati. The spec of SerializeJSONArray is pretty clear that the index should be transformed into a string before calling SerializeJSONProperty. See http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonarray * runtime/JSONObject.cpp: (JSC::PropertyNameForFunctionCall::value): 2016-06-03 Saam barati Proxy.ownKeys should no longer throw an exception when duplicate keys are returned and the target is non-extensible https://bugs.webkit.org/show_bug.cgi?id=158350 Reviewed by Michael Saboff. The spec was recently changes in Proxy [[OwnPropertyKeys]] to allow for duplicate property names under certain circumstances. This patch fixes our implementation to match the spec. See: https://github.com/tc39/ecma262/pull/594 * runtime/ProxyObject.cpp: (JSC::ProxyObject::performGetOwnPropertyNames): * tests/stress/proxy-own-keys.js: (i.catch): (ownKeys): (assert): 2016-06-03 Saam barati Some shadow chicken code is wrong when run on a big endian CPU https://bugs.webkit.org/show_bug.cgi?id=158361 Reviewed by Mark Lam. This code was wrong on a big endian CPU, and it was also an anti-pattern in the file. The code was harmless on a little endian CPU, but it's better to remove it. * llint/LowLevelInterpreter64.asm: 2016-06-03 Keith Miller Add argument_count bytecode for concat https://bugs.webkit.org/show_bug.cgi?id=158358 Reviewed by Geoffrey Garen. This patch adds a new argument count bytecode. Normally, we would just make sure that the argument.length bytecode was fast enough that we shouldn't need such an bytecode. However, for the case of Array.prototype.concat the overhead of the arguments object allocation in the LLInt was too high and caused regressions. * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_argumentCount): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getArgumentCount): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_argument_count): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * tests/stress/argument-count-bytecode.js: Added. (inlineCount): (inlineCount1): (inlineCount2): (inlineCountVarArgs): (assert): 2016-06-03 Geoffrey Garen Clients of PolymorphicAccess::addCases shouldn't have to malloc https://bugs.webkit.org/show_bug.cgi?id=158357 Reviewed by Keith Miller. We only ever have 1 or 2 cases, so we can use inline Vector capacity. This shows up a little in the JSBench profile. * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::addCases): (JSC::PolymorphicAccess::addCase): * bytecode/PolymorphicAccess.h: * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): 2016-06-03 Benjamin Poulain Fix some more INFINITI->INFINITY typos Unreviewed. The tests were not covering the edge cases they were supposed to test. * tests/stress/math-ceil-basics.js: (testMathCeilOnConstants): * tests/stress/math-clz32-basics.js: (testMathClz32OnDoubles): (testMathClz32OnConstants): * tests/stress/math-floor-basics.js: (testMathFloorOnConstants): * tests/stress/math-round-basics.js: (testMathRoundOnConstants): * tests/stress/math-trunc-basics.js: (testMathTruncOnConstants): 2016-06-02 Gavin & Ellie Barraclough JSGlobalObject::addFunction should call deleteProperty rather than removeDirect https://bugs.webkit.org/show_bug.cgi?id=158295 Reviewed by Saam Barati. When a function in declared in program code, this replaces any previosly existing property from the global object. JSGlobalObject::addFunction is currently calling removeDirect rather than deleteProperty to remove the existing property. This fails to remove any properties from static tables. We currently get away with this because (a) JSObject & JSGlobalObject don't currently have any properties in static tables, and (b) the current quirky property precedence means that the symbol table properties end up taking precedence over JSDOMWindow's static table, so window object properties end up being shadowed. As a part of bug #158178 the precedence of static tables will change, requiring this to be fixed. The deleteProperty function does what we want (has the ability to remove properties, including those from the static tables). Normally deleteProperty will not remove properties that are non-configurable (DontDelete) - we need to do so. The function does already support this, through a flag on VM named 'isInDefineOwnProperty', which causes configurability to be ignored. Generalize this mechanism for use outside of defineOwnProperty, renaming & moving DefineOwnPropertyScope helper class out to VM. * runtime/JSFunction.cpp: (JSC::JSFunction::deleteProperty): - isInDefineOwnProperty -> deletePropertyMode. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addFunction): - removeDirect -> deleteProperty. * runtime/JSObject.cpp: (JSC::JSObject::deleteProperty): - isInDefineOwnProperty -> deletePropertyMode. (JSC::JSObject::defineOwnNonIndexProperty): - DefineOwnPropertyScope -> VM::DeletePropertyModeScope. (JSC::DefineOwnPropertyScope::DefineOwnPropertyScope): Deleted. (JSC::DefineOwnPropertyScope::~DefineOwnPropertyScope): Deleted. - DefineOwnPropertyScope -> VM::DeletePropertyModeScope. * runtime/VM.cpp: (JSC::VM::VM): - removed m_inDefineOwnProperty. * runtime/VM.h: (JSC::VM::deletePropertyMode): - isInDefineOwnProperty -> deletePropertyMode. (JSC::VM::DeletePropertyModeScope::DeletePropertyModeScope): (JSC::VM::DeletePropertyModeScope::~DeletePropertyModeScope): - DefineOwnPropertyScope -> VM::DeletePropertyModeScope. (JSC::VM::setInDefineOwnProperty): Deleted. - Replaced with deletePropertyMode, can now only be set via VM::DeletePropertyModeScope. (JSC::VM::isInDefineOwnProperty): Deleted. - isInDefineOwnProperty -> deletePropertyMode. 2016-06-03 Mark Lam ARMv7 vstm and vldm instructions can only operate on a maximum of 16 registers. https://bugs.webkit.org/show_bug.cgi?id=158349 Reviewed by Filip Pizlo. According to the ARM Assembler Reference, the vstm and vldm instructions can only operate on a maximum of 16 registers. See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s03s02.html and http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/ch01s03s02.html. The ARMv7 probe code was wrongly using these instructions to store and load all 32 'd' registers. This is now fixed. * assembler/MacroAssemblerARMv7.cpp: 2016-06-03 Mark Lam Gardening: CLOOP build fix (needs a #include). Not reviewed. * interpreter/StackVisitor.h: 2016-06-03 Andreas Kling Eliminate two large sources of temporary StringImpl objects. Reviewed by Anders Carlsson. We were jumping through some inefficient hoops when creating Identifiers due to the convenience of our String(const char*) constructor. This patch avoids just over 1 million temporary StringImpl objects on the PLUM benchmark. * runtime/JSObject.h: (JSC::makeIdentifier): Add an overload for string literals so we can stop creating a temporary String just for passing to Identifier::fromString(). * runtime/Lookup.h: (JSC::reifyStaticProperties): Use the Identifier::fromString() that takes an LChar* and a length instead of creating a temporary String. 2016-06-03 Mark Lam Clean up how StackVisitor dumps its frames. https://bugs.webkit.org/show_bug.cgi?id=158316 Reviewed by Keith Miller. 1. Updated to do dumping to a PrintStream. 2. Added support for printing a prefix for each frame. This is currently used by JSDollarVMPrototype to print frame numbers. 3. Fix the incrementing of the frame index in StackVisitor. It was initialized but never incremented before when iterating the frames. * interpreter/StackVisitor.cpp: (JSC::StackVisitor::gotoNextFrame): (JSC::StackVisitor::Frame::codeType): (JSC::StackVisitor::Frame::functionName): (JSC::StackVisitor::Frame::sourceURL): (JSC::StackVisitor::Frame::toString): (JSC::StackVisitor::Frame::createArguments): (JSC::StackVisitor::Frame::computeLineAndColumn): (JSC::StackVisitor::Frame::retrieveExpressionInfo): (JSC::StackVisitor::Frame::setToEnd): (JSC::StackVisitor::Frame::dump): (JSC::StackVisitor::Indent::dump): (JSC::printIndents): Deleted. (JSC::log): Deleted. (JSC::logF): Deleted. (JSC::StackVisitor::Frame::print): Deleted. * interpreter/StackVisitor.h: (JSC::StackVisitor::Indent::Indent): (JSC::StackVisitor::Indent::operator++): (JSC::StackVisitor::Indent::operator--): (JSC::StackVisitor::Frame::isJSFrame): (JSC::StackVisitor::Frame::isInlinedFrame): (JSC::StackVisitor::Frame::vmEntryFrame): (JSC::StackVisitor::Frame::callFrame): (JSC::StackVisitor::Frame::Frame): (JSC::StackVisitor::Frame::~Frame): * tools/JSDollarVMPrototype.cpp: (JSC::PrintFrameFunctor::operator()): 2016-06-02 Saam Barati global lexical environment variables are not accessible through functions created using the function constructor https://bugs.webkit.org/show_bug.cgi?id=158319 Reviewed by Filip Pizlo. When creating a function using the Function constructor, we were using the global object instead of the global lexical environment as the function's scope. We should be using the global lexical environment. * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * tests/stress/function-constructor-reading-from-global-lexical-environment.js: Added. (assert): (test): (ClassTDZ): 2016-06-02 Oliver Hunt JS parser incorrectly handles invalid utf8 in error messages. https://bugs.webkit.org/show_bug.cgi?id=158128 Reviewed by Saam Barati. The bug here was caused by us using PrintStream's toString method to produce the error message for a parse error, even though toString may produce a null string in the event of invalid utf8 that causes the error in first case. So when we try to create an error message containing the invalid character code, we set m_errorMessage to the null string, as that signals "no error" we don't stop parsing, and everything goes down hill from there. Now we use the new toStringWithLatin1Fallback so that we can always produce an error message, even if it contains invalid unicode. We also add an additional fallback so that we can guarantee an error message is set even if we're given a null string. There's a debug mode assertion to prevent anyone accidentally attempting to clear the message via setErrorMessage. * parser/Parser.cpp: (JSC::Parser::logError): * parser/Parser.h: (JSC::Parser::setErrorMessage): 2016-06-02 Saam Barati Teach bytecode liveness about the debugger https://bugs.webkit.org/show_bug.cgi?id=158288 Reviewed by Filip Pizlo. There was a bug where we wouldn't always keep the scope register on the stack when the debugger is enabled. The debugger always assumes it can read from the scope. The bug happened in OSR exit from the FTL. The FTL uses bytecode liveness for OSR exit. Bytecode liveness proved that the scope register was dead, so the FTL OSR exit wrote `undefined` into the scope's stack slot when OSR exiting to the baseline. To fix this, I taught bytecode liveness' computeUsesForBytecodeOffset() that the scope is used by every instruction except op_enter. This causes the scope to be live-in at every instruction except op_enter. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::blockContainsBytecodeOffset): (JSC::addAlwaysLiveLocals): (JSC::findBasicBlockForBytecodeOffset): (JSC::stepOverInstruction): (JSC::computeLocalLivenessForBytecodeOffset): (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * tests/stress/shadow-chicken-reading-from-scope-after-ftl-osr-exit-bytecode-liveness.js: Added. (foo): (catch): 2016-06-02 Michael Saboff REGRESSION(r200694): %ThrowTypeError% is not unique https://bugs.webkit.org/show_bug.cgi?id=158231 Reviewed by Joseph Pecoraro. The ES6 standard in section 9.2.7.1 states that %ThrowTypeError% is unique. This change reverts the handling of TypeError before r200694 and then rolls in throwTypeErrorGetterSetter() with the renamed throwTypeErrorArgumentsCalleeAndCallerGetterSetter(). * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::getOwnPropertySlot): (JSC::ClonedArguments::materializeSpecials): * runtime/JSBoundFunction.cpp: (JSC::JSBoundFunction::finishCreation): (JSC::JSBoundFunction::visitChildren): * runtime/JSFunction.cpp: (JSC::getThrowTypeErrorGetterSetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::defineOwnProperty): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction): (JSC::JSGlobalObject::regExpProtoGlobalGetter): (JSC::JSGlobalObject::regExpProtoUnicodeGetter): (JSC::JSGlobalObject::throwTypeErrorArgumentsCalleeAndCallerGetterSetter): (JSC::JSGlobalObject::moduleLoader): (JSC::JSGlobalObject::throwTypeErrorGetterSetter): Deleted. (JSC::JSGlobalObject::throwTypeErrorCalleeAndCallerGetterSetter): Deleted. (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInStrictModeGetterSetter): Deleted. (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInClassContextGetterSetter): Deleted. * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncThrowTypeError): (JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller): (JSC::globalFuncThrowTypeErrorCalleeAndCaller): Deleted. (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInStrictMode): Deleted. (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInClassContext): Deleted. * runtime/JSGlobalObjectFunctions.h: * tests/stress/reflect-set.js: 2016-06-02 Michael Saboff [iOS]: Some JSC stress tests fail running out of executable memory when the LLInt is disabled https://bugs.webkit.org/show_bug.cgi?id=158317 Reviewed by Saam Barati. Updated these test to not run the "no-llint" variant when running on ARM machines. * tests/stress/arrowfunction-lexical-bind-superproperty.js: Skip no-llint for ARM (testCase): * tests/stress/proxy-revoke.js: Skipp no-lint for ARM and ARM64 (assert): 2016-06-02 Keith Miller Unreviewed, reland r201532. The associated regressions have been fixed by r201584. 2016-06-02 Filip Pizlo Use "= delete" for Locker(int) Rubber stamped by Saam Barati. * runtime/ConcurrentJITLock.h: (JSC::ConcurrentJITLocker::ConcurrentJITLocker): 2016-06-02 Keith Miller ObjectPropertyCondition should have a isStillValidAssumingImpurePropertyWatchpoint function https://bugs.webkit.org/show_bug.cgi?id=158308 Reviewed by Filip Pizlo. Recently, structureEnsuresValidityAssumingImpurePropertyWatchpoint was converted to check what should be isStillValidAssumingImpurePropertyWatchpoint. This patch fixes the API so it should work as expected. This patch also changes generateConditions in ObjectPropertyConditionSet to use isStillValidAssumingImpurePropertyWatchpoint. * bytecode/ObjectPropertyCondition.cpp: (JSC::ObjectPropertyCondition::structureEnsuresValidityAssumingImpurePropertyWatchpoint): (JSC::ObjectPropertyCondition::isStillValidAssumingImpurePropertyWatchpoint): * bytecode/ObjectPropertyCondition.h: * bytecode/ObjectPropertyConditionSet.cpp: 2016-06-02 Filip Pizlo Make it harder to accidentally pass an integer to a locker. Rubber stamped by Keith Miller. * runtime/ConcurrentJITLock.h: (JSC::ConcurrentJITLocker::ConcurrentJITLocker): 2016-06-02 Filip Pizlo Make it easier to use NoLockingNecessary https://bugs.webkit.org/show_bug.cgi?id=158306 Reviewed by Keith Miller. Adapt to the new NoLockingNecessary API. More details in the WTF ChangeLog. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded): (JSC::BytecodeGenerator::instantiateLexicalVariables): (JSC::BytecodeGenerator::emitPrefillStackTDZVariables): (JSC::BytecodeGenerator::initializeBlockScopedFunctions): (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary): (JSC::BytecodeGenerator::popLexicalScopeInternal): (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration): (JSC::BytecodeGenerator::variable): (JSC::BytecodeGenerator::createVariable): (JSC::BytecodeGenerator::emitResolveScope): (JSC::BytecodeGenerator::emitPushFunctionNameScope): * runtime/ConcurrentJITLock.h: (JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase): (JSC::ConcurrentJITLocker::ConcurrentJITLocker): 2016-06-01 Filip Pizlo Structure::previousID() races with Structure::allocateRareData() https://bugs.webkit.org/show_bug.cgi?id=158280 Reviewed by Mark Lam. The problem is that previousID() would test hasRareData() and then either load the previous Structure from the rare data, or load it directly. allocateRareData() would set the hasRareData() bit separately from moving the Structure pointer into the rare data. So we'd have a race that would cause previousID() to sometimes return the rarae data instead of the previous Structure. The fix is to get rid of the hasRareData bit. We can use the structureID of the previousOrRareData cell to determine if it's the previousID or the RareData. This fixes the race and it's probably not any slower. * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::allocateRareData): * runtime/Structure.h: 2016-06-01 Michael Saboff Runaway WebContent process CPU & memory @ foxnews.com https://bugs.webkit.org/show_bug.cgi?id=158290 Reviewed by Mark Lam. Clear the thrown value at the end of the catch block so that the stack scanner won't find the value during GC. Added a new stress test. * bytecompiler/NodesCodegen.cpp: (JSC::TryNode::emitBytecode): * tests/stress/recursive-try-catch.js: Added. (logError): (tryCallingBadFunction): (recurse): (test): 2016-06-01 Benjamin Poulain [JSC] Some setters for components of Date do not timeClip() their result https://bugs.webkit.org/show_bug.cgi?id=158278 rdar://problem/25131426 Reviewed by Geoffrey Garen. Many of the setters where not doing timeClip() on the computed UTC time since Epoch. See http://www.ecma-international.org/ecma-262/6.0/#sec-date.prototype.setdate and the following sections for the definition. * runtime/DatePrototype.cpp: (JSC::setNewValueFromTimeArgs): (JSC::setNewValueFromDateArgs): 2016-06-01 Keith Miller canOptimizeStringObjectAccess should use ObjectPropertyConditions rather than structure watchpoints https://bugs.webkit.org/show_bug.cgi?id=158291 Reviewed by Benjamin Poulain. The old StringObject primitive access code used structure watchpoints. This meant that if you set a watchpoint on String.prototype prior to tiering up to the DFG then added a new property to String.prototype then we would never use StringObject optimizations. This made property caching in the LLInt bad because it meant we would watchpoint String.prototype very early in the program, which hurt date-format-xpab.js since that benchmark relies on the StringObject optimizations. This patch also extends ObjectPropertyConditionSet to be able to handle a slotBase equivalence condition. Since that makes the code for generating the DFG watchpoints significantly cleaner. * bytecode/ObjectPropertyCondition.cpp: (JSC::ObjectPropertyCondition::structureEnsuresValidityAssumingImpurePropertyWatchpoint): * bytecode/ObjectPropertyConditionSet.cpp: (JSC::ObjectPropertyConditionSet::hasOneSlotBaseCondition): (JSC::ObjectPropertyConditionSet::slotBaseCondition): (JSC::generateConditionsForPrototypeEquivalenceConcurrently): * bytecode/ObjectPropertyConditionSet.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::isStringPrototypeMethodSane): (JSC::DFG::Graph::canOptimizeStringObjectAccess): * dfg/DFGGraph.h: 2016-06-01 Geoffrey Garen Unreviewed, rolling in r201436. https://bugs.webkit.org/show_bug.cgi?id=158143 r201562 should haved fixed the Dromaeo DOM core regression. Restored changeset: "REGRESSION: JSBench spends a lot of time transitioning to/from dictionary" https://bugs.webkit.org/show_bug.cgi?id=158045 http://trac.webkit.org/changeset/201436 2016-06-01 Commit Queue Unreviewed, rolling out r201488. https://bugs.webkit.org/show_bug.cgi?id=158268 Caused 23% regression on JetStream's crypto-md5 (Requested by rniwa on #webkit). Reverted changeset: "[ESNext] Support trailing commas in function param lists" https://bugs.webkit.org/show_bug.cgi?id=158020 http://trac.webkit.org/changeset/201488 2016-05-31 Geoffrey Garen Dictionary property access should be fast https://bugs.webkit.org/show_bug.cgi?id=158250 Reviewed by Keith Miller. We have some remnant code that unnecessarily takes a slow path for dictionaries. This caused the Dromaeo regression in r201436. Let's fix that. * jit/Repatch.cpp: (JSC::tryCacheGetByID): Attempt to flatten a dictionary if necessary, but not too much. This is our idiom in other places. (JSC::tryCachePutByID): See tryCacheGetByID. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setupGetByIdPrototypeCache): See tryCacheGetByID. * runtime/JSObject.cpp: (JSC::JSObject::fillGetterPropertySlot): * runtime/JSObject.h: (JSC::JSObject::fillCustomGetterPropertySlot): The rules for caching a getter are the same as the rules for caching anything else: We're allowed to cache even in dictionaries, as long as they're cacheable dictionaries. Any transition that would change to/from getter/setter or change other attributes requires a structure transition. 2016-05-31 Yusuke Suzuki [JSC] Drop "replace" from JSC_COMMON_PRIVATE_IDENTIFIERS_EACH_WELL_KNOWN_SYMBOL_NOT_IMPLEMENTED_YET https://bugs.webkit.org/show_bug.cgi?id=158223 Reviewed by Darin Adler. This list maintains "not implemented yet" well-known symbols. `Symbol.replace` is already implemented. * runtime/CommonIdentifiers.h: 2016-05-31 Yusuke Suzuki Unreviewed, roll out r201481, r201523: 0.3% regression in Octane code-load https://bugs.webkit.org/show_bug.cgi?id=158249 * API/JSScriptRef.cpp: (parseScript): * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/AsyncFunctionPrototype.js: Removed. (asyncFunctionResume): Deleted. * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createExecutable): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): Deleted. (JSC::computeDefsForBytecodeOffset): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::dumpBytecode): Deleted. * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::isArrowFunction): (JSC::UnlinkedCodeBlock::isOrdinaryArrowFunction): Deleted. (JSC::UnlinkedCodeBlock::isAsyncArrowFunction): Deleted. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): (JSC::UnlinkedFunctionExecutable::fromGlobalCode): (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor): * bytecode/UnlinkedFunctionExecutable.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitNewArrowFunctionExpression): (JSC::BytecodeGenerator::emitNewMethodDefinition): (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): Deleted. (JSC::BytecodeGenerator::emitNewFunction): Deleted. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::makeFunction): * bytecompiler/NodesCodegen.cpp: (JSC::FunctionNode::emitBytecode): Deleted. * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::parse): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): Deleted. * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emitNewFuncCommon): Deleted. (JSC::JIT::emit_op_new_async_func): Deleted. (JSC::JIT::emitNewFuncExprCommon): Deleted. (JSC::JIT::emit_op_new_async_func_exp): Deleted. * jit/JITOperations.cpp: * jit/JITOperations.h: * jsc.cpp: (runInteractive): (printUsageStatement): Deleted. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted. * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * parser/ASTBuilder.h: (JSC::ASTBuilder::createAsyncFunctionBody): Deleted. * parser/Keywords.table: * parser/Parser.cpp: (JSC::Parser::Parser): (JSC::Parser::parseInner): (JSC::Parser::isArrowFunctionParameters): (JSC::Parser::parseStatementListItem): (JSC::Parser::parseStatement): (JSC::Parser::parseFunctionParameters): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseClass): (JSC::Parser::parseImportClauseItem): (JSC::Parser::parseImportDeclaration): (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseProperty): (JSC::Parser::parsePropertyMethod): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::parseMemberExpression): (JSC::Parser::parseArrowFunctionExpression): (JSC::Parser::printUnexpectedTokenText): (JSC::Parser::parseAsyncFunctionSourceElements): Deleted. (JSC::Parser::parseVariableDeclarationList): Deleted. (JSC::Parser::parseDestructuringPattern): Deleted. (JSC::Parser::parseFunctionDeclarationStatement): Deleted. (JSC::Parser::parseFormalParameters): Deleted. (JSC::stringForFunctionMode): Deleted. (JSC::Parser::parseAsyncFunctionDeclaration): Deleted. (JSC::Parser::parseExpressionOrLabelStatement): Deleted. (JSC::Parser::parseAwaitExpression): Deleted. (JSC::Parser::parseAsyncFunctionExpression): Deleted. (JSC::Parser::parseUnaryExpression): Deleted. * parser/Parser.h: (JSC::Scope::Scope): (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass): (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope): (JSC::Parser::pushScope): (JSC::Parser::popScopeInternal): (JSC::Parser::matchSpecIdentifier): (JSC::parse): (JSC::Scope::setSourceParseMode): Deleted. (JSC::Scope::isAsyncFunction): Deleted. (JSC::Scope::isAsyncFunctionBoundary): Deleted. (JSC::Scope::isModule): Deleted. (JSC::Scope::setIsFunction): Deleted. (JSC::Scope::setIsAsyncArrowFunction): Deleted. (JSC::Scope::setIsAsyncFunction): Deleted. (JSC::Scope::setIsAsyncFunctionBody): Deleted. (JSC::Scope::setIsAsyncArrowFunctionBody): Deleted. (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError): Deleted. (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction): Deleted. (JSC::Parser::forceClassifyExpressionError): Deleted. (JSC::Parser::declarationTypeToVariableKind): Deleted. (JSC::Parser::upperScope): Deleted. (JSC::Parser::isDisallowedIdentifierAwait): Deleted. (JSC::Parser::disallowedIdentifierAwaitReason): Deleted. * parser/ParserModes.h: (JSC::isFunctionParseMode): (JSC::isModuleParseMode): (JSC::isProgramParseMode): (JSC::SourceParseModeSet::SourceParseModeSet): Deleted. (JSC::SourceParseModeSet::contains): Deleted. (JSC::SourceParseModeSet::mergeSourceParseModes): Deleted. (JSC::isAsyncFunctionParseMode): Deleted. (JSC::isAsyncArrowFunctionParseMode): Deleted. (JSC::isAsyncFunctionWrapperParseMode): Deleted. (JSC::isAsyncFunctionBodyParseMode): Deleted. (JSC::constructAbilityForParseMode): Deleted. * parser/ParserTokens.h: * parser/SourceCodeKey.h: (JSC::SourceCodeKey::SourceCodeKey): (JSC::SourceCodeKey::operator==): (JSC::SourceCodeKey::runtimeFlags): Deleted. * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createAsyncFunctionBody): Deleted. * runtime/AsyncFunctionConstructor.cpp: Removed. (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor): Deleted. (JSC::AsyncFunctionConstructor::finishCreation): Deleted. (JSC::callAsyncFunctionConstructor): Deleted. (JSC::constructAsyncFunctionConstructor): Deleted. (JSC::AsyncFunctionConstructor::getCallData): Deleted. (JSC::AsyncFunctionConstructor::getConstructData): Deleted. * runtime/AsyncFunctionConstructor.h: Removed. (JSC::AsyncFunctionConstructor::create): Deleted. (JSC::AsyncFunctionConstructor::createStructure): Deleted. * runtime/AsyncFunctionPrototype.cpp: Removed. (JSC::AsyncFunctionPrototype::AsyncFunctionPrototype): Deleted. (JSC::AsyncFunctionPrototype::finishCreation): Deleted. * runtime/AsyncFunctionPrototype.h: Removed. (JSC::AsyncFunctionPrototype::create): Deleted. (JSC::AsyncFunctionPrototype::createStructure): Deleted. * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): (JSC::CodeCache::getProgramCodeBlock): (JSC::CodeCache::getEvalCodeBlock): (JSC::CodeCache::getModuleProgramCodeBlock): (JSC::CodeCache::getFunctionExecutableFromGlobalCode): * runtime/CodeCache.h: * runtime/CommonIdentifiers.h: * runtime/Completion.cpp: (JSC::checkSyntax): (JSC::checkModuleSyntax): * runtime/Completion.h: * runtime/Executable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): (JSC::ProgramExecutable::checkSyntax): * runtime/Executable.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/FunctionConstructor.h: * runtime/JSAsyncFunction.cpp: Removed. (JSC::JSAsyncFunction::JSAsyncFunction): Deleted. (JSC::JSAsyncFunction::createImpl): Deleted. (JSC::JSAsyncFunction::create): Deleted. (JSC::JSAsyncFunction::createWithInvalidatedReallocationWatchpoint): Deleted. * runtime/JSAsyncFunction.h: Removed. (JSC::JSAsyncFunction::allocationSize): Deleted. (JSC::JSAsyncFunction::createStructure): Deleted. * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnPropertySlot): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::createProgramCodeBlock): (JSC::JSGlobalObject::createEvalCodeBlock): (JSC::JSGlobalObject::createModuleProgramCodeBlock): (JSC::JSGlobalObject::init): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::asyncFunctionPrototype): Deleted. (JSC::JSGlobalObject::asyncFunctionStructure): Deleted. * runtime/ModuleLoaderObject.cpp: (JSC::moduleLoaderObjectParseModule): * runtime/RuntimeFlags.h: (JSC::RuntimeFlags::operator==): Deleted. (JSC::RuntimeFlags::operator!=): Deleted. * tests/stress/async-await-basic.js: Removed. (shouldBe): Deleted. (shouldBeAsync): Deleted. (shouldThrow): Deleted. (shouldThrowAsync): Deleted. (shouldThrowSyntaxError): Deleted. (let.AsyncFunction.async): Deleted. (async.asyncFunctionForProto): Deleted. (Object.getPrototypeOf.async): Deleted. (Object.getPrototypeOf.async.method): Deleted. (async): Deleted. (async.method): Deleted. (async.asyncNonConstructorDecl): Deleted. (shouldThrow.new.async): Deleted. (shouldThrow.new.async.nonConstructor): Deleted. (async.asyncDecl): Deleted. (async.f): Deleted. (MyError): Deleted. (async.asyncDeclThrower): Deleted. (shouldThrowAsync.async): Deleted. (resolveLater): Deleted. (rejectLater): Deleted. (async.resumeAfterNormal): Deleted. (O.async.resumeAfterNormal): Deleted. (resumeAfterNormalArrow.async): Deleted. (async.resumeAfterThrow): Deleted. (O.async.resumeAfterThrow): Deleted. (resumeAfterThrowArrow.async): Deleted. (catch): Deleted. * tests/stress/async-await-module-reserved-word.js: Removed. (shouldThrow): Deleted. (SyntaxError.Canstring_appeared_hereawait.checkModuleSyntaxError.String.raw.await): Deleted. (checkModuleSyntaxError.String.raw.await): Deleted. (checkModuleSyntaxError.String.raw.async.await): Deleted. (SyntaxError.Cannot.declare.named): Deleted. * tests/stress/async-await-mozilla.js: Removed. (shouldBe): Deleted. (shouldBeAsync): Deleted. (shouldThrow): Deleted. (shouldThrowAsync): Deleted. (assert): Deleted. (shouldThrowSyntaxError): Deleted. (mozSemantics.async.empty): Deleted. (mozSemantics.async.simpleReturn): Deleted. (mozSemantics.async.simpleAwait): Deleted. (mozSemantics.async.simpleAwaitAsync): Deleted. (mozSemantics.async.returnOtherAsync): Deleted. (mozSemantics.async.simpleThrower): Deleted. (mozSemantics.async.delegatedThrower): Deleted. (mozSemantics.async.tryCatch): Deleted. (mozSemantics.async.tryCatchThrow): Deleted. (mozSemantics.async.wellFinally): Deleted. (mozSemantics.async.finallyMayFail): Deleted. (mozSemantics.async.embedded.async.inner): Deleted. (mozSemantics.async.embedded): Deleted. (mozSemantics.async.fib): Deleted. (mozSemantics.async.isOdd.async.isEven): Deleted. (mozSemantics.async.isOdd): Deleted. (mozSemantics.hardcoreFib.async.fib2): Deleted. (mozSemantics.namedAsyncExpr.async.simple): Deleted. (mozSemantics.async.executionOrder.async.first): Deleted. (mozSemantics.async.executionOrder.async.second): Deleted. (mozSemantics.async.executionOrder.async.third): Deleted. (mozSemantics.async.executionOrder): Deleted. (mozSemantics.async.miscellaneous): Deleted. (mozSemantics.thrower): Deleted. (mozSemantics.async.defaultArgs): Deleted. (mozSemantics.shouldThrow): Deleted. (mozSemantics): Deleted. (mozMethods.X): Deleted. (mozMethods.X.prototype.async.getValue): Deleted. (mozMethods.X.prototype.setValue): Deleted. (mozMethods.X.prototype.async.increment): Deleted. (mozMethods.X.prototype.async.getBaseClassName): Deleted. (mozMethods.X.async.getStaticValue): Deleted. (mozMethods.Y.prototype.async.getBaseClassName): Deleted. (mozMethods.Y): Deleted. (mozFunctionNameInferrence.async.test): Deleted. (mozSyntaxErrors): Deleted. * tests/stress/async-await-reserved-word.js: Removed. (assert): Deleted. (shouldThrowSyntaxError): Deleted. (AsyncFunction.async): Deleted. * tests/stress/async_arrow_functions_lexical_arguments_binding.js: Removed. (shouldBe): Deleted. (shouldBeAsync): Deleted. (shouldThrowAsync): Deleted. (noArgumentsArrow2.async): Deleted. * tests/stress/async_arrow_functions_lexical_new.target_binding.js: Removed. (shouldBe): Deleted. (shouldBeAsync): Deleted. (shouldThrowAsync): Deleted. (C1): Deleted. (C2): Deleted. (shouldThrowAsync.async): Deleted. * tests/stress/async_arrow_functions_lexical_super_binding.js: Removed. (shouldBe): Deleted. (shouldBeAsync): Deleted. (BaseClass.prototype.baseClassValue): Deleted. (BaseClass.prototype.get property): Deleted. (BaseClass): Deleted. (ChildClass.prototype.asyncSuperProp): Deleted. (ChildClass.prototype.asyncSuperProp2): Deleted. (ChildClass): Deleted. (ChildClass2): Deleted. * tests/stress/async_arrow_functions_lexical_this_binding.js: Removed. (shouldBe): Deleted. (shouldBeAsync): Deleted. (d.y): Deleted. 2016-05-31 Commit Queue Unreviewed, rolling out r201363 and r201456. https://bugs.webkit.org/show_bug.cgi?id=158240 "40% regression on date-format-xparb" (Requested by keith_miller on #webkit). Reverted changesets: "LLInt should be able to cache prototype loads for values in GetById" https://bugs.webkit.org/show_bug.cgi?id=158032 http://trac.webkit.org/changeset/201363 "get_by_id should support caching unset properties in the LLInt" https://bugs.webkit.org/show_bug.cgi?id=158136 http://trac.webkit.org/changeset/201456 2016-05-31 Commit Queue Unreviewed, rolling out r201359. https://bugs.webkit.org/show_bug.cgi?id=158238 "It was not a speedup on anything" (Requested by saamyjoon on #webkit). Reverted changeset: "We can cache lookups to JSScope::abstractResolve inside CodeBlock::finishCreation" https://bugs.webkit.org/show_bug.cgi?id=158036 http://trac.webkit.org/changeset/201359 2016-05-31 Yusuke Suzuki [JSC] Recover parser performance regression by async support https://bugs.webkit.org/show_bug.cgi?id=158228 Reviewed by Saam Barati. This patch recovers parser performance regression caused in r201481. Compared to the version that reverts r201481, still ~1% regression remains. But compared to ToT, this patch significantly improves the code-load performance. In Linux x64 JSCOnly port, with GCC 5.3.1. reverted v.s. patched. reverted patched closure 0.61805+-0.00376 ? 0.62280+-0.00525 ? jquery 8.03778+-0.02114 8.03453+-0.04646 2.22883+-0.00836 ? 2.23688+-0.00995 ? might be 1.0036x slower ToT v.s. patched. baseline patched closure 0.65490+-0.00351 ^ 0.62473+-0.00363 ^ definitely 1.0483x faster jquery 8.25373+-0.06256 ^ 8.04701+-0.03455 ^ definitely 1.0257x faster 2.32488+-0.00921 ^ 2.24210+-0.00592 ^ definitely 1.0369x faster * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): * bytecode/UnlinkedFunctionExecutable.h: Extend SourceParseMode. * parser/Parser.cpp: (JSC::Parser::parseInner): (JSC::Parser::isArrowFunctionParameters): Do not call `matchSpecIdentifier()` as much as we can. This greatly improves the performance. (JSC::Parser::parseStatementListItem): (JSC::Parser::parseStatement): (JSC::Parser::parseFunctionParameters): (JSC::Parser::parseFunctionInfo): Do not touch `currentScope()->isGenerator()` even if it is unnecessary in parseFunctionInfo. And accidental `syntaxChecker => context` changes are fixed. (JSC::Parser::parseClass): (JSC::Parser::parseExpressionOrLabelStatement): (JSC::Parser::parseImportClauseItem): (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseAssignmentExpression): Do not use matchSpecIdentifier() in the hot paths. (JSC::Parser::parseProperty): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::parseMemberExpression): (JSC::Parser::parseUnaryExpression): (JSC::Parser::printUnexpectedTokenText): Deleted. * parser/Parser.h: (JSC::isIdentifierOrKeyword): AWAIT shoud be one of the keywords. This AWAIT check is unnecessary. (JSC::Parser::upperScope): (JSC::Parser::matchSpecIdentifier): Touching currentScope() and its member causes significant performance degradation. We carefully remove the above access in the hot paths. (JSC::Parser::isDisallowedIdentifierAwait): * parser/ParserModes.h: (JSC::SourceParseModeSet::SourceParseModeSet): (JSC::SourceParseModeSet::contains): (JSC::SourceParseModeSet::mergeSourceParseModes): (JSC::isFunctionParseMode): (JSC::isAsyncFunctionParseMode): (JSC::isAsyncArrowFunctionParseMode): (JSC::isAsyncFunctionWrapperParseMode): (JSC::isAsyncFunctionBodyParseMode): (JSC::isModuleParseMode): (JSC::isProgramParseMode): (JSC::constructAbilityForParseMode): The parser frequently checks SourceParseMode. And variety of SourceParseMode becomes many. So using switch onto SourceParseMode degrades the performance. Instead, we use bit tests to guard against many SourceParseModes. We expect that this will be efficiently compiled into test & jmp. * parser/ParserTokens.h: Change AWAIT to one of the keywords, as the same to YIELD / LET. 2016-05-31 Saam Barati Web Inspector: capturing with Allocations timeline causes GC to take 100x longer and cause frame drops https://bugs.webkit.org/show_bug.cgi?id=158054 Reviewed by Joseph Pecoraro. HeapSnapshot::sweepCell was taking a long time on http://bl.ocks.org/syntagmatic/6c149c08fc9cde682635 because it has to do a binary search to find if an item is or is not in the list. 90% of the binary searches would not find anything. This resulted in a lot of wasted time. This patch adds a TinyBloomFilter member variable to HeapSnapshot. We use this filter to try to bypass doing a binary search when the filter tells us that a particular JSCell is definitely not in our list. This is a 2x speedup on the steady state GC of the above website. * heap/HeapSnapshot.cpp: (JSC::HeapSnapshot::appendNode): (JSC::HeapSnapshot::sweepCell): (JSC::HeapSnapshot::shrinkToFit): (JSC::HeapSnapshot::nodeForCell): * heap/HeapSnapshot.h: 2016-05-29 Saam barati Stack overflow crashes with deep or cyclic proxy prototype chains https://bugs.webkit.org/show_bug.cgi?id=157087 Reviewed by Filip Pizlo and Mark Lam. Because a Proxy can call back into the JS runtime in arbitrary ways, we may have effectively cyclic prototype chains and property lookups by using a Proxy. We may also have arbitrarily long Proxy chains where we call into a C frame for each link in the Proxy chain. This means that every Proxy hook must be aware that it can stack overflow. Before, only certain hooks were aware of this fact. That was a bug, all hooks must assume they can stack overflow. Also, because we may have effectively cyclic prototype chains, we compile ProxyObject.cpp with -fno-optimize-sibling-calls. This prevents tail call optimization from happening on any of the calls from ProxyObject.cpp. We do this because we rely on the machine stack growing for throwing a stack overflow error. It's better for developers to be able to see a stack overflow error than to have their program infinite loop because the compiler performed TCO. This patch also fixes a couple call sites of various methods where we didn't check for an exception. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): * runtime/InternalFunction.cpp: (JSC::InternalFunction::createSubclassStructure): * runtime/JSArray.h: (JSC::getLength): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncToString): * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::getOwnPropertySlotCommon): (JSC::ProxyObject::performPut): (JSC::performProxyCall): (JSC::performProxyConstruct): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::performPreventExtensions): (JSC::ProxyObject::performIsExtensible): (JSC::ProxyObject::performDefineOwnProperty): (JSC::ProxyObject::performGetOwnPropertyNames): (JSC::ProxyObject::getOwnPropertyNames): (JSC::ProxyObject::getPropertyNames): (JSC::ProxyObject::getOwnNonIndexPropertyNames): (JSC::ProxyObject::performSetPrototype): (JSC::ProxyObject::performGetPrototype): * runtime/ProxyObject.h: (JSC::ProxyObject::create): * tests/stress/proxy-stack-overflow-exceptions.js: Added. (shouldThrowStackOverflow): (const.emptyFunction): (makeLongProxyChain): (shouldThrowStackOverflow.longProxyChain): (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain1): (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain2): (shouldThrowStackOverflow.effecivelyCyclicProxyProtoChain3): (shouldThrowStackOverflow.longProxyChainBind): (shouldThrowStackOverflow.longProxyChainPropertyAccess): (shouldThrowStackOverflow.longProxyChainReflectConstruct): (shouldThrowStackOverflow.longProxyChainReflectSet): (shouldThrowStackOverflow.longProxyChainReflectOwnKeys): (shouldThrowStackOverflow.longProxyChainGetPrototypeOf): (shouldThrowStackOverflow.longProxyChainSetPrototypeOf): (shouldThrowStackOverflow.longProxyChainGetOwnPropertyDescriptor): (shouldThrowStackOverflow.longProxyChainDefineProperty): (shouldThrowStackOverflow.longProxyChainIsExtensible): (shouldThrowStackOverflow.longProxyChainPreventExtensions): (shouldThrowStackOverflow.longProxyChainDeleteProperty): (shouldThrowStackOverflow.longProxyChainWithScope): (shouldThrowStackOverflow.longProxyChainWithScope2): (shouldThrowStackOverflow.longProxyChainWithScope3): (shouldThrowStackOverflow.longProxyChainArrayPrototypePush): (shouldThrowStackOverflow.longProxyChainWithScope4): (shouldThrowStackOverflow.longProxyChainCall): (shouldThrowStackOverflow.longProxyChainConstruct): (shouldThrowStackOverflow.longProxyChainHas): 2016-05-28 Andreas Kling JSGlobalLexicalEnvironment leaks SegmentedVector due to lack of destructor. Reviewed by Saam Barati. Give JSGlobalLexicalEnvironment a destroy() and set up a finalizer for it like we do with JSGlobalObject. (This is needed because they don't inherit from JSDestructibleObjects and thus can't use JSCell::needsDestruction to ask for allocation in destructor space.) This stops us from leaking all the SegmentedVector backing stores. * runtime/JSGlobalLexicalEnvironment.cpp: (JSC::JSGlobalLexicalEnvironment::destroy): * runtime/JSGlobalLexicalEnvironment.h: (JSC::JSGlobalLexicalEnvironment::create): 2016-05-28 Skachkov Oleksandr [ESNext] Trailing commas in function parameters. https://bugs.webkit.org/show_bug.cgi?id=158020 Reviewed by Keith Miller. ESNext allow to add trailing commas in function parameters and function arguments. Link to spec - https://jeffmo.github.io/es-trailing-function-commas Example of using - (function (a, b,) { return a + b; })(1,2,); * parser/Parser.cpp: (JSC::Parser::parseFormalParameters): (JSC::Parser::parseArguments): * tests/stress/trailing-comma-in-function-paramters.js: Added. 2016-05-28 Yusuke Suzuki [JSC] op_new_arrow_func_exp is no longer necessary https://bugs.webkit.org/show_bug.cgi?id=158180 Reviewed by Saam Barati. This patch removes op_new_arrow_func_exp bytecode since what op_new_arrow_func_exp is doing is completely the same to op_new_func_exp. * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): Deleted. (JSC::computeDefsForBytecodeOffset): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): Deleted. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): Deleted. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): Deleted. * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emitNewFuncExprCommon): (JSC::JIT::emit_op_new_arrow_func_exp): Deleted. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted. * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: 2016-05-27 Caitlin Potter [JSC] implement async functions proposal https://bugs.webkit.org/show_bug.cgi?id=156147 Reviewed by Yusuke Suzuki. Adds support for `async` functions, proposed in https://tc39.github.io/ecmascript-asyncawait/. On the front-end side, "await" becomes a contextual keyword when used within an async function, which triggers parsing an AwaitExpression. "await" becomes an illegal identifier name within these contexts. The bytecode generated from an "await" expression is identical to that generated in a "yield" expression in a Generator, as AsyncFunction reuses generator's state machine mechanism. There are numerous syntactic forms for language features, including a variation on ArrowFunctions, requiring the keyword `async` to precede ArrowFormalParameters, and similarly, MethodDefinitions, which are ordinary MethodDefinitions preceded by the keyword `async`. An async function desugars to the following: ``` async function asyncFn() { } becomes: function asyncFn() { let generator = { @generatorNext: function(@generator, @generatorState, @generatorValue, @generatorResumeMode) { // generator state machine stuff here }, @generatorState: 0, @generatorThis: this, @generatorFrame: null }; return @asyncFunctionResume(generator, undefined, GeneratorResumeMode::NormalMode); } ``` `@asyncFunctionResume()` is similar to `@generatorResume`, with the exception that it will wrap the result of invoking `@generatorNext()` in a Promise, and will avoid allocating an iterator result object. If the generator has yielded (an AwaitExpression has occurred), resumption will occur automatically once the await-expression operand is finished, via Promise chaining. * API/JSScriptRef.cpp: (parseScript): * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/AsyncFunctionPrototype.js: Added. (asyncFunctionResume): * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createExecutable): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::finishCreation): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::isArrowFunction): (JSC::UnlinkedCodeBlock::isOrdinaryArrowFunction): (JSC::UnlinkedCodeBlock::isAsyncArrowFunction): * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): (JSC::UnlinkedFunctionExecutable::fromGlobalCode): (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor): * bytecode/UnlinkedFunctionExecutable.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): (JSC::BytecodeGenerator::emitNewArrowFunctionExpression): (JSC::BytecodeGenerator::emitNewMethodDefinition): (JSC::BytecodeGenerator::emitNewFunction): (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::makeFunction): * bytecompiler/NodesCodegen.cpp: (JSC::FunctionNode::emitBytecode): * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::parse): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emit_op_new_async_func): (JSC::JIT::emitNewFuncExprCommon): (JSC::JIT::emit_op_new_async_func_exp): * jit/JITOperations.cpp: * jit/JITOperations.h: * jsc.cpp: (runInteractive): (printUsageStatement): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * parser/ASTBuilder.h: (JSC::ASTBuilder::createAsyncFunctionBody): * parser/Keywords.table: * parser/Parser.cpp: (JSC::Parser::Parser): (JSC::Parser::parseInner): (JSC::Parser::isArrowFunctionParameters): (JSC::Parser::parseAsyncFunctionSourceElements): (JSC::Parser::parseStatementListItem): (JSC::Parser::parseVariableDeclarationList): (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseStatement): (JSC::Parser::parseFunctionDeclarationStatement): (JSC::Parser::parseFormalParameters): (JSC::stringForFunctionMode): (JSC::Parser::parseFunctionParameters): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseAsyncFunctionDeclaration): (JSC::Parser::parseClass): (JSC::Parser::parseExpressionOrLabelStatement): (JSC::Parser::parseImportClauseItem): (JSC::Parser::parseImportDeclaration): (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseAwaitExpression): (JSC::Parser::parseProperty): (JSC::Parser::parsePropertyMethod): (JSC::Parser::parseAsyncFunctionExpression): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::parseMemberExpression): (JSC::Parser::parseArrowFunctionExpression): (JSC::Parser::parseUnaryExpression): (JSC::Parser::printUnexpectedTokenText): * parser/Parser.h: (JSC::isIdentifierOrKeyword): (JSC::Scope::Scope): (JSC::Scope::setSourceParseMode): (JSC::Scope::isAsyncFunction): (JSC::Scope::isAsyncFunctionBoundary): (JSC::Scope::isModule): (JSC::Scope::setIsFunction): (JSC::Scope::setIsAsyncArrowFunction): (JSC::Scope::setIsAsyncFunction): (JSC::Scope::setIsAsyncFunctionBody): (JSC::Scope::setIsAsyncArrowFunctionBody): (JSC::Parser::ExpressionErrorClassifier::forceClassifyExpressionError): (JSC::Parser::ExpressionErrorClassifier::propagateExpressionErrorClass): (JSC::Parser::ExpressionErrorClassifier::indicatesPossibleAsyncArrowFunction): (JSC::Parser::forceClassifyExpressionError): (JSC::Parser::declarationTypeToVariableKind): (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope): (JSC::Parser::pushScope): (JSC::Parser::popScopeInternal): (JSC::Parser::matchSpecIdentifier): (JSC::Parser::isDisallowedIdentifierAwait): (JSC::Parser::disallowedIdentifierAwaitReason): (JSC::parse): * parser/ParserModes.h: (JSC::isFunctionParseMode): (JSC::isAsyncFunctionParseMode): (JSC::isAsyncArrowFunctionParseMode): (JSC::isAsyncFunctionWrapperParseMode): (JSC::isAsyncFunctionBodyParseMode): (JSC::isModuleParseMode): (JSC::isProgramParseMode): (JSC::constructAbilityForParseMode): * parser/ParserTokens.h: * parser/SourceCodeKey.h: (JSC::SourceCodeKey::SourceCodeKey): (JSC::SourceCodeKey::runtimeFlags): (JSC::SourceCodeKey::operator==): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createAsyncFunctionBody): * runtime/AsyncFunctionConstructor.cpp: Added. (JSC::AsyncFunctionConstructor::AsyncFunctionConstructor): (JSC::AsyncFunctionConstructor::finishCreation): (JSC::callAsyncFunctionConstructor): (JSC::constructAsyncFunctionConstructor): (JSC::AsyncFunctionConstructor::getCallData): (JSC::AsyncFunctionConstructor::getConstructData): * runtime/AsyncFunctionConstructor.h: Added. (JSC::AsyncFunctionConstructor::create): (JSC::AsyncFunctionConstructor::createStructure): * runtime/AsyncFunctionPrototype.cpp: Added. (JSC::AsyncFunctionPrototype::AsyncFunctionPrototype): (JSC::AsyncFunctionPrototype::finishCreation): * runtime/AsyncFunctionPrototype.h: Added. (JSC::AsyncFunctionPrototype::create): (JSC::AsyncFunctionPrototype::createStructure): * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): (JSC::CodeCache::getProgramCodeBlock): (JSC::CodeCache::getEvalCodeBlock): (JSC::CodeCache::getModuleProgramCodeBlock): (JSC::CodeCache::getFunctionExecutableFromGlobalCode): * runtime/CodeCache.h: * runtime/CommonIdentifiers.h: * runtime/Completion.cpp: (JSC::checkSyntax): (JSC::checkModuleSyntax): * runtime/Completion.h: * runtime/Executable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): (JSC::ProgramExecutable::checkSyntax): * runtime/Executable.h: * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/FunctionConstructor.h: * runtime/JSAsyncFunction.cpp: Added. (JSC::JSAsyncFunction::JSAsyncFunction): (JSC::JSAsyncFunction::createImpl): (JSC::JSAsyncFunction::create): (JSC::JSAsyncFunction::createWithInvalidatedReallocationWatchpoint): * runtime/JSAsyncFunction.h: Added. (JSC::JSAsyncFunction::allocationSize): (JSC::JSAsyncFunction::createStructure): * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnPropertySlot): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::createProgramCodeBlock): (JSC::JSGlobalObject::createEvalCodeBlock): (JSC::JSGlobalObject::createModuleProgramCodeBlock): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::asyncFunctionPrototype): (JSC::JSGlobalObject::asyncFunctionStructure): * runtime/ModuleLoaderObject.cpp: (JSC::moduleLoaderObjectParseModule): * runtime/RuntimeFlags.h: (JSC::RuntimeFlags::operator==): (JSC::RuntimeFlags::operator!=): * tests/stress/async-await-basic.js: Added. (shouldBe): (shouldBeAsync): (shouldThrow): (shouldThrowAsync): (let.AsyncFunction.async): (async.asyncFunctionForProto): (Object.getPrototypeOf.async): (Object.getPrototypeOf.async.method): (async): (async.method): (async.asyncNonConstructorDecl): (shouldThrow.new.async): (shouldThrow.new.async.nonConstructor): (async.asyncDecl): (async.f): (MyError): (async.asyncDeclThrower): (shouldThrowAsync.async): (resolveLater): (rejectLater): (async.resumeAfterNormal): (O.async.resumeAfterNormal): (resumeAfterNormalArrow.async): (async.resumeAfterThrow): (O.async.resumeAfterThrow): (resumeAfterThrowArrow.async): (catch): * tests/stress/async-await-module-reserved-word.js: Added. (shouldThrow): (SyntaxError.Canstring_appeared_hereawait.checkModuleSyntaxError.String.raw.await): (checkModuleSyntaxError.String.raw.await): (checkModuleSyntaxError.String.raw.async.await): (SyntaxError.Cannot.declare.named): * tests/stress/async-await-mozilla.js: Added. (shouldBe): (shouldBeAsync): (shouldThrow): (shouldThrowAsync): (assert): (shouldThrowSyntaxError): (mozSemantics.async.empty): (mozSemantics.async.simpleReturn): (mozSemantics.async.simpleAwait): (mozSemantics.async.simpleAwaitAsync): (mozSemantics.async.returnOtherAsync): (mozSemantics.async.simpleThrower): (mozSemantics.async.delegatedThrower): (mozSemantics.async.tryCatch): (mozSemantics.async.tryCatchThrow): (mozSemantics.async.wellFinally): (mozSemantics.async.finallyMayFail): (mozSemantics.async.embedded.async.inner): (mozSemantics.async.embedded): (mozSemantics.async.fib): (mozSemantics.async.isOdd.async.isEven): (mozSemantics.async.isOdd): (mozSemantics.hardcoreFib.async.fib2): (mozSemantics.namedAsyncExpr.async.simple): (mozSemantics.async.executionOrder.async.first): (mozSemantics.async.executionOrder.async.second): (mozSemantics.async.executionOrder.async.third): (mozSemantics.async.executionOrder): (mozSemantics.async.miscellaneous): (mozSemantics.thrower): (mozSemantics.async.defaultArgs): (mozSemantics.shouldThrow): (mozSemantics): (mozMethods.X): (mozMethods.X.prototype.async.getValue): (mozMethods.X.prototype.setValue): (mozMethods.X.prototype.async.increment): (mozMethods.X.prototype.async.getBaseClassName): (mozMethods.X.async.getStaticValue): (mozMethods.Y.prototype.async.getBaseClassName): (mozMethods.Y): (mozFunctionNameInferrence.async.test): (mozSyntaxErrors): * tests/stress/async-await-reserved-word.js: Added. (assert): (shouldThrowSyntaxError): (AsyncFunction.async): * tests/stress/async_arrow_functions_lexical_arguments_binding.js: Added. (shouldBe): (shouldBeAsync): (shouldThrowAsync): (noArgumentsArrow2.async): * tests/stress/async_arrow_functions_lexical_new.target_binding.js: Added. (shouldBe): (shouldBeAsync): (shouldThrowAsync): (C1): (C2): (shouldThrowAsync.async): * tests/stress/async_arrow_functions_lexical_super_binding.js: Added. (shouldBe): (shouldBeAsync): (BaseClass.prototype.baseClassValue): (BaseClass): (ChildClass.prototype.asyncSuperProp): (ChildClass.prototype.asyncSuperProp2): (ChildClass): * tests/stress/async_arrow_functions_lexical_this_binding.js: Added. (shouldBe): (shouldBeAsync): (d.y): 2016-05-27 Saam barati DebuggerCallFrame crashes when updated with the globalExec because neither ShadowChicken's algorithm nor StackVisitor's algorithm reasons about the globalExec https://bugs.webkit.org/show_bug.cgi?id=158104 Reviewed by Filip Pizlo. I think globalExec is a special enough case that it should be handled at the layers above ShadowChicken and StackVisitor. Those APIs should deal with real stack frames on the machine stack, not a heap constructed frame. This patch makes DebuggerCallFrame::create aware that it may be created with the globalObject->globalExec() by having it construct a single DebuggerCallFrame that wraps the globalExec. This fixes a crasher because we will construct a DebuggerCallFrame with the globalExec when the Inspector is set to pause on all uncaught exceptions and the JS program has a syntax error. Because the program hasn't begun execution, there is no machine JS stack frame yet. So DebuggerCallFrame is created with globalExec, which will cause it to hit an assertion that dictates that the stack have size greater than zero. * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::create): 2016-05-27 Filip Pizlo DFG::LazyJSValue::tryGetStringImpl() crashes for empty values https://bugs.webkit.org/show_bug.cgi?id=158170 Reviewed by Michael Saboff. The problem here is that jsDynamicCast<>() is evil! It avoids checking for the empty value, presumably because this makes it soooper fast. In DFG IR, empty values can appear anywhere because of TDZ. This patch doesn't change jsDynamicCast<>(), but it hardens our wrappers for it in the DFG and it has the affected code use one of those wrappers. * dfg/DFGFrozenValue.h: (JSC::DFG::FrozenValue::dynamicCast): Harden this. (JSC::DFG::FrozenValue::cast): * dfg/DFGLazyJSValue.cpp: (JSC::DFG::LazyJSValue::tryGetStringImpl): Use the hardened wrapper. * tests/stress/strcat-emtpy.js: Added. This used to crash every time. (foo): (i.catch): 2016-05-27 Filip Pizlo regExpProtoFuncSplitFast should OOM before it swaps https://bugs.webkit.org/show_bug.cgi?id=158157 Reviewed by Mark Lam. This is a huge speed-up on some jsfunfuzz test cases because it makes us realize much sooner that running a regexp split will result in swapping. It uses the same basic approach as http://trac.webkit.org/changeset/201451: if the result array crosses a certain size threshold, we proceed with a dry run to see how big the array will get before allocating anything else. This way, bogus uses of split that would have OOMed only after killing the user's machine will now OOM before killing the user's machine. This is an enormous speed-up on some jsfunfuzz tests: they go from running for a long time to running instantly. * runtime/RegExpPrototype.cpp: (JSC::advanceStringIndex): (JSC::genericSplit): (JSC::regExpProtoFuncSplitFast): * runtime/StringObject.h: (JSC::jsStringWithReuse): (JSC::jsSubstring): * tests/stress/big-split-captures.js: Added. * tests/stress/big-split.js: Added. 2016-05-27 Saam barati ShadowChicken/DebuggerCallFrame don't properly handle when the entry stack frame is a tail deleted frame https://bugs.webkit.org/show_bug.cgi?id=158131 Reviewed by Yusuke Suzuki. There were bugs both in DebuggerCallFrame and ShadowChicken when the entry stack frame(s) are tail deleted. DebuggerCallFrame had an assertion saying that the entry frame shouldn't be tail deleted. This is clearly wrong. The following program proves that this assertion was misguided: ``` "use strict"; setTimeout(function foo() { return bar(); }, 0); ``` ShadowChicken had a very subtle bug when creating the shadow stack when the entry frames of the stack were tail deleted. Because it places frames into its shadow stack by walking the machine frame and looking up entries in the log, the machine frame doesn't have any notion of those tail deleted frames at the entry of execution. ShadowChicken would never find those frames because it would look for tail deleted frames *before* consulting the current machine frame. This is wrong because if the entry frames are tail deleted, then there is no machine frame for them because there is no machine frame before them! Therefore, we must search for tail deleted frames *after* consulting a machine frame. This is sound because we will always have at least one machine frame on the stack (when we are using StackVisitor on a valid ExecState). So when we consult the machine frame that is the entry frame on the machine stack, we will search for tail deleted frames that come before it in the shadow stack. This will allow us to find those tail deleted frames that are the entry frames for the shadow stack. * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::create): * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::Packet::dump): (JSC::ShadowChicken::update): (JSC::ShadowChicken::dump): 2016-05-27 Chris Dumez WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables https://bugs.webkit.org/show_bug.cgi?id=158111 Reviewed by Darin Adler. WorkQueue::dispatch() / RunLoop::dispatch() should not copy captured lambda variables. These are often used cross-thread and copying the captured lambda variables can be dangerous (e.g. we do not want to copy a String after calling isolatedCopy() upon capture). * runtime/Watchdog.cpp: (JSC::Watchdog::startTimer): (JSC::Watchdog::Watchdog): Deleted. (JSC::Watchdog::setTimeLimit): Deleted. * runtime/Watchdog.h: 2016-05-27 Konstantin Tokarev Removed unused headers from ExecutableAllocatorFixedVMPool.cpp. https://bugs.webkit.org/show_bug.cgi?id=158159 Reviewed by Darin Adler. * jit/ExecutableAllocatorFixedVMPool.cpp: 2016-05-27 Keith Miller get_by_id should support caching unset properties in the LLInt https://bugs.webkit.org/show_bug.cgi?id=158136 Reviewed by Benjamin Poulain. Recently, we started supporting prototype load caching for get_by_id in the LLInt. This patch extends that to caching unset properties. While it is uncommon in general for a program to see a single structure without a given property, the Array.prototype.concat function needs to lookup the Symbol.isConcatSpreadable property. For any existing code That property will never be set as it did not exist prior to ES6. Similarly to the get_by_id_proto_load bytecode, this patch adds a new bytecode, get_by_id_unset that checks the structureID of the base and assigns undefined to the result. There are no new tests here since we already have many tests that incidentally cover this change. * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::printGetByIdOp): (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::finalizeLLIntInlineCaches): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setupGetByIdPrototypeCache): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2016-05-26 Filip Pizlo Bogus uses of regexp matching should realize that they will OOM before they start swapping https://bugs.webkit.org/show_bug.cgi?id=158142 Reviewed by Michael Saboff. Refactored the RegExpObject::matchGlobal() code so that there is less duplication. Took advantage of this to make the code more resilient in case of absurd situations: if the result array gets large, it proceeds with a dry run to detect how many matches there will be. This allows it to OOM before it starts swapping. This also improves the overall performance of the code by using lightweight substrings and skipping the whole intermediate argument array. This makes some jsfunfuzz tests run a lot faster and use a lot less memory. * builtins/RegExpPrototype.js: * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/MatchResult.cpp: Added. (JSC::MatchResult::dump): * runtime/MatchResult.h: (JSC::MatchResult::empty): (MatchResult::empty): Deleted. * runtime/RegExpObject.cpp: (JSC::RegExpObject::match): (JSC::collectMatches): (JSC::RegExpObject::matchGlobal): * runtime/StringObject.h: (JSC::jsStringWithReuse): (JSC::jsSubstring): * tests/stress/big-match.js: Added. Make sure that this optimization doesn't break big matches. 2016-05-26 Gavin & Ellie Barraclough Static table property lookup should not require getOwnPropertySlot override. https://bugs.webkit.org/show_bug.cgi?id=158059 Reviewed by Darin Adler. Currently JSObject does not handle property lookup of entries in the static table. Each subclass with static properties mut override getOwnPropertySlot, and explicitly call the lookup functions. This has the following drawbacks: - Performance: for any class with static properties, property acces becomes virtual (via method table). - Poor encapsulation: implementation detail of static property access is spread throughout & cross projects, rather than being contained in JSObject. - Code size: this results in a great many additional functions. - Inconsistency: static table presence has to be be taken into account in many other operations, e.g. presence of read-only properties for put. - Memory: in order to avoid the virtual lookup, DOM prototypes eagerly reify all properties. This is likely suboptimal. Instead, JSObject::getPropertySlot / JSObject::getOwnPropertySlot should be able to handle static properties. This is actually a fairly small & simple change. The common pattern is for subclasses of JObject to override getOwnPropertySlot to first defer to JSObject for property storage lookup, and only if this fails consult the static table. They just want the static tables to be consulted after regular property storgae lookup. So just add a fast flag in TypeInfo for JSObject to check, and where it is set, do so. Then it's just a question of switching classes over to start setting this flag, and drop the override. The new mechanism does change static table lookup order from oldest-ancestor first to most-derived first. The new ordering makes more sense (means derived class static tables can now override entries from parents), and shoudn't affect any existing code (since overriding didn't previously work, there likely aren't shadowing properties in more derived types). This patch changes all classes in JavaScriptCore over to using the new mechanism, except JSGlobalObject. I'll move classes in WebCore over as a separate patch (this is also why I've not moved JSGlobalObject in this patch - doing so would move JSDOMWindow, and I'd rather handle that separately). * runtime/JSTypeInfo.h: (JSC::TypeInfo::hasStaticPropertyTable): - Add HasStaticPropertyTable flag. * runtime/Lookup.cpp: (JSC::setUpStaticFunctionSlot): - Change setUpStaticFunctionSlot to take a VM&. * runtime/Lookup.h: (JSC::getStaticPropertySlotFromTable): - Added helper function to perform static lookup alone. (JSC::getStaticPropertySlot): (JSC::getStaticFunctionSlot): - setUpStaticFunctionSlot changed to take a VM&. * runtime/JSObject.cpp: (JSC::JSObject::getOwnStaticPropertySlot): - Added, walks ClassInfo chain looking for static properties. * runtime/JSObject.h: (JSC::JSObject::getOwnNonIndexPropertySlot): - getOwnNonIndexPropertySlot is used internally by getPropertySlot & getOwnPropertySlot. If property is not present in storage array then check the static table. * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::finishCreation): (JSC::constructArrayWithSizeQuirk): (JSC::ArrayConstructor::getOwnPropertySlot): Deleted. * runtime/ArrayConstructor.h: (JSC::ArrayConstructor::create): * runtime/ArrayIteratorPrototype.cpp: (JSC::ArrayIteratorPrototype::finishCreation): (JSC::ArrayIteratorPrototype::getOwnPropertySlot): Deleted. * runtime/ArrayIteratorPrototype.h: (JSC::ArrayIteratorPrototype::create): (JSC::ArrayIteratorPrototype::ArrayIteratorPrototype): * runtime/BooleanPrototype.cpp: (JSC::BooleanPrototype::finishCreation): (JSC::booleanProtoFuncToString): (JSC::BooleanPrototype::getOwnPropertySlot): Deleted. * runtime/BooleanPrototype.h: (JSC::BooleanPrototype::create): * runtime/DateConstructor.cpp: (JSC::DateConstructor::finishCreation): (JSC::millisecondsFromComponents): (JSC::DateConstructor::getOwnPropertySlot): Deleted. * runtime/DateConstructor.h: (JSC::DateConstructor::create): * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): (JSC::dateProtoFuncToString): (JSC::DatePrototype::getOwnPropertySlot): Deleted. * runtime/DatePrototype.h: (JSC::DatePrototype::create): * runtime/ErrorPrototype.cpp: (JSC::ErrorPrototype::finishCreation): (JSC::ErrorPrototype::getOwnPropertySlot): Deleted. * runtime/ErrorPrototype.h: (JSC::ErrorPrototype::create): * runtime/GeneratorPrototype.cpp: (JSC::GeneratorPrototype::finishCreation): (JSC::GeneratorPrototype::getOwnPropertySlot): Deleted. * runtime/GeneratorPrototype.h: (JSC::GeneratorPrototype::create): (JSC::GeneratorPrototype::createStructure): (JSC::GeneratorPrototype::GeneratorPrototype): * runtime/InspectorInstrumentationObject.cpp: (JSC::InspectorInstrumentationObject::finishCreation): (JSC::InspectorInstrumentationObject::isEnabled): (JSC::InspectorInstrumentationObject::getOwnPropertySlot): Deleted. * runtime/InspectorInstrumentationObject.h: (JSC::InspectorInstrumentationObject::create): (JSC::InspectorInstrumentationObject::createStructure): * runtime/IntlCollatorConstructor.cpp: (JSC::IntlCollatorConstructor::getCallData): (JSC::IntlCollatorConstructorFuncSupportedLocalesOf): (JSC::IntlCollatorConstructor::getOwnPropertySlot): Deleted. * runtime/IntlCollatorConstructor.h: * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototype::finishCreation): (JSC::IntlCollatorFuncCompare): (JSC::IntlCollatorPrototype::getOwnPropertySlot): Deleted. * runtime/IntlCollatorPrototype.h: * runtime/IntlDateTimeFormatConstructor.cpp: (JSC::IntlDateTimeFormatConstructor::getCallData): (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): (JSC::IntlDateTimeFormatConstructor::getOwnPropertySlot): Deleted. * runtime/IntlDateTimeFormatConstructor.h: * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototype::finishCreation): (JSC::IntlDateTimeFormatFuncFormatDateTime): (JSC::IntlDateTimeFormatPrototype::getOwnPropertySlot): Deleted. * runtime/IntlDateTimeFormatPrototype.h: * runtime/IntlNumberFormatConstructor.cpp: (JSC::IntlNumberFormatConstructor::getCallData): (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): (JSC::IntlNumberFormatConstructor::getOwnPropertySlot): Deleted. * runtime/IntlNumberFormatConstructor.h: * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::finishCreation): (JSC::IntlNumberFormatFuncFormatNumber): (JSC::IntlNumberFormatPrototype::getOwnPropertySlot): Deleted. * runtime/IntlNumberFormatPrototype.h: * runtime/JSDataViewPrototype.cpp: (JSC::JSDataViewPrototype::createStructure): (JSC::getData): (JSC::JSDataViewPrototype::getOwnPropertySlot): Deleted. * runtime/JSDataViewPrototype.h: * runtime/JSInternalPromiseConstructor.cpp: (JSC::JSInternalPromiseConstructor::getCallData): (JSC::JSInternalPromiseConstructor::getOwnPropertySlot): Deleted. * runtime/JSInternalPromiseConstructor.h: * runtime/JSONObject.cpp: (JSC::Walker::Walker): (JSC::JSONObject::getOwnPropertySlot): Deleted. * runtime/JSONObject.h: (JSC::JSONObject::create): * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::getCallData): (JSC::JSPromiseConstructor::getOwnPropertySlot): Deleted. * runtime/JSPromiseConstructor.h: * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototype::addOwnInternalSlots): (JSC::JSPromisePrototype::getOwnPropertySlot): Deleted. * runtime/JSPromisePrototype.h: * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): (JSC::getMap): (JSC::MapPrototype::getOwnPropertySlot): Deleted. * runtime/MapPrototype.h: (JSC::MapPrototype::create): (JSC::MapPrototype::MapPrototype): * runtime/ModuleLoaderObject.cpp: (JSC::ModuleLoaderObject::finishCreation): (JSC::printableModuleKey): (JSC::ModuleLoaderObject::getOwnPropertySlot): Deleted. * runtime/ModuleLoaderObject.h: * runtime/NumberPrototype.cpp: (JSC::NumberPrototype::finishCreation): (JSC::toThisNumber): (JSC::NumberPrototype::getOwnPropertySlot): Deleted. * runtime/NumberPrototype.h: (JSC::NumberPrototype::create): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::addDefineProperty): (JSC::constructObject): (JSC::ObjectConstructor::getOwnPropertySlot): Deleted. * runtime/ObjectConstructor.h: (JSC::ObjectConstructor::create): (JSC::ObjectConstructor::createStructure): * runtime/ReflectObject.cpp: (JSC::ReflectObject::finishCreation): (JSC::ReflectObject::getOwnPropertySlot): Deleted. * runtime/ReflectObject.h: (JSC::ReflectObject::create): (JSC::ReflectObject::createStructure): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::getRightContext): (JSC::regExpConstructorDollar): (JSC::RegExpConstructor::getOwnPropertySlot): Deleted. * runtime/RegExpConstructor.h: (JSC::RegExpConstructor::create): (JSC::RegExpConstructor::createStructure): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): (JSC::getSet): (JSC::SetPrototype::getOwnPropertySlot): Deleted. * runtime/SetPrototype.h: (JSC::SetPrototype::create): (JSC::SetPrototype::SetPrototype): * runtime/StringConstructor.cpp: (JSC::StringConstructor::finishCreation): (JSC::stringFromCharCodeSlowCase): (JSC::StringConstructor::getOwnPropertySlot): Deleted. * runtime/StringConstructor.h: (JSC::StringConstructor::create): * runtime/StringIteratorPrototype.cpp: (JSC::StringIteratorPrototype::finishCreation): (JSC::StringIteratorPrototype::getOwnPropertySlot): Deleted. * runtime/StringIteratorPrototype.h: (JSC::StringIteratorPrototype::create): (JSC::StringIteratorPrototype::StringIteratorPrototype): * runtime/StringPrototype.cpp: (JSC::StringPrototype::create): (JSC::substituteBackreferencesSlow): (JSC::StringPrototype::getOwnPropertySlot): Deleted. * runtime/StringPrototype.h: * runtime/SymbolConstructor.cpp: (JSC::SymbolConstructor::finishCreation): (JSC::callSymbol): (JSC::SymbolConstructor::getOwnPropertySlot): Deleted. * runtime/SymbolConstructor.h: (JSC::SymbolConstructor::create): * runtime/SymbolPrototype.cpp: (JSC::SymbolPrototype::finishCreation): (JSC::SymbolPrototype::getOwnPropertySlot): Deleted. * runtime/SymbolPrototype.h: (JSC::SymbolPrototype::create): - remove getOwnPropertySlot, replace OverridesGetOwnPropertySlot flag with HasStaticPropertyTable. 2016-05-26 Commit Queue Unreviewed, rolling out r201436. https://bugs.webkit.org/show_bug.cgi?id=158143 Caused 30% regression on Dromaeo DOM core tests (Requested by rniwa on #webkit). Reverted changeset: "REGRESSION: JSBench spends a lot of time transitioning to/from dictionary" https://bugs.webkit.org/show_bug.cgi?id=158045 http://trac.webkit.org/changeset/201436 2016-05-26 Geoffrey Garen REGRESSION: JSBench spends a lot of time transitioning to/from dictionary https://bugs.webkit.org/show_bug.cgi?id=158045 Reviewed by Saam Barati. 15% speedup on jsbench-amazon-firefox, possibly 5% speedup overall on jsbench. This regression seems to have two parts: (1) Transitioning the window object to/from dictionary is more expensive than it used to be to because the window object has lots more properties. The window object has more properties because, for WebIDL compatibility, we reify DOM APIs as properties when you delete. (2) DOM prototypes transition to/from dictionary upon creation because, once again for WebIDL compatibility, we reify their static APIs eagerly. The solution is to chill out a bit on dictionary transitions. * bytecode/ObjectPropertyConditionSet.cpp: Don't flatten a dictionary if we've already done so before. This avoids pathological churn, and it is our idiom in other places. * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): Do flatten the global object unconditionally if it is an uncacheable dictionary because the global object is super important. * runtime/BatchedTransitionOptimizer.h: (JSC::BatchedTransitionOptimizer::BatchedTransitionOptimizer): (JSC::BatchedTransitionOptimizer::~BatchedTransitionOptimizer): Deleted. Don't transition away from dictionary after a batched set of property puts because normal dictionaries are cacheable and that's a perfectly fine state to be in -- and the transition is expensive. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): Do start the global object out as a cacheable dictionary because it will inevitably have enough properties to become a dictionary. * runtime/Operations.h: (JSC::normalizePrototypeChain): Same as ObjectPropertyConditionSet.cpp. 2016-05-25 Geoffrey Garen replaceable own properties seem to ignore replacement after property caching https://bugs.webkit.org/show_bug.cgi?id=158091 Reviewed by Darin Adler. * runtime/Lookup.h: (JSC::replaceStaticPropertySlot): New helper function for replacing a static property with a direct property. We need to do an attribute changed transition because client code might have cached our static property. 2016-05-25 Benjamin Poulain [JSC] RegExp with deeply nested subexpressions overflow the stack in Yarr https://bugs.webkit.org/show_bug.cgi?id=158011 rdar://problem/25946592 Reviewed by Saam Barati. When generating the meta-data required for compilation, Yarr uses a recursive function over the various expression in the pattern. If you have many nested expressions, you can run out of stack and crash the WebProcess. This patch changes that into a soft failure. The expression is just considered invalid. * runtime/RegExp.cpp: (JSC::RegExp::finishCreation): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor): (JSC::Yarr::YarrPatternConstructor::setupOffsets): (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse): (JSC::Yarr::YarrPattern::compile): (JSC::Yarr::YarrPattern::YarrPattern): (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets): Deleted. (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets): Deleted. * yarr/YarrPattern.h: 2016-05-25 Alex Christensen Fix Win64 build after r201335 https://bugs.webkit.org/show_bug.cgi?id=158078 Reviewed by Mark Lam. * offlineasm/x86.rb: Add intel implementations for loadbs and loadhs 2016-05-25 Carlos Garcia Campos REGRESSION(r201066): [GTK] Several intl tests started to fail in GTK+ bot after r201066 https://bugs.webkit.org/show_bug.cgi?id=158066 Reviewed by Darin Adler. run-javascriptcore-tests does $ENV{LANG}="en_US.UTF-8"; but we are not actually honoring the environment variables at all when using jsc binary. We are using setlocale() with a nullptr locale to get the current one, but the current one is always "C", because to set the locale according to the environment variables we need to call setlocale with an empty string as locale. That's done by gtk_init(), which is called by all our binaries (web process, network process, etc.), but not by jsc (because jsc doesn't depend on GTK+). The reason why it has always worked for EFL is because they call ecore_init() in jsc that calls setlocale. * jsc.cpp: (main): Call setlocale(LC_ALL, "") on GTK+. 2016-05-25 Csaba Osztrogonác [ARM] Fix the Wcast-align warning in LinkBuffer.cpp https://bugs.webkit.org/show_bug.cgi?id=157889 Reviewed by Darin Adler. * assembler/LinkBuffer.cpp: (JSC::recordLinkOffsets): 2016-05-24 Keith Miller TypedArray.prototype.slice should not throw if no arguments are provided https://bugs.webkit.org/show_bug.cgi?id=158044 Reviewed by Geoffrey Garen. We were throwing an exception if the TypedArray.prototype.slice function was not provided arguments. This was wrong. Instead we should just assume the first argument was 0. * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncSlice): Deleted. * tests/stress/typedarray-slice.js: 2016-05-24 Keith Miller LLInt should be able to cache prototype loads for values in GetById https://bugs.webkit.org/show_bug.cgi?id=158032 Reviewed by Filip Pizlo. This patch adds prototype value caching to the LLInt for op_get_by_id. Two previously unused words in the op_get_by_id bytecode have been repurposed to hold extra information for the cache. The first is a counter that records the number of get_by_ids that hit a cacheable value on a prototype. When the counter is decremented from one to zero we attempt to cache the prototype load, which will be discussed further below. The second word is used to hold the prototype object when we have started caching. When the counter is decremented to zero we first attempt to generate and watch the property conditions needed to ensure the validity of prototype load. If the watchpoints are successfully created and installed we replace the op_get_by_id opcode with the new op_get_by_id_proto_load opcode, which tells the LLInt to use the cache prototype object for the load rather than the base value. Prior to this patch there was not LLInt specific data onCodeBlocks. Since the CodeBlock needs to own the Watchpoints for the cache, a weak map from each base structure to a bag of Watchpoints created for that structure by some op_get_by_id has been added to the CodeBlock. During GC, if we find that the a structure in the map has not been marked we free the associated bag on the CodeBlock. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::printGetByIdOp): (JSC::CodeBlock::printGetByIdCacheStatus): (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::finalizeLLIntInlineCaches): * bytecode/CodeBlock.h: (JSC::CodeBlock::llintGetByIdWatchpointMap): (JSC::clearLLIntGetByIdCache): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: Added. (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint): (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::install): (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal): * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h: Added. * bytecode/ObjectPropertyConditionSet.cpp: (JSC::ObjectPropertyConditionSet::isValidAndWatchable): * bytecode/ObjectPropertyConditionSet.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitGetById): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::setupGetByIdPrototypeCache): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/Options.h: * tests/stress/llint-get-by-id-cache-prototype-load-from-dictionary.js: Added. (test): 2016-05-24 Keith Miller We should be able to use the sampling profiler with DRT/WTR. https://bugs.webkit.org/show_bug.cgi?id=158041 Reviewed by Saam Barati. This patch makes the sampling profiler use a new option, samplingProfilerPath, which specifies the path to a directory to output sampling profiler data when the program terminates or the VM is destroyed. Additionally, it fixes some other issues with the bytecode profiler that would cause crashes on debug builds. * profiler/ProfilerDatabase.cpp: (JSC::Profiler::Database::ensureBytecodesFor): (JSC::Profiler::Database::performAtExitSave): * runtime/Options.h: * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::registerForReportAtExit): (JSC::SamplingProfiler::reportDataToOptionFile): (JSC::SamplingProfiler::reportTopFunctions): (JSC::SamplingProfiler::reportTopBytecodes): * runtime/SamplingProfiler.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): 2016-05-24 Saam barati We can cache lookups to JSScope::abstractResolve inside CodeBlock::finishCreation https://bugs.webkit.org/show_bug.cgi?id=158036 Reviewed by Geoffrey Garen. This patch implements a 1 item cache for JSScope::abstractResolve. I also tried implementing the cache as a HashMap, but it seemed either less profitable on some benchmarks or just as profitable on others. Therefore, it's cleaner to just use a 1 item cache. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::AbstractResolveKey::AbstractResolveKey): (JSC::AbstractResolveKey::operator==): (JSC::AbstractResolveKey::isEmptyValue): (JSC::CodeBlock::finishCreation): * runtime/GetPutInfo.h: (JSC::needsVarInjectionChecks): (JSC::ResolveOp::ResolveOp): 2016-05-24 Filip Pizlo Unreviwed, add a comment to describe the test's failure mode. Suggested by mlam. * tests/stress/override-map-constructor.js: (Map): 2016-05-24 Filip Pizlo Map should not be in JSGlobalObject's static hashtable because it's initialized eagerly via FOR_EACH_SIMPLE_BUILTIN_TYPE_WITH_CONSTRUCTOR https://bugs.webkit.org/show_bug.cgi?id=158031 rdar://problem/26353661 Reviewed by Geoffrey Garen. We were listing Map as being a lazy class structure. It's not. m_mapStructure is a WriteBarrier<> not a LazyClassStructure<> and there is nothing lazy about it. * runtime/JSGlobalObject.cpp: The fix is to remove Map here. * runtime/Lookup.cpp: Add some dumping on the assert path. (JSC::setUpStaticFunctionSlot): * tests/stress/override-map-constructor.js: Added. This test used to crash. (Map): 2016-05-24 Filip Pizlo LLInt64 should have typed array fast paths for get_by_val https://bugs.webkit.org/show_bug.cgi?id=157931 Reviewed by Keith Miller. I think that the LLInt should be able to access typed arrays more quickly than it does now. Ideally we would have fast paths for every major typed array operation and we would use inline cache optimizations. I don't want to do this all in one go, so my plan is to incrementally add support for this as time allows. This change just adds the easy typed array fast paths for get_by_val in the 64-bit version of LLInt. Another bug, https://bugs.webkit.org/show_bug.cgi?id=157922, tracks the overall task of adding all typed array fast paths to both versions of the LLInt. This is a 30% speed-up on typed array benchmarks in LLInt. This is not a speed-up when the JITs are enabled. * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntOffsetsExtractor.cpp: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/backends.rb: * runtime/JSArrayBufferView.h: * runtime/JSType.h: 2016-05-24 Saam barati and Yusuke Suzuki ThisTDZMode is no longer needed https://bugs.webkit.org/show_bug.cgi?id=157209 Reviewed by Saam Barati. ThisTDZMode is no longer needed because we have ConstructorKind and DerivedContextType. The value of ThisTDZMode is strictly less expressive than the combination of those two values. We were using those values anyways, and this patch just makes it official by removing ThisTDZMode. This patch also cleans up caching keys. We extract SourceCodeFlags from SourceCodeKey and use it in EvalCodeCache. It correctly contains needed cache attributes: EvalContextType, DerivedContextType, etc. Here, we still use specialized keys for EvalCodeCache instead of SourceCodeKey for performance; it does not include name String and does not allocate SourceCode. * bytecode/EvalCodeCache.h: (JSC::EvalCodeCache::CacheKey::CacheKey): (JSC::EvalCodeCache::CacheKey::operator==): (JSC::EvalCodeCache::CacheKey::Hash::equal): (JSC::EvalCodeCache::tryGet): (JSC::EvalCodeCache::getSlow): * bytecompiler/NodesCodegen.cpp: (JSC::ThisNode::emitBytecode): Deleted. * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::evaluateWithScopeExtension): * interpreter/Interpreter.cpp: (JSC::eval): * parser/ASTBuilder.h: (JSC::ASTBuilder::createThisExpr): * parser/NodeConstructors.h: (JSC::ThisNode::ThisNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::Parser::Parser): (JSC::Parser::parsePrimaryExpression): * parser/Parser.h: (JSC::parse): * parser/ParserModes.h: * parser/SourceCodeKey.h: (JSC::SourceCodeFlags::SourceCodeFlags): (JSC::SourceCodeFlags::operator==): (JSC::SourceCodeKey::SourceCodeKey): (JSC::SourceCodeKey::Hash::hash): (JSC::SourceCodeKey::Hash::equal): (JSC::SourceCodeKey::HashTraits::isEmptyValue): (JSC::SourceCodeKeyHash::hash): Deleted. (JSC::SourceCodeKeyHash::equal): Deleted. (JSC::SourceCodeKeyHashTraits::isEmptyValue): Deleted. * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createThisExpr): * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): (JSC::CodeCache::getProgramCodeBlock): (JSC::CodeCache::getEvalCodeBlock): (JSC::CodeCache::getModuleProgramCodeBlock): (JSC::CodeCache::getFunctionExecutableFromGlobalCode): * runtime/CodeCache.h: * runtime/Executable.cpp: (JSC::EvalExecutable::create): * runtime/Executable.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::createEvalCodeBlock): * runtime/JSGlobalObject.h: * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncEval): * tests/stress/code-cache-incorrect-caching.js: Added. (shouldBe): (hello): (catch): (shouldBe.test.hello): (globalEval.ok): (global.hello.hello): 2016-05-23 Yusuke Suzuki Assertion failure for Reflect.get with Proxy and primitive value as explicit receiver https://bugs.webkit.org/show_bug.cgi?id=157080 Reviewed by Saam Barati. In custom accessor getter, the argument "thisValue" can be altered by using `Reflect.get`. In this patch, we add a new parameter, "slotBase". This represents the base value offering this custom getter. And use it in ProxyObject's performGet custom accessor getter. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::staticFunctionGetter): (JSC::JSCallbackObject::callbackGetter): * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generateImpl): In PolymorphicAccess case, the thisValue and the slotBase are always cells. This is because IC is enabled in the case that the base value is a cell. And slotBase is always on the prototype chain from this base value. * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsWithExecState): * jsc.cpp: (WTF::CustomGetter::customGetter): (WTF::RuntimeArray::lengthGetter): * runtime/CustomGetterSetter.cpp: (JSC::callCustomSetter): * runtime/JSBoundSlotBaseFunction.cpp: (JSC::boundSlotBaseFunctionCall): * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): * runtime/JSFunction.h: * runtime/JSModuleNamespaceObject.cpp: (JSC::callbackGetter): * runtime/PropertySlot.cpp: (JSC::PropertySlot::customGetter): * runtime/PropertySlot.h: * runtime/ProxyObject.cpp: (JSC::performProxyGet): * runtime/RegExpConstructor.cpp: (JSC::regExpConstructorDollar): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): (JSC::regExpConstructorDollar1): Deleted. (JSC::regExpConstructorDollar2): Deleted. (JSC::regExpConstructorDollar3): Deleted. (JSC::regExpConstructorDollar4): Deleted. (JSC::regExpConstructorDollar5): Deleted. (JSC::regExpConstructorDollar6): Deleted. (JSC::regExpConstructorDollar7): Deleted. (JSC::regExpConstructorDollar8): Deleted. (JSC::regExpConstructorDollar9): Deleted. * tests/stress/proxy-get-with-primitive-receiver.js: Added. (shouldBe): 2016-05-23 Geoffrey Garen REGRESSION (196374): deleting a global property is expensive https://bugs.webkit.org/show_bug.cgi?id=158005 Reviewed by Chris Dumez. * runtime/JSObject.cpp: (JSC::JSObject::deleteProperty): We only need to reify static properties if the name being deleted matches a static property. Otherwise, we can be sure that delete won't observe any static properties. 2016-05-23 Saam barati The baseline JIT crashes when compiling "(1,1)/1" https://bugs.webkit.org/show_bug.cgi?id=157933 Reviewed by Benjamin Poulain. op_div in the baseline JIT needed to better handle when both the lhs and rhs are constants. It needs to make sure to load either the lhs or the rhs into a register since the div generator can't handle both the lhs and rhs being constants. * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_div): * tests/stress/jit-gracefully-handle-double-constants-in-math-operators.js: Added. (assert): (test): 2016-05-23 Saam barati String template don't handle let initialization properly inside eval https://bugs.webkit.org/show_bug.cgi?id=157991 Reviewed by Oliver Hunt. The fix is to make sure we emit TDZ checks. * bytecompiler/NodesCodegen.cpp: (JSC::TaggedTemplateNode::emitBytecode): * tests/stress/tagged-template-tdz.js: Added. (shouldThrowTDZ): (test): 2016-05-22 Saam barati Unreviewed. Fixed debug assertion failures from r201235. * runtime/JSScope.cpp: (JSC::abstractAccess): 2016-05-22 Brady Eidson Attempted Yosemite build fix after http://trac.webkit.org/changeset/201255 Suggested by and reviewed by Anders Carlsson. * b3/B3CCallValue.h: Initialize the effects member more conventionally. 2016-05-22 Brady Eidson Move to C++14. https://bugs.webkit.org/show_bug.cgi?id=157948 Reviewed by Michael Catanzaro. * Configurations/Base.xcconfig: 2016-05-22 Saam barati REGRESSION(r199075): String.prototype.replace fails after being used many times with different replace values https://bugs.webkit.org/show_bug.cgi?id=157968 Reviewed by Ryosuke Niwa and Filip Pizlo. There was a bug in the DFG where we were checking a condition on the wrong variable. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): 2016-05-22 Chris Dumez Remove uses of PassRefPtr in JS bindings code https://bugs.webkit.org/show_bug.cgi?id=157949 Reviewed by Andreas Kling. Remove uses of PassRefPtr in JS bindings code. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::queueMicrotask): * runtime/JSGlobalObject.h: 2016-05-20 Joseph Pecoraro Remove LegacyProfiler https://bugs.webkit.org/show_bug.cgi?id=153565 Reviewed by Mark Lam. JavaScriptCore now provides a sampling profiler and it is enabled by all ports. Web Inspector switched months ago to using the sampling profiler and displaying its data. Remove the legacy profiler, as it is no longer being used by anything other then console.profile and tests. We will update console.profile's behavior soon to have new behavior and use the sampling data. * API/JSProfilerPrivate.cpp: Removed. * API/JSProfilerPrivate.h: Removed. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): Deleted. (JSC::computeDefsForBytecodeOffset): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): Deleted. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor): * bytecode/UnlinkedFunctionExecutable.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitCallVarargs): (JSC::BytecodeGenerator::emitCallVarargsInTailPosition): (JSC::BytecodeGenerator::emitConstructVarargs): (JSC::BytecodeGenerator::emitConstruct): * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::profileHookRegister): Deleted. (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted. * bytecompiler/NodesCodegen.cpp: (JSC::CallFunctionCallDotNode::emitBytecode): (JSC::ApplyFunctionCallDotNode::emitBytecode): (JSC::CallArguments::CallArguments): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): Deleted. * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): Deleted. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): Deleted. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): Deleted. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): Deleted. * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): Deleted. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): Deleted. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): Deleted. * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled): * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::operator()): Deleted. (JSC::Interpreter::execute): Deleted. (JSC::Interpreter::executeCall): Deleted. (JSC::Interpreter::executeConstruct): Deleted. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): Deleted. * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_profile_will_call): Deleted. (JSC::JIT::emit_op_profile_did_call): Deleted. * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_profile_will_call): Deleted. (JSC::JIT::emit_op_profile_did_call): Deleted. * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted. * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * parser/ParserModes.h: * profiler/CallIdentifier.h: Removed. * profiler/LegacyProfiler.cpp: Removed. * profiler/LegacyProfiler.h: Removed. * profiler/Profile.cpp: Removed. * profiler/Profile.h: Removed. * profiler/ProfileGenerator.cpp: Removed. * profiler/ProfileGenerator.h: Removed. * profiler/ProfileNode.cpp: Removed. * profiler/ProfileNode.h: Removed. * profiler/ProfilerJettisonReason.cpp: (WTF::printInternal): Deleted. * profiler/ProfilerJettisonReason.h: * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): (JSC::CodeCache::getProgramCodeBlock): (JSC::CodeCache::getEvalCodeBlock): (JSC::CodeCache::getModuleProgramCodeBlock): * runtime/CodeCache.h: * runtime/Executable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::createProgramCodeBlock): (JSC::JSGlobalObject::createEvalCodeBlock): (JSC::JSGlobalObject::createModuleProgramCodeBlock): (JSC::JSGlobalObject::~JSGlobalObject): Deleted. (JSC::JSGlobalObject::hasLegacyProfiler): Deleted. * runtime/JSGlobalObject.h: * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::VM): Deleted. (JSC::SetEnabledProfilerFunctor::operator()): Deleted. (JSC::VM::setEnabledProfiler): Deleted. * runtime/VM.h: (JSC::VM::enabledProfiler): Deleted. (JSC::VM::enabledProfilerAddress): Deleted. 2016-05-20 Joseph Pecoraro Remove LegacyProfiler https://bugs.webkit.org/show_bug.cgi?id=153565 Reviewed by Saam Barati. * inspector/protocol/Timeline.json: * jsc.cpp: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::hasLegacyProfiler): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted. 2016-05-20 Saam barati JSScope::abstractAccess doesn't need to copy the SymbolTableEntry, it can use it by reference https://bugs.webkit.org/show_bug.cgi?id=157956 Reviewed by Geoffrey Garen. A SymbolTableEntry may be a FatEntry. Copying a FatEntry is slow because we have to malloc memory for it, then free the malloced memory once the entry goes out of scope. abstractAccess uses a SymbolTableEntry temporarily when performing scope accesses during bytecode linking. It copies out the SymbolTableEntry every time it does a SymbolTable lookup. This is not cheap when the entry happens to be a FatEntry. We should really just be using a reference to the entry because there is no need to copy it in such a scenario. * runtime/JSScope.cpp: (JSC::abstractAccess): 2016-05-20 Joseph Pecoraro Web Inspector: retained size for typed arrays does not count native backing store https://bugs.webkit.org/show_bug.cgi?id=157945 Reviewed by Geoffrey Garen. * runtime/JSArrayBuffer.h: * runtime/JSArrayBuffer.cpp: (JSC::JSArrayBuffer::estimatedSize): Include an estimatedSize implementation for JSArrayBuffer. ArrayBuffer has a unique path, different from other data stored in the Heap. * tests/heapProfiler/typed-array-sizes.js: Added. Test sizes of TypedArray with and without an ArrayBuffer. When the TypedArray is a view wrapping an ArrayBuffer, the ArrayBuffer has the size. 2016-05-20 Geoffrey Garen reifyAllStaticProperties makes two copies of every string https://bugs.webkit.org/show_bug.cgi?id=157953 Reviewed by Mark Lam. Let's not do that. * runtime/JSObject.cpp: (JSC::JSObject::reifyAllStaticProperties): Pass our Identifier to reifyStaticProperty so it doesn't have to make its own. * runtime/Lookup.h: (JSC::reifyStaticProperty): No need to null check because callers never pass null anymore. No need to make an identifier because callers pass us one. (JSC::reifyStaticProperties): Honor new interface. 2016-05-20 Geoffrey Garen JSBench regression: CodeBlock linking always copies the symbol table https://bugs.webkit.org/show_bug.cgi?id=157951 Reviewed by Saam Barati. We always put a SymbolTable into the constant pool, even in simple functions in which it won't be used -- i.e., there's on eval and there are no captured variables and so on. This is costly because linking must copy any provided symbol tables. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitProfileType): Only add the symbol table as a constant if we will use it at runtime. 2016-05-19 Benjamin Poulain [JSC] Improve int->float conversion in FTL https://bugs.webkit.org/show_bug.cgi?id=157936 Reviewed by Filip Pizlo. The integer -> floating point lowering was very barebone. For example, converting a constant integer to double was doing: mov #const, %eax xor %xmm0, %xmm0 cvtsi2sd %eax, %xmm0 Conversion from integer to float was also missing. We were always converting to double then rounding the double to float. This patch adds the basics: -Constant folding. -Integer to Float opcode. -Reducing int->double to int->float when used by DoubleToFloat. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::convertInt32ToFloat): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::convertInt64ToDouble): (JSC::MacroAssemblerX86_64::convertInt64ToFloat): * assembler/X86Assembler.h: (JSC::X86Assembler::cvtsi2ss_rr): (JSC::X86Assembler::cvtsi2ssq_rr): (JSC::X86Assembler::cvtsi2sdq_mr): (JSC::X86Assembler::cvtsi2ssq_mr): (JSC::X86Assembler::cvtsi2ss_mr): * assembler/MacroAssemblerARM64.h: * b3/B3Const32Value.cpp: (JSC::B3::Const32Value::iToDConstant): (JSC::B3::Const32Value::iToFConstant): * b3/B3Const32Value.h: * b3/B3Const64Value.cpp: (JSC::B3::Const64Value::iToDConstant): (JSC::B3::Const64Value::iToFConstant): * b3/B3Const64Value.h: * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::lower): * b3/B3Opcode.cpp: (WTF::printInternal): * b3/B3Opcode.h: * b3/B3ReduceDoubleToFloat.cpp: * b3/B3ReduceStrength.cpp: * b3/B3Validate.cpp: * b3/B3Value.cpp: (JSC::B3::Value::iToDConstant): (JSC::B3::Value::iToFConstant): (JSC::B3::Value::isRounded): (JSC::B3::Value::effects): (JSC::B3::Value::key): (JSC::B3::Value::typeFor): * b3/B3Value.h: * b3/B3ValueKey.cpp: (JSC::B3::ValueKey::materialize): * b3/air/AirFixPartialRegisterStalls.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.cpp: (JSC::B3::int64Operands): (JSC::B3::testIToD64Arg): (JSC::B3::testIToF64Arg): (JSC::B3::testIToD32Arg): (JSC::B3::testIToF32Arg): (JSC::B3::testIToD64Mem): (JSC::B3::testIToF64Mem): (JSC::B3::testIToD32Mem): (JSC::B3::testIToF32Mem): (JSC::B3::testIToD64Imm): (JSC::B3::testIToF64Imm): (JSC::B3::testIToD32Imm): (JSC::B3::testIToF32Imm): (JSC::B3::testIToDReducedToIToF64Arg): (JSC::B3::testIToDReducedToIToF32Arg): (JSC::B3::run): 2016-05-19 Benjamin Poulain [JSC] FTL can crash on stack overflow https://bugs.webkit.org/show_bug.cgi?id=157881 rdar://problem/24665964 Reviewed by Michael Saboff. The VM's m_largestFTLStackSize was never set anywhere (updateFTLLargestStackSize() was never called). We forgot to change that when implementing B3. Even when it is set, we still have a problem on OSR Exit. If the last frame is a FTL frame and it OSR Exits, the space required for that frame becomes significantly larger. What happens is we crash in the OSR Exit instead of the FTL frame (this is what happens in rdar://problem/24665964). This patch changes the stack boundary checks in FTL to be the same as DFG: we verify that we have enough space for the current optimized function but also for the baseline version (including inlining) in case of exit. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack): Deleted. * runtime/VM.cpp: (JSC::VM::VM): Deleted. (JSC::VM::updateStackLimit): Deleted. (JSC::VM::updateFTLLargestStackSize): Deleted. * runtime/VM.h: (JSC::VM::addressOfFTLStackLimit): Deleted. 2016-05-18 Filip Pizlo DFG::LICMPhase shouldn't hoist type checks unless it knows that the check will succeed at the loop pre-header https://bugs.webkit.org/show_bug.cgi?id=144527 Reviewed by Saam Barati. This adds a control flow equivalence analysis (called ControlEquivalenceAnalysis) based on dominator analysis over the backwards CFG. Two basic blocks are control flow equivalent if the execution of one implies that the other one must also execute. It means that the two blocks' forward and backward dominance are reciprocated: (A dom B and B backdom A) or (B dom A and A backdom B). LICM now uses it to become more conservative about hoisting checks, if this has caused problems in the past. If we hoist something that may exit from a block that was not control equivalent to the pre-header then it's possible that the node's speculation will fail even though it wouldn't have if it wasn't hoisted. So, we flag these nodes' origins as being "wasHoisted" and we track all of their exits as "HoistingFailed". LICM will turn off such speculative hoisting if the CodeBlock from which we are hoisting had the HoistingFailed exit kind. Note that this deliberately still allows us to hoist things that may exit even if they are not control equivalent to the pre-header. This is necessary because the profitability of hoisting is so huge in all of the cases that we're aware of that it's worth giving it a shot. This is neutral on macrobenchmarks since none of the benchmarks we track have a hoistable operation that would exit only if hoisted. I added microbenchmarks to illustrate the problem and two of them speed up by ~40% while one of them is neutral (Int52 saves us from having problems on that program even though LICM previously did the wrong thing). * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/ExitKind.cpp: (JSC::exitKindToString): * bytecode/ExitKind.h: * dfg/DFGAtTailAbstractState.h: (JSC::DFG::AtTailAbstractState::operator bool): (JSC::DFG::AtTailAbstractState::initializeTo): * dfg/DFGBackwardsCFG.h: Added. (JSC::DFG::BackwardsCFG::BackwardsCFG): * dfg/DFGBackwardsDominators.h: Added. (JSC::DFG::BackwardsDominators::BackwardsDominators): * dfg/DFGCommon.h: (JSC::DFG::checkAndSet): Deleted. * dfg/DFGControlEquivalenceAnalysis.h: Added. (JSC::DFG::ControlEquivalenceAnalysis::ControlEquivalenceAnalysis): (JSC::DFG::ControlEquivalenceAnalysis::dominatesEquivalently): (JSC::DFG::ControlEquivalenceAnalysis::areEquivalent): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): (JSC::DFG::Graph::dumpBlockHeader): (JSC::DFG::Graph::invalidateCFG): (JSC::DFG::Graph::substituteGetLocal): (JSC::DFG::Graph::handleAssertionFailure): (JSC::DFG::Graph::ensureDominators): (JSC::DFG::Graph::ensurePrePostNumbering): (JSC::DFG::Graph::ensureNaturalLoops): (JSC::DFG::Graph::ensureBackwardsCFG): (JSC::DFG::Graph::ensureBackwardsDominators): (JSC::DFG::Graph::ensureControlEquivalenceAnalysis): (JSC::DFG::Graph::methodOfGettingAValueProfileFor): * dfg/DFGGraph.h: (JSC::DFG::Graph::hasDebuggerEnabled): * dfg/DFGInPlaceAbstractState.h: (JSC::DFG::InPlaceAbstractState::operator bool): (JSC::DFG::InPlaceAbstractState::createValueForNode): (JSC::DFG::InPlaceAbstractState::forNode): * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::run): (JSC::DFG::LICMPhase::attemptHoist): * dfg/DFGMayExit.cpp: (JSC::DFG::mayExit): * dfg/DFGMayExit.h: * dfg/DFGNode.h: * dfg/DFGNodeOrigin.cpp: (JSC::DFG::NodeOrigin::dump): * dfg/DFGNodeOrigin.h: (JSC::DFG::NodeOrigin::takeValidExit): (JSC::DFG::NodeOrigin::withWasHoisted): (JSC::DFG::NodeOrigin::forInsertingAfter): * dfg/DFGNullAbstractState.h: Added. (JSC::DFG::NullAbstractState::NullAbstractState): (JSC::DFG::NullAbstractState::operator bool): (JSC::DFG::NullAbstractState::forNode): * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::OSRExit): * dfg/DFGOSRExitBase.cpp: (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow): * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::OSRExitBase): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): * ftl/FTLOSRExit.cpp: (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle): (JSC::FTL::OSRExit::OSRExit): * ftl/FTLOSRExit.h: 2016-05-19 Mark Lam Code that null checks the VM pointer before any use should ref the VM. https://bugs.webkit.org/show_bug.cgi?id=157864 Reviewed by Filip Pizlo and Keith Miller. JSLock::willReleaseLock() and HeapTimer::timerDidFire() need to reference the VM through a RefPtr. Otherwise, there's no guarantee that the VM won't be deleted after their null checks. * bytecode/CodeBlock.h: (JSC::CodeBlock::vm): (JSC::CodeBlock::setVM): Deleted. - Not used, and suggests that it can be changed during the lifetime of the CodeBlock (which should not be). * heap/HeapTimer.cpp: (JSC::HeapTimer::timerDidFire): * runtime/JSLock.cpp: (JSC::JSLock::willReleaseLock): - Store the VM pointer in a RefPtr first, and null check the RefPtr instead of the raw VM pointer. This makes the null check a strong guarantee that the VM pointer is valid while these functions are using it. 2016-05-19 Saam barati arrow function lexical environment should reuse the same environment as the function's lexical environment where possible https://bugs.webkit.org/show_bug.cgi?id=157908 Reviewed by Filip Pizlo. We can safely combine these two environment when we have a simple parameter list (no default parameters, no destructring parameters). * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack): (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded): * bytecompiler/BytecodeGenerator.h: 2016-05-19 Michael Saboff Unreviewed build fix. Skipping this new test as it times out on the bots. Issue tracked in https://bugs.webkit.org/show_bug.cgi?id=157903 * tests/stress/regress-157595.js: (MyRegExp): 2016-05-19 Guillaume Emont JSC: DFG::SpeculativeJIT::compile special case for MIPS for PutByValWithThis https://bugs.webkit.org/show_bug.cgi?id=157741 Reviewed by Saam Barati. The PutByValWithThis case needs a special case for MIPS because we don't have enough registers. The special case needs to be different from the x86 one because we have a different ABI. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2016-05-19 Brian Burg Web Inspector: use a consistent prefix for injected scripts https://bugs.webkit.org/show_bug.cgi?id=157715 Reviewed by Timothy Hatcher. * CMakeLists.txt: * DerivedSources.make: * inspector/InjectedScriptSource.js: 2016-05-19 Csaba Osztrogonác [ARM] Remove redefined macro after r200606 https://bugs.webkit.org/show_bug.cgi?id=157890 Reviewed by Michael Saboff. * bytecode/PolymorphicAccess.cpp: * jit/CCallHelpers.h: 2016-05-18 Saam barati Function with default parameter values that are arrow functions that capture this isn't working https://bugs.webkit.org/show_bug.cgi?id=157786 Reviewed by Geoffrey Garen. To make the scopes ordered properly, I needed to initialize the arrow function lexical environment before initializing default parameter values. I also made the code easier to reason about by never reusing the function's var lexical environment for the arrow function lexical environment. The reason for this is that that code was wrong, and we just didn't have code to that properly tested it. It was easy for that code to be wrong because sometimes the function's lexical environment isn't the top-most scope (namely, when a function's parameter list is non-simple) and sometimes it is (when the function's parameter list is simple). Also, because a function's default parameter values may capture the 'arguments' variable inside an arrow function, I needed to take care to initialize the 'arguments' variable as part of whichever scope is the top-most scope. It's either the function's var environment if the parameter list is simple, or it's the function's parameter environment if the parameter list is non-simple. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack): (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded): (JSC::BytecodeGenerator::initializeParameters): (JSC::BytecodeGenerator::initializeVarLexicalEnvironment): (JSC::BytecodeGenerator::visibleNameForParameter): * bytecompiler/BytecodeGenerator.h: * tests/stress/arrow-functions-as-default-parameter-values.js: Added. (assert): (test): (test.foo): * tests/stress/op-push-name-scope-crashes-profiler.js: (test): 2016-05-18 Michael Saboff r199812 broke test262 https://bugs.webkit.org/show_bug.cgi?id=157595 Reviewed by Filip Pizlo. Added a reasonable limit to the size of the match result array to catch possible infinite loops when matching. Added a new tests that creates an infinite loop in RegExp.prototype.[Symbol.match] by creating a subclass of RegExp where the base RegExp's global flag is false and the subclass overrides .global with a getter that always returns true. * builtins/RegExpPrototype.js: (match): * tests/stress/regress-157595.js: Added. (MyRegExp): (MyRegExp.prototype.get global): (test): (catch): 2016-05-18 Yusuke Suzuki [ES6] Namespace object re-export should be handled as local export https://bugs.webkit.org/show_bug.cgi?id=157806 Reviewed by Mark Lam. We align the implementation of ExportEntry to the spec; remove Type::Namespace. This Type::Namespace is used for re-exported namespace object binding. For example, import * as namespace from "namespace.js" export { namespace } In the above case, we used ExportEntry(Type::Namespace). In this patch, we drop this and use normal local export (Type::Local) instead because namespace object actually has the local binding in the above module environment. And this handling strictly meets the spec (Sec 15.2.1.16.1 step 11-a-ii-2-b). And we also clean up the ExportEntry implementation; dropping unnecessary information. This change fixes the test262/test/language/module-code/instn-star-equality.js crash. * parser/ModuleAnalyzer.cpp: (JSC::ModuleAnalyzer::exportVariable): * runtime/JSModuleRecord.cpp: (JSC::getExportedNames): (JSC::JSModuleRecord::dump): Deleted. * runtime/JSModuleRecord.h: * tests/modules/namespace-re-export.js: Added. * tests/modules/namespace-re-export/namespace-re-export-fixture.js: Added. * tests/modules/namespace-re-export/namespace-re-export.js: Added. * tests/modules/resources/assert.js: (export.shouldNotBe): 2016-05-17 Filip Pizlo JSC should detect the right default locale even when it's not embedded in WebCore https://bugs.webkit.org/show_bug.cgi?id=157755 rdar://problem/24665424 Reviewed by Keith Miller. This makes JSC try to use WTF's platform user preferred language detection if the DOM did not register a defaultLanguage callback. The result is that when JSC runs standalone it will detect the platform user preferred language almost the same way as when it's embedded in WebCore. The only difference is that WebCore may have its own additional overrides via the WK API. But in the absence of overrides, WebCore uses the same WTF logic that JSC falls back to. We first found this bug because on iOS, the intl tests would fail because ICU would report a somewhat bogus locale on that platform. Prior to this change, standalone JSC would fall back to ICU's locale detection. It turns out that the ICU default locale is also bogus on OS X, just less so. For example, setting things to Poland did not result in the jsc shell printing dates Polish-style. Now it will print them Polish-style if your system preferences say so. Also, the tests don't fail on iOS anymore. * runtime/IntlObject.cpp: (JSC::defaultLocale): 2016-05-17 Dean Jackson Remove ES6_GENERATORS flag https://bugs.webkit.org/show_bug.cgi?id=157815 Reviewed by Geoffrey Garen. This flag isn't needed. Generators are enabled everywhere and part of a stable specification. * Configurations/FeatureDefines.xcconfig: * parser/Parser.cpp: (JSC::Parser::parseFunctionDeclaration): Deleted. (JSC::Parser::parseClass): Deleted. (JSC::Parser::parseExportDeclaration): Deleted. (JSC::Parser::parseAssignmentExpression): Deleted. (JSC::Parser::parseProperty): Deleted. (JSC::Parser::parseFunctionExpression): Deleted. 2016-05-17 Keith Miller Rollout r200426 since it causes PLT regressions. https://bugs.webkit.org/show_bug.cgi?id=157812 Unreviewed rollout of r200426 since the bots see a ~.6% PLT regression from the patch. 2016-05-17 Keith Miller Add test262 harness support code https://bugs.webkit.org/show_bug.cgi?id=157797 Reviewed by Filip Pizlo. This patch adds some new tooling needed to run Test262 with the jsc CLI. There were three options that needed to be added for Test262: 1) "--test262-async" This option overrides the print function in the test runner to look for 'Test262:AsyncTestComplete' instead of printing the passed text. If test262-async mode is on and that string is not passed then the test is marked as failing. 2) "--strict-file=" This option appends `"use strict";\n` to the beginning of the passed file before passing the source code to the VM. This option can, in theory, be passed multiple times. 3) "--exception=" This option asserts that at the end of the last script file passed the VM has an uncaught exception with its name property equal to the passed name. * jsc.cpp: (Script::Script): (fillBufferWithContentsOfFile): (functionPrint): (checkUncaughtException): (runWithScripts): (printUsageStatement): (CommandLine::parseArguments): (runJSC): 2016-05-17 Filip Pizlo WTF should know about Language https://bugs.webkit.org/show_bug.cgi?id=157756 Reviewed by Geoffrey Garen. Teach our scripts that a ObjC class beginning with WTF is totally cool. * JavaScriptCore.xcodeproj/project.pbxproj: 2016-05-17 Joseph Pecoraro console namespace breaks putting properties on console.__proto__ https://bugs.webkit.org/show_bug.cgi?id=157782 Reviewed by Geoffrey Garen. Some websites currently depend on console.__proto__ existing and being a separate object from Object.prototype. This patch adds back a basic console.__proto__ object, but all the console functions are left on the ConsoleObject itself. * runtime/JSGlobalObject.cpp: (JSC::createConsoleProperty): 2016-05-17 Yusuke Suzuki Unreviewed, dump more information when math-pow-stable-results.js failed https://bugs.webkit.org/show_bug.cgi?id=157168 * tests/stress/math-pow-stable-results.js: 2016-05-16 Saam barati ShadowChicken crashes when reading a scope from the frame during a stack overflow exception https://bugs.webkit.org/show_bug.cgi?id=157770 Reviewed by Filip Pizlo. ShadowChicken was reading the scope from a half formed frame as it threw a stack overflow exception. The frame had a valid CodeBlock pointer, but it did not have a valid scope. The code in ShadowChicken's throw packet logging mechanism didn't account for this. The fix is to respect whether genericUnwind wants to unwind from the current frame or the caller's frame. For stack overflow errors, we always unwind the caller's frame. * jit/JITExceptions.cpp: (JSC::genericUnwind): 2016-05-16 Yusuke Suzuki REGRESSION(r200208): It made 2 JSC stress tests fail on x86 https://bugs.webkit.org/show_bug.cgi?id=157168 Reviewed by Benjamin Poulain. The fast path in operationMathPow produces different results between x87 and the other environments. This is because x87 calculates the double value in 80bit precision. The situation is the following: in x86 32bit environment, floating point operations are compiled to x87 operations by default even if we can use SSE2. But in DFG environment, we aggressively use SSE2 if the cpuid reports SSE2 is available. As a result, the implementations differ between C runtime and DFG JIT code. The C runtime uses x87 while DFG JIT code uses SSE2. This causes a precision problem since x87 has 80bit precision while SSE2 has 64bit precision. In this patch, in x86 32bit environment, we use `volatile double` if the `-mfpmath=sse and -msse2 (or later)` is not specified. This will round the x87 value into 64bit per multiplying. Note that this problem does not occur in OS X clang 32bit environment. This is because `-mfpmath=sse` is enabled by default in OS X clang 32bit. * b3/B3MathExtras.cpp: (JSC::B3::powDoubleInt32): * runtime/MathCommon.cpp: (JSC::operationMathPow): 2016-05-16 Benjamin Poulain [JSC] "return this" in a constructor does not need a branch on isObject(this) https://bugs.webkit.org/show_bug.cgi?id=157775 Reviewed by Saam Barati and Ryosuke Niwa. When returning "this" in a constructor, the bytecode generator was generating: is_object locX, this jtrue locX, 5(->second ret) ret this ret this That code is eliminated in DFG but it is pretty costly lower tiers. This patch changes bytecode generation to avoid the is_object test when possible and not generate two ret if they encode the same thing. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitReturn): 2016-05-16 Benjamin Poulain [JSC] Remove the index check from op_get_by_val/op_put_by_val when the index is constant https://bugs.webkit.org/show_bug.cgi?id=157766 Reviewed by Geoffrey Garen. If the index is an integer constant, do not generate the index check. * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitSlow_op_put_by_val): 2016-05-16 Benjamin Poulain [JSC][DFG] Fill spilled Int32 as Int32 instead of JSInt32 https://bugs.webkit.org/show_bug.cgi?id=157700 Reviewed by Michael Saboff. In general, fillSpeculateInt32() originate from SpeculateInt32 and the user does not care about the tag. This is particularily obvious on Sunspider's math-spectral-norm.js. In that test, registers are frequently spilled because of x86's DIV. When they are re-filled, they were always tagged. Since the loops are small, all the tagging adds up. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): 2016-05-16 Saam barati Unreviewed Cloop build fix. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex): 2016-05-16 Saam barati Hook up ShadowChicken to the debugger to show tail deleted frames https://bugs.webkit.org/show_bug.cgi?id=156685 Reviewed by Filip Pizlo and Mark Lam and Joseph Pecoraro. The heart of this patch hooks up ShadowChicken to DebuggerCallFrame to allow the Web Inspector to display the ShadowChicken's shadow stack. This means the Web Inspector can now display tail deleted frames. To make this work, I made the necessary changes to ShadowChicken and DebuggerCallFrame to allow DebuggerCallFrame to keep the same API when representing both machine frames and tail deleted frames. - ShadowChicken prologue packets now log the current scope. Tail packets log the current scope, the 'this' value, the CodeBlock, and the CallSiteIndex. This allows the inspector to not only show the tail deleted frame, but also show exactly where the tail call happened (line and column numbers), with which scope it executed, and with which 'this' value. This patch also allows DebuggerCallFrame to execute console statements in a tail deleted frame. - I changed ShadowChicken's stack resizing algorithm. ShadowChicken now only keeps a maximum number of tail deleted frames in its shadow stack. It will happily represent all machine frames without limit. Right now, the maximum number of tail deleted frames I chose to keep alive is 128. We will keep frames alive starting from the top of the stack. This allows us to have a strong defense against runaway memory usage. We will only keep around at most 128 "shadow" frames that wouldn't have naturally been kept alive by the executing program. We can play around with this number if we find that 128 is either too many or too few frames. - DebuggerCallFrame is no longer a cheap class to create. When it is created, we will eagerly create the entire virtual debugger stack. So I modified the existing code to lazily create DebuggerCallFrames only when necessary. We used to eagerly create them at each op_debug statement even though we would just throw them away if we didn't hit a breakpoint. - A valid DebuggerCallFrame will always have a valid CallFrame* pointer into the stack. This pointer won't always refer to the logical frame that the DebuggerCallFrame represents because a DebuggerCallFrame can now represent a tail deleted frame. To do this, DebuggerCallFrame now has a ShadowChicken::Frame member variable. This allows DebuggerCallFrame to know when it represents a tail deleted frame and gives DebuggerCallFrame a mechanism to ask the tail deleted frame for interesting information (like its 'this' value, scope, CodeBlock, etc). A tail deleted frame's machine frame pointer will be the machine caller of the tail deleted frame (or the machine caller of the first of a series of consecutive tail calls). - I added a new flag to UnlinkedCodeBlock to indicate when it is compiled with debugging opcodes. I did this because ShadowChicken may read a JSScope from the machine stack. This is only safe if the machine CodeBlock was compiled with debugging opcodes. This is safer than asking if the CodeBlock's global object has an interactive debugger enabled because it's theoretically possible for the debugger to be enabled while code compiled without a debugger is still live on the stack. This field is also now used to indicate to the DFGGraph that the interactive debugger is enabled. - Finally, this patch adds a new field to the Inspector's CallFrame protocol object called 'isTailDeleted' to allow the Inspector to know when a CallFrame represents a tail deleted frame. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::findPC): (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex): * bytecode/CodeBlock.h: (JSC::CodeBlock::clearDebuggerRequests): (JSC::CodeBlock::wasCompiledWithDebuggingOpcodes): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes): (JSC::UnlinkedCodeBlock::finishCreation): (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock): * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitEnter): (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary): (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary): (JSC::BytecodeGenerator::emitCallDefineProperty): * debugger/Debugger.cpp: (JSC::DebuggerPausedScope::DebuggerPausedScope): (JSC::DebuggerPausedScope::~DebuggerPausedScope): (JSC::Debugger::didReachBreakpoint): (JSC::Debugger::currentDebuggerCallFrame): * debugger/Debugger.h: * debugger/DebuggerCallFrame.cpp: (JSC::LineAndColumnFunctor::operator()): (JSC::DebuggerCallFrame::create): (JSC::DebuggerCallFrame::DebuggerCallFrame): (JSC::DebuggerCallFrame::callerFrame): (JSC::DebuggerCallFrame::globalExec): (JSC::DebuggerCallFrame::vmEntryGlobalObject): (JSC::DebuggerCallFrame::sourceID): (JSC::DebuggerCallFrame::functionName): (JSC::DebuggerCallFrame::scope): (JSC::DebuggerCallFrame::type): (JSC::DebuggerCallFrame::thisValue): (JSC::DebuggerCallFrame::evaluateWithScopeExtension): (JSC::DebuggerCallFrame::invalidate): (JSC::DebuggerCallFrame::currentPosition): (JSC::DebuggerCallFrame::positionForCallFrame): (JSC::DebuggerCallFrame::sourceIDForCallFrame): (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor): Deleted. (JSC::FindCallerMidStackFunctor::operator()): Deleted. (JSC::FindCallerMidStackFunctor::getCallerFrame): Deleted. (JSC::DebuggerCallFrame::thisValueForCallFrame): Deleted. * debugger/DebuggerCallFrame.h: (JSC::DebuggerCallFrame::isValid): (JSC::DebuggerCallFrame::isTailDeleted): (JSC::DebuggerCallFrame::create): Deleted. (JSC::DebuggerCallFrame::exec): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): (JSC::DFG::Graph::~Graph): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::addCallSite): (JSC::DFG::JITCompiler::emitStoreCodeOrigin): (JSC::DFG::JITCompiler::emitStoreCallSiteIndex): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue): (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail): (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket): (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket): Deleted. * inspector/InjectedScriptSource.js: (InjectedScript.CallFrameProxy): * inspector/JSJavaScriptCallFrame.cpp: (Inspector::JSJavaScriptCallFrame::thisObject): (Inspector::JSJavaScriptCallFrame::isTailDeleted): (Inspector::JSJavaScriptCallFrame::type): * inspector/JSJavaScriptCallFrame.h: * inspector/JSJavaScriptCallFramePrototype.cpp: (Inspector::JSJavaScriptCallFramePrototype::finishCreation): (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension): (Inspector::jsJavaScriptCallFrameAttributeType): (Inspector::jsJavaScriptCallFrameIsTailDeleted): * inspector/JavaScriptCallFrame.h: (Inspector::JavaScriptCallFrame::type): (Inspector::JavaScriptCallFrame::scopeChain): (Inspector::JavaScriptCallFrame::vmEntryGlobalObject): (Inspector::JavaScriptCallFrame::isTailDeleted): (Inspector::JavaScriptCallFrame::thisValue): (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension): * inspector/ScriptDebugServer.cpp: (Inspector::ScriptDebugServer::evaluateBreakpointAction): * inspector/protocol/Debugger.json: * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::update): (JSC::ShadowChicken::visitChildren): (JSC::ShadowChicken::reset): * interpreter/ShadowChicken.h: (JSC::ShadowChicken::Packet::throwMarker): (JSC::ShadowChicken::Packet::prologue): (JSC::ShadowChicken::Packet::tail): (JSC::ShadowChicken::Frame::Frame): (JSC::ShadowChicken::Frame::operator==): * jit/CCallHelpers.cpp: (JSC::CCallHelpers::logShadowChickenProloguePacket): (JSC::CCallHelpers::logShadowChickenTailPacket): (JSC::CCallHelpers::ensureShadowChickenPacket): (JSC::CCallHelpers::setupShadowChickenPacket): Deleted. * jit/CCallHelpers.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): (JSC::JIT::emit_op_get_enumerable_length): (JSC::JIT::emit_op_resume): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_profile_type): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/RegisterSet.cpp: (JSC::RegisterSet::webAssemblyCalleeSaveRegisters): (JSC::RegisterSet::argumentGPRS): (JSC::RegisterSet::registersToNotSaveForJSCall): * jit/RegisterSet.h: * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): * runtime/Options.h: * tests/stress/shadow-chicken-enabled.js: (test5a.foo): (test5a): (test5b.foo): (test5b): (test6.foo): (test6): 2016-05-16 Saam barati TypeSet/StructureShape have a flawed sense of JS prototype chains https://bugs.webkit.org/show_bug.cgi?id=157760 Reviewed by Joseph Pecoraro. There was an assumption that we would bottom out in "Object". This is not true for many reasons. JS objects may not end in Object.prototype. Also, our mechanism of grabbing an Object's class name may also not bottom out in "Object". We were seeing this in the JS objects we use in the InjectedScriptSource.js inspector script. * runtime/TypeSet.cpp: (JSC::StructureShape::leastCommonAncestor): * tests/typeProfiler/weird-prototype-chain.js: Added. (wrapper.foo): (wrapper.let.o2): (wrapper): 2016-05-16 Joseph Pecoraro Unreviewed rollout r200924. Caused js/regress/string-replace-generic.html to fail. * API/JSProfilerPrivate.cpp: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h. (JSStartProfiling): (JSEndProfiling): * API/JSProfilerPrivate.h: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor): * bytecode/UnlinkedFunctionExecutable.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitCallVarargs): (JSC::BytecodeGenerator::emitCallVarargsInTailPosition): (JSC::BytecodeGenerator::emitConstructVarargs): (JSC::BytecodeGenerator::emitConstruct): * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::profileHookRegister): (JSC::BytecodeGenerator::shouldEmitProfileHooks): * bytecompiler/NodesCodegen.cpp: (JSC::CallArguments::CallArguments): (JSC::CallFunctionCallDotNode::emitBytecode): (JSC::ApplyFunctionCallDotNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled): * inspector/protocol/Timeline.json: * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::operator()): (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_profile_will_call): (JSC::JIT::emit_op_profile_did_call): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_profile_will_call): (JSC::JIT::emit_op_profile_did_call): * jit/JITOperations.cpp: * jit/JITOperations.h: * jsc.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * parser/ParserModes.h: * profiler/CallIdentifier.h: Added. (JSC::CallIdentifier::CallIdentifier): (JSC::CallIdentifier::functionName): (JSC::CallIdentifier::url): (JSC::CallIdentifier::lineNumber): (JSC::CallIdentifier::columnNumber): (JSC::CallIdentifier::operator==): (JSC::CallIdentifier::operator!=): (JSC::CallIdentifier::Hash::hash): (JSC::CallIdentifier::Hash::equal): (JSC::CallIdentifier::hash): (JSC::CallIdentifier::operator const char*): (JSC::CallIdentifier::c_str): (WTF::HashTraits::constructDeletedValue): (WTF::HashTraits::isDeletedValue): * profiler/LegacyProfiler.cpp: Added. (JSC::LegacyProfiler::profiler): (JSC::LegacyProfiler::startProfiling): (JSC::LegacyProfiler::stopProfiling): (JSC::callFunctionForProfilesWithGroup): (JSC::LegacyProfiler::suspendProfiling): (JSC::LegacyProfiler::unsuspendProfiling): (JSC::LegacyProfiler::willExecute): (JSC::LegacyProfiler::didExecute): (JSC::LegacyProfiler::exceptionUnwind): (JSC::LegacyProfiler::createCallIdentifier): (JSC::createCallIdentifierFromFunctionImp): * profiler/LegacyProfiler.h: Added. (JSC::LegacyProfiler::currentProfiles): * profiler/Profile.cpp: Added. (JSC::Profile::create): (JSC::Profile::Profile): (JSC::Profile::~Profile): (JSC::Profile::debugPrint): (JSC::functionNameCountPairComparator): (JSC::Profile::debugPrintSampleStyle): * profiler/Profile.h: Copied from Source/JavaScriptCore/profiler/ProfilerJettisonReason.h. * profiler/ProfileGenerator.cpp: Added. (JSC::ProfileGenerator::create): (JSC::ProfileGenerator::ProfileGenerator): (JSC::AddParentForConsoleStartFunctor::AddParentForConsoleStartFunctor): (JSC::AddParentForConsoleStartFunctor::foundParent): (JSC::AddParentForConsoleStartFunctor::operator()): (JSC::ProfileGenerator::addParentForConsoleStart): (JSC::ProfileGenerator::title): (JSC::ProfileGenerator::beginCallEntry): (JSC::ProfileGenerator::endCallEntry): (JSC::ProfileGenerator::willExecute): (JSC::ProfileGenerator::didExecute): (JSC::ProfileGenerator::exceptionUnwind): (JSC::ProfileGenerator::stopProfiling): (JSC::ProfileGenerator::removeProfileStart): (JSC::ProfileGenerator::removeProfileEnd): * profiler/ProfileGenerator.h: Added. (JSC::ProfileGenerator::profile): (JSC::ProfileGenerator::origin): (JSC::ProfileGenerator::profileGroup): (JSC::ProfileGenerator::setIsSuspended): * profiler/ProfileNode.cpp: Added. (JSC::ProfileNode::ProfileNode): (JSC::ProfileNode::addChild): (JSC::ProfileNode::removeChild): (JSC::ProfileNode::spliceNode): (JSC::ProfileNode::traverseNextNodePostOrder): (JSC::ProfileNode::debugPrint): (JSC::ProfileNode::debugPrintSampleStyle): (JSC::ProfileNode::debugPrintRecursively): (JSC::ProfileNode::debugPrintSampleStyleRecursively): * profiler/ProfileNode.h: Added. (JSC::ProfileNode::create): (JSC::ProfileNode::Call::Call): (JSC::ProfileNode::Call::startTime): (JSC::ProfileNode::Call::setStartTime): (JSC::ProfileNode::Call::elapsedTime): (JSC::ProfileNode::Call::setElapsedTime): (JSC::ProfileNode::operator==): (JSC::ProfileNode::callerCallFrame): (JSC::ProfileNode::callIdentifier): (JSC::ProfileNode::id): (JSC::ProfileNode::functionName): (JSC::ProfileNode::url): (JSC::ProfileNode::lineNumber): (JSC::ProfileNode::columnNumber): (JSC::ProfileNode::parent): (JSC::ProfileNode::setParent): (JSC::ProfileNode::calls): (JSC::ProfileNode::lastCall): (JSC::ProfileNode::appendCall): (JSC::ProfileNode::children): (JSC::ProfileNode::firstChild): (JSC::ProfileNode::lastChild): (JSC::ProfileNode::nextSibling): (JSC::ProfileNode::setNextSibling): (JSC::ProfileNode::forEachNodePostorder): (JSC::CalculateProfileSubtreeDataFunctor::operator()): (JSC::CalculateProfileSubtreeDataFunctor::returnValue): * profiler/ProfilerJettisonReason.cpp: (WTF::printInternal): * profiler/ProfilerJettisonReason.h: * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): (JSC::CodeCache::getProgramCodeBlock): (JSC::CodeCache::getEvalCodeBlock): (JSC::CodeCache::getModuleProgramCodeBlock): * runtime/CodeCache.h: * runtime/Executable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::~JSGlobalObject): (JSC::JSGlobalObject::hasLegacyProfiler): (JSC::JSGlobalObject::createProgramCodeBlock): (JSC::JSGlobalObject::createEvalCodeBlock): (JSC::JSGlobalObject::createModuleProgramCodeBlock): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::supportsLegacyProfiling): * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::SetEnabledProfilerFunctor::operator()): (JSC::VM::setEnabledProfiler): * runtime/VM.h: (JSC::VM::enabledProfiler): (JSC::VM::enabledProfilerAddress): 2016-05-16 Konstantin Tokarev Unreviewed, fixed typo in a comment. * assembler/MacroAssembler.h: Replaced "onvenience" with "convenience". 2016-05-16 Filip Pizlo FixupPhase should be more eager to demote bit math to untyped https://bugs.webkit.org/show_bug.cgi?id=157746 Reviewed by Mark Lam. This just makes the logic for how we fixup bit math match the way we do it in other places. This doesn't affect performance on any major benchmark but it's a big win on new microbenchmarks added in this change. Details: object-and 11.1610+-0.7602 ^ 4.8105+-0.1690 ^ definitely 2.3201x faster object-or 11.0845+-0.2487 ^ 4.7146+-0.0374 ^ definitely 2.3511x faster object-xor 10.2946+-0.9946 ^ 4.7278+-0.0814 ^ definitely 2.1775x faster object-lshift 10.4896+-1.0867 ^ 4.7699+-0.0721 ^ definitely 2.1991x faster object-rshift 11.1239+-0.5010 ^ 4.7194+-0.0445 ^ definitely 2.3570x faster object-urshift 10.9745+-0.1315 ^ 4.7848+-0.0479 ^ definitely 2.2936x faster * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): 2016-05-15 Michael Saboff RegExp /y flag incorrect handling of mixed-length alternation https://bugs.webkit.org/show_bug.cgi?id=157723 Reviewed by Filip Pizlo. Previously for sticky patterns, we were bailing out and exiting when backtracking alternatives with dissimilar match lengths. Deleted that code. Instead, for sticky patterns we need to process the backtracking except for advancing to the next input index. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::backtrack): 2016-05-15 Filip Pizlo DFG::Plan shouldn't read from its VM once it's been cancelled https://bugs.webkit.org/show_bug.cgi?id=157726 Reviewed by Saam Barati. Plan::vm was a reference, not a pointer, and so wasn't nulled by Plan::cancel(). So, a cancelled plan may have a dangling pointer to a VM: we could delete the VM after cancelling the plan. Prior to http://trac.webkit.org/changeset/200705, this was probably fine because nobody would read Plan::vm if the plan was cancelled. But r200705 changed that. It was a hard regression to spot because usually a cancelled plan will still refer to a valid VM. This change fixes the regression and makes it a lot easier to spot the regression in the future. Plan::vm is now a pointer and we null it in Plan::cancel(). Now if you make this mistake, you will get a crash anytime the Plan is cancelled, not just anytime the plan is cancelled and the VM gets deleted. Also, it's now very clear what to do when you want to use Plan::vm on the cancel path: you can null-check vm; if it's null, assume the worst. Because we null the VM of a cancelled plan, we cannot have Safepoint::vm() return the plan's VM anymore. That's because when we cancel a plan that is at a safepoint, we use the safepoint's VM to determine whether this is one of our safepoints *after* the plan is already cancelled. So, Safepoint now has its own copy of m_vm, and that copy gets nulled when the Safepoint is cancelled. The Safepoint's m_vm will be nulled moments after Plan's vm gets nulled (see Worklist::removeDeadPlans(), which has a cancel path for Plans in one loop and a cancel path for Safepoints in the loop after it). * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::finalizeCommon): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::Plan): (JSC::DFG::Plan::computeCompileTimes): (JSC::DFG::Plan::reportCompileTimes): (JSC::DFG::Plan::compileInThreadImpl): (JSC::DFG::Plan::reallyAdd): (JSC::DFG::Plan::notifyCompiling): (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): (JSC::DFG::Plan::cancel): * dfg/DFGPlan.h: (JSC::DFG::Plan::canTierUpAndOSREnter): * dfg/DFGSafepoint.cpp: (JSC::DFG::Safepoint::cancel): (JSC::DFG::Safepoint::vm): * dfg/DFGSafepoint.h: * dfg/DFGWorklist.cpp: (JSC::DFG::Worklist::isActiveForVM): (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady): (JSC::DFG::Worklist::removeAllReadyPlansForVM): (JSC::DFG::Worklist::rememberCodeBlocks): (JSC::DFG::Worklist::visitWeakReferences): (JSC::DFG::Worklist::removeDeadPlans): (JSC::DFG::Worklist::runThread): * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::finalizeFunction): 2016-05-15 Yusuke Suzuki Modernize Intl constructors; using InternalFunction::createSubclassStructure https://bugs.webkit.org/show_bug.cgi?id=157082 Reviewed by Darin Adler. Previously, Intl constructors retrieve "prototype" to inherit the "new.target". At that time, this mis-assumed that getDirect() always returns meaningful JS value. Actually, it returns an empty value if a property does not exist. Instead of fixing this assertion, we now use InternalFunction::createSubclassStructure in Intl constructors. It is modern and preferable way since it can cache the derived structures in InternalFunction. This patch also cleans up the workaround in Intl.NumberFormat and Intl.DateTimeFormat. Those code are largely duplicate. This is now extracted into constructIntlInstanceWithWorkaroundForLegacyIntlConstructor. This clean up does not have any behavior changes. They are already tested in LayoutTests/js/intl-datetimeformat and LayoutTests/js/intl-numberformat. * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/IntlCollator.cpp: (JSC::IntlCollator::create): * runtime/IntlCollator.h: * runtime/IntlCollatorConstructor.cpp: (JSC::constructIntlCollator): (JSC::callIntlCollator): * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::create): * runtime/IntlDateTimeFormat.h: * runtime/IntlDateTimeFormatConstructor.cpp: (JSC::constructIntlDateTimeFormat): (JSC::callIntlDateTimeFormat): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeGetterFormat): (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions): * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::create): * runtime/IntlNumberFormat.h: * runtime/IntlNumberFormatConstructor.cpp: (JSC::constructIntlNumberFormat): (JSC::callIntlNumberFormat): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototypeGetterFormat): (JSC::IntlNumberFormatPrototypeFuncResolvedOptions): * runtime/IntlObjectInlines.h: Added. (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor): * tests/stress/intl-constructors-with-proxy.js: Added. (shouldBe): (throw.new.Error.Empty): (throw.new.Error): (shouldBe.Empty): 2016-05-14 Joseph Pecoraro Remove LegacyProfiler https://bugs.webkit.org/show_bug.cgi?id=153565 Reviewed by Mark Lam. JavaScriptCore now provides a sampling profiler and it is enabled by all ports. Web Inspector switched months ago to using the sampling profiler and displaying its data. Remove the legacy profiler, as it is no longer being used by anything other then console.profile and tests. We will update console.profile's behavior soon to have new behavior and use the sampling data. * API/JSProfilerPrivate.cpp: Removed. * API/JSProfilerPrivate.h: Removed. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): Deleted. (JSC::computeDefsForBytecodeOffset): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): Deleted. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor): * bytecode/UnlinkedFunctionExecutable.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitCallVarargs): (JSC::BytecodeGenerator::emitCallVarargsInTailPosition): (JSC::BytecodeGenerator::emitConstructVarargs): (JSC::BytecodeGenerator::emitConstruct): * bytecompiler/BytecodeGenerator.h: (JSC::CallArguments::profileHookRegister): Deleted. (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted. * bytecompiler/NodesCodegen.cpp: (JSC::CallFunctionCallDotNode::emitBytecode): (JSC::ApplyFunctionCallDotNode::emitBytecode): (JSC::CallArguments::CallArguments): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): Deleted. * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): Deleted. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): Deleted. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): Deleted. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): Deleted. * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): Deleted. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): Deleted. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): Deleted. * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled): * inspector/protocol/Timeline.json: * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::operator()): Deleted. (JSC::Interpreter::execute): Deleted. (JSC::Interpreter::executeCall): Deleted. (JSC::Interpreter::executeConstruct): Deleted. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): Deleted. * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_profile_will_call): Deleted. (JSC::JIT::emit_op_profile_did_call): Deleted. * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_profile_will_call): Deleted. (JSC::JIT::emit_op_profile_did_call): Deleted. * jit/JITOperations.cpp: * jit/JITOperations.h: * jsc.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted. * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * parser/ParserModes.h: * profiler/CallIdentifier.h: Removed. * profiler/LegacyProfiler.cpp: Removed. * profiler/LegacyProfiler.h: Removed. * profiler/Profile.cpp: Removed. * profiler/Profile.h: Removed. * profiler/ProfileGenerator.cpp: Removed. * profiler/ProfileGenerator.h: Removed. * profiler/ProfileNode.cpp: Removed. * profiler/ProfileNode.h: Removed. * profiler/ProfilerJettisonReason.cpp: (WTF::printInternal): Deleted. * profiler/ProfilerJettisonReason.h: * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): (JSC::CodeCache::getProgramCodeBlock): (JSC::CodeCache::getEvalCodeBlock): (JSC::CodeCache::getModuleProgramCodeBlock): * runtime/CodeCache.h: * runtime/Executable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::createProgramCodeBlock): (JSC::JSGlobalObject::createEvalCodeBlock): (JSC::JSGlobalObject::createModuleProgramCodeBlock): (JSC::JSGlobalObject::~JSGlobalObject): Deleted. (JSC::JSGlobalObject::hasLegacyProfiler): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted. * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::VM): Deleted. (JSC::SetEnabledProfilerFunctor::operator()): Deleted. (JSC::VM::setEnabledProfiler): Deleted. * runtime/VM.h: (JSC::VM::enabledProfiler): Deleted. (JSC::VM::enabledProfilerAddress): Deleted. 2016-05-13 Joseph Pecoraro jsc: samplingProfilerStackTraces() without starting sampling should not cause jsc to crash https://bugs.webkit.org/show_bug.cgi?id=157704 Reviewed by Saam Barati. * jsc.cpp: (functionStartSamplingProfiler): (functionSamplingProfilerStackTraces): Throw an exception instead of crashing if we haven't started sampling. * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::InspectorScriptProfilerAgent::startTracking): * runtime/VM.h: * runtime/VM.cpp: (JSC::VM::ensureSamplingProfiler): Switch ensure to returning a reference, like most other ensures. 2016-05-13 Saam barati DFG/FTL have a few bugs in their reasoning about the scope https://bugs.webkit.org/show_bug.cgi?id=157696 Reviewed by Benjamin Poulain. 1. When the debugger is enabled, it is easier for the DFG to reason about the scope register by simply claiming all nodes read the scope register. This prevents us from ever entering the runtime where we may take a stack trace but there isn't a scope on the stack. 2. This patch fixes a bug where the FTL compilation wasn't properly setting the CodeBlock register. It was only doing this when there was inline data, but when the debugger is enabled, we never inline. So this code just needed to be removed from that loop. It was never right for it to be inside the loop. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * ftl/FTLCompile.cpp: (JSC::FTL::compile): 2016-05-13 Benjamin Poulain [JSC] SetLocal without exit do not need phantoms https://bugs.webkit.org/show_bug.cgi?id=157653 Reviewed by Filip Pizlo. I made a mistake in r200498. If a SetLocal cannot possibly exit, we were not clearing the source of the operand. As a result, we sometime kept a value alive up to the end of the block. That's uncommon because SetLocal typically appear toward the end of blocks. That's probably why there was no perf impact with that fix. * dfg/DFGPhantomInsertionPhase.cpp: 2016-05-13 Benjamin Poulain [JSC] Move the CheckTierUp function calls out of the main path https://bugs.webkit.org/show_bug.cgi?id=157668 Reviewed by Mark Lam. If you have a tiny tiny loop (for example, Sunspider's bits-in-byte), the size of CheckTierUp is a problem. On multi-issue CPUs, the node is so big that we do not get to run anything from the loop in the instruction fetch. On x86, having a bigger loop also pushes us out of the LSD. This is a 6% improvement on bits-in-byte. Other Sunspider tests only improves marginally. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::addSlowPathGenerator): (JSC::DFG::SpeculativeJIT::runSlowPathGenerators): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::silentSpill): (JSC::DFG::SpeculativeJIT::silentFill): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2016-05-13 Benjamin Poulain [JSC] Emit the loads of emitLoadWithStructureCheck() in the order they are used https://bugs.webkit.org/show_bug.cgi?id=157671 Reviewed by Mark Lam. This improves the chances of having a value when issuing the TEST. * jit/JITPropertyAccess.cpp: (JSC::JIT::emitLoadWithStructureCheck): 2016-05-13 Joseph Pecoraro Web Inspector: Inform augmenting client when inspector controller is destroyed https://bugs.webkit.org/show_bug.cgi?id=157688 Reviewed by Timothy Hatcher. * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController): * inspector/augmentable/AugmentableInspectorControllerClient.h: There is a weak relationship between the InspectorController and the AugmentingClient. Let the augmenting client know when the controller is destroyed so it doesn't try to use us anymore. 2016-05-13 Geoffrey Garen Runaway malloc memory usage in this simple JSC program https://bugs.webkit.org/show_bug.cgi?id=157682 Reviewed by Mark Lam. * heap/WeakSet.cpp: (JSC::WeakSet::sweep): Whenever we might add a block to m_logicallyEmptyWeakBlocks, be sure also to sweep a block in m_logicallyEmptyWeakBlocks. Otherwise, additions might outpace removals even when all memory is freed. We do this whenever we *might* add a block and not just whenever we *do* add a block because we'd like to sweep the entries in m_logicallyEmptyWeakBlocks promptly even when it's not growing, and this is a reasonably rate-limited opportunity to do so. 2016-05-13 Mark Lam We should have one calleeSaveRegistersBuffer per VMEntryFrame, not one per VM. https://bugs.webkit.org/show_bug.cgi?id=157537 Reviewed by Michael Saboff. The pre-existing code behaves this way: 1. When JS code throws an exception, it saves callee save registers in the VM calleeSaveRegistersBuffer. These values are meant to be restored to the callee save registers later either at the catch handler or at the uncaught exception handler. 2. If the Inspector is enable, the VM will invoke inspector C++ code to inspect the exception. That C++ code can change the values of the callee save registers. The inspector code in turn re-enters the VM to execute JS inspector code. The JS inspector code can run hot enough that we do an enterOptimizationCheck on it. The enterOptimizationCheck first saves all callee save registers into the VM calleeSaveRegistersBuffer. This effectively overwrites the values in the VM calleeSaveRegistersBuffer from (1). 3. Eventually, execution returns to the catch handler or the uncaught exception handler which restores the overwritten values in the VM calleeSaveRegistersBuffer to the callee save registers. When execution returns to the C++ code that entered the VM before (1), the values in the callee registers are not what that code expects, and badness and/or crashes ensues. This patch applies the following fix: 1. Allocate space in the VMEntryFrame for the calleeSaveRegistersBuffer. This ensures that each VM entry session has its own buffer to use, and will not corrupt the one from the previous VM entry session. Delete the VM calleeSaveRegistersBuffer. 2. Change all locations that uses the VM calleeSaveRegistersBuffer to use the calleeSaveRegistersBuffer in the current VMEntryFrame. 3. Renamed all uses of the term "VMCalleeSavesBuffer" to "VMEntryFrameCalleeSavesBuffer". This fix has been tested on the following configurations: 1. JSC and layout tests on a debug ASan build for 64-bit x86_64. 2. JSC tests on a release ASan build for 32-bit x86. 3. JSC tests on a release normal (non-ASan) build for ARM64. 4. JSC tests on a release normal (non-ASan) build for ARMv7 and ARMv7s. 5. JSC tests on a release ASan CLOOP build for x86_64. These test runs did not produce any new crashes. The ASan CLOOP has some pre-existing crashes which are not due to this patch. This bug can be tested by running the inspector/debugger/regress-133182.html test on an ASan build. * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationState::emitExplicitExceptionHandler): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileExceptionHandlers): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGThunks.cpp: (JSC::DFG::osrEntryThunkGenerator): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::operator()): (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer): Deleted. * interpreter/Interpreter.h: (JSC::NativeCallFrameTracer::NativeCallFrameTracer): * interpreter/VMEntryRecord.h: (JSC::VMEntryRecord::calleeSaveRegistersBufferOffset): (JSC::VMEntryRecord::prevTopCallFrame): (JSC::VMEntryRecord::unsafePrevTopCallFrame): (JSC::VMEntryFrame::vmEntryRecordOffset): (JSC::VMEntryFrame::calleeSaveRegistersBufferOffset): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitRandomThunk): (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer): Deleted. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters): (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer): Deleted. (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer): Deleted. * jit/JIT.cpp: (JSC::JIT::emitEnterOptimizationCheck): (JSC::JIT::privateCompileExceptionHandlers): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_catch): (JSC::JIT::emitSlow_op_loop_hint): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_catch): * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::nativeForGenerator): * llint/LLIntThunks.cpp: (JSC::vmEntryRecord): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/VM.h: (JSC::VM::getCTIStub): (JSC::VM::calleeSaveRegistersBufferOffset): Deleted. * wasm/WASMFunctionCompiler.h: (JSC::WASMFunctionCompiler::endFunction): 2016-05-13 Beth Dakin Add dyldSPI.h for linked on or after checks, and add one for link preview https://bugs.webkit.org/show_bug.cgi?id=157401 -and corresponding- rdar://problem/26253396 Reviewed by Darin Adler. Import #import which now declares all of the needed dyld code. * API/JSWrapperMap.mm: 2016-05-13 Yusuke Suzuki Assertion failure for direct eval in non-class method https://bugs.webkit.org/show_bug.cgi?id=157138 Reviewed by Saam Barati. This assertion was incorrect. In method definitions in object literals, it can be sloppy mode, but its DerivedContextType may not be DerivedContextType::None. * bytecode/EvalCodeCache.h: (JSC::EvalCodeCache::CacheKey::CacheKey): (JSC::EvalCodeCache::CacheKey::operator==): (JSC::EvalCodeCache::CacheKey::Hash::equal): (JSC::EvalCodeCache::tryGet): (JSC::EvalCodeCache::getSlow): * interpreter/Interpreter.cpp: (JSC::eval): * tests/stress/direct-eval-in-object-literal-methods.js: Added. (shouldBe): (throw.new.Error): (shouldBe.Parent.prototype.l): (shouldBe.Parent): (shouldBe.Derived.prototype.m): (shouldBe.Derived): 2016-05-13 Skachkov Oleksandr Assertion failure for super() call in arrow function default parameters https://bugs.webkit.org/show_bug.cgi?id=157079 Reviewed by Saam Barati. Root of the issue that in arrow function we load bounded variables this/super/new.target just after input parameters were initialized, and did not covered case of default values for function parameters. Current patch tried to fix issue and allow to load bounded variables earlier, before the input parameters are assigned by default values. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * tests/stress/arrowfunction-lexical-bind-this-2.js: 2016-05-12 Mark Lam Baseline and DFG's JSC_report...CompileTimes needs CodeBlock hashes. https://bugs.webkit.org/show_bug.cgi?id=157643 Reviewed by Keith Miller. * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2016-05-12 Csaba Osztrogonác Remove ENABLE(ES6_ARROWFUNCTION_SYNTAX) guards https://bugs.webkit.org/show_bug.cgi?id=157564 Reviewed by Darin Adler. * Configurations/FeatureDefines.xcconfig: * parser/Parser.cpp: 2016-05-12 Joseph Pecoraro Web Inspector: CRASH getting internal properties of function with no bound arguments causes https://bugs.webkit.org/show_bug.cgi?id=157613 Reviewed by Timothy Hatcher. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::getInternalProperties): Gracefully handle a JSBoundFunction with no bound arguments. In this case boundArgs is JSValue() which we don't want to expose as the value of the internal property. 2016-05-11 Benjamin Poulain [JSC] Make sure StringRange is passed to Vector by register https://bugs.webkit.org/show_bug.cgi?id=157603 Reviewed by Darin Adler. This is bizarre, but on my SDK, Vector::append(StringRange) is passing the values on the stack. The two integers are written to the stack, the address given to append(), then append() reads it back and store it. This patch changes the code to use constructAndAppend(), ensuring the values are used directly. On my machine, this helps Sunspider and Octane. This might be something wrong with my SDK but the fix is so easy that we might as well do this. * runtime/StringPrototype.cpp: (JSC::removeUsingRegExpSearch): (JSC::replaceUsingRegExpSearch): 2016-05-11 Zan Dobersek ARMv7Assembler: suppress a -Wnarrowing warning when compiling with GCC https://bugs.webkit.org/show_bug.cgi?id=157576 Reviewed by Csaba Osztrogonác. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2): Explicitly cast the `OP_CMP_reg_T2 | left` value to uint16_t, avoiding a narrowing conversion warning that's being reported when compiling with GCC. The warning is sprung due to RegisterID (which is the type of `left`) being an enum based on int, even when the enum itself only declares 23 values. 2016-05-11 Joseph Pecoraro Web Inspector: `this` in Scope Chain Sidebar does not have preview, looks poor https://bugs.webkit.org/show_bug.cgi?id=157602 Reviewed by Timothy Hatcher. * inspector/InjectedScriptSource.js: (InjectedScript.CallFrameProxy): Include a preview when creating the RemoteObject for `this`. 2016-05-11 Keith Miller Unreviewed, correct the title of the ChangeLog for r200667. 2016-05-11 Joseph Pecoraro JSC test stress/reflect-set.js failing after 200694 https://bugs.webkit.org/show_bug.cgi?id=157586 Unreviewed test rebaseline. * tests/stress/reflect-set.js: Update the expected error message. We are in strict mode, so the improved error message makes sense. 2016-05-11 Filip Pizlo Beef up JSC profiler event log https://bugs.webkit.org/show_bug.cgi?id=157584 Reviewed by Saam Barati. Also log more about compilation. * bytecode/ExecutionCounter.cpp: Changed the meaning of codeBlock to be the codeBlock that is doing the profiling. This will now get the baseline version if it needs it. This is needed for logging the threshold checking event. (JSC::applyMemoryUsageHeuristics): (JSC::ExecutionCounter::hasCrossedThreshold): * dfg/DFGJITCode.cpp: Pass the right codeBlock. (JSC::DFG::JITCode::checkIfOptimizationThresholdReached): (JSC::DFG::JITCode::optimizeNextInvocation): (JSC::DFG::JITCode::dontOptimizeAnytimeSoon): (JSC::DFG::JITCode::optimizeSoon): (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently): * dfg/DFGPlan.cpp: Log things about compile times and whether the compiler succeeded or failed. (JSC::DFG::Plan::computeCompileTimes): (JSC::DFG::Plan::reportCompileTimes): (JSC::DFG::Plan::compileInThread): (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): * jit/ExecutableAllocatorFixedVMPool.cpp: Make it possible to look at memory usage, though separately from the log, for now. (JSC::ExecutableAllocator::allocate): * runtime/Options.h: 2016-05-11 Saam barati Air may decide to put the result register of an arithmetic snippet in the tag register https://bugs.webkit.org/show_bug.cgi?id=157548 Reviewed by Filip Pizlo. This patch adds a new ValueRep to B3 called LateRegister. The semantics are similar to Register in that it can be used to pin an argument to a particular register. It differs from ValueRep::Register in that the semantics of LateRegister are that it is used after the result of the node its an argument to is computed. This means that a LateRegister argument will interfere with the result of a node. LateRegister is not a valid result ValueRep. This was needed because there was a bug where B3/Air would assign the result of a patchpoint to the TagTypeNumber register. This broke our code when we would box a double into a JSValue in a snippet when the result is the same as the TagTypeNumber register. To fix the issue, we pass TagMaskRegister and TagTypeNumberRegister as ValueRep::LateRegister arguments to various patchpoints. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::fillStackmap): * 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): (JSC::B3::ValueRep::dump): (JSC::B3::ValueRep::emitRestore): (JSC::B3::ValueRep::recoveryForJSValue): (WTF::printInternal): * b3/B3ValueRep.h: (JSC::B3::ValueRep::reg): (JSC::B3::ValueRep::lateReg): (JSC::B3::ValueRep::stack): (JSC::B3::ValueRep::operator==): (JSC::B3::ValueRep::isSomeRegister): (JSC::B3::ValueRep::isReg): * b3/testb3.cpp: (JSC::B3::testSpillUseLargerThanDef): (JSC::B3::testLateRegister): (JSC::B3::zero): (JSC::B3::run): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::compileIn): (JSC::FTL::DFG::LowerDFGToB3::getById): (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet): (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet): (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet): 2016-05-11 Joseph Pecoraro Improve error messages for accessing arguments.callee and similar getters in strict mode https://bugs.webkit.org/show_bug.cgi?id=157545 Reviewed by Mark Lam. * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::getOwnPropertySlot): (JSC::ClonedArguments::materializeSpecials): Provide better error GetterSetter in strict mode. * runtime/JSFunction.cpp: (JSC::getThrowTypeErrorGetterSetter): (JSC::JSFunction::defineOwnProperty): Provide better error GetterSetter in strict mode. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::throwTypeErrorGetterSetter): (JSC::JSGlobalObject::throwTypeErrorCalleeAndCallerGetterSetter): (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInStrictModeGetterSetter): (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInClassContextGetterSetter): (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter): Deleted. * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncThrowTypeErrorCalleeAndCaller): (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInStrictMode): (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInClassContext): (JSC::globalFuncThrowTypeErrorArgumentsAndCaller): Deleted. * runtime/JSGlobalObjectFunctions.h: Rename and expose new handles for new error getter setter native functions. 2016-05-11 Commit Queue Unreviewed, rolling out r200481. https://bugs.webkit.org/show_bug.cgi?id=157573 it's bad news for asm.js (Requested by pizlo on #webkit). Reverted changeset: "Reduce maximum JIT pool size on X86_64." http://trac.webkit.org/changeset/200481 2016-05-10 Keith Miller TypedArray.prototype.slice should not use the byteLength of the passed array for memmove https://bugs.webkit.org/show_bug.cgi?id=157551 Reviewed by Michael Saboff. The TypedArray.prototype.slice function would use the byteLength of the passed array to determine the amount of data to copy. It should have been using the passed length times the size of each element. This fixes a crash on JavaPoly.com * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::set): * tests/stress/typedarray-slice.js: 2016-05-10 Michael Saboff REGRESSION(r200447): Unable to build C_LOOP with clang version 800.0.12 or higher https://bugs.webkit.org/show_bug.cgi?id=157549 Reviewed by Keith Miller. Disable debug annotations for C_LOOP builds. They are inline assembly directives, unnecessary and they cause syntax errors. * offlineasm/asm.rb: 2016-05-10 Filip Pizlo Internal JSC profiler should have a timestamped log of events for each code block https://bugs.webkit.org/show_bug.cgi?id=157538 Reviewed by Benjamin Poulain. For example, in 3d-cube, I can query the events for MMulti and I get: 1462917476.17083 MMulti#DTZ7qc installCode 1462917476.179663 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode 1462917476.179664 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline osrEntry at bc#49 1462917476.185651 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1011.214233/1717.000000, -707 1462917476.187913 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG installCode 1462917476.187917 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG osrEntry at bc#49 1462917476.205365 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG jettison due to OSRExit, counting = true, detail = (null) 1462917476.205368 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit bc#65: BadCache/FromDFG 1462917476.205369 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode 1462917476.205482 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/3434.000000, -1000 1462917476.211547 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/3434.000000, -1000 1462917476.213721 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG installCode 1462917476.213726 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG osrEntry at bc#49 1462917476.223976 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG jettison due to OSRExit, counting = true, detail = (null) 1462917476.223981 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit bc#77: BadCache/FromDFG 1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit bc#94: BadCache/FromDFG 1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode 1462917476.224064 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/6868.000000, -1000 1462917476.224151 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/6868.000000, -1000 1462917476.224258 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 3013.000000/6868.000000, -1000 1462917476.224337 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 4023.000000/6868.000000, -1000 1462917476.224425 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 5023.000000/6868.000000, -1000 1462917476.224785 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 6023.396484/6868.000000, -862 1462917476.227669 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG installCode 1462917476.227675 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG osrEntry at bc#0 The output is ugly but useful. We can make it less ugly later. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::jettison): * bytecode/CodeBlock.h: (JSC::ScriptExecutable::forEachCodeBlock): * bytecode/DFGExitProfile.cpp: (JSC::DFG::ExitProfile::add): * dfg/DFGJITFinalizer.cpp: (JSC::DFG::JITFinalizer::finalizeCommon): * dfg/DFGOperations.cpp: * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::finalizeFunction): * jit/JIT.cpp: (JSC::JIT::privateCompile): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::jitCompileAndSetHeuristics): (JSC::LLInt::entryOSR): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * profiler/ProfilerCompilation.cpp: (JSC::Profiler::Compilation::Compilation): (JSC::Profiler::Compilation::setJettisonReason): (JSC::Profiler::Compilation::dump): (JSC::Profiler::Compilation::toJS): * profiler/ProfilerCompilation.h: (JSC::Profiler::Compilation::uid): * profiler/ProfilerDatabase.cpp: (JSC::Profiler::Database::ensureBytecodesFor): (JSC::Profiler::Database::notifyDestruction): (JSC::Profiler::Database::addCompilation): (JSC::Profiler::Database::toJS): (JSC::Profiler::Database::registerToSaveAtExit): (JSC::Profiler::Database::logEvent): (JSC::Profiler::Database::addDatabaseToAtExit): * profiler/ProfilerDatabase.h: * profiler/ProfilerEvent.cpp: Added. (JSC::Profiler::Event::dump): (JSC::Profiler::Event::toJS): * profiler/ProfilerEvent.h: Added. (JSC::Profiler::Event::Event): (JSC::Profiler::Event::operator bool): (JSC::Profiler::Event::time): (JSC::Profiler::Event::bytecodes): (JSC::Profiler::Event::compilation): (JSC::Profiler::Event::summary): (JSC::Profiler::Event::detail): * profiler/ProfilerUID.cpp: Added. (JSC::Profiler::UID::create): (JSC::Profiler::UID::dump): (JSC::Profiler::UID::toJS): * profiler/ProfilerUID.h: Added. (JSC::Profiler::UID::UID): (JSC::Profiler::UID::fromInt): (JSC::Profiler::UID::toInt): (JSC::Profiler::UID::operator==): (JSC::Profiler::UID::operator!=): (JSC::Profiler::UID::operator bool): (JSC::Profiler::UID::isHashTableDeletedValue): (JSC::Profiler::UID::hash): (JSC::Profiler::UIDHash::hash): (JSC::Profiler::UIDHash::equal): * runtime/CommonIdentifiers.h: * runtime/Executable.cpp: (JSC::ScriptExecutable::installCode): * runtime/VM.h: (JSC::VM::bytecodeIntrinsicRegistry): (JSC::VM::shadowChicken): * runtime/VMInlines.h: (JSC::VM::shouldTriggerTermination): (JSC::VM::logEvent): 2016-05-10 Joseph Pecoraro Web Inspector: Backend should initiate timeline recordings on page navigations to ensure nothing is missed https://bugs.webkit.org/show_bug.cgi?id=157504 Reviewed by Brian Burg. * inspector/protocol/Timeline.json: Add protocol commands to enable/disable auto capture and list the instruments that should be enabled when auto capture starts. Add protocol event for when the backend starts an auto capture. 2016-05-10 Joseph Pecoraro Make the different evaluateWithScopeExtension implementations more consistent https://bugs.webkit.org/show_bug.cgi?id=157536 Reviewed by Timothy Hatcher. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension): Throw the exception consistent with JSJavaScriptCallFrame. * inspector/JSJavaScriptCallFrame.cpp: (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension): Better error message consistent with InjectedScriptHost. * runtime/Completion.h: * runtime/Completion.cpp: (JSC::evaluateWithScopeExtension): Give this an Exception out parameter like other evaluations so the caller can decide what to do with it. 2016-05-10 Benjamin Poulain [JSC] FTL can produce GetByVal nodes without proper bounds checking https://bugs.webkit.org/show_bug.cgi?id=157502 rdar://problem/26027027 Reviewed by Filip Pizlo. It was possible for FTL to generates GetByVal on arbitrary offsets without any bounds checking. The bug is caused by the order of optimization phases: -First, the Integer Range Optimization proves that a CheckInBounds test can never fail. This proof is based on control flow or preceeding instructions inside a loop. -The Loop Invariant Code Motion phase finds that the GetByVal does not depend on anything in the loop and hoist it out of the loop. -> As a result, the conditions that were necessary to eliminate the CheckInBounds are no longer met before the GetByVal. This patch just moves the Integer Range Optimization phase after Loop Invariant Code Motion to make sure no code is moved after its integer ranges bounds proofs have been used. * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * tests/stress/bounds-check-not-eliminated-by-licm.js: Added. (testInLoopTests): 2016-05-10 Joseph Pecoraro Web Inspector: Eliminate the crazy code for evaluateOnCallFrame https://bugs.webkit.org/show_bug.cgi?id=157510 Reviewed by Timothy Hatcher. * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::evaluateWithScopeExtension): Set and clear an optional scope extension object. * inspector/InjectedScriptSource.js: (InjectedScript.prototype.evaluate): (InjectedScript.prototype._evaluateOn): (InjectedScript.prototype.evaluateOnCallFrame): Unify the code to use the passed in evaluate function and object. When evaluating on a call frame the evaluate function ends up being DebuggerCallFrame::evaluateWithScopeExtension. When evaluating globally this ends up being JSInjectedScriptHost::evaluateWithScopeExtension. In both cases "object" is the preferred this object to use. * debugger/DebuggerCallFrame.h: * inspector/JSJavaScriptCallFrame.cpp: (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension): (Inspector::JSJavaScriptCallFrame::evaluate): Deleted. * inspector/JSJavaScriptCallFrame.h: * inspector/JSJavaScriptCallFramePrototype.cpp: (Inspector::JSJavaScriptCallFramePrototype::finishCreation): (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension): * inspector/JavaScriptCallFrame.h: (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension): (Inspector::JavaScriptCallFrame::evaluate): Deleted. Pass through to DebuggerCallFrame with the proper arguments. * debugger/Debugger.cpp: (JSC::Debugger::hasBreakpoint): * inspector/ScriptDebugServer.cpp: (Inspector::ScriptDebugServer::evaluateBreakpointAction): Use the new evaluate on call frame method name and no scope extension object. 2016-05-10 Saam barati Make super-property-access.js test run for less time because it was timing out in debug builds. Rubber stamped by Filip Pizlo. * tests/stress/super-property-access.js: (test): (test.value): (test.foo): (test.B.prototype.bar): (test.B): 2016-05-10 Csaba Osztrogonác [JSC] Fix the !ENABLE(DFG_JIT) build https://bugs.webkit.org/show_bug.cgi?id=157512 Reviewed by Mark Lam. * jit/Repatch.cpp: 2016-05-09 Joseph Pecoraro Web Inspector: CRASH under JSC::DebuggerCallFrame::thisValue when hitting breakpoint https://bugs.webkit.org/show_bug.cgi?id=157442 Reviewed by Saam Barati. * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::thisValueForCallFrame): When the thisValue is JSValue() return undefined and avoid calling toThisValue which would lead to a crash. Having `this` be an empty JSValue could happen inside an ES6 class constructor, before calling super. 2016-05-09 Filip Pizlo Unreviewed, fix cloop. * bytecode/ValueProfile.cpp: (JSC::ResultProfile::emitDetectNumericness): (JSC::ResultProfile::emitSetNonNumber): * bytecode/ValueProfile.h: (JSC::ResultProfile::addressOfFlags): (JSC::ResultProfile::addressOfSpecialFastPathCount): (JSC::ResultProfile::detectNumericness): (JSC::ResultProfile::hasBits): 2016-05-09 Michael Saboff Crash beneath ObjCCallbackFunctionImpl::call https://bugs.webkit.org/show_bug.cgi?id=157491 Reviewed by Saam Barati. Clear any exceptions after the micro task runs. Tried creating a test case, but I don't have source for the app. I can't seem to find the right combination of Promises and ObjC code. * runtime/JSJob.cpp: (JSC::JSJobMicrotask::run): 2016-05-09 Filip Pizlo Polymorphic operands in operators coerces downstream values to double. https://bugs.webkit.org/show_bug.cgi?id=151793 Reviewed by Mark Lam. Previously if an object flowed into arithmetic, the prediction propagation phase would either assume that the output of the arithmetic had to be double or sometimes it would assume that it couldn't be double. We want it to only assume that the output is double if it actually had been. The first part of this patch is to roll out http://trac.webkit.org/changeset/200502. That removed some of the machinery that we had in place to detect whether the output of an operation is int or double. That changeset claimed that the machinery was "fundamentally broken". It actually wasn't. The reason why it didn't work was that ByteCodeParser was ignoring it if likelyToTakeSlowCase was false. I think this was a complete goof-up: the code in ByteCodeParser::makeSafe was structured in a way that made it non-obvious that the method is a no-op if !likelyToTakeSlowCase. So, this change rolls out r200502 and makes ResultProfile do its job by reshaping how makeSafe processes it. This also makes two other changes to shore up ResultProfile: - OSR exit can now refine a ResultProfile the same way that it refines ValueProfile. - Baseline JIT slow paths now set bits in ResultProfile. Based on this stuff, the DFG now predicts int/double/string in op_add/op_sub/op_mul based on ResultProfiles. To be conservative, we still only use the ResultProfiles if the incoming prediction is not number-or-boolean. This ensures that we exactly retain our old behavior in those cases for which it was tuned. But I hope to remove this soon. I believe that ResultProfile is already strictly better than what prediction propagation was doing before. This can be an enormous win. This patch adds some simple microbenchmarks that demonstrate the problem of assuming that arithmetic on objects returns double. The most extreme of these speeds up 8x with this change (object-int-add-array). * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.h: (JSC::CodeBlock::addFrequentExitSite): (JSC::CodeBlock::hasExitSite): * bytecode/DFGExitProfile.cpp: (JSC::DFG::FrequentExitSite::dump): (JSC::DFG::ExitProfile::ExitProfile): (JSC::DFG::ExitProfile::~ExitProfile): (JSC::DFG::ExitProfile::add): * bytecode/DFGExitProfile.h: (JSC::DFG::FrequentExitSite::isHashTableDeletedValue): * bytecode/MethodOfGettingAValueProfile.cpp: (JSC::MethodOfGettingAValueProfile::fromLazyOperand): (JSC::MethodOfGettingAValueProfile::emitReportValue): (JSC::MethodOfGettingAValueProfile::getSpecFailBucket): Deleted. * bytecode/MethodOfGettingAValueProfile.h: (JSC::MethodOfGettingAValueProfile::MethodOfGettingAValueProfile): (JSC::MethodOfGettingAValueProfile::operator bool): (JSC::MethodOfGettingAValueProfile::operator!): Deleted. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generateImpl): * bytecode/ValueProfile.cpp: (JSC::ResultProfile::emitDetectBitsLight): (JSC::ResultProfile::emitSetDouble): (JSC::ResultProfile::emitSetNonNumber): (WTF::printInternal): * bytecode/ValueProfile.h: (JSC::ResultProfile::ResultProfile): (JSC::ResultProfile::bytecodeOffset): (JSC::ResultProfile::specialFastPathCount): (JSC::ResultProfile::didObserveNonInt32): (JSC::ResultProfile::didObserveDouble): (JSC::ResultProfile::didObserveNonNegZeroDouble): (JSC::ResultProfile::didObserveNegZeroDouble): (JSC::ResultProfile::didObserveNonNumber): (JSC::ResultProfile::didObserveInt32Overflow): (JSC::ResultProfile::didObserveInt52Overflow): (JSC::ResultProfile::setObservedNonNegZeroDouble): (JSC::ResultProfile::setObservedNegZeroDouble): (JSC::ResultProfile::setObservedNonNumber): (JSC::ResultProfile::setObservedInt32Overflow): (JSC::ResultProfile::addressOfFlags): (JSC::ResultProfile::addressOfSpecialFastPathCount): (JSC::ResultProfile::detectBitsLight): (JSC::ResultProfile::hasBits): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::ensureNaturalLoops): (JSC::DFG::Graph::methodOfGettingAValueProfileFor): (JSC::DFG::Graph::valueProfileFor): Deleted. * dfg/DFGGraph.h: (JSC::DFG::Graph::hasExitSite): (JSC::DFG::Graph::numBlocks): * dfg/DFGNode.h: (JSC::DFG::Node::arithNodeFlags): (JSC::DFG::Node::mayHaveNonIntResult): (JSC::DFG::Node::mayHaveDoubleResult): (JSC::DFG::Node::mayHaveNonNumberResult): (JSC::DFG::Node::hasConstantBuffer): * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): * dfg/DFGNodeFlags.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchIfEqual): (JSC::AssemblyHelpers::branchIfNotCell): (JSC::AssemblyHelpers::branchIfNotNumber): (JSC::AssemblyHelpers::branchIfNotDoubleKnownNotInt32): (JSC::AssemblyHelpers::branchIfBoolean): (JSC::AssemblyHelpers::branchIfEmpty): (JSC::AssemblyHelpers::branchStructure): * jit/CCallHelpers.h: (JSC::CCallHelpers::CCallHelpers): (JSC::CCallHelpers::setupArguments): (JSC::CCallHelpers::setupArgumentsWithExecState): * jit/IntrinsicEmitter.cpp: (JSC::AccessCase::emitIntrinsicGetter): * jit/JIT.h: * jit/JITAddGenerator.cpp: (JSC::JITAddGenerator::generateFastPath): * jit/JITAddGenerator.h: (JSC::JITAddGenerator::JITAddGenerator): * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_add): (JSC::JIT::emitSlow_op_add): (JSC::JIT::emit_op_div): (JSC::JIT::emit_op_mul): (JSC::JIT::emitSlow_op_mul): (JSC::JIT::emit_op_sub): (JSC::JIT::emitSlow_op_sub): * jit/JITInlines.h: (JSC::JIT::callOperation): (JSC::JIT::callOperationNoExceptionCheck): * jit/JITMulGenerator.cpp: (JSC::JITMulGenerator::generateFastPath): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITSubGenerator.cpp: (JSC::JITSubGenerator::generateFastPath): * jit/JITSubGenerator.h: (JSC::JITSubGenerator::JITSubGenerator): * jit/TagRegistersMode.cpp: Added. (WTF::printInternal): * jit/TagRegistersMode.h: Added. * runtime/CommonSlowPaths.cpp: (JSC::updateResultProfileForBinaryArithOp): 2016-05-09 Keith Miller CallObjectConstructor should not call operationToThis in the FTL https://bugs.webkit.org/show_bug.cgi?id=157492 Reviewed by Mark Lam. At some point when I was working on intrinsifying the Object constructor, I realized that the Object constructor was different from the ToObject operation. I fixed the DFG but I guess I didn't fix the FTL. This patch fixes an issue with www.wunderground.com not loading the 10-day forecast and local map. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): * tests/stress/call-object-constructor.js: Added. (test): (assert): 2016-05-09 Saam barati Getter and setter on super are called with wrong "this" object https://bugs.webkit.org/show_bug.cgi?id=147064 Reviewed by Filip Pizlo. This patch implements calls to 'super' getters and setters. The problem before is we were passing the 'super' (i.e, the prototype object) as the this value to these getters/setters, which is wrong. We should be passing the caller's this value. To implement this behavior, I've introduced four new opcodes and their corresponding DFG nodes: - op_get_by_id_with_this | GetByIdWithThis - op_put_by_id_with_this | PutByIdWithThis - op_get_by_val_with_this | GetByValWithThis - op_put_by_val_with_this | PutByValWithThis These are implemented with no optimizations. The future plan is to unite them with the *by_id and *by_val opcodes and nodes: https://bugs.webkit.org/show_bug.cgi?id=157215 * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitGetById): (JSC::BytecodeGenerator::emitPutById): (JSC::BytecodeGenerator::emitDirectPutById): (JSC::BytecodeGenerator::emitGetByVal): (JSC::BytecodeGenerator::emitPutByVal): (JSC::BytecodeGenerator::emitDirectPutByVal): (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::ensureThis): (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::ThisNode::emitBytecode): (JSC::emitHomeObjectForCallee): (JSC::emitSuperBaseForCallee): (JSC::emitGetSuperFunctionForConstruct): (JSC::SuperNode::emitBytecode): (JSC::NewTargetNode::emitBytecode): (JSC::TaggedTemplateNode::emitBytecode): (JSC::BracketAccessorNode::emitBytecode): (JSC::DotAccessorNode::emitBytecode): (JSC::FunctionCallValueNode::emitBytecode): (JSC::FunctionCallBracketNode::emitBytecode): (JSC::FunctionCallDotNode::emitBytecode): (JSC::CallFunctionCallDotNode::emitBytecode): (JSC::ApplyFunctionCallDotNode::emitBytecode): (JSC::PostfixNode::emitBracket): (JSC::PostfixNode::emitDot): (JSC::PrefixNode::emitBracket): (JSC::PrefixNode::emitDot): (JSC::AssignDotNode::emitBytecode): (JSC::ReadModifyDotNode::emitBytecode): (JSC::AssignBracketNode::emitBytecode): (JSC::ReadModifyBracketNode::emitBytecode): (JSC::ForInNode::emitLoopHeader): (JSC::ForOfNode::emitBytecode): (JSC::AssignmentElementNode::bindValue): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasIdentifier): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: (JSC::DFG::newTypedArrayWithSize): (JSC::DFG::putWithThis): * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileGetById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis): (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis): (JSC::FTL::DFG::LowerDFGToB3::compilePutById): * jit/CCallHelpers.cpp: (JSC::CCallHelpers::setupShadowChickenPacket): (JSC::CCallHelpers::setupFourStubArgsGPR): * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsWithExecState): (JSC::CCallHelpers::setupThreeStubArgsGPR): (JSC::CCallHelpers::setupTwoStubArgsFPR): (JSC::CCallHelpers::setupStubArguments134): * jit/GPRInfo.h: (JSC::argumentRegisterFor): Deleted. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emit_op_put_by_val_with_this): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emit_op_get_by_val_with_this): (JSC::JIT::emitSlow_op_get_by_id): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emit_op_put_by_id_with_this): (JSC::JIT::emitSlow_op_put_by_id): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_put_to_arguments): (JSC::JIT::emit_op_get_by_id_with_this): (JSC::JIT::emit_op_get_by_val_with_this): (JSC::JIT::emit_op_put_by_id_with_this): (JSC::JIT::emit_op_put_by_val_with_this): * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * tests/stress/super-property-access-exceptions.js: Added. (assert): (test): (test.fooProp): (test.A.prototype.get foo): (test.A.prototype.get x): (test.A): (test.B): (test.B.prototype.bar): (test.B.prototype.baz): (test.foo): (test.func): (test.A.prototype.set foo): * tests/stress/super-property-access-tdz.js: Added. (assert): (test): (shouldThrowTDZ): (test.A.prototype.get foo): (test.A.prototype.set foo): (test.A): (test.fooProp): (test.B): (test.C): (test.D): (test.E): (test.F): * tests/stress/super-property-access.js: Added. (assert): (test): (func): (test.A): (test.A.prototype.set value): (test.A.prototype.get value): (test.B.prototype.set value): (test.B.prototype.get value): (test.B): (test.value): (test.A.prototype.get func): (test.B.prototype.inc): (test.B.prototype.dec): (test.B.prototype.preInc): (test.B.prototype.preDec): (test.B.prototype.plusEq): (test.B.prototype.minusEq): (test.B.prototype.timesEq): (test.B.prototype.divEq): (test.B.prototype.funcDot): (test.B.prototype.funcBracket): (test.foo): (test.B.prototype.baz): (test.B.prototype.jaz): (test.B.prototype.bar): (test.B.prototype.index): (test.): (test.prototype.bar): (test.A.prototype.set foo): (test.A.prototype.get array): (test.A.prototype.get foo): (test.obj): (test.A.prototype.get call): (test.A.prototype.get apply): (test.B.prototype.foo): (test.A.prototype.get i): 2016-05-08 Chris Dumez [COCOA] Disable HAVE_DTRACE at build time https://bugs.webkit.org/show_bug.cgi?id=157433 Reviewed by Mark Lam. Drop DTRACE-related code from JSC since it is very old and seems unused. * JavaScriptCore.xcodeproj/project.pbxproj: * PlatformMac.cmake: * heap/Heap.cpp: (JSC::Heap::collectImpl): Deleted. (JSC::Heap::didFinishCollection): Deleted. * profiler/ProfileGenerator.cpp: (JSC::ProfileGenerator::willExecute): Deleted. (JSC::ProfileGenerator::didExecute): Deleted. * runtime/Tracing.d: Removed. * runtime/Tracing.h: Removed. 2016-05-07 Mark Lam Add JSC options bytecodeRangeToJITCompile and jitWhitelist. https://bugs.webkit.org/show_bug.cgi?id=157428 Reviewed by Michael Saboff. 1. Added Options::bytecodeRangeToJITCompile and Options::jitWhitelist options. 2. Moved DFGFunctionWhitelist* to FunctionWhitelist* and made it generic so that it can be used for more than one whitelist instance. In this case, we now have two: the dfgWhitelist and the jitWhitelist. 3. Added "can compile" checks in LLInt::shouldJIT() to check Options::bytecodeRangeToJITCompile and Options::jitWhitelist. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGDriver.cpp: (JSC::DFG::getNumCompilations): (JSC::DFG::ensureGlobalDFGWhitelist): (JSC::DFG::compileImpl): * dfg/DFGFunctionWhitelist.cpp: Removed. * dfg/DFGFunctionWhitelist.h: Removed. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::ensureGlobalJITWhitelist): (JSC::LLInt::shouldJIT): * runtime/Options.h: * tools/FunctionWhitelist.cpp: Copied from Source/JavaScriptCore/dfg/DFGFunctionWhitelist.cpp. (JSC::FunctionWhitelist::FunctionWhitelist): (JSC::FunctionWhitelist::contains): (JSC::DFG::FunctionWhitelist::ensureGlobalWhitelist): Deleted. (JSC::DFG::FunctionWhitelist::FunctionWhitelist): Deleted. (JSC::DFG::FunctionWhitelist::parseFunctionNamesInFile): Deleted. (JSC::DFG::FunctionWhitelist::contains): Deleted. * tools/FunctionWhitelist.h: Copied from Source/JavaScriptCore/dfg/DFGFunctionWhitelist.h. 2016-05-07 Benjamin Poulain [JSC][32bit] stress/tagged-templates-template-object.js fails in debug https://bugs.webkit.org/show_bug.cgi?id=157436 Reviewed by Filip Pizlo. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): The node OverridesHasInstance had a speculation after a jump. 2016-05-06 Joseph Pecoraro Web Inspector: Misc CommandLineAPI cleanup https://bugs.webkit.org/show_bug.cgi?id=157450 Reviewed by Ryosuke Niwa. * inspector/InjectedScriptSource.js: (BasicCommandLineAPI): Fix mistake in r200533, and modernize related code. 2016-05-06 Joseph Pecoraro Web Inspector: Improve console.count() https://bugs.webkit.org/show_bug.cgi?id=157439 Reviewed by Timothy Hatcher. - make console.count() increment an unnamed global counter. - make console.count(label) increment a counter with that label name. * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::count): 2016-05-06 Simon Fraser Enable IOS_TEXT_AUTOSIZING on Mac and make it testable https://bugs.webkit.org/show_bug.cgi?id=157432 rdar://problem/16406720 Reviewed by Dean Jackson. Enable IOS_TEXT_AUTOSIZING on Mac so it can be tested. * Configurations/FeatureDefines.xcconfig: 2016-05-06 Joseph Pecoraro Web Inspector: Console: Variables defined with let/const aren't accessible outside of console's scope https://bugs.webkit.org/show_bug.cgi?id=150752 Reviewed by Mark Lam. This approach allows Web Inspector to hang a "Scope Extension", a WithObjectScope, off the GlobalObject. When resolving identifiers in fails to resolve anything in the normal scope chain, consult the scope extension. This allows us to eliminate the `with (commandLineAPI) { ... }` block in global console evaluations, and instead makes it a full program evaluation, with the commandLineAPI available and safely shadowed by actual variables as expected. * inspector/InjectedScriptSource.js: (InjectedScript.prototype._evaluateOn): Use the new evaluateWithScopeExtension and provide the CommandLineAPI object as the scope extension object. (BasicCommandLineAPI): (BasicCommandLineAPI.inScopeVariables): Deleted. Simplify now that we don't need to check for variable shadowing ourselves. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension): * inspector/JSInjectedScriptHost.h: * inspector/JSInjectedScriptHostPrototype.cpp: (Inspector::JSInjectedScriptHostPrototype::finishCreation): (Inspector::jsInjectedScriptHostPrototypeFunctionEvaluateWithScopeExtension): Provide a new InjectedScriptHost method to evaluate a program with a scope extension. * runtime/Completion.cpp: (JSC::evaluateWithScopeExtension): * runtime/Completion.h: General JSC::evaluate function to evaluate a program with a scope extension. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::setGlobalScopeExtension): (JSC::JSGlobalObject::clearGlobalScopeExtension): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::globalScopeExtension): Hang a scope extension off the global object. * runtime/JSScope.cpp: (JSC::JSScope::resolve): Consult the scope extension when resolve fails to find anything normally. 2016-05-06 Mark Lam Add JSC options reportBaselineCompileTimes and reportDFGCompileTimes. https://bugs.webkit.org/show_bug.cgi?id=157427 Reviewed by Filip Pizlo and Keith Miller. The compile times reporting options are now: reportCompileTimes -> report compile times in all tiers. reportBaselineCompileTimes -> report compile times in baseline JIT. reportDFGCompileTimes -> report compile times in DFG and FTL. reportFTLCompileTimes -> report compile times in FTL. Also updated reportTotalCompileTimes() to collect stats that include the baseline JIT. compileTimeStats() is now moved into JIT.cpp (from DFGPlan.cpp). * dfg/DFGPlan.cpp: (JSC::DFG::Plan::reportCompileTimes): (JSC::DFG::Plan::compileInThread): (JSC::DFG::Plan::compileInThreadImpl): (JSC::DFG::Plan::cancel): (JSC::DFG::Plan::compileTimeStats): Deleted. * dfg/DFGPlan.h: (JSC::DFG::Plan::compileTimeStats): Deleted. * jit/JIT.cpp: (JSC::ctiPatchCallByReturnAddress): (JSC::JIT::privateCompile): (JSC::JIT::stackPointerOffsetFor): (JSC::JIT::reportCompileTimes): (JSC::JIT::computeCompileTimes): (JSC::JIT::compileTimeStats): * jit/JIT.h: (JSC::JIT::shouldEmitProfiling): * jsc.cpp: (runJSC): * runtime/Options.h: 2016-05-05 Benjamin Poulain [JSC] Get rid of NonNegZeroDouble, it is broken https://bugs.webkit.org/show_bug.cgi?id=157399 rdar://problem/25339647 Reviewed by Mark Lam. The profile "NonNegZeroDouble" is fundamentally broken. It is used by DFG to predict the result of ArithMul as being a Double or Int32. The problem is you are likely to mispredict, and when you do, you are guaranteed to end up in a recompile loop. The compile loops usually happen like this: -We speculate you have Int32 despite producing doubles. -We OSR exit on another node (ValueToInt32 for example) from the result of this ArithMul. -When we compile this block again, ArithMul will do the same misprediction because it unconditionally predicts Int32. The flag NonNegZeroDouble was very unlikely to be set correctly in the first place. In LLINT, the flag is only set on the slow path. Since double*double is on the fast path, those cases are ignored. In Baseline, the flag is set for any case that falls back on double multiplication. BUT, the DFG flag was only set for nodes that spend many iteration in slow path, which obviously does not apply to double*double. Given the perf drawbacks and the recompile loops, I removed the whole flag for now. * bytecode/ValueProfile.cpp: (WTF::printInternal): * bytecode/ValueProfile.h: (JSC::ResultProfile::didObserveNonInt32): Deleted. (JSC::ResultProfile::didObserveDouble): Deleted. (JSC::ResultProfile::didObserveNonNegZeroDouble): Deleted. (JSC::ResultProfile::setObservedNonNegZeroDouble): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): Deleted. * dfg/DFGNode.h: (JSC::DFG::Node::mayHaveNonIntResult): Deleted. * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): Deleted. * dfg/DFGNodeFlags.h: * dfg/DFGPredictionPropagationPhase.cpp: * jit/JITMulGenerator.cpp: (JSC::JITMulGenerator::generateFastPath): Deleted. * runtime/CommonSlowPaths.cpp: (JSC::updateResultProfileForBinaryArithOp): Deleted. 2016-05-05 Joseph Pecoraro REGRESSION(r200422): Web Inspector: Make new Array Iterator objects play nice with Web Inspector https://bugs.webkit.org/show_bug.cgi?id=157361 Reviewed by Timothy Hatcher. * builtins/ArrayPrototype.js: (createArrayIterator): (values): (keys): (entries): * builtins/TypedArrayPrototype.js: (values): (keys): (entries): * runtime/CommonIdentifiers.h: Set the kind on the iterator object, that can be shown to the inspector if the object is shown in the console. * inspector/InjectedScriptSource.js: (InjectedScript.prototype._describe): Get a better name for the new Array Iterator which is just an Object. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::subtype): (Inspector::JSInjectedScriptHost::getInternalProperties): Detect and handle ArrayIterator object instances. Porting the code from the JSArrayIterator code path. 2016-05-05 Benjamin Poulain [JSC] In DFG, an OSR Exit on SetLocal can trash its child node https://bugs.webkit.org/show_bug.cgi?id=157358 rdar://problem/25339647 Reviewed by Filip Pizlo. When we OSR Exit on SetLocal, the child is never restored if its representation was changed since the MovHint. For example, say we have: @1 = SomethingProducingDouble() @2 = MovHint(@1) @3 = ValueRep(@1) @4 = SetLocal(@3, FlushedInt32) When we lower SetLocal(), we start by speculating that @3 is an Int32. Now this can fail if @1 was really a double. When that happens, we go over the VariableEventStream to find where values are, and @1 died at @3. Since the speculation failure happens before the SetLocal event, we don't do anything with @3. In this patch, I extend the PhantomInsertion phase to keep the MovHint alive past the SetLocal. * dfg/DFGPhantomInsertionPhase.cpp: * tests/stress/multiply-typed-double-and-object.js: Added. (otherObject.valueOf): (targetDFG.multiply): (targetFTL.multiply): 2016-05-05 Oliver Hunt Enable separated heap by default on ios https://bugs.webkit.org/show_bug.cgi?id=156720 Reviewed by Geoffrey Garen. We've fixed the xnu side of things, so we can reland this. * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2016-05-05 Joseph Pecoraro JSContext Inspector: Better CommandLineAPI in JSContext inspection https://bugs.webkit.org/show_bug.cgi?id=157387 Reviewed by Timothy Hatcher. * inspector/InjectedScriptSource.js: (InjectedScript.prototype._evaluateOn): (BasicCommandLineAPI.inScopeVariables): (BasicCommandLineAPI): When creating a BasicCommandLineAPI, pass the call frame so that we don't shadow variables in the callstack. (BasicCommandLineAPI.methods): (clear): (table): (profile): (profileEnd): (keys): (values): Some just pass through to console, others are tiny methods. Implement them, and give them the expected toString string. 2016-05-05 Filip Pizlo Reduce maximum JIT pool size on X86_64. Rubber stamped by Geoffrey Garen. This changes our maximum pool size to 100MB. The problem with letting a page allocate much more than this is that we will sometimes call deleteAllCode() or one of its friends. Deleting a huge amount of memory is expensive in our allocator. So long as we allow for such large-scale code death to happen, and so long as it's expensive, we should bound the amount of code we end up with in the first place. In the long run, we should fix our executable allocator so that it's not so expensive to kill all code. * jit/ExecutableAllocator.h: 2016-05-05 Filip Pizlo Reduce thresholds that control the maximum IC stub size. Rubber stamped by Chris Dumez and Benjamin Poulain. This reduces the thresholds to before the megamorphic load optimizations to see if that recovers a PLT regression. * runtime/Options.h: 2016-05-05 Filip Pizlo We shouldn't crash if DFG AI proved that something was unreachable on one run but then decided not to prove it on another run https://bugs.webkit.org/show_bug.cgi?id=157379 Reviewed by Mark Lam. Any run of DFG AI is a fixpoint that loosens the proof until it can't find any more counterexamples to the proof. It errs on the side of loosening proofs, i.e., on the side of proving fewer things. We run this fixpoint multiple times since there are multiple points in the DFG optimization pipeline when we run DFG AI. Each of those runs completes a fixpoint and produces the tightest proof it can that did not result in counterexamples being found. It's possible that on run K of DFG AI, we prove some property, but on run K+1, we don't prove that property. The code could have changed between the two runs due to other phases. Other phases may modify the code in such a way that it's less amenable to AI's analysis. Our design allows this because DFG AI is not 100% precise. It defends itself from making unsound choices or running forever by sometimes punting on proving some property. It must be able to do this, and so therefore, it might sometimes prove fewer things on a later run. Currently in trunk if the property that AI proves on run K but fails to prove on run K+1 is the reachability of a piece of code, then run K+1 will crash on an assertion at the Unreachable node. It will complain that it reached an Unreachable. But it might be reaching that Unreachable because it failed to prove that something earlier was always exiting. That's OK, see above. So, we should remove the assertion that AI doesn't see Unreachable. No new tests because I don't know how to make this happen. I believe that this happens in the wild based on crash logs. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): 2016-05-05 Joseph Pecoraro Crash if you type "debugger" in the console and continue https://bugs.webkit.org/show_bug.cgi?id=156924 Reviewed by Mark Lam. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame): Bail with an error when we are not paused. * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::callFunctionOn): (Inspector::InspectorRuntimeAgent::getProperties): (Inspector::InspectorRuntimeAgent::getDisplayableProperties): (Inspector::InspectorRuntimeAgent::getCollectionEntries): (Inspector::InspectorRuntimeAgent::saveResult): Update poor error message. 2016-05-05 Keith Miller Add support for delete by value to the DFG https://bugs.webkit.org/show_bug.cgi?id=157372 Reviewed by Filip Pizlo. This patch adds basic support for delete by value to the DFG. delete by value just calls out to a C++ operation on each execution. Additionally, this patch fixes an issue with delete by id where we would crash if the base was null or undefined. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDeleteById): (JSC::DFG::SpeculativeJIT::compileDeleteByVal): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_del_by_val): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_del_by_val): * tests/stress/delete-by-val.js: Added. (assert): (test): * tests/stress/delete-to-object-exception.js: Added. (assert): (test): 2016-05-05 Michael Saboff Unreviewed build fix after change set r200447. Made the detection of clang version XCode build specific. Now shouldEnableDebugAnnotations() should return false for all other build types. * offlineasm/config.rb: 2016-05-05 Joseph Pecoraro Create console object lazily https://bugs.webkit.org/show_bug.cgi?id=157328 Reviewed by Geoffrey Garen. * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::createConsoleProperty): (JSC::JSGlobalObject::init): Deleted. 2016-05-04 Michael Saboff Enable Dwarf2 debug information in offline assembler for clang compiler https://bugs.webkit.org/show_bug.cgi?id=157364. Reviewed by Mark Lam. Added a new function shouldEnableDebugAnnotations() that determines if we are using clang and a new enough version to support the debug annotations. * offlineasm/config.rb: (shouldEnableDebugAnnotations): Added. 2016-05-04 Keith Miller Unreviewed, fix test for new ArrayIteratorPrototype.next() error message. * tests/stress/array-iterators-next-with-call.js: 2016-05-04 Filip Pizlo Speed up JSGlobalObject initialization by making some properties lazy https://bugs.webkit.org/show_bug.cgi?id=157045 Reviewed by Keith Miller. This makes about half of JSGlobalObject's state lazy. There are three categories of state in JSGlobalObject: 1) C++ fields in JSGlobalObject. 2) JS object properties in JSGlobalObject's JSObject superclass. 3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass. State held in JS variables cannot yet be made lazy. That's why this patch only goes half-way. State in JS object properties can be made lazy if we move it to the static property hashtable. JSGlobalObject already had one of those. This patch makes static property hashtables a lot more powerful, by adding three new kinds of static properties. These new kinds allow us to make almost all of JSGlobalObject's object properties lazy. State in C++ fields can now be made lazy thanks in part to WTF's support for stateless lambdas. You can of course make anything lazy by hand, but there are many C++ fields in JSGlobalObject and we are adding more all the time. We don't want to require that each of these has a getter with an initialization check and a corresponding out-of-line slow path that does the initialization. We want this kind of boilerplate to be handled by some abstractions. The primary abstraction introduced in this patch is LazyProperty. Currently, this only works where Type is a subclass of JSCell. Such a property holds a pointer to Type. You can use it like you would a WriteBarrier. It even has set() and get() methods, so it's almost a drop-in replacement. The key to LazyProperty's power is that you can do this: class Bar { ... LazyProperty m_foo; }; ... m_foo.initLater( [] (const LazyProperty::Initializer& init) { init.set(Foo::create(init.vm, init.owner)); }); This initLater() call requires that you pass a stateless lambda (see WTF changelog for the definition). Miraculously, this initLater() call is guaranteed to compile to a store of a pointer constant to m_foo, as in: movabsq 0xBLAH, %rax movq %rax, &m_foo This magical pointer constant points to a callback that was generated by the template instantiation of initLater(). That callback knows to call your stateless lambda, but also does some other bookkeeping: it makes sure that you indeed initialized the property inside the callback and it manages recursive initializations. It's totally legal to call m_foo.get() inside the initLater() callback. If you do that before you call init.set(), m_foo.get() will return null. This is an excellent escape hatch if we ever find ourselves in a dependency cycle. I added this feature because I already had to create a dependency cycle. Note that using LazyProperties from DFG threads is super awkward. It's going to be hard to get this right. The DFG thread cannot initialize those fields, so it has to make sure that it does conservative things. But for some nodes this could mean adding a lot of new logic, like NewTypedArray, which currently is written in such a way that it assumes that we always have the typed array structure. Currently we take a two-fold approach: for typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't initialized, and for everything else we don't make the properties lazy if the DFG needs them. As we optimize this further we might need to teach the DFG to handle more lazy properties. I tried to do this for RegExp but found it to be very confusing. With typed arrays I got lucky. There is also a somewhat more powerful construct called LazyClassStructure. We often need to keep around the structure of some standard JS class, like Date. We also need to make sure that the constructor ends up in the global object's property table. And we often need to keep the original value of the constructor for ourselves. In this case, we want to make sure that the creation of the structure-prototype-constructor constellation is atomic. We don't want code to start looking at the structure if it points to a prototype that doesn't have its "constructor" property set yet, for example. LazyClassStructure solves this by abstracting that whole initialization. You provide the callback that allocates everything, since we are super inconsistent about the way we initialize things, but LazyClassStructure establishes the workflow and helps you not mess up. Finally, the new static hashtable attributes allow for all of this to work with the JS property table: PropertyCallback: if you use this attribute, the second column in the table should be the name of a function to call to initialize this property. This is useful for things like the Math property. The Math object turns out to be very expensive to allocate. Delaying its allocation is super easy with the PropertyCallback attribute. CellProperty: with this attribute the second column should be a C++ field name like JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of this property, and when it needs to be initialized, Lookup will assume you have a LazyProperty and call its get() method. It will initialize the property to whatever get() returned. Note that it's legal to cast a LazyProperty to LazyProperty for the purpose of calling get() because the get() method will just call whatever callback function pointer is encoded in the property and it does not need to know anything about what type that callback will instantiate. ClassStructure: with this attribute the second column should be a C++ field name. The static hashtable will initialize the property by treating the field as a LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns, the property in question will already be set. By convention, we have LazyClassStructure initialize the property with a pointer to the constructor, since that's how all of our classes work: "globalObject.Date" points to the DateConstructor. This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that calls our C API. This is a 1% speed-up on SunSpider and JSRegress. Rolling this back in after fixing the function pointer alignment issue. The last version relied on function pointers being aligned to a 4-byte boundary. We cannot rely on this, especially since ARMv7 uses the low bit of function pointers as a tag to indicate the instruction set. This version adds an extra indirection, so that LazyProperty<>::m_pointer points to a pointer that points to the function. A pointer to a pointer is guaranteed to be at least 4-byte aligned. * API/JSCallbackFunction.cpp: (JSC::JSCallbackFunction::create): * API/ObjCCallbackFunction.h: (JSC::ObjCCallbackFunction::impl): * API/ObjCCallbackFunction.mm: (JSC::ObjCCallbackFunction::ObjCCallbackFunction): (JSC::ObjCCallbackFunction::create): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * create_hash_table: * debugger/DebuggerScope.cpp: (JSC::DebuggerScope::create): (JSC::DebuggerScope::DebuggerScope): * debugger/DebuggerScope.h: (JSC::DebuggerScope::jsScope): (JSC::DebuggerScope::create): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::set): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::originalArrayStructure): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewTypedArray): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStructureRegistrationPhase.cpp: (JSC::DFG::StructureRegistrationPhase::run): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::getOwnPropertySlot): (JSC::ClonedArguments::materializeSpecials): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncToString): * runtime/InternalFunction.cpp: (JSC::InternalFunction::visitChildren): (JSC::InternalFunction::name): (JSC::InternalFunction::calculatedDisplayName): (JSC::InternalFunction::createSubclassStructure): * runtime/InternalFunction.h: * runtime/JSBoundFunction.cpp: (JSC::JSBoundFunction::finishCreation): (JSC::JSBoundFunction::visitChildren): * runtime/JSBoundSlotBaseFunction.cpp: (JSC::JSBoundSlotBaseFunction::create): * runtime/JSFunction.cpp: (JSC::retrieveCallerFunction): (JSC::getThrowTypeErrorGetterSetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::getOwnPropertySlot): (JSC::JSFunction::defineOwnProperty): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayView): * runtime/JSGlobalObject.cpp: (JSC::createProxyProperty): (JSC::createJSONProperty): (JSC::createMathProperty): (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::stringPrototypeChainIsSane): (JSC::JSGlobalObject::resetPrototype): (JSC::JSGlobalObject::visitChildren): (JSC::JSGlobalObject::toThis): (JSC::JSGlobalObject::getOwnPropertySlot): (JSC::JSGlobalObject::createThrowTypeError): Deleted. (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::objectConstructor): (JSC::JSGlobalObject::promiseConstructor): (JSC::JSGlobalObject::internalPromiseConstructor): (JSC::JSGlobalObject::evalErrorConstructor): (JSC::JSGlobalObject::rangeErrorConstructor): (JSC::JSGlobalObject::referenceErrorConstructor): (JSC::JSGlobalObject::syntaxErrorConstructor): (JSC::JSGlobalObject::typeErrorConstructor): (JSC::JSGlobalObject::URIErrorConstructor): (JSC::JSGlobalObject::nullGetterFunction): (JSC::JSGlobalObject::nullSetterFunction): (JSC::JSGlobalObject::callFunction): (JSC::JSGlobalObject::applyFunction): (JSC::JSGlobalObject::definePropertyFunction): (JSC::JSGlobalObject::arrayProtoValuesFunction): (JSC::JSGlobalObject::initializePromiseFunction): (JSC::JSGlobalObject::newPromiseCapabilityFunction): (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction): (JSC::JSGlobalObject::regExpProtoExecFunction): (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction): (JSC::JSGlobalObject::regExpProtoGlobalGetter): (JSC::JSGlobalObject::regExpProtoUnicodeGetter): (JSC::JSGlobalObject::throwTypeErrorGetterSetter): (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter): (JSC::JSGlobalObject::moduleLoader): (JSC::JSGlobalObject::objectPrototype): (JSC::JSGlobalObject::functionPrototype): (JSC::JSGlobalObject::arrayPrototype): (JSC::JSGlobalObject::booleanPrototype): (JSC::JSGlobalObject::stringPrototype): (JSC::JSGlobalObject::symbolPrototype): (JSC::JSGlobalObject::numberPrototype): (JSC::JSGlobalObject::datePrototype): (JSC::JSGlobalObject::regExpPrototype): (JSC::JSGlobalObject::errorPrototype): (JSC::JSGlobalObject::iteratorPrototype): (JSC::JSGlobalObject::generatorFunctionPrototype): (JSC::JSGlobalObject::generatorPrototype): (JSC::JSGlobalObject::debuggerScopeStructure): (JSC::JSGlobalObject::withScopeStructure): (JSC::JSGlobalObject::strictEvalActivationStructure): (JSC::JSGlobalObject::activationStructure): (JSC::JSGlobalObject::moduleEnvironmentStructure): (JSC::JSGlobalObject::directArgumentsStructure): (JSC::JSGlobalObject::scopedArgumentsStructure): (JSC::JSGlobalObject::clonedArgumentsStructure): (JSC::JSGlobalObject::isOriginalArrayStructure): (JSC::JSGlobalObject::booleanObjectStructure): (JSC::JSGlobalObject::callbackConstructorStructure): (JSC::JSGlobalObject::callbackFunctionStructure): (JSC::JSGlobalObject::callbackObjectStructure): (JSC::JSGlobalObject::propertyNameIteratorStructure): (JSC::JSGlobalObject::objcCallbackFunctionStructure): (JSC::JSGlobalObject::objcWrapperObjectStructure): (JSC::JSGlobalObject::dateStructure): (JSC::JSGlobalObject::nullPrototypeObjectStructure): (JSC::JSGlobalObject::errorStructure): (JSC::JSGlobalObject::calleeStructure): (JSC::JSGlobalObject::functionStructure): (JSC::JSGlobalObject::boundFunctionStructure): (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): (JSC::JSGlobalObject::getterSetterStructure): (JSC::JSGlobalObject::nativeStdFunctionStructure): (JSC::JSGlobalObject::namedFunctionStructure): (JSC::JSGlobalObject::functionNameOffset): (JSC::JSGlobalObject::numberObjectStructure): (JSC::JSGlobalObject::privateNameStructure): (JSC::JSGlobalObject::mapStructure): (JSC::JSGlobalObject::regExpStructure): (JSC::JSGlobalObject::generatorFunctionStructure): (JSC::JSGlobalObject::setStructure): (JSC::JSGlobalObject::stringObjectStructure): (JSC::JSGlobalObject::symbolObjectStructure): (JSC::JSGlobalObject::iteratorResultObjectStructure): (JSC::JSGlobalObject::lazyTypedArrayStructure): (JSC::JSGlobalObject::typedArrayStructure): (JSC::JSGlobalObject::typedArrayStructureConcurrently): (JSC::JSGlobalObject::isOriginalTypedArrayStructure): (JSC::JSGlobalObject::typedArrayConstructor): (JSC::JSGlobalObject::actualPointerFor): (JSC::JSGlobalObject::internalFunctionStructure): Deleted. * runtime/JSNativeStdFunction.cpp: (JSC::JSNativeStdFunction::create): * runtime/JSWithScope.cpp: (JSC::JSWithScope::create): (JSC::JSWithScope::visitChildren): (JSC::JSWithScope::createStructure): (JSC::JSWithScope::JSWithScope): * runtime/JSWithScope.h: (JSC::JSWithScope::object): (JSC::JSWithScope::create): Deleted. (JSC::JSWithScope::createStructure): Deleted. (JSC::JSWithScope::JSWithScope): Deleted. * runtime/LazyClassStructure.cpp: Added. (JSC::LazyClassStructure::Initializer::Initializer): (JSC::LazyClassStructure::Initializer::setPrototype): (JSC::LazyClassStructure::Initializer::setStructure): (JSC::LazyClassStructure::Initializer::setConstructor): (JSC::LazyClassStructure::visit): (JSC::LazyClassStructure::dump): * runtime/LazyClassStructure.h: Added. (JSC::LazyClassStructure::LazyClassStructure): (JSC::LazyClassStructure::get): (JSC::LazyClassStructure::prototype): (JSC::LazyClassStructure::constructor): (JSC::LazyClassStructure::getConcurrently): (JSC::LazyClassStructure::prototypeConcurrently): (JSC::LazyClassStructure::constructorConcurrently): * runtime/LazyClassStructureInlines.h: Added. (JSC::LazyClassStructure::initLater): * runtime/LazyProperty.h: Added. (JSC::LazyProperty::Initializer::Initializer): (JSC::LazyProperty::LazyProperty): (JSC::LazyProperty::get): (JSC::LazyProperty::getConcurrently): * runtime/LazyPropertyInlines.h: Added. (JSC::ElementType>::Initializer::set): (JSC::ElementType>::initLater): (JSC::ElementType>::setMayBeNull): (JSC::ElementType>::set): (JSC::ElementType>::visit): (JSC::ElementType>::dump): (JSC::ElementType>::callFunc): * runtime/Lookup.cpp: (JSC::setUpStaticFunctionSlot): * runtime/Lookup.h: (JSC::HashTableValue::function): (JSC::HashTableValue::functionLength): (JSC::HashTableValue::propertyGetter): (JSC::HashTableValue::propertyPutter): (JSC::HashTableValue::accessorGetter): (JSC::HashTableValue::accessorSetter): (JSC::HashTableValue::constantInteger): (JSC::HashTableValue::lexerValue): (JSC::HashTableValue::lazyCellPropertyOffset): (JSC::HashTableValue::lazyClassStructureOffset): (JSC::HashTableValue::lazyPropertyCallback): (JSC::getStaticPropertySlot): (JSC::getStaticValueSlot): (JSC::putEntry): (JSC::reifyStaticProperty): * runtime/PropertySlot.h: * runtime/TypedArrayType.h: 2016-05-04 Joseph Pecoraro Improve the grammar of some error messages 'a argument list' => 'an argument list' https://bugs.webkit.org/show_bug.cgi?id=157350 Reviewed by Mark Lam. * parser/Parser.cpp: (JSC::Parser::parseIfStatement): (JSC::Parser::parseImportDeclaration): (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseObjectLiteral): (JSC::Parser::parseStrictObjectLiteral): (JSC::Parser::parseArguments): Use the alternate error message formatter macro which outputs 'an' instead of 'a' preceding the last argument. 2016-05-04 Keith Miller Corrections to r200422 https://bugs.webkit.org/show_bug.cgi?id=157351 Reviewed by Joseph Pecoraro. Fix some typos in various files. Also, make separate error messages for the this value being undefined vs null in the ArrayIteratorprototype next function and add test. * Scripts/builtins/builtins_model.py: * builtins/ArrayIteratorPrototype.js: (next): (arrayIteratorValueNext): (arrayIteratorKeyNext): (arrayIteratorKeyValueNext): * builtins/ArrayPrototype.js: (keys): (entries): * builtins/TypedArrayPrototype.js: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): Deleted. * tests/stress/array-iterators-next-error-messages.js: Added. (assert): (catch): 2016-05-04 Keith Miller Unreviewed, reland r200149 since the rollout had inconclusive PLT AB testing results. 2016-05-04 Mark Lam ES6 Function.name inferred from property names of literal objects can break some websites. https://bugs.webkit.org/show_bug.cgi?id=157246 Reviewed by Geoffrey Garen. Specifically, the library mathjs (see http://mathjs.org and https://github.com/josdejong/mathjs) uses an idiom where it created literal objects with property names that look like this: 'number | BigNumber | Unit'. Later, this name is used in a string to create function source code that gets eval'ed. Since 'number | BigNumber | Unit' is not a valid function name, we get a syntax error. Here are the details: 1. mathjs uses object literals with the funky property names for its function members. For example, // helper function to type check the middle value of the array var middle = typed({ 'number | BigNumber | Unit': function (value) { return value; } }); 2. mathjs' getName() uses Function.name to get the name of functions (hence, picks up the property name as inferred value of Function.name as specified by ES6): /** * Retrieve the function name from a set of functions, and check * whether the name of all functions match (if given) ... */ function getName (fns) { var name = ''; for (var i = 0; i < fns.length; i++) { var fn = fns[i]; ... name = fn.name; ... return name; } 3. mathjs uses that name to assembler new function source code that gets eval'ed: /** * Compose a function from sub-functions each handling a single type signature. ... */ function _typed(name, signatures) { ... // generate code for the typed function var code = []; var _name = name || ''; ... code.push('function ' + _name + '(' + _args.join(', ') + ') {'); code.push(' "use strict";'); code.push(' var name = \'' + _name + '\';'); code.push(node.toCode(refs, ' ')); code.push('}'); // generate body for the factory function var body = [ refs.toCode(), 'return ' + code.join('\n') ].join('\n'); // evaluate the JavaScript code and attach function references var factory = (new Function(refs.name, 'createError', body)); // <== Syntax Error here! var fn = factory(refs, createError); ... return fn; } Until mathjs (and any other frameworks that does similar things) and sites that uses mathjs has been updated to work with ES6, we'll need a compatibility hack to work around it. Here's what we'll do: 1. Introduce a needsSiteSpecificQuirks flag in JSGlobalObject. 2. Have WebCore's JSDOMWindowBase set that flag if the browser's needsSiteSpecificQuirks is enabled in its settings. 3. If needsSiteSpecificQuirks is enabled, have JSFunction::reifyName() check for ' ' or '|' in the name string it will use to reify the Function.name property. If those characters exists in the name, we'll replace the name string with a null string. * runtime/JSFunction.cpp: (JSC::JSFunction::reifyName): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::needsSiteSpecificQuirks): (JSC::JSGlobalObject::GlobalPropertyInfo::GlobalPropertyInfo): (JSC::JSGlobalObject::setNeedsSiteSpecificQuirks): 2016-05-04 Keith Miller Speedup array iterators https://bugs.webkit.org/show_bug.cgi?id=157315 Reviewed by Michael Saboff. This patch improves the performance of Array iterators in ES6. There are two main changes that make things faster. The first is that the value, keys and entries functions have been moved to JS. This enables us to inline the construction of the iterator. Thus, when we get to the FTL we are able to sink the allocation of the iterator object. This significantly improves the performance of any for-of loop since we are now able to have both the iteration counter and the iterated object in local variables rather than in the heap. Secondly, instead of using a number to store the iteratation kind we now use a virtual method on the iteration object to indicate which next function to use. This ends up being helpful because it means we can eliminate the branches in the old next function that decide what value to return. With those branches gone the various next functions are now small enough to inline. Once the next functions are inlined then the FTL is able to sink the allocation of next() result object. There is still room for optimization in the loop since we currently don't recognize that the array access in the next function is in bounds or that the increment to the loop counter cannot overflow. The overall performance changes appear to be a ~4-6x speedup in a simple microbenchmark that computes the sum of an array with some extra arithmetic. The variance depends on the exact body of the loop. Additionally, on a new regress test that changes all the loops in deltablue into for-of loops this patch is a 1.8x progression. Overall, it still looks like for-of loops are significantly slower than an indexed for loop. In the first test it's ~2-4x slower with the difference depending on the body of the loop. If the loop is just the sum then we see a much larger regression than if the loop does even simple arithmetic. It looks like the indexed for loop without extra arithmetic is small enough to fit into the x86 replay buffer on my machine, which would explain why there is such a big difference between the for of loop in that case. On the deltablue benchmark it's 1.4x slower. It's clear from these numbers that there is still a lot of work we can do to make for of loops faster. This patch also makes some changes to the way that we decorate our builtin js functions. Instead of the old syntax (putting the decorated values in [] before the function declaration i.e. [intrinsic=foo]) this patch changes the syntax to be closer to the way that decorators are proposed in a future ECMAScript proposal (using @ followed by the entry on a new line before the function declaration i.e. @intrinsic=foo). Finally, in the builtin scripts regular expressions re.S has been changed to re.DOTALL since DOTALL is easier to understand without going to the reference page for python regular expressions. * Scripts/builtins/builtins_model.py: * builtins/ArrayIteratorPrototype.js: (next): (arrayIteratorValueNext): (arrayIteratorKeyNext): (arrayIteratorKeyValueNext): * builtins/ArrayPrototype.js: (createArrayIterator): (values): (keys): (entries): * builtins/RegExpPrototype.js: (intrinsic.RegExpTestIntrinsic.test): * builtins/StringPrototype.js: (intrinsic.StringPrototypeReplaceIntrinsic.replace): * builtins/TypedArrayPrototype.js: (values): (keys): (entries): * inspector/JSInjectedScriptHost.cpp: (Inspector::cloneArrayIteratorObject): (Inspector::JSInjectedScriptHost::iteratorEntries): * jit/ThunkGenerators.cpp: * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): (JSC::arrayProtoFuncValues): Deleted. (JSC::arrayProtoFuncEntries): Deleted. (JSC::arrayProtoFuncKeys): Deleted. * runtime/CommonIdentifiers.h: * runtime/JSArrayIterator.cpp: (JSC::JSArrayIterator::clone): Deleted. * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncEntries): Deleted. (JSC::genericTypedArrayViewProtoFuncKeys): Deleted. (JSC::typedArrayViewProtoFuncValues): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): (JSC::typedArrayViewProtoFuncEntries): Deleted. (JSC::typedArrayViewProtoFuncKeys): Deleted. (JSC::typedArrayViewProtoFuncValues): Deleted. * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2016-05-04 Yusuke Suzuki [JSC] Object constructor need to be aware of new.target https://bugs.webkit.org/show_bug.cgi?id=157196 Reviewed by Darin Adler. Object constructor should be aware of new.target. When the new.target is specified, we should store it.prototype to the newly created object's [[Prototype]]. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): Take the design that caches the structure used for empty object. This structure is also used in constructEmptyObject frequently. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::objectStructureForObjectConstructor): * runtime/ObjectConstructor.cpp: (JSC::constructObject): (JSC::constructWithObjectConstructor): (JSC::callObjectConstructor): * runtime/ObjectConstructor.h: (JSC::constructEmptyObject): Construct the object by using the plain structure that is also used in the ObjectConstructor. * tests/stress/object-constructor-should-be-new-target-aware.js: Added. (shouldBe): (Hello): 2016-05-04 Chris Dumez Unreviewed, rolling out r200383 and r200406. Seems to have caused crashes on iOS / ARMv7s Reverted changesets: "Speed up JSGlobalObject initialization by making some properties lazy" https://bugs.webkit.org/show_bug.cgi?id=157045 http://trac.webkit.org/changeset/200383 "REGRESSION(r200383): Setting lazily initialized properties across frame boundaries crashes" https://bugs.webkit.org/show_bug.cgi?id=157333 http://trac.webkit.org/changeset/200406 2016-05-04 Yusuke Suzuki Assertion failure for super() call in direct eval in method function https://bugs.webkit.org/show_bug.cgi?id=157091 Reviewed by Darin Adler. While we ensure that direct super is under the correct context, we don't check it for the eval code. This patch moves the check from the end of parsing the function to the places where we found the direct super or the super bindings. This covers the direct eval that contains the direct super calls. * parser/Parser.cpp: (JSC::Parser::parseGeneratorFunctionSourceElements): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseMemberExpression): * parser/Parser.h: (JSC::Scope::hasDirectSuper): (JSC::Scope::setHasDirectSuper): (JSC::Scope::needsSuperBinding): (JSC::Scope::setNeedsSuperBinding): (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope): * tests/stress/eval-and-super.js: Added. (shouldBe): (shouldThrow): (prototype.m): (prototype.n): * tests/stress/generator-and-super.js: Added. (testSyntaxError): (testSyntaxError.Base.prototype.hello): (testSyntaxError.Base.prototype.ok): (testSyntaxError.Base): (Hello.prototype.gen): (Hello): (testSyntaxError.hello): 2016-05-03 Filip Pizlo REGRESSION(r200383): Setting lazily initialized properties across frame boundaries crashes https://bugs.webkit.org/show_bug.cgi?id=157333 Reviewed by Benjamin Poulain. I forgot to add logic for lazy properties in putEntry(). It turns out that it's easy to add. * runtime/Lookup.h: (JSC::putEntry): * runtime/PropertySlot.h: 2016-05-03 Filip Pizlo References from code to Structures should be stronger than weak https://bugs.webkit.org/show_bug.cgi?id=157324 Reviewed by Mark Lam. If code refers to a Structure and the Structure dies, then previously we'd kill the code. This makes sense because the Structure could be the only thing left referring to some global object or prototype. But this also causes unnecessary churn. Sometimes there will be a structure that we just haven't really done anything with recently and so it appears dead. The approach we use elsewhere in our type inference is that the type that the code uses is general enough to handle every past execution. Having the GC clear code when some Structure it uses dies means that we forget that the code used that Structure. We'll either assume that the code is more monomorphic than it really is (because after GC we patch in some other structure but not the deleted one, so it looks like we only ever saw the new structure), or we'll assume that it's crazier than it really is (because we'll remember that there had been some structure that caused deletion, so we'll assume that deletions might happen in the future, so we'll use a fully dynamic IC). This change introduces a more nuanced policy: if it's cheap to mark a dead Structure then we should mark it just so that all of the code that refers to it remembers that there had been this exact Structure in the past. If the code often goes through different Structures then we already have great mechanisms to realize that the code is nutty (namely, the PolymorphicAccess size limit). But if the code just does this a handful of times then remembering this old Structure is probably net good: - It obeys the "handle all past executions" law. - It preserves the history of the property access, allowing a precise measure of its past polymorphism. - It makes the code ready to run fast if the user decides to use that Structure again. Marking the Structure means it will stay in whatever property transition tables it was in, so if the program does the same thing it did in the past, it will get this old Structure. It looks like this is a progression in gbemu and it makes gbemu perform more deterministically. Also, it seems that this makes JetStream run faster. Over five in-browser runs of JetStream, here's what we see before and after: Geometric Mean: Before After 229.23 +- 8.2523 230.70 +- 12.888 232.91 +- 15.638 239.04 +- 13.766 234.79 +- 12.760 236.32 +- 15.562 236.20 +- 23.125 242.02 +- 3.3865 237.22 +- 2.1929 237.23 +- 17.664 Just gbemu: Before After 541.0 +- 135.8 481.7 +- 143.4 518.9 +- 15.65 508.1 +- 136.3 362.5 +- 0.8884 489.7 +- 101.4 470.7 +- 313.3 530.7 +- 11.49 418.7 +- 180.6 537.2 +- 6.514 Notice that there is plenty of noise before and after, but the noise is now far less severe. After this change I did not see any runs like "470.7 +- 313.3" where the size of the confidence interval (313.3 * 2) is greater than the score (470.7). Also, notice that the least noisy run before the change also got a lower score than we ever observed after the change (36.5 +- 0.8884). The noise, and these occasional very low scores, are due to a pathology where the GC would reset some stubs at an unfortunate time during profiling, causing the optimizing compiler to make many poor decisions. That pathology doesn't exist anymore. On the other hand, prior to this change it was possible for gbemu to sometimes run sooooper fast because the GC would cause the profiler to forget gbemu's behavior on the first tick and focus only on its behavior in subsequent ticks. So, in steady state, we'd optimize gbemu for its later behavior rather than a combination of its early behavior and later behavior. We rarely got lucky this way, so it's not fair to view this quirk as a feature. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::propagateTransitions): * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::visitWeak): (JSC::AccessCase::propagateTransitions): (JSC::AccessCase::generateWithGuard): (JSC::PolymorphicAccess::visitWeak): (JSC::PolymorphicAccess::propagateTransitions): (JSC::PolymorphicAccess::dump): * bytecode/PolymorphicAccess.h: * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::visitWeakReferences): (JSC::StructureStubInfo::propagateTransitions): (JSC::StructureStubInfo::containsPC): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::considerCaching): * runtime/Structure.cpp: (JSC::Structure::visitChildren): (JSC::Structure::isCheapDuringGC): (JSC::Structure::markIfCheap): (JSC::Structure::prototypeChainMayInterceptStoreTo): * runtime/Structure.h: 2016-05-03 Joseph Pecoraro Web Inspector: Simplify console.clear https://bugs.webkit.org/show_bug.cgi?id=157316 Reviewed by Timothy Hatcher. * inspector/ScriptArguments.cpp: (Inspector::ScriptArguments::createEmpty): (Inspector::ScriptArguments::ScriptArguments): * inspector/ScriptArguments.h: Provide a way to create an empty list. * runtime/ConsoleClient.cpp: (JSC::ConsoleClient::clear): * runtime/ConsoleClient.h: Drop unnecessary parameter. * runtime/ConsoleObject.cpp: (JSC::consoleProtoFuncClear): No need to parse arguments. 2016-05-03 Yusuke Suzuki Improve Symbol() to string coercion error message https://bugs.webkit.org/show_bug.cgi?id=157317 Reviewed by Geoffrey Garen. Improve error messages related to Symbols. * runtime/JSCJSValue.cpp: (JSC::JSValue::toStringSlowCase): * runtime/Symbol.cpp: (JSC::Symbol::toNumber): * runtime/SymbolConstructor.cpp: (JSC::symbolConstructorKeyFor): * runtime/SymbolPrototype.cpp: (JSC::symbolProtoFuncToString): (JSC::symbolProtoFuncValueOf): * tests/stress/dfg-to-primitive-pass-symbol.js: * tests/stress/floating-point-div-to-mul.js: (i.catch): * tests/stress/string-from-code-point.js: (shouldThrow): (string_appeared_here.shouldThrow): * tests/stress/symbol-error-messages.js: Added. (shouldThrow): * tests/stress/symbol-registry.js: 2016-05-03 Joseph Pecoraro Web Inspector: Give console.time/timeEnd a default label and warnings https://bugs.webkit.org/show_bug.cgi?id=157325 Reviewed by Timothy Hatcher. Provide more user friendly console.time/timeEnd. The timer name is now optional, and is "default" if not provided. Also provide warnings when attempting to start an already started timer, or stop a timer that does not exist. * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::startTiming): (Inspector::InspectorConsoleAgent::stopTiming): Warnings for bad cases. * runtime/ConsoleObject.cpp: (JSC::defaultLabelString): (JSC::consoleProtoFuncTime): (JSC::consoleProtoFuncTimeEnd): Optional label becomes "default". 2016-05-03 Xan Lopez Fix the ENABLE(WEBASSEMBLY) build https://bugs.webkit.org/show_bug.cgi?id=157312 Reviewed by Darin Adler. * runtime/Executable.cpp: (JSC::WebAssemblyExecutable::WebAssemblyExecutable): * wasm/WASMFunctionCompiler.h: (JSC::WASMFunctionCompiler::convertValueToDouble): 2016-05-03 Joseph Pecoraro Web Inspector: Remove unused parameter of ScriptArguments::getFirstArgumentAsString https://bugs.webkit.org/show_bug.cgi?id=157301 Reviewed by Timothy Hatcher. * inspector/ScriptArguments.cpp: (Inspector::ScriptArguments::getFirstArgumentAsString): * inspector/ScriptArguments.h: Remove unused argument and related code. * runtime/ConsoleClient.cpp: (JSC::ConsoleClient::printConsoleMessageWithArguments): Drive by remove unnecessary cast. 2016-05-03 Michael Saboff Crash: Array.prototype.slice() and .splice() can call fastSlice() after an array is truncated https://bugs.webkit.org/show_bug.cgi?id=157322 Reviewed by Filip Pizlo. Check to see if the source array has changed length before calling fastSlice(). If it has, take the slow path. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSlice): (JSC::arrayProtoFuncSplice): * tests/stress/regress-157322.js: New test. 2016-05-03 Joseph Pecoraro Eliminate PassRefPtr conversion from ConsoleObject https://bugs.webkit.org/show_bug.cgi?id=157300 Reviewed by Timothy Hatcher. * runtime/ConsoleObject.cpp: (JSC::consoleLogWithLevel): (JSC::consoleProtoFuncClear): (JSC::consoleProtoFuncDir): (JSC::consoleProtoFuncDirXML): (JSC::consoleProtoFuncTable): (JSC::consoleProtoFuncTrace): (JSC::consoleProtoFuncAssert): (JSC::consoleProtoFuncCount): (JSC::consoleProtoFuncTimeStamp): (JSC::consoleProtoFuncGroup): (JSC::consoleProtoFuncGroupCollapsed): (JSC::consoleProtoFuncGroupEnd): No need to release to a PassRefPtr, we can just move into the RefPtr<>&&. 2016-05-01 Filip Pizlo Speed up JSGlobalObject initialization by making some properties lazy https://bugs.webkit.org/show_bug.cgi?id=157045 Reviewed by Keith Miller. This makes about half of JSGlobalObject's state lazy. There are three categories of state in JSGlobalObject: 1) C++ fields in JSGlobalObject. 2) JS object properties in JSGlobalObject's JSObject superclass. 3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass. State held in JS variables cannot yet be made lazy. That's why this patch only goes half-way. State in JS object properties can be made lazy if we move it to the static property hashtable. JSGlobalObject already had one of those. This patch makes static property hashtables a lot more powerful, by adding three new kinds of static properties. These new kinds allow us to make almost all of JSGlobalObject's object properties lazy. State in C++ fields can now be made lazy thanks in part to WTF's support for stateless lambdas. You can of course make anything lazy by hand, but there are many C++ fields in JSGlobalObject and we are adding more all the time. We don't want to require that each of these has a getter with an initialization check and a corresponding out-of-line slow path that does the initialization. We want this kind of boilerplate to be handled by some abstractions. The primary abstraction introduced in this patch is LazyProperty. Currently, this only works where Type is a subclass of JSCell. Such a property holds a pointer to Type. You can use it like you would a WriteBarrier. It even has set() and get() methods, so it's almost a drop-in replacement. The key to LazyProperty's power is that you can do this: class Bar { ... LazyProperty m_foo; }; ... m_foo.initLater( [] (const LazyProperty::Initializer& init) { init.set(Foo::create(init.vm, init.owner)); }); This initLater() call requires that you pass a stateless lambda (see WTF changelog for the definition). Miraculously, this initLater() call is guaranteed to compile to a store of a pointer constant to m_foo, as in: movabsq 0xBLAH, %rax movq %rax, &m_foo This magical pointer constant points to a callback that was generated by the template instantiation of initLater(). That callback knows to call your stateless lambda, but also does some other bookkeeping: it makes sure that you indeed initialized the property inside the callback and it manages recursive initializations. It's totally legal to call m_foo.get() inside the initLater() callback. If you do that before you call init.set(), m_foo.get() will return null. This is an excellent escape hatch if we ever find ourselves in a dependency cycle. I added this feature because I already had to create a dependency cycle. Note that using LazyProperties from DFG threads is super awkward. It's going to be hard to get this right. The DFG thread cannot initialize those fields, so it has to make sure that it does conservative things. But for some nodes this could mean adding a lot of new logic, like NewTypedArray, which currently is written in such a way that it assumes that we always have the typed array structure. Currently we take a two-fold approach: for typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't initialized, and for everything else we don't make the properties lazy if the DFG needs them. As we optimize this further we might need to teach the DFG to handle more lazy properties. I tried to do this for RegExp but found it to be very confusing. With typed arrays I got lucky. There is also a somewhat more powerful construct called LazyClassStructure. We often need to keep around the structure of some standard JS class, like Date. We also need to make sure that the constructor ends up in the global object's property table. And we often need to keep the original value of the constructor for ourselves. In this case, we want to make sure that the creation of the structure-prototype-constructor constellation is atomic. We don't want code to start looking at the structure if it points to a prototype that doesn't have its "constructor" property set yet, for example. LazyClassStructure solves this by abstracting that whole initialization. You provide the callback that allocates everything, since we are super inconsistent about the way we initialize things, but LazyClassStructure establishes the workflow and helps you not mess up. Finally, the new static hashtable attributes allow for all of this to work with the JS property table: PropertyCallback: if you use this attribute, the second column in the table should be the name of a function to call to initialize this property. This is useful for things like the Math property. The Math object turns out to be very expensive to allocate. Delaying its allocation is super easy with the PropertyCallback attribute. CellProperty: with this attribute the second column should be a C++ field name like JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of this property, and when it needs to be initialized, Lookup will assume you have a LazyProperty and call its get() method. It will initialize the property to whatever get() returned. Note that it's legal to cast a LazyProperty to LazyProperty for the purpose of calling get() because the get() method will just call whatever callback function pointer is encoded in the property and it does not need to know anything about what type that callback will instantiate. ClassStructure: with this attribute the second column should be a C++ field name. The static hashtable will initialize the property by treating the field as a LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns, the property in question will already be set. By convention, we have LazyClassStructure initialize the property with a pointer to the constructor, since that's how all of our classes work: "globalObject.Date" points to the DateConstructor. This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that calls our C API. This is a 1% speed-up on SunSpider and JSRegress. * API/JSCallbackFunction.cpp: (JSC::JSCallbackFunction::create): * API/ObjCCallbackFunction.h: (JSC::ObjCCallbackFunction::impl): * API/ObjCCallbackFunction.mm: (JSC::ObjCCallbackFunction::ObjCCallbackFunction): (JSC::ObjCCallbackFunction::create): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * create_hash_table: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::set): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::originalArrayStructure): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewTypedArray): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStructureRegistrationPhase.cpp: (JSC::DFG::StructureRegistrationPhase::run): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::getOwnPropertySlot): (JSC::ClonedArguments::materializeSpecials): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncToString): * runtime/InternalFunction.cpp: (JSC::InternalFunction::visitChildren): (JSC::InternalFunction::name): (JSC::InternalFunction::calculatedDisplayName): (JSC::InternalFunction::createSubclassStructure): * runtime/InternalFunction.h: * runtime/JSBoundFunction.cpp: (JSC::JSBoundFunction::finishCreation): (JSC::JSBoundFunction::visitChildren): * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnPropertySlot): (JSC::JSFunction::defineOwnProperty): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayView): * runtime/JSGlobalObject.cpp: (JSC::createProxyProperty): (JSC::createJSONProperty): (JSC::createMathProperty): (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::stringPrototypeChainIsSane): (JSC::JSGlobalObject::resetPrototype): (JSC::JSGlobalObject::visitChildren): (JSC::JSGlobalObject::toThis): (JSC::JSGlobalObject::getOwnPropertySlot): (JSC::JSGlobalObject::createThrowTypeError): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::objectConstructor): (JSC::JSGlobalObject::promiseConstructor): (JSC::JSGlobalObject::internalPromiseConstructor): (JSC::JSGlobalObject::evalErrorConstructor): (JSC::JSGlobalObject::rangeErrorConstructor): (JSC::JSGlobalObject::referenceErrorConstructor): (JSC::JSGlobalObject::syntaxErrorConstructor): (JSC::JSGlobalObject::typeErrorConstructor): (JSC::JSGlobalObject::URIErrorConstructor): (JSC::JSGlobalObject::nullGetterFunction): (JSC::JSGlobalObject::nullSetterFunction): (JSC::JSGlobalObject::callFunction): (JSC::JSGlobalObject::applyFunction): (JSC::JSGlobalObject::definePropertyFunction): (JSC::JSGlobalObject::arrayProtoValuesFunction): (JSC::JSGlobalObject::initializePromiseFunction): (JSC::JSGlobalObject::newPromiseCapabilityFunction): (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction): (JSC::JSGlobalObject::regExpProtoExecFunction): (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction): (JSC::JSGlobalObject::regExpProtoGlobalGetter): (JSC::JSGlobalObject::regExpProtoUnicodeGetter): (JSC::JSGlobalObject::throwTypeErrorGetterSetter): (JSC::JSGlobalObject::moduleLoader): (JSC::JSGlobalObject::objectPrototype): (JSC::JSGlobalObject::functionPrototype): (JSC::JSGlobalObject::arrayPrototype): (JSC::JSGlobalObject::booleanPrototype): (JSC::JSGlobalObject::stringPrototype): (JSC::JSGlobalObject::symbolPrototype): (JSC::JSGlobalObject::numberPrototype): (JSC::JSGlobalObject::datePrototype): (JSC::JSGlobalObject::regExpPrototype): (JSC::JSGlobalObject::errorPrototype): (JSC::JSGlobalObject::iteratorPrototype): (JSC::JSGlobalObject::generatorFunctionPrototype): (JSC::JSGlobalObject::generatorPrototype): (JSC::JSGlobalObject::debuggerScopeStructure): (JSC::JSGlobalObject::withScopeStructure): (JSC::JSGlobalObject::strictEvalActivationStructure): (JSC::JSGlobalObject::activationStructure): (JSC::JSGlobalObject::moduleEnvironmentStructure): (JSC::JSGlobalObject::directArgumentsStructure): (JSC::JSGlobalObject::scopedArgumentsStructure): (JSC::JSGlobalObject::clonedArgumentsStructure): (JSC::JSGlobalObject::isOriginalArrayStructure): (JSC::JSGlobalObject::booleanObjectStructure): (JSC::JSGlobalObject::callbackConstructorStructure): (JSC::JSGlobalObject::callbackFunctionStructure): (JSC::JSGlobalObject::callbackObjectStructure): (JSC::JSGlobalObject::propertyNameIteratorStructure): (JSC::JSGlobalObject::objcCallbackFunctionStructure): (JSC::JSGlobalObject::objcWrapperObjectStructure): (JSC::JSGlobalObject::dateStructure): (JSC::JSGlobalObject::nullPrototypeObjectStructure): (JSC::JSGlobalObject::errorStructure): (JSC::JSGlobalObject::calleeStructure): (JSC::JSGlobalObject::functionStructure): (JSC::JSGlobalObject::boundFunctionStructure): (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): (JSC::JSGlobalObject::getterSetterStructure): (JSC::JSGlobalObject::nativeStdFunctionStructure): (JSC::JSGlobalObject::namedFunctionStructure): (JSC::JSGlobalObject::functionNameOffset): (JSC::JSGlobalObject::numberObjectStructure): (JSC::JSGlobalObject::privateNameStructure): (JSC::JSGlobalObject::mapStructure): (JSC::JSGlobalObject::regExpStructure): (JSC::JSGlobalObject::generatorFunctionStructure): (JSC::JSGlobalObject::setStructure): (JSC::JSGlobalObject::stringObjectStructure): (JSC::JSGlobalObject::symbolObjectStructure): (JSC::JSGlobalObject::iteratorResultObjectStructure): (JSC::JSGlobalObject::lazyTypedArrayStructure): (JSC::JSGlobalObject::typedArrayStructure): (JSC::JSGlobalObject::typedArrayStructureConcurrently): (JSC::JSGlobalObject::isOriginalTypedArrayStructure): (JSC::JSGlobalObject::typedArrayConstructor): (JSC::JSGlobalObject::actualPointerFor): (JSC::JSGlobalObject::internalFunctionStructure): Deleted. * runtime/JSNativeStdFunction.cpp: (JSC::JSNativeStdFunction::create): * runtime/JSWithScope.cpp: (JSC::JSWithScope::create): (JSC::JSWithScope::visitChildren): (JSC::JSWithScope::createStructure): (JSC::JSWithScope::JSWithScope): * runtime/JSWithScope.h: (JSC::JSWithScope::object): (JSC::JSWithScope::create): Deleted. (JSC::JSWithScope::createStructure): Deleted. (JSC::JSWithScope::JSWithScope): Deleted. * runtime/LazyClassStructure.cpp: Added. (JSC::LazyClassStructure::Initializer::Initializer): (JSC::LazyClassStructure::Initializer::setPrototype): (JSC::LazyClassStructure::Initializer::setStructure): (JSC::LazyClassStructure::Initializer::setConstructor): (JSC::LazyClassStructure::visit): (JSC::LazyClassStructure::dump): * runtime/LazyClassStructure.h: Added. (JSC::LazyClassStructure::LazyClassStructure): (JSC::LazyClassStructure::get): (JSC::LazyClassStructure::prototype): (JSC::LazyClassStructure::constructor): (JSC::LazyClassStructure::getConcurrently): (JSC::LazyClassStructure::prototypeConcurrently): (JSC::LazyClassStructure::constructorConcurrently): * runtime/LazyClassStructureInlines.h: Added. (JSC::LazyClassStructure::initLater): * runtime/LazyProperty.h: Added. (JSC::LazyProperty::Initializer::Initializer): (JSC::LazyProperty::LazyProperty): (JSC::LazyProperty::get): (JSC::LazyProperty::getConcurrently): * runtime/LazyPropertyInlines.h: Added. (JSC::LazyProperty::Initializer::set): (JSC::LazyProperty::initLater): (JSC::LazyProperty::setMayBeNull): (JSC::LazyProperty::set): (JSC::LazyProperty::visit): (JSC::LazyProperty::dump): (JSC::LazyProperty::callFunc): * runtime/Lookup.cpp: (JSC::setUpStaticFunctionSlot): * runtime/Lookup.h: (JSC::HashTableValue::function): (JSC::HashTableValue::functionLength): (JSC::HashTableValue::propertyGetter): (JSC::HashTableValue::propertyPutter): (JSC::HashTableValue::accessorGetter): (JSC::HashTableValue::accessorSetter): (JSC::HashTableValue::constantInteger): (JSC::HashTableValue::lexerValue): (JSC::HashTableValue::lazyCellPropertyOffset): (JSC::HashTableValue::lazyClassStructureOffset): (JSC::HashTableValue::lazyPropertyCallback): (JSC::getStaticPropertySlot): (JSC::getStaticValueSlot): (JSC::reifyStaticProperty): * runtime/PropertySlot.h: * runtime/TypedArrayType.h: 2016-05-03 Per Arne Vollan [Win] Remove Windows XP Compatibility Requirements https://bugs.webkit.org/show_bug.cgi?id=152899 Reviewed by Brent Fulgham. Windows XP is not supported anymore, we can remove workarounds. * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: (enableTerminationOnHeapCorruption): 2016-05-03 Joseph Pecoraro Web Inspector: console.assert should do far less work when the assertion is true https://bugs.webkit.org/show_bug.cgi?id=157297 Reviewed by Timothy Hatcher. * runtime/ConsoleClient.h: * runtime/ConsoleClient.cpp: (JSC::ConsoleClient::assertion): (JSC::ConsoleClient::assertCondition): Deleted. Rename, now that this will only get called when the assertion failed. * runtime/ConsoleObject.cpp: (JSC::consoleProtoFuncAssert): Avoid doing any work if the assertion succeeded. 2016-05-03 Joseph Pecoraro Unreviewed follow-up testapi fix after r200355. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): Revert back to non-enumerable. This matches our older behavior, we can decide to make this Enumerable later if needed. 2016-05-02 Joseph Pecoraro Web Inspector: Reflect.toString() should be [object Object] not [object Reflect] https://bugs.webkit.org/show_bug.cgi?id=157288 Reviewed by Darin Adler. * runtime/ReflectObject.cpp: * tests/stress/reflect.js: Added. 2016-05-02 Jon Davis Add Resource Timing entry to the Feature Status page. https://bugs.webkit.org/show_bug.cgi?id=157285 Reviewed by Timothy Hatcher. * features.json: 2016-05-02 Joseph Pecoraro Make console a namespace object (like Math/JSON), allowing functions to be called unbound https://bugs.webkit.org/show_bug.cgi?id=157286 Reviewed by Timothy Hatcher. This changes `console` to be a global namespace object, like `Math` and `JSON`. It just holds a bunch of functions, that can be used on their own, unbound. For example, `[1,2,3].forEach(console.log)` and `var log = console.log; log(1)` used to throw exceptions and now do not. Previously console was an Object/Prototype pair, so functions were on ConsolePrototype (console.__proto__.log) and they needed to be called Console objects as the `this` value. Now, `console` is just a standard object with a bunch of functions. Since there is no console prototype the functions can be passed around and called as expected and they will just do the right thing. For compatability with other browsers, `console` was made enumerable on the global object. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: Add new files and remove old files. * runtime/CommonIdentifiers.h: Add "console". * runtime/ConsoleObject.cpp: Renamed from Source/JavaScriptCore/runtime/ConsolePrototype.cpp. (JSC::ConsoleObject::ConsoleObject): (JSC::ConsoleObject::finishCreation): (JSC::valueToStringWithUndefinedOrNullCheck): (JSC::consoleLogWithLevel): (JSC::consoleProtoFuncDebug): (JSC::consoleProtoFuncError): (JSC::consoleProtoFuncLog): (JSC::consoleProtoFuncInfo): (JSC::consoleProtoFuncWarn): (JSC::consoleProtoFuncClear): (JSC::consoleProtoFuncDir): (JSC::consoleProtoFuncDirXML): (JSC::consoleProtoFuncTable): (JSC::consoleProtoFuncTrace): (JSC::consoleProtoFuncAssert): (JSC::consoleProtoFuncCount): (JSC::consoleProtoFuncProfile): (JSC::consoleProtoFuncProfileEnd): (JSC::consoleProtoFuncTakeHeapSnapshot): (JSC::consoleProtoFuncTime): (JSC::consoleProtoFuncTimeEnd): (JSC::consoleProtoFuncTimeStamp): (JSC::consoleProtoFuncGroup): (JSC::consoleProtoFuncGroupCollapsed): (JSC::consoleProtoFuncGroupEnd): Console functions no longer need to check if the this object is a Console object. They will always just work now. * runtime/MathObject.cpp: * runtime/MathObject.h: * runtime/ConsoleObject.h: Renamed from Source/JavaScriptCore/runtime/ConsolePrototype.h. (JSC::ConsoleObject::create): (JSC::ConsoleObject::createStructure): ConsoleObject is a basic object like MathObject. * runtime/JSConsole.cpp: Removed. * runtime/JSConsole.h: Removed. * runtime/JSGlobalObject.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): Remove JSConsole / ConsolePrototype in favor of the single ConsoleObject. 2016-05-02 Per Arne Vollan [Win] Clean up annoying compiler warnings https://bugs.webkit.org/show_bug.cgi?id=149813 Reviewed by Alex Christensen. * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::isWatchableWhenValid): * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * inspector/InspectorBackendDispatcher.cpp: (Inspector::BackendDispatcher::sendPendingErrors): * jit/JITCall32_64.cpp: (JSC::JIT::compileOpCall): * parser/Parser.cpp: (JSC::Parser::parseAssignmentExpression): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createWithInlineFrame): * runtime/Error.cpp: (JSC::addErrorInfoAndGetBytecodeOffset): * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::initializeNumberFormat): * runtime/JSObject.cpp: (JSC::JSObject::heapSnapshot): (JSC::callToPrimitiveFunction): * runtime/RegExpPrototype.cpp: (JSC::flagsString): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::StackFrame::functionStartColumn): 2016-05-02 Keith Miller ToThis should be able to be eliminated in Constant Folding https://bugs.webkit.org/show_bug.cgi?id=157213 Reviewed by Saam Barati. This patch enables eliminating the ToThis value when we have abstract interpreter indicates the node is not needed. Since there are Objects that override their ToThis behavior we first check if we can eliminate the node by looking at its speculated type. If the function is in strict mode then we can eliminate ToThis as long as the speculated type is not SpecObjectOther since that contains objects that may set OverridesToThis. If the function is not in strict mode then we can eliminate ToThis as long is the speculated type is an object that is not SpecObjectOther. If we can't eliminate with type information we can still eliminate the ToThis node with the proven structure set. When ToThis only sees structures that do not set OverridesToThis it can be eliminated. Additionally, if the function is in strict mode then we can eliminate ToThis as long as all only the object structures don't set OverridesToThis. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::isToThisAnIdentity): (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupToThis): * tests/stress/to-this-global-object.js: Added. (test): (test2): (get for): 2016-05-01 Skachkov Oleksandr Class contructor and methods shouldn't have "arguments" and "caller" https://bugs.webkit.org/show_bug.cgi?id=144238 Reviewed by Ryosuke Niwa. Added TypeError that is raised in case of access to properties 'arguments' or 'caller' of constructor or method of class. Actually TypeError already raised for most cases, except case with undeclared constructor e. g. class A {} (new A).constructor.caller (new A).constructor.arguments * runtime/JSFunction.cpp: (JSC::getThrowTypeErrorGetterSetter): (JSC::JSFunction::getOwnPropertySlot): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncThrowTypeErrorArgumentsAndCaller): * runtime/JSGlobalObjectFunctions.h: 2016-05-02 Yoav Weiss Move ResourceTiming behind a runtime flag https://bugs.webkit.org/show_bug.cgi?id=157133 Reviewed by Alex Christensen. * runtime/CommonIdentifiers.h: Added PerformanceEntry, PerformanceEntryList and PerformanceResourceTiming as property names. 2016-05-02 Yusuke Suzuki Assertion failure for bound function with custom prototype and Reflect.construct https://bugs.webkit.org/show_bug.cgi?id=157081 Reviewed by Saam Barati. We ensured `newTarget != exec->callee()`. However, it does not mean `newTarget.get("prototype") != exec->callee()->get("prototype")`. When the given `prototype` is the same to `baseStructure->sotredPrototype()`, it is unnecessary to create a new structure from this baseStructure. * bytecode/InternalFunctionAllocationProfile.h: (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase): * tests/stress/custom-prototype-may-be-same-to-original-one.js: Added. (shouldBe): (boundFunction): 2016-04-30 Konstantin Tokarev Guard ObjC-specific code in Heap.cpp with USE(FOUNDATION) https://bugs.webkit.org/show_bug.cgi?id=157236 Reviewed by Darin Adler. This also fixes build with GCC 4.8 which does not provide __has_include. * heap/Heap.cpp: 2016-04-30 Yusuke Suzuki Assertion failure for destructuring assignment with new.target and unary operator https://bugs.webkit.org/show_bug.cgi?id=157149 Reviewed by Saam Barati. The caller of parseDefaultValueForDestructuringPattern() should propagate errors. And this patch also cleans up createSavePoint and createSavePointForError; introducing SavePointWithError. * parser/Parser.cpp: (JSC::Parser::parseSourceElements): (JSC::Parser::parseDestructuringPattern): Add propagateErorr() for parseDefaultValueForDestructuringPattern. (JSC::Parser::parseAssignmentExpression): * parser/Parser.h: (JSC::Parser::restoreLexerState): (JSC::Parser::internalSaveState): (JSC::Parser::createSavePointForError): (JSC::Parser::createSavePoint): (JSC::Parser::internalRestoreState): (JSC::Parser::restoreSavePointWithError): (JSC::Parser::restoreSavePoint): * tests/stress/default-value-parsing-should-propagate-error.js: Added. (testSyntaxError): (testSyntaxError.f): 2016-04-28 Darin Adler First step in using "enum class" instead of "String" for enumerations in DOM https://bugs.webkit.org/show_bug.cgi?id=157163 Reviewed by Chris Dumez. * runtime/JSString.h: (JSC::jsStringWithCache): Deleted unneeded overload for AtomicString. 2016-04-29 Benjamin Poulain [JSC][ARMv7S] Arithmetic module results change when tiering up to DFG https://bugs.webkit.org/show_bug.cgi?id=157217 rdar://problem/24733432 Reviewed by Mark Lam. ARMv7's fmod() returns less accurate results than an integer division. Since we have integer div on ARMv7s, the results start changing when we reach DFG. In this patch, I change our fmod slow path to behave like the fast path on ARMv7s. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMod): (JSC::DFG::fmodAsDFGOperation): Deleted. * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/MathCommon.cpp: (JSC::isStrictInt32): * runtime/MathCommon.h: 2016-04-29 Joseph Pecoraro Web Inspector: Issues inspecting the inspector, pausing on breakpoints causes content to not load https://bugs.webkit.org/show_bug.cgi?id=157198 Reviewed by Timothy Hatcher. * inspector/InspectorBackendDispatcher.cpp: (Inspector::BackendDispatcher::sendResponse): While auditing the code, add a WTFMove. 2016-04-29 Mark Lam Make RegExp.prototype.test spec compliant. https://bugs.webkit.org/show_bug.cgi?id=155862 Reviewed by Saam Barati. * builtins/RegExpPrototype.js: (intrinsic.RegExpTestIntrinsic.test): * create_hash_table: - Delete obsoleted code. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::addToGraph): (JSC::DFG::ByteCodeParser::handleIntrinsicCall): - We now have 2 intrinsics for RegExp.prototype.test: RegExpTestIntrinsic and RegExpTestFastIntrinsic. RegExpTestIntrinsic maps to the entry at the top of the builtin ES6 RegExp.prototype.test. RegExpTestFastIntrinsic maps to the fast path in the builtin ES6 RegExp.prototype.test. Both will end up using the RegExpTest DFG node to implement the fast path of RegExp.prototype.test. RegExpTestIntrinsic will have some additional checks before the RegExpTest node. Those checks are for speculating that it is ok for us to take the fast path. * runtime/CommonIdentifiers.h: * runtime/Intrinsic.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): - Added the regExpTestFast function. - Also fixed the parameter length on 2 other functions that were erroneous. * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): (JSC::regExpProtoFuncTestFast): (JSC::regExpProtoFuncTest): Deleted. * runtime/RegExpPrototype.h: * tests/es6.yaml: 2016-04-29 Benjamin Poulain Extend math-pow-stable-results.js to get more information about the failure * tests/stress/math-pow-stable-results.js: 2016-04-29 Yusuke Suzuki Assertion failure for exception in "prototype" property getter and Reflect.construct https://bugs.webkit.org/show_bug.cgi?id=157084 Reviewed by Mark Lam. InternalFunction::createSubclassStrucuture may throw exceptions because it performs [[Get]] to look up the "prototype" object. The current assertion is invalid. We also found that Object constructor is not aware of new.target. This is filed[1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=157196 * runtime/InternalFunction.cpp: (JSC::InternalFunction::createSubclassStructure): * tests/stress/create-subclass-structure-may-throw-exception-when-getting-prototype.js: Added. (shouldThrow): (bf): 2016-04-29 Commit Queue Unreviewed, rolling out r200232. https://bugs.webkit.org/show_bug.cgi?id=157189 This change broke the Mac CMake build and its LayoutTest is failing and/or flaky on all platforms (Requested by ryanhaddad on #webkit). Reverted changeset: "Move ResourceTiming behind a runtime flag" https://bugs.webkit.org/show_bug.cgi?id=157133 http://trac.webkit.org/changeset/200232 2016-04-29 Yusuke Suzuki [ES6] RegExp.prototype.@@replace should use @isObject instead of `instanceof` for object guard https://bugs.webkit.org/show_bug.cgi?id=157124 Reviewed by Keith Miller. Use @isObject instead of `instanceof @Object`. The `instanceof` check is not enough to check Object Type. This fix itself is the same to r199647, and this patch is for RegExp.prototype.@@replace. * builtins/RegExpPrototype.js: (replace): * tests/stress/regexp-replace-in-other-realm-should-work.js: Added. (shouldBe): * tests/stress/regexp-replace-should-work-with-objects-not-inheriting-object-prototype.js: Added. (shouldBe): (regexp.exec): 2016-04-29 Yoav Weiss Move ResourceTiming behind a runtime flag https://bugs.webkit.org/show_bug.cgi?id=157133 Reviewed by Alex Christensen. * runtime/CommonIdentifiers.h: Added PerformanceEntry, PerformanceEntryList and PerformanceResourceTiming as property names. 2016-04-28 Joseph Pecoraro Remove unused bool parameter in CodeCache::getGlobalCodeBlock https://bugs.webkit.org/show_bug.cgi?id=157156 Reviewed by Mark Lam. The bool parameter appears to be isArrowFunctionContext, but the method's contents just get that property from the Executable, so the parameter is unnecessary and unused. * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): (JSC::CodeCache::getProgramCodeBlock): (JSC::CodeCache::getEvalCodeBlock): (JSC::CodeCache::getModuleProgramCodeBlock): * runtime/CodeCache.h: * runtime/Executable.cpp: (JSC::EvalExecutable::create): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::createEvalCodeBlock): * runtime/JSGlobalObject.h: 2016-04-28 Caitlin Potter [JSC] re-implement String#padStart and String#padEnd in JavaScript https://bugs.webkit.org/show_bug.cgi?id=157146 Reviewed by Saam Barati. * builtins/StringPrototype.js: (repeatCharactersSlowPath): (padStart): (padEnd): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): Deleted. (JSC::repeatStringPattern): Deleted. (JSC::padString): Deleted. (JSC::stringProtoFuncPadEnd): Deleted. (JSC::stringProtoFuncPadStart): Deleted. 2016-04-28 Joseph Pecoraro Web Inspector: Tweak auto attach initialization on some platforms https://bugs.webkit.org/show_bug.cgi?id=157150 Reviewed by Timothy Hatcher. * inspector/EventLoop.cpp: (Inspector::EventLoop::cycle): * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): 2016-04-28 Benjamin Poulain [JSC] Unify Math.pow() accross all tiers https://bugs.webkit.org/show_bug.cgi?id=157121 Reviewed by Geoffrey Garen. My previous optimizations of DFG compile time have slowly regressed Sunspider's math-partial-sums. What is happenning is baseline used a thunk for Math.pow() that has a special case for an exponent of -0.5, while DFG/FTL have other special cases for other exponents. The faster we get to DFG, the less time we spend in that fast case for -0.5. While looking into this, I discovered some correctness issues. Baseline optimizes y=-0.5 by turning it into 1/sqrt(). DFG/FTL optimize constant y=0.5 by turning it into sqrt(). The problem is sqrt() behaves differently for -0 and -Infinity. With sqrt(), negative numbers are undefined, and the result is NaN. With pow(), they have a result. Something else that has bothered me for a while is that Math.pow() with the same arguments give you different results in LLINT, Baseline, and DFG/FTL. This seems a bit dangerous for numerical stability. With this patch, I unify the behaviors for all tiers while keeping the "special cases". We have pow() that is super slow, but most callers don't need the full power. We have: -pow() with an exponent between 0 and 1000 is a fast path implemented by multiplication only. -pow(x, 0.5) is sqrt with special checks for negative values. -pow(x, -0.5) is sqrt with special checks for negative values. The C++ implementation handles all those optimizations too. This ensure you get the same results from LLINT to FTL. The thunk is eliminated, it was producing incorrect results and only optimized Sunspider's partial-sums. DFG gets the optimized integer, 0.5 and -0.5 cases since those are important for somewhat-hot code. DFG falls back to the C++ code for any non-obvious case. FTL gets the full C++ implementation inlined in B3. B3 knows how to eliminate all the dead cases so you get the best if your code is hot enough to reach FTL. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): Deleted. * dfg/DFGNode.h: (JSC::DFG::Node::convertToArithSqrt): Deleted. * dfg/DFGNodeType.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::compileArithPowIntegerFastPath): (JSC::DFG::SpeculativeJIT::compileArithPow): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArithPow): * jit/ThunkGenerators.cpp: (JSC::powThunkGenerator): Deleted. * jit/ThunkGenerators.h: * runtime/MathCommon.cpp: (JSC::operationMathPow): * runtime/MathCommon.h: * runtime/VM.cpp: (JSC::thunkGeneratorForIntrinsic): Deleted. * tests/stress/math-pow-stable-results.js: Added. Getting consistent results when tiering up is new. This test verify that results always remains the same as LLINT. * tests/stress/math-pow-with-constants.js: (testPowUsedAsSqrt): (powUsedAsOneOverSqrt): (testPowUsedAsOneOverSqrt): (powUsedAsSquare): (testPowUsedAsSquare): 2016-04-28 Mark Lam DebuggerScope::className() should not assert scope->isValid(). https://bugs.webkit.org/show_bug.cgi?id=157143 Reviewed by Keith Miller. DebuggerScope::className() should not assert scope->isValid() because the TypeProfiler logs objects it encounters, and may indirectly call JSObject::calculatedClassName() on those objects later, thereby calling DebuggerScope::className() on an invalidated DebuggerScope. The existing handling in DebuggerScope::className() for an invalidated scope (that returns a null string) is sufficient. * debugger/DebuggerScope.cpp: (JSC::DebuggerScope::className): 2016-04-28 Caitlin Potter [JSC] implement spec changes for String#padStart and String#padEnd https://bugs.webkit.org/show_bug.cgi?id=157139 Reviewed by Keith Miller. Previously, if the fill string was the empty string, it was treated as a single U+0020 SPACE character. Now, if this occurs, the original string is returned instead. Change was discussed at TC39 in March [1], and is reflected in new test262 tests for the feature. [1] https://github.com/tc39/tc39-notes/blob/master/es7/2016-03/march-29.md#stringprototypepadstartpadend * runtime/StringPrototype.cpp: (JSC::padString): * tests/es6/String.prototype_methods_String.prototype.padEnd.js: (TestFillerToString): (TestFillerEmptyString): * tests/es6/String.prototype_methods_String.prototype.padStart.js: (TestFillerToString): (TestFillerEmptyString): 2016-04-28 Skachkov Oleksandr Crash for non-static super property call in derived class constructor https://bugs.webkit.org/show_bug.cgi?id=157089 Reviewed by Darin Adler. Added tdz check of the 'this' before access to the 'super' for FunctionCallBracketNode, the same as it was done for FunctionCallDotNode. * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallBracketNode::emitBytecode): 2016-04-27 Mark Lam The GetterSetter structure needs a globalObject. https://bugs.webkit.org/show_bug.cgi?id=157120 Reviewed by Filip Pizlo. In r199170: , GetterSetter was promoted from being a JSCell to a JSObject. JSObject methods expect their structure to have a globalObject. For example, see JSObject::calculatedClassName(). GetterSetter was previously using a singleton getterSetterStructure owned by the VM. That singleton getterSetterStructure is not associated with any globalObjects. As a result, JSObject::calculatedClassName() will run into a null globalObject when it is called on a GetterSetter object. This patch removes the VM singleton getterSetterStructure, and instead, creates a getterSetterStructure for each JSGlobalObject. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGStructureRegistrationPhase.cpp: (JSC::DFG::StructureRegistrationPhase::run): * runtime/GetterSetter.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::functionStructure): (JSC::JSGlobalObject::boundFunctionStructure): (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): (JSC::JSGlobalObject::getterSetterStructure): (JSC::JSGlobalObject::nativeStdFunctionStructure): (JSC::JSGlobalObject::namedFunctionStructure): (JSC::JSGlobalObject::functionNameOffset): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2016-04-27 Keith Miller Unreviewed, Revert r199397 due to PLT regressions * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/ArrayPrototype.js: (concatSlowPath): Deleted. (concat): Deleted. * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): Deleted. * bytecode/BytecodeIntrinsicRegistry.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Deleted. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): Deleted. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): Deleted. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::compileIsJSArray): Deleted. (JSC::DFG::SpeculativeJIT::compileIsArrayObject): Deleted. (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor): Deleted. (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): Deleted. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): Deleted. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): Deleted. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): Deleted. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor): Deleted. (JSC::FTL::DFG::LowerDFGToB3::isArray): Deleted. * jit/JITOperations.h: * jsc.cpp: (GlobalObject::finishCreation): (functionDataLogValue): Deleted. * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::finishCreation): (JSC::arrayConstructorPrivateFuncIsArrayConstructor): * runtime/ArrayConstructor.h: (JSC::isArrayConstructor): Deleted. * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): (JSC::arrayProtoFuncConcat): (JSC::arrayProtoPrivateFuncIsJSArray): Deleted. (JSC::moveElements): Deleted. (JSC::arrayProtoPrivateFuncConcatMemcpy): Deleted. (JSC::arrayProtoPrivateFuncAppendMemcpy): Deleted. * runtime/ArrayPrototype.h: * runtime/CommonIdentifiers.h: * runtime/Intrinsic.h: * runtime/JSArray.cpp: (JSC::JSArray::fastConcatWith): (JSC::JSArray::appendMemcpy): Deleted. * runtime/JSArray.h: (JSC::JSArray::fastConcatType): (JSC::JSArray::createStructure): (JSC::isJSArray): * runtime/JSArrayInlines.h: Removed. (JSC::JSArray::memCopyWithIndexingType): Deleted. (JSC::JSArray::canFastCopy): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSType.h: * runtime/ObjectConstructor.h: (JSC::constructObject): Deleted. * tests/es6.yaml: * tests/stress/array-concat-spread-object.js: Removed. (arrayEq): Deleted. * tests/stress/array-concat-spread-proxy-exception-check.js: Removed. (arrayEq): Deleted. * tests/stress/array-concat-spread-proxy.js: Removed. (arrayEq): Deleted. * tests/stress/array-concat-with-slow-indexingtypes.js: Removed. (arrayEq): Deleted. * tests/stress/array-species-config-array-constructor.js: 2016-04-27 Michael Saboff REGRESSION(r200117): Crash in lowerDFGToB3::compileStringReplace() https://bugs.webkit.org/show_bug.cgi?id=157099 Reviewed by Saam Barati. Given that the DFGFixupPhase could mark the edge of child2 as StringUse, we need to lower that edge appropriately. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace): 2016-04-27 Mark Lam Address feedback from https://bugs.webkit.org/show_bug.cgi?id=157048#c5. https://bugs.webkit.org/show_bug.cgi?id=157096 Reviewed by Geoffrey Garen. 1. Check for USE(APPLE_INTERNAL_SDK) instead of __has_include(). 2. Rename webkitFirstSDKVersionWithInitConstructorSupport to firstSDKVersionWithInitConstructorSupport. * API/JSWrapperMap.mm: (supportsInitMethodConstructors): 2016-04-27 Mark Lam Restrict the availability of some JSC options to local debug builds only. https://bugs.webkit.org/show_bug.cgi?id=157058 Reviewed by Geoffrey Garen. 1. Each option will be given an availability flag. 2. The functionOverrides and useDollarVM (along with its alias, enableDollarVM) will have "Restricted" availability. 3. All other options will have “Normal” availability. 4. Any options with "Restricted" availability will only be accessible if function allowRestrictedOptions() returns true. 5. For now, allowRestrictedOptions() always returns false for release builds, and true for debug builds. If an option is "Restricted" and restricted options are not allowed, the VM will behave semantically as if that option does not exist at all: 1. Option dumps will not show the option. 2. Attempts to set the option will fail as if the option does not exist. Behind the scene, the option does exist, and is set to its default value (whatever that may be) once and only once on options initialization. * runtime/Options.cpp: (JSC::allowRestrictedOptions): (JSC::parse): (JSC::overrideOptionWithHeuristic): (JSC::Options::initialize): (JSC::Options::setOptionWithoutAlias): (JSC::Options::dumpOption): * runtime/Options.h: (JSC::Option::type): (JSC::Option::availability): (JSC::Option::isOverridden): 2016-04-27 Gavin Barraclough Enable separated heap by default on ios https://bugs.webkit.org/show_bug.cgi?id=156720 Unreviewed rollout - caused memory regression. * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2016-04-27 Benjamin Poulain Follow up for r200113 on 32bit I forgot to do the 32bit counterpart of r200113. The test fails on the bots. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2016-04-27 Alberto Garcia [GTK] Fails to build randomly when generating LLIntDesiredOffsets.h https://bugs.webkit.org/show_bug.cgi?id=155427 Reviewed by Carlos Garcia Campos. If the build directory contains the -I string, the script that generates LLIntDesiredOffsets.h will confuse it with an option to declare an include directory. In order to avoid that we should only use the arguments that start with -I when extracting the list of include directories, instead of using the ones that simply contain that string. * offlineasm/parser.rb: 2016-04-27 Saam barati JSC should have an option to allow global const redeclarations https://bugs.webkit.org/show_bug.cgi?id=157006 Reviewed by Geoffrey Garen. This patch implements an option that dictates whether const redeclarations at the program level will throw. This option defaults to true but allows users of JSC to set it to false. This option is per VM. This is needed for backwards compatibility with our old const implementation. * jsc.cpp: (GlobalObject::finishCreation): (functionShadowChickenFunctionsOnStack): (functionSetGlobalConstRedeclarationShouldNotThrow): (functionReadline): * runtime/Executable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): * runtime/JSGlobalLexicalEnvironment.cpp: (JSC::JSGlobalLexicalEnvironment::put): (JSC::JSGlobalLexicalEnvironment::isConstVariable): * runtime/JSGlobalLexicalEnvironment.h: (JSC::JSGlobalLexicalEnvironment::isEmpty): * runtime/VM.h: (JSC::VM::setGlobalConstRedeclarationShouldThrow): (JSC::VM::globalConstRedeclarationShouldThrow): * tests/stress/global-const-redeclaration-setting: Added. * tests/stress/global-const-redeclaration-setting-2.js: Added. (assert): * tests/stress/global-const-redeclaration-setting-3.js: Added. (assert): (catch): * tests/stress/global-const-redeclaration-setting-4.js: Added. (assert): (catch): * tests/stress/global-const-redeclaration-setting-5.js: Added. (assert): (catch): * tests/stress/global-const-redeclaration-setting.js: Added. (assert): * tests/stress/global-const-redeclaration-setting/first.js: Added. * tests/stress/global-const-redeclaration-setting/let.js: Added. * tests/stress/global-const-redeclaration-setting/second.js: Added. * tests/stress/global-const-redeclaration-setting/strict.js: Added. 2016-04-26 Michael Saboff [ES] Implement RegExp.prototype.@@replace and use it for String.prototype.replace https://bugs.webkit.org/show_bug.cgi?id=156562 Reviewed by Filip Pizlo. Added builtins for String.prototype.replace as well as RegExp.prototype[Symbol.replace]. The String.prototype.replace also has an intrinsic, StringPrototypeReplaceIntrinsic. This original intrinsic was copied to make StringPrototypeReplaceRegExpIntrinsic. The difference between the two intrinsics is that StringPrototypeReplaceIntrinsic has the same checks found in the new builtin hasObservableSideEffectsForStringReplace. We implement these primordial checks for StringPrototypeReplaceIntrinsic in two places. First, we do a trial check during ByteCode parsing time to see if the current RegExp.prototype properties have changed from the original. If they have, we don't inline the intrinsic. Later, in the fixup phase, we add nodes to the IR to emit the checks at runtime. The new intrinsic StringPrototypeReplaceRegExpIntrinsic is only available via the private @replaceUsingRegExp, which is called in the String.prototype.replace builtin. It is only called after hasObservableSideEffectsForStringReplace has been called Both of these intrinsics are needed, because the JS code containing String.replace() calls runs initially in the LLint and then the baseline JIT. Even after the function tiers up to the DFG JIT, the inlining budget may not allow StringPrototypeReplaceIntrinsic to be inlined. Having StringPrototypeReplaceRegExpIntrinsic allows for the String.prototype.replace builtin to get reasonable performance before the other intrinsic is inlined or when it can't. * builtins/RegExpPrototype.js: (match): (getSubstitution): (replace): (search): (split): * builtins/StringPrototype.js: (repeat): (hasObservableSideEffectsForStringReplace): (intrinsic.StringPrototypeReplaceIntrinsic.replace): (localeCompare): New builtins for String.prototype.replace and RegExp.prototype[Symbol.replace]. * bytecode/BytecodeIntrinsicRegistry.cpp: * bytecode/BytecodeIntrinsicRegistry.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupGetAndSetLocalsInBlock): (JSC::DFG::FixupPhase::tryAddStringReplacePrimordialChecks): (JSC::DFG::FixupPhase::checkArray): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::getRegExpPrototypeProperty): * dfg/DFGGraph.h: (JSC::DFG::Graph::getRegExpPrototypeProperty): * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * 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): * runtime/CommonIdentifiers.h: * runtime/Intrinsic.h: * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::replace): (JSC::stringProtoFuncReplaceUsingRegExp): (JSC::stringProtoFuncReplaceUsingStringSearch): (JSC::operationStringProtoFuncReplaceGeneric): (JSC::stringProtoFuncReplace): Deleted. Added StringReplaceRegExp intrinsic. Added checks for RegExp profiled arguments to StringReplace that mirror what is in hasObservableSideEffectsForStringReplace(). If we aren't able to add the checks, we OSR exit. Add Graph::getPrimordialRegExpPrototypeProperty() as a helper to get the primordial values from RegExp.prototype. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): Added @regExpPrototypeSymbolReplace and @hasObservableSideEffectsForStringReplace here instead og String.prototype so that we reduce the number of objects we have to traverse. * tests/es6.yaml: Changed expectations for the various replace related tests to passing. * tests/stress/regexp-replace-proxy.js: (assert): (let.getProxyNullExec.new.Proxy): (let.getSetProxyNullExec.new.Proxy): (get resetTracking): (let.getSetProxyMatches_comma.new.Proxy): (set get getSetProxyNullExec): (let.getSetProxyReplace_phoneNumber.new.Proxy): (set get getSetProxyMatches_comma): (let.getSetProxyReplaceUnicode_digit_nonGreedy.new.Proxy): (set get resetTracking): * tests/stress/string-replace-proxy.js: (assert): (let.getSetProxyReplace.new.Proxy.replace): New tests. 2016-04-26 Mark Lam Gardening: speculative build fix. Not reviewed. * API/JSWrapperMap.mm: 2016-04-26 Mark Lam Update the compatibility version check for the ObjC API's InitConstructorSupport to use dyld_get_program_sdk_version(). https://bugs.webkit.org/show_bug.cgi?id=157048 Reviewed by Geoffrey Garen. * API/JSWrapperMap.mm: (supportsInitMethodConstructors): (getJSExportProtocol): 2016-04-26 Benjamin Poulain [JSC] GetByVal on Undecided use its children before its OSR Exit https://bugs.webkit.org/show_bug.cgi?id=157046 Reviewed by Mark Lam. Very silly bug: GetByVal on Undecided uses its children before the speculationCheck(). If we fail the speculation, we have already lost how to recover the values. The existing tests did not catch this because we tier up to B3 before such Exits happen. B3 has explicit liveness and did not suffer from this bug. The new test has a smaller warmup to exercise the OSR Exit in DFG instead of FTL. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * tests/stress/get-by-val-on-undecided-out-of-bounds.js: Added. (string_appeared_here.opaqueGetByValKnownArray): 2016-04-26 Skachkov Oleksandr calling super() a second time in a constructor should throw https://bugs.webkit.org/show_bug.cgi?id=151113 Reviewed by Saam Barati. Currently, our implementation checks if 'super()' was called in a constructor more than once and raises a RuntimeError before the second call. According to the spec we need to raise an error just after the second super() is finished and before the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour. To implement this behavior this patch adds a new op code, op_is_empty, that is used to check if 'this' is empty. * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitIsEmpty): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallValueNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_is_empty): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_is_empty): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * tests/stress/class-syntax-double-constructor.js: Added. 2016-04-26 Mark Lam Changed jsc options title to be more descriptive. https://bugs.webkit.org/show_bug.cgi?id=157036 Reviewed by Joseph Pecoraro. Let the title for --dumpOptions be "Modified JSC runtime options:" since it only dumps overridden options. The title for --options will remain "All JSC runtime options:" since it dumps all all options with verbose detail. * jsc.cpp: (CommandLine::parseArguments): 2016-04-26 Oliver Hunt Enable separated heap by default on ios https://bugs.webkit.org/show_bug.cgi?id=156720 Unreviewed roll-in of this change. There is only one additional allocation involved in this logic, and that is a duplicate mapping. Either our tools are not report real memory usage or this revision is not responsible for the regression. * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2016-04-26 Filip Pizlo DFG backends shouldn't emit type checks at KnownBlah edges https://bugs.webkit.org/show_bug.cgi?id=157025 Reviewed by Michael Saboff. This fixes a crash I found when browsing Bing maps with forceEagerCompilation. I include a 100% repro test case. The issue is that our code still doesn't fully appreciate the devious implications of KnownBlah use kinds. Consider KnownCell for example. It means: "trust me, I know that this value will be a cell". You aren't required to provide a proof when you use KnownCell. Often, we use it as a result of a path-sensitive proof. The abstract interpreter is not path-sensitive, so AI will be absolutely sure that the KnownCell use might see a non-cell. This can lead to debug assertions (which this change removes) and it can lead to the backends emitting a type check. That type check can be pure evil if the node that has this edge does not have an exit origin. Such a node would have passed validation because the validater would have thought that the node cannot exit (after all, according to the IR semantics, there is no speculation at KnownCell). This comprehensively fixes the issue by recognizing that Foo(KnownCell:@x) means: I have already proved that by the time you start executing Foo, @x will already be a cell. I cannot tell you how I proved this but you can rely on it anyway. AI now takes advantage of this meaning and will always do filtering of KnownBlah edges regardless of whether the backend actually emits any type checks for those edges. Since the filtering runs before the backend, the backend will not emit any checks because it will know that the edge was already checked (by whatever mechanism we used when we made the edge KnownBlah). Note that it's good that we found this bug now. The DFG currently does very few sparse-conditional or path-sensitive optimizations, but it will probably do more in the future. The bug happens because GetByOffset and friends can achieve path-sensitive proofs via watchpoints on the inferred type. Normally, AI can follow along with this proof. But in the example program, and on Bing maps, we would GCSE one GetByOffset with another that had a weaker proven type. That turned out to be completely sound - between the two GetByOffset's there was a Branch to null check it. The inferred type of the second GetByOffset ended up knowing that it cannot be null because null only occurred in some structures but not others. If we added more sparse-conditional stuff to Branch, then AI would know how to follow along with the proof but it would also create more situations where we'd have a path-sensitive proof. So, it's good that we're now getting this right. * dfg/DFGAbstractInterpreter.h: (JSC::DFG::AbstractInterpreter::filterEdgeByUse): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEdges): (JSC::DFG::AbstractInterpreter::executeKnownEdgeTypes): (JSC::DFG::AbstractInterpreter::verifyEdge): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): * tests/stress/path-sensitive-known-cell-crash.js: Added. (bar): (foo): 2016-04-26 Gavin Barraclough Enable separated heap by default on ios https://bugs.webkit.org/show_bug.cgi?id=156720 Unreviewed rollout - caused memory regression. * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2016-04-26 Joseph Pecoraro Improve jsc --help and making sampling options https://bugs.webkit.org/show_bug.cgi?id=157015 Reviewed by Saam Barati. Simplify sampling options to be easier to remember: * --reportSamplingProfilerData => --sample * --samplingProfilerTimingInterval => --sampleInterval Update the --help to mention --sample, and restore the behavior of --options outputing all possible options so you can discover which options are available. * jsc.cpp: (printUsageStatement): (CommandLine::parseArguments): Improve help and modify option dumping. * runtime/Options.h: * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::SamplingProfiler): Rename the sampling interval option. 2016-04-26 Commit Queue Unreviewed, rolling out r200083. https://bugs.webkit.org/show_bug.cgi?id=157033 It brokes the debug build (Requested by gskachkov on #webkit). Reverted changeset: "calling super() a second time in a constructor should throw" https://bugs.webkit.org/show_bug.cgi?id=151113 http://trac.webkit.org/changeset/200083 2016-04-26 Skachkov Oleksandr calling super() a second time in a constructor should throw https://bugs.webkit.org/show_bug.cgi?id=151113 Reviewed by Saam Barati. Currently, our implementation checks if 'super()' was called in a constructor more than once and raises a RuntimeError before the second call. According to the spec we need to raise an error just after the second super() is finished and before the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour. To implement this behavior this patch adds a new op code, op_is_empty, that is used to check if 'this' is empty. * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitIsEmpty): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallValueNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_is_empty): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_is_empty): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * tests/stress/class-syntax-double-constructor.js: Added. 2016-04-25 Ryosuke Niwa Remove the build flag for template elements https://bugs.webkit.org/show_bug.cgi?id=157022 Reviewed by Daniel Bates. * Configurations/FeatureDefines.xcconfig: 2016-04-25 Benjamin Poulain [JSC] Constant folding of UInt32ToNumber is incorrect https://bugs.webkit.org/show_bug.cgi?id=157011 rdar://problem/25769641 Reviewed by Geoffrey Garen. UInt32ToNumber should return the unsigned 32bit value of its child. The abstract interpreter fails to do that when handling Int52. None of the tests caught that because the bytecode generator already fold the operation if given a constant. If the constant is not visible from the bytecode generator (for example because it comes from an inlined call), then the abstract interpreter folding was producing invalid results. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * tests/stress/uint32-to-number-constant-folding.js: Added. (uint32ToNumberMinusOne): (uint32ToNumberMinusOnePlusInteger): (inlineMinusOne): (uint32ToNumberOnHiddenMinusOne): (uint32ToNumberOnHiddenMinusOnePlusInteger): (inlineLargeNegativeNumber1): (inlineLargeNegativeNumber2): (inlineLargeNegativeNumber3): (uint32ToNumberOnHiddenLargeNegativeNumber1): (uint32ToNumberOnHiddenLargeNegativeNumber2): (uint32ToNumberOnHiddenLargeNegativeNumber3): 2016-04-25 Fujii Hironori Heap corruption is detected when destructing JSGlobalObject https://bugs.webkit.org/show_bug.cgi?id=156831 Reviewed by Mark Lam. WebKit uses CRT static library on Windows. Each copy of the CRT library has its own heap manager, allocating memory in one CRT library and passing the pointer across a DLL boundary to be freed by a different copy of the CRT library is a potential cause for heap corruption. Potential Errors Passing CRT Objects Across DLL Boundaries JSGlobalObject::createRareDataIfNeeded is inlined but JSGlobalObject::~JSGlobalObject is not. Then, the heap of allocating JSGlobalObjectRareData is WebKit.dll, but deallocating JavaScriptCore.dll. Adding WTF_MAKE_FAST_ALLOCATED to JSGlobalObjectRareData ensures heap consistency of it. WTF::Lock also needs WTF_MAKE_FAST_ALLOCATED because it is allocated from the inlined constructor of JSGlobalObjectRareData. Test: fast/dom/insertedIntoDocument-iframe.html * runtime/JSGlobalObject.h: Add WTF_MAKE_FAST_ALLOCATED to JSGlobalObjectRareData. 2016-04-25 Michael Saboff Crash using @tryGetById in DFG https://bugs.webkit.org/show_bug.cgi?id=156992 Reviewed by Filip Pizlo. We need to spill live registers when compiling TryGetById in DFG. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileTryGetById): * tests/stress/regress-156992.js: New test. (tryMultipleGetByIds): (test): 2016-04-25 Saam barati We don't have to parse a function's parameters every time if the function is in the source provider cache https://bugs.webkit.org/show_bug.cgi?id=156943 Reviewed by Filip Pizlo. This patch makes a few changes to make parsing inner functions faster. First, we were always parsing an inner function's parameter list using the templatized TreeBuiler. This means if our parent scope was building an AST, we ended up building AST nodes for the inner function's parameter list even though these nodes would go unused. This patch fixes that to *always* build an inner function's parameter list using the SyntaxChecker. (Note that this is consistent now with always building an inner function's body with a SyntaxChecker.) Second, we were always parsing an inner function's parameter list even if we had that function saved in the source provider cache. I've fixed that bug and made it so that we skip over the parsing of a function's parameter list when it's in the source provider cache. We could probably enhance this in the future to skip over the entirety of a function starting at the "function" keyword or any other start of the function (depending on the function type: arrow function, method, etc). This patch also renames a few fields. First, I fixed a typo from "tocken" => "token" for a few field names. Secondly, I renamed a field that was called 'bodyStartColumn' to 'parametersStartColumn' because the field really held the parameter list's start column. I'm benchmarking this as a 1.5-2% octane/jquery speedup on a 15" MBP. * parser/ASTBuilder.h: (JSC::ASTBuilder::createFunctionExpr): (JSC::ASTBuilder::createMethodDefinition): (JSC::ASTBuilder::createArrowFunctionExpr): (JSC::ASTBuilder::createGetterOrSetterProperty): (JSC::ASTBuilder::createFuncDeclStatement): * parser/Lexer.cpp: (JSC::Lexer::lex): * parser/Lexer.h: (JSC::Lexer::currentPosition): (JSC::Lexer::positionBeforeLastNewline): (JSC::Lexer::lastTokenLocation): (JSC::Lexer::setLastLineNumber): (JSC::Lexer::lastLineNumber): (JSC::Lexer::prevTerminator): * parser/Parser.cpp: (JSC::Parser::parseInner): (JSC::Parser::parseGeneratorFunctionSourceElements): (JSC::Parser::parseFunctionBody): (JSC::stringForFunctionMode): (JSC::Parser::parseFunctionParameters): (JSC::Parser::parseFunctionInfo): * parser/Parser.h: (JSC::Scope::usedVariablesContains): (JSC::Scope::forEachUsedVariable): (JSC::Scope::useVariable): (JSC::Scope::copyCapturedVariablesToVector): (JSC::Scope::fillParametersForSourceProviderCache): (JSC::Scope::restoreFromSourceProviderCache): * parser/ParserFunctionInfo.h: * parser/SourceProviderCacheItem.h: (JSC::SourceProviderCacheItem::endFunctionToken): (JSC::SourceProviderCacheItem::usedVariables): (JSC::SourceProviderCacheItem::SourceProviderCacheItem): 2016-04-25 Mark Lam Renaming SpecInt32, SpecInt52, MachineInt to SpecInt32Only, SpecInt52Only, AnyInt. https://bugs.webkit.org/show_bug.cgi?id=156941 Reviewed by Filip Pizlo. While looking at https://bugs.webkit.org/show_bug.cgi?id=153431, it was decided that SpecInt32Only, SpecInt52Only, and AnyInt would be better names for SpecInt32, SpecInt52, and MachineInt. Let's do a bulk rename. This is only a renaming patch, and deletion of a piece of unused code. There are no semantic changes. * bindings/ScriptValue.cpp: (Inspector::jsToInspectorValue): * bytecode/SpeculatedType.cpp: (JSC::dumpSpeculation): (JSC::speculationToAbbreviatedString): (JSC::speculationFromValue): (JSC::leastUpperBoundOfStrictlyEquivalentSpeculations): (JSC::typeOfDoubleNegation): (JSC::typeOfDoubleRounding): * bytecode/SpeculatedType.h: (JSC::isInt32Speculation): (JSC::isInt32OrBooleanSpeculation): (JSC::isInt32SpeculationForArithmetic): (JSC::isInt32OrBooleanSpeculationForArithmetic): (JSC::isInt32OrBooleanSpeculationExpectingDefined): (JSC::isInt52Speculation): (JSC::isAnyIntSpeculation): (JSC::isAnyIntAsDoubleSpeculation): (JSC::isDoubleRealSpeculation): (JSC::isMachineIntSpeculation): Deleted. (JSC::isInt52AsDoubleSpeculation): Deleted. (JSC::isIntegerSpeculation): Deleted. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::set): (JSC::DFG::AbstractValue::fixTypeForRepresentation): (JSC::DFG::AbstractValue::checkConsistency): (JSC::DFG::AbstractValue::resultType): * dfg/DFGAbstractValue.h: (JSC::DFG::AbstractValue::validateType): * dfg/DFGArgumentsUtilities.cpp: (JSC::DFG::emitCodeToGetArgumentsArrayLength): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupToThis): (JSC::DFG::FixupPhase::observeUseKindOnNode): (JSC::DFG::FixupPhase::fixIntConvertingEdge): (JSC::DFG::FixupPhase::fixIntOrBooleanEdge): (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge): (JSC::DFG::FixupPhase::truncateConstantToInt32): (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd): (JSC::DFG::FixupPhase::prependGetArrayLength): (JSC::DFG::FixupPhase::fixupChecksInBlock): * dfg/DFGGraph.h: (JSC::DFG::Graph::addShouldSpeculateInt32): (JSC::DFG::Graph::addShouldSpeculateAnyInt): (JSC::DFG::Graph::binaryArithShouldSpeculateInt32): (JSC::DFG::Graph::binaryArithShouldSpeculateAnyInt): (JSC::DFG::Graph::unaryArithShouldSpeculateInt32): (JSC::DFG::Graph::unaryArithShouldSpeculateAnyInt): (JSC::DFG::Graph::addShouldSpeculateMachineInt): Deleted. (JSC::DFG::Graph::binaryArithShouldSpeculateMachineInt): Deleted. (JSC::DFG::Graph::unaryArithShouldSpeculateMachineInt): Deleted. * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGNode.cpp: (JSC::DFG::Node::convertToIdentityOn): * dfg/DFGNode.h: (JSC::DFG::Node::asNumber): (JSC::DFG::Node::isAnyIntConstant): (JSC::DFG::Node::asAnyInt): (JSC::DFG::Node::isBooleanConstant): (JSC::DFG::Node::shouldSpeculateInt32OrBooleanExpectingDefined): (JSC::DFG::Node::shouldSpeculateAnyInt): (JSC::DFG::Node::shouldSpeculateDouble): (JSC::DFG::Node::shouldSpeculateNumber): (JSC::DFG::Node::isMachineIntConstant): Deleted. (JSC::DFG::Node::asMachineInt): Deleted. (JSC::DFG::Node::shouldSpeculateMachineInt): Deleted. * dfg/DFGOSREntry.cpp: (JSC::DFG::OSREntryData::dumpInContext): (JSC::DFG::prepareOSREntry): * dfg/DFGOSREntry.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::handleNode): (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compileArithAdd): (JSC::DFG::SpeculativeJIT::compileArithSub): (JSC::DFG::SpeculativeJIT::compileArithNegate): (JSC::DFG::SpeculativeJIT::speculateInt32): (JSC::DFG::SpeculativeJIT::speculateNumber): (JSC::DFG::SpeculativeJIT::speculateMisc): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::spill): (JSC::DFG::SpeculativeJIT::isKnownInteger): (JSC::DFG::SpeculativeJIT::isKnownCell): (JSC::DFG::SpeculativeJIT::isKnownNotInteger): (JSC::DFG::SpeculativeJIT::isKnownNotNumber): (JSC::DFG::SpeculativeJIT::isKnownNotCell): (JSC::DFG::SpeculativeJIT::isKnownNotOther): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateInt52): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::emitBranch): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::blessBoolean): (JSC::DFG::SpeculativeJIT::convertAnyInt): (JSC::DFG::SpeculativeJIT::speculateAnyInt): (JSC::DFG::SpeculativeJIT::speculateDoubleRepAnyInt): (JSC::DFG::SpeculativeJIT::convertMachineInt): Deleted. (JSC::DFG::SpeculativeJIT::speculateMachineInt): Deleted. (JSC::DFG::SpeculativeJIT::speculateDoubleRepMachineInt): Deleted. * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): (JSC::DFG::isNumerical): (JSC::DFG::isDouble): * dfg/DFGValidate.cpp: * dfg/DFGVariableAccessData.cpp: (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat): (JSC::DFG::VariableAccessData::couldRepresentInt52Impl): (JSC::DFG::VariableAccessData::flushFormat): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileInt52Constant): (JSC::FTL::DFG::LowerDFGToB3::compileInt52Rep): (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub): (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush): (JSC::FTL::DFG::LowerDFGToB3::lowInt32): (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToInt32): (JSC::FTL::DFG::LowerDFGToB3::isInt32): (JSC::FTL::DFG::LowerDFGToB3::isNotInt32): (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52): (JSC::FTL::DFG::LowerDFGToB3::doubleToStrictInt52): (JSC::FTL::DFG::LowerDFGToB3::speculate): (JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther): (JSC::FTL::DFG::LowerDFGToB3::speculateAnyInt): (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepReal): (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepAnyInt): (JSC::FTL::DFG::LowerDFGToB3::speculateMachineInt): Deleted. (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepMachineInt): Deleted. * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_profile_type): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_profile_type): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::isInt52): (JSC::JSValue::isAnyInt): (JSC::JSValue::asAnyInt): (JSC::JSValue::isMachineInt): Deleted. (JSC::JSValue::asMachineInt): Deleted. * runtime/RuntimeType.cpp: (JSC::runtimeTypeForValue): (JSC::runtimeTypeAsString): * runtime/RuntimeType.h: * runtime/TypeSet.cpp: (JSC::TypeSet::dumpTypes): (JSC::TypeSet::displayName): (JSC::TypeSet::inspectorTypeSet): (JSC::TypeSet::toJSONString): 2016-04-24 Yusuke Suzuki [JSC] Optimize JSON.parse string fast path https://bugs.webkit.org/show_bug.cgi?id=156953 Reviewed by Mark Lam. This patch further optimizes the string parsing fast path. Previously, we generated the WTF::String to hold the ownership of the token's string. And always copied the token in LiteralParser side. Instead, we hold the ownership of the token String by the StringBuilder in LiteralParser::Lexer, and remove the processing in the string parsing fast path. This patch gives us stable 1 - 2.5% improvement in Kraken json-parse-financial. Baseline Modified json-parse-financial 41.383+-0.248 ^ 40.894+-0.189 ^ definitely 1.0120x faster * runtime/LiteralParser.cpp: (JSC::LiteralParser::tryJSONPParse): (JSC::LiteralParser::Lexer::lex): (JSC::LiteralParser::Lexer::lexStringSlow): (JSC::LiteralParser::parse): (JSC::LiteralParser::Lexer::lexString): Deleted. * runtime/LiteralParser.h: (JSC::LiteralParser::tryLiteralParse): (JSC::LiteralParser::Lexer::currentToken): (JSC::LiteralParser::Lexer::LiteralParserTokenPtr::LiteralParserTokenPtr): (JSC::LiteralParser::Lexer::LiteralParserTokenPtr::operator->): 2016-04-24 Filip Pizlo and Andy VanWagoner [INTL] Implement String.prototype.localeCompare in ECMA-402 https://bugs.webkit.org/show_bug.cgi?id=147607 Reviewed by Darin Adler. Part of this change is just rolling 194394 back in. The other part is making that not a regression on CDjs. Other than the fact that it uses bound functions, the problem with this new localeCompare implementation is that it uses the arguments object. It uses it in a way that *seems* like ArgumentsEliminationPhase ought to handle, but to my surprise it didn't: - If we have a ForceExit GetByVal on the arguments object, we would previously assume that it escaped. That's false since we just exit at ForceExit. On the other hand we probably should be pruning unreachable paths before we get here, but that's a separate issue. I don't want to play with phase order right now. - If we have a OutOfBounds GetByVal on the arguments object, then the best that would previously happen is that we'd compile it into an in-bounds arguments access. That's quite bad, as Andy's localeCompare illustrates: it uses out-of-bounds access on the arguments object to detect if an argument was passed. This change introduces an OutOfBounds version of GetMyArgumentByVal for this purpose. This change required registering sane chain watchpoints. In the process, I noticed that the old way of doing it had a race condition: we might register watchpoints for the structure that had become insane. This change introduces a double-checking idiom that I believe works because once the structure becomes insane it can't go back to sane and watchpoints registration already involves executing the hardest possible fences. * builtins/StringPrototype.js: (repeat): (localeCompare): (search): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnString): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): * ftl/FTLTypedPointer.h: (JSC::FTL::TypedPointer::TypedPointer): (JSC::FTL::TypedPointer::operator bool): (JSC::FTL::TypedPointer::heap): (JSC::FTL::TypedPointer::operator!): Deleted. * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): 2016-04-23 Filip Pizlo Unreviewed, unbreak cloop. * runtime/VM.cpp: (JSC::VM::getHostFunction): 2016-04-22 Filip Pizlo Speed up bound functions a bit https://bugs.webkit.org/show_bug.cgi?id=156889 Reviewed by Saam Barati. Bound functions are hard to optimize because JSC doesn't have a good notion of non-JS code that does JS-ey things like make JS calls. What I mean by "non-JS code" is code that did not originate from JS source. A bound function does a highly polymorphic call to the target stored in the JSBoundFunction. Prior to this change, we represented it as native code that used the generic native->JS call API. That's not cheap. We could model bound functions using a builtin, but it's not clear that this would be easy to grok, since so much of the code would have to access special parts of the JSBoundFunction type. Doing it that way might solve the performance problems but it would mean extra work to arrange for the builtin to have speedy access to the call target, the bound this, and the bound arguments. Also, optimizing bound functions that way would mean that bound function performance would be gated on the performance of a bunch of other things in our system. For example, we'd want this polymorphic call to be handled like the funnel that it is: if we're compiling the bound function's outgoing call with no context then we should compile it as fully polymorphic but we can let it assume basic sanity like that the callee is a real function; but if we're compiling the call with any amount of calling context then we want to use normal call IC's. Since the builtin path wouldn't lead to a simpler patch and since I think that the VM will benefit in the long run from using custom handling for bound functions, I kept the native code and just added Intrinsic/thunk support. This just adds an Intrinsic for bound function calls where the JSBoundFunction targets a JSFunction instance and has no bound arguments (only bound this). This intrinsic is currently only implemented as a thunk and not yet recognized by the DFG bytecode parser. I needed to loosen some restrictions to do this. For one, I was really tired of our bad use of ENABLE(JIT) conditionals, which made it so that any serious client of Intrinsics would have to have #ifdefs. Really what should happen is that if the JIT is not enabled then we just ignore intrinsics. Also, the code was previously assuming that having a native constructor and knowing the Intrinsic for your native call were mutually exclusive. This change makes it possible to have a native executable that has a custom function, custom constructor, and an Intrinsic. This is a >4x speed-up on bound function calls with no bound arguments. In the future, we should teach the DFG Intrinsic handling to deal with bound functions and we should teach the inliner (and ByteCodeParser::handleCall() in general) how to deal with the function call inside the bound function. That would be super awesome. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::timesPtr): (JSC::AbstractMacroAssembler::Address::withOffset): (JSC::AbstractMacroAssembler::BaseIndex::BaseIndex): (JSC::MacroAssemblerType>::Address::indexedBy): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::storeCell): (JSC::AssemblyHelpers::loadCell): (JSC::AssemblyHelpers::storeValue): (JSC::AssemblyHelpers::emitSaveCalleeSaves): (JSC::AssemblyHelpers::emitSaveThenMaterializeTagRegisters): (JSC::AssemblyHelpers::emitRestoreCalleeSaves): (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters): (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer): * jit/JITThunks.cpp: (JSC::JITThunks::ctiNativeTailCall): (JSC::JITThunks::ctiNativeTailCallWithoutSavedTags): (JSC::JITThunks::ctiStub): (JSC::JITThunks::hostFunctionStub): (JSC::JITThunks::clearHostFunctionStubs): * jit/JITThunks.h: * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn): (JSC::SpecializedThunkJIT::tagReturnAsInt32): (JSC::SpecializedThunkJIT::emitSaveThenMaterializeTagRegisters): Deleted. (JSC::SpecializedThunkJIT::emitRestoreSavedTagRegisters): Deleted. * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): (JSC::nativeForGenerator): (JSC::nativeCallGenerator): (JSC::nativeTailCallGenerator): (JSC::nativeTailCallWithoutSavedTagsGenerator): (JSC::nativeConstructGenerator): (JSC::randomThunkGenerator): (JSC::boundThisNoArgsFunctionCallGenerator): * jit/ThunkGenerators.h: * runtime/Executable.cpp: (JSC::NativeExecutable::create): (JSC::NativeExecutable::destroy): (JSC::NativeExecutable::createStructure): (JSC::NativeExecutable::finishCreation): (JSC::NativeExecutable::NativeExecutable): (JSC::ScriptExecutable::ScriptExecutable): * runtime/Executable.h: * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncBind): * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototypeGetterCompare): * runtime/Intrinsic.h: * runtime/JSBoundFunction.cpp: (JSC::boundThisNoArgsFunctionCall): (JSC::boundFunctionCall): (JSC::boundThisNoArgsFunctionConstruct): (JSC::boundFunctionConstruct): (JSC::getBoundFunctionStructure): (JSC::JSBoundFunction::create): (JSC::JSBoundFunction::customHasInstance): (JSC::JSBoundFunction::JSBoundFunction): * runtime/JSBoundFunction.h: (JSC::JSBoundFunction::targetFunction): (JSC::JSBoundFunction::boundThis): (JSC::JSBoundFunction::boundArgs): (JSC::JSBoundFunction::createStructure): (JSC::JSBoundFunction::offsetOfTargetFunction): (JSC::JSBoundFunction::offsetOfBoundThis): * runtime/JSFunction.cpp: (JSC::JSFunction::lookUpOrCreateNativeExecutable): (JSC::JSFunction::create): * runtime/VM.cpp: (JSC::thunkGeneratorForIntrinsic): (JSC::VM::getHostFunction): * runtime/VM.h: (JSC::VM::getCTIStub): (JSC::VM::exceptionOffset): 2016-04-22 Joonghun Park [JSC] Fix build break since r199866 https://bugs.webkit.org/show_bug.cgi?id=156892 Reviewed by Darin Adler. * runtime/MathCommon.cpp: Follow up to r199913. Remove 'include cmath' in cpp file. 2016-04-22 Yusuke Suzuki [JSC] Optimize number parsing and string parsing in LiteralParser https://bugs.webkit.org/show_bug.cgi?id=156896 Reviewed by Mark Lam. This patch aim to improve JSON.parse performance. Major 2 optimizations are included. 1. Change `double result` to `int32_t result` in integer parsing case. We already have the optimized path for integer parsing, when it's digits are less than 10. At that case, the maximum number is 999999999, and the minimum number is -99999999. The both are in range of Int32. So We can use int32_t for accumulation instead of double. 2. Add the string parsing fast / slow cases. We add the fast case for string parsing, which does not include any escape sequences. Both optimizations improve Kraken json-parse-financial, roughly 3.5 - 4.5%. json-parse-financial 49.128+-1.589 46.979+-0.912 might be 1.0457x faster * runtime/LiteralParser.cpp: (JSC::isJSONWhiteSpace): (JSC::isSafeStringCharacter): (JSC::LiteralParser::Lexer::lexString): (JSC::LiteralParser::Lexer::lexStringSlow): (JSC::LiteralParser::Lexer::lexNumber): * runtime/LiteralParser.h: 2016-04-22 Joseph Pecoraro Web Inspector: Source directives lost when using Function constructor repeatedly https://bugs.webkit.org/show_bug.cgi?id=156863 Reviewed by Geoffrey Garen. Source directives (sourceURL and sourceMappingURL) are normally accessed through the SourceProvider and normally set when the script is parsed. However, when a CodeCache lookup skips parsing, the new SourceProvider never gets the directives (sourceURL/sourceMappingURL). This patch stores the directives on the UnlinkedCodeBlock and UnlinkedFunctionExecutable when entering the cache, and copies to the new providers when the cache is used. * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::sourceURLDirective): (JSC::UnlinkedCodeBlock::sourceMappingURLDirective): (JSC::UnlinkedCodeBlock::setSourceURLDirective): (JSC::UnlinkedCodeBlock::setSourceMappingURLDirective): * bytecode/UnlinkedFunctionExecutable.h: * parser/SourceProvider.h: * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): (JSC::CodeCache::getFunctionExecutableFromGlobalCode): * runtime/CodeCache.h: Store directives on the unlinked code block / executable when adding to the cache, so they can be used to update new providers when the cache gets used. * runtime/JSGlobalObject.cpp: Add needed header after CodeCache header cleanup. 2016-04-22 Mark Lam javascript jit bug affecting Google Maps. https://bugs.webkit.org/show_bug.cgi?id=153431 Reviewed by Filip Pizlo. The issue was due to the abstract interpreter wrongly marking the type of the value read from the Uint3Array as SpecInt52, which precludes it from being an Int32. This proves to be false, and the generated code failed to handle the case where the read value is actually an Int32. The fix is to have the abstract interpreter use SpecMachineInt instead of SpecInt52. * bytecode/SpeculatedType.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): 2016-04-22 Benjamin Poulain [JSC] PredictionPropagation should not be in the top 5 heaviest phases https://bugs.webkit.org/show_bug.cgi?id=156891 Reviewed by Mark Lam. In DFG, PredictionPropagation is often way too high in profiles. It is a simple phase, it should not be that hot. Most of the time is spent accessing memory. This patch attempts to reduce that. First, propagate() is split in processInvariants() and propagates(). The step processInvariants() sets all the types for nodes for which the type does not depends on other nodes. Adding processInvariants() lowers two hotspot inside PredictionPropagation: speculationFromValue() and setPrediction(). Next, to avoid touching all the nodes at every operation, we keep track of the nodes that actually need propagate(). The vector m_dependentNodes keeps the list of those nodes and propagate() only need to process them at each phase. This is a smaller gain because growing m_dependentNodes negates some of the gains. On 3d-cube, this moves PredictionPropagation from fifth position to ninth. A lot of the remaining overhead is caused by double-voting and cannot be fixed by moving stuff around. * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagateToFixpoint): Deleted. (JSC::DFG::PredictionPropagationPhase::propagate): Deleted. (JSC::DFG::PredictionPropagationPhase::propagateForward): Deleted. (JSC::DFG::PredictionPropagationPhase::propagateBackward): Deleted. (JSC::DFG::PredictionPropagationPhase::doDoubleVoting): Deleted. (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): Deleted. (JSC::DFG::PredictionPropagationPhase::propagateThroughArgumentPositions): Deleted. 2016-04-22 Geoffrey Garen super should be available in object literals https://bugs.webkit.org/show_bug.cgi?id=156933 Reviewed by Saam Barati. When we originally implemented classes, super seemed to be a class-only feature. But the final spec says it's available in object literals too. * bytecompiler/NodesCodegen.cpp: (JSC::PropertyListNode::emitBytecode): Having 'super' and being a class property are no longer synonymous, so we track two separate variables. (JSC::PropertyListNode::emitPutConstantProperty): Being inside the super branch no longer guarantees that you're a class property, so we decide our attributes and our function name dynamically. * parser/ASTBuilder.h: (JSC::ASTBuilder::createArrowFunctionExpr): (JSC::ASTBuilder::createGetterOrSetterProperty): (JSC::ASTBuilder::createArguments): (JSC::ASTBuilder::createArgumentsList): (JSC::ASTBuilder::createProperty): (JSC::ASTBuilder::createPropertyList): Pass through state to indicate whether we're a class property, since we can't infer it from 'super' anymore. * parser/NodeConstructors.h: (JSC::PropertyNode::PropertyNode): See ASTBuilder.h. * parser/Nodes.h: (JSC::PropertyNode::expressionName): (JSC::PropertyNode::name): (JSC::PropertyNode::type): (JSC::PropertyNode::needsSuperBinding): (JSC::PropertyNode::isClassProperty): (JSC::PropertyNode::putType): See ASTBuilder.h. * parser/Parser.cpp: (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseClass): (JSC::Parser::parseProperty): (JSC::Parser::parsePropertyMethod): (JSC::Parser::parseGetterSetter): (JSC::Parser::parseMemberExpression): I made these error messages generic because it is no longer practical to say concise things about the list of places you can use super. * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createArgumentsList): (JSC::SyntaxChecker::createProperty): (JSC::SyntaxChecker::appendExportSpecifier): (JSC::SyntaxChecker::appendConstDecl): (JSC::SyntaxChecker::createGetterOrSetterProperty): Updated for interface change. * tests/stress/generator-with-super.js: (test): * tests/stress/modules-syntax-error.js: * tests/stress/super-in-lexical-scope.js: (testSyntaxError): (testSyntaxError.test): * tests/stress/tagged-templates-syntax.js: Updated for error message changes. See Parser.cpp. 2016-04-22 Filip Pizlo ASSERT(m_stack.last().isTailDeleted) at ShadowChicken.cpp:127 inspecting the inspector https://bugs.webkit.org/show_bug.cgi?id=156930 Reviewed by Joseph Pecoraro. The loop that prunes the stack from the top should preserve the invariant that the top frame cannot be tail-deleted. * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::update): 2016-04-22 Benjamin Poulain Attempt to fix the CLoop after r199866 * runtime/MathCommon.h: 2016-04-22 Benjamin Poulain [JSC] Integer Multiply of a number by itself does not need negative zero support https://bugs.webkit.org/show_bug.cgi?id=156895 Reviewed by Saam Barati. You cannot produce negative zero by squaring an integer. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMul): Minor codegen fixes: -Use the right form of multiply for ARM. -Use a sign-extended 32bit immediates, that's the one with fast forms in the MacroAssembler. 2016-04-21 Darin Adler Follow-on to the build fix. * runtime/MathCommon.h: Use the C++ std namespace version of the frexp function too. 2016-04-21 Joonghun Park [JSC] Fix build break since r199866. Unreviewed. https://bugs.webkit.org/show_bug.cgi?id=156892 * runtime/MathCommon.h: Add namespace std to isnormal invoking. 2016-04-21 Benjamin Poulain [JSC] Add primitive String support to compare operators https://bugs.webkit.org/show_bug.cgi?id=156783 Reviewed by Geoffrey Garen. Just the basics. We should eventually inline some of the simplest cases. This is a 2% improvement on Longspider. It is unfortunately neutral for Sunspider on my machine because most of the comparison are from baseline. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compare): (JSC::DFG::SpeculativeJIT::compileStringCompare): (JSC::DFG::SpeculativeJIT::compileStringIdentCompare): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareLess): (JSC::FTL::DFG::LowerDFGToB3::compileCompareLessEq): (JSC::FTL::DFG::LowerDFGToB3::compileCompareGreater): (JSC::FTL::DFG::LowerDFGToB3::compileCompareGreaterEq): (JSC::FTL::DFG::LowerDFGToB3::compare): * ftl/FTLOutput.h: (JSC::FTL::Output::callWithoutSideEffects): * jit/JITOperations.h: * tests/stress/string-compare.js: Added. (makeRope): (makeString): (let.operator.of.operators.eval.compareStringIdent): (let.operator.of.operators.compareStringString): (let.operator.of.operators.compareStringIdentString): (let.operator.of.operators.compareStringStringIdent): (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.eval): 2016-04-21 Benjamin Poulain [JSC] Commute FDiv-by-constant into FMul-by-reciprocal when it is safe https://bugs.webkit.org/show_bug.cgi?id=156871 Reviewed by Filip Pizlo. FMul is significantly faster than FDiv. For example, on Haswell, FMul has a latency of 5, a throughput of 1 while FDiv has latency 10-24, throughput 8-18. Fortunately for us, Sunspider and Kraken have plenty of division by a simple power of 2 constant. Those are just exponent operations and can be easily reversed to use FMul instead of FDiv. LLVM does something similar in InstCombine. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * jit/JITDivGenerator.cpp: (JSC::JITDivGenerator::loadOperand): (JSC::JITDivGenerator::generateFastPath): * jit/SnippetOperand.h: (JSC::SnippetOperand::asConstNumber): * runtime/MathCommon.h: (JSC::safeReciprocalForDivByConst): * tests/stress/floating-point-div-to-mul.js: Added. (opaqueDivBy2): (opaqueDivBy3): (opaqueDivBy4): (opaqueDivBySafeMaxMinusOne): (opaqueDivBySafeMax): (opaqueDivBySafeMaxPlusOne): (opaqueDivBySafeMin): (opaqueDivBySafeMinMinusOne): (i.catch): (i.result.opaqueDivBySafeMin.valueOf): 2016-04-21 Benjamin Poulain [JSC] Improve the absThunkGenerator() for 64bit https://bugs.webkit.org/show_bug.cgi?id=156888 Reviewed by Michael Saboff. A few tests spend a lot of time in this abs() with double argument. This patch adds custom handling for the JSValue64 representation. In particular: -Do not load the value twice. Unbox the GPR if it is not an Int32. -Deal with IntMin inline instead of falling back to the C function call. -Box the values ourself to avoid a duplicate function tail and return. * jit/ThunkGenerators.cpp: (JSC::absThunkGenerator): 2016-04-21 Saam barati LLInt CallSiteIndex off by 1 https://bugs.webkit.org/show_bug.cgi?id=156886 Reviewed by Benjamin Poulain. I think was done for historical reasons but isn't needed anymore. * llint/LLIntSlowPaths.cpp: 2016-04-21 Keith Miller FTL should handle exceptions in operationInOptimize https://bugs.webkit.org/show_bug.cgi?id=156885 Reviewed by Michael Saboff. For some reasone we didn't handle any exceptions in "in" when we called operationInOptimize in the FTL. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpAssumingJITType): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileIn): * ftl/FTLPatchpointExceptionHandle.h: Add comments explaining which function to use for different exception types. * jsc.cpp: (GlobalObject::finishCreation): (functionNoFTL): * runtime/Executable.cpp: (JSC::ScriptExecutable::ScriptExecutable): * runtime/Executable.h: (JSC::ScriptExecutable::setNeverFTLOptimize): (JSC::ScriptExecutable::neverFTLOptimize): * tests/stress/in-ftl-exception-check.js: Added. (foo): (bar): (catch): 2016-04-21 Filip Pizlo JSC virtual call thunk shouldn't do a structure->classInfo lookup https://bugs.webkit.org/show_bug.cgi?id=156874 Reviewed by Keith Miller. This lookup was unnecessary because we can just test the inlined type field. But also, this meant that we were exempting JSBoundFunction from the virtual call optimization. That's pretty bad. * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): 2016-04-21 Joseph Pecoraro Web Inspector: sourceMappingURL not loaded in generated script https://bugs.webkit.org/show_bug.cgi?id=156022 Reviewed by Geoffrey Garen. * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace): Synthetic CallFrames for native code will not have script identifiers. * inspector/ScriptCallFrame.cpp: (Inspector::ScriptCallFrame::ScriptCallFrame): (Inspector::ScriptCallFrame::isEqual): (Inspector::ScriptCallFrame::buildInspectorObject): * inspector/ScriptCallFrame.h: * inspector/protocol/Console.json: Include the script identifier in ScriptCallFrame so we can correlate this to the exactly script, even if there isn't a URL. The Script may have a sourceURL, so the Web Inspector frontend may decide to show / link to it. * inspector/ScriptCallStackFactory.cpp: (Inspector::CreateScriptCallStackFunctor::operator()): (Inspector::createScriptCallStackFromException): Include SourceID when we have it. * interpreter/Interpreter.cpp: (JSC::GetStackTraceFunctor::operator()): * interpreter/Interpreter.h: * interpreter/StackVisitor.cpp: (JSC::StackVisitor::Frame::sourceID): * interpreter/StackVisitor.h: Access the SourceID when we have it. 2016-04-21 Saam barati Lets do less locking of symbol tables in the BytecodeGenerator where we don't have race conditions https://bugs.webkit.org/show_bug.cgi?id=156821 Reviewed by Filip Pizlo. The BytecodeGenerator allocates all the SymbolTables that it uses. This is before any concurrent compiler thread can use that SymbolTable. This means we don't actually need to lock for any operations of the SymbolTable. This patch makes this change by removing all locking. To do this, I've introduced a new constructor for ConcurrentJITLocker which implies no locking is necessary. You instantiate such a ConcurrentJITLocker like so: `ConcurrentJITLocker locker(ConcurrentJITLocker::NoLockingNecessary);` This patch also removes all uses of Strong from the bytecode generator and instead wraps bytecode generation in a DeferGC. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack): (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded): (JSC::BytecodeGenerator::instantiateLexicalVariables): (JSC::BytecodeGenerator::emitPrefillStackTDZVariables): (JSC::BytecodeGenerator::pushLexicalScopeInternal): (JSC::BytecodeGenerator::initializeBlockScopedFunctions): (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary): (JSC::BytecodeGenerator::popLexicalScopeInternal): (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration): (JSC::BytecodeGenerator::variable): (JSC::BytecodeGenerator::createVariable): (JSC::BytecodeGenerator::emitResolveScope): (JSC::BytecodeGenerator::emitPushWithScope): (JSC::BytecodeGenerator::emitPushFunctionNameScope): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::constructorKind): (JSC::BytecodeGenerator::superBinding): (JSC::BytecodeGenerator::generate): * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): * runtime/ConcurrentJITLock.h: (JSC::ConcurrentJITLockerBase::ConcurrentJITLockerBase): (JSC::ConcurrentJITLockerBase::~ConcurrentJITLockerBase): (JSC::ConcurrentJITLocker::ConcurrentJITLocker): 2016-04-21 Saam barati Remove some unnecessary RefPtrs in the parser https://bugs.webkit.org/show_bug.cgi?id=156865 Reviewed by Filip Pizlo. The IdentifierArena or the SourceProviderCacheItem will own these UniquedStringImpls while we are using them. There is no need for us to reference count them. This might be a 0.5% speedup on octane code-load. * parser/Parser.cpp: (JSC::Parser::parseInner): * parser/Parser.h: (JSC::Scope::setIsLexicalScope): (JSC::Scope::isLexicalScope): (JSC::Scope::closedVariableCandidates): (JSC::Scope::declaredVariables): (JSC::Scope::lexicalVariables): (JSC::Scope::finalizeLexicalEnvironment): (JSC::Scope::computeLexicallyCapturedVariablesAndPurgeCandidates): (JSC::Scope::collectFreeVariables): (JSC::Scope::getCapturedVars): (JSC::Scope::setStrictMode): (JSC::Scope::isValidStrictMode): (JSC::Scope::shadowsArguments): (JSC::Scope::copyCapturedVariablesToVector): * parser/SourceProviderCacheItem.h: (JSC::SourceProviderCacheItem::usedVariables): (JSC::SourceProviderCacheItem::~SourceProviderCacheItem): (JSC::SourceProviderCacheItem::create): (JSC::SourceProviderCacheItem::SourceProviderCacheItem): (JSC::SourceProviderCacheItem::writtenVariables): Deleted. 2016-04-21 Filip Pizlo PolymorphicAccess adds sizeof(CallerFrameAndPC) rather than subtracting it when calculating stack height https://bugs.webkit.org/show_bug.cgi?id=156872 Reviewed by Geoffrey Garen. The code that added sizeof(CallerFrameAndPC) emerged from a bad copy-paste in r189586. That was the revision that created the PolymorphicAccess class. It moved code for generating a getter/setter call from Repatch.cpp to PolymorphicAccess.cpp. You can see the code doing a subtraction here: http://trac.webkit.org/changeset/189586/trunk/Source/JavaScriptCore/jit/Repatch.cpp This makes the world right again. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generateImpl): 2016-04-21 Geoffrey Garen Build warning: CODE_SIGN_ENTITLEMENTS specified without specifying CODE_SIGN_IDENTITY https://bugs.webkit.org/show_bug.cgi?id=156862 Reviewed by Joseph Pecoraro. * Configurations/Base.xcconfig: Specify the ad hoc signing identity by default. See . 2016-04-21 Andy Estes REGRESSION (r199734): WebKit crashes loading numerous websites in iOS Simulator https://bugs.webkit.org/show_bug.cgi?id=156842 Reviewed by Daniel Bates. Disable separated heap on iOS Simulator. * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2016-04-21 Michael Saboff Align RegExp[@@match] with other @@ methods https://bugs.webkit.org/show_bug.cgi?id=156832 Reviewed by Mark Lam. Various changes to align the RegExp[@@match] with [@@search] and [@@split]. Made RegExp.prototype.@exec a hidden property on the global object and called it @regExpBuiltinExec to match the name it has in the standard. Changed all places that used the old name to use the new one. Made the match fast path function, which used to be call @match, to be called @regExpMatchFast and put it on the global object. Changed it to also handle expressions both with and without the global flag. Refactored the builtin @match accordingly. Added the builtin function @hasObservableSideEffectsForRegExpMatch() that checks to see if we can use the fast path of if we need the explicit version. Put the main RegExp functions @match, @search and @split in alphabetical order in RegExpPrototype.js. Did the same for @match, @repeat, @search and @split in StringPrototype.js. * builtins/RegExpPrototype.js: (regExpExec): (hasObservableSideEffectsForRegExpMatch): New. (match): (search): (hasObservableSideEffectsForRegExpSplit): Reordered in the file and updated to use @regExpBuiltinExec. * builtins/StringPrototype.js: (match): (repeatSlowPath): (repeat): (search): (split): Reordered functions in the file. * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::setGlobalThis): (JSC::getById): (JSC::getGetterById): (JSC::JSGlobalObject::init): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): (JSC::regExpProtoFuncExec): (JSC::regExpProtoFuncMatchFast): (JSC::regExpProtoFuncMatchPrivate): Deleted. * runtime/RegExpPrototype.h: 2016-04-20 Geoffrey Garen JavaScriptCore garbage collection is missing an autorelease pool https://bugs.webkit.org/show_bug.cgi?id=156751 Reviewed by Mark Lam. * heap/Heap.cpp: (JSC::Heap::releaseDelayedReleasedObjects): Add an autorelease pool to catch autoreleases when we call out to arbitrary ObjC code. We use the C interface here because this is not an ObjC compilation unit. 2016-04-20 Filip Pizlo DFG del_by_id support forgets to set() https://bugs.webkit.org/show_bug.cgi?id=156830 Reviewed by Saam Barati. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * tests/stress/dfg-del-by-id.js: Added. 2016-04-20 Saam barati Improve sampling profiler CLI JSC tool https://bugs.webkit.org/show_bug.cgi?id=156824 Reviewed by Mark Lam. This patch enhances the Sampling Profiler CLI tool from the JSC shell to display the JITType of a particular CodeBlock. Because this happens once we process a log of stack frames, the data for a particular frame being in LLInt vs. Baseline could be wrong. For example, we may have taken a stack trace of a CodeBlock while it was executing in the LLInt, then it tiers up to the baseline, then we process the log. We will show such CodeBlocks as being in the baseline JIT. We could be smarter about this in the future if it turns out to truly be a problem. This patch also adds a 'samplingProfilerTimingInterval' JSC option to allow CLI users to control the sleep time between stack traces. * jsc.cpp: (jscmain): * runtime/Options.h: * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::processUnverifiedStackTraces): (JSC::SamplingProfiler::reportTopBytecodes): * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::StackFrame::hasExpressionInfo): 2016-04-20 Benjamin Poulain [JSC] DFG should not generate two jumps when the target of DoubleBranch is the next block https://bugs.webkit.org/show_bug.cgi?id=156815 Reviewed by Mark Lam. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePeepHoleDoubleBranch): 2016-04-20 Benjamin Poulain [JSC] Add register reuse for ArithAdd of an Int32 and constant in DFG https://bugs.webkit.org/show_bug.cgi?id=155164 Reviewed by Mark Lam. Every "inc" in loop was looking like this: move rX, rY inc rY jo 0x230f4a200580 This patch add register Reuse to that case to remove the extra "move". * dfg/DFGOSRExit.h: (JSC::DFG::SpeculationRecovery::SpeculationRecovery): (JSC::DFG::SpeculationRecovery::immediate): * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithAdd): * tests/stress/arith-add-with-constant-overflow.js: Added. (opaqueAdd): 2016-04-20 Saam barati We don't need a manual stack for an RAII object when the machine's stack will do just fine https://bugs.webkit.org/show_bug.cgi?id=156807 Reviewed by Mark Lam. We kept around a vector for an RAII object to maintain the recursive nature of having these RAII objects on the stack as the parser recursed. Instead, the RAII object can just have a field with the value it wants to restore and use the machine's stack. This is a 1% octane code-load progression. * parser/SyntaxChecker.h: (JSC::SyntaxChecker::BinaryExprContext::BinaryExprContext): (JSC::SyntaxChecker::BinaryExprContext::~BinaryExprContext): (JSC::SyntaxChecker::UnaryExprContext::UnaryExprContext): (JSC::SyntaxChecker::UnaryExprContext::~UnaryExprContext): (JSC::SyntaxChecker::operatorStackPop): 2016-04-20 Michael Saboff REGRESSION(r190289): Spin trying to view/sign in to hbogo.com https://bugs.webkit.org/show_bug.cgi?id=156765 Reviewed by Saam Barati. In the op_get_by_val case, we were holding the lock on a profiled CodeBlock when we call into handleGetById(). Changed to drop the lock before calling handleGetById(). The bug here was that the call to handleGetById() may end up calling in to getPredictionWithoutOSRExit() for a tail call opcode. As part of that processing, we walk back up the stack to find the effective caller and when found, we lock the corresponding CodeBlock to get the predicition. That CodeBLock may be the same one locked above. There is no need anyway to hold the CodeBlock lock when calling handleGetById(). Added a new stress test. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * tests/stress/regress-156765.js: Added. (realValue): (object.get hello): (ok): 2016-04-20 Mark Lam Unindent an unnecessary block in stringProtoFuncSplitFast(). https://bugs.webkit.org/show_bug.cgi?id=156802 Reviewed by Filip Pizlo. In webkit.org/b/156013, I refactored stringProtoFuncSplit into stringProtoFuncSplitFast. In that patch, I left an unnecessary block of code in its original block (with FIXMEs) to keep the diff for that patch minimal. Now that the patch for webkit.org/b/156013 has landed, I will unindent that block and remove the FIXMEs. * runtime/StringPrototype.cpp: (JSC::stringProtoFuncSplitFast): 2016-04-20 Brady Eidson Modern IDB (Workers): Enable INDEXED_DATABASE_IN_WORKERS compile time flag, but disabled in RuntimeEnabledFeatures. https://bugs.webkit.org/show_bug.cgi?id=156782 Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: 2016-04-20 Saam barati Remove unused m_writtenVariables from the parser and related bits https://bugs.webkit.org/show_bug.cgi?id=156784 Reviewed by Yusuke Suzuki. This isn't a octane/codeload speedup even though we're doing less work in collectFreeVariables. But it's good to get rid of things that are not used. * parser/Nodes.h: (JSC::ScopeNode::usesEval): (JSC::ScopeNode::usesArguments): (JSC::ScopeNode::usesArrowFunction): (JSC::ScopeNode::isStrictMode): (JSC::ScopeNode::setUsesArguments): (JSC::ScopeNode::usesThis): (JSC::ScopeNode::modifiesParameter): Deleted. (JSC::ScopeNode::modifiesArguments): Deleted. * parser/Parser.cpp: (JSC::Parser::parseInner): (JSC::Parser::parseAssignmentExpression): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::hasDeclaredParameter): (JSC::Scope::preventAllVariableDeclarations): (JSC::Scope::collectFreeVariables): (JSC::Scope::mergeInnerArrowFunctionFeatures): (JSC::Scope::getSloppyModeHoistedFunctions): (JSC::Scope::getCapturedVars): (JSC::Scope::setStrictMode): (JSC::Scope::strictMode): (JSC::Scope::fillParametersForSourceProviderCache): (JSC::Scope::restoreFromSourceProviderCache): (JSC::Parser::hasDeclaredParameter): (JSC::Parser::exportName): (JSC::Scope::declareWrite): Deleted. (JSC::Parser::declareWrite): Deleted. * parser/ParserModes.h: 2016-04-19 Saam barati Unreviewed, fix cloop build after r199754. * jsc.cpp: (jscmain): 2016-04-19 Michael Saboff iTunes crashing JavaScriptCore.dll https://bugs.webkit.org/show_bug.cgi?id=156647 Reviewed by Filip Pizlo. Given that there there are only 128 FLS indices compared to over a 1000 for TLS, I eliminated the thread specific m_threadSpecificForThread and instead we look for the current thread in m_registeredThreads list when we need it. In most cases there will only be one thread. Added THREAD_SPECIFIC_CALL to signature of ThreadSpecific remove callbacks to set the calling convention correctly for Windows 32 bit. * heap/MachineStackMarker.cpp: (JSC::ActiveMachineThreadsManager::remove): (JSC::MachineThreads::MachineThreads): (JSC::MachineThreads::~MachineThreads): (JSC::MachineThreads::addCurrentThread): (JSC::MachineThreads::machineThreadForCurrentThread): (JSC::MachineThreads::removeThread): * heap/MachineStackMarker.h: 2016-04-19 Benjamin Poulain [JSC] Small cleanup of RegisterAtOffsetList https://bugs.webkit.org/show_bug.cgi?id=156779 Reviewed by Mark Lam. I was wondering why RegisterAtOffsetList always cache-miss. It looks like it is doing more than it needs to. We do not need to sort the values. The total order of RegisterAtOffset is: 1) Order of Reg. 2) Order of offsets. We already generate the list in order. Also allocate the right array size ahead of filling the array. * jit/RegisterAtOffsetList.cpp: (JSC::RegisterAtOffsetList::RegisterAtOffsetList): (JSC::RegisterAtOffsetList::sort): Deleted. * jit/RegisterAtOffsetList.h: (JSC::RegisterAtOffsetList::append): Deleted. 2016-04-19 Saam barati Add a couple UNLIKELY macros in parseMemberExpression https://bugs.webkit.org/show_bug.cgi?id=156775 Reviewed by Filip Pizlo. These UNLIKELY macros have to do with the base of the member expression being 'super'. I think it's safe to argue that this is truly UNLIKELY. I am seeing speedups sometimes on Octane codeload. Usually around 0.5%. Sometimes 1%. * parser/Parser.cpp: (JSC::Parser::parseMemberExpression): 2016-04-19 Saam barati allow jsc shell to dump sampling profiler data https://bugs.webkit.org/show_bug.cgi?id=156725 Reviewed by Benjamin Poulain. This patch adds a '--reportSamplingProfilerData' option to the JSC shell which will enable the sampling profiler and dump its data at the end of execution. The dump will include the 40 hottest functions and the 80 hottest bytecode locations. If you're using this option to debug, it's easy to just hack on the code to make it dump more or less information. * jsc.cpp: (CommandLine::parseArguments): (jscmain): * runtime/Options.h: * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::processUnverifiedStackTraces): (JSC::SamplingProfiler::stackTracesAsJSON): (JSC::SamplingProfiler::reportTopFunctions): (JSC::SamplingProfiler::reportTopBytecodes): * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::StackFrame::hasExpressionInfo): (JSC::SamplingProfiler::StackFrame::hasBytecodeIndex): (JSC::SamplingProfiler::StackFrame::hasCodeBlockHash): (JSC::SamplingProfiler::setStopWatch): 2016-04-19 Mark Lam Re-landing: ES6: Implement RegExp.prototype[@@search]. https://bugs.webkit.org/show_bug.cgi?id=156331 Reviewed by Keith Miller. What changed? 1. Implemented search builtin in RegExpPrototype.js. The native path is now used as a fast path. 2. Added DFG support for an IsRegExpObjectIntrinsic (modelled after the IsJSArrayIntrinsic). 3. Renamed @isRegExp to @isRegExpObject to match the new IsRegExpObjectIntrinsic. 4. Change the esSpecIsRegExpObject() implementation to check if the object's JSType is RegExpObjectType instead of walking the classinfo chain. * builtins/RegExpPrototype.js: (search): * builtins/StringPrototype.js: (search): - fixed some indentation. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor): (JSC::DFG::SpeculativeJIT::compileIsRegExpObject): (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction): (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject): (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf): (JSC::FTL::DFG::LowerDFGToB3::isExoticForTypeof): (JSC::FTL::DFG::LowerDFGToB3::isRegExpObject): (JSC::FTL::DFG::LowerDFGToB3::isType): * runtime/Intrinsic.h: - Added IsRegExpObjectIntrinsic. * runtime/CommonIdentifiers.h: * runtime/ECMAScriptSpecInternalFunctions.cpp: (JSC::esSpecIsConstructor): - Changed to use uncheckedArgument since this is only called from internal code. (JSC::esSpecIsRegExpObject): (JSC::esSpecIsRegExp): Deleted. * runtime/ECMAScriptSpecInternalFunctions.h: - Changed to check the object for a JSType of RegExpObjectType. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): - Added split fast path. * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): (JSC::regExpProtoFuncSearchFast): (JSC::regExpProtoFuncSearch): Deleted. * runtime/RegExpPrototype.h: * tests/es6.yaml: * tests/stress/regexp-search.js: - Rebased test. 2016-04-19 Mark Lam Replace $vm.printValue() with $vm.value(). https://bugs.webkit.org/show_bug.cgi?id=156767 Reviewed by Saam Barati. When debugging with $vm, this change allows us to do this: $vm.print("myObj = " + $vm.value(myObj) + "\n"); ... instead of having to do this: $vm.print("myObj = "); $vm.printValue(myObj); $vm.print("\n"); * tools/JSDollarVMPrototype.cpp: (JSC::JSDollarVMPrototype::printValue): (JSC::functionValue): (JSC::JSDollarVMPrototype::finishCreation): (JSC::functionPrintValue): Deleted. 2016-04-19 Mark Lam Re-landing: ES6: Implement String.prototype.split and RegExp.prototype[@@split]. https://bugs.webkit.org/show_bug.cgi?id=156013 Reviewed by Keith Miller. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/GlobalObject.js: (speciesConstructor): * builtins/PromisePrototype.js: - refactored to use the @speciesConstructor internal function. * builtins/RegExpPrototype.js: (advanceStringIndex): - refactored from @advanceStringIndexUnicode() to be match the spec. Benchmarks show that there's no advantage in doing the unicode check outside of the advanceStringIndexUnicode part. So, I simplified the code to match the spec (especially since @@split needs to call advanceStringIndex from more than 1 location). (match): - Removed an unnecessary call to @Object because it was already proven above. - Changed to use advanceStringIndex instead of advanceStringIndexUnicode. Again, there's no perf regression for this. (regExpExec): (hasObservableSideEffectsForRegExpSplit): (split): (advanceStringIndexUnicode): Deleted. * builtins/StringPrototype.js: (split): - Modified to use RegExp.prototype[@@split]. * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): (JSC::BytecodeIntrinsicRegistry::lookup): * bytecode/BytecodeIntrinsicRegistry.h: - Added the @@split symbol. * runtime/CommonIdentifiers.h: * runtime/ECMAScriptSpecInternalFunctions.cpp: Added. (JSC::esSpecIsConstructor): (JSC::esSpecIsRegExp): * runtime/ECMAScriptSpecInternalFunctions.h: Added. * runtime/JSGlobalObject.cpp: (JSC::getGetterById): (JSC::JSGlobalObject::init): * runtime/PropertyDescriptor.cpp: (JSC::PropertyDescriptor::setDescriptor): - Removed an assert that is no longer valid. * runtime/RegExpObject.h: - Made advanceStringUnicode() public so that it can be re-used by the regexp split fast path. * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): (JSC::regExpProtoFuncExec): (JSC::regExpProtoFuncSearch): (JSC::advanceStringIndex): (JSC::regExpProtoFuncSplitFast): * runtime/RegExpPrototype.h: * runtime/StringObject.h: (JSC::jsStringWithReuse): (JSC::jsSubstring): - Hoisted some utility functions from StringPrototype.cpp so that they can be reused by the regexp split fast path. * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::stringProtoFuncSplitFast): (JSC::stringProtoFuncSubstr): (JSC::builtinStringSubstrInternal): (JSC::stringProtoFuncSubstring): (JSC::stringIncludesImpl): (JSC::stringProtoFuncIncludes): (JSC::builtinStringIncludesInternal): (JSC::jsStringWithReuse): Deleted. (JSC::jsSubstring): Deleted. (JSC::stringProtoFuncSplit): Deleted. * runtime/StringPrototype.h: * tests/es6.yaml: 2016-04-19 Commit Queue Unreviewed, rolling out r199726. https://bugs.webkit.org/show_bug.cgi?id=156748 WebKit tests crash on Windows 32 (Requested by msaboff on #webkit). Reverted changeset: "iTunes crashing JavaScriptCore.dll" https://bugs.webkit.org/show_bug.cgi?id=156647 http://trac.webkit.org/changeset/199726 2016-04-19 Michael Saboff iTunes crashing JavaScriptCore.dll https://bugs.webkit.org/show_bug.cgi?id=156647 Reviewed by Saam Barati. Given that there there are only 128 FLS indices compared to over a 1000 for TLS, I eliminated the thread specific m_threadSpecificForThread and instead we look for the current thread in m_registeredThreads list when we need it. In most cases there will only be one thread. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThreads): (JSC::MachineThreads::~MachineThreads): (JSC::MachineThreads::addCurrentThread): (JSC::MachineThreads::machineThreadForCurrentThread): (JSC::MachineThreads::removeThread): * heap/MachineStackMarker.h: 2016-04-19 Yusuke Suzuki [INTL] Use @thisNumberValue instead of `instanceof @Number` https://bugs.webkit.org/show_bug.cgi?id=156680 Reviewed by Saam Barati. Use @thisNumberValue instead of `instanceof @Number`. `instanceof @Number` is not enough; For example, given 2 realms, the object created in one realm does not inherit the Number of another realm. Another example is that the object which does not inherit Number. ``` var number = new Number(42); number.__proto__ = null; ``` * builtins/NumberPrototype.js: (toLocaleString): * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/NumberPrototype.cpp: (JSC::numberProtoFuncValueOf): * runtime/NumberPrototype.h: * tests/stress/number-to-locale-string-should-accept-strange-number-objects.js: Added. (shouldBe): 2016-04-19 Commit Queue Unreviewed, rolling out r199712. https://bugs.webkit.org/show_bug.cgi?id=156741 It caused a serious regression on 32 bit platform (Requested by gskachkov on #webkit). Reverted changeset: "calling super() a second time in a constructor should throw" https://bugs.webkit.org/show_bug.cgi?id=151113 http://trac.webkit.org/changeset/199712 2016-04-09 Skachkov Oleksandr calling super() a second time in a constructor should throw https://bugs.webkit.org/show_bug.cgi?id=151113 Reviewed by Saam Barati and Keith Miller. Currently, our implementation checks if 'super()' was called in a constructor more than once and raises a RuntimeError before the second call. According to the spec we need to raise an error just after the second super() is finished and before the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour. To implement this behavior this patch adds a new op code, op_is_empty, that is used to check if 'this' is empty. * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitIsEmpty): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallValueNode::emitBytecode): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_is_empty): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_is_empty): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * tests/stress/class-syntax-double-constructor.js: Added. 2016-04-18 Benjamin Poulain [JSC] Fix some overhead affecting small codegen https://bugs.webkit.org/show_bug.cgi?id=156728 Reviewed by Filip Pizlo. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::AbstractMacroAssembler): (JSC::AbstractMacroAssembler::random): cryptographicallyRandomNumber() is very costly. We only need it in lowering some very particular cases of non-trusted immediates. No inline cache needs that. * assembler/LinkBuffer.h: (JSC::LinkBuffer::link): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::addSlowCase): Do not copy the JumpList to access its elements. 2016-04-18 Saam barati implement dynamic scope accesses in the DFG/FTL https://bugs.webkit.org/show_bug.cgi?id=156567 Reviewed by Geoffrey Garen. This patch adds dynamic scope operations to the DFG/FTL. This patch adds three new DFG nodes: ResolveScope, PutDynamicVar and GetDynamicVar. When we encounter a Dynamic/UnresolvedProperty/UnresolvedPropertyWithVarInjectionChecks resolve type, we will compile dynamic scope resolution nodes. When we encounter a resolve type that needs var injection checks and the var injection watchpoint has already been fired, we will compile dynamic scope resolution nodes. This patch also adds a new value to the InitializationMode enum: ConstInitialization. There was a subtle bug where we used to never compile the var injection variant of the resolve type for an eval that injected a var where there was also a global lexical variable with the same name. For example, the store compiled in this eval("var foo = 20;") wouldn't be compiled with var injection checks if there was global let/const variable named "foo". So there was the potential for the injected var to store to the GlobalLexicalObject. I found this bug because my initial implementation in the DFG/FTL ran into it. The reason this bug existed is because when we compile a const initialization, we never need a var injections check. The const initialization always knows where to store its value. This same logic leaked into the above eval's "var foo = 20" store. This new enum value allows us to distinguish const initialization stores from non-const initialization stores. (I also changed InitializationMode to be an enum class instead of an enum). * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack): (JSC::BytecodeGenerator::initializeBlockScopedFunctions): (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary): (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration): (JSC::BytecodeGenerator::emitGetFromScope): (JSC::BytecodeGenerator::initializeVariable): (JSC::BytecodeGenerator::emitInstanceOf): (JSC::BytecodeGenerator::emitPushFunctionNameScope): (JSC::BytecodeGenerator::pushScopedControlFlowContext): (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope): (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope): (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope): * bytecompiler/NodesCodegen.cpp: (JSC::PostfixNode::emitResolve): (JSC::PrefixNode::emitResolve): (JSC::ReadModifyResolveNode::emitBytecode): (JSC::initializationModeForAssignmentContext): (JSC::AssignResolveNode::emitBytecode): (JSC::EmptyLetExpression::emitBytecode): (JSC::ForInNode::emitLoopHeader): (JSC::ForOfNode::emitBytecode): (JSC::ClassExprNode::emitBytecode): (JSC::BindingNode::bindValue): (JSC::AssignmentElementNode::bindValue): (JSC::RestParameterNode::emit): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::noticeArgumentsUse): (JSC::DFG::ByteCodeParser::promoteToConstant): (JSC::DFG::ByteCodeParser::needsDynamicLookup): (JSC::DFG::ByteCodeParser::planLoad): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasIdentifier): (JSC::DFG::Node::identifierNumber): (JSC::DFG::Node::hasGetPutInfo): (JSC::DFG::Node::getPutInfo): (JSC::DFG::Node::hasAccessorAttributes): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePutGetterSetterById): (JSC::DFG::SpeculativeJIT::compileResolveScope): (JSC::DFG::SpeculativeJIT::compileGetDynamicVar): (JSC::DFG::SpeculativeJIT::compilePutDynamicVar): (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compare): (JSC::FTL::DFG::LowerDFGToB3::compileResolveScope): (JSC::FTL::DFG::LowerDFGToB3::compileGetDynamicVar): (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar): (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject): * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsWithExecState): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * runtime/GetPutInfo.h: (JSC::resolveModeName): (JSC::initializationModeName): (JSC::isInitialization): (JSC::makeType): (JSC::GetPutInfo::GetPutInfo): * runtime/JSScope.cpp: (JSC::abstractAccess): 2016-04-18 Filip Pizlo Disable AVX. Rubber stampted by Benjamin Poulain. AVX is silly. If you use it and some of your other code isn't careful with float register bits, you will run 10x slower. We could fix the underlying issue, but it's better to stay away from this odd instruction subset. This fixes a massive regression on some real code. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::supportsAVX): (JSC::MacroAssemblerX86Common::updateEax1EcxFlags): 2016-04-18 Filip Pizlo ToThis should have a fast path based on type info flags https://bugs.webkit.org/show_bug.cgi?id=156712 Reviewed by Geoffrey Garen. Prior to this change, if we couldn't nail down the type of ToThis to something easy, we'd emit code that would take slow path if the argument was not a final object. We'd end up taking that slow path a lot. This adds a type info flag for ToThis having non-obvious behavior and changes the DFG and FTL paths to test this flag. This is a sub-1% speed-up on SunSpider and Octane. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileToThis): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::create): * runtime/JSLexicalEnvironment.h: (JSC::JSLexicalEnvironment::create): * runtime/JSString.h: * runtime/JSTypeInfo.h: (JSC::TypeInfo::overridesGetOwnPropertySlot): (JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero): (JSC::TypeInfo::structureIsImmortal): (JSC::TypeInfo::overridesToThis): (JSC::TypeInfo::overridesGetPropertyNames): (JSC::TypeInfo::prohibitsPropertyCaching): (JSC::TypeInfo::getOwnPropertySlotIsImpure): * runtime/StrictEvalActivation.h: (JSC::StrictEvalActivation::create): * runtime/Symbol.h: 2016-04-18 Filip Pizlo Check to see how the perf bots react to megamorphic load being disabled. Rubber stamped by Chris Dumez. * runtime/Options.h: 2016-04-18 Keith Miller We should support delete in the DFG https://bugs.webkit.org/show_bug.cgi?id=156607 Reviewed by Benjamin Poulain. This patch adds support for the delete in the DFG as it appears that some major frameworks use the operation in particularly hot functions. As a result, even if the function rarely ever calls delete we would never tier up to the DFG. This patch also changes operationDeleteById to take a UniquedStringImpl and return a size_t. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasIdentifier): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDeleteById): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_del_by_id): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_del_by_id): 2016-04-17 Filip Pizlo FTL should pin the tag registers at inline caches https://bugs.webkit.org/show_bug.cgi?id=156678 Reviewed by Saam Barati. This is a long-overdue fix to our inline caches. Back when we had LLVM, we couldn't rely on the tags being pinned to any registers. So, if the inline caches needed tags, they'd have to materialize them. This removes those materializations. This should reduce the amount of code generated in inline caches and it should make inline caches faster. The effect appears to be small. It may be that after this change, we'll even be able to kill the HaveTagRegisters/DoNotHaveTagRegisters logic. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generateImpl): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compilePutById): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileIn): (JSC::FTL::DFG::LowerDFGToB3::getById): * jit/Repatch.cpp: (JSC::readCallTarget): (JSC::linkPolymorphicCall): * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): 2016-04-18 Yusuke Suzuki [ES7] yield star should not return if the inner iterator.throw returns { done: true } https://bugs.webkit.org/show_bug.cgi?id=156576 Reviewed by Saam Barati. This is slight generator fix in ES7. When calling generator.throw(), the yield-star should call the throw() of the inner generator. At that time, when the result of throw() is { done: true}, the generator should not stop itself. function * gen() { yield * (function * () { try { yield 42; } catch (error) { } }()); // Continue executing. yield 42; } let g = gen(); g.next(); shouldBe(g.throw().value, 42); * builtins/GeneratorPrototype.js: (generatorResume): (next): (return): (throw): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitDelegateYield): * runtime/JSGeneratorFunction.h: * tests/stress/generator-yield-star.js: (gen): * tests/stress/yield-star-throw-continue.js: Added. (shouldBe): (generator): (shouldThrow): 2016-04-17 Jeremy Huddleston Sequoia Fix incorrect assumption that APPLE implies Mac. https://bugs.webkit.org/show_bug.cgi?id=156683 Addresses build failure introduced in r199094 Reviewed by Alex Christensen. * CMakeLists.txt: 2016-04-17 Benjamin Poulain [JSC] ReduceDoubleToFloat should work accross Phis https://bugs.webkit.org/show_bug.cgi?id=156603 Reviewed by Saam Barati and Filip Pizlo. This patch extends B3's ReduceDoubleToFloat phase to work accross Upsilon-Phis. This is important to optimize loops and some crazy cases. In its simplest form, we can have conversion propagated from something like this: Double @1 = Phi() Float @2 = DoubleToFloat(@1) When that happens, we just need to propagate that the result only need float precision accross all values coming to this Phi. There are more complicated cases when the value produced is effectively Float but the user of the value does not do DoubleToFloat. Typically, we have something like: #1 @1 = ConstDouble(1) @2 = Upsilon(@1, ^5) #2 @3 = FloatToDouble(@x) @4 = Upsilon(@3, ^5) #3 @5 = Phi() @6 = Add(@5, @somethingFloat) @7 = DoubleToFloat(@6) Here with a Phi-Upsilon that is a Double but can be represented as Float without loss of precision. It is valuable to convert such Phis to float if and only if the value is used as float. Otherwise, you may be just adding useless conversions (for example, two double constants that flow into a double Add should not turn into two float constant flowing into a FloatToDouble then Add). ReduceDoubleToFloat do two analysis passes to gather the necessary meta information. Then we have a simplify() phase to actually reduce operation. Finally, the cleanup() pass put the graph into a valid state again. The two analysis passes work by disproving that something is float. -findCandidates() accumulates anything used as Double. -findPhisContainingFloat() accumulates phis that would lose precision by converting the input to float. With this change, Unity3D improves by ~1.5%, box2d-f32 improves by ~2.8% (on Haswell). * b3/B3ReduceDoubleToFloat.cpp: (JSC::B3::reduceDoubleToFloat): * b3/testb3.cpp: (JSC::B3::testCompareTwoFloatToDouble): (JSC::B3::testCompareOneFloatToDouble): (JSC::B3::testCompareFloatToDoubleThroughPhi): (JSC::B3::testDoubleToFloatThroughPhi): (JSC::B3::testDoubleProducerPhiToFloatConversion): (JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer): (JSC::B3::testDoubleProducerPhiWithNonFloatConst): (JSC::B3::testStoreDoubleConstantAsFloat): (JSC::B3::run): * tests/stress/double-compare-to-float.js: Added. (canSimplifyToFloat): (canSimplifyToFloatWithConstant): (cannotSimplifyA): (cannotSimplifyB): * tests/stress/double-to-float.js: Added. (upsilonReferencingItsPhi): (upsilonReferencingItsPhiAllFloat): (upsilonReferencingItsPhiWithoutConversion): (conversionPropagages): (chainedUpsilonBothConvert): (chainedUpsilonFirstConvert): 2016-04-17 Yusuke Suzuki [ES6] Use @isObject to check Object Type instead of using instanceof https://bugs.webkit.org/show_bug.cgi?id=156676 Reviewed by Darin Adler. Use @isObject instead of `instanceof @Object`. The `instanceof` check is not enough to check Object Type. For example, given 2 realms, the object created in one realm does not inherit the Object of another realm. Another example is that the object which does not inherit Object. This object can be easily created by calling `Object.create(null)`. * builtins/RegExpPrototype.js: (match): * jsc.cpp: (GlobalObject::finishCreation): (functionCreateGlobalObject): * tests/stress/regexp-match-in-other-realm-should-work.js: Added. (shouldBe): * tests/stress/regexp-match-should-work-with-objects-not-inheriting-object-prototype.js: Added. (shouldBe): (regexp.exec): 2016-04-17 Darin Adler Remove more uses of Deprecated::ScriptXXX https://bugs.webkit.org/show_bug.cgi?id=156660 Reviewed by Antti Koivisto. * bindings/ScriptFunctionCall.cpp: (Deprecated::ScriptCallArgumentHandler::appendArgument): Deleted unneeded overloads that take a ScriptObject and ScriptValue. * bindings/ScriptFunctionCall.h: Ditto. * bindings/ScriptObject.h: Added operator so this can change itself into a JSObject*. Helps while phasing this class out. * bindings/ScriptValue.h: Export toInspectorValue so it can be used in WebCore. * inspector/InjectedScriptManager.cpp: (Inspector::InjectedScriptManager::createInjectedScript): Changed return value from Deprecated::ScriptObject to JSObject*. (Inspector::InjectedScriptManager::injectedScriptFor): Updated for the return value change above. * inspector/InjectedScriptManager.h: Ditto. 2016-04-16 Benjamin Poulain [JSC] DFG should support relational comparisons of Number and Other https://bugs.webkit.org/show_bug.cgi?id=156669 Reviewed by Darin Adler. In Sunspider/3d-raytrace, DFG falls back to JSValue in some important relational compare because profiling sees "undefined" from time to time. This case is fairly common outside Sunspider too because of out-of-bounds array access. Unfortunately for us, our fallback for compare is really inefficient. Fortunately, relational comparison with null/undefined/true/false are trival. We can just convert both side to Double. That's what this patch adds. I also extended constant folding for those cases because I noticed a bunch of "undefined" constant going through DoubleRep at runtime. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * tests/stress/compare-number-and-other.js: Added. (opaqueSideEffect): (let.operator.of.operators.eval.testPolymorphic): (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.eval.testMonomorphic): (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.testMonomorphicLeftConstant): (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.testMonomorphicRightConstant): (let.operator.of.operators.let.left.of.typeCases.let.right.of.typeCases.i.testPolymorphic): 2016-04-16 Benjamin Poulain [JSC] FRound/Negate can produce an impure NaN out of a pure NaN https://bugs.webkit.org/show_bug.cgi?id=156528 Reviewed by Filip Pizlo. If you fround a double with the bits 0xfff7000000000000 you get 0xfffe000000000000. The first is a pure NaN, the second isn't. This is without test because I could not find a way to create a 0xfff7000000000000 while convincing DFG that its pure. When we purify NaNs from typed array, we use a specific value of NaN if the input is any NaN, making testing tricky. * bytecode/SpeculatedType.cpp: (JSC::typeOfDoubleNegation): 2016-04-16 Konstantin Tokarev JS::DFG::nodeValuePairListDump does not compile with libstdc++ 4.8 https://bugs.webkit.org/show_bug.cgi?id=156670 Reviewed by Darin Adler. * dfg/DFGNode.h: (JSC::DFG::nodeValuePairListDump): Modified to use lambda as comparator. 2016-04-16 Konstantin Tokarev [mips] Implemented moveZeroToDouble. https://bugs.webkit.org/show_bug.cgi?id=155429 Reviewed by Darin Adler. This function is required to fix compilation after r197687. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::moveZeroToDouble): 2016-04-15 Darin Adler Reduce use of Deprecated::ScriptXXX classes https://bugs.webkit.org/show_bug.cgi?id=156632 Reviewed by Alex Christensen. * bindings/ScriptFunctionCall.cpp: (Deprecated::ScriptCallArgumentHandler::appendArgument): Deleted version that takes a Deprecated::ScriptValue. (Deprecated::ScriptFunctionCall::call): Changed to return a JSValue. * bindings/ScriptFunctionCall.h: Updated for the above. * bindings/ScriptValue.cpp: (Inspector::jsToInspectorValue): Moved from Deprecated namespace to Inspector namespace. Later, we should move this to another source file in the inspector directory. (Inspector::toInspectorValue): Added. (Deprecated::ScriptValue::toInspectorValue): Updated for change to underlying function. * bindings/ScriptValue.h: Update for the above. * inspector/InjectedScript.cpp: (Inspector::InjectedScript::evaluateOnCallFrame): Changed arguments and return values from Deprecated::ScriptValue to JSC::JSValue. (Inspector::InjectedScript::functionDetails): Ditto. (Inspector::InjectedScript::wrapCallFrames): Ditto. (Inspector::InjectedScript::wrapObject): Ditto. (Inspector::InjectedScript::wrapTable): Ditto. (Inspector::InjectedScript::previewValue): Ditto. (Inspector::InjectedScript::setExceptionValue): Ditto. (Inspector::InjectedScript::findObjectById): Ditto. (Inspector::InjectedScript::inspectObject): Ditto. * inspector/InjectedScript.h: Ditto. * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled): Ditto. (Inspector::InjectedScriptBase::makeCall): Ditto. * inspector/InjectedScriptBase.h: Ditto. * inspector/InjectedScriptModule.cpp: (Inspector::InjectedScriptModule::ensureInjected): Ditto. * inspector/ScriptDebugListener.h: Ditto. * inspector/ScriptDebugServer.cpp: (Inspector::ScriptDebugServer::evaluateBreakpointAction): Ditto. (Inspector::ScriptDebugServer::dispatchDidPause): Ditto. (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe): Ditto. (Inspector::ScriptDebugServer::exceptionOrCaughtValue): Ditto. * inspector/ScriptDebugServer.h: Ditto. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::buildExceptionPauseReason): Ditto. (Inspector::InspectorDebuggerAgent::didPause): Ditto. (Inspector::InspectorDebuggerAgent::breakpointActionProbe): Ditto. (Inspector::InspectorDebuggerAgent::didContinue): Ditto. (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState): Ditto. * inspector/agents/InspectorDebuggerAgent.h: Ditto. * inspector/agents/InspectorHeapAgent.cpp: (Inspector::InspectorHeapAgent::getPreview): Ditto. (Inspector::InspectorHeapAgent::getRemoteObject): Ditto. 2016-04-15 Keith Miller Some JIT/DFG operations need NativeCallFrameTracers https://bugs.webkit.org/show_bug.cgi?id=156650 Reviewed by Michael Saboff. Some of our operation functions did not have native call frame tracers. This meant that we would crash occasionally on some of our tests when they triggered a GC in one of the functions without a tracer. In particular, this was exemplified by another upcoming patch when calling operationSetFunctionName. This patch does not add tests since this happens consistently in the patch adding delete_by_id to the DFG. * dfg/DFGOperations.cpp: * jit/JITOperations.cpp: 2016-04-15 Joseph Pecoraro Web Inspector: sourceMappingURL not used when sourceURL is set https://bugs.webkit.org/show_bug.cgi?id=156021 Reviewed by Timothy Hatcher. Clean up Debugger.sourceParsed to separately include: - url ("resource URL", "source url" in JSC APIs) - sourceURL - //# sourceURL directive By always having the resource URL the Web Inspector frontend can better match this Script to a Resource of the same URL, and decide to use the sourceURL if it is available when appropriate. * inspector/protocol/Debugger.json: * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::setBreakpointByUrl): (Inspector::InspectorDebuggerAgent::didParseSource): Send the new sourceParsed parameters. 2016-04-14 Joseph Pecoraro Web Inspector: Cleanup inspector/debugger tests https://bugs.webkit.org/show_bug.cgi?id=156619 Reviewed by Brian Burg. While cleaning up the tests it exposed the fact that breakpoints were not getting disabled when the inspector closes. This means that opening the inspector, with breakpoints, and closing the inspector, would leave the JSC::Debugger thinking breakpoints are active. The JSC::Debugger should be reset. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::disable): 2016-04-14 Geoffrey Garen CopiedBlock should be 64kB Reviewed by Benjamin Poulain. Let's try another value. This is 25% faster on kraken-audio-beat-detection on Mac Pro. * heap/CopiedBlock.h: 2016-04-15 Zan Dobersek Tail call optimizations lead to crashes on ARM Thumb + Linux https://bugs.webkit.org/show_bug.cgi?id=150083 Reviewed by Csaba Osztrogonác. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::repatchNearCall): In case of a tail call relink to the data location of the destination, and not the executable address. This is needed for the ARM Thumb2 platform where both the source and destination addresses of a jump relink must not have the bottom bit decorated, as asserted in ARMv7Assembler::relinkJump(). * jit/Repatch.cpp: (JSC::linkPolymorphicCall): Similarly, when linking a tail call we must link to the address that has a non-decorated bottom bit, as asserted in ARMv7Assembler::linkJumpAbsolute(). 2016-04-14 Geoffrey Garen Unreviewed, rolling out r199567. performance regression on kraken on macbook* Reverted changeset: "CopiedBlock should be 8kB" https://bugs.webkit.org/show_bug.cgi?id=156610 http://trac.webkit.org/changeset/199567 2016-04-14 Geoffrey Garen CopiedBlock should be 8kB https://bugs.webkit.org/show_bug.cgi?id=156610 Reviewed by Michael Saboff. On Mac Pro, this is: 15% faster on kraken-audio-beat-detection 5% faster on v8-splay Hopefully, this will be OK on MacBook* bots as well. 32kB is the full size of L1 cache on x86. So, allocating and zero-filling a 32kB CopiedBlock would basically flush the L1 cache. We can ameliorate this problem by using smaller blocks -- or, if that doesn't work, we can use larger blocks to amortize the cost. * heap/CopiedBlock.h: 2016-04-14 Filip Pizlo PolymorphicAccess should try to generate a stub only once https://bugs.webkit.org/show_bug.cgi?id=156555 Reviewed by Geoffrey Garen. This changes the PolymorphicAccess heuristics to reduce the amount of code generation even more than before. We used to always generate a monomorphic stub for the first case we saw. This change disables that. This change also increases the buffering countdown to match the cool-down repatch count. This means that we will allow for ten slow paths for adding cases, then we will generate a stub, and then we will go into cool-down and the repatching slow paths will not even attempt repatching for a while. After we emerge from cool-down - which requires a bunch of slow path calls - we will again wait for ten slow paths to get new cases. Note that it only takes 13 cases to cause the stub to give up on future repatching entirely. Also, most stubs don't ever get to 10 cases. Therefore, for most stubs this change means that each IC will repatch once. If they make it to two repatching, then the likelihood of a third becomes infinitesimal because of all of the rules that come into play at that point (the size limit being 13, the fact that we go into exponential cool-down every time we generate code, and the fact that if we have lots of self cases then we will create a catch-all megamorphic load case). This also undoes a change to the megamorphic optimization that I think was unintentional. As in the change that originally introduced megamorphic loads, we want to do this only if we would otherwise exhaust the max size of the IC. This is because megamorphic loads are pretty expensive and it's best to use them only if we know that the alternative is giving up on caching. This is neutral on JS benchmarks, but looks like it's another speed-up for page loading. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::canBeReplacedByMegamorphicLoad): (JSC::AccessCase::canReplace): (JSC::AccessCase::dump): (JSC::PolymorphicAccess::regenerate): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::StructureStubInfo): * runtime/Options.h: 2016-04-14 Mark Lam Update treatment of invoking RegExp.prototype methods on RegExp.prototype. https://bugs.webkit.org/show_bug.cgi?id=155922 Reviewed by Keith Miller. According to the TC39 committee, when invoking the following RegExp.prototype methods on the RegExp.prototype: 1. RegExp.prototype.flags yields "" 2. RegExp.prototype.global yields undefined 3. RegExp.prototype.ignoreCase yields undefined 4. RegExp.prototype.multiline yields undefined 5. RegExp.prototype.unicode yields undefined 6. RegExp.prototype.source yields "(?:)" 7. RegExp.prototype.sticky yields undefined 8. RegExp.prototype.toString() yields "/(?:)/" and RegExp.prototype is still NOT an instance of RegExp. The above behavior changes is a special dispensation applicable only to RegExp.prototype. The ES6 spec of throwing errors still applies if those methods are applied to anything = else that is not a RegExp object. * runtime/RegExpPrototype.cpp: (JSC::regExpProtoGetterGlobal): (JSC::regExpProtoGetterIgnoreCase): (JSC::regExpProtoGetterMultiline): (JSC::regExpProtoGetterSticky): (JSC::regExpProtoGetterUnicode): (JSC::regExpProtoGetterFlags): (JSC::regExpProtoGetterSource): - Implemented new behavior. * tests/es6/miscellaneous_built-in_prototypes_are_not_instances.js: (test): - Updated to match current kangax test. 2016-04-14 Geoffrey Garen Some imported ES6 tests are missing __createIterableObject https://bugs.webkit.org/show_bug.cgi?id=156584 Reviewed by Keith Miller. These tests were failing because I neglected to include __createIterableObject when I first imported them. Now they pass. * tests/es6.yaml: * tests/es6/Array_static_methods_Array.from_generic_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/Array_static_methods_Array.from_instances_of_generic_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/Array_static_methods_Array.from_iterator_closing.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): * tests/es6/Array_static_methods_Array.from_map_function_generic_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/Array_static_methods_Array.from_map_function_instances_of_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/Map_iterator_closing.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): * tests/es6/Promise_Promise.all_generic_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test.asyncTestPassed): * tests/es6/Promise_Promise.race_generic_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test.asyncTestPassed): * tests/es6/Set_iterator_closing.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): * tests/es6/WeakMap_iterator_closing.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): * tests/es6/WeakSet_iterator_closing.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): * tests/es6/destructuring_iterator_closing.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): * tests/es6/destructuring_with_generic_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/destructuring_with_instances_of_generic_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/for..of_loops_iterator_closing_break.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): * tests/es6/for..of_loops_iterator_closing_throw.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): * tests/es6/for..of_loops_with_generic_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/for..of_loops_with_instances_of_generic_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/generators_yield_star_generic_iterables.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): * tests/es6/generators_yield_star_iterator_closing_via_throw.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): * tests/es6/spread_..._operator_with_generic_iterables_in_arrays.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/spread_..._operator_with_generic_iterables_in_calls.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/spread_..._operator_with_instances_of_iterables_in_arrays.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): * tests/es6/spread_..._operator_with_instances_of_iterables_in_calls.js: (iterator.next): (iterable.Symbol.iterator): (__createIterableObject): (test): 2016-04-13 Alex Christensen CMake MiniBrowser should be an app bundle https://bugs.webkit.org/show_bug.cgi?id=156521 Reviewed by Brent Fulgham. * PlatformMac.cmake: Unreviewed build fix. Define __STDC_WANT_LIB_EXT1__ so we can find memset_s. 2016-04-13 Joseph Pecoraro JSContext Inspector: Improve Class instances and JSC API Exported Values view in Console / ObjectTree https://bugs.webkit.org/show_bug.cgi?id=156566 Reviewed by Timothy Hatcher. * inspector/InjectedScriptSource.js: (InjectedScript.RemoteObject.prototype._appendPropertyPreviews): Treat non-basic object types as not lossless so they can be expanded. Show non-enumerable native getters in Object previews. 2016-04-13 Michael Saboff Some tests fail with ES6 `u` (Unicode) flag for regular expressions https://bugs.webkit.org/show_bug.cgi?id=151597 Reviewed by Geoffrey Garen. Added two new tables to handle the anomolies of \w and \W CharacterClassEscapes when specified in RegExp's with both the unicode and ignoreCase flags. Given the case folding rules described in the standard vie the meta function Canonicalize(), which allow cross ASCII case folding when unicode is specified, the unicode characters \u017f (small sharp s) and \u212a (kelvin symbol) are part of the \w (word) characterClassEscape. This is true because they case fold to 's' and 'k' respectively. Because they case fold to lower case letters, the corresponding letters, 'k', 'K', 's' and 'S', are also matched with \W with the unicode and ignoreCase flags. * create_regex_tables: * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass): (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn): (JSC::Yarr::YarrPattern::YarrPattern): * yarr/YarrPattern.h: (JSC::Yarr::YarrPattern::wordcharCharacterClass): (JSC::Yarr::YarrPattern::wordUnicodeIgnoreCaseCharCharacterClass): (JSC::Yarr::YarrPattern::nonwordcharCharacterClass): (JSC::Yarr::YarrPattern::nonwordUnicodeIgnoreCaseCharCharacterClass): 2016-04-13 Commit Queue Unreviewed, rolling out r199502 and r199511. https://bugs.webkit.org/show_bug.cgi?id=156557 Appears to have in-browser perf regression (Requested by mlam on #webkit). Reverted changesets: "ES6: Implement String.prototype.split and RegExp.prototype[@@split]." https://bugs.webkit.org/show_bug.cgi?id=156013 http://trac.webkit.org/changeset/199502 "ES6: Implement RegExp.prototype[@@search]." https://bugs.webkit.org/show_bug.cgi?id=156331 http://trac.webkit.org/changeset/199511 2016-04-13 Keith Miller isJSArray should use ArrayType rather than the ClassInfo https://bugs.webkit.org/show_bug.cgi?id=156551 Reviewed by Filip Pizlo. Using the JSType rather than the ClassInfo should be slightly faster since the type is inline on the cell whereas the ClassInfo is only on the structure. * runtime/JSArray.h: (JSC::isJSArray): 2016-04-13 Mark Lam ES6: Implement RegExp.prototype[@@search]. https://bugs.webkit.org/show_bug.cgi?id=156331 Reviewed by Keith Miller. What changed? 1. Implemented search builtin in RegExpPrototype.js. The native path is now used as a fast path. 2. Added DFG support for an IsRegExpObjectIntrinsic (modelled after the IsJSArrayIntrinsic). 3. Renamed @isRegExp to @isRegExpObject to match the new IsRegExpObjectIntrinsic. 4. Change the esSpecIsRegExpObject() implementation to check if the object's JSType is RegExpObjectType instead of walking the classinfo chain. * builtins/RegExpPrototype.js: (search): * builtins/StringPrototype.js: (search): - fixed some indentation. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor): (JSC::DFG::SpeculativeJIT::compileIsRegExpObject): (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction): (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject): (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf): (JSC::FTL::DFG::LowerDFGToB3::isExoticForTypeof): (JSC::FTL::DFG::LowerDFGToB3::isRegExpObject): (JSC::FTL::DFG::LowerDFGToB3::isType): * runtime/Intrinsic.h: - Added IsRegExpObjectIntrinsic. * runtime/CommonIdentifiers.h: * runtime/ECMAScriptSpecInternalFunctions.cpp: (JSC::esSpecIsConstructor): - Changed to use uncheckedArgument since this is only called from internal code. (JSC::esSpecIsRegExpObject): (JSC::esSpecIsRegExp): Deleted. * runtime/ECMAScriptSpecInternalFunctions.h: - Changed to check the object for a JSType of RegExpObjectType. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): - Added split fast path. * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): (JSC::regExpProtoFuncSearchFast): (JSC::regExpProtoFuncSearch): Deleted. * runtime/RegExpPrototype.h: * tests/es6.yaml: * tests/stress/regexp-search.js: - Rebased test. 2016-04-12 Filip Pizlo PolymorphicAccess::regenerate() shouldn't have to clone non-generated AccessCases https://bugs.webkit.org/show_bug.cgi?id=156493 Reviewed by Geoffrey Garen. Cloning AccessCases is only necessary if they hold some artifacts that are used by code that they already generated. So, if the state is not Generated, we don't have to bother with cloning them. This should speed up PolymorphicAccess regeneration a bit more. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::commit): (JSC::PolymorphicAccess::regenerate): 2016-04-13 Mark Lam ES6: Implement String.prototype.split and RegExp.prototype[@@split]. https://bugs.webkit.org/show_bug.cgi?id=156013 Reviewed by Keith Miller. Re-landing r199393 now that the shadow chicken crash has been fixed. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/GlobalObject.js: (speciesConstructor): * builtins/PromisePrototype.js: - refactored to use the @speciesConstructor internal function. * builtins/RegExpPrototype.js: (advanceStringIndex): - refactored from @advanceStringIndexUnicode() to be match the spec. Benchmarks show that there's no advantage in doing the unicode check outside of the advanceStringIndexUnicode part. So, I simplified the code to match the spec (especially since @@split needs to call advanceStringIndex from more than 1 location). (match): - Removed an unnecessary call to @Object because it was already proven above. - Changed to use advanceStringIndex instead of advanceStringIndexUnicode. Again, there's no perf regression for this. (regExpExec): (hasObservableSideEffectsForRegExpSplit): (split): (advanceStringIndexUnicode): Deleted. * builtins/StringPrototype.js: (split): - Modified to use RegExp.prototype[@@split]. * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): (JSC::BytecodeIntrinsicRegistry::lookup): * bytecode/BytecodeIntrinsicRegistry.h: - Added the @@split symbol. * runtime/CommonIdentifiers.h: * runtime/ECMAScriptSpecInternalFunctions.cpp: Added. (JSC::esSpecIsConstructor): (JSC::esSpecIsRegExp): * runtime/ECMAScriptSpecInternalFunctions.h: Added. * runtime/JSGlobalObject.cpp: (JSC::getGetterById): (JSC::JSGlobalObject::init): * runtime/PropertyDescriptor.cpp: (JSC::PropertyDescriptor::setDescriptor): - Removed an assert that is no longer valid. * runtime/RegExpObject.h: - Made advanceStringUnicode() public so that it can be re-used by the regexp split fast path. * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): (JSC::regExpProtoFuncExec): (JSC::regExpProtoFuncSearch): (JSC::advanceStringIndex): (JSC::regExpProtoFuncSplitFast): * runtime/RegExpPrototype.h: * runtime/StringObject.h: (JSC::jsStringWithReuse): (JSC::jsSubstring): - Hoisted some utility functions from StringPrototype.cpp so that they can be reused by the regexp split fast path. * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::stringProtoFuncSplitFast): (JSC::stringProtoFuncSubstr): (JSC::builtinStringSubstrInternal): (JSC::stringProtoFuncSubstring): (JSC::stringIncludesImpl): (JSC::stringProtoFuncIncludes): (JSC::builtinStringIncludesInternal): (JSC::jsStringWithReuse): Deleted. (JSC::jsSubstring): Deleted. (JSC::stringProtoFuncSplit): Deleted. * runtime/StringPrototype.h: * tests/es6.yaml: 2016-04-13 Mark Lam ShadowChicken::visitChildren() should not visit tailMarkers and throwMarkers. https://bugs.webkit.org/show_bug.cgi?id=156532 Reviewed by Saam Barati and Filip Pizlo. ShadowChicken can store tailMarkers and throwMarkers in its log, specifically in the callee field of a log packet. However, ShadowChicken::visitChildren() unconditionally visits the callee field of each packet as if they are real objects. If visitChildren() encounters one of these markers in the log, we get a crash. This crash was observed in the v8-v6/v8-regexp.js stress test running with shadow chicken when r199393 landed. r199393 introduced tail calls to a RegExp split fast path, and the v8-regexp.js test exercised this fast path a lot. Throw in some timely GCs, and we get a crash party. The fix is to have ShadowChicken::visitChildren() filter out the tailMarker and throwMarker. Alternatively, if perf is an issue, we can allocate 2 dedicated objects for these markers so that ShadowChicken can continue to visit them. For now, I'm going with the filter. * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::visitChildren): 2016-04-13 Yusuke Suzuki [ES6] Add @@toStringTag to GeneratorFunction https://bugs.webkit.org/show_bug.cgi?id=156499 Reviewed by Mark Lam. GeneratorFunction.prototype has @@toStringTag property, "GeneratorFunction". https://tc39.github.io/ecma262/#sec-generatorfunction.prototype-@@tostringtag * runtime/GeneratorFunctionPrototype.cpp: (JSC::GeneratorFunctionPrototype::finishCreation): * tests/es6.yaml: * tests/es6/well-known_symbols_Symbol.toStringTag_new_built-ins.js: Added. (test): 2016-04-13 Alberto Garcia Fix build in glibc-based BSD systems https://bugs.webkit.org/show_bug.cgi?id=156533 Reviewed by Carlos Garcia Campos. Change the order of the #elif conditionals so glibc-based BSD systems (e.g. Debian GNU/kFreeBSD) use the code inside the OS(FREEBSD) blocks. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::Thread::Registers::stackPointer): (JSC::MachineThreads::Thread::Registers::framePointer): (JSC::MachineThreads::Thread::Registers::instructionPointer): (JSC::MachineThreads::Thread::Registers::llintPC): 2016-04-12 Keith Miller Unreviewed undo change from ArrayClass to ArrayWithUndecided, which was not intedend to land with r199397. * runtime/ArrayPrototype.h: (JSC::ArrayPrototype::createStructure): 2016-04-12 Mark Lam Rollout: ES6: Implement String.prototype.split and RegExp.prototype[@@split]. https://bugs.webkit.org/show_bug.cgi?id=156013 Speculative rollout to fix 32-bit shadow-chicken.yaml/tests/v8-v6/v8-regexp.js.shadow-chicken test failure. Not reviewed. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/GlobalObject.js: (speciesGetter): (speciesConstructor): Deleted. * builtins/PromisePrototype.js: * builtins/RegExpPrototype.js: (advanceStringIndexUnicode): (match): (advanceStringIndex): Deleted. (regExpExec): Deleted. (hasObservableSideEffectsForRegExpSplit): Deleted. (split): Deleted. * builtins/StringPrototype.js: (repeat): (split): Deleted. * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): (JSC::BytecodeIntrinsicRegistry::lookup): * bytecode/BytecodeIntrinsicRegistry.h: * runtime/CommonIdentifiers.h: * runtime/ECMAScriptSpecInternalFunctions.cpp: Removed. * runtime/ECMAScriptSpecInternalFunctions.h: Removed. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::setGlobalThis): (JSC::JSGlobalObject::init): (JSC::getGetterById): Deleted. * runtime/PropertyDescriptor.cpp: (JSC::PropertyDescriptor::setDescriptor): * runtime/RegExpObject.h: (JSC::RegExpObject::offsetOfLastIndexIsWritable): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): (JSC::regExpProtoFuncExec): (JSC::regExpProtoFuncSearch): (JSC::advanceStringIndex): Deleted. (JSC::regExpProtoFuncSplitFast): Deleted. * runtime/RegExpPrototype.h: * runtime/StringObject.h: (JSC::jsStringWithReuse): Deleted. (JSC::jsSubstring): Deleted. * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::jsStringWithReuse): (JSC::jsSubstring): (JSC::substituteBackreferencesSlow): (JSC::splitStringByOneCharacterImpl): (JSC::stringProtoFuncSplit): (JSC::stringProtoFuncSubstr): (JSC::stringProtoFuncSubstring): (JSC::stringProtoFuncEndsWith): (JSC::stringProtoFuncIncludes): (JSC::stringProtoFuncIterator): (JSC::stringProtoFuncSplitFast): Deleted. (JSC::builtinStringSubstrInternal): Deleted. (JSC::stringIncludesImpl): Deleted. (JSC::builtinStringIncludesInternal): Deleted. * runtime/StringPrototype.h: * tests/es6.yaml: 2016-04-12 Mark Lam Remove 2 unused JSC options. https://bugs.webkit.org/show_bug.cgi?id=156526 Reviewed by Benjamin Poulain. The options JSC_assertICSizing and JSC_dumpFailedICSizing are no longer in use now that we have B3. * runtime/Options.h: 2016-04-12 Keith Miller [ES6] Add support for Symbol.isConcatSpreadable. https://bugs.webkit.org/show_bug.cgi?id=155351 Reviewed by Saam Barati. This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to a builtin performant. First, four new DFG intrinsics were added. 1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of the Array.isArray function. 2) IsJSArray: checks the first child is a JSArray object. 3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor. 4) CallObjectConstructor: an intrinsic of the Object constructor. IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if we are able to prove that the first child is an Array or for ToObject an Object. In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this into a contiguous array). This patch also adds a new fast path for concat with more than one array argument by using memcpy to append values onto the result array. This works roughly the same as the two array fast path using the same methodology to decide if we can memcpy the other butterfly into the result butterfly. Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our dataLog function on it. Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a JSValueOperand if the operand's use count is one. * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/ArrayPrototype.js: (concatSlowPath): (concat): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::compileIsJSArray): (JSC::DFG::SpeculativeJIT::compileIsArrayObject): (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor): (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject): (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor): (JSC::FTL::DFG::LowerDFGToB3::isArray): * jit/JITOperations.h: * jsc.cpp: (GlobalObject::finishCreation): (functionDataLogValue): * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::finishCreation): (JSC::arrayConstructorPrivateFuncIsArrayConstructor): * runtime/ArrayConstructor.h: (JSC::isArrayConstructor): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): (JSC::arrayProtoPrivateFuncIsJSArray): (JSC::moveElements): (JSC::arrayProtoPrivateFuncConcatMemcpy): (JSC::arrayProtoPrivateFuncAppendMemcpy): (JSC::arrayProtoFuncConcat): Deleted. * runtime/ArrayPrototype.h: (JSC::ArrayPrototype::createStructure): * runtime/CommonIdentifiers.h: * runtime/Intrinsic.h: * runtime/JSArray.cpp: (JSC::JSArray::appendMemcpy): (JSC::JSArray::fastConcatWith): Deleted. * runtime/JSArray.h: (JSC::JSArray::createStructure): (JSC::JSArray::fastConcatType): Deleted. * runtime/JSArrayInlines.h: Added. (JSC::JSArray::memCopyWithIndexingType): (JSC::JSArray::canFastCopy): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSType.h: * runtime/ObjectConstructor.h: (JSC::constructObject): * tests/es6.yaml: * tests/stress/array-concat-spread-object.js: Added. (arrayEq): * tests/stress/array-concat-spread-proxy-exception-check.js: Added. (arrayEq): * tests/stress/array-concat-spread-proxy.js: Added. (arrayEq): * tests/stress/array-concat-with-slow-indexingtypes.js: Added. (arrayEq): * tests/stress/array-species-config-array-constructor.js: 2016-04-12 Saam barati Lets not iterate over the constant pool twice every time we link a code block https://bugs.webkit.org/show_bug.cgi?id=156517 Reviewed by Mark Lam. I introduced a second iteration over the constant pool when I implemented block scoping. I did this because we must clone all the symbol tables when we link a CodeBlock. We can just do this cloning when setting the constant registers for the first time. There is no need to iterate over the constant pool a second time. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::~CodeBlock): (JSC::CodeBlock::setConstantRegisters): (JSC::CodeBlock::setAlternative): * bytecode/CodeBlock.h: (JSC::CodeBlock::replaceConstant): (JSC::CodeBlock::setConstantRegisters): Deleted. 2016-04-12 Mark Lam ES6: Implement String.prototype.split and RegExp.prototype[@@split]. https://bugs.webkit.org/show_bug.cgi?id=156013 Reviewed by Keith Miller. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/GlobalObject.js: (speciesConstructor): * builtins/PromisePrototype.js: - refactored to use the @speciesConstructor internal function. * builtins/RegExpPrototype.js: (advanceStringIndex): - refactored from @advanceStringIndexUnicode() to be match the spec. Benchmarks show that there's no advantage in doing the unicode check outside of the advanceStringIndexUnicode part. So, I simplified the code to match the spec (especially since @@split needs to call advanceStringIndex from more than 1 location). (match): - Removed an unnecessary call to @Object because it was already proven above. - Changed to use advanceStringIndex instead of advanceStringIndexUnicode. Again, there's no perf regression for this. (regExpExec): (hasObservableSideEffectsForRegExpSplit): (split): (advanceStringIndexUnicode): Deleted. * builtins/StringPrototype.js: (split): - Modified to use RegExp.prototype[@@split]. * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): (JSC::BytecodeIntrinsicRegistry::lookup): * bytecode/BytecodeIntrinsicRegistry.h: - Added the @@split symbol. * runtime/CommonIdentifiers.h: * runtime/ECMAScriptSpecInternalFunctions.cpp: Added. (JSC::esSpecIsConstructor): (JSC::esSpecIsRegExp): * runtime/ECMAScriptSpecInternalFunctions.h: Added. * runtime/JSGlobalObject.cpp: (JSC::getGetterById): (JSC::JSGlobalObject::init): * runtime/PropertyDescriptor.cpp: (JSC::PropertyDescriptor::setDescriptor): - Removed an assert that is no longer valid. * runtime/RegExpObject.h: - Made advanceStringUnicode() public so that it can be re-used by the regexp split fast path. * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): (JSC::regExpProtoFuncExec): (JSC::regExpProtoFuncSearch): (JSC::advanceStringIndex): (JSC::regExpProtoFuncSplitFast): * runtime/RegExpPrototype.h: * runtime/StringObject.h: (JSC::jsStringWithReuse): (JSC::jsSubstring): - Hoisted some utility functions from StringPrototype.cpp so that they can be reused by the regexp split fast path. * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::stringProtoFuncSplitFast): (JSC::stringProtoFuncSubstr): (JSC::builtinStringSubstrInternal): (JSC::stringProtoFuncSubstring): (JSC::stringIncludesImpl): (JSC::stringProtoFuncIncludes): (JSC::builtinStringIncludesInternal): (JSC::jsStringWithReuse): Deleted. (JSC::jsSubstring): Deleted. (JSC::stringProtoFuncSplit): Deleted. * runtime/StringPrototype.h: * tests/es6.yaml: 2016-04-12 Keith Miller AbstractValue should use the result type to filter structures https://bugs.webkit.org/show_bug.cgi?id=156516 Reviewed by Geoffrey Garen. When filtering an AbstractValue with a SpeculatedType we would not use the merged type when filtering out the valid structures (despite what the comment directly above said). This would cause us to crash if our structure-set was Top and the two speculated types were different kinds of cells. * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::filter): * tests/stress/ai-consistency-filter-cells.js: Added. (get value): (attribute.value.get record): (attribute.attrs.get this): (get foo): (let.thisValue.return.serialize): (let.thisValue.transformFor): 2016-04-12 Filip Pizlo Unreviewed, remove FIXME for https://bugs.webkit.org/show_bug.cgi?id=156457 and replace it with a comment that describes what we do now. * bytecode/PolymorphicAccess.h: 2016-04-12 Saam barati isLocked() assertion broke builds because ConcurrentJITLock isn't always a real lock. Rubber-stamped by Filip Pizlo. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resultProfileForBytecodeOffset): (JSC::CodeBlock::ensureResultProfile): 2016-04-11 Filip Pizlo PolymorphicAccess should buffer AccessCases before regenerating https://bugs.webkit.org/show_bug.cgi?id=156457 Reviewed by Benjamin Poulain. Prior to this change, whenever we added an AccessCase to a PolymorphicAccess, we would regenerate the whole stub. That meant that we'd do O(N^2) work for N access cases. One way to fix this is to have each AccessCase generate a stub just for itself, which cascades down to the already-generated cases. But that removes the binary switch optimization, which makes the IC perform great even when there are many cases. This change fixes the issue by buffering access cases. When we take slow path and try to add a new case, the StructureStubInfo will usually just buffer the new case without generating new code. We simply guarantee that after we buffer a case, we will take at most Options::repatchBufferingCountdown() slow path calls before generating code for it. That option is currently 7. Taking 7 more slow paths means that we have 7 more opportunities to gather more access cases, or to realize that this IC is too crazy to bother with. This change ensures that the DFG still gets the same kind of profiling. This is because the buffered AccessCases are still part of PolymorphicAccess and so are still scanned by GetByIdStatus and PutByIdStatus. The fact that the AccessCases hadn't been generated and so hadn't executed doesn't change much. Mainly, it increases the likelihood that the DFG will see an access case that !couldStillSucceed(). The DFG's existing profile parsing logic can handle this just fine. There are a bunch of algorithmic changes here. StructureStubInfo now caches the set of structures that it has seen as a guard to prevent adding lots of redundant cases, in case we see the same 7 cases after buffering the first one. This cache means we won't wastefully allocate 7 identical AccessCase instances. PolymorphicAccess is now restructured around having separate addCase() and regenerate() calls. That means a bit more moving data around. So far that seems OK for performance, probably since it's O(N) work rather than O(N^2) work. There is room for improvement for future patches, to be sure. This is benchmarking as slightly positive or neutral on JS benchmarks. It's meant to reduce pathologies I saw in page loads. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::PolymorphicAccess): (JSC::PolymorphicAccess::~PolymorphicAccess): (JSC::PolymorphicAccess::addCases): (JSC::PolymorphicAccess::addCase): (JSC::PolymorphicAccess::visitWeak): (JSC::PolymorphicAccess::dump): (JSC::PolymorphicAccess::commit): (JSC::PolymorphicAccess::regenerate): (JSC::PolymorphicAccess::aboutToDie): (WTF::printInternal): (JSC::PolymorphicAccess::regenerateWithCases): Deleted. (JSC::PolymorphicAccess::regenerateWithCase): Deleted. * bytecode/PolymorphicAccess.h: (JSC::AccessCase::isGetter): (JSC::AccessCase::callLinkInfo): (JSC::AccessGenerationResult::AccessGenerationResult): (JSC::AccessGenerationResult::madeNoChanges): (JSC::AccessGenerationResult::gaveUp): (JSC::AccessGenerationResult::buffered): (JSC::AccessGenerationResult::generatedNewCode): (JSC::AccessGenerationResult::generatedFinalCode): (JSC::AccessGenerationResult::shouldGiveUpNow): (JSC::AccessGenerationResult::generatedSomeCode): (JSC::PolymorphicAccess::isEmpty): (JSC::PolymorphicAccess::size): (JSC::PolymorphicAccess::at): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeForStubInfo): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::StructureStubInfo): (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::reset): (JSC::StructureStubInfo::visitWeakReferences): * bytecode/StructureStubInfo.h: (JSC::StructureStubInfo::considerCaching): (JSC::StructureStubInfo::willRepatch): Deleted. (JSC::StructureStubInfo::willCoolDown): Deleted. * jit/JITOperations.cpp: * jit/Repatch.cpp: (JSC::tryCacheGetByID): (JSC::repatchGetByID): (JSC::tryCachePutByID): (JSC::repatchPutByID): (JSC::tryRepatchIn): (JSC::repatchIn): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::putByIndex): (JSC::JSValue::structureOrNull): (JSC::JSValue::structureOrUndefined): * runtime/Options.h: 2016-04-12 Saam barati There is a race with the compiler thread and the main thread with result profiles https://bugs.webkit.org/show_bug.cgi?id=156503 Reviewed by Filip Pizlo. The compiler thread should not be asking for a result profile while the execution thread is creating one. We must guard against such races with a lock. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::resultProfileForBytecodeOffset): (JSC::CodeBlock::ensureResultProfile): (JSC::CodeBlock::capabilityLevel): * bytecode/CodeBlock.h: (JSC::CodeBlock::couldTakeSlowCase): (JSC::CodeBlock::numberOfResultProfiles): (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): (JSC::CodeBlock::ensureResultProfile): Deleted. 2016-04-12 Commit Queue Unreviewed, rolling out r199339. https://bugs.webkit.org/show_bug.cgi?id=156505 memset_s is indeed necessary (Requested by alexchristensen_ on #webkit). Reverted changeset: "Build fix after r199299." https://bugs.webkit.org/show_bug.cgi?id=155508 http://trac.webkit.org/changeset/199339 2016-04-12 Guillaume Emont MIPS: add MacroAssemblerMIPS::store8(TrustedImm32,ImplicitAddress) https://bugs.webkit.org/show_bug.cgi?id=156481 This method with this signature is used by r199075, and therefore WebKit doesn't build on MIPS since then. Reviewed by Mark Lam. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::store8): 2016-04-12 Saam barati We incorrectly parse arrow function expressions https://bugs.webkit.org/show_bug.cgi?id=156373 Reviewed by Mark Lam. This patch removes the notion of "isEndOfArrowFunction". This was a very weird function and it was incorrect. It checked that the arrow functions with concise body grammar production "had a valid ending". "had a valid ending" is in quotes because concise body arrow functions have a valid ending as long as their body has a valid assignment expression. I've removed all notion of this function because it was wrong and was causing us to throw syntax errors on valid programs. * parser/Lexer.cpp: (JSC::Lexer::nextTokenIsColon): (JSC::Lexer::lex): (JSC::Lexer::setTokenPosition): Deleted. * parser/Lexer.h: (JSC::Lexer::setIsReparsingFunction): (JSC::Lexer::isReparsingFunction): (JSC::Lexer::lineNumber): * parser/Parser.cpp: (JSC::Parser::parseInner): (JSC::Parser::parseArrowFunctionSingleExpressionBodySourceElements): (JSC::Parser::parseFunctionInfo): * parser/Parser.h: (JSC::Parser::matchIdentifierOrKeyword): (JSC::Parser::tokenStart): (JSC::Parser::autoSemiColon): (JSC::Parser::canRecurse): (JSC::Parser::isEndOfArrowFunction): Deleted. (JSC::Parser::setEndOfStatement): Deleted. * tests/stress/arrowfunction-others.js: (testCase): (simpleArrowFunction): (truthy): (falsey): 2016-04-12 Yusuke Suzuki [JSC] addStaticGlobals should emit SymbolTableEntry watchpoints to encourage constant folding in DFG https://bugs.webkit.org/show_bug.cgi?id=155110 Reviewed by Saam Barati. `addStaticGlobals` does not emit SymbolTableEntry watchpoints for the added entries. So, all the global variable lookups pointing to these static globals are not converted into constants in DFGBytecodeGenerator: this fact leaves these lookups as GetGlobalVar. Such thing avoids constant folding chance and emits CheckCell for @privateFunction inlining. This operation is pure overhead. Static globals are not configurable, and they are typically non-writable. So they are constants in almost all the cases. This patch initializes watchpoints for these static globals. These watchpoints allow DFG to convert these nodes into constants in DFG BytecodeParser. These watchpoints includes many builtin operations and `undefined`. The microbenchmark, many-foreach-calls shows 5 - 7% improvement since it removes unnecessary CheckCell. * bytecode/VariableWriteFireDetail.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addGlobalVar): (JSC::JSGlobalObject::addStaticGlobals): * runtime/JSSymbolTableObject.h: (JSC::symbolTablePutTouchWatchpointSet): (JSC::symbolTablePutInvalidateWatchpointSet): (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributesTouchWatchpointSet): Deleted. * runtime/SymbolTable.h: (JSC::SymbolTableEntry::SymbolTableEntry): (JSC::SymbolTableEntry::operator=): (JSC::SymbolTableEntry::swap): 2016-04-12 Alex Christensen Build fix after r199299. https://bugs.webkit.org/show_bug.cgi?id=155508 * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps): memset_s is not defined. __STDC_WANT_LIB_EXT1__ is not defined anywhere. Since the return value is unused and set_constraint_handler_s is never called I'm chaning it to memset. 2016-04-11 Benjamin Poulain [JSC] B3 can use undefined bits or not defined required bits when spilling https://bugs.webkit.org/show_bug.cgi?id=156486 Reviewed by Filip Pizlo. Spilling had issues when replacing arguments in place. The problems are: 1) If we have a 32bit stackslot, a x86 instruction could still try to load 64bits from it. 2) If we have a 64bit stackslot, Move32 would only set half the bits. 3) We were reducing Move to Move32 even if the top bits are read from the stack slot. The case 1 appear with something like this: Move32 %tmp0, %tmp1 Op64 %tmp1, %tmp2, %tmp3 When we spill %tmp1, the stack slot is 32bit, Move32 sets 32bits but Op64 supports addressing for %tmp1. When we substitute %tmp1 in Op64, we are creating a 64bit read for a 32bit stack slot. The case 2 is an other common one. If we have: BB#1 Move32 %tmp0, %tmp1 Jump #3 BB#2 Op64 %tmp0, %tmp1 Jump #3 BB#3 Use64 %tmp1 We have a stack slot of 64bits. When spilling %tmp1 in #1, we are effectively doing a 32bit store on the stack slot, leaving the top bits undefined. Case 3 is pretty much the same as 2 but we create the Move32 ourself because the source is a 32bit with ZDef. Case (1) is solved by requiring that the stack slot is at least as large as the largest use/def of that tmp. Case (2) and (3) are solved by not replacing a Tmp by an Address if the Def is smaller than the stack slot. * b3/air/AirIteratedRegisterCoalescing.cpp: * b3/testb3.cpp: (JSC::B3::testSpillDefSmallerThanUse): (JSC::B3::testSpillUseLargerThanDef): (JSC::B3::run): 2016-04-11 Brian Burg Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses https://bugs.webkit.org/show_bug.cgi?id=156407 Reviewed by Joseph Pecoraro. There's no point having these subclasses as they don't save any space. Add a StringImpl to the union and merge some implementations of writeJSON. Rename m_data to m_map and explicitly name the union as InspectorValue::m_value. If the value is a string and the string is not empty or null (i.e., it has a StringImpl), then we need to ref() and deref() the string as the InspectorValue is created or destroyed. Move uses of the subclass to InspectorValue and delete redundant methods. Now, most InspectorValue methods are non-virtual so they can be templated. * bindings/ScriptValue.cpp: (Deprecated::jsToInspectorValue): * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::makeCall): Don't used deleted subclasses. * inspector/InspectorValues.cpp: (Inspector::InspectorValue::null): (Inspector::InspectorValue::create): (Inspector::InspectorValue::asValue): (Inspector::InspectorValue::asBoolean): (Inspector::InspectorValue::asDouble): (Inspector::InspectorValue::asInteger): (Inspector::InspectorValue::asString): These only need one implementation now. (Inspector::InspectorValue::writeJSON): Still a virtual method since Object and Array need their members. (Inspector::InspectorObjectBase::InspectorObjectBase): (Inspector::InspectorBasicValue::asBoolean): Deleted. (Inspector::InspectorBasicValue::asDouble): Deleted. (Inspector::InspectorBasicValue::asInteger): Deleted. (Inspector::InspectorBasicValue::writeJSON): Deleted. (Inspector::InspectorString::asString): Deleted. (Inspector::InspectorString::writeJSON): Deleted. (Inspector::InspectorString::create): Deleted. (Inspector::InspectorBasicValue::create): Deleted. * inspector/InspectorValues.h: (Inspector::InspectorObjectBase::find): (Inspector::InspectorObjectBase::setBoolean): (Inspector::InspectorObjectBase::setInteger): (Inspector::InspectorObjectBase::setDouble): (Inspector::InspectorObjectBase::setString): (Inspector::InspectorObjectBase::setValue): (Inspector::InspectorObjectBase::setObject): (Inspector::InspectorObjectBase::setArray): (Inspector::InspectorArrayBase::pushBoolean): (Inspector::InspectorArrayBase::pushInteger): (Inspector::InspectorArrayBase::pushDouble): (Inspector::InspectorArrayBase::pushString): (Inspector::InspectorArrayBase::pushValue): (Inspector::InspectorArrayBase::pushObject): (Inspector::InspectorArrayBase::pushArray): Use new factory methods. * replay/EncodedValue.cpp: (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): * replay/EncodedValue.h: Use new factory methods. 2016-04-11 Filip Pizlo It should be possible to edit StructureStubInfo without recompiling the world https://bugs.webkit.org/show_bug.cgi?id=156470 Reviewed by Keith Miller. This change makes it less painful to make changes to the IC code. It used to be that any change to StructureStubInfo caused every JIT-related file to get recompiled. Now only a smaller set of files - ones that actually peek into StructureStubInfo - will recompile. This is mainly because CodeBlock.h no longer includes StructureStubInfo.h. * bytecode/ByValInfo.h: * bytecode/CodeBlock.cpp: * bytecode/CodeBlock.h: * bytecode/GetByIdStatus.cpp: * bytecode/GetByIdStatus.h: * bytecode/PutByIdStatus.cpp: * bytecode/PutByIdStatus.h: * bytecode/StructureStubInfo.h: (JSC::getStructureStubInfoCodeOrigin): * dfg/DFGByteCodeParser.cpp: * dfg/DFGJITCompiler.cpp: * dfg/DFGOSRExitCompilerCommon.cpp: * dfg/DFGSpeculativeJIT.h: * ftl/FTLLowerDFGToB3.cpp: * ftl/FTLSlowPathCall.h: * jit/IntrinsicEmitter.cpp: * jit/JITInlineCacheGenerator.cpp: * jit/JITInlineCacheGenerator.h: * jit/JITOperations.cpp: * jit/JITPropertyAccess.cpp: * jit/JITPropertyAccess32_64.cpp: 2016-04-11 Skachkov Oleksandr Remove NewArrowFunction from DFG IR https://bugs.webkit.org/show_bug.cgi?id=156439 Reviewed by Saam Barati. It seems that NewArrowFunction was left in DFG IR during refactoring by mistake. * dfg/DFGAbstractInterpreterInlines.h: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGClobbersExitState.cpp: * dfg/DFGDoesGC.cpp: * dfg/DFGFixupPhase.cpp: * dfg/DFGMayExit.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::convertToPhantomNewFunction): * dfg/DFGNodeType.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunction): * dfg/DFGSpeculativeJIT32_64.cpp: * dfg/DFGSpeculativeJIT64.cpp: * dfg/DFGStoreBarrierInsertionPhase.cpp: * dfg/DFGStructureRegistrationPhase.cpp: * ftl/FTLCapabilities.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): 2016-04-05 Oliver Hunt Remove compile time define for SEPARATED_HEAP https://bugs.webkit.org/show_bug.cgi?id=155508 Reviewed by Mark Lam. Remove the SEPARATED_HEAP compile time flag. The separated heap is available, but off by default, on x86_64, ARMv7, and ARM64. Working through the issues that happened last time essentially required implementing the ARMv7 path for the separated heap just so I could find all the ways it was going wrong. We fixed all the logic by making the branch and jump logic in the linker and assemblers take two parameters, the location to write to, and the location we'll actually be writing to. We need to do this because it's no longer sufficient to compute jumps relative to region the linker is writing to. The repatching jump, branch, and call functions only need the executable address as the patching is performed directly using performJITMemcpy function which works in terms of the executable address. There is no performance impact on jsc-benchmarks with the separate heap either emabled or disabled. * Configurations/FeatureDefines.xcconfig: * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::linkJump): (JSC::ARM64Assembler::linkCall): (JSC::ARM64Assembler::relinkJump): (JSC::ARM64Assembler::relinkCall): (JSC::ARM64Assembler::link): (JSC::ARM64Assembler::linkJumpOrCall): (JSC::ARM64Assembler::linkCompareAndBranch): (JSC::ARM64Assembler::linkConditionalBranch): (JSC::ARM64Assembler::linkTestAndBranch): (JSC::ARM64Assembler::relinkJumpOrCall): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2): (JSC::ARMv7Assembler::revertJumpTo_movT3): (JSC::ARMv7Assembler::link): (JSC::ARMv7Assembler::linkJump): (JSC::ARMv7Assembler::relinkJump): (JSC::ARMv7Assembler::repatchCompact): (JSC::ARMv7Assembler::replaceWithJump): (JSC::ARMv7Assembler::replaceWithLoad): (JSC::ARMv7Assembler::replaceWithAddressComputation): (JSC::ARMv7Assembler::setInt32): (JSC::ARMv7Assembler::setUInt7ForLoad): (JSC::ARMv7Assembler::isB): (JSC::ARMv7Assembler::isBX): (JSC::ARMv7Assembler::isMOV_imm_T3): (JSC::ARMv7Assembler::isMOVT): (JSC::ARMv7Assembler::isNOP_T1): (JSC::ARMv7Assembler::isNOP_T2): (JSC::ARMv7Assembler::linkJumpT1): (JSC::ARMv7Assembler::linkJumpT2): (JSC::ARMv7Assembler::linkJumpT3): (JSC::ARMv7Assembler::linkJumpT4): (JSC::ARMv7Assembler::linkConditionalJumpT4): (JSC::ARMv7Assembler::linkBX): (JSC::ARMv7Assembler::linkConditionalBX): (JSC::ARMv7Assembler::linkJumpAbsolute): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::link): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::link): * jit/ExecutableAllocator.h: (JSC::performJITMemcpy): * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps): (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator): (JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion): (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Deleted. * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/Options.h: 2016-04-10 Filip Pizlo Clean up how we reason about the states of AccessCases https://bugs.webkit.org/show_bug.cgi?id=156454 Reviewed by Mark Lam. Currently when we add an AccessCase to a PolymorphicAccess stub, we regenerate the stub. That means that as we grow a stub to have N cases, we will do O(N^2) generation work. I want to explore buffering AccessCases so that we can do O(N) generation work instead. But to before I go there, I want to make sure that the statefulness of AccessCase makes sense. So, I broke it down into three different states and added assertions about the transitions. I also broke out a separate operation called AccessCase::commit(), which is the work that cannot be buffered since there cannot be any JS effects between when the AccessCase was created and when we do the work in commit(). This opens up a fairly obvious path to buffering AccessCases: add them to the list without regenerating. Then when we do eventually trigger regeneration, those cases will get cloned and generated automagically. This patch doesn't implement this technique yet, but gives us an opportunity to independently test the scaffolding necessary to do it. This is perf-neutral on lots of tests. * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationResult::dump): (JSC::AccessCase::clone): (JSC::AccessCase::commit): (JSC::AccessCase::guardedByStructureCheck): (JSC::AccessCase::dump): (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generate): (JSC::AccessCase::generateImpl): (JSC::PolymorphicAccess::regenerateWithCases): (JSC::PolymorphicAccess::regenerate): (WTF::printInternal): * bytecode/PolymorphicAccess.h: (JSC::AccessCase::type): (JSC::AccessCase::state): (JSC::AccessCase::offset): (JSC::AccessCase::viaProxy): (JSC::AccessCase::callLinkInfo): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): * bytecode/Watchpoint.h: * dfg/DFGOperations.cpp: * jit/Repatch.cpp: (JSC::repatchGetByID): (JSC::repatchPutByID): (JSC::repatchIn): * runtime/VM.cpp: (JSC::VM::dumpRegExpTrace): (JSC::VM::ensureWatchpointSetForImpureProperty): (JSC::VM::registerWatchpointForImpureProperty): (JSC::VM::addImpureProperty): * runtime/VM.h: 2016-04-11 Fujii Hironori [CMake] Make FOLDER property INHERITED https://bugs.webkit.org/show_bug.cgi?id=156460 Reviewed by Brent Fulgham. * CMakeLists.txt: * shell/CMakeLists.txt: * shell/PlatformWin.cmake: Set FOLDER property as a directory property not a target property 2016-04-09 Keith Miller tryGetById should be supported by the DFG/FTL https://bugs.webkit.org/show_bug.cgi?id=156378 Reviewed by Filip Pizlo. This patch adds support for tryGetById in the DFG/FTL. It adds a new DFG node TryGetById, which acts similarly to the normal GetById DFG node. One key difference between GetById and TryGetById is that in the LLInt and Baseline we do not profile the result type. This profiling is unnessary for the current use case of tryGetById, which is expected to be a strict equality comparision against a specific object or undefined. In either case other DFG optimizations will make this equally fast with or without the profiling information. Additionally, this patch adds new reuse modes for JSValueRegsTemporary that take an operand and attempt to reuse the registers for that operand if they are free after the current DFG node. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasIdentifier): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileTryGetById): (JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::GPRTemporary::operator=): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileGetById): (JSC::FTL::DFG::LowerDFGToB3::getById): * jit/JITOperations.cpp: * jit/JITOperations.h: * tests/stress/try-get-by-id.js: (tryGetByIdTextStrict): (get let): (let.get createBuiltin): (get throw): (getCaller.obj.1.throw.new.Error): Deleted. 2016-04-09 Saam barati Allocation sinking SSA Defs are allowed to have replacements https://bugs.webkit.org/show_bug.cgi?id=156444 Reviewed by Filip Pizlo. Consider the following program and the annotations that explain why the SSA defs we create in allocation sinking can have replacements. function foo(a1) { let o1 = {x: 20, y: 50}; let o2 = {y: 40, o1: o1}; let o3 = {}; // We're Defing a new variable here, call it o3_field. // o3_field is defing the value that is the result of // a GetByOffset that gets eliminated through allocation sinking. o3.field = o1.y; dontCSE(); // This control flow is here to not allow the phase to consult // its local SSA mapping (which properly handles replacements) // for the value of o3_field. if (a1) { a1 = true; } else { a1 = false; } // Here, we ask for the reaching def of o3_field, and assert // it doesn't have a replacement. It does have a replacement // though. The original Def was the GetByOffset. We replaced // that GetByOffset with the value of the o1_y variable. let value = o3.field; assert(value === 50); } * dfg/DFGObjectAllocationSinkingPhase.cpp: * tests/stress/allocation-sinking-defs-may-have-replacements.js: Added. (dontCSE): (assert): (foo): 2016-04-09 Commit Queue Unreviewed, rolling out r199242. https://bugs.webkit.org/show_bug.cgi?id=156442 Caused many many leaks (Requested by ap on #webkit). Reverted changeset: "Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses" https://bugs.webkit.org/show_bug.cgi?id=156407 http://trac.webkit.org/changeset/199242 2016-04-09 Filip Pizlo Debug JSC test failure: stress/multi-put-by-offset-reallocation-butterfly-cse.js.ftl-no-cjit-small-pool https://bugs.webkit.org/show_bug.cgi?id=156406 Reviewed by Saam Barati. The failure was because the GC ran from within the butterfly allocation call in a put_by_id transition AccessCase that had to deal with indexing storage. When the GC runs in a call from a stub, then we need to be extra careful: 1) The GC may reset the IC and delete the stub. So, the stub needs to tell the GC that it might be on the stack during GC, so that the GC keeps it alive if it's currently running. 2) If the stub uses (dereferences or stores) some object after the call, then we need to ensure that the stub routine knows about that object independently of the IC. In the case of put_by_id transitions that use a helper to allocate the butterfly, we have both issues. A long time ago, we had to deal with (2), and we still had code to handle that case, although it appears to be dead. This change revives that code and glues it together with PolymorphicAccess. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::alternateBase): (JSC::AccessCase::doesCalls): (JSC::AccessCase::couldStillSucceed): (JSC::AccessCase::generate): (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: (JSC::AccessCase::customSlotBase): (JSC::AccessCase::isGetter): (JSC::AccessCase::doesCalls): Deleted. * jit/GCAwareJITStubRoutine.cpp: (JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal): (JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine): (JSC::MarkingGCAwareJITStubRoutine::~MarkingGCAwareJITStubRoutine): (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal): (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler): (JSC::createJITStubRoutine): (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject): Deleted. (JSC::MarkingGCAwareJITStubRoutineWithOneObject::~MarkingGCAwareJITStubRoutineWithOneObject): Deleted. (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal): Deleted. * jit/GCAwareJITStubRoutine.h: (JSC::createJITStubRoutine): 2016-04-08 Joseph Pecoraro Web Inspector: XHRs and Web Worker scripts are not searchable https://bugs.webkit.org/show_bug.cgi?id=154214 Reviewed by Timothy Hatcher. * inspector/protocol/Page.json: Add optional requestId to search results properties and search parameters for when the frameId and url are not enough. XHR resources, and "Other" resources will use this. 2016-04-08 Guillaume Emont MIPS: support Signed cond in branchTest32() https://bugs.webkit.org/show_bug.cgi?id=156260 This is needed since r197688 makes use of it. Reviewed by Mark Lam. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchTest32): 2016-04-08 Alex Christensen Progress towards running CMake WebKit2 on Mac https://bugs.webkit.org/show_bug.cgi?id=156426 Reviewed by Tim Horton. * PlatformMac.cmake: 2016-04-08 Saam barati Debugger may dereference m_currentCallFrame even after the VM has gone idle https://bugs.webkit.org/show_bug.cgi?id=156413 Reviewed by Mark Lam. There is a bug where the debugger may dereference its m_currentCallFrame pointer after that pointer becomes invalid to read from. This happens like so: We may step over an instruction which causes the end of execution for the current program. This causes the VM to exit. Then, we perform a GC which causes us to collect the global object. The global object being collected causes us to detach the debugger. In detaching, we think we still have a valid m_currentCallFrame, we dereference it, and crash. The solution is to make sure we're paused when dereferencing this pointer inside ::detach(). * debugger/Debugger.cpp: (JSC::Debugger::detach): 2016-04-08 Brian Burg Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses https://bugs.webkit.org/show_bug.cgi?id=156407 Reviewed by Timothy Hatcher. There's no point having these subclasses as they don't save any space. Add m_stringValue to the union and merge some implementations of writeJSON. Move uses of the subclass to InspectorValue and delete redundant methods. Now, most InspectorValue methods are non-virtual so they can be templated. * bindings/ScriptValue.cpp: (Deprecated::jsToInspectorValue): * inspector/InjectedScriptBase.cpp: (Inspector::InjectedScriptBase::makeCall): Don't used deleted subclasses. * inspector/InspectorValues.cpp: (Inspector::InspectorValue::null): (Inspector::InspectorValue::create): (Inspector::InspectorValue::asValue): (Inspector::InspectorValue::asBoolean): (Inspector::InspectorValue::asDouble): (Inspector::InspectorValue::asInteger): (Inspector::InspectorValue::asString): These only need one implementation now. (Inspector::InspectorValue::writeJSON): Still a virtual method since Object and Array need their members. (Inspector::InspectorObjectBase::InspectorObjectBase): (Inspector::InspectorBasicValue::asBoolean): Deleted. (Inspector::InspectorBasicValue::asDouble): Deleted. (Inspector::InspectorBasicValue::asInteger): Deleted. (Inspector::InspectorBasicValue::writeJSON): Deleted. (Inspector::InspectorString::asString): Deleted. (Inspector::InspectorString::writeJSON): Deleted. (Inspector::InspectorString::create): Deleted. (Inspector::InspectorBasicValue::create): Deleted. * inspector/InspectorValues.h: (Inspector::InspectorObjectBase::setBoolean): (Inspector::InspectorObjectBase::setInteger): (Inspector::InspectorObjectBase::setDouble): (Inspector::InspectorObjectBase::setString): (Inspector::InspectorArrayBase::pushBoolean): (Inspector::InspectorArrayBase::pushInteger): (Inspector::InspectorArrayBase::pushDouble): (Inspector::InspectorArrayBase::pushString): Use new factory methods. * replay/EncodedValue.cpp: (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): (JSC::ScalarEncodingTraits::encodeValue): * replay/EncodedValue.h: Use new factory methods. 2016-04-08 Filip Pizlo Add IC support for arguments.length https://bugs.webkit.org/show_bug.cgi?id=156389 Reviewed by Geoffrey Garen. This adds support for caching accesses to arguments.length for both DirectArguments and ScopedArguments. In strict mode, we already cached these accesses since they were just normal properties. Amazingly, we also already supported caching of overridden arguments.length in both DirectArguments and ScopedArguments. This is because when you override, the property gets materialized as a normal JS property and the structure is changed. This patch painstakingly preserves our previous caching of overridden length while introducing caching of non-overridden length (i.e. the common case). In fact, we even cache the case where it could either be overridden or not, since we just end up with an AccessCase for each and they cascade to each other. This is a >3x speed-up on microbenchmarks that do arguments.length in a polymorphic context. Entirely monomorphic accesses were already handled by the DFG. * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling): (JSC::AccessCase::guardedByStructureCheck): (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generate): (WTF::printInternal): * bytecode/PolymorphicAccess.h: * jit/ICStats.h: * jit/JITOperations.cpp: * jit/Repatch.cpp: (JSC::tryCacheGetByID): (JSC::tryCachePutByID): (JSC::tryRepatchIn): * tests/stress/direct-arguments-override-length-then-access-normal-length.js: Added. (args): (foo): (result.foo): 2016-04-08 Benjamin Poulain UInt32ToNumber should have an Int52 path https://bugs.webkit.org/show_bug.cgi?id=125704 Reviewed by Filip Pizlo. When dealing with big numbers, fall back to Int52 instead of double when possible. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileUInt32ToNumber): 2016-04-08 Brian Burg Web Inspector: protocol generator should emit an error when 'type' is used instead of '$ref' https://bugs.webkit.org/show_bug.cgi?id=156275 Reviewed by Darin Adler. * inspector/protocol/Heap.json: Fix a mistake that's now caught by the protocol generator. * inspector/scripts/codegen/models.py: (TypeReference.__init__): Check here if type_kind is on a whitelist of primitive types. (TypeReference.referenced_name): Update comment. Add a new test specifically for the case when the type would otherwise be resolved. Rebaseline. * inspector/scripts/tests/expected/fail-on-type-reference-as-primitive-type.json-error: Added. * inspector/scripts/tests/expected/fail-on-unknown-type-reference-in-type-declaration.json-error: * inspector/scripts/tests/fail-on-type-reference-as-primitive-type.json: Added. 2016-04-07 Joseph Pecoraro Remove ENABLE(ENABLE_ES6_CLASS_SYNTAX) guards https://bugs.webkit.org/show_bug.cgi?id=156384 Reviewed by Ryosuke Niwa. * Configurations/FeatureDefines.xcconfig: * features.json: Mark as Done. * parser/Parser.cpp: (JSC::Parser::parseExportDeclaration): (JSC::Parser::parseStatementListItem): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::parseMemberExpression): 2016-04-07 Filip Pizlo Implementing caching transition puts that need to reallocate with indexing storage https://bugs.webkit.org/show_bug.cgi?id=130914 Reviewed by Saam Barati. This enables the IC's put_by_id path to handle reallocating the out-of-line storage even if the butterfly has indexing storage. Like the DFG, we do this by calling operations that reallocate the butterfly. Those use JSObject API and do all of the nasty work for us, like triggering a barrier. This does a bunch of refactoring to how PolymorphicAccess makes calls. It's a lot easier to do it now because the hard work is hidden under AccessGenerationState methods. This means that custom accessors now share logic with put_by_id transitions. * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationState::succeed): (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling): (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall): (JSC::AccessGenerationState::originalCallSiteIndex): (JSC::AccessGenerationState::emitExplicitExceptionHandler): (JSC::AccessCase::AccessCase): (JSC::AccessCase::transition): (JSC::AccessCase::generate): (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: (JSC::AccessGenerationState::needsToRestoreRegistersIfException): (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * jit/JITOperations.cpp: * jit/JITOperations.h: 2016-04-07 Joseph Pecoraro Remote Inspector: When disallowing remote inspection on a debuggable, a listing is still sent to debuggers https://bugs.webkit.org/show_bug.cgi?id=156380 Reviewed by Timothy Hatcher. * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::updateTarget): (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): When a target has been updated and it no longer generates a listing, we should remove the old listing as that is now stale and should not be sent. Not generating a listing means this target is no longer allowed to be debugged. 2016-04-07 Joseph Pecoraro Web Inspector: Not necessary to validate webinspectord connection on iOS https://bugs.webkit.org/show_bug.cgi?id=156377 Reviewed by Simon Fraser. * inspector/remote/RemoteInspectorXPCConnection.h: * inspector/remote/RemoteInspectorXPCConnection.mm: (Inspector::RemoteInspectorXPCConnection::handleEvent): 2016-04-07 Keith Miller Rename ArrayMode::supportsLength to supportsSelfLength https://bugs.webkit.org/show_bug.cgi?id=156374 Reviewed by Filip Pizlo. The name supportsLength is confusing because TypedArray have a length function however it is on the prototype and not on the instance. supportsSelfLength makes more sense since we use the function during fixup to tell if we can intrinsic the length property lookup on self accesses. * dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::supportsSelfLength): (JSC::DFG::ArrayMode::supportsLength): Deleted. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength): 2016-04-07 Joseph Pecoraro Web Inspector: ProfileView source links are off by 1 line, worse in pretty printed code https://bugs.webkit.org/show_bug.cgi?id=156371 Reviewed by Timothy Hatcher. * inspector/protocol/ScriptProfiler.json: Clarify that these locations are 1-based. 2016-04-07 Jon Davis Add Web Animations API to Feature Status Page https://bugs.webkit.org/show_bug.cgi?id=156360 Reviewed by Timothy Hatcher. * features.json: 2016-04-07 Saam barati Invalid assertion inside DebuggerScope::getOwnPropertySlot https://bugs.webkit.org/show_bug.cgi?id=156357 Reviewed by Keith Miller. The Type Profiler might profile JS code that uses DebuggerScope and accesses properties on it. Therefore, it may have a DebuggerScope object in its log. Objects in the log are subject to having their getOwnPropertySlot method called. Therefore, the DebuggerScope might not always be in a valid state when its getOwnPropertySlot method is called. Therefore, the assertion invalid. * debugger/DebuggerScope.cpp: (JSC::DebuggerScope::getOwnPropertySlot): 2016-04-07 Saam barati Initial implementation of annex b.3.3 behavior was incorrect https://bugs.webkit.org/show_bug.cgi?id=156276 Reviewed by Keith Miller. I almost got annex B.3.3 correct in my first implementation. There is a subtlety here I got wrong. We always create a local binding for a function at the very beginning of execution of a block scope. So we hoist function declarations to their local binding within a given block scope. When we actually evaluate the function declaration statement itself, we must lookup the binding in the current scope, and bind the value to the binding in the "var" scope. We perform the following abstract operations when executing a function declaration statement. f = lookupBindingInCurrentScope("func") store(varScope, "func", f) I got this wrong by performing the store to the var binding at the beginning of the block scope instead of when we evaluate the function declaration statement. This behavior is observable. For example, a program could change the value of "func" before the actual function declaration statement executes. Consider the following two functions: ``` function foo1() { // func === undefined { // typeof func === "function" function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding. func = 20 // This sets the local "func" binding to 20. } // typeof func === "function" } function foo2() { // func === undefined { // typeof func === "function" func = 20 // This sets the local "func" binding to 20. function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding. } // func === 20 } ``` * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::initializeBlockScopedFunctions): (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitNodeForLeftHandSide): * bytecompiler/NodesCodegen.cpp: (JSC::FuncDeclNode::emitBytecode): * tests/stress/sloppy-mode-function-hoisting.js: (test.foo): (test): (test.): (test.bar): (test.switch.case.0): (test.capFoo1): (test.switch.capFoo2): (test.outer): (foo): 2016-04-07 Alex Christensen Build fix after r199170 * CMakeLists.txt: 2016-04-07 Keith Miller We should support the ability to do a non-effectful getById https://bugs.webkit.org/show_bug.cgi?id=156116 Reviewed by Benjamin Poulain. Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is useful because it enables us to take different code paths based on values that we would otherwise not be able to have knowledge of. This patch adds this new feature called try_get_by_id that will attempt to do as much of a get_by_id as possible without performing an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and undefined if the slot is unset. If the slot is proxied or any other cases then the result is null. In theory, if we ever wanted to check for null we could add a sentinal object to the global object that indicates we could not get the result. In order to implement this feature we add a new enum GetByIdKind that indicates what to do for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the get_by_id the same way we would for load and return the value at the appropriate offset. Additionally, in order to make sure the we can properly compare the GetterSetter object with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are likely to have little to no impact on memory usage as normal accessors are generally rare. * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/BuiltinExecutableCreator.cpp: Added. (JSC::createBuiltinExecutable): * builtins/BuiltinExecutableCreator.h: Copied from Source/JavaScriptCore/builtins/BuiltinExecutables.h. * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createDefaultConstructor): (JSC::BuiltinExecutables::createBuiltinExecutable): (JSC::createBuiltinExecutable): (JSC::BuiltinExecutables::createExecutable): (JSC::createExecutableInternal): Deleted. * builtins/BuiltinExecutables.h: * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::tryGet): (JSC::AccessCase::generate): (WTF::printInternal): * bytecode/PolymorphicAccess.h: (JSC::AccessCase::isGet): Deleted. (JSC::AccessCase::isPut): Deleted. (JSC::AccessCase::isIn): Deleted. * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::reset): * bytecode/StructureStubInfo.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitTryGetById): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::getById): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITInlineCacheGenerator.cpp: (JSC::JITGetByIdGenerator::JITGetByIdGenerator): * jit/JITInlineCacheGenerator.h: * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id): * jit/Repatch.cpp: (JSC::repatchByIdSelfAccess): (JSC::appropriateOptimizingGetByIdFunction): (JSC::appropriateGenericGetByIdFunction): (JSC::tryCacheGetByID): (JSC::repatchGetByID): (JSC::resetGetByID): * jit/Repatch.h: * jsc.cpp: (GlobalObject::finishCreation): (functionGetGetterSetter): (functionCreateBuiltin): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * runtime/GetterSetter.cpp: * runtime/GetterSetter.h: * runtime/JSType.h: * runtime/PropertySlot.cpp: (JSC::PropertySlot::getPureResult): * runtime/PropertySlot.h: * runtime/ProxyObject.cpp: (JSC::ProxyObject::getOwnPropertySlotCommon): * tests/stress/try-get-by-id.js: Added. (tryGetByIdText): (getCaller.obj.1.throw.new.Error.let.func): (getCaller.obj.1.throw.new.Error): (throw.new.Error.get let): (throw.new.Error.): (throw.new.Error.let.get createBuiltin): (get let): (let.get createBuiltin): (let.func): (get let.func): (get throw): 2016-04-07 Filip Pizlo Rationalize the makeSpaceForCCall stuff https://bugs.webkit.org/show_bug.cgi?id=156352 Reviewed by Mark Lam. I want to add more code to PolymorphicAccess that makes C calls, so that I can finally fix https://bugs.webkit.org/show_bug.cgi?id=130914 (allow transition caches to handle indexing headers). When trying to understand what it takes to make a C call, I came across code that was making room on the stack for spilled arguments. This logic was guarded with some complicated condition. At first, I tried to just refactor the code so that the same ugly condition wouldn't have to be copy-pasted everywhere that we made C calls. But then I started thinking about the condition, and realized that it was probably wrong: if the outer PolymorphicAccess harness decides to reuse a register for the scratchGPR then the top of the stack will store the old value of scratchGPR, but the condition wouldn't necessarily trigger. So if the call then overwrote something on the stack, we'd have a bad time. Making room on the stack for a call is a cheap operation. It's orders of magnitude cheaper than the rest of the call. Therefore, I think that it's best to just unconditionally make room on the stack. This patch makes us do just that. I also made the relevant helpers not inline, because I think that we have too many inline methods in our assemblers. Now it's much easier to make C calls from PolymorphicAccess because you just call the AssemblyHelper methods for making space. There are no special conditions or anything like that. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generate): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitLoadStructure): (JSC::AssemblyHelpers::makeSpaceOnStackForCCall): (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall): (JSC::emitRandomThunkImpl): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::makeSpaceOnStackForCCall): Deleted. (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall): Deleted. 2016-04-07 Commit Queue Unreviewed, rolling out r199128 and r199141. https://bugs.webkit.org/show_bug.cgi?id=156348 Causes crashes on multiple webpages (Requested by keith_mi_ on #webkit). Reverted changesets: "[ES6] Add support for Symbol.isConcatSpreadable." https://bugs.webkit.org/show_bug.cgi?id=155351 http://trac.webkit.org/changeset/199128 "Unreviewed, uncomment accidentally commented line in test." http://trac.webkit.org/changeset/199141 2016-04-07 Filip Pizlo Rationalize the handling of PutById transitions a bit https://bugs.webkit.org/show_bug.cgi?id=156330 Reviewed by Mark Lam. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generate): Get rid of the specialized slow calls. We can just use the failAndIgnore jump target. We just need to make sure that we don't make observable effects until we're done with all of the fast path checks. * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): MadeNoChanges indicates that we should keep trying to repatch. Currently PutById transitions might trigger the case that addAccessCase() sees null, if the transition involves an indexing header. Doing repatching in that case is probably not good. But, we should just fix this the right way eventually. 2016-04-07 Per Arne Vollan [Win] Fix for JSC stress test failures. https://bugs.webkit.org/show_bug.cgi?id=156343 Reviewed by Filip Pizlo. We need to make it clear to MSVC that the method loadPtr(ImplicitAddress address, RegisterID dest) should be used, and not loadPtr(const void* address, RegisterID dest). * jit/CCallHelpers.cpp: (JSC::CCallHelpers::setupShadowChickenPacket): 2016-04-06 Benjamin Poulain [JSC] UInt32ToNumber should be NodeMustGenerate https://bugs.webkit.org/show_bug.cgi?id=156329 Reviewed by Filip Pizlo. It exits on negative numbers on the integer path. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: 2016-04-04 Geoffrey Garen Unreviewed, rolling out r199016. https://bugs.webkit.org/show_bug.cgi?id=156140 "Perf bots are down, so I can't re-land this right now." Reverted changeset: CopiedBlock should be 16kB https://bugs.webkit.org/show_bug.cgi?id=156168 http://trac.webkit.org/changeset/199016 2016-04-06 Mark Lam String.prototype.match() should be calling internal function RegExpCreate. https://bugs.webkit.org/show_bug.cgi?id=156318 Reviewed by Filip Pizlo. RegExpCreate is not the same as the RegExp constructor. The current implementation invokes new @RegExp which calls the constructor. This results in failures in es6/Proxy_internal_get_calls_String.prototype.match.js, and es6/Proxy_internal_get_calls_String.prototype.search.js due to observable side effects. This patch fixes this by factoring out the part of the RegExp constructor that makes the RegExpCreate function, and changing String's match and search to call RegExpCreate instead in accordance with the ES6 spec. * builtins/StringPrototype.js: (match): (search): * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/RegExpConstructor.cpp: (JSC::toFlags): (JSC::regExpCreate): (JSC::constructRegExp): (JSC::esSpecRegExpCreate): (JSC::constructWithRegExpConstructor): * runtime/RegExpConstructor.h: (JSC::isRegExp): 2016-04-06 Keith Miller Unreviewed, uncomment accidentally commented line in test. * tests/stress/array-concat-spread-object.js: 2016-04-06 Filip Pizlo JSC should have a simple way of gathering IC statistics https://bugs.webkit.org/show_bug.cgi?id=156317 Reviewed by Benjamin Poulain. This adds a cheap, runtime-enabled way of gathering statistics about why we take the slow paths for inline caches. This is complementary to our existing bytecode profiler. Eventually we may want to combine the two things. This is not a slow-down on anything because we only do extra work on IC slow paths and if it's disabled it's just a load-and-branch to skip the stats gathering code. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * jit/ICStats.cpp: Added. * jit/ICStats.h: Added. * jit/JITOperations.cpp: * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::inherits): (JSC::JSValue::classInfoOrNull): (JSC::JSValue::toThis): * runtime/Options.h: 2016-04-06 Filip Pizlo 32-bit JSC stress/multi-put-by-offset-multiple-transitions.js failing https://bugs.webkit.org/show_bug.cgi?id=156292 Reviewed by Benjamin Poulain. Make sure that we stash the callsite index before calling operationReallocateStorageAndFinishPut. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generate): 2016-04-06 Filip Pizlo JSC test stress/arrowfunction-lexical-bind-superproperty.js failing https://bugs.webkit.org/show_bug.cgi?id=156309 Reviewed by Saam Barati. Just be honest about the fact that the ArgumentCount and Callee parts of inline callframe runtime meta-data can be read at any time. We only have to say this for the inline callframe forms of ArgumentCount and Callee because we don't sink any part of the machine prologue. This change just prevents us from sinking the pseudoprologue of inlined varargs or closure calls. Shockingly, this is not a regression on anything. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2016-03-29 Keith Miller [ES6] Add support for Symbol.isConcatSpreadable. https://bugs.webkit.org/show_bug.cgi?id=155351 Reviewed by Saam Barati. This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to a builtin performant. First, four new DFG intrinsics were added. 1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of the Array.isArray function. 2) IsJSArray: checks the first child is a JSArray object. 3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor. 4) CallObjectConstructor: an intrinsic of the Object constructor. IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if we are able to prove that the first child is an Array or for ToObject an Object. In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this into a contiguous array). This patch also adds a new fast path for concat with more than one array argument by using memcpy to append values onto the result array. This works roughly the same as the two array fast path using the same methodology to decide if we can memcpy the other butterfly into the result butterfly. Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our dataLog function on it. Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a JSValueOperand if the operand's use count is one. * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/ArrayPrototype.js: (concatSlowPath): (concat): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::compileIsJSArray): (JSC::DFG::SpeculativeJIT::compileIsArrayObject): (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor): (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject): (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor): (JSC::FTL::DFG::LowerDFGToB3::isArray): * jit/JITOperations.h: * jsc.cpp: (WTF::RuntimeArray::createStructure): (GlobalObject::finishCreation): (functionDebug): (functionDataLogValue): * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::finishCreation): (JSC::arrayConstructorPrivateFuncIsArrayConstructor): * runtime/ArrayConstructor.h: (JSC::isArrayConstructor): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): (JSC::arrayProtoPrivateFuncIsJSArray): (JSC::moveElements): (JSC::arrayProtoPrivateFuncConcatMemcpy): (JSC::arrayProtoPrivateFuncAppendMemcpy): (JSC::arrayProtoFuncConcat): Deleted. * runtime/ArrayPrototype.h: (JSC::ArrayPrototype::createStructure): * runtime/CommonIdentifiers.h: * runtime/Intrinsic.h: * runtime/JSArray.cpp: (JSC::JSArray::appendMemcpy): (JSC::JSArray::fastConcatWith): Deleted. * runtime/JSArray.h: (JSC::JSArray::createStructure): (JSC::JSArray::fastConcatType): Deleted. * runtime/JSArrayInlines.h: Added. (JSC::JSArray::memCopyWithIndexingType): (JSC::JSArray::canFastCopy): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSType.h: * runtime/ObjectConstructor.h: (JSC::constructObject): * tests/es6.yaml: * tests/stress/array-concat-spread-object.js: Added. (arrayEq): * tests/stress/array-concat-spread-proxy-exception-check.js: Added. (arrayEq): * tests/stress/array-concat-spread-proxy.js: Added. (arrayEq): * tests/stress/array-concat-with-slow-indexingtypes.js: Added. (arrayEq): * tests/stress/array-species-config-array-constructor.js: 2016-04-06 Commit Queue Unreviewed, rolling out r199070. https://bugs.webkit.org/show_bug.cgi?id=156324 "It didn't fix the timeout" (Requested by saamyjoon on #webkit). Reverted changeset: "jsc-layout-tests.yaml/js/script-tests/regress-141098.js failing on Yosemite Debug after r198989" https://bugs.webkit.org/show_bug.cgi?id=156187 http://trac.webkit.org/changeset/199070 2016-04-06 Geoffrey Garen Unreviewed, rolling in r199016. https://bugs.webkit.org/show_bug.cgi?id=156140 It might work this time without regression because 16kB aligned requests now take the allocation fast path. Restored changeset: CopiedBlock should be 16kB https://bugs.webkit.org/show_bug.cgi?id=156168 http://trac.webkit.org/changeset/199016 2016-04-06 Mark Lam Update es6.yaml to expect es6/Proxy_internal_get_calls_RegExp_constructor.js to pass. https://bugs.webkit.org/show_bug.cgi?id=156314 Reviewed by Saam Barati. * tests/es6.yaml: 2016-04-06 Commit Queue Unreviewed, rolling out r199104. https://bugs.webkit.org/show_bug.cgi?id=156301 Still breaks internal builds (Requested by keith_miller on #webkit). Reverted changeset: "We should support the ability to do a non-effectful getById" https://bugs.webkit.org/show_bug.cgi?id=156116 http://trac.webkit.org/changeset/199104 2016-04-06 Keith Miller RegExp constructor should use Symbol.match and other properties https://bugs.webkit.org/show_bug.cgi?id=155873 Reviewed by Michael Saboff. This patch updates the behavior of the RegExp constructor. Now the constructor should get the Symbol.match property and check if it exists to decide if something should be constructed like a regexp object. * runtime/RegExpConstructor.cpp: (JSC::toFlags): (JSC::constructRegExp): (JSC::constructWithRegExpConstructor): (JSC::callRegExpConstructor): * runtime/RegExpConstructor.h: * tests/stress/regexp-constructor.js: Added. (assert): (throw.new.Error.get let): (throw.new.Error.): (throw.new.Error.get re): 2016-04-06 Keith Miller We should support the ability to do a non-effectful getById https://bugs.webkit.org/show_bug.cgi?id=156116 Reviewed by Benjamin Poulain. Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is useful because it enables us to take different code paths based on values that we would otherwise not be able to have knowledge of. This patch adds this new feature called try_get_by_id that will attempt to do as much of a get_by_id as possible without performing an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and undefined if the slot is unset. If the slot is proxied or any other cases then the result is null. In theory, if we ever wanted to check for null we could add a sentinal object to the global object that indicates we could not get the result. In order to implement this feature we add a new enum GetByIdKind that indicates what to do for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the get_by_id the same way we would for load and return the value at the appropriate offset. Additionally, in order to make sure the we can properly compare the GetterSetter object with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are likely to have little to no impact on memory usage as normal accessors are generally rare. * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createDefaultConstructor): (JSC::BuiltinExecutables::createBuiltinExecutable): (JSC::createBuiltinExecutable): (JSC::BuiltinExecutables::createExecutable): (JSC::createExecutableInternal): Deleted. * builtins/BuiltinExecutables.h: * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::tryGet): (JSC::AccessCase::generate): (WTF::printInternal): * bytecode/PolymorphicAccess.h: (JSC::AccessCase::isGet): Deleted. (JSC::AccessCase::isPut): Deleted. (JSC::AccessCase::isIn): Deleted. * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::reset): * bytecode/StructureStubInfo.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitTryGetById): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::getById): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITInlineCacheGenerator.cpp: (JSC::JITGetByIdGenerator::JITGetByIdGenerator): * jit/JITInlineCacheGenerator.h: * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id): * jit/Repatch.cpp: (JSC::repatchByIdSelfAccess): (JSC::appropriateOptimizingGetByIdFunction): (JSC::appropriateGenericGetByIdFunction): (JSC::tryCacheGetByID): (JSC::repatchGetByID): (JSC::resetGetByID): * jit/Repatch.h: * jsc.cpp: (GlobalObject::finishCreation): (functionGetGetterSetter): (functionCreateBuiltin): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * runtime/GetterSetter.cpp: * runtime/GetterSetter.h: * runtime/JSType.h: * runtime/PropertySlot.cpp: (JSC::PropertySlot::getPureResult): * runtime/PropertySlot.h: * runtime/ProxyObject.cpp: (JSC::ProxyObject::getOwnPropertySlotCommon): * tests/stress/try-get-by-id.js: Added. (tryGetByIdText): (getCaller.obj.1.throw.new.Error.let.func): (getCaller.obj.1.throw.new.Error): (throw.new.Error.get let): (throw.new.Error.): (throw.new.Error.let.get createBuiltin): (get let): (let.get createBuiltin): (let.func): (get let.func): (get throw): 2016-04-05 Chris Dumez Add support for [EnabledAtRuntime] operations on DOMWindow https://bugs.webkit.org/show_bug.cgi?id=156272 Reviewed by Alex Christensen. Add identifier for 'fetch' so it can be used from the generated bindings. * runtime/CommonIdentifiers.h: 2016-04-05 Alex Christensen Make CMake-generated binaries on Mac able to run https://bugs.webkit.org/show_bug.cgi?id=156268 Reviewed by Daniel Bates. * CMakeLists.txt: 2016-04-05 Filip Pizlo Improve some other cases of context-sensitive inlining https://bugs.webkit.org/show_bug.cgi?id=156277 Reviewed by Benjamin Poulain. This implements some improvements for inlining: - We no longer do guarded inlining when the profiling doesn't come from a stub. Doing so would have been risky, and according to benchmarks, it wasn't common enough to matter. I think it's better to err on the side of not inlining. - The jneq_ptr pattern for variadic calls no longer breaks the basic block. Not breaking the block increases the chances of the parser seeing the callee constant. While inlining doesn't require a callee constant, sometimes it makes a difference. Note that we were previously breaking the block for no reason at all: if the boundary after jneq_ptr is a jump target from some other jump, then the parser will automatically break the block for us. There is no reason to add any block breaking ourselves since we implement jneq_ptr by ignoring the affirmative jump destination and inserting a check and falling through. - get_by_id handling now tries to apply some common sense to its status object. In particular, if the source is a NewObject and there was no interfering operation that could clobber the structure, then we know which case of a polymorphic GetByIdStatus we would take. This arises in some constructor patterns. Long term, we should address all of these cases comprehensively by having a late inliner. The inliner being part of the bytecode parser means that there is a lot of complexity in the parser and it prevents us from inlining upon learning new information from static analysis. But for now, I think it's fine to experiment with one-off hacks, if only to learn what the possibilities are. This is a 14% speed-up on Octane/raytrace. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::dump): * bytecode/CallLinkStatus.h: (JSC::CallLinkStatus::couldTakeSlowPath): (JSC::CallLinkStatus::setCouldTakeSlowPath): (JSC::CallLinkStatus::variants): (JSC::CallLinkStatus::size): (JSC::CallLinkStatus::at): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::makesCalls): (JSC::GetByIdStatus::filter): (JSC::GetByIdStatus::dump): * bytecode/GetByIdStatus.h: (JSC::GetByIdStatus::wasSeenInJIT): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::refineStatically): (JSC::DFG::ByteCodeParser::handleVarargsCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::parseBlock): * runtime/Options.h: 2016-04-05 Saam barati JSC SamplingProfiler: Use a thread + sleep loop instead of WTF::WorkQueue for taking samples https://bugs.webkit.org/show_bug.cgi?id=154017 Reviewed by Geoffrey Garen. By moving to an explicitly created seperate thread + sample-then-sleep loop, we can remove a lot of the crufty code around WorkQueue. We're also getting sample rates that are much closer to what we're asking the OS for. When the sampling handler was built off of WorkQueue, we'd often get sample rates much higher than the 1ms we asked for. On Kraken, we would average about 1.7ms sample rates, even though we'd ask for a 1ms rate. Now, on Kraken, we're getting about 1.2ms rates. Because we're getting higher rates, this patch is a performance regression. It's slower because we're sampling more frequently. Before this patch, the sampling profiler had the following overhead: - 10% on Kraken - 12% on octane - 15% on AsmBench With this patch, the sampling profiler has the following overhead: - 16% on Kraken - 17% on Octane - 30% on AsmBench Comparatively, this new patch has the following overhead over the old sampling profiler: - 5% on Kraken - 3.5% on Octane - 13% slower on AsmBench * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::InspectorScriptProfilerAgent::trackingComplete): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::~SamplingProfiler): (JSC::SamplingProfiler::createThreadIfNecessary): (JSC::SamplingProfiler::timerLoop): (JSC::SamplingProfiler::takeSample): (JSC::tryGetBytecodeIndex): (JSC::SamplingProfiler::shutdown): (JSC::SamplingProfiler::start): (JSC::SamplingProfiler::pause): (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread): (JSC::SamplingProfiler::noticeJSLockAcquisition): (JSC::SamplingProfiler::noticeVMEntry): (JSC::SamplingProfiler::clearData): (JSC::SamplingProfiler::stop): Deleted. (JSC::SamplingProfiler::dispatchIfNecessary): Deleted. (JSC::SamplingProfiler::dispatchFunction): Deleted. * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::setTimingInterval): (JSC::SamplingProfiler::setStopWatch): * runtime/VM.cpp: (JSC::VM::VM): 2016-04-05 Commit Queue Unreviewed, rolling out r199073. https://bugs.webkit.org/show_bug.cgi?id=156261 This change broke internal Mac builds (Requested by ryanhaddad on #webkit). Reverted changeset: "We should support the ability to do a non-effectful getById" https://bugs.webkit.org/show_bug.cgi?id=156116 http://trac.webkit.org/changeset/199073 2016-04-05 Youenn Fablet [Fetch API] Add a runtime flag to fetch API and related constructs https://bugs.webkit.org/show_bug.cgi?id=156113 Reviewed by Alex Christensen. Add a fetch API runtime flag based on preferences. Disable fetch API by default. * runtime/CommonIdentifiers.h: 2016-04-05 Filip Pizlo Unreviewed, fix cloop some more. * runtime/RegExpInlines.h: (JSC::RegExp::hasCodeFor): (JSC::RegExp::hasMatchOnlyCodeFor): 2016-04-05 Filip Pizlo Unreviewed, fix cloop. * jit/CCallHelpers.cpp: 2016-03-18 Filip Pizlo JSC should use a shadow stack version of CHICKEN so that debuggers have the option of retrieving tail-deleted frames https://bugs.webkit.org/show_bug.cgi?id=155598 Reviewed by Saam Barati. JSC is the first JSVM to have proper tail calls. This means that error.stack and the debugger will appear to "delete" strict mode stack frames, if the call that this frame made was in tail position. This is exactly what functional programmers expect - they don't want the VM to waste resources on tail-deleted frames to ensure that it's legal to loop forever using tail calls. It's also something that non-functional programmers fear. It's not clear that tail-deleted frames would actually degrade the debugging experience, but the fear is real, so it's worthwhile to do something about it. It turns out that there is at least one tail call implementation that doesn't suffer from this problem. It implements proper tail calls in the sense that you won't run out of memory by tail-looping. It also has the power to show you tail-deleted frames in a backtrace, so long as you haven't yet run out of memory. It's called CHICKEN Scheme, and it's one of my favorite hacks: http://www.more-magic.net/posts/internals-gc.html CHICKEN does many awesome things. The intuition from CHICKEN that we use here is a simple one: what if a tail call still kept the tail-deleted frame, and the GC actually deleted that frame only once we proved that there was insufficient memory to keep it around. CHICKEN does this by reshaping the C stack with longjmp/setjmp. We can't do that because we can have arbitrary native code, and that native code does not have relocatable stack frames. But we can do something almost like CHICKEN on a shadow stack. It's a common trick to have a VM maintain two stacks - the actual execution stack plus a shadow stack that has some extra information. The shadow stack can be reshaped, moved, etc, since the VM tightly controls its layout. The main stack can then continue to obey ABI rules. This patch implements a mechanism for being able to display stack traces that include tail-deleted frames. It uses a shadow stack that behaves like a CHICKEN stack: it has all frames all the time, though we will collect the tail-deleted ones if the stack gets too big. This new mechanism is called ShadowChicken, obviously: it's CHICKEN on a shadow stack. ShadowChicken is always on, but individual CodeBlocks may make their own choices about whether to opt into it. They will do that at bytecompile time based on the debugger mode on their global object. When no CodeBlock opts in, there is no overhead, since ShadowChicken ends up doing nothing in that case. Well, except when exceptions are thrown. Then it might do some work, but it's minor. When all CodeBlocks opt in, there is about 6% overhead. That's too much overhead to enable this all the time, but it's low enough to justify enabling in the Inspector. It's currently enabled on all CodeBlocks only when you use an Option. Otherwise it will auto-enable if the debugger is on. Note that ShadowChicken attempts to gracefully handle the presence of stack frames that have no logging. This is essential since we *can* have debugging enabled in one GlobalObject and disabled in another. Also, some frames don't do ShadowChicken because they just haven't been hacked to do it yet. Native frames fall into this category, as do the VM entry frames. This doesn't yet wire ShadowChicken into DebuggerCallFrame. That will take more work. It just makes a ShadowChicken stack walk function available to jsc. It's used from the shadow-chicken tests. * API/JSContextRef.cpp: (BacktraceFunctor::BacktraceFunctor): (BacktraceFunctor::operator()): (JSContextCreateBacktrace): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::RecursionCheckFunctor::RecursionCheckFunctor): (JSC::RecursionCheckFunctor::operator()): (JSC::CodeBlock::noticeIncomingCall): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitEnter): (JSC::BytecodeGenerator::emitCallInTailPosition): (JSC::BytecodeGenerator::emitCallVarargsInTailPosition): (JSC::BytecodeGenerator::emitCallVarargs): (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary): (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary): (JSC::BytecodeGenerator::emitCallDefineProperty): * bytecompiler/BytecodeGenerator.h: * debugger/DebuggerCallFrame.cpp: (JSC::LineAndColumnFunctor::operator()): (JSC::LineAndColumnFunctor::column): (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor): (JSC::FindCallerMidStackFunctor::operator()): (JSC::DebuggerCallFrame::DebuggerCallFrame): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.cpp: * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex): (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue): (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail): (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket): (JSC::FTL::DFG::LowerDFGToB3::boolify): * heap/Heap.cpp: (JSC::Heap::markRoots): (JSC::Heap::visitSamplingProfiler): (JSC::Heap::visitShadowChicken): (JSC::Heap::traceCodeBlocksAndJITStubRoutines): (JSC::Heap::collectImpl): * heap/Heap.h: * inspector/ScriptCallStackFactory.cpp: (Inspector::CreateScriptCallStackFunctor::CreateScriptCallStackFunctor): (Inspector::CreateScriptCallStackFunctor::operator()): (Inspector::createScriptCallStack): * interpreter/CallFrame.h: (JSC::ExecState::iterate): * interpreter/Interpreter.cpp: (JSC::DumpRegisterFunctor::DumpRegisterFunctor): (JSC::DumpRegisterFunctor::operator()): (JSC::GetStackTraceFunctor::GetStackTraceFunctor): (JSC::GetStackTraceFunctor::operator()): (JSC::Interpreter::getStackTrace): (JSC::GetCatchHandlerFunctor::handler): (JSC::GetCatchHandlerFunctor::operator()): (JSC::notifyDebuggerOfUnwinding): (JSC::UnwindFunctor::UnwindFunctor): (JSC::UnwindFunctor::operator()): (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer): * interpreter/ShadowChicken.cpp: Added. (JSC::ShadowChicken::Packet::dump): (JSC::ShadowChicken::Frame::dump): (JSC::ShadowChicken::ShadowChicken): (JSC::ShadowChicken::~ShadowChicken): (JSC::ShadowChicken::log): (JSC::ShadowChicken::update): (JSC::ShadowChicken::visitChildren): (JSC::ShadowChicken::reset): (JSC::ShadowChicken::dump): (JSC::ShadowChicken::functionsOnStack): * interpreter/ShadowChicken.h: Added. (JSC::ShadowChicken::Packet::Packet): (JSC::ShadowChicken::Packet::tailMarker): (JSC::ShadowChicken::Packet::throwMarker): (JSC::ShadowChicken::Packet::prologue): (JSC::ShadowChicken::Packet::tail): (JSC::ShadowChicken::Packet::throwPacket): (JSC::ShadowChicken::Packet::operator bool): (JSC::ShadowChicken::Packet::isPrologue): (JSC::ShadowChicken::Packet::isTail): (JSC::ShadowChicken::Packet::isThrow): (JSC::ShadowChicken::Frame::Frame): (JSC::ShadowChicken::Frame::operator==): (JSC::ShadowChicken::Frame::operator!=): (JSC::ShadowChicken::log): (JSC::ShadowChicken::logSize): (JSC::ShadowChicken::addressOfLogCursor): (JSC::ShadowChicken::logEnd): * interpreter/ShadowChickenInlines.h: Added. (JSC::ShadowChicken::iterate): * interpreter/StackVisitor.h: (JSC::StackVisitor::Frame::callee): (JSC::StackVisitor::Frame::codeBlock): (JSC::StackVisitor::Frame::bytecodeOffset): (JSC::StackVisitor::Frame::inlineCallFrame): (JSC::StackVisitor::Frame::isJSFrame): (JSC::StackVisitor::Frame::isInlinedFrame): (JSC::StackVisitor::visit): * jit/CCallHelpers.cpp: Added. (JSC::CCallHelpers::logShadowChickenProloguePacket): (JSC::CCallHelpers::logShadowChickenTailPacket): (JSC::CCallHelpers::setupShadowChickenPacket): * jit/CCallHelpers.h: (JSC::CCallHelpers::prepareForTailCallSlow): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITExceptions.cpp: (JSC::genericUnwind): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_resume): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/JITOperations.cpp: * jit/JITOperations.h: * jsc.cpp: (GlobalObject::finishCreation): (FunctionJSCStackFunctor::FunctionJSCStackFunctor): (FunctionJSCStackFunctor::operator()): (functionClearSamplingFlags): (functionShadowChickenFunctionsOnStack): (functionReadline): * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::llint_throw_stack_overflow_error): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * profiler/ProfileGenerator.cpp: (JSC::AddParentForConsoleStartFunctor::foundParent): (JSC::AddParentForConsoleStartFunctor::operator()): * runtime/Error.cpp: (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor): (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()): (JSC::addErrorInfoAndGetBytecodeOffset): * runtime/JSFunction.cpp: (JSC::RetrieveArgumentsFunctor::result): (JSC::RetrieveArgumentsFunctor::operator()): (JSC::retrieveArguments): (JSC::RetrieveCallerFunctionFunctor::result): (JSC::RetrieveCallerFunctionFunctor::operator()): (JSC::retrieveCallerFunction): * runtime/JSGlobalObjectFunctions.cpp: (JSC::GlobalFuncProtoGetterFunctor::result): (JSC::GlobalFuncProtoGetterFunctor::operator()): (JSC::globalFuncProtoGetter): (JSC::GlobalFuncProtoSetterFunctor::allowsAccess): (JSC::GlobalFuncProtoSetterFunctor::operator()): * runtime/NullSetterFunction.cpp: (JSC::GetCallerStrictnessFunctor::GetCallerStrictnessFunctor): (JSC::GetCallerStrictnessFunctor::operator()): (JSC::GetCallerStrictnessFunctor::callerIsStrict): (JSC::callerIsStrict): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructorGetPrototypeOfFunctor::result): (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()): (JSC::objectConstructorGetPrototypeOf): * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::VM): (JSC::SetEnabledProfilerFunctor::operator()): * runtime/VM.h: (JSC::VM::shouldBuilderPCToCodeOriginMapping): (JSC::VM::bytecodeIntrinsicRegistry): (JSC::VM::shadowChicken): * tests/stress/resources/shadow-chicken-support.js: Added. (describeFunction): (describeArray): (expectStack): (initialize): * tests/stress/shadow-chicken-disabled.js: Added. (test1.foo): (test1.bar): (test1.baz): (test1): (test2.foo): (test2.bar): (test2.baz): (test2): (test3.foo): (test3.bar): (test3.baz): (test3): * tests/stress/shadow-chicken-enabled.js: Added. (test1.foo): (test1.bar): (test1.baz): (test1): (test2.foo): (test2.bar): (test2.baz): (test2): (test3.bob): (test3.thingy): (test3.foo): (test3.bar): (test3.baz): (test3): (test4.bob): (test4.thingy): (test4.foo): (test4.bar): (test4.baz): (test4): (test5.foo): (test5): * tools/JSDollarVMPrototype.cpp: (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor): (JSC::CallerFrameJITTypeFunctor::operator()): (JSC::CallerFrameJITTypeFunctor::jitType): (JSC::functionLLintTrue): (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor): (JSC::CellAddressCheckFunctor::operator()): (JSC::JSDollarVMPrototype::isValidCell): (JSC::JSDollarVMPrototype::isValidCodeBlock): (JSC::JSDollarVMPrototype::codeBlockForFrame): (JSC::PrintFrameFunctor::PrintFrameFunctor): (JSC::PrintFrameFunctor::operator()): (JSC::printCallFrame): 2016-03-19 Filip Pizlo DFG and FTL should constant-fold RegExpExec, RegExpTest, and StringReplace https://bugs.webkit.org/show_bug.cgi?id=155270 Reviewed by Saam Barati. This enables constant-folding of RegExpExec, RegExpTest, and StringReplace. It's now possible to run Yarr on the JIT threads. Since previous work on constant-folding strings gave the DFG an API for reasoning about JSString constants in terms of JIT-thread-local WTF::Strings, it's now super easy to just pass strings to Yarr and build IR based on the results. But RegExpExec is hard: the folded version still must allocate a RegExpMatchesArray. We must use the same Structure that the code would have used or else we'll pollute the program's inline caches. Also, RegExpMatchesArray.h|cpp will allocate the array and its named properties in one go - we don't want to lose that optimization. So, this patch enables MaterializeNewObject to allocate objects or arrays with any number of indexed or named properties. Previously it could only handle objects (but not arrays) and named properties (but not indexed ones). This also adds a few minor things for setting the RegExpConstructor cached result. This is about a 2x speed-up on microbenchmarks when we fold a match success and about a 8x speed-up when we fold a match failure. It's a 10% speed-up on Octane/regexp. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGInsertionSet.cpp: (JSC::DFG::InsertionSet::insertSlow): (JSC::DFG::InsertionSet::execute): * dfg/DFGInsertionSet.h: (JSC::DFG::InsertionSet::insertCheck): * dfg/DFGLazyJSValue.cpp: (JSC::DFG::LazyJSValue::tryGetString): * dfg/DFGMayExit.cpp: (JSC::DFG::mayExit): * dfg/DFGNode.h: (JSC::DFG::StackAccessData::flushedAt): (JSC::DFG::OpInfo::OpInfo): Deleted. * dfg/DFGNodeType.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGObjectMaterializationData.cpp: (JSC::DFG::ObjectMaterializationData::dump): (JSC::DFG::PhantomPropertyValue::dump): Deleted. (JSC::DFG::ObjectMaterializationData::oneWaySimilarityScore): Deleted. (JSC::DFG::ObjectMaterializationData::similarityScore): Deleted. * dfg/DFGObjectMaterializationData.h: (JSC::DFG::PhantomPropertyValue::PhantomPropertyValue): Deleted. (JSC::DFG::PhantomPropertyValue::operator==): Deleted. * dfg/DFGOpInfo.h: Added. (JSC::DFG::OpInfo::OpInfo): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGPromotedHeapLocation.cpp: (WTF::printInternal): * dfg/DFGPromotedHeapLocation.h: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::~SpeculativeJIT): (JSC::DFG::SpeculativeJIT::emitAllocateRawObject): (JSC::DFG::SpeculativeJIT::emitGetLength): (JSC::DFG::SpeculativeJIT::compileLazyJSConstant): (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject): (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult): (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): Deleted. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStoreBarrierInsertionPhase.cpp: * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase): (JSC::DFG::StrengthReductionPhase::handleNode): (JSC::DFG::StrengthReductionPhase::handleCommutativity): (JSC::DFG::StrengthReductionPhase::executeInsertionSet): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validate): (JSC::DFG::Validate::validateCPS): * ftl/FTLAbstractHeapRepository.cpp: * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex): (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult): (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack): (JSC::FTL::DFG::LowerDFGToB3::storageForTransition): (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements): (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage): (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc): (JSC::FTL::DFG::LowerDFGToB3::unboxDouble): * ftl/FTLOperations.cpp: (JSC::FTL::operationPopulateObjectInOSR): (JSC::FTL::operationNewObjectWithButterfly): Deleted. * ftl/FTLOperations.h: * inspector/ContentSearchUtilities.cpp: * runtime/JSObject.h: (JSC::JSObject::createRawObject): (JSC::JSFinalObject::create): * runtime/RegExp.cpp: (JSC::RegExp::compile): (JSC::RegExp::match): (JSC::RegExp::matchConcurrently): (JSC::RegExp::compileMatchOnly): (JSC::RegExp::deleteCode): * runtime/RegExp.h: * runtime/RegExpCachedResult.h: (JSC::RegExpCachedResult::offsetOfLastRegExp): (JSC::RegExpCachedResult::offsetOfLastInput): (JSC::RegExpCachedResult::offsetOfResult): (JSC::RegExpCachedResult::offsetOfReified): * runtime/RegExpConstructor.h: (JSC::RegExpConstructor::offsetOfCachedResult): * runtime/RegExpInlines.h: (JSC::RegExp::hasCodeFor): (JSC::RegExp::compileIfNecessary): (JSC::RegExp::matchInline): (JSC::RegExp::hasMatchOnlyCodeFor): (JSC::RegExp::compileIfNecessaryMatchOnly): * runtime/RegExpObjectInlines.h: (JSC::RegExpObject::execInline): * runtime/StringPrototype.cpp: (JSC::substituteBackreferencesSlow): (JSC::substituteBackreferencesInline): (JSC::substituteBackreferences): (JSC::StringRange::StringRange): * runtime/StringPrototype.h: * runtime/VM.h: * tests/stress/simple-regexp-exec-folding-fail.js: Added. (foo): * tests/stress/simple-regexp-exec-folding.js: Added. (foo): * tests/stress/simple-regexp-test-folding-fail.js: Added. (foo): * tests/stress/simple-regexp-test-folding.js: Added. (foo): * yarr/RegularExpression.cpp: * yarr/Yarr.h: * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::interpret): (JSC::Yarr::ByteCompiler::ByteCompiler): (JSC::Yarr::ByteCompiler::compile): (JSC::Yarr::ByteCompiler::checkInput): (JSC::Yarr::byteCompile): (JSC::Yarr::interpret): * yarr/YarrInterpreter.h: (JSC::Yarr::BytecodePattern::BytecodePattern): 2016-04-05 Keith Miller We should support the ability to do a non-effectful getById https://bugs.webkit.org/show_bug.cgi?id=156116 Reviewed by Benjamin Poulain. Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is useful because it enables us to take different code paths based on values that we would otherwise not be able to have knowledge of. This patch adds this new feature called try_get_by_id that will attempt to do as much of a get_by_id as possible without performing an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and undefined if the slot is unset. If the slot is proxied or any other cases then the result is null. In theory, if we ever wanted to check for null we could add a sentinal object to the global object that indicates we could not get the result. In order to implement this feature we add a new enum GetByIdKind that indicates what to do for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the get_by_id the same way we would for load and return the value at the appropriate offset. Additionally, in order to make sure the we can properly compare the GetterSetter object with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are likely to have little to no impact on memory usage as normal accessors are generally rare. * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createDefaultConstructor): (JSC::BuiltinExecutables::createBuiltinExecutable): (JSC::createBuiltinExecutable): (JSC::BuiltinExecutables::createExecutable): (JSC::createExecutableInternal): Deleted. * builtins/BuiltinExecutables.h: * bytecode/BytecodeIntrinsicRegistry.h: * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::tryGet): (JSC::AccessCase::generate): (WTF::printInternal): * bytecode/PolymorphicAccess.h: (JSC::AccessCase::isGet): Deleted. (JSC::AccessCase::isPut): Deleted. (JSC::AccessCase::isIn): Deleted. * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::reset): * bytecode/StructureStubInfo.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitTryGetById): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedGetById): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::getById): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITInlineCacheGenerator.cpp: (JSC::JITGetByIdGenerator::JITGetByIdGenerator): * jit/JITInlineCacheGenerator.h: * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGetByValWithCachedId): (JSC::JIT::emit_op_try_get_by_id): (JSC::JIT::emitSlow_op_try_get_by_id): (JSC::JIT::emit_op_get_by_id): * jit/Repatch.cpp: (JSC::repatchByIdSelfAccess): (JSC::appropriateOptimizingGetByIdFunction): (JSC::appropriateGenericGetByIdFunction): (JSC::tryCacheGetByID): (JSC::repatchGetByID): (JSC::resetGetByID): * jit/Repatch.h: * jsc.cpp: (GlobalObject::finishCreation): (functionGetGetterSetter): (functionCreateBuiltin): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * runtime/GetterSetter.cpp: * runtime/GetterSetter.h: * runtime/JSType.h: * runtime/PropertySlot.cpp: (JSC::PropertySlot::getPureResult): * runtime/PropertySlot.h: * runtime/ProxyObject.cpp: (JSC::ProxyObject::getOwnPropertySlotCommon): * tests/stress/try-get-by-id.js: Added. (tryGetByIdText): (getCaller.obj.1.throw.new.Error.let.func): (getCaller.obj.1.throw.new.Error): (throw.new.Error.get let): (throw.new.Error.): (throw.new.Error.let.get createBuiltin): (get let): (let.get createBuiltin): (let.func): (get let.func): (get throw): 2016-04-05 Saam barati jsc-layout-tests.yaml/js/script-tests/regress-141098.js failing on Yosemite Debug after r198989 https://bugs.webkit.org/show_bug.cgi?id=156187 Reviewed by Filip Pizlo. This is a speculative fix. Lets see if the prevents the timeout. * parser/Parser.cpp: (JSC::Parser::parseStatementListItem): 2016-04-04 Filip Pizlo PolymorphicAccess should have a MegamorphicLoad case https://bugs.webkit.org/show_bug.cgi?id=156182 Reviewed by Geoffrey Garen and Keith Miller. This introduces a new case to PolymorphicAccess called MegamorphicLoad. This inlines the lookup in the PropertyTable. It's cheaper than switching on a huge number of cases and it's cheaper than calling into C++ to do the same job - particularly since inlining the lookup into an access means that we can precompute the hash code. When writing the inline code for the hashtable lookup, I found that our hashing algorithm was not optimal. It used a double-hashing method for reducing collision pathologies. This is great for improving the performance of some worst-case scenarios. But this misses the point of a hashtable: we want to optimize the average-case performance. When optimizing for average-case, we can choose to either focus on maximizing the likelihood of the fast case happening, or to minimize the cost of the worst-case, or to minimize the cost of the fast case. Even a very basic hashtable will achieve a high probability of hitting the fast case. So, doing work to reduce the likelihood of a worst-case pathology only makes sense if it also preserves the good performance of the fast case, or reduces the likelihood of the worst-case by so much that it's a win for the average case even with a slow-down in the fast case. I don't believe, based on looking at how the double-hashing is implemented, that it's possible that this preserves the good performance of the fast case. It requires at least one more value to be live around the loop, and dramatically increases the register pressure at key points inside the loop. The biggest offender is the doubleHash() method itself. There is no getting around how bad this is: if the compiler live-range-splits that method to death to avoid degrading register pressure elsewhere then we will pay a steep price anytime we take the second iteration around the loop; but if the compiler doesn't split around the call then the hashtable lookup fast path will be full of spills on some architectures (I performed biological register allocation and found that I needed 9 registers for complete lookup, while x86-64 has only 6 callee-saves; OTOH ARM64 has 10 callee-saves so it might be better off). Hence, this patch changes the hashtable lookup to use simple linear probing. This was not a slow-down on anything, and it made MegamorphicLoad much more sensible since it is less likely to have to spill. There are some other small changes in this patch, like rationalizing the IC's choice between giving up after a repatch (i.e. never trying again) and just pretending that nothing happened (so we can try to repatch again in the future). It looked like the code in Repatch.cpp was set up to be able to choose between those options, but we weren't fully taking advantage of it because the regenerateWithCase() method just returned null for any failure, and didn't say whether it was the sort of failure that renders the inline cache unrepatchable (like memory allocation failure). Now this is all made explicit. I wanted to make sure this change happened in this patch since the MegamorphicLoad code automagically generates a MegamorphicLoad case by coalescing other cases. Since this is intended to avoid blowing out the cache and making it unrepatchable, I wanted to make sure that the rules for giving up were something that made sense to me. This is a big win on microbenchmarks. It's neutral on traditional JS benchmarks. It's a slight speed-up for page loading, because many real websites like to have megamorphic property accesses. * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationResult::dump): (JSC::AccessGenerationState::addWatchpoint): (JSC::AccessCase::get): (JSC::AccessCase::megamorphicLoad): (JSC::AccessCase::replace): (JSC::AccessCase::guardedByStructureCheck): (JSC::AccessCase::couldStillSucceed): (JSC::AccessCase::canBeReplacedByMegamorphicLoad): (JSC::AccessCase::canReplace): (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generate): (JSC::PolymorphicAccess::PolymorphicAccess): (JSC::PolymorphicAccess::~PolymorphicAccess): (JSC::PolymorphicAccess::regenerateWithCases): (JSC::PolymorphicAccess::regenerateWithCase): (WTF::printInternal): * bytecode/PolymorphicAccess.h: (JSC::AccessCase::isGet): (JSC::AccessCase::isPut): (JSC::AccessCase::isIn): (JSC::AccessGenerationResult::AccessGenerationResult): (JSC::AccessGenerationResult::operator==): (JSC::AccessGenerationResult::operator!=): (JSC::AccessGenerationResult::operator bool): (JSC::AccessGenerationResult::kind): (JSC::AccessGenerationResult::code): (JSC::AccessGenerationResult::madeNoChanges): (JSC::AccessGenerationResult::gaveUp): (JSC::AccessGenerationResult::generatedNewCode): (JSC::PolymorphicAccess::isEmpty): (JSC::AccessGenerationState::AccessGenerationState): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::aboutToDie): (JSC::StructureStubInfo::addAccessCase): * bytecode/StructureStubInfo.h: * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo): (JSC::AssemblyHelpers::loadProperty): (JSC::emitRandomThunkImpl): (JSC::AssemblyHelpers::emitRandomThunk): (JSC::AssemblyHelpers::emitLoadStructure): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::loadValue): (JSC::AssemblyHelpers::moveValueRegs): (JSC::AssemblyHelpers::argumentsStart): (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo): (JSC::AssemblyHelpers::emitLoadStructure): Deleted. * jit/GPRInfo.cpp: (JSC::JSValueRegs::dump): * jit/GPRInfo.h: (JSC::JSValueRegs::uses): * jit/Repatch.cpp: (JSC::replaceWithJump): (JSC::tryCacheGetByID): (JSC::tryCachePutByID): (JSC::tryRepatchIn): * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): * runtime/Options.h: * runtime/PropertyMapHashTable.h: (JSC::PropertyTable::begin): (JSC::PropertyTable::find): (JSC::PropertyTable::get): * runtime/Structure.h: 2016-04-05 Antoine Quint [WebGL2] Turn the ENABLE_WEBGL2 flag on https://bugs.webkit.org/show_bug.cgi?id=156061 Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: * runtime/CommonIdentifiers.h: Define the conditionalized classes WebGL2RenderingContext and WebGLVertexArrayObject. 2016-04-04 Zan Dobersek Add missing EABI_32BIT_DUMMY_ARG arguments for some callOperation(J_JITOperation_EGReoJ, ...) overloads https://bugs.webkit.org/show_bug.cgi?id=156161 Reviewed by Yusuke Suzuki. r197641 added a couple of callOperation(J_JITOperation_EGReoJ, ...) overloads that handle arguments split into the tag and the payload. The two were split between the last argument register and the stack on 32-bit ARM EABI systems, causing incorrect behavior. Adding EABI_32BIT_DUMMY_ARG pushes the tag and payload together onto the stack, removing the issue. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): 2016-04-04 Joseph Pecoraro Avoid copying ModuleLoaderObject.js to resources bundle https://bugs.webkit.org/show_bug.cgi?id=156188 Reviewed by Alexey Proskuryakov. * JavaScriptCore.xcodeproj/project.pbxproj: 2016-04-04 Geoffrey Garen Unreviewed, rolling out r199016. https://bugs.webkit.org/show_bug.cgi?id=156140 "Regressed Octane and Kraken on the perf bots." Reverted changeset: CopiedBlock should be 16kB https://bugs.webkit.org/show_bug.cgi?id=156168 http://trac.webkit.org/changeset/199016 2016-04-04 Benjamin Poulain [JSC][x86] Fix an assertion in MacroAssembler::branch8() https://bugs.webkit.org/show_bug.cgi?id=156181 Reviewed by Geoffrey Garen. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::branch8): The test was wrong because valid negative numbers have ones in the top bits. I replaced the assertion to be explicit about the valid range. 2016-04-04 Chris Dumez Regression(r196145): Crash in getOwnPropertyDescriptor on http://www.history.com/shows/vikings https://bugs.webkit.org/show_bug.cgi?id=156136 Reviewed by Ryosuke Niwa. Add a few more identifiers for using in the generated bindings. * runtime/CommonIdentifiers.h: 2016-04-04 Geoffrey Garen CopiedBlock should be 16kB https://bugs.webkit.org/show_bug.cgi?id=156168 Reviewed by Mark Lam. MarkedBlock is 16kB, and bmalloc's largest fast-path allocation is 16kB, and the largest page size on Apple devices is 16kB -- so this change should improve sharing and recycling and keep us on the fast path more. 32kB is also super aggro. At 16kB, we support allocations up to 8kB, which covers 99.3% of allocations on facebook.com. The 32kB block size only covered an additional 0.2% of allocations. * heap/CopiedBlock.h: 2016-04-04 Carlos Garcia Campos REGRESSION(r198792): [GTK] Inspector crashes in Inspector::Protocol::getEnumConstantValue since r198792 https://bugs.webkit.org/show_bug.cgi?id=155745 Reviewed by Brian Burg. The problem is that we are generating the Inspector::Protocol::getEnumConstantValue() method and the enum_constant_values array for every framework that has enum values. So, in case of GTK port we have two implementations, one for the inspector in JavaScriptCore and another one for Web Automation in WebKit2, but when using the inspector in WebKit2 we always end up using the one in WebKit2. Since the enum_constant_values array is smaller in WebKit2 than the one in JavaScriptCore, we crash every time we receive an enum value higher than the array size. We need to disambiguate the getEnumConstantValue() generated and used for every framework, so we can use a specific namespace for the enum conversion methods. * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::breakpointActionTypeForString): Use Inspector::Protocol::InspectorHelpers. * inspector/scripts/codegen/cpp_generator.py: (CppGenerator.helpers_namespace): Return the namespace name that should be used for the helper methods. * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py: (CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain): Use CppGenerator.helpers_namespace() to use the right namespace when using getEnumConstantValue(). (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): Ditto. * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py: (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event): Ditto. * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: (CppProtocolTypesHeaderGenerator.generate_output): Move declaration of getEnumConstantValue to a helper function. (_generate_enum_constant_value_conversion_methods): Do not emit any code if there aren't enums and ensure all conversion methods are declared inside the helpers namespace. (_generate_builder_setter_for_member): Use CppGenerator.helpers_namespace() to use the right namespace when using getEnumConstantValue(). (_generate_unchecked_setter_for_member): Ditto. (_generate_declarations_for_enum_conversion_methods): Return a list instead of a string so that we can return an empty list in case of not emitting any code. The caller will use extend() that has no effect when an empty list is passed. * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: (CppProtocolTypesImplementationGenerator.generate_output): Use the new helper function to generate both the enum mapping and conversion methods inside the helpers namespace. (CppProtocolTypesImplementationGenerator._generate_enum_mapping): Return a list instead of a string so that we can return an empty list in case of not emitting any code. (CppProtocolTypesImplementationGenerator._generate_enum_mapping_and_conversion_methods): Ensure we only emit code when there are enum values, and it's generated inside the helpers namespace. * inspector/scripts/tests/expected/commands-with-async-attribute.json-result: * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result: * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result: * inspector/scripts/tests/expected/enum-values.json-result: * inspector/scripts/tests/expected/events-with-optional-parameters.json-result: * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result: * inspector/scripts/tests/expected/same-type-id-different-domain.json-result: * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result: * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result: * inspector/scripts/tests/expected/type-declaration-array-type.json-result: * inspector/scripts/tests/expected/type-declaration-enum-type.json-result: * inspector/scripts/tests/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result: 2016-04-04 Csaba Osztrogonác Unreviewed ARM buildfix after r198981. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::roundTowardZeroDouble): 2016-04-03 Saam barati Implement Annex B.3.3 function hoisting rules for function code https://bugs.webkit.org/show_bug.cgi?id=155672 Reviewed by Geoffrey Garen. The spec states that functions declared inside a function inside a block scope are subject to the rules of Annex B.3.3: https://tc39.github.io/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics The rule states that functions declared in such blocks should be local bindings of the block. If declaring the function's name as a "var" in the function would not lead to a syntax error (i.e, if we don't have a let/const/class variable with the same name) and if we don't have a parameter with the same name, then we implictly also declare the funcion name as a "var". When evaluating the block statement we bind the hoisted "var" to be the value of the local function binding. There is one more thing we do for web compatibility. We allow function declarations inside if/else statements that aren't blocks. For such statements, we transform the code as if the function were declared inside a block s