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 statement. For example: ``` function foo() { if (cond) function baz() { } }``` is transformed into: ``` function foo() { if (cond) { function baz() { } } }``` * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack): (JSC::BytecodeGenerator::initializeBlockScopedFunctions): * bytecompiler/BytecodeGenerator.h: * parser/Nodes.cpp: (JSC::ScopeNode::ScopeNode): (JSC::ProgramNode::ProgramNode): (JSC::ModuleProgramNode::ModuleProgramNode): (JSC::EvalNode::EvalNode): (JSC::FunctionNode::FunctionNode): * parser/Nodes.h: (JSC::ScopeNode::hasCapturedVariables): (JSC::ScopeNode::captures): (JSC::ScopeNode::hasSloppyModeHoistedFunction): (JSC::ScopeNode::varDeclarations): (JSC::ProgramNode::startColumn): (JSC::ProgramNode::endColumn): (JSC::EvalNode::startColumn): (JSC::EvalNode::endColumn): (JSC::ModuleProgramNode::startColumn): (JSC::ModuleProgramNode::endColumn): * parser/Parser.cpp: (JSC::Parser::Parser): (JSC::Parser::parseInner): (JSC::Parser::didFinishParsing): (JSC::Parser::parseStatement): (JSC::Parser::parseIfStatement): * parser/Parser.h: (JSC::Scope::declareVariable): (JSC::Scope::declareFunction): (JSC::Scope::addSloppyModeHoistableFunctionCandidate): (JSC::Scope::appendFunction): (JSC::Scope::declareParameter): (JSC::Scope::mergeInnerArrowFunctionFeatures): (JSC::Scope::getSloppyModeHoistedFunctions): (JSC::Scope::getCapturedVars): (JSC::ScopeRef::containingScope): (JSC::ScopeRef::operator==): (JSC::ScopeRef::operator!=): (JSC::Parser::declareFunction): (JSC::Parser::hasDeclaredVariable): (JSC::Parser::isFunctionMetadataNode): (JSC::Parser::DepthManager::DepthManager): (JSC::Parser::parse): * parser/VariableEnvironment.h: (JSC::VariableEnvironmentEntry::isImported): (JSC::VariableEnvironmentEntry::isImportedNamespace): (JSC::VariableEnvironmentEntry::isFunction): (JSC::VariableEnvironmentEntry::isParameter): (JSC::VariableEnvironmentEntry::isSloppyModeHoistingCandidate): (JSC::VariableEnvironmentEntry::setIsCaptured): (JSC::VariableEnvironmentEntry::setIsConst): (JSC::VariableEnvironmentEntry::setIsImported): (JSC::VariableEnvironmentEntry::setIsImportedNamespace): (JSC::VariableEnvironmentEntry::setIsFunction): (JSC::VariableEnvironmentEntry::setIsParameter): (JSC::VariableEnvironmentEntry::setIsSloppyModeHoistingCandidate): (JSC::VariableEnvironmentEntry::clearIsVar): * runtime/CodeCache.h: (JSC::SourceCodeValue::SourceCodeValue): * runtime/JSScope.cpp: * runtime/JSScope.h: * tests/es6.yaml: * tests/stress/sloppy-mode-function-hoisting.js: Added. (assert): (test): (falsey): (truthy): (test.): (test.a): (test.f): (test.let.funcs.f): (test.catch.f): (test.foo): (test.bar): (test.switch.case.0): (test.else.f): (test.b): (test.c): (test.d): (test.e): (test.g): (test.h): (test.i): (test.j): (test.k): (test.l): (test.m): (test.n): (test.o): (test.p): (test.q): (test.r): (test.s): (test.t): (test.u): (test.v): (test.w): (test.x): (test.y): (test.z): (foo): (bar): (falsey.bar): (baz): (falsey.baz): 2016-04-03 Yusuke Suzuki Unreviewed, turn ES6 for-in loop test success https://bugs.webkit.org/show_bug.cgi?id=155451 * tests/es6.yaml: 2016-04-03 Yusuke Suzuki [JSC] Add truncate operation (rounding to zero) https://bugs.webkit.org/show_bug.cgi?id=156072 Reviewed by Saam Barati. Add TruncIntrinsic for Math.trunc. DFG handles it as ArithTrunc. In DFG, ArithTrunc behaves similar to ArithRound, ArithCeil, and ArithFloor. ArithTrunc rounds the value towards zero. And we rewrite @toInteger to use @trunc instead of @abs, @floor, negation and branch. This is completely the same to what we do in JSValue::toInteger. Since DFG recognize it, DFG can convert ArithTrunc to Identity if the given argument is Int32. This is useful because almost all the argument is Int32 in @toLength -> @toInteger -> @trunc case. In such cases, we can eliminate trunc() call. As a bonus, to speed up Math.trunc operation, we use x86 SSE round and frintz in ARM64 for ArithRound. In DFG, we emit these instructions. In FTL, we use Patchpoint to emit these instructions to avoid adding a new B3 IR. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::roundTowardZeroDouble): (JSC::MacroAssemblerARM64::roundTowardZeroFloat): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::roundTowardZeroDouble): * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::roundTowardZeroDouble): * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::roundTowardZeroDouble): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::roundTowardZeroDouble): (JSC::MacroAssemblerX86Common::roundTowardZeroFloat): * builtins/GlobalObject.js: (toInteger): * 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/DFGGraph.h: (JSC::DFG::Graph::roundShouldSpeculateInt32): * dfg/DFGNode.h: (JSC::DFG::Node::arithNodeFlags): (JSC::DFG::Node::hasHeapPrediction): (JSC::DFG::Node::hasArithRoundingMode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithRounding): * 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::compileArithTrunc): * ftl/FTLOutput.cpp: (JSC::FTL::Output::doubleTrunc): * ftl/FTLOutput.h: * jit/ThunkGenerators.cpp: (JSC::truncThunkGenerator): * jit/ThunkGenerators.h: * runtime/CommonIdentifiers.h: * runtime/Intrinsic.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/MathObject.cpp: (JSC::MathObject::finishCreation): * runtime/MathObject.h: * runtime/VM.cpp: (JSC::thunkGeneratorForIntrinsic): * tests/stress/math-rounding-infinity.js: (testTrunc): * tests/stress/math-rounding-nan.js: (testTrunc): * tests/stress/math-rounding-negative-zero.js: (testTrunc): * tests/stress/math-trunc-arith-rounding-mode.js: Added. (firstCareAboutZeroSecondDoesNot): (firstDoNotCareAboutZeroSecondDoes): (warmup): (verifyNegativeZeroIsPreserved): * tests/stress/math-trunc-basics.js: Added. (mathTruncOnIntegers): (mathTruncOnDoubles): (mathTruncOnBooleans): (uselessMathTrunc): (mathTruncWithOverflow): (mathTruncConsumedAsDouble): (mathTruncDoesNotCareAboutMinusZero): (mathTruncNoArguments): (mathTruncTooManyArguments): (testMathTruncOnConstants): (mathTruncStructTransition): (Math.trunc): * tests/stress/math-trunc-should-be-truncate.js: Added. (mathTrunc): 2016-04-03 Skachkov Oleksandr [ES6] Class syntax. Access to new.target inside of the eval should not lead to SyntaxError https://bugs.webkit.org/show_bug.cgi?id=155545 Reviewed by Saam Barati. Current patch allow to invoke new.target in eval if this eval is executed within function, otherwise this will lead to Syntax error * bytecode/EvalCodeCache.h: (JSC::EvalCodeCache::getSlow): * bytecode/ExecutableInfo.h: (JSC::ExecutableInfo::ExecutableInfo): (JSC::ExecutableInfo::evalContextType): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::evalContextType): * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::evaluate): * interpreter/Interpreter.cpp: (JSC::eval): * parser/Parser.cpp: (JSC::Parser::Parser): (JSC::Parser::parseMemberExpression): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::setEvalContextType): (JSC::Scope::evalContextType): (JSC::parse): * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): (JSC::CodeCache::getProgramCodeBlock): (JSC::CodeCache::getEvalCodeBlock): (JSC::CodeCache::getModuleProgramCodeBlock): * runtime/CodeCache.h: * runtime/Executable.cpp: (JSC::ScriptExecutable::ScriptExecutable): (JSC::EvalExecutable::create): (JSC::EvalExecutable::EvalExecutable): (JSC::ProgramExecutable::ProgramExecutable): (JSC::ModuleProgramExecutable::ModuleProgramExecutable): (JSC::FunctionExecutable::FunctionExecutable): * runtime/Executable.h: (JSC::ScriptExecutable::evalContextType): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::createEvalCodeBlock): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncEval): * tests/stress/arrowfunction-lexical-bind-newtarget.js: * tests/stress/new-target.js: 2016-04-02 Commit Queue Unreviewed, rolling out r198976. https://bugs.webkit.org/show_bug.cgi?id=156140 "Causes js/regress/array-nonarray-polymorhpic-access.html to crash." (Requested by ddkilzer on #webkit). Reverted changeset: "[JSC] Initialize SSA's live values at tail lazily" https://bugs.webkit.org/show_bug.cgi?id=156126 http://trac.webkit.org/changeset/198976 2016-04-02 Benjamin Poulain [JSC] Initialize SSA's live values at tail lazily https://bugs.webkit.org/show_bug.cgi?id=156126 Reviewed by Mark Lam. Setting up the clean state early looks harmless but it is actually quite expensive. The problem is AbstractValue is gigantic, you really want to minimize how much you touch that memory. By removing the initialization, most blocks only get 2 or 3 accesses. Once to setup the value, and a few queries for merging the current block with the successors. * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::endBasicBlock): (JSC::DFG::setLiveValues): Deleted. (JSC::DFG::InPlaceAbstractState::initialize): Deleted. 2016-04-02 Benjamin Poulain [JSC] Add an option to avoid disassembling baseline code for the JSC Profiler https://bugs.webkit.org/show_bug.cgi?id=156127 Reviewed by Mark Lam. The profiler run out of memory on big programs if you dump the baseline disassembly. * jit/JIT.cpp: (JSC::JIT::privateCompile): * runtime/Options.h: 2016-04-02 Dan Bernstein jsc binary embedded in relocatable JavaScriptCore.framework links against system JavaScriptCore.framework https://bugs.webkit.org/show_bug.cgi?id=156134 Reviewed by Mark Lam. * Configurations/JSC.xcconfig: Define WK_RELOCATABLE_FRAMEWORKS_LDFLAGS when building relocatable frameworks to include a -dyld_env option setting DYLD_FRAMEWORK_PATH to point to the directory containing JavaScript.framework, and add WK_RELOCATABLE_FRAMEWORKS_LDFLAGS to OTHER_LDFLAGS. 2016-04-01 Benjamin Poulain [JSC][x86] Add the 3 operands form of floating point substraction https://bugs.webkit.org/show_bug.cgi?id=156095 Reviewed by Geoffrey Garen. Same old, same old. Add the AVX form of subsd and subss. Unfortunately, we cannot benefit from the 3 register form in B3 yet because the Air script does not support CPU flags yet. That can be fixed later. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::subDouble): (JSC::MacroAssemblerX86Common::subFloat): * assembler/X86Assembler.h: (JSC::X86Assembler::vsubsd_rr): (JSC::X86Assembler::subsd_mr): (JSC::X86Assembler::vsubsd_mr): (JSC::X86Assembler::vsubss_rr): (JSC::X86Assembler::subss_mr): (JSC::X86Assembler::vsubss_mr): (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM): * b3/air/AirOpcode.opcodes: 2016-04-01 Alberto Garcia [JSC] Missing PATH_MAX definition https://bugs.webkit.org/show_bug.cgi?id=156102 Reviewed by Yusuke Suzuki. Not all systems define PATH_MAX, so add a fallback value that is long enough. * jsc.cpp: 2016-03-31 Benjamin Poulain [JSC] CFA's valuesAtHead should be a list, not a map https://bugs.webkit.org/show_bug.cgi?id=156087 Reviewed by Mark Lam. One more step toward moving to the Air-style of liveness analysis: Make DFG's valuesAtHead a list of Node*-AbstractValue. This patch alone is already a speedup because our many CFAs spend an unreasonable amount of time updating at block boundaries. * dfg/DFGBasicBlock.h: * dfg/DFGCFAPhase.cpp: (JSC::DFG::CFAPhase::performBlockCFA): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::beginBasicBlock): (JSC::DFG::setLiveValues): (JSC::DFG::InPlaceAbstractState::merge): * dfg/DFGNode.h: (JSC::DFG::nodeValuePairComparator): (JSC::DFG::nodeValuePairListDump): 2016-03-31 Saam barati Revert rewrite const as var workaround https://bugs.webkit.org/show_bug.cgi?id=155393 Reviewed by Mark Lam. * parser/Parser.h: (JSC::Parser::next): (JSC::Parser::nextExpectIdentifier): * runtime/VM.h: (JSC::VM::setShouldRewriteConstAsVar): Deleted. (JSC::VM::shouldRewriteConstAsVar): Deleted. 2016-03-31 Saam barati [ES6] Disallow var assignments in for-in loops https://bugs.webkit.org/show_bug.cgi?id=155451 Reviewed by Mark Lam. We're doing this in its own patch instead of the patch for https://bugs.webkit.org/show_bug.cgi?id=155384 because last time we made this change it broke some websites. Lets try making it again because it's what the ES6 mandates. If it still breaks things we will roll it out. * parser/Parser.cpp: (JSC::Parser::parseForStatement): 2016-03-31 Saam barati parsing arrow function expressions slows down the parser by 8% lets recoup some loss https://bugs.webkit.org/show_bug.cgi?id=155988 Reviewed by Benjamin Poulain. We used to eagerly check if we're parsing an arrow function. We did this inside parseAssignmentExpression(), and it was very costly. The reason it was costly is that arrow functions might start with an identifier. This means anytime we saw an identifier we would have to do a lookahead, and then most likely backtrack because more often than not, we wouldn't see "=>" as the next token. In this patch I implement a new approach. We just parse the lhs of an assignment expression eagerly without doing any lookahead. Retroactively, if we see that we might have started with an arrow function, and we don't have a valid lhs or the next token is a "=>", we try to parse as an arrow function. Here are a few examples motivating why this is valid: `x => x` In this example: - "x" is a valid arrow function starting point. - "x" also happens to be a valid lhs - because we see "=>" as the next token, we parse as an arrow function and succeed. `(x) => x` In this example: - "(" is a valid arrow function starting point. - "(x)" also happens to be a valid lhs - because we see "=>" as the next token, we parse as an arrow function and succeed. `({x = 30}) => x;` In this example: - "(" is a valid arrow function starting point. - "({x = 30})" is NOT a valid lhs. Because of this, we try to parse it as an arrow function and succeed. There is one interesting implementation detail where we might parse something that is both a valid LHS but happens to actually be the arrow function parameters. The valid LHS parsing might declare such variables as "uses" which would cause weird capture analysis. This patch also introduces a mechanism to backtrack on used variable analysis. This is a 3.5%-4.5% octane code load speedup. * parser/Lexer.h: (JSC::Lexer::sawError): (JSC::Lexer::setSawError): (JSC::Lexer::getErrorMessage): (JSC::Lexer::setErrorMessage): (JSC::Lexer::sourceURL): (JSC::Lexer::sourceMappingURL): * parser/Parser.cpp: (JSC::Parser::isArrowFunctionParameters): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parsePrimaryExpression): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::startSwitch): (JSC::Scope::declareParameter): (JSC::Scope::usedVariablesContains): (JSC::Scope::useVariable): (JSC::Scope::pushUsedVariableSet): (JSC::Scope::currentUsedVariablesSize): (JSC::Scope::revertToPreviousUsedVariables): (JSC::Scope::setNeedsFullActivation): (JSC::Scope::needsFullActivation): (JSC::Scope::isArrowFunctionBoundary): (JSC::Scope::setInnerArrowFunctionUsesEvalAndUseArgumentsIfNeeded): (JSC::Scope::collectFreeVariables): (JSC::Scope::fillParametersForSourceProviderCache): (JSC::Scope::restoreFromSourceProviderCache): (JSC::Scope::setIsModule): 2016-03-31 Yusuke Suzuki Fails to build in Linux / PowerPC due to different ucontext_t definition https://bugs.webkit.org/show_bug.cgi?id=156015 Reviewed by Michael Catanzaro. PPC does not have mcontext_t in ucontext_t::uc_mcontext. So we take the special way to retrieve mcontext_t in PPC. * heap/MachineStackMarker.cpp: (pthreadSignalHandlerSuspendResume): 2016-03-31 Benjamin Poulain [JSC][x86] Add the indexed forms of floating point addition and multiplication https://bugs.webkit.org/show_bug.cgi?id=156058 Reviewed by Geoffrey Garen. B3 supports lowering [base, index] addresses into arbitrary instructions but we were not using that feature. This patch adds the missing support for the lowering of Add and Mul. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::addDouble): (JSC::MacroAssemblerX86Common::addFloat): (JSC::MacroAssemblerX86Common::mulDouble): (JSC::MacroAssemblerX86Common::mulFloat): * assembler/X86Assembler.h: (JSC::X86Assembler::addsd_mr): (JSC::X86Assembler::vaddsd_mr): (JSC::X86Assembler::addss_mr): (JSC::X86Assembler::vaddss_mr): (JSC::X86Assembler::mulsd_mr): (JSC::X86Assembler::vmulsd_mr): (JSC::X86Assembler::mulss_mr): (JSC::X86Assembler::vmulss_mr): (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::appendBinOp): Unlike the Addr form, we never need to transform a Tmp into an Index for spilling. Instead of duplicating all the code in MacroAssembler, I can just have the lowering phase try using addresses for the first argument when possible. * b3/air/AirOpcode.opcodes: * b3/air/testair.cpp: (JSC::B3::Air::testX86VMULSDBaseNeedsRex): (JSC::B3::Air::testX86VMULSDIndexNeedsRex): (JSC::B3::Air::testX86VMULSDBaseIndexNeedRex): (JSC::B3::Air::run): 2016-03-31 Saam barati DFG JIT bug in typeof constant folding where the input to typeof is an object or function https://bugs.webkit.org/show_bug.cgi?id=156034 Reviewed by Ryosuke Niwa. AI would constant fold TypeOf to the string "object" if it saw that its input type didn't expand past the types contained in the set "SpecObject - SpecObjectOther". But, SpecObject contains SpecFunction. And typeof of a function should return "function". This patch fixes this bug by making sure we constant fold to object iff the type doesn't expand past the set "SpecObject - SpecObjectOther - SpecFunction". * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * tests/stress/typeof-dfg-function-or-object.js: Added. (assert): (foo.else.o): (foo): 2016-03-31 Mark Lam Gardening: Build and logic fix after r198873. https://bugs.webkit.org/show_bug.cgi?id=156043 Not reviewed. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::addFloat): - 2 args were meant to be ordered differently in order to call the other addFloat. Instead, there was an infinite recursion bug. This is now fixed. 2016-03-30 Benjamin Poulain [JSC][x86] Add the 3 operands forms of floating point addition and multiplication https://bugs.webkit.org/show_bug.cgi?id=156043 Reviewed by Geoffrey Garen. When they are available, VADD and VMUL are better options to lower floating point addition and multiplication. In the simple cases when one of the operands is aliased to the destination, those forms have the same size or 1 byte shorter depending on the registers. In the more advanced cases, we gain nice advantages with the new forms: -We can get rid of the MoveDouble in front the instruction when we cannot alias. -We can disable aliasing entirely in Air. That is useful for latency since computing coalescing is not exactly cheap. * assembler/MacroAssemblerX86Common.cpp: * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::and32): (JSC::MacroAssemblerX86Common::mul32): (JSC::MacroAssemblerX86Common::or32): (JSC::MacroAssemblerX86Common::xor32): (JSC::MacroAssemblerX86Common::branchAdd32): The change in B3LowerToAir exposed a bug in the fake 3 operands forms of those instructions. If the address is equal to the destination, we were nuking the address. For example, Add32([%r11], %eax, %r11) would generate: move %eax, %r11 add32 [%r11], %r11 which crashes. I updated codegen of those cases to support that case through load32 [%r11], %r11 add32 %eax, %r11 The weird case were all arguments have the same registers is handled too. (JSC::MacroAssemblerX86Common::addDouble): (JSC::MacroAssemblerX86Common::addFloat): (JSC::MacroAssemblerX86Common::mulDouble): (JSC::MacroAssemblerX86Common::mulFloat): (JSC::MacroAssemblerX86Common::supportsFloatingPointRounding): (JSC::MacroAssemblerX86Common::supportsAVX): (JSC::MacroAssemblerX86Common::updateEax1EcxFlags): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::branchAdd64): * assembler/X86Assembler.h: (JSC::X86Assembler::vaddsd_rr): (JSC::X86Assembler::vaddsd_mr): (JSC::X86Assembler::vaddss_rr): (JSC::X86Assembler::vaddss_mr): (JSC::X86Assembler::vmulsd_rr): (JSC::X86Assembler::vmulsd_mr): (JSC::X86Assembler::vmulss_rr): (JSC::X86Assembler::vmulss_mr): (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::appendBinOp): Add the 3 operand forms so that we lower Add and Mul to the best form directly. I will change how we lower the fake 3 operands instructions but the codegen should end up the same in most cases. The new codegen is the load32 + op above. * b3/air/AirInstInlines.h: (JSC::B3::Air::Inst::shouldTryAliasingDef): * b3/air/testair.cpp: (JSC::B3::Air::testX86VMULSD): (JSC::B3::Air::testX86VMULSDDestRex): (JSC::B3::Air::testX86VMULSDOp1DestRex): (JSC::B3::Air::testX86VMULSDOp2DestRex): (JSC::B3::Air::testX86VMULSDOpsDestRex): (JSC::B3::Air::testX86VMULSDAddr): (JSC::B3::Air::testX86VMULSDAddrOpRexAddr): (JSC::B3::Air::testX86VMULSDDestRexAddr): (JSC::B3::Air::testX86VMULSDRegOpDestRexAddr): (JSC::B3::Air::testX86VMULSDAddrOpDestRexAddr): Make sure we have some coverage for AVX encoding of instructions. 2016-03-30 Saam Barati Change some release asserts in CodeBlock linking into debug asserts https://bugs.webkit.org/show_bug.cgi?id=155500 Reviewed by Filip Pizlo. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): 2016-03-30 Joseph Pecoraro Remove unused ScriptProfiler.Samples.totalTime https://bugs.webkit.org/show_bug.cgi?id=156002 Reviewed by Saam Barati. * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::buildSamples): (Inspector::InspectorScriptProfilerAgent::trackingComplete): * inspector/protocol/ScriptProfiler.json: Remove totalTime. * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::SamplingProfiler): Deleted. * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::totalTime): Deleted. Remove now unused m_totalTime. 2016-03-30 Michael Saboff [ES6] Quantified unicode regular expressions do not work for counts greater than 1 https://bugs.webkit.org/show_bug.cgi?id=156044 Reviewed by Mark Lam. Fixed incorrect indexing of non-BMP characters in fixed patterns. The old code was indexing by character units, a single JS character, instead of code points which is 2 JS characters. * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::matchDisjunction): 2016-03-30 Mark Lam Make the $vm debugging tools available to builtins as @$vm. https://bugs.webkit.org/show_bug.cgi?id=156012 Reviewed by Saam Barati. We also need some debugging tools for builtin development. The $vm object will be made available to builtins as @$vm, which gives us, amongst many goodies, @$vm.print() (which prints the toString() values of its args) and @$vm.printValue() (which dataLogs its arg as a JSValue). @$vm will only be available if we run with JSC_useDollarVM=true. Also changed @$vm.print() to not automatically insert a space between the printing of each of its args. This makes it clearer as to what will be printed i.e. it will only print what is passed to it. * builtins/BuiltinNames.h: (JSC::BuiltinNames::BuiltinNames): (JSC::BuiltinNames::dollarVMPublicName): (JSC::BuiltinNames::dollarVMPrivateName): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * tools/JSDollarVMPrototype.cpp: (JSC::functionPrint): 2016-03-30 Keith Miller Unreviewed, buildfix. * bytecode/BytecodeIntrinsicRegistry.h: 2016-03-30 Keith Miller Unreviewed, rollout r198808. The patch causes crashes on 32-bit and appears to be a JSBench regression. 2016-03-30 Yusuke Suzuki [JSC] Implement String.prototype.repeat in builtins JS https://bugs.webkit.org/show_bug.cgi?id=155974 Reviewed by Darin Adler. This patch converts C++ String.prototype.repeat implementation into JS builtins. |this| in strict mode is correctly inferred as String[1]. This fact encourages us to write PrimitiveTypes.prototype.XXX methods in builtin JS. LayoutTests/js/string-repeat.html already covers the tests for this change. Note: String.prototype.repeat functionality is similar to Harmony's String.prototype.{padStart, padEnd}. It's nice to port them to builtin JS in the other patch. The existing C++ code has the fast path for singleCharacterString repeating. Since this use is important (e.g. generating N length spaces: ' '.repeat(N)), we keep this fast path as @repeatCharacter(). The performance results show that, while the performance of the single character fast path is neutral, other string repeating has significant speed up. There are two reasons. 1. Not resolving string rope. We added several tests postfixed "not-resolving". In that tests, we do not touch the content of the generated string. As a result, the generated rope is not resolved. 2. O(log N) intermediate JSRopeStrings. In the existing C++ implementation, we use JSString::RopeBuilder. We iterate N times and append the given string to the builder. In this case, the intermediate rope strings generated in JSString::RopeBuilder is O(N). In JS builtin implementation, we only iterate log N times. As a result, the number of the intermediate rope strings becomes O(log N). [1]: http://trac.webkit.org/changeset/195938 * builtins/StringPrototype.js: (repeatSlowPath): (repeat): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncRepeatCharacter): (JSC::StringPrototype::finishCreation): Deleted. (JSC::stringProtoFuncRepeat): Deleted. * runtime/StringPrototype.h: * tests/stress/string-repeat-edge-cases.js: Added. (shouldBe): (let.object.toString): (valueOf): (shouldThrow): 2016-03-30 Benjamin Poulain [JSC] Update udis86 https://bugs.webkit.org/show_bug.cgi?id=156005 Reviewed by Geoffrey Garen. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * disassembler/udis86/differences.txt: * disassembler/udis86/itab.py: Removed. * disassembler/udis86/optable.xml: * disassembler/udis86/ud_itab.py: Added. * disassembler/udis86/ud_opcode.py: * disassembler/udis86/ud_optable.py: Removed. * disassembler/udis86/udis86.c: * disassembler/udis86/udis86_decode.c: * disassembler/udis86/udis86_decode.h: * disassembler/udis86/udis86_extern.h: * disassembler/udis86/udis86_input.c: Removed. * disassembler/udis86/udis86_input.h: Removed. * disassembler/udis86/udis86_syn-att.c: * disassembler/udis86/udis86_syn.h: * disassembler/udis86/udis86_types.h: * disassembler/udis86/udis86_udint.h: 2016-03-30 Benjamin Poulain [JSC] Get rid of operationInitGlobalConst(), it is useless https://bugs.webkit.org/show_bug.cgi?id=156010 Reviewed by Geoffrey Garen. * jit/JITOperations.cpp: * jit/JITOperations.h: 2016-03-29 Saam barati Fix typos in our error messages and remove some trailing periods https://bugs.webkit.org/show_bug.cgi?id=155985 Reviewed by Mark Lam. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * runtime/ArrayConstructor.h: (JSC::isArray): * runtime/ProxyConstructor.cpp: (JSC::makeRevocableProxy): (JSC::proxyRevocableConstructorThrowError): (JSC::ProxyConstructor::finishCreation): (JSC::constructProxyObject): * runtime/ProxyObject.cpp: (JSC::ProxyObject::finishCreation): (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (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/StringPrototype.cpp: (JSC::stringProtoFuncStartsWith): (JSC::stringProtoFuncEndsWith): (JSC::stringProtoFuncIncludes): * runtime/Structure.cpp: (JSC::Structure::preventExtensionsTransition): * tests/stress/proxy-basic.js: * tests/stress/proxy-construct.js: (throw.new.Error): (assert): * tests/stress/proxy-define-own-property.js: (assert): (throw.new.Error): (i.catch): (assert.set get catch): * tests/stress/proxy-delete.js: (assert): * tests/stress/proxy-get-own-property.js: (assert): (i.catch): (set get let): * tests/stress/proxy-get-prototype-of.js: (assert): (assert.get let): (assert.get catch): * tests/stress/proxy-has-property.js: (assert): * tests/stress/proxy-is-array.js: (test): * tests/stress/proxy-is-extensible.js: (assert): * tests/stress/proxy-json.js: (assert): (test): * tests/stress/proxy-own-keys.js: (assert): (i.catch): * tests/stress/proxy-prevent-extensions.js: (assert): * tests/stress/proxy-property-descriptor.js: * tests/stress/proxy-revoke.js: (assert): (throw.new.Error.): (throw.new.Error): (shouldThrowNullHandler): * tests/stress/proxy-set-prototype-of.js: (assert.set let): (assert.set catch): (assert): (set catch): * tests/stress/proxy-set.js: (throw.new.Error.let.handler.set 45): (throw.new.Error): * tests/stress/proxy-with-private-symbols.js: (assert): * tests/stress/proxy-with-unbalanced-getter-setter.js: (assert): * tests/stress/reflect-set-proxy-set.js: (throw.new.Error.let.handler.set 45): (throw.new.Error): * tests/stress/reflect-set-receiver-proxy-set.js: (let.handler.set 45): (catch): * tests/stress/string-prototype-methods-endsWith-startsWith-includes-correctness.js: (test): (test.get let): 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-03-29 Saam barati We don't properly optimize TDZ checks when we declare a let variable without an initializer https://bugs.webkit.org/show_bug.cgi?id=150453 Reviewed by Mark Lam. * bytecompiler/NodesCodegen.cpp: (JSC::EmptyLetExpression::emitBytecode): 2016-03-29 Saam barati Allow builtin JS functions to be intrinsics https://bugs.webkit.org/show_bug.cgi?id=155960 Reviewed by Mark Lam. Builtin functions can now be recognized as intrinsics inside the DFG. This gives us the flexibility to either lower a builtin as an intrinsic in the DFG or as a normal function call. Because we may decide to not lower it as an intrinsic, the DFG inliner could still inline the function call. You can annotate a builtin function like so to make it be recognized as an intrinsic. ``` [intrinsic=FooIntrinsic] function foo() { ... } ``` where FooIntrinsic is an enum value of the Intrinsic enum. So in the future if we write RegExp.prototype.test as a builtin, we would do: ``` RegExpPrototype.js [intrinsic=RegExpTestIntrinsic] function test() { ... } ``` * Scripts/builtins/builtins_generate_combined_implementation.py: (BuiltinsCombinedImplementationGenerator.generate_secondary_header_includes): * Scripts/builtins/builtins_generate_separate_implementation.py: (BuiltinsSeparateImplementationGenerator.generate_secondary_header_includes): * Scripts/builtins/builtins_generator.py: (BuiltinsGenerator.generate_embedded_code_string_section_for_function): * Scripts/builtins/builtins_model.py: (BuiltinObject.__init__): (BuiltinFunction): (BuiltinFunction.__init__): (BuiltinFunction.fromString): (BuiltinFunction.__str__): * Scripts/builtins/builtins_templates.py: * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::visitChildren): (JSC::UnlinkedFunctionExecutable::link): * bytecode/UnlinkedFunctionExecutable.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::attemptToInlineCall): * runtime/Executable.cpp: (JSC::ExecutableBase::clearCode): (JSC::NativeExecutable::destroy): (JSC::ScriptExecutable::ScriptExecutable): (JSC::EvalExecutable::create): (JSC::EvalExecutable::EvalExecutable): (JSC::ProgramExecutable::ProgramExecutable): (JSC::ModuleProgramExecutable::ModuleProgramExecutable): (JSC::FunctionExecutable::FunctionExecutable): (JSC::ExecutableBase::intrinsic): Deleted. (JSC::NativeExecutable::intrinsic): Deleted. * runtime/Executable.h: (JSC::ExecutableBase::ExecutableBase): (JSC::ExecutableBase::hasJITCodeFor): (JSC::ExecutableBase::intrinsic): (JSC::ExecutableBase::intrinsicFor): (JSC::ScriptExecutable::finishCreation): * runtime/Intrinsic.h: 2016-03-29 Joseph Pecoraro JSC::Debugger cleanup after recent changes https://bugs.webkit.org/show_bug.cgi?id=155982 Reviewed by Mark Lam. * debugger/Debugger.cpp: (JSC::Debugger::Debugger): Initialize with breakpoints disabled. Web Inspector always informs the backend if it should enable or disable breakpoints on startup. (JSC::Debugger::setProfilingClient): When using the Sampling profiler we do not need to recompile. 2016-03-29 Saam barati "Can not" => "cannot" in String.prototype error messages https://bugs.webkit.org/show_bug.cgi?id=155895 Reviewed by Mark Lam. * runtime/StringPrototype.cpp: (JSC::stringProtoFuncStartsWith): (JSC::stringProtoFuncEndsWith): (JSC::stringProtoFuncIncludes): * tests/stress/string-prototype-methods-endsWith-startsWith-includes-correctness.js: (test): (test.get let): 2016-03-29 Joseph Pecoraro Web Inspector: We should have a way to capture heap snapshots programatically. https://bugs.webkit.org/show_bug.cgi?id=154407 Reviewed by Timothy Hatcher. * inspector/protocol/Console.json: Add a new Console.heapSnapshot event for when a heap snapshot is taken. * runtime/ConsolePrototype.cpp: (JSC::ConsolePrototype::finishCreation): (JSC::consoleProtoFuncProfile): (JSC::consoleProtoFuncProfileEnd): (JSC::consoleProtoFuncTakeHeapSnapshot): * runtime/ConsoleClient.h: Add the console.takeHeapSnapshot method and dispatch to the ConsoleClient. * inspector/JSGlobalObjectConsoleClient.cpp: (Inspector::JSGlobalObjectConsoleClient::takeHeapSnapshot): * inspector/JSGlobalObjectConsoleClient.h: Have the InspectorConsoleAgent handle this. * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): * inspector/agents/InspectorConsoleAgent.cpp: (Inspector::InspectorConsoleAgent::InspectorConsoleAgent): (Inspector::InspectorConsoleAgent::takeHeapSnapshot): * inspector/agents/InspectorConsoleAgent.h: * inspector/agents/JSGlobalObjectConsoleAgent.cpp: (Inspector::JSGlobalObjectConsoleAgent::JSGlobalObjectConsoleAgent): * inspector/agents/JSGlobalObjectConsoleAgent.h: Give the ConsoleAgent a HeapAgent pointer so that it can have the HeapAgent perform the snapshot building work like it normally does. 2016-03-29 Yusuke Suzuki REGRESSION(r192914): 10% regression on Sunspider's date-format-tofte https://bugs.webkit.org/show_bug.cgi?id=155559 Reviewed by Saam Barati. The fast path of the eval function is the super hot path in date-format-tofte. Any performance regression is not allowed here. Before this patch, we allocated SourceCode in the fast path. This allocation incurs 10% performance regression. This patch removes this allocation in the fast path. And change the key of the EvalCodeCache to EvalCodeCache::CacheKey. It combines RefPtr and isArrowFunctionContext. Since EvalCodeCache does not cache any eval code evaluated under the strict mode, it is unnecessary to include several options (ThisTDZMode, and DerivedContextType) in the cache map's key. But isArrowFunctionContext is necessary since the sloppy mode arrow function exists. To validate this change, we add a new test that evaluates the same code under the non-arrow function context and the arrow function context. After introducing CacheKey, we observed 1% regression compared to the RefPtr keyed case. This is because HashMap, ...>::get(T*) is specially optimized; this path is inlined while the normal ::get() is not inlined. To avoid this performance regression, we introduce HashMap::fastGet, that aggressively encourages inlining. The relationship between fastGet() and get() is similar to fastAdd() and add(). After applying this change, the evaluation shows no performance regression in comparison with the RefPtr keyed case. * bytecode/EvalCodeCache.h: (JSC::EvalCodeCache::CacheKey::CacheKey): (JSC::EvalCodeCache::CacheKey::hash): (JSC::EvalCodeCache::CacheKey::isEmptyValue): (JSC::EvalCodeCache::CacheKey::operator==): (JSC::EvalCodeCache::CacheKey::isHashTableDeletedValue): (JSC::EvalCodeCache::CacheKey::Hash::hash): (JSC::EvalCodeCache::CacheKey::Hash::equal): (JSC::EvalCodeCache::tryGet): (JSC::EvalCodeCache::getSlow): (JSC::EvalCodeCache::isCacheable): * interpreter/Interpreter.cpp: (JSC::eval): * tests/stress/eval-in-arrow-function.js: Added. (shouldBe): (i): 2016-03-29 Joseph Pecoraro Audit WebCore builtins for user overridable code https://bugs.webkit.org/show_bug.cgi?id=155923 Reviewed by Youenn Fablet. * runtime/CommonIdentifiers.h: * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): Expose @Object.@defineProperty to built-ins. 2016-03-28 Benjamin Poulain [JSC] ArithSub should not propagate "UsesAsOther" https://bugs.webkit.org/show_bug.cgi?id=155932 Reviewed by Mark Lam. The node ArithSub was backpropagating UsesAsOther. This causes any GetByVal on a Double Array to have an extra hole check if it flows into an ArithSub. The definition of ArithSub (12.8.4.1) has both operands go through ToNumber(). ToNumber() on "undefined" always produces NaN. It is safe to ignore the NaN marker from hole when the DAG flows into ArithSub. This patch also adds this change and test coverage to ArithAdd. ArithAdd was not a problem in practice because it is only generated before Fixup if both operands are known to be numerical. The change to ArithAdd is there to protect us of the ArithSub-like problems if we ever improve our support of arithmetic operators. * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * tests/stress/arith-add-on-double-array-with-holes.js: Added. (let.testCase.of.testCases.eval.nonObservableHoleOnLhs): (let.testCase.of.testCases.observableHoleOnLhs): (let.testCase.of.testCases.nonObservableHoleOnRhs): (let.testCase.of.testCases.observableHoleOnRhs): * tests/stress/arith-sub-on-double-array-with-holes.js: Added. (let.testCase.of.testCases.eval.nonObservableHoleOnLhs): (let.testCase.of.testCases.observableHoleOnLhs): (let.testCase.of.testCases.nonObservableHoleOnRhs): (let.testCase.of.testCases.observableHoleOnRhs): * tests/stress/value-add-on-double-array-with-holes.js: Added. (let.testCase.of.testCases.eval.nonObservableHoleOnLhs): (let.testCase.of.testCases.observableHoleOnLhs): (let.testCase.of.testCases.nonObservableHoleOnRhs): (let.testCase.of.testCases.observableHoleOnRhs): 2016-03-28 Brian Burg Web Inspector: protocol generator should generate C++ string-to-enum helper functions https://bugs.webkit.org/show_bug.cgi?id=155691 Reviewed by Timothy Hatcher. There's a lot of code throughout the Inspector agents and automation code that needs to convert a raw string into a typed protocol enum. Generate some helpers that do this conversion so clients can move over to using it. These helpers are necessary for when we eventually switch to calling backend dispatcher handlers with typed arguments instead of untyped JSON objects. To correctly generate a conversion function for an anonymous enum, the generator needs to be able to get the containing object type's declaration. Since the model's Type object each have only one instance, there is a one-to-one association between type and its declaration. * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: (CppProtocolTypesHeaderGenerator.generate_output): (CppProtocolTypesHeaderGenerator._generate_forward_declarations): Clean up this method to use methodcaller to sort types by raw name. (_generate_declarations_for_enum_conversion_methods): (_generate_declarations_for_enum_conversion_methods.return_type_with_export_macro): (_generate_declarations_for_enum_conversion_methods.type_member_is_anonymous_enum_type): Added. Generates a new section with an unfilled template and specializations of the template for every named and anonymous enum in every domain. Guards for domains wrap the forward declarations. This is added to the end of the header file so that specializations for both types of enums are in the same place. * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: (CppProtocolTypesImplementationGenerator.generate_output): (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain): (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.type_member_is_anonymous_enum_type): (CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.generate_conversion_method_body): Added. Generate a static array of offsets into the enum constant value array. Then, loop over this array of offsets and do string comparisons against the provided string and enum constant values at the relevant offsets for this enum. * inspector/scripts/codegen/generator_templates.py: (GeneratorTemplates): Update copyright year in generated files. * inspector/scripts/codegen/models.py: (AliasedType.__init__): (EnumType.__init__): (EnumType.enum_values): (EnumType.declaration): (ArrayType.__init__): (ArrayType.declaration): (ObjectType.__init__): (ObjectType.declaration): (Protocol.resolve_types): (Protocol.lookup_type_reference): Pass the type declaration to Type constructors if available. If not, fill in a placeholder name for the type in the constructor instead of caller. Rebaseline all the things, mostly for copyright block changes. * 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-03-25 Joseph Pecoraro Misc. JavaScriptCore built-ins cleanups https://bugs.webkit.org/show_bug.cgi?id=155920 Reviewed by Mark Lam. * builtins/RegExpPrototype.js: (match): No need for an else after an if that always returns. * builtins/TypedArrayConstructor.js: (of): Fix error message to use the correct function name. (allocateInt8Array): (allocateInt16Array): (allocateInt32Array): (allocateUint32Array): (allocateUint16Array): (allocateUint8Array): (allocateUint8ClampedArray): (allocateFloat32Array): (allocateFloat64Array): Cleanup style to be like all the other code. * tests/stress/typedarray-of.js: Test the exception message. 2016-03-25 Joseph Pecoraro Date.prototype.toLocaleDateString uses overridable Object.create https://bugs.webkit.org/show_bug.cgi?id=155917 Reviewed by Mark Lam. * builtins/DatePrototype.js: (toLocaleString.toDateTimeOptionsAnyAll): (toLocaleDateString.toDateTimeOptionsDateDate): (toLocaleTimeString.toDateTimeOptionsTimeTime): Switch from @Object.create to @Object.@create to guarentee we are using the built-in create method and not user defined code. * runtime/CommonIdentifiers.h: * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): Setup the @create private symbol. 2016-03-25 Benjamin Poulain [JSC] Put the x86 Assembler on a binary diet https://bugs.webkit.org/show_bug.cgi?id=155683 Reviewed by Darin Adler. The MacroAssemblers are heavily inlined. This is unfortunately important for baseline JIT where many branches can be eliminated at compile time. This inlining causes a lot of binary bloat. The phases lowering to ASM are massively large. This patch improves the situation a bit for x86 through many small improvements: -Every instruction starts with ensureSpace(). The slow path realloc the buffer. From that slow path, only fastRealloc() was a function call. What is around does not need to be fast, I moved the whole grow() function out of line for those cases. -When testing multiple registers for REX requirements, we had something like this: byteRegRequiresRex(reg) || byteRegRequiresRex(rm) regRequiresRex(index) || regRequiresRex(base) Those were producing multiple test-and-branch. Those branches are effectively random so we don't have to care about individual branches being predictable. The new code effectively does: byteRegRequiresRex(reg | rm) regRequiresRex(index | base) -Change "ModRmMode" to have the value we can OR directly to the generated ModRm. This is important because some ModRM code is so large that is goes out of line; -Finally, a big change on how we write to the AssemblerBuffer. Previously, instructions were written byte by byte into the assembler buffer of the MacroAssembler. The problem with that is the compiler cannot prove that the buffer pointer and the AssemblerBuffer are not pointing to the same memory. Because of that, before any write, all the local register were pushed back to the AssemblerBuffer memory, then everything was read back after the write to compute the next write. I attempted to use the "restrict" keyword and wrapper types to help Clang with that but nothing worked. The current solution is to keep a local copy of the index and the buffer pointer in the scope of each instruction. That is done by AssemblerBuffer::LocalWriter. Since LocalWriter only exists locally, it stays in register and we don't have all the memory churn between each byte writing. This also allows clang to combine obvious cases since there are no longer observable side effects between bytes. This patch reduces the binary size by 66k. It is a small speed-up on Sunspider. * assembler/AssemblerBuffer.h: (JSC::AssemblerBuffer::ensureSpace): (JSC::AssemblerBuffer::LocalWriter::LocalWriter): (JSC::AssemblerBuffer::LocalWriter::~LocalWriter): (JSC::AssemblerBuffer::LocalWriter::putByteUnchecked): (JSC::AssemblerBuffer::LocalWriter::putShortUnchecked): (JSC::AssemblerBuffer::LocalWriter::putIntUnchecked): (JSC::AssemblerBuffer::LocalWriter::putInt64Unchecked): (JSC::AssemblerBuffer::LocalWriter::putIntegralUnchecked): (JSC::AssemblerBuffer::putIntegral): (JSC::AssemblerBuffer::outOfLineGrow): * assembler/MacroAssemblerX86Common.h: * assembler/X86Assembler.h: (JSC::X86Assembler::X86InstructionFormatter::byteRegRequiresRex): (JSC::X86Assembler::X86InstructionFormatter::regRequiresRex): (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::LocalBufferWriter): (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRex): (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexW): (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexIf): (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::emitRexIfNeeded): (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::putModRm): (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::putModRmSib): (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::registerModRM): (JSC::X86Assembler::X86InstructionFormatter::LocalBufferWriter::memoryModRM): (JSC::X86Assembler::X86InstructionFormatter::oneByteOp): Deleted. (JSC::X86Assembler::X86InstructionFormatter::oneByteOp_disp32): Deleted. (JSC::X86Assembler::X86InstructionFormatter::oneByteOp_disp8): Deleted. (JSC::X86Assembler::X86InstructionFormatter::twoByteOp): Deleted. (JSC::X86Assembler::X86InstructionFormatter::threeByteOp): Deleted. (JSC::X86Assembler::X86InstructionFormatter::oneByteOp64): Deleted. (JSC::X86Assembler::X86InstructionFormatter::oneByteOp64_disp32): Deleted. (JSC::X86Assembler::X86InstructionFormatter::oneByteOp64_disp8): Deleted. (JSC::X86Assembler::X86InstructionFormatter::twoByteOp64): Deleted. (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8): Deleted. (JSC::X86Assembler::X86InstructionFormatter::twoByteOp8): Deleted. (JSC::X86Assembler::X86InstructionFormatter::emitRex): Deleted. (JSC::X86Assembler::X86InstructionFormatter::emitRexW): Deleted. (JSC::X86Assembler::X86InstructionFormatter::emitRexIf): Deleted. (JSC::X86Assembler::X86InstructionFormatter::emitRexIfNeeded): Deleted. (JSC::X86Assembler::X86InstructionFormatter::putModRm): Deleted. (JSC::X86Assembler::X86InstructionFormatter::putModRmSib): Deleted. (JSC::X86Assembler::X86InstructionFormatter::registerModRM): Deleted. (JSC::X86Assembler::X86InstructionFormatter::memoryModRM): Deleted. 2016-03-25 Saam barati RegExp.prototype.test should be an intrinsic again https://bugs.webkit.org/show_bug.cgi?id=155861 Reviewed by Yusuke Suzuki. * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): 2016-03-25 Mark Lam ES6's throwing of TypeErrors on access of RegExp.prototype flag properties breaks websites. https://bugs.webkit.org/show_bug.cgi?id=155904 Reviewed by Geoffrey Garen. There exists a JS library XRegExp (see http://xregexp.com) that extends the regexp implementation. XRegExp does feature testing by comparing RegExp.prototype.sticky to undefined. See: Example 1. https://github.com/slevithan/xregexp/blob/28a2b033c5951477bed8c7c867ddf7e89c431cd4/tests/perf/index.html ... } else if (knownVersion[version]) { // Hack around ES6 incompatibility in XRegExp versions prior to 3.0.0 if (parseInt(version, 10) < 3) { delete RegExp.prototype.sticky; } ... Example 2. https://github.com/slevithan/xregexp/blob/d0e665d4068cec4d15919215b098b2373f1f12e9/tests/perf/versions/xregexp-all-v2.0.0.js ... // Check for flag y support (Firefox 3+) hasNativeY = RegExp.prototype.sticky !== undef, ... The ES6 spec states that we should throw a TypeError here because RegExp.prototype is not a RegExp object, and the sticky getter is only allowed to be called on RegExp objects. See https://tc39.github.io/ecma262/2016/#sec-get-regexp.prototype.sticky. As a result, websites that uses XRegExp can break (e.g. some Atlassian tools). As a workaround, we'll return undefined instead of throwing on access of these flag properties that may be used for feature testing. * runtime/RegExpPrototype.cpp: (JSC::regExpProtoGetterGlobal): (JSC::regExpProtoGetterIgnoreCase): (JSC::regExpProtoGetterMultiline): (JSC::regExpProtoGetterSticky): (JSC::regExpProtoGetterUnicode): 2016-03-25 Caitlin Potter [JSC] fix divide-by-zero in String.prototype.padStart/padEnd https://bugs.webkit.org/show_bug.cgi?id=155903 Reviewed by Filip Pizlo. * runtime/StringPrototype.cpp: (JSC::padString): 2016-03-25 Benjamin Poulain [JSC] materialize-past-butterfly-allocation.js time out in debug * tests/stress/materialize-past-butterfly-allocation.js: The test times out on the debug bots. We suspect there is nothing wrong, just overkill loops. 2016-03-25 Brian Burg Web Inspector: protocol generator should prefix C++ filenames with the protocol group https://bugs.webkit.org/show_bug.cgi?id=155859 Reviewed by Alex Christensen and Joseph Pecoraro. Like for generated Objective-C files, we should use the 'protocol group' name as the prefix for generated C++ files so that headers from different protocol groups have unambiguous names. * inspector/scripts/codegen/cpp_generator.py: (CppGenerator): (CppGenerator.__init__): (CppGenerator.protocol_name): Make all C++ code generators extend the CppGenerator python class and use the protocol_name() instance method. This matches a recent change to the ObjC generator. * inspector/scripts/codegen/cpp_generator_templates.py: (CppGeneratorTemplates): Drive-by cleanup to use #pragma once instead of header guards. * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py: (CppAlternateBackendDispatcherHeaderGenerator): (CppAlternateBackendDispatcherHeaderGenerator.__init__): (CppAlternateBackendDispatcherHeaderGenerator.output_filename): (CppAlternateBackendDispatcherHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: (CppBackendDispatcherHeaderGenerator): (CppBackendDispatcherHeaderGenerator.__init__): (CppBackendDispatcherHeaderGenerator.output_filename): (CppBackendDispatcherHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py: (CppBackendDispatcherImplementationGenerator): (CppBackendDispatcherImplementationGenerator.__init__): (CppBackendDispatcherImplementationGenerator.output_filename): (CppBackendDispatcherImplementationGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py: (CppFrontendDispatcherHeaderGenerator): (CppFrontendDispatcherHeaderGenerator.__init__): (CppFrontendDispatcherHeaderGenerator.output_filename): (CppFrontendDispatcherHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py: (CppFrontendDispatcherImplementationGenerator): (CppFrontendDispatcherImplementationGenerator.__init__): (CppFrontendDispatcherImplementationGenerator.output_filename): (CppFrontendDispatcherImplementationGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: (CppProtocolTypesHeaderGenerator): (CppProtocolTypesHeaderGenerator.__init__): (CppProtocolTypesHeaderGenerator.output_filename): (CppProtocolTypesHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: (CppProtocolTypesImplementationGenerator): (CppProtocolTypesImplementationGenerator.__init__): (CppProtocolTypesImplementationGenerator.output_filename): (CppProtocolTypesImplementationGenerator.generate_output): Use the protocol_name() instance method to compute generated protocol file names. * inspector/scripts/codegen/models.py: Explicitly set the 'protocol_group' for the Inspector protocol. Rebaseline generator test results. * 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-03-25 Keith Miller putByIndexBeyondVectorLengthWithoutAttributes should not crash if it can't ensureLength https://bugs.webkit.org/show_bug.cgi?id=155730 Reviewed by Saam Barati. This patch makes ensureLength return a boolean indicating if it was able to set the length. ensureLength also no longer sets the butterfly to null if the allocation of the butterfly fails. All of ensureLengths callers including putByIndexBeyondVectorLengthWithoutAttributes have been adapted to throw an out of memory error if ensureLength fails. * runtime/JSArray.cpp: (JSC::JSArray::setLength): (JSC::JSArray::unshiftCountWithAnyIndexingType): * runtime/JSObject.cpp: (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): (JSC::JSObject::ensureLengthSlow): * runtime/JSObject.h: (JSC::JSObject::ensureLength): 2016-03-25 Caitlin Potter [JSC] implement String.prototype.padStart() and String.prototype.padEnd() proposal https://bugs.webkit.org/show_bug.cgi?id=155795 Reviewed by Darin Adler. Implements ECMAScript proposal http://tc39.github.io/proposal-string-pad-start-end/ Currently at Stage 3. * runtime/JSString.h: * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::repeatCharacter): (JSC::repeatStringPattern): (JSC::padString): (JSC::stringProtoFuncPadEnd): (JSC::stringProtoFuncPadStart): * tests/es6.yaml: * tests/es6/String.prototype_methods_String.prototype.padEnd.js: Added. * tests/es6/String.prototype_methods_String.prototype.padStart.js: Added. 2016-03-24 Alex Christensen Fix Mac CMake build. * PlatformMac.cmake: Link to Security framework. 2016-03-24 Saam barati ES6: Implement IsRegExp function and use where needed in String.prototype.* methods https://bugs.webkit.org/show_bug.cgi?id=155854 Reviewed by Mark Lam. This patch is a straight forward implementation of IsRegExp in the ES6 spec: https://tc39.github.io/ecma262/#sec-isregexp We now use this IsRegExp function inside String.prototype.(startsWith | endsWith | includes) as is dictated by the spec. * runtime/RegExpConstructor.h: (JSC::RegExpConstructor::recordMatch): (JSC::isRegExp): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncStartsWith): (JSC::stringProtoFuncEndsWith): (JSC::stringProtoFuncIncludes): * tests/es6.yaml: * tests/es6/well-known_symbols_Symbol.match_String.prototype.endsWith.js: Added. (test): * tests/es6/well-known_symbols_Symbol.match_String.prototype.includes.js: Added. (test): * tests/es6/well-known_symbols_Symbol.match_String.prototype.startsWith.js: Added. (test): * tests/stress/string-prototype-methods-endsWith-startsWith-includes-correctness.js: Added. (assert): (test): (test.get let): (get let): 2016-03-24 Saam barati Web Inspector: Separate Debugger enable state from the debugger breakpoints enabled state https://bugs.webkit.org/show_bug.cgi?id=152193 Reviewed by Joseph Pecoraro. When all breakpoints are disabled, we can recompile all JS code and remove the necessary debugging code that is emitted. This allows for the code that is executing to be almost as fast as it is with the debugger completely disabled. This is in preparation for: https://bugs.webkit.org/show_bug.cgi?id=155809 which will introduce a high fidelity profiler. That profiler could be built off the principle that breakpoints are disabled when we're performing a high fidelity profile. Doing so, for example, allows the sampling profiler to better measure the real performance of the JS of a particular application. * debugger/Debugger.cpp: (JSC::Debugger::setBreakpointsActivated): (JSC::Debugger::setPauseOnExceptionsState): * debugger/Debugger.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): * inspector/JSGlobalObjectScriptDebugServer.cpp: (Inspector::JSGlobalObjectScriptDebugServer::attachDebugger): (Inspector::JSGlobalObjectScriptDebugServer::detachDebugger): * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::InspectorDebuggerAgent::enable): * runtime/Executable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::createProgramCodeBlock): (JSC::JSGlobalObject::createEvalCodeBlock): (JSC::JSGlobalObject::createModuleProgramCodeBlock): (JSC::JSGlobalObject::queueMicrotask): (JSC::JSGlobalObject::hasDebugger): (JSC::JSGlobalObject::hasInteractiveDebugger): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::runtimeFlags): (JSC::JSGlobalObject::hasDebugger): Deleted. 2016-03-24 Michael Saboff Create private builtin helper advanceStringIndexUnicode() for use by RegExp builtins https://bugs.webkit.org/show_bug.cgi?id=155855 Reviewed by Mark Lam. Moved advanceStringIndexUnicode() as a separate helper. Added it as a private builtin to the GlobalObject like other private builtins. * builtins/RegExpPrototype.js: (advanceStringIndexUnicode): (match): (match.advanceStringIndexUnicode): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): 2016-03-24 Michael Saboff [ES6] Add Proxy based tests for RegExp.prototype[@@match] https://bugs.webkit.org/show_bug.cgi?id=155807 Reviewed by Saam Barati. Added new test that uses Proxy to verify RegExp.prototype[@@match] processing conforms to the ES6 standard Modified builtin RegExp.prototype[@@match] to be ES6 spec conformant. Updated es6.yaml as Proxy_internal_get_calls_RegExp.prototype[Symbol.match].js now passes. * builtins/RegExpPrototype.js: (match): * tests/es6.yaml: Updated. * tests/stress/regexp-match-proxy.js: Added. (assert): (let.getProxyNullExec.new.Proxy): (let.getSetProxyNullExec.new.Proxy): (get resetTracking): (let.getSetProxyMatches_s.new.Proxy): (set get getSetProxyNullExec): (let.getSetProxyMatches_tx_Greedy.new.Proxy): (set get getSetProxyMatches_s): (let.getSetProxyMatchesUnicode_digit_nonGreedy.new.Proxy): (set get getSetProxyMatches_tx_Greedy): 2016-03-24 Michael Saboff [ES6] Greedy unicode RegExp's don't properly backtrack past non BMP characters https://bugs.webkit.org/show_bug.cgi?id=155829 Reviewed by Saam Barati. When we backup when matching part of a unicode pattern, we can't just backup one character. Instead we need to save our start position before trying to match a character and restore the position if the match fails. This was done in other places, but wasn't done for all greedy types. Fixed matchGlobal() to properly handle advancing past non BMP characters. * runtime/RegExpObject.cpp: (JSC::RegExpObject::matchGlobal): * runtime/RegExpObjectInlines.h: (JSC::RegExpObject::advanceStringUnicode): * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::matchCharacterClass): (JSC::Yarr::Interpreter::matchDisjunction): 2016-03-24 Benjamin Poulain [JSC] In some cases, the integer range optimization phase never converges https://bugs.webkit.org/show_bug.cgi?id=155828 rdar://problem/25155460 Reviewed by Filip Pizlo. In certain conditions, the integer range optimization phase continuously changes the representation of the same truth, preventing it from converging to a stable state. The bug starts by having the same ground truth incomming into a block in different valid forms. For example, you can have x < 42 coming as: 1) x < 42 2) x < 41 + 1 3) x < 43 - 1 Having those 3 alone coming from predecessors would be okay, we would just accumulate them. The problem is when you have a combination of rule that filter out the previously obtained truth, then add a new form of the same truth. Let's use the test case as an example. We have two incoming blocks: Block #1: -i < 42 -i != 41 Block #2: -i < 41 -i == 42 - 42 (i == 0 refining the rule above). Let say that our conditions at head are now [i < 41, i < 42 - 1]. If we merge block #2: -i < 42 and i < 41 -> i < 42 -i < 42 and i < 42 - 1 -> i < 42 -i != 41 and i < 41 -> i < 41 -i != 41 and i < 42 - 1 -> nothing The new head is: [i < 41, i < 42] If we merge block #1: -i < 41 and i < 41 -> i < 41 -i < 41 and i < 42 -> i < 42 -i == 42 - 42 and i < 41 -> (i < 41 and i < 42 - 1) -i == 42 - 42 and i < 42 -> i < 42 After filter, we are back to [i < 41, i < 42 - 1]. There are several variations of this idea where the same truth rotate different forms with each merge(). One possible solution is to make filter() more aggressive to avoid the better form occuring at merge(). I'll probably do that at some point but that seems fragile since the same problem could reappear if merge() is later improved. For this patch, I went with a more generic solution after merge(): if the generated form is equivalent to one that previously existed at head, pick the existing form. In the previous example, what happens is we only have either [i < 41] or [i < 42 - 1] but never both simultaneously. * dfg/DFGIntegerRangeOptimizationPhase.cpp: * tests/stress/integer-range-optimization-constant-representation-1.js: Added. * tests/stress/integer-range-optimization-constant-representation-2.js: Added. Two variation. One timeout in release because of the additional flags. The other is gets more type of run but only assert in debug. 2016-03-23 Commit Queue Unreviewed, rolling out r198582. https://bugs.webkit.org/show_bug.cgi?id=155812 "It broke debugging in the web inspector" (Requested by saamyjoon on #webkit). Reverted changeset: "We should not disable inlining when the debugger is enabled" https://bugs.webkit.org/show_bug.cgi?id=155741 http://trac.webkit.org/changeset/198582 2016-03-23 Michael Saboff JavaScriptCore ArrayPrototype::join shouldn't cache butterfly when it makes effectful calls https://bugs.webkit.org/show_bug.cgi?id=155776 Reviewed by Saam Barati. Array.join ends up calling toString, possibly on some object. Since these calls could be effectful and could change the array itself, we can't hold the butterfly pointer while making effectful calls. Changed the code to fall back to the general case when an effectful toString() call might be made. * runtime/ArrayPrototype.cpp: (JSC::join): * runtime/JSStringJoiner.h: (JSC::JSStringJoiner::appendWithoutSideEffects): New helper that doesn't make effectful toString() calls. (JSC::JSStringJoiner::append): Built upon appendWithoutSideEffects. 2016-03-23 Keith Miller Array.prototype native functions' species constructors should work with proxies https://bugs.webkit.org/show_bug.cgi?id=155798 Reviewed by Mark Lam. Before native the species constructors were checking if the this value was a JSArray. Instead they should look check that the this value returns true on Array.isArray. * runtime/ArrayPrototype.cpp: (JSC::speciesConstructArray): * tests/es6.yaml: * tests/stress/proxy-array-prototype-methods.js: 2016-03-23 Saam barati We should not disable inlining when the debugger is enabled https://bugs.webkit.org/show_bug.cgi?id=155741 Reviewed by Oliver Hunt. We can enable inlining when the debugger is enabled as long as we make sure we still jettison the proper CodeBlocks when a breakpoint is set. This means that for any optimized CodeBlock, we must ask if any of its inlinees contain the breakpoint that is being set. If any inlinees do contain the breakpoint, we must jettison the machine code block that they are a part of. * debugger/Debugger.cpp: (JSC::Debugger::toggleBreakpoint): (JSC::Debugger::applyBreakpoints): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::ByteCodeParser): (JSC::DFG::ByteCodeParser::setLocal): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::flushForTerminal): (JSC::DFG::ByteCodeParser::inliningCost): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): (JSC::DFG::Graph::~Graph): * dfg/DFGGraph.h: (JSC::DFG::Graph::hasDebuggerEnabled): Deleted. * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): * ftl/FTLCompile.cpp: (JSC::FTL::compile): 2016-03-23 Yusuke Suzuki [ES6] Allow undefined/null for Symbol.search and Symbol.match https://bugs.webkit.org/show_bug.cgi?id=155785 Reviewed by Saam Barati. Undefined and null for Symbol.search and Symbol.match properties of the given RegExp (like) object are allowed. When they are specified, we go to the fallback path; creating the RegExp with the given object and matching. * builtins/StringPrototype.js: (match): (search): * tests/stress/string-symbol-customization.js: Added. (shouldBe): (shouldThrow): 2016-03-22 Caitlin Potter [JSC] correctly handle indexed properties in Object.getOwnPropertyDescriptors https://bugs.webkit.org/show_bug.cgi?id=155563 Reviewed by Saam Barati. * runtime/JSObject.h: (JSC::JSObject::putOwnDataPropertyMayBeIndex): * runtime/ObjectConstructor.cpp: (JSC::objectConstructorGetOwnPropertyDescriptors): 2016-03-22 Saam Barati We should FTL compile code when the debugger is enabled https://bugs.webkit.org/show_bug.cgi?id=155740 Reviewed by Oliver Hunt. There was no fundamental reason why we didn't support debugging with the FTL. It looks like this was just an oversight. We had a Breakpoint node in the DFG that amounted to a nop. By removing this node, we now support debugging in the FTL. Anytime a breakpoint is set, we will jettison any DFG/FTL CodeBlocks that contain the breakpoint that was set. * 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): 2016-03-22 Keith Miller REGRESSION(r197543): Use-after-free on storage/indexeddb/transaction-abort-private.html https://bugs.webkit.org/show_bug.cgi?id=155067 Reviewed by Filip Pizlo. GCIncommingRefCountedSets need to be finalized before we start destructing members of the Heap object. Previously, we would clear all our ArrayBuffer objects when the GCIncommingRefCountedSet holding them was destroyed. However, ArrayBuffers have a weak reference to their wrappers. When we would attempt to destroy the ArrayBuffer object we would end up accessing the WeakImpl for the weak reference, which had already been freed as we destroyed our weak block. The solution to this is to move the old GCIncommingRefCountedSet destructor functionality to a new function lastChanceToFinalize. This function is called when we finalize our other objects on Heap destruction. * heap/GCIncomingRefCountedSet.h: * heap/GCIncomingRefCountedSetInlines.h: (JSC::GCIncomingRefCountedSet::lastChanceToFinalize): (JSC::GCIncomingRefCountedSet::~GCIncomingRefCountedSet): Deleted. * heap/Heap.cpp: (JSC::Heap::lastChanceToFinalize): 2016-03-22 Per Arne Vollan [Win] [64-bit] Remove MSVC 2013 FMA3 Bug Workaround https://bugs.webkit.org/show_bug.cgi?id=141499 Reviewed by Brent Fulgham. As we have moved on to VS2015, this workaround is no longer needed. * API/tests/testapi.c: (main): * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: (wWinMain): * jsc.cpp: (main): * testRegExp.cpp: (main): 2016-03-22 Michael Saboff [ES6] Implement RegExp.prototype[@@match] https://bugs.webkit.org/show_bug.cgi?id=155711 Reviewed by Filip Pizlo. Implemented ES6 spec for String.prototype.match and RegExp.prototype[@@match]. Implemented both as builtins, with String.prototype.match calling RegExp.prototype[@@match]. For performance reasons, RegExp.prototype[@@match] has a C++ fast path when RegExp.prototype.exec has not been overridden. This fast path, RegExpObject::matchGlobal, was taken from the prior StringPrototype::match. It only handles global matches. Added new test, stress/regexp-match.js. Updated various tests for changes exception string and now passing ES6 behavior. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: Added builtins/RegExpPrototype.js and eliminated RegExpPrototype.lut.h. * builtins/RegExpPrototype.js: Added. (match.advanceStringIndexUnicode): Helper. (match): Implements RegExp.prototype[@@match]. * builtins/StringPrototype.js: (match): Implements String.prototype.match. * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): (JSC::BytecodeIntrinsicRegistry::lookup): * bytecode/BytecodeIntrinsicRegistry.h: * runtime/CommonIdentifiers.h: Added Symbol.match and builtins @match and @exec. * runtime/RegExpObject.cpp: * runtime/RegExpObject.h: * runtime/RegExpObjectInlines.h: (JSC::RegExpObject::matchGlobal): Added. (JSC::RegExpObject::advanceStringUnicode): Added helper. * runtime/RegExpPrototype.cpp: * runtime/RegExpPrototype.h: (JSC::RegExpPrototype::RegExpPrototype): (JSC::RegExpPrototype::finishCreation): (JSC::RegExpPrototype::visitChildren): (JSC::regExpProtoFuncMatchPrivate): (JSC::RegExpPrototype::getOwnPropertySlot): Deleted. (JSC::RegExpPrototype::create): Restructured to create properties explicitly due to having two names for native regExpProtoFuncExec. * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): Made match a builtin. Removed unused declaration of stringProtoFuncSearch() since it was made a builtin. * tests/es6.yaml: * tests/stress/regexp-match.js: Added. (shouldBe): (shouldThrow): (errorKey.toString): (primitive.of.primitives.shouldThrow): (testRegExpMatch): (testMatch): (testBoth): (alwaysUnmatch): 2016-03-22 Caitlin Potter [JSC] allow duplicate property names returned from Proxy ownKeys() trap https://bugs.webkit.org/show_bug.cgi?id=155560 Reviewed by Darin Adler. Specification allows duplicate property names to be reported by the Proxy ownKeys() trap --- and this is observable in any API which operates on the returned list, such as Object.keys(), Object.getOwnPropertyNames(), Object.getOwnPropertySymbols(), or Object.getOwnPropertyDescriptors(). * runtime/PropertyNameArray.h: (JSC::PropertyNameArray::addUnchecked): (JSC::PropertyNameArray::add): (JSC::PropertyNameArray::addKnownUnique): Deleted. * runtime/ProxyObject.cpp: (JSC::ProxyObject::performGetOwnPropertyNames): * runtime/Structure.cpp: (JSC::Structure::getPropertyNamesFromStructure): 2016-03-21 Yusuke Suzuki [JSC] Clean up Math.floor thunk and use SSE round instruction https://bugs.webkit.org/show_bug.cgi?id=155705 Reviewed by Geoffrey Garen. SSE now allow us to use round instruction to implement Math.floor. MacroAssembler's floorDouble is now only used in ARM64, but it can be allowed in x86 SSE. * jit/ThunkGenerators.cpp: (JSC::floorThunkGenerator): 2016-03-21 Konstantin Tokarev Fixed compilation with GCC 4.8. https://bugs.webkit.org/show_bug.cgi?id=155698 Reviewed by Alexey Proskuryakov. GCC 4.8 does not allow aggregate initialization for type with deleted constructor, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707. * dfg/DFGCSEPhase.cpp: Added ctor for ImpureDataSlot. 2016-03-21 Joonghun Park [JSC] Add ArrayBuffer::tryCreate and change the callsites where it is needed https://bugs.webkit.org/show_bug.cgi?id=155328 Reviewed by Darin Adler. * API/JSTypedArray.cpp: (JSObjectMakeTypedArray): (JSObjectMakeArrayBufferWithBytesNoCopy): * runtime/ArrayBuffer.h: (JSC::ArrayBuffer::create): (JSC::ArrayBuffer::tryCreate): (JSC::ArrayBuffer::createUninitialized): (JSC::ArrayBuffer::tryCreateUninitialized): (JSC::ArrayBuffer::createInternal): * runtime/GenericTypedArrayViewInlines.h: (JSC::GenericTypedArrayView::create): (JSC::GenericTypedArrayView::createUninitialized): * runtime/JSArrayBufferConstructor.cpp: (JSC::constructArrayBuffer): 2016-03-20 Dan Bernstein [Mac] Determine TARGET_MAC_OS_X_VERSION_MAJOR from MACOSX_DEPLOYMENT_TARGET rather than from MAC_OS_X_VERSION_MAJOR https://bugs.webkit.org/show_bug.cgi?id=155707 Reviewed by Darin Adler. * Configurations/Base.xcconfig: Set TARGET_MAC_OS_X_VERSION_MAJOR based on the last component of MACOSX_DEPLOYMENT_TARGET. * Configurations/DebugRelease.xcconfig: For engineering builds, preserve the behavior of TARGET_MAC_OS_X_VERSION_MAJOR being the host’s OS version. 2016-03-20 Michael Saboff Crash in stress/regexp-matches-array-slow-put.js due to stomping on memory when having bad time https://bugs.webkit.org/show_bug.cgi?id=155679 Reviewed by Saam Barati. Allocate out of line storage based on what the structure says it needs in JSArray::tryCreateUninitialized. * runtime/JSArray.h: (JSC::JSArray::tryCreateUninitialized): 2016-03-20 Joseph Pecoraro Crash on DFG::WorkList thread in JSC::Heap::isCollecting for destroyed Web Worker https://bugs.webkit.org/show_bug.cgi?id=155678 Reviewed by Filip Pizlo. This fixes a crash that we saw with GuardMalloc. If the Plan was Cancelled it may not be safe to access the VM. If the Plan was cancelled we are just going to bail anyways, so keep the ASSERT but short-circuit if the plan was Cancelled. * dfg/DFGWorklist.cpp: (JSC::DFG::Worklist::runThread): 2016-03-20 Dan Bernstein Update build settings Rubber-stamped by Andy Estes. * Configurations/DebugRelease.xcconfig: * Configurations/FeatureDefines.xcconfig: * Configurations/Version.xcconfig: 2016-03-19 Skachkov Oleksandr [ES6] Arrow function syntax. Update syntax error text 'super is only valid inside functions' to more suitable https://bugs.webkit.org/show_bug.cgi?id=155491 Reviewed by Saam Barati. Current message 'super is only valid inside of funcitons' is not correct after patch for https://bugs.webkit.org/show_bug.cgi?id=153864 because it is allow to use 'super' in eval. Current patch replace old message by 'Super is only valid inside functions or 'eval' inside a function' and fix tests that rely on this message. * parser/Parser.cpp: (JSC::Parser::parseMemberExpression): * tests/stress/generator-with-super.js: (shouldThrow): * tests/stress/modules-syntax-error.js: * tests/stress/super-in-lexical-scope.js: * tests/stress/tagged-templates-syntax.js: 2016-03-19 Mark Lam ES6 spec requires that ErrorPrototype not be an Error object. https://bugs.webkit.org/show_bug.cgi?id=155680 Reviewed by Michael Saboff. The ES6 spec states that Error.prototype should not be an instance of Error: https://tc39.github.io/ecma262/#sec-properties-of-the-error-prototype-object "The Error prototype object is an ordinary object. It is not an Error instance and does not have an [[ErrorData]] internal slot." This patch changes ErrorPrototype to conform to the above specification. * runtime/ErrorConstructor.cpp: (JSC::ErrorConstructor::finishCreation): * runtime/ErrorPrototype.cpp: (JSC::ErrorPrototype::ErrorPrototype): (JSC::ErrorPrototype::finishCreation): (JSC::ErrorPrototype::getOwnPropertySlot): * runtime/ErrorPrototype.h: (JSC::ErrorPrototype::create): * runtime/NativeErrorConstructor.cpp: (JSC::NativeErrorConstructor::finishCreation): * runtime/NativeErrorPrototype.cpp: (JSC::NativeErrorPrototype::NativeErrorPrototype): (JSC::NativeErrorPrototype::finishCreation): * runtime/NativeErrorPrototype.h: (JSC::NativeErrorPrototype::create): - updated to no longer need a JSGlobalObject argument. * tests/es6/miscellaneous_built-in_prototypes_are_not_instances.js: - updated to match the kangax version of this test. 2016-03-18 Benjamin Poulain [JSC] Limit DFG's Validate symbols to its compilation unit https://bugs.webkit.org/show_bug.cgi?id=155670 Reviewed by Filip Pizlo. * dfg/DFGValidate.cpp: 2016-03-18 Mark Lam ES6 spec requires that RegExpPrototype not be a RegExp object. https://bugs.webkit.org/show_bug.cgi?id=155654 Reviewed by Filip Pizlo. The ES6 spec states that RegExp.prototype should not be an instance of RegExp: https://tc39.github.io/ecma262/#sec-properties-of-the-regexp-prototype-object "The RegExp prototype object is an ordinary object. It is not a RegExp instance and does not have a [[RegExpMatcher]] internal slot or any of the other internal slots of RegExp instance objects." This patch changes RegExpPrototype to conform to the above specifications. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::RegExpConstructor): (JSC::RegExpConstructor::finishCreation): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::RegExpPrototype): (JSC::RegExpPrototype::finishCreation): (JSC::RegExpPrototype::getOwnPropertySlot): (JSC::RegExpPrototype::visitChildren): (JSC::regExpProtoFuncTest): * runtime/RegExpPrototype.h: (JSC::RegExpPrototype::create): (JSC::RegExpPrototype::createStructure): (JSC::RegExpPrototype::emptyRegExp): * tests/es6.yaml: - This patch makes the es6/miscellaneous_built-in_prototypes_are_not_instances.js test now pass. However, the kangax version of this test still fails because it also checks Error objects (which will be fixed in a subsequent patch). * tests/mozilla/ecma_2/shell.js: (stringify): (test): (getFailedCases): (err): * tests/stress/static-getter-in-names.js: (shouldBe): 2016-03-18 Keith Miller DataView should use an accessor for its length and buffer properties https://bugs.webkit.org/show_bug.cgi?id=155625 Reviewed by Michael Saboff. The DataView object should use an accessor on DataView.prototype for its byteLength, byteOffset, and buffer properties. This patch also, moves the buffer property off the TypedArray object itself and onto the prototype along with the other accessors. Since the .buffer property is no longer on the object, JSArrayBufferView no longer needs to intercept accesses to properties. Finally, this patch also fixes the length property on all the existing DataView.prototype functions. * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::getOwnPropertySlot): Deleted. (JSC::JSArrayBufferView::put): Deleted. (JSC::JSArrayBufferView::defineOwnProperty): Deleted. (JSC::JSArrayBufferView::deleteProperty): Deleted. (JSC::JSArrayBufferView::getOwnNonIndexPropertyNames): Deleted. * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::jsBuffer): * runtime/JSDataViewPrototype.cpp: (JSC::dataViewProtoGetterBuffer): (JSC::dataViewProtoGetterByteLength): (JSC::dataViewProtoGetterByteOffset): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoGetterFuncBuffer): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::typedArrayViewProtoGetterFuncBuffer): (JSC::JSTypedArrayViewPrototype::finishCreation): 2016-03-18 Csaba Osztrogonác Unreviewed speculative cloop buildfix after r198364. * bytecode/SuperSampler.cpp: 2016-03-17 Benjamin Poulain [JSC] Make CSE's ImpureData faster when dealing with large blocks https://bugs.webkit.org/show_bug.cgi?id=155594 Reviewed by Filip Pizlo. In some tests with large blocks, the time spent in DFG's LocalCSE can be over 10% of the total compile time. In those cases, LocalCSE is completely dominated by handling large blocks. This patch addresses the most obvious hot spots ImpureData's handling. Initially, most of the time was going into HashTable::rehash(). The reason is the buckets are gigantic. The hash table would easily get into several kilobytes and the CPU was spending more time dealing with memory than anything. To solve that, I moved the pairs lazily to the heap. The table itself just contains the unique_ptr to those values. This makes the table reasonably small and the alloc/dealloc are paid for by the fast rehash(). Once addImpure() was better, the next big bottleneck was clobber(). For each clobber(), we need to go over the entire map and test each value. That loop was where most of the time was going. Most calls to clobber() come from two kinds: SideState and Stack. SideState is easy: it is never def'ed so we can always skip it. Stack is disjoint from Heap too so we can also put it separately. Splitting the map into 2 helped reduce the overhead. The maps are: -Stack -Heap Having Stack alone was not enough for many blocks. In some cases, you have a ton of SetLocal/GetLocal and having Stack separately makes no difference. To solve that, I split Stack in two: a map addressed by AbstractHeap + unique HeapLocation and a fallback map for everything else. Since most Stack are not TOP and are unique per AbstractHeap, I get O(1) clobber in most cases. I could achieve the same result with a custom hash structure. I don't think it is worth the effort, in most cases, m_fallbackStackMap has a size of zero or one. This patch introduces a lot of coupling between CSE and AbstractHeap. To reduce the risk of bugs, the old map is still maintained in debug and each step checks that the results are the same as the new implementation. A new validation step also verify the strong assumptions made by CSE: -SideState and World are never def(). -We never write HEAP TOP, we only write specific heap location. * dfg/DFGCSEPhase.cpp: * dfg/DFGHeapLocation.h: * dfg/DFGLazyNode.h: (JSC::DFG::LazyNode::hash): 2016-03-17 Saam barati Implement SmallPtrSet and integrate it into the Parser https://bugs.webkit.org/show_bug.cgi?id=155552 Reviewed by Filip Pizlo. Using SmallPtrSet instead of HashSet really helps speed up the parser. What saves us most is not needing to always malloc/free memory in the HashSet. * parser/Parser.cpp: (JSC::Parser::parseInner): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::startSwitch): (JSC::Scope::endSwitch): (JSC::Scope::startLoop): (JSC::Scope::hasDeclaredParameter): (JSC::Scope::declareWrite): (JSC::Scope::declareParameter): (JSC::Scope::usedVariablesContains): (JSC::Scope::useVariable): (JSC::Scope::collectFreeVariables): (JSC::Scope::getCapturedVars): (JSC::Scope::isValidStrictMode): (JSC::Scope::shadowsArguments): (JSC::Scope::copyCapturedVariablesToVector): (JSC::Scope::setIsModule): (JSC::Parser::pushScope): (JSC::Scope::getUsedVariables): Deleted. 2016-03-17 Brian Burg Web Inspector: protocol generator shouldn't generate enums for parameters with non-anonymous enum types https://bugs.webkit.org/show_bug.cgi?id=155610 Reviewed by Joseph Pecoraro. If a command parameter has an anonymous enum type, the backend dispatcher generator makes a C++ enum for the parameter. However, if the parameter references a named enum type specified in a domain's 'type' section, then there's no need to generate an enum. * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: (CppBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command): Add a missing check for the is_anonymous flag. Type references to named enums are resolved to the underlying aliased EnumType instead of an AliasedType, so we have to check the flag. Rebaseline tests. * inspector/scripts/tests/expected/commands-with-async-attribute.json-result: * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result: 2016-03-17 Filip Pizlo Replace all of the various non-working and non-compiling sampling profiler hacks with a single super hack https://bugs.webkit.org/show_bug.cgi?id=155561 Reviewed by Saam Barati. A VM needs some internal profiling hacks in addition to the profiler(s) that the user sees, because you can squeeze out more fidelity if you're willing to make some kind of deal with the devil. Prior to this change JSC had a bunch of these: - CodeBlock sampling profiler - Bytecode sampling profiler - Sampling flags - Sampling regions - Some other stuff I tried using these recently. They didn't even build. Initially I fixed that, but then I found that these profilers had some serious bugs that made them report bogus results - like underreporting the time spent in regions of code by more than 2x. Part of the problem here is that a profiler loses fidelity as it gains power. The more general it tries to be, the more code gets executed on the hot path for the profiler, which increasingly perturbs the results. I believe that's the reason for the underreporting - code ran sufficiently slower, and in a sufficiently different way when profiling, that the results were just wrong. This change attacks this problem directly by replacing all of the diverse profiling hacks with just one, which I call the SuperSampler. It consists of exactly one counter. When enabled, the sampler will periodically print (via dataLog()) the percentage of samples that saw a non-zero count. Because it's so simple, it gives better accuracy. This comes about in two ways: - It runs at a lower rate. That's fine since it's only checking one flag. You don't need a high rate for just one flag. - The fact that there is only *one* flag means that the user must choose a hypothesis about what is slow. This turns the problem of profiling into a hypothesis testing problem, which is an inherently less flaky kind of experiment to run. The SuperSampler is enabled with a runtime flag rather than a compile-time flag, so it's much less likely to break. That also means that you can enable it without rebuilding the universe. The old samplers all had ENABLE flags in Platform.h, which was rather unfortunate for compile times. SuperSampler supports both JIT and C++ users. C++ users should use SuperSamplerScope. The default idiom is to create one and pass "true" to it. You can disable a scope by passing "false" instead. This patch puts a bunch of scopes in places I care about. I think it's probably OK if people check in these deactivated scopes. That makes it convenient to retest things we've tested previously. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/SamplingTool.cpp: Removed. * bytecode/SamplingTool.h: Removed. * bytecode/SuperSampler.cpp: Added. (JSC::initializeSuperSampler): (JSC::printSuperSamplerState): * bytecode/SuperSampler.h: Added. (JSC::SuperSamplerScope::SuperSamplerScope): (JSC::SuperSamplerScope::~SuperSamplerScope): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): * bytecompiler/NodesCodegen.cpp: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::forAllValues): (JSC::DFG::AbstractInterpreter::clobberStructures): * dfg/DFGArgumentsEliminationPhase.cpp: (JSC::DFG::performArgumentsElimination): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::performBackwardsPropagation): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::parse): * dfg/DFGCFAPhase.cpp: (JSC::DFG::performCFA): * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::performCFGSimplification): * dfg/DFGCPSRethreadingPhase.cpp: (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes): (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlocks): (JSC::DFG::CPSRethreadingPhase::propagatePhis): (JSC::DFG::performCPSRethreading): * dfg/DFGCSEPhase.cpp: (JSC::DFG::performLocalCSE): (JSC::DFG::performGlobalCSE): * dfg/DFGCleanUpPhase.cpp: (JSC::DFG::performCleanUp): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::performConstantFolding): * dfg/DFGConstantHoistingPhase.cpp: (JSC::DFG::performConstantHoisting): * dfg/DFGCriticalEdgeBreakingPhase.cpp: (JSC::DFG::performCriticalEdgeBreaking): * dfg/DFGDCEPhase.cpp: (JSC::DFG::performDCE): * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGFixupPhase.cpp: (JSC::DFG::performFixup): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dethread): * dfg/DFGIntegerCheckCombiningPhase.cpp: (JSC::DFG::performIntegerCheckCombining): * dfg/DFGIntegerRangeOptimizationPhase.cpp: (JSC::DFG::performIntegerRangeOptimization): * dfg/DFGInvalidationPointInjectionPhase.cpp: (JSC::DFG::performInvalidationPointInjection): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGLICMPhase.cpp: (JSC::DFG::performLICM): * dfg/DFGLiveCatchVariablePreservationPhase.cpp: (JSC::DFG::performLiveCatchVariablePreservationPhase): * dfg/DFGLivenessAnalysisPhase.cpp: (JSC::DFG::performLivenessAnalysis): * dfg/DFGLoopPreHeaderCreationPhase.cpp: (JSC::DFG::performLoopPreHeaderCreation): * dfg/DFGMaximalFlushInsertionPhase.cpp: (JSC::DFG::performMaximalFlushInsertion): * dfg/DFGMovHintRemovalPhase.cpp: (JSC::DFG::performMovHintRemoval): * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::performOSRAvailabilityAnalysis): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::performOSREntrypointCreation): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGObjectAllocationSinkingPhase.cpp: (JSC::DFG::performObjectAllocationSinking): * dfg/DFGOperations.cpp: * dfg/DFGPhantomInsertionPhase.cpp: (JSC::DFG::performPhantomInsertion): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThread): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::performPredictionInjection): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::performPredictionPropagation): * dfg/DFGPutStackSinkingPhase.cpp: (JSC::DFG::performPutStackSinking): * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::performSSAConversion): * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::performSSALowering): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::performStackLayout): * dfg/DFGStaticExecutionCountEstimationPhase.cpp: (JSC::DFG::performStaticExecutionCountEstimation): * dfg/DFGStoreBarrierInsertionPhase.cpp: (JSC::DFG::performFastStoreBarrierInsertion): (JSC::DFG::performGlobalStoreBarrierInsertion): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::performStrengthReduction): * dfg/DFGStructureAbstractValue.cpp: (JSC::DFG::StructureAbstractValue::assertIsRegistered): (JSC::DFG::StructureAbstractValue::clobber): (JSC::DFG::StructureAbstractValue::observeTransition): (JSC::DFG::StructureAbstractValue::observeTransitions): (JSC::DFG::StructureAbstractValue::add): (JSC::DFG::StructureAbstractValue::merge): (JSC::DFG::StructureAbstractValue::mergeSlow): (JSC::DFG::StructureAbstractValue::mergeNotTop): (JSC::DFG::StructureAbstractValue::filter): (JSC::DFG::StructureAbstractValue::filterSlow): (JSC::DFG::StructureAbstractValue::contains): (JSC::DFG::StructureAbstractValue::isSubsetOf): (JSC::DFG::StructureAbstractValue::isSupersetOf): (JSC::DFG::StructureAbstractValue::overlaps): (JSC::DFG::StructureAbstractValue::equalsSlow): * dfg/DFGStructureRegistrationPhase.cpp: (JSC::DFG::performStructureRegistration): * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::performTierUpCheckInjection): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::performTypeCheckHoisting): * dfg/DFGUnificationPhase.cpp: (JSC::DFG::performUnification): * dfg/DFGVarargsForwardingPhase.cpp: (JSC::DFG::performVarargsForwarding): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::performVirtualRegisterAllocation): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::performWatchpointCollection): * dynbench.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec): (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest): (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace): (JSC::FTL::DFG::LowerDFGToB3::compileGetRegExpObjectLastIndex): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileFTLOSRExit): * ftl/FTLOutput.cpp: (JSC::FTL::Output::store): (JSC::FTL::Output::absolute): (JSC::FTL::Output::incrementSuperSamplerCount): (JSC::FTL::Output::decrementSuperSamplerCount): * ftl/FTLOutput.h: (JSC::FTL::Output::baseIndex): (JSC::FTL::Output::load8SignExt32): (JSC::FTL::Output::load8ZeroExt32): (JSC::FTL::Output::anchor): (JSC::FTL::Output::absolute): Deleted. * heap/Heap.cpp: (JSC::Heap::markRoots): (JSC::Heap::collectAndSweep): (JSC::Heap::collectImpl): (JSC::Heap::zombifyDeadObjects): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::specializedSweep): * interpreter/Interpreter.cpp: (JSC::setupVarargsFrameAndSetThis): (JSC::Interpreter::Interpreter): (JSC::Interpreter::initialize): (JSC::checkedReturn): (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::debug): (JSC::SamplingScope::SamplingScope): Deleted. (JSC::SamplingScope::~SamplingScope): Deleted. (JSC::Interpreter::enableSampler): Deleted. (JSC::Interpreter::dumpSampleData): Deleted. (JSC::Interpreter::startSampling): Deleted. (JSC::Interpreter::stopSampling): Deleted. * interpreter/Interpreter.h: (JSC::Interpreter::isCallBytecode): (JSC::Interpreter::sampler): Deleted. * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::branchIfNotFastTypedArray): (JSC::AssemblyHelpers::incrementSuperSamplerCount): (JSC::AssemblyHelpers::decrementSuperSamplerCount): (JSC::AssemblyHelpers::purifyNaN): * jit/AssemblyHelpers.h: * jit/JIT.cpp: * jit/JIT.h: * jit/JITArithmetic.cpp: * jit/JITArithmetic32_64.cpp: * jit/JITCall.cpp: * jit/JITCall32_64.cpp: * jit/JITOperations.cpp: * jit/JITPropertyAccess.cpp: * jit/JITPropertyAccess32_64.cpp: * jsc.cpp: (runWithScripts): (jscmain): * parser/Nodes.cpp: * parser/Parser.h: (JSC::parse): * runtime/Executable.h: * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/Options.h: * runtime/RegExpCachedResult.h: * runtime/RegExpMatchesArray.h: (JSC::createRegExpMatchesArray): * runtime/StringPrototype.cpp: (JSC::removeUsingRegExpSearch): (JSC::stringProtoFuncSubstring): * runtime/VM.cpp: (JSC::VM::resetDateCache): (JSC::VM::whenIdle): (JSC::VM::deleteAllCode): (JSC::VM::addSourceProviderCache): (JSC::VM::startSampling): Deleted. (JSC::VM::stopSampling): Deleted. (JSC::VM::dumpSampleData): Deleted. * runtime/VM.h: (JSC::VM::regExpCache): * testRegExp.cpp: (runFromFiles): * yarr/YarrInterpreter.cpp: (JSC::Yarr::interpret): 2016-03-17 Saam barati [ES6] Make GetProperty(.) inside ArrayPrototype.cpp spec compatible. https://bugs.webkit.org/show_bug.cgi?id=155575 Reviewed by Filip Pizlo and Mark Lam. This patch makes various Array.prototype.(shift | unshift | splice) spec compliant. Before, they were performing Get and HasProperty as one operation. Instead, they need to be performed as two distinct operations when it would be observable. * runtime/ArrayPrototype.cpp: (JSC::getProperty): * runtime/PropertySlot.h: (JSC::PropertySlot::PropertySlot): (JSC::PropertySlot::isCacheableValue): (JSC::PropertySlot::isCacheableGetter): (JSC::PropertySlot::isCacheableCustom): (JSC::PropertySlot::setIsTaintedByProxy): (JSC::PropertySlot::isTaintedByProxy): (JSC::PropertySlot::internalMethodType): (JSC::PropertySlot::getValue): * runtime/ProxyObject.cpp: (JSC::ProxyObject::getOwnPropertySlotCommon): * tests/es6.yaml: * tests/stress/proxy-array-prototype-methods.js: Added. (assert): (test): (shallowEq): 2016-03-17 Mark Lam Make FunctionMode an enum class. https://bugs.webkit.org/show_bug.cgi?id=155587 Reviewed by Saam Barati. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): * parser/NodeConstructors.h: (JSC::BaseFuncExprNode::BaseFuncExprNode): (JSC::FuncExprNode::FuncExprNode): (JSC::FuncDeclNode::FuncDeclNode): (JSC::ArrowFuncExprNode::ArrowFuncExprNode): (JSC::MethodDefinitionNode::MethodDefinitionNode): * parser/ParserModes.h: (JSC::functionNameIsInScope): 2016-03-17 Michael Saboff [ES6] Getters and Setters should be prefixed appropriately https://bugs.webkit.org/show_bug.cgi?id=155593 Reviewed by Mark Lam. Changed the putDirectNativeIntrinsicGetter() to prepend "get " to the funtion name. Updated places that had their own macro or hand constructed a getter function to use the JSC_NATIVE_GETTER macro which will properly append "get ". Prepended "get " and "set " to the __proto__ accessor created on the Object prototype. When we create the Symbol.species getter, added an explicit function name of "get [Symbol.species]". * inspector/JSInjectedScriptHostPrototype.cpp: (Inspector::JSInjectedScriptHostPrototype::finishCreation): (Inspector::jsInjectedScriptHostPrototypeAttributeEvaluate): * inspector/JSJavaScriptCallFramePrototype.cpp: (Inspector::JSJavaScriptCallFramePrototype::finishCreation): (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluate): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSObject.cpp: (JSC::JSObject::putDirectNativeIntrinsicGetter): * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): (JSC::MapPrototype::getOwnPropertySlot): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): (JSC::SetPrototype::getOwnPropertySlot): * tests/stress/accessors-get-set-prefix.js: Added. (tryGetOwnPropertyDescriptorGetName): 2016-03-16 Mark Lam Method names should not appear in the lexical scope of the method's body. https://bugs.webkit.org/show_bug.cgi?id=155568 Reviewed by Saam Barati. Consider this scenario: var f = "foo"; var result = ({ f() { return f; // f should be the string "foo", not this method f. } }).f(); result === "foo"; // Should be true. The reason this is not current working is because the parser does not yet distinguish between FunctionExpressions and MethodDefinitions. The ES6 spec explicitly distinguishes between the 2, and we should do the same. This patch changes all methods (and getters and setters which are also methods) to have a FunctionMode of MethodDefinition (instead of FunctionExpression). functionNameIsInScope() is responsible for determining whether a function's name should be in its scope or not. It already returns false for any function whose FunctionMode is not FunctionExpression. Giving methods the MethodDefinition FunctionMode gets us the correct behavior ES6 expects. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): * bytecode/UnlinkedFunctionExecutable.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitNewArrowFunctionExpression): (JSC::BytecodeGenerator::emitNewMethodDefinition): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::ArrowFuncExprNode::emitBytecode): (JSC::MethodDefinitionNode::emitBytecode): (JSC::YieldExprNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createFunctionExpr): (JSC::ASTBuilder::createMethodDefinition): (JSC::ASTBuilder::createFunctionMetadata): (JSC::ASTBuilder::createGetterOrSetterProperty): (JSC::ASTBuilder::createArguments): * parser/NodeConstructors.h: (JSC::FunctionParameters::FunctionParameters): (JSC::BaseFuncExprNode::BaseFuncExprNode): (JSC::FuncExprNode::FuncExprNode): (JSC::FuncDeclNode::FuncDeclNode): (JSC::ArrowFuncExprNode::ArrowFuncExprNode): (JSC::MethodDefinitionNode::MethodDefinitionNode): (JSC::YieldExprNode::YieldExprNode): * parser/Nodes.h: (JSC::BaseFuncExprNode::metadata): * parser/Parser.cpp: (JSC::Parser::parseClass): (JSC::Parser::parsePropertyMethod): * parser/ParserModes.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createFunctionExpr): (JSC::SyntaxChecker::createFunctionMetadata): (JSC::SyntaxChecker::createArrowFunctionExpr): (JSC::SyntaxChecker::createMethodDefinition): (JSC::SyntaxChecker::setFunctionNameStart): (JSC::SyntaxChecker::createArguments): * tests/es6.yaml: 2016-03-17 Yusuke Suzuki REGRESSION(r197380): Build fails with new GCC and Clang https://bugs.webkit.org/show_bug.cgi?id=155044 Reviewed by Michael Catanzaro. In C++, std math functions ceil and floor are overloaded for double and float. Without explicit cast or function pointer assignment, compilers cannot determine which function address is used in the given context. * b3/B3LowerMacrosAfterOptimizations.cpp: 2016-03-17 Skachkov Oleksandr Invoking super()/super inside of the eval should not lead to SyntaxError https://bugs.webkit.org/show_bug.cgi?id=153864 Reviewed by Saam Barati. Added support of the invoking super/super() inside of the eval within class. Also support cases when eval is invoked in constructor, class method directly or via arrow function. Access to the new.target in eval is not part of this patch and will be implemented in https://bugs.webkit.org/show_bug.cgi?id=155545 * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction): (JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction): (JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction): (JSC::BytecodeGenerator::isSuperCallUsedInInnerArrowFunction): (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope): * interpreter/Interpreter.cpp: (JSC::eval): * parser/Parser.cpp: (JSC::Parser::Parser): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseMemberExpression): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::isEvalContext): (JSC::Scope::setIsEvalContext): (JSC::parse): * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): * tests/stress/arrowfunction-lexical-bind-supercall-4.js: * tests/stress/arrowfunction-lexical-bind-superproperty.js: * tests/stress/class-syntax-super-in-eval.js: Added. * tests/stress/generator-with-super.js: 2016-03-15 Filip Pizlo ASSERTION FAILED: !edge->isPhantomAllocation() in regress/script-tests/sink-huge-activation.js.ftl-eager in debug mode https://bugs.webkit.org/show_bug.cgi?id=153805 Reviewed by Mark Lam. The object allocation sinking phase uses InferredValue::isStillValid() in the opposite way from most clients: it will do an *extra* optimization if it returns false. The phase will first compute sink candidates and then it will compute materialization points. If something is a sink candidate then it is not a materialization point. A NewFunction node may appear as not being a sink candidate during the first pass, so it's not added to the set of things that will turn into PhantomNewFunction. But on the second pass where we add materializations, we check isStillValid() again. Now this may become false, so that second pass thinks that NewFunction is a sink candidate (even though it's not in the sink candidates set) and so is not a materialization point. This manifests as the NewFunction referring to a PhantomCreateActivation or whatever. The solution is to have the phase cache results of calls to isStillValid(). It's OK if we just remember the result of the first call and assume that it's not a sink candidate. That's the worst that can happen. No new tests since this is a super hard race and sink-huge-activation seemed to already be catching it. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2016-03-16 Saam Barati [ES6] Make Array.prototype.reverse spec compatible. https://bugs.webkit.org/show_bug.cgi?id=155528 Reviewed by Michael Saboff. This patch make Array.prototype.reverse spec compatible. Before, we weren't performing a HasProperty of each index before performing a Get on that index. We now do that on the slow path. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncReverse): * tests/stress/array-reverse-proxy.js: Added. (assert): (test): (shallowCopy): (shallowEqual): (let.handler.get getSet): (test.let.handler.get getSet): 2016-03-16 Chris Dumez Unreviewed, rolling out r198235, r198240, r198241, and r198252. Causing crashes on ARM Reverted changesets: "Remove compile time define for SEPARATED_HEAP" https://bugs.webkit.org/show_bug.cgi?id=155508 http://trac.webkit.org/changeset/198235 "Gardening: build fix after r198235." http://trac.webkit.org/changeset/198240 "Build fix." http://trac.webkit.org/changeset/198241 "Rename performJITMemcpy to something more inline with our normal webkit function names" https://bugs.webkit.org/show_bug.cgi?id=155525 http://trac.webkit.org/changeset/198252 2016-03-16 Brian Burg Unreviewed, rolling out r198257. https://bugs.webkit.org/show_bug.cgi?id=155553 This change is unnecessary, clients can instead compile the file with ARC enabled (Requested by brrian on #webkit). Reverted changeset: "REGRESSION(r198077): generated Objective-C protocol object getters leak their wrappers" https://bugs.webkit.org/show_bug.cgi?id=155523 http://trac.webkit.org/changeset/198257 2016-03-16 Mark Lam Add support for setting Function.name from computed properties. https://bugs.webkit.org/show_bug.cgi?id=155437 Reviewed by Filip Pizlo. In JS code, we can have initialization of computed properties with function and class objects e.g. var o = { [x]: function() {}, [y]: class {} } The ES6 spec states that the function and class in the example above (being anonymous) should take on the value of x and y respectively as their names: o[x].name; // should be the "stringified" value of x. o[y].name; // should be the "stringified" value of y. To achieve this, we will now inject an op_set_function_name bytecode at property initialization sites if: 1. the property assigned value is a function or class, and 2. the function and class is anonymous, and 3. if property assigned value is a class, it doesn't have a static method that is statically named "name". The op_set_function_name will result in JSFunction::setFunctionName() being called on the target function / class before it is assigned to the property. JSFunction::setFunctionName() will take care of: 1. computing the name to use from the value of the computed property name e.g. x and y in the example above. If the computed property name is not a symbol, then the function / class name should be the toString() value of that computed property name. If the computed property name is a symbol, then ... a. if the Symbol has a defined description (e.g. Symbol("foo")), then the function / class name should be "[]" e.g. "[foo]". b. if the Symbol has an undefined description (e.g. Symbol()), then the function / class name should be "". Note: Symbol("") is not the same as Symbol(). The former has a defined descriptor "", and hence, yields a function / class name of "[]". The latter yields a function / class name of "". 2. reifying the lazy name property with this function / class name. op_set_function_name is named after the SetFunctionName internal function in the ES6 spec that performs the above operation. It is behaviorally correct to use op_set_function_name at every property initialization site with computed property names. However, we choose to not emit the op_set_function_name bytecode when we already know that it will do nothing i.e. when the target function / class is proven to already have a name or name property. This is done as an optimization to avoid unnecessary calls to JSFunction::setFunctionName(). Note: we could further check if the class has a static method with a computed name that is a constant string "name" and elide op_set_function_name there too. However, we don't bother because this should be rare. JSFunction::setFunctionName() will still do the right thing. * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitNewFunction): (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded): (JSC::BytecodeGenerator::emitCall): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::PropertyListNode::emitBytecode): (JSC::PropertyListNode::emitPutConstantProperty): * 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/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewFunction): (JSC::DFG::SpeculativeJIT::compileSetFunctionName): (JSC::DFG::SpeculativeJIT::compileForwardVarargs): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStoreBarrierInsertionPhase.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp): (JSC::FTL::DFG::LowerDFGToB3::compileSetFunctionName): (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_strcat): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emitSlow_op_to_primitive): (JSC::JIT::emit_op_set_function_name): (JSC::JIT::emit_op_strcat): * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): (JSC::LLInt::handleHostCall): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * parser/Nodes.cpp: (JSC::FunctionNode::finishParsing): (JSC::PropertyListNode::hasStaticallyNamedProperty): (JSC::VariableEnvironmentNode::VariableEnvironmentNode): * parser/Nodes.h: * runtime/JSFunction.cpp: (JSC::getCalculatedDisplayName): (JSC::JSFunction::setFunctionName): (JSC::JSFunction::reifyLength): (JSC::JSFunction::reifyName): * runtime/JSFunction.h: * tests/es6.yaml: * tests/stress/computed-function-names.js: Added. (toKeyString): (toFuncName): (shouldBe): (return.propKey): 2016-03-16 Yusuke Suzuki [ES6] Reflect.set with receiver https://bugs.webkit.org/show_bug.cgi?id=155294 Reviewed by Saam Barati. This patch introduces the receiver parameter support for Reflect.set. Reflect.set can alter the receiver with arbitrary values. Each property descriptor uses the receiver in [[Set]]. 1) In the accessor descriptor case, the receiver is used as |this| value for setter calls. 2) In the data descriptor case, the actual property will be set onto the receiver objects. The current put operation does not support the receiver that is different from the base object. In particular, (2) case is not supported. The naive implementation adds one more [[GetOwnProperty]] for the receiver per [[Set]] (9.1.9.1-4-c [1]), and it is unacceptable. To keep the fast path efficiently, we fall back to the slow but generic implementation (ordinarySetSlow) only when the receiver is altered. We need not to change any JIT part, because the JS code cannot alter the receiver without Reflect.set. The property accesses generated by the JIT code always have the receiver that is the same to the base object. ProxyObject can alter the receiver, but this situation has no problem because ProxyObject disables Inline Caching. NOTE: Generating Inline Caching for JSProxy (that is used for the Window proxy) is already disabled before this change. [1]: https://tc39.github.io/ecma262/#sec-ordinaryset * jsc.cpp: (functionCreateProxy): * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::put): * runtime/JSArray.cpp: (JSC::JSArray::put): * runtime/JSArrayBuffer.cpp: (JSC::JSArrayBuffer::put): * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::put): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::isThisValueAltered): * runtime/JSDataView.cpp: (JSC::JSDataView::put): * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::put): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::put): * runtime/JSObject.cpp: (JSC::ordinarySetSlow): (JSC::JSObject::putInlineSlow): * runtime/JSObject.h: * runtime/JSObjectInlines.h: (JSC::JSObject::putInline): * runtime/JSProxy.h: (JSC::JSProxy::createStructure): * runtime/Lookup.h: (JSC::putEntry): * runtime/PropertySlot.h: * runtime/ProxyObject.cpp: (JSC::ProxyObject::put): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::isCacheablePut): (JSC::PutPropertySlot::isCacheableSetter): (JSC::PutPropertySlot::isCacheableCustom): (JSC::PutPropertySlot::isCustomAccessor): (JSC::PutPropertySlot::disableCaching): (JSC::PutPropertySlot::isCacheable): * runtime/ReflectObject.cpp: (JSC::reflectObjectSet): * runtime/RegExpObject.cpp: (JSC::RegExpObject::put): (JSC::reject): Deleted. * runtime/StringObject.cpp: (JSC::StringObject::put): * tests/es6.yaml: * tests/stress/ordinary-set-exceptions.js: Added. (shouldBe): (shouldThrow): (shouldThrow.set get var): * tests/stress/proxy-set.js: * tests/stress/reflect-set-proxy-set.js: Copied from Source/JavaScriptCore/tests/stress/proxy-set.js. (shouldBe): (unreachable): (assert): (throw.new.Error.let.handler.set 45): (throw.new.Error): (let.target.set x): (let.target.get x): (set let): * tests/stress/reflect-set-receiver-proxy-set.js: Added. (shouldBe): (unreachable): (assert): (let.handler.set 45): (catch): (let.target.set x): (let.target.get x): (set let): * tests/stress/reflect-set-with-global-proxy.js: Added. (shouldBe): (unreachable): (get shouldBe): (set shouldBe): (set test1): (set test2): (set test3): * tests/stress/reflect-set.js: (shouldThrow): (unreachable): (get shouldBe): (set shouldBe): (receiverTestIndexed): (set get Uint8Array): (receiverCase): Deleted. (proxyCase): Deleted. (stringObjectCase.set get shouldBe): Deleted. (regExpLastIndex): Deleted. 2016-03-15 Benjamin Poulain [JSC] Remove hint from SlowCaseEntry https://bugs.webkit.org/show_bug.cgi?id=155530 Reviewed by Alex Christensen. * jit/JIT.h: (JSC::SlowCaseEntry::SlowCaseEntry): 2016-03-15 Brian Burg REGRESSION(r198077): generated Objective-C protocol object getters leak their wrappers https://bugs.webkit.org/show_bug.cgi?id=155523 Reviewed by Joseph Pecoraro. Since the code may not be compiled with ARC, autorelease the returned wrapper. * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator.protocol_to_objc_expression_for_member): * inspector/scripts/tests/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result: 2016-03-15 Benjamin Poulain [JSC] Help clang generate better code on arrayProtoFuncToString() https://bugs.webkit.org/show_bug.cgi?id=155512 Reviewed by Mark Lam. 3d-raytrace hits Array.toString() hard with small arrays. Half of the time is going into overhead around the StringJoiner. This patch makes the function shorter and the layout better. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncToString): Add "UNLIKELY" on rare cases. Clang pushes that code to the tail. Factor the code of jsMakeNontrivialString() so that the operation is not duplicated in the function. * runtime/JSStringBuilder.h: (JSC::jsMakeNontrivialString): jsNontrivialString() supports r-value reference. Move the result string into jsNontrivialString(), this removes the deref+destructor from the function. * runtime/JSStringJoiner.cpp: (JSC::JSStringJoiner::~JSStringJoiner): The destructor is pretty large. No point in inlining it. (JSC::joinStrings): * runtime/JSStringJoiner.h: (JSC::JSStringJoiner::JSStringJoiner): (JSC::JSStringJoiner::append): The calls were duplicated. That's unnecessary. * runtime/NumericStrings.h: (JSC::NumericStrings::add): Return a reference in all cases. This removes a deref+destructor. 2016-03-15 Joseph Pecoraro Remove stale ArrayPrototype declarations https://bugs.webkit.org/show_bug.cgi?id=155520 Reviewed by Mark Lam. * runtime/ArrayPrototype.cpp: The implementations went away when the methods were moved to builtins but the declarations were left behind. 2016-03-15 Oliver Hunt Rename performJITMemcpy to something more inline with our normal webkit function names https://bugs.webkit.org/show_bug.cgi?id=155525 Reviewed by Saam Barati. Simple bulk search/replace with a better name. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::fillNops): (JSC::ARM64Assembler::replaceWithJump): (JSC::ARM64Assembler::replaceWithLoad): (JSC::ARM64Assembler::replaceWithAddressComputation): (JSC::ARM64Assembler::setPointer): (JSC::ARM64Assembler::repatchInt32): (JSC::ARM64Assembler::repatchCompact): (JSC::ARM64Assembler::linkJumpOrCall): (JSC::ARM64Assembler::linkCompareAndBranch): (JSC::ARM64Assembler::linkConditionalBranch): (JSC::ARM64Assembler::linkTestAndBranch): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): * jit/ExecutableAllocator.h: (JSC::writeToExecutableRegion): (JSC::performJITMemcpy): Deleted. 2016-03-15 Oliver Hunt Build fix. * jit/ExecutableAllocatorFixedVMPool.cpp: 2016-03-15 Mark Lam Gardening: build fix after r198235. Not Reviewed. * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator): 2016-03-15 Oliver Hunt Remove compile time define for SEPARATED_HEAP https://bugs.webkit.org/show_bug.cgi?id=155508 Reviewed by Mark Lam. This removes the compile time define for the SEPARATED_HEAP feature, and moves to a default-off runtime preference. This happily also removes the need for world rebuilds while bringing it up on different platforms. * Configurations/FeatureDefines.xcconfig: * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): * 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-03-15 Commit Queue Unreviewed, rolling out r198148. https://bugs.webkit.org/show_bug.cgi?id=155518 "Lets do this patch at a later time" (Requested by saamyjoon on #webkit). Reverted changeset: "[ES6] Disallow var assignments in for-in loops" https://bugs.webkit.org/show_bug.cgi?id=155451 http://trac.webkit.org/changeset/198148 2016-03-15 Joseph Pecoraro REGRESSION: ASSERTION FAILED: !m_lastActiveBlock on js/function-apply.html https://bugs.webkit.org/show_bug.cgi?id=155411 Reviewed by Mark Lam. * heap/Heap.cpp: (JSC::Heap::collectImpl): (JSC::Heap::didFinishCollection): During collection allocators are stop/reset. The HeapProfiler tasks were using HeapIterationScope (to satisfy MarkedSpace forEachCell API contracts) which was doing its own stop/resume of allocators. Doing a stop/resume in between the normal stop/reset of collection is unexpected. Move this to didFinishCollection, alongside other heap iterations like zombies and immortal objects. Putting this after those tasks also means the heap snapshots will respect the zombies/immortal options when deciding if the cell is alive or not. 2016-03-15 Saam Barati We should have different JSTypes for JSGlobalLexicalEnvironment and JSLexicalEnvironment and JSModuleEnvironment https://bugs.webkit.org/show_bug.cgi?id=152406 Reviewed by Mark Lam. This makes testing for a JSGlobalLexicalEnvironment faster because we can just check the Cell's type instead of using jsDynamicCast. I also changed code that does jsDynamicCast instead of isGlobalObject(). * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: (JSC::CommonSlowPaths::tryCachePutToScopeGlobal): (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): * runtime/JSGlobalLexicalEnvironment.h: (JSC::JSGlobalLexicalEnvironment::createStructure): * runtime/JSLexicalEnvironment.h: (JSC::JSLexicalEnvironment::createStructure): (JSC::JSLexicalEnvironment::JSLexicalEnvironment): * runtime/JSModuleEnvironment.h: (JSC::JSModuleEnvironment::createStructure): (JSC::JSModuleEnvironment::offsetOfModuleRecord): * runtime/JSObject.h: (JSC::JSObject::isGlobalObject): (JSC::JSObject::isJSLexicalEnvironment): (JSC::JSObject::isGlobalLexicalEnvironment): (JSC::JSObject::isErrorInstance): * runtime/JSScope.cpp: (JSC::abstractAccess): (JSC::isUnscopable): (JSC::JSScope::resolve): (JSC::JSScope::collectVariablesUnderTDZ): (JSC::JSScope::isVarScope): (JSC::JSScope::isLexicalScope): (JSC::JSScope::isModuleScope): (JSC::JSScope::isCatchScope): (JSC::JSScope::isFunctionNameScopeObject): (JSC::JSScope::isNestedLexicalScope): (JSC::JSScope::constantScopeForCodeBlock): (JSC::isScopeType): Deleted. (JSC::JSScope::isGlobalLexicalEnvironment): Deleted. * runtime/JSScope.h: * runtime/JSType.h: 2016-03-15 Filip Pizlo Remove the Baker barrier from JSC https://bugs.webkit.org/show_bug.cgi?id=155479 Reviewed by Saam Barati. It's been a while since I added a Baker barrier, but I never followed it up with an actual concurrent GC. While thinking about the GC, I became convinced that the right path forward is to do a non-copying concurrent GC. That is, remove the copied space and just use the marked space. The downside of using marked space cannot be more than the overhead of the Baker barrier, so concurrent non-copying GC is definitely better than copying non-concurrent GC. I also suspect that just plain non-copying non-concurrent GC is going to be fine also, so the path forward will probably be to first just remove CopiedSpace. Anyway, for now this patch just removes the Baker barrier. It was a cute implementation but it just cost performance and I don't think we'll ever use it. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generate): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGCopyBarrierOptimizationPhase.cpp: Removed. * dfg/DFGCopyBarrierOptimizationPhase.h: Removed. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): (JSC::DFG::SpeculativeJIT::compileGetButterfly): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileGetButterfly): (JSC::FTL::DFG::LowerDFGToB3::compileConstantStoragePointer): (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage): (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray): (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset): (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset): (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset): (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname): (JSC::FTL::DFG::LowerDFGToB3::storageForTransition): (JSC::FTL::DFG::LowerDFGToB3::getById): (JSC::FTL::DFG::LowerDFGToB3::isFastTypedArray): (JSC::FTL::DFG::LowerDFGToB3::compileGetButterflyReadOnly): Deleted. (JSC::FTL::DFG::LowerDFGToB3::loadButterflyWithBarrier): Deleted. (JSC::FTL::DFG::LowerDFGToB3::loadVectorWithBarrier): Deleted. (JSC::FTL::DFG::LowerDFGToB3::copyBarrier): Deleted. (JSC::FTL::DFG::LowerDFGToB3::isInToSpace): Deleted. (JSC::FTL::DFG::LowerDFGToB3::loadButterflyReadOnly): Deleted. (JSC::FTL::DFG::LowerDFGToB3::loadVectorReadOnly): Deleted. (JSC::FTL::DFG::LowerDFGToB3::removeSpaceBits): Deleted. * heap/CopyBarrier.h: (JSC::CopyBarrierBase::CopyBarrierBase): (JSC::CopyBarrierBase::operator bool): (JSC::CopyBarrierBase::get): (JSC::CopyBarrierBase::clear): (JSC::CopyBarrierBase::setWithoutBarrier): (JSC::CopyBarrier::CopyBarrier): (JSC::CopyBarrier::get): (JSC::CopyBarrier::set): (JSC::CopyBarrier::setWithoutBarrier): (JSC::CopyBarrierBase::operator!): Deleted. (JSC::CopyBarrierBase::getWithoutBarrier): Deleted. (JSC::CopyBarrierBase::getPredicated): Deleted. (JSC::CopyBarrierBase::copyState): Deleted. (JSC::CopyBarrierBase::setCopyState): Deleted. (JSC::CopyBarrierBase::weakCASWithoutBarrier): Deleted. (JSC::CopyBarrier::getWithoutBarrier): Deleted. (JSC::CopyBarrier::getPredicated): Deleted. (JSC::CopyBarrier::weakCASWithoutBarrier): Deleted. * heap/Heap.cpp: (JSC::Heap::addToRememberedSet): (JSC::Heap::collectAndSweep): (JSC::Heap::copyBarrier): Deleted. * heap/Heap.h: (JSC::Heap::writeBarrierBuffer): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::branchIfNotFastTypedArray): (JSC::AssemblyHelpers::purifyNaN): (JSC::AssemblyHelpers::loadTypedArrayVector): Deleted. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::branchStructure): (JSC::AssemblyHelpers::addressForByteOffset): (JSC::AssemblyHelpers::branchIfToSpace): Deleted. (JSC::AssemblyHelpers::branchIfNotToSpace): Deleted. (JSC::AssemblyHelpers::removeSpaceBits): Deleted. * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompile): * jit/JITOpcodes.cpp: (JSC::JIT::emitSlow_op_has_indexed_property): (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emitSlow_op_get_direct_pname): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_get_direct_pname): (JSC::JIT::emitSlow_op_get_direct_pname): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitDoubleLoad): (JSC::JIT::emitContiguousLoad): (JSC::JIT::emitArrayStorageLoad): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::emit_op_get_from_scope): (JSC::JIT::emitSlow_op_get_from_scope): (JSC::JIT::emit_op_put_to_scope): (JSC::JIT::emitSlow_op_put_to_scope): (JSC::JIT::emitIntTypedArrayGetByVal): (JSC::JIT::emitFloatTypedArrayGetByVal): (JSC::JIT::emitIntTypedArrayPutByVal): (JSC::JIT::emitFloatTypedArrayPutByVal): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter64.asm: * runtime/DirectArguments.cpp: (JSC::DirectArguments::visitChildren): (JSC::DirectArguments::copyBackingStore): (JSC::DirectArguments::overrideArgument): (JSC::DirectArguments::copyToArguments): * runtime/DirectArguments.h: (JSC::DirectArguments::canAccessIndexQuickly): (JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG): * runtime/JSArray.cpp: (JSC::JSArray::setLength): (JSC::JSArray::pop): (JSC::JSArray::push): (JSC::JSArray::fastSlice): (JSC::JSArray::fastConcatWith): (JSC::JSArray::shiftCountWithArrayStorage): (JSC::JSArray::shiftCountWithAnyIndexingType): (JSC::JSArray::unshiftCountWithAnyIndexingType): (JSC::JSArray::fillArgList): (JSC::JSArray::copyToArguments): * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::finalize): * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::isNeutered): (JSC::JSArrayBufferView::vector): (JSC::JSArrayBufferView::length): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::visitChildren): (JSC::JSGenericTypedArrayView::copyBackingStore): * runtime/JSObject.cpp: (JSC::JSObject::visitChildren): (JSC::JSObject::copyBackingStore): (JSC::JSObject::heapSnapshot): (JSC::JSObject::getOwnPropertySlotByIndex): (JSC::JSObject::putByIndex): (JSC::JSObject::enterDictionaryIndexingMode): (JSC::JSObject::createInitialIndexedStorage): (JSC::JSObject::createArrayStorage): (JSC::JSObject::convertUndecidedToInt32): (JSC::JSObject::convertUndecidedToDouble): (JSC::JSObject::convertUndecidedToContiguous): (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements): (JSC::JSObject::convertUndecidedToArrayStorage): (JSC::JSObject::convertInt32ToDouble): (JSC::JSObject::convertInt32ToContiguous): (JSC::JSObject::convertInt32ToArrayStorage): (JSC::JSObject::convertDoubleToContiguous): (JSC::JSObject::convertDoubleToArrayStorage): (JSC::JSObject::convertContiguousToArrayStorage): (JSC::JSObject::setIndexQuicklyToUndecided): (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): (JSC::JSObject::deletePropertyByIndex): (JSC::JSObject::getOwnPropertyNames): (JSC::JSObject::putIndexedDescriptor): (JSC::JSObject::defineOwnIndexedProperty): (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): (JSC::JSObject::putDirectIndexBeyondVectorLength): (JSC::JSObject::getNewVectorLength): (JSC::JSObject::ensureLengthSlow): (JSC::JSObject::reallocateAndShrinkButterfly): (JSC::JSObject::growOutOfLineStorage): (JSC::getBoundSlotBaseFunctionForGetterSetter): (JSC::JSObject::getEnumerableLength): * runtime/JSObject.h: (JSC::JSObject::getArrayLength): (JSC::JSObject::getVectorLength): (JSC::JSObject::canGetIndexQuickly): (JSC::JSObject::getIndexQuickly): (JSC::JSObject::tryGetIndexQuickly): (JSC::JSObject::canSetIndexQuickly): (JSC::JSObject::canSetIndexQuicklyForPutDirect): (JSC::JSObject::setIndexQuickly): (JSC::JSObject::initializeIndex): (JSC::JSObject::hasSparseMap): (JSC::JSObject::inSparseIndexingMode): (JSC::JSObject::inlineStorage): (JSC::JSObject::butterfly): (JSC::JSObject::outOfLineStorage): (JSC::JSObject::locationForOffset): (JSC::JSObject::ensureInt32): (JSC::JSObject::ensureDouble): (JSC::JSObject::ensureContiguous): (JSC::JSObject::ensureArrayStorage): (JSC::JSObject::arrayStorage): (JSC::JSObject::arrayStorageOrNull): (JSC::JSObject::ensureLength): (JSC::JSObject::putDirectWithoutTransition): * runtime/MapData.h: (JSC::JSIterator>::IteratorData::next): (JSC::JSIterator>::IteratorData::refreshCursor): * runtime/MapDataInlines.h: (JSC::JSIterator>::find): (JSC::JSIterator>::add): (JSC::JSIterator>::remove): (JSC::JSIterator>::replaceAndPackBackingStore): (JSC::JSIterator>::replaceBackingStore): (JSC::JSIterator>::ensureSpaceForAppend): (JSC::JSIterator>::visitChildren): (JSC::JSIterator>::copyBackingStore): * runtime/Options.h: 2016-03-15 Saam barati Destructuring parameters are evaluated in the wrong scope https://bugs.webkit.org/show_bug.cgi?id=155454 Reviewed by Geoffrey Garen. This patch makes our engine compatible with how parameter lists are evaluated in ES6. A parameter list that contains a rest parameter, any destructuring patterns, or default parameter values, is classified as being non-simple. Non-simple parameter lists must get their own scope to live in, and the variables in the scope are under TDZ. This means that functions evaluated in the parameter list don't have access to variables inside the function body. Also, non-simple parameter lists get the strict-mode arguments object. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::~BytecodeGenerator): (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack): (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded): * bytecompiler/BytecodeGenerator.h: * parser/Nodes.h: (JSC::FunctionParameters::size): (JSC::FunctionParameters::at): (JSC::FunctionParameters::append): (JSC::FunctionParameters::hasDefaultParameterValues): Deleted. * tests/es6.yaml: * tests/stress/parameter-scoping.js: Added. (assert): (test): (test.foo): (test.): 2016-03-14 Yusuke Suzuki [JSC] Don't reference the properties of @Reflect directly https://bugs.webkit.org/show_bug.cgi?id=155436 Reviewed by Geoffrey Garen. Reflect.ownKeys and Reflect.getOwnPropertyDescriptor can be altered with the user-crafted values. Instead of referencing them directly, let's reference them through private names. * builtins/ObjectConstructor.js: (assign): * runtime/CommonIdentifiers.h: * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): Deleted. * runtime/ReflectObject.cpp: (JSC::ReflectObject::finishCreation): * tests/stress/object-assign-correctness.js: (runTests.): (runTests.get let): (Reflect.ownKeys): (Reflect.getOwnPropertyDescriptor): (test.let.handler.switch.case.string_appeared_here.return.get enumerable): Deleted. (test.let.handler.getOwnPropertyDescriptor): Deleted. (test.let.handler.ownKeys): Deleted. (test.let.handler.get getProps): Deleted. (test.let.handler): Deleted. (test): Deleted. 2016-03-14 Daniel Bates Web Inspector: Display Content Security Policy hash in details sidebar for script and style elements https://bugs.webkit.org/show_bug.cgi?id=155466 Reviewed by Joseph Pecoraro and Timothy Hatcher. Add property contentSecurityPolicyHash to store the CSP hash for an HTML style element or an applicable HTML script element. * inspector/protocol/DOM.json: 2016-03-14 Joonghun Park Purge PassRefPtr from ArrayBuffer, ArchiveResource, Pasteboard, LegacyWebArchive and DataObjectGtk https://bugs.webkit.org/show_bug.cgi?id=150497 Reviewed by Darin Adler. * runtime/ArrayBuffer.h: (JSC::ArrayBuffer::create): (JSC::ArrayBuffer::createAdopted): (JSC::ArrayBuffer::createFromBytes): (JSC::ArrayBuffer::createUninitialized): (JSC::ArrayBuffer::slice): (JSC::ArrayBuffer::sliceImpl): 2016-03-14 Benjamin Poulain Andy VanWagoner no longer has time to own Intl * features.json: Andy is busy with other things. Andy, thanks for your amazing work on Intl and your dedication to making things right. 2016-03-14 Julien Brianceau [mips] Fix unaligned access in LLINT. https://bugs.webkit.org/show_bug.cgi?id=153228 Address loads used with btbxx opcodes were wrongly converted to lw instruction instead of lbu, leading to unaligned access on mips platforms. This is not a bug as it's silently fixed up by kernel, but it's more efficient to avoid unaligned accesses for mips. Reviewed by Geoffrey Garen. * offlineasm/mips.rb: 2016-03-14 Filip Pizlo REGRESSION(r194394): >2x slow-down on CDjs https://bugs.webkit.org/show_bug.cgi?id=155471 Unreviewed (rollout). This revision changes localeCompare() so that it's *much* slower than before. It's understandable that sometimes things will get a tiny bit slower when implementing new language features, but more than 2x regression on a major benchmark is not OK. This rolls out that change. We can reland it once we think about how to do it in a performant way. * builtins/StringPrototype.js: (search): (localeCompare): Deleted. * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): 2016-03-14 Mark Lam Need to distinguish between Symbol() and Symbol(""). https://bugs.webkit.org/show_bug.cgi?id=155438 Reviewed by Saam Barati. * runtime/PrivateName.h: (JSC::PrivateName::PrivateName): 2016-03-14 Oliver Hunt Temporarily disable the separated heap. https://bugs.webkit.org/show_bug.cgi?id=155472 Reviewed by Geoffrey Garen. Temporarily disable this. * Configurations/FeatureDefines.xcconfig: 2016-03-14 Joseph Pecoraro Reduce generated JSON HeapSnapshot size https://bugs.webkit.org/show_bug.cgi?id=155460 Reviewed by Geoffrey Garen. Adjust the HeapSnapshot JSON to better reduce its size. Changes include: - avoid inner array groups and instead just have a large array for nodes/edges. This removes lots of small array allocations. - eliminate duplicate edges - avoid duplicating edge names by including them in their own table; - now both the nodes and edges lists hold only integers * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::json): Add some more documentation for the slightly modified format. While generating, clear data structures as early as possible. * heap/HeapSnapshotBuilder.h: (JSC::HeapSnapshotEdge::HeapSnapshotEdge): During JSON building, the edge's cell pointers are converted to the identifier they point to. This avoids having to re-lookup the identifier. * tests/heapProfiler/driver/driver.js: (CheapHeapSnapshotEdge): (CheapHeapSnapshot): (CheapHeapSnapshot.prototype.edgeNameFromTableIndex): (HeapSnapshot): Update test driver for slightly different snapshot format. 2016-03-14 Keith Miller We should be able to eliminate cloned arguments objects that use the length property https://bugs.webkit.org/show_bug.cgi?id=155391 Reviewed by Geoffrey Garen. Previously if a programmer tried to use arguments.length in a strict function we would not eliminate the arguments object. We were unable to eliminate the arguments object because the user would get a cloned arguments object, which does not special case the length property. Thus, in order to get arguments elimination for cloned we need to add a special case. There are two things that need to happen for the elimination to succeed. First, we need to eliminate the CheckStructure blocking the GetByOffset for the length property. In order to eliminate the check structure we need to prove to the Abstract Interpreter that this structure check is unnesssary. This didn't occur before for two reasons: 1) CreateClonedArguments did not set the structure it produced. 2) Even if CreateClonedArguments provided the global object's cloned arguments structure we would transition the new argements object when we added the length property during construction. To fix the second problem we now pre-assign a slot on clonedArgumentsStructure for the length property. Additionally, in order to prevent future transitions of the structure we need to choose an indexing type for the structure. Since, not eliminating the arguments object is so expensive we choose to have all cloned arguments start with continuous indexing type, this avoids transitioning when otherwise we would not have to. In the future we should be smarter about choosing the indexing type but since its relatively rare to have a arguments object escape we don't worry about this for now. Additionally, this patch renames all former references of outOfBandArguments to clonedArguments and adds extra instrumentation to DFGArgumentsEliminationPhase. * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/ValueRecovery.h: (JSC::ValueRecovery::clonedArgumentsThatWereNotCreated): (JSC::ValueRecovery::outOfBandArgumentsThatWereNotCreated): Deleted. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGOperations.cpp: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments): * dfg/DFGStructureRegistrationPhase.cpp: (JSC::DFG::StructureRegistrationPhase::run): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::tryToSetConstantRecovery): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments): * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_create_cloned_arguments): (JSC::JIT::emit_op_create_out_of_band_arguments): Deleted. * llint/LowLevelInterpreter.asm: * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::ClonedArguments): (JSC::ClonedArguments::createEmpty): (JSC::ClonedArguments::createWithInlineFrame): (JSC::ClonedArguments::createByCopyingFrom): (JSC::ClonedArguments::createStructure): * runtime/ClonedArguments.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::clonedArgumentsStructure): (JSC::JSGlobalObject::outOfBandArgumentsStructure): Deleted. 2016-03-14 Saam barati [ES6] Make JSON.stringify ES6 compatible https://bugs.webkit.org/show_bug.cgi?id=155448 Reviewed by Sam Weinig and Mark Lam. We weren't following the spec with respect to the "toJSON" property of the thing being stringified. We were perform hasProperty(.) on "toJSON" instead of get(.). This patch changes it our implementation to perform get(value, "toJSON"). * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::isFunction): (JSC::JSValue::isCallable): * runtime/JSONObject.cpp: (JSC::Stringifier::toJSON): (JSC::Stringifier::toJSONImpl): (JSC::Stringifier::appendStringifiedValue): * tests/es6.yaml: * tests/stress/proxy-json.js: (test): (test.let.handler.get assert): (test.let.handler): 2016-03-14 Saam barati [ES6] Disallow var assignments in for-in loops https://bugs.webkit.org/show_bug.cgi?id=155451 Reviewed by Mark Lam. We're doing this in its own patch instead of the patch for https://bugs.webkit.org/show_bug.cgi?id=155384 because last time we made this change it broke some websites. Lets try making it again because it's what the ES6 mandates. If it still breaks things we will roll it out. * parser/Parser.cpp: (JSC::Parser::parseForStatement): 2016-03-14 Saam barati assignments in for-in/for-of header not allowed https://bugs.webkit.org/show_bug.cgi?id=155384 Reviewed by Darin Adler. This patch prevents assignments to the loop variable in for in/of loops in all but one situation. The following syntax is still allowed even though the spec prevents it: ``` for (var i = X in blah) ; ``` If the loop contains let/const, destructuring, or is a for-of loop, we always throw a syntax error if there is an assignment. We can do this with full backwards compatibility. We only allow the above type of for-in loops because Oliver told me that when he tried to make such programs illegal he ran into real websites breaking. This patch also removed the !::CreatesAST compile-time branch when checking assignments to new.target. This was a dangerous thing for me to introduce into our parser. There are times where ::CreatesAST is true but we also want to check for syntax errors. For example, when parsing the top-level AST of a program. Though this check was technically correct, it's dangerous to have. It was correct because we would always be reparsing the new.target assignment because new.target is only allowed inside a function. That made it so that (!::CreatesAST <=> we care about new.target assignment syntax errors). But, (!::CreatesAST <=> we care about syntax error X) is not true in general. I think it's safer to remove such code. * parser/ASTBuilder.h: (JSC::ASTBuilder::createNewTargetExpr): (JSC::ASTBuilder::isNewTarget): (JSC::ASTBuilder::createResolve): * parser/Nodes.h: (JSC::ExpressionNode::isBoolean): (JSC::ExpressionNode::isSpreadExpression): (JSC::ExpressionNode::isSuperNode): (JSC::ExpressionNode::isNewTarget): (JSC::ExpressionNode::isBytecodeIntrinsicNode): * parser/Parser.cpp: (JSC::Parser::parseForStatement): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseUnaryExpression): 2016-03-13 Joseph Pecoraro Remove ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) guards https://bugs.webkit.org/show_bug.cgi?id=155417 Reviewed by Yusuke Suzuki. * Configurations/FeatureDefines.xcconfig: * parser/Parser.cpp: (JSC::Parser::parsePrimaryExpression): Deleted. (JSC::Parser::parseMemberExpression): Deleted. 2016-03-13 Konstantin Tokarev Added new port JSCOnly. https://bugs.webkit.org/show_bug.cgi?id=154512 Reviewed by Michael Catanzaro. This port allows to build JavaScriptCore engine with minimal dependencies. * PlatformJSCOnly.cmake: Added. 2016-03-12 Mark Lam http://kangax.github.io/compat-table/esnext/ crashes reliably. https://bugs.webkit.org/show_bug.cgi?id=155404 Reviewed by Yusuke Suzuki. constructObjectFromPropertyDescriptor() was incorrectly assuming that either both getter and setter will be set or unset. It did not consider that only one of the getter or setter may be set. This patch fixes that. * runtime/ObjectConstructor.h: (JSC::constructObjectFromPropertyDescriptor): * tests/stress/proxy-with-unbalanced-getter-setter.js: Added. (assert): (let.handler.defineProperty): (i.): (i.assert): (i.get assert): (set assert): 2016-03-12 Brian Burg When generating Objective-C protocol types, getters for objects need to synthesize a new object instance https://bugs.webkit.org/show_bug.cgi?id=155389 Reviewed by Timothy Hatcher. Currently, in object property getters for Objective-C protocol types, we use a C-style cast of the member's RWIProtocolJSONObject * to the type of the property. However, at runtime the class of `self` is going to be RWIProtocolJSONObject *, not MemberType *, so any subsequent calls to MemberType properties on the return value will fail as the selectors will not be recognized. Instead of doing a C-style pointer cast, we need to create a new MemberType object that's backed by the InspectorObject retrieved from the parent object by key. This requires a new initWithJSONObject initializer for each object protocol type. * inspector/scripts/codegen/generate_objc_header.py: (ObjCHeaderGenerator._generate_type_interface): Add new declaration. * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator.generate_type_implementation): (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_json_object): Added. Forward through to the super class initializer who assigns the underlying InspectorObject. (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members): Drive-by cleanup to use the more compact [super init] form. * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator.protocol_to_objc_expression_for_member): For property getters of objects, use initWithJSONObject: rather than a C-style cast. Rebaseline relevant test results. * 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/events-with-optional-parameters.json-result: * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result: * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result: * inspector/scripts/tests/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result: 2016-03-12 Konstantin Tokarev Removed variable names from default constructor declarations. https://bugs.webkit.org/show_bug.cgi?id=155397 Reviewed by Mark Lam. They carry no information and generate unused variable warning with GCC 4.8 in a lot of source files. * parser/VariableEnvironment.h: 2016-03-12 Myles C. Maxfield Delete dead SVG Font code https://bugs.webkit.org/show_bug.cgi?id=154718 Reviewed by Antti Koivisto. * Configurations/FeatureDefines.xcconfig: 2016-03-11 Benjamin Poulain [JSC] Remove a few jumps from DFG https://bugs.webkit.org/show_bug.cgi?id=155347 Reviewed by Mark Lam. Usually, setting ValueTrue or ValueFalse is set by Compare+Or. There are 3 places in DFG with branches instead. This patch changes them to the usual pattern. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileObjectEquality): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): 2016-03-11 Saam barati [ES6] Make Object.assign spec compliant https://bugs.webkit.org/show_bug.cgi?id=155375 Reviewed by Michael Saboff. This is a straight forward implementation of Object.assign in the spec. https://tc39.github.io/ecma262/#sec-object.assign Before, weren't performing all of the specified operations. Now, we are. * builtins/ObjectConstructor.js: (assign): * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * tests/es6.yaml: 2016-03-11 Mark Lam Implement Function.name and Function#toString for ES6 class. https://bugs.webkit.org/show_bug.cgi?id=155336 Reviewed by Geoffrey Garen. The only thing that the ES6 spec says about toString with regards to class objects is: "The string representation must have the syntax of a FunctionDeclaration, FunctionExpression, GeneratorDeclaration, GeneratorExpression, ClassDeclaration, ClassExpression, ArrowFunction, MethodDefinition, or GeneratorMethod depending upon the actual characteristics of the object." Previously, invoking toString() on a class object will return the function source string of the class' constructor function. This does not conform to the spec in that the toString string for a class does not have the syntax of a ClassDeclaration or ClassExpression. This is now fixed by doing the following: 1. Added "m_classSource" to FunctionExecutable (and correspondingly to UnlinkedFunctionExecutable, FunctionMetadataNode, and ClassExprNode). m_classSource is the SourceCode for the code range "class ... { ... }". Since the class constructor function is the in memory representation of the class object, only class constructor functions will have its m_classSource set. m_classSource will be "null" (by default) for all other functions. This is how we know if a FunctionExecutable is for a class. Note: FunctionExecutable does not have its own m_classSource. It always gets it from its UnlinkedFunctionExecutable. This is ok to do because our CodeCache currently does not cache UnlinkedFunctionExecutables for class constructors. 2. The ClassExprNode now tracks the SourceCode range for the class expression. This is used to set m_classSource in the UnlinkedFunctionExecutable at bytecode generation time, and the FunctionExecutable later at bytecode linking time. 3. Function.prototype.toString() now checks if the function is for a class. If so, it returns the string for the class source instead of just the function source for the class constructor. Note: the class source is static from the time the class was parsed. This can introduces some weirdness at runtime. Consider the following: var v1 = class {} v1.toString(); // yields "class {}". class c2 extends v1 {} c2.__proto__ === v1; // yields true i.e. c2 extends v1. c2.toString(); // yields "class c2 extends v1 {}" which is fine. v1 = {}; // point v1 to something else now. c2.__proto__ === v1; // now yields false i.e. c2 no longer extends v1. // c2 actually extends the class that v1 used to // point to, but ... c2.toString(); // still yields "class c2 extends v1 {}" which is no longer true. It is unclear how we can best implement toString() to avoid this issue. The above behavior is how Chrome (Version 51.0.2671.0 canary (64-bit)) currently implements toString() of a class, and we do the same in this patch. In Firefox (45.0), toString() of a class will yield the function source of it constructor function, which is not better. In this patch, we also added ES6 compliance for Function.name on class objects: 4. The ClassExprNode now has a m_ecmaName string for tracking the inferred name of a class according to the ES6 spec. The ASTBuilder now mirrors its handling of FuncExprNodes to ClassExprNodes in setting the nodes' m_ecmaName where relevant. The m_ecmaName is later used to set the m_ecmaName of the FunctionExecutable of the class constructor, which in turn is used to populate the initial value of the Function.name property. 5. Also renamed some variable names (/m_metadata/metadata/) to be consistent with webkit naming convention. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): * bytecode/UnlinkedFunctionExecutable.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitNewArrowFunctionExpression): (JSC::BytecodeGenerator::emitNewDefaultConstructor): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::ClassExprNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createAssignResolve): (JSC::ASTBuilder::createYield): (JSC::ASTBuilder::createClassExpr): (JSC::ASTBuilder::createFunctionExpr): (JSC::ASTBuilder::createProperty): (JSC::ASTBuilder::makeAssignNode): * parser/NodeConstructors.h: (JSC::FunctionParameters::FunctionParameters): (JSC::BaseFuncExprNode::BaseFuncExprNode): (JSC::FuncExprNode::FuncExprNode): (JSC::FuncDeclNode::FuncDeclNode): (JSC::ArrowFuncExprNode::ArrowFuncExprNode): (JSC::ClassDeclNode::ClassDeclNode): (JSC::ClassExprNode::ClassExprNode): * parser/Nodes.h: (JSC::ExpressionNode::isDestructuringNode): (JSC::ExpressionNode::isFuncExprNode): (JSC::ExpressionNode::isArrowFuncExprNode): (JSC::ExpressionNode::isClassExprNode): (JSC::ExpressionNode::isCommaNode): (JSC::ExpressionNode::isSimpleArray): (JSC::ExpressionNode::isAdd): * parser/Parser.cpp: (JSC::stringForFunctionMode): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseClass): * parser/ParserFunctionInfo.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createEmptyLetExpression): (JSC::SyntaxChecker::createYield): (JSC::SyntaxChecker::createClassExpr): (JSC::SyntaxChecker::createFunctionExpr): (JSC::SyntaxChecker::createFunctionMetadata): (JSC::SyntaxChecker::createArrowFunctionExpr): * runtime/Executable.cpp: (JSC::FunctionExecutable::FunctionExecutable): (JSC::FunctionExecutable::finishCreation): * runtime/Executable.h: * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncToString): * tests/es6.yaml: 2016-03-11 Commit Queue Unreviewed, rolling out r197994. https://bugs.webkit.org/show_bug.cgi?id=155368 Broke several ARM tests (Requested by msaboff on #webkit). Reverted changeset: "[JSC] Add register reuse for ArithAdd of an Int32 and constant in DFG" https://bugs.webkit.org/show_bug.cgi?id=155164 http://trac.webkit.org/changeset/197994 2016-03-11 Yusuke Suzuki [ES6] Implement Reflect.set without receiver support https://bugs.webkit.org/show_bug.cgi?id=155024 Reviewed by Geoffrey Garen. This patch implements Reflect.set. The challenge in this patch is Reflect.set requires boolean result of [[Set]], this is not propagated in the previous JSC put implementation. This patch changes the put and putByIndex signature from `void put(...)` and `void putByIndex(...)` to `bool put(...)` and `bool putByIndex(...)`, more consistent style to the ECMA262 spec's [[Set]]. This patch modifies so many part of WebKit. But almost all the changes are mechanical ones. Currently, this patch does not support receiver modification support. This will be supported in the subsequent patch[1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=155294 * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::put): (JSC::JSCallbackObject::putByIndex): * debugger/DebuggerScope.cpp: (JSC::DebuggerScope::put): * debugger/DebuggerScope.h: * jsc.cpp: (WTF::RuntimeArray::put): * runtime/ClassInfo.h: * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::put): * runtime/ClonedArguments.h: * runtime/CustomGetterSetter.cpp: (JSC::callCustomSetter): * runtime/CustomGetterSetter.h: * runtime/GenericArguments.h: * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments::put): (JSC::GenericArguments::putByIndex): * runtime/GetterSetter.cpp: (JSC::callSetter): * runtime/GetterSetter.h: * runtime/JSArray.cpp: (JSC::JSArray::defineOwnProperty): (JSC::JSArray::put): (JSC::JSArray::push): * runtime/JSArray.h: * runtime/JSArrayBuffer.cpp: (JSC::JSArrayBuffer::put): * runtime/JSArrayBuffer.h: * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::put): * runtime/JSArrayBufferView.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::put): (JSC::JSValue::putInline): (JSC::JSValue::putByIndex): * runtime/JSCell.cpp: (JSC::JSCell::put): (JSC::JSCell::putByIndex): * runtime/JSCell.h: * runtime/JSDataView.cpp: (JSC::JSDataView::put): * runtime/JSDataView.h: * runtime/JSFunction.cpp: (JSC::JSFunction::put): (JSC::JSFunction::defineOwnProperty): * runtime/JSFunction.h: * runtime/JSGenericTypedArrayView.h: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::put): (JSC::JSGenericTypedArrayView::putByIndex): * runtime/JSGlobalLexicalEnvironment.cpp: (JSC::JSGlobalLexicalEnvironment::put): * runtime/JSGlobalLexicalEnvironment.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::put): * runtime/JSGlobalObject.h: * runtime/JSLexicalEnvironment.cpp: (JSC::JSLexicalEnvironment::put): * runtime/JSLexicalEnvironment.h: * runtime/JSModuleEnvironment.cpp: (JSC::JSModuleEnvironment::put): * runtime/JSModuleEnvironment.h: * runtime/JSModuleNamespaceObject.cpp: (JSC::JSModuleNamespaceObject::put): (JSC::JSModuleNamespaceObject::putByIndex): * runtime/JSModuleNamespaceObject.h: * runtime/JSModuleRecord.cpp: (JSC::JSModuleRecord::instantiateDeclarations): * runtime/JSObject.cpp: (JSC::JSObject::put): (JSC::JSObject::putInlineSlow): (JSC::JSObject::putByIndex): (JSC::JSObject::putGetter): (JSC::JSObject::putSetter): (JSC::JSObject::putDirectAccessor): (JSC::JSObject::putDirectCustomAccessor): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::putIndexedDescriptor): (JSC::JSObject::defineOwnIndexedProperty): (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype): (JSC::JSObject::attemptToInterceptPutByIndexOnHole): (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage): (JSC::JSObject::putByIndexBeyondVectorLength): (JSC::JSObject::putDirectNativeIntrinsicGetter): (JSC::JSObject::putDirectNativeFunction): (JSC::JSObject::putDirectMayBeIndex): (JSC::validateAndApplyPropertyDescriptor): * runtime/JSObject.h: (JSC::JSObject::putByIndexInline): (JSC::JSObject::putDirect): * runtime/JSObjectInlines.h: (JSC::JSObject::putInline): * runtime/JSProxy.cpp: (JSC::JSProxy::put): (JSC::JSProxy::putByIndex): * runtime/JSProxy.h: * runtime/JSSymbolTableObject.h: (JSC::symbolTablePut): (JSC::symbolTablePutTouchWatchpointSet): (JSC::symbolTablePutInvalidateWatchpointSet): (JSC::symbolTablePutWithAttributesTouchWatchpointSet): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): * runtime/ProxyObject.cpp: (JSC::ProxyObject::performPut): (JSC::ProxyObject::put): (JSC::ProxyObject::putByIndexCommon): (JSC::ProxyObject::putByIndex): * runtime/ProxyObject.h: * runtime/PutPropertySlot.h: * runtime/ReflectObject.cpp: (JSC::reflectObjectSet): * runtime/RegExpConstructor.cpp: (JSC::setRegExpConstructorInput): (JSC::setRegExpConstructorMultiline): * runtime/RegExpObject.cpp: (JSC::RegExpObject::defineOwnProperty): (JSC::regExpObjectSetLastIndexStrict): (JSC::regExpObjectSetLastIndexNonStrict): (JSC::RegExpObject::put): * runtime/RegExpObject.h: * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayValueMap::putEntry): (JSC::SparseArrayEntry::put): * runtime/SparseArrayValueMap.h: * runtime/StringObject.cpp: (JSC::StringObject::put): (JSC::StringObject::putByIndex): * runtime/StringObject.h: * tests/es6.yaml: * tests/modules/namespace.js: * tests/stress/reflect-set.js: Added. (shouldBe): (shouldThrow): (receiverCase.object2.set Cocoa): (receiverCase): (proxyCase): (objectCase.set get shouldBe): (objectCase.get shouldBe): (arrayCase.set get shouldBe): (arrayCase.get shouldBe): (arrayBufferCase.set get shouldBe): (arrayBufferCase.get shouldBe): (set get shouldBe): (get shouldBe): (argumentCase.test1): (argumentCase.test2): (argumentCase.test3): (argumentCase.test4.set get shouldBe): (argumentCase.test5.get shouldBe): (argumentStrictCase.test1): (argumentStrictCase.test2): (argumentStrictCase.test3): (argumentStrictCase.test4.set get shouldBe): (argumentStrictCase.test5.get shouldBe): (stringObjectCase.set get shouldBe): (stringObjectCase.get shouldBe): (customSetter.test1): (customSetter.test2): (customSetter.test3): (customSetter): (regExpLastIndex): (functionCase.func): 2016-03-10 Brian Burg Web Inspector: generated initWithPayload: protocol object initializers should recursively decode array and object members https://bugs.webkit.org/show_bug.cgi?id=155337 Reviewed by Timothy Hatcher. In cases where an object member is itself an object or array, we were not calling initWithPayload: on the object member itself. So, this caused a runtime error when constructing the outer object because the generated code casted the NSDictionary/NSArray into the member's protocol object type. * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator.payload_to_objc_expression_for_member): Do a straightforward call to initWithPayload: for objects. For arrays, call a templated helper function which does the same thing. The helper is used to make this array decoding fit into a single generated expression. Rebaseline relevant test results. * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result: * inspector/scripts/tests/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result: 2016-03-10 Keith Miller Unreviewed, fix Changelog. git merged poorly. 2016-03-10 Keith Miller Unreviewed, fix testapi. * API/tests/TypedArrayCTest.cpp: (testAccess): (testConstructors): (forEachTypedArrayType): (testTypedArrayCAPI): 2016-03-10 Saam barati [ES6] Make RegExp.prototype.toString spec compliant https://bugs.webkit.org/show_bug.cgi?id=155341 Reviewed by Filip Pizlo. Before we were directly calling into the flagsString function. Instead, we must get the "flags" property of the thisObject. This will usually call into the flags getter, but not always. Specifically, you can you a Proxy to observe this behavior. * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncToString): (JSC::regExpProtoGetterGlobal): * tests/es6.yaml: * tests/es6/Proxy_internal_get_calls_RegExp.prototype.toString.js: Added. (test.get var): (test.): * tests/stress/regexp-prototype-tostring.js: Added. (assert): (test): (test.get var): (test.): (let.handler.get switch): (let.handler): (get test): (test.get RegExp): 2016-03-10 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 Geoffrey Garen. 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-03-10 Keith Miller Unreviewed, build fix for r197983, hopefully. * API/WebKitAvailability.h: 2016-03-10 Keith Miller Typed Arrays have no public facing API https://bugs.webkit.org/show_bug.cgi?id=120112 Reviewed by Geoffrey Garen. This patch adds a new C-API (an Obj-C API will follow in the future) for Typed Arrays. The API has two sets of functions. One for Typed Arrays and another for Array Buffers. This API is intended to reflect the use of Typed Array objects in JS code. There is a method for each of the core TypedArray and Array Buffer methods. Originally, we were planning on using a separate non-JS object as the backing store instead of a JS Array Buffer but we decide to defer that idea since there was no good CF/NS API that met all the constraints we needed (Discussed further below). We also wanted to want until Shared Array Buffers had reached a more finished state to see what impact they might have on an API. The API has the following Typed Array construction methods: 1) Create with length (the backing buffer is zero initialized). -- JSObjectMakeTypedArray 2) Create with an existing pointer and a destructor. -- JSObjectMakeTypedArrayFromBytesNoCopy 3) Create with an Array Buffer object. -- JSObjectMakeTypedArrayFromArrayBuffer 4) Create with an Array Buffer object with a given offset and length. -- JSObjectMakeTypedArrayFromArrayBufferWithOffset The API has the following functions on Typed Array JSObjectRefs: 5) Get access to a temporary void* of the backing store's data. -- JSObjectGetTypedArrayBytesPtr 6) Get the length of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayLength 7) Get the byte length of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayByteLength 8) Get the byte offset of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayByteOffset 9) Get a Typed Array object's Array Buffer backing store. -- JSObjectGetTypedArrayBuffer The API has the following Array Buffer construction method: 10) Create with an existing pointer and a destructor. -- JSObjectMakeArrayBufferWithBytesNoCopy The API has the following functions on Array Buffer JSObjectRefs: 11) Get access to a temporary void* of the backing store's data. -- JSObjectGetArrayBufferBytesPtr 12) Get the byte length of an Array Buffer object (returns 0 if it is not an Array Buffer object). -- JSObjectGetArrayBufferByteLength The API adds the following new typedefs and enumerations: 13) A typedef representing the function pointer type used to deallocate byte pointers provided to constructors. -- JSTypedArrayByesDeallocator 14) An enumeration indicating the Typed Array API type of a JSValueRef. -- JSTypedArrayType Finally, The API has the following function to get Typed Array Types: 15) Get the Typed Array type of a JS value. -- JSValueGetTypedArrayType There are a couple of things to note about these functions. Calling JSObjectGetTypedArrayBytesPtr (5) or JSObjectGetArrayBufferBytesPtr (12) will pin and lock the ArrayBuffer's data for the remaining lifetime of that ArrayBuffer. This is because, currently, we do not have finalizers for our Array Buffers or Typed Arrays with a backing ArrayBuffer and adding one would likely incur a non-trivial cost to GC. Also, we do not have a direct way to make a Typed Array from a pointer with an offset as we do not expect using offsets to be a common use case of the API. While it would have been nice to integrate our backing store with CFData or one of its subclasses, it is not possible to force a CFData/CFMutableData to be both writable and have a fixed size/backing store pointer. NSData is not writable and CFMutableData can have a fixed pointer if it is allocated with a non-zero capacity but there is no way for us to force an existing CFMutableData into this state. * API/APIUtils.h: Copied from Source/JavaScriptCore/runtime/ArrayBuffer.cpp. (handleExceptionIfNeeded): (setException): * API/JSBase.h: * API/JSObjectRef.cpp: (handleExceptionIfNeeded): Deleted. * API/JSTypedArray.cpp: Added. (toJSTypedArrayType): (toTypedArrayType): (createTypedArray): (JSValueGetTypedArrayType): (JSObjectMakeTypedArray): (JSObjectMakeTypedArrayWithBytesNoCopy): (JSObjectMakeTypedArrayWithArrayBuffer): (JSObjectMakeTypedArrayWithArrayBufferAndOffset): (JSObjectGetTypedArrayBytesPtr): (JSObjectGetTypedArrayLength): (JSObjectGetTypedArrayByteLength): (JSObjectGetTypedArrayByteOffset): (JSObjectGetTypedArrayBuffer): (JSObjectMakeArrayBufferWithBytesNoCopy): (JSObjectGetArrayBufferBytesPtr): (JSObjectGetArrayBufferByteLength): * API/JSTypedArray.h: Added. * API/JSValueRef.cpp: (handleExceptionIfNeeded): Deleted. * API/JSValueRef.h: * API/JavaScript.h: * API/WebKitAvailability.h: * API/tests/TypedArrayCTest.cpp: Added. (id): (freePtr): (assertEqualsAsNumber): (testAccess): (testConstructors): (forEachTypedArrayType): (testTypedArrayCAPI): * API/tests/TypedArrayCTest.h: Added. * API/tests/testapi.c: (main): * CMakeLists.txt: * ForwardingHeaders/JavaScriptCore/JSTypedArray.h: Added. * JavaScriptCore.xcodeproj/project.pbxproj: * PlatformEfl.cmake: * PlatformGTK.cmake: * runtime/ArrayBuffer.cpp: (JSC::ArrayBuffer::transfer): * runtime/ArrayBuffer.h: (JSC::arrayBufferDestructorNull): (JSC::arrayBufferDestructorDefault): (JSC::ArrayBufferContents::ArrayBufferContents): (JSC::ArrayBufferContents::transfer): (JSC::ArrayBuffer::createAdopted): (JSC::ArrayBuffer::createFromBytes): (JSC::ArrayBuffer::ArrayBuffer): (JSC::ArrayBuffer::pinAndLock): (JSC::ArrayBufferContents::tryAllocate): (JSC::ArrayBufferContents::~ArrayBufferContents): * shell/PlatformWin.cmake: 2016-03-10 Saam barati [ES6] Instanceof isn't spec compliant when the RHS is a Proxy with a target that is a function https://bugs.webkit.org/show_bug.cgi?id=155329 Reviewed by Mark Lam. We use type info flags on the structure to dictate whether or not the RHS of an instanceof is a valid RHS (i.e, a function). The solution to make Proxy a valid RHS when the Proxy's target is callable is to have two different structures for ProxyObject: one for a non-callable target and one for a callable target. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::moduleRecordStructure): (JSC::JSGlobalObject::moduleNamespaceObjectStructure): (JSC::JSGlobalObject::proxyObjectStructure): (JSC::JSGlobalObject::callableProxyObjectStructure): (JSC::JSGlobalObject::proxyRevokeStructure): (JSC::JSGlobalObject::wasmModuleStructure): * runtime/ProxyConstructor.cpp: (JSC::makeRevocableProxy): (JSC::constructProxyObject): (JSC::ProxyConstructor::getConstructData): * runtime/ProxyObject.cpp: (JSC::ProxyObject::ProxyObject): (JSC::ProxyObject::structureForTarget): (JSC::ProxyObject::finishCreation): * runtime/ProxyObject.h: (JSC::ProxyObject::create): (JSC::ProxyObject::createStructure): * tests/es6.yaml: * tests/stress/proxy-instanceof.js: Added. (assert): (test): (C): (test.let.handler.get if): (test.let.handler): 2016-03-10 Michael Saboff [ES6] RegExp sticky flag should be ignored in String.match when global flag is given https://bugs.webkit.org/show_bug.cgi?id=155332 Reviewed by Saam Barati. Removed logic from stringProtoFuncMatch that handles the case where both global and sticky flags are set. * runtime/StringPrototype.cpp: (JSC::stringProtoFuncMatch): 2016-03-10 Michael Saboff [ES6] Allow RegExp constructor to take pattern from an existing RegExp with new flags https://bugs.webkit.org/show_bug.cgi?id=155315 Reviewed by Saam Barati. Changed to comply with section 21.2.3.1, step 5. Eliminated syntax error. In the process, change to get the VM at the top of the function. Updated tests accordingly. * runtime/RegExpConstructor.cpp: (JSC::constructRegExp): * tests/es6.yaml: Changed miscellaneous_RegExp_constructor_can_alter_flags.js to normal. * tests/mozilla/mozilla-tests.yaml: Disabled ecma_3/RegExp/15.10.4.1-5-n.js as it checks for the old behavior of throwing a syntax error. 2016-03-10 Saam barati [ES6] Make ToPropertyDescriptor spec compliant https://bugs.webkit.org/show_bug.cgi?id=155313 Reviewed by Mark Lam. We were performing HasProperty(.) and Get(.) in the same operation. This isn't valid according to the spec and it's user observable behavior with Proxy. This patch fixes ToPropertyDescriptor to use two distinct operations for HasProperty(.) and Get(.). * runtime/ObjectConstructor.cpp: (JSC::ownEnumerablePropertyKeys): (JSC::toPropertyDescriptor): * tests/es6.yaml: * tests/stress/to-property-key-correctness.js: Added. (assert): (test): (test.let.handler.has): (arrayEq): (let.handler.has): (let.target): (set get let): 2016-03-10 Brian Burg Web Inspector: report the underlying parser error message when JSON parsing fails https://bugs.webkit.org/show_bug.cgi?id=155303 Reviewed by Timothy Hatcher. * inspector/scripts/generate-inspector-protocol-bindings.py: (generate_from_specification.load_specification): Stringize the underlying error so we can see what it says. 2016-03-09 Joseph Pecoraro Web Inspector: JavaScript Heap Allocations Timeline https://bugs.webkit.org/show_bug.cgi?id=155287 Reviewed by Timothy Hatcher. * inspector/InjectedScriptSource.js: (InjectedScript.prototype._describe): (InjectedScript.prototype._nodeDescription): Provide the nicer node preview more often. 2016-03-10 Saam barati Assignment to new.target should be an early error https://bugs.webkit.org/show_bug.cgi?id=151148 Reviewed by Mark Lam. This patch makes it so that any form of assignment to new.target is an early syntax error. * parser/ASTBuilder.h: (JSC::ASTBuilder::createNewTargetExpr): (JSC::ASTBuilder::isNewTarget): (JSC::ASTBuilder::createResolve): * parser/Parser.cpp: (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseUnaryExpression): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createThisExpr): (JSC::SyntaxChecker::createSuperExpr): (JSC::SyntaxChecker::createNewTargetExpr): (JSC::SyntaxChecker::isNewTarget): (JSC::SyntaxChecker::createResolve): (JSC::SyntaxChecker::createObjectLiteral): * tests/es6.yaml: * tests/stress/new-target-syntax-errors.js: Added. (shouldBeSyntaxError): (shouldNotBeSyntaxError): * tests/stress/new-target.js: (Constructor): (doWeirdThings): (noAssign): Deleted. (catch): Deleted. 2016-03-08 Skachkov Oleksandr How we load new.target in arrow functions is broken https://bugs.webkit.org/show_bug.cgi?id=155153 Reviewed by Saam Barati. Fixed not correct approach of caching new.target. In current patch was added code feature flag that shows that current function is using new.target, when generating byte code an arrow function we are loading new.target value to its register from arrow function lexical environment. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::newTarget): * parser/ASTBuilder.h: (JSC::ASTBuilder::createNewTargetExpr): (JSC::ASTBuilder::usesNewTarget): * parser/Nodes.h: (JSC::ScopeNode::usesNewTarget): * parser/ParserModes.h: * tests/stress/arrowfunction-lexical-bind-newtarget.js: 2016-03-09 Joseph Pecoraro Web Inspector: Get a RemoteObject or ObjectPreview from HeapSnapshot Object Identifier https://bugs.webkit.org/show_bug.cgi?id=155264 Reviewed by Timothy Hatcher. * inspector/InjectedScript.h: * inspector/InjectedScript.cpp: (Inspector::InjectedScript::functionDetails): (Inspector::InjectedScript::previewValue): New InjectedScript methods for building Debugger.FunctionDetails or Runtime.ObjectPreview protocol objects from a JSValue. * inspector/InjectedScriptSource.js: (InjectedScript.prototype.previewValue): (InjectedScript.prototype.functionDetails): (InjectedScript.prototype.getFunctionDetails): (InjectedScript.RemoteObject.prototype._isPreviewableObjectInternal): (InjectedScript.RemoteObject.prototype._createObjectPreviewForValue): Deleted. (InjectedScript.RemoteObject.prototype._appendEntryPreviews): Deleted. Share code around creating function details or object preview objects. * inspector/agents/InspectorHeapAgent.cpp: (Inspector::InspectorHeapAgent::InspectorHeapAgent): (Inspector::InspectorHeapAgent::nodeForHeapObjectIdentifier): (Inspector::InspectorHeapAgent::getPreview): (Inspector::InspectorHeapAgent::getRemoteObject): * inspector/agents/InspectorHeapAgent.h: * inspector/protocol/Heap.json: New protocol methods that go from heap object identifier to a remote object or some kind of preview. * inspector/scripts/codegen/generator.py: Allow runtime casts for ObjectPreview. 2016-03-09 Andy VanWagoner [INTL] Intl Constructors not web compatible with Object.create usage https://bugs.webkit.org/show_bug.cgi?id=153679 Reviewed by Darin Adler. Add workaround for initializing NumberFormat and DateTimeFormat objects using Object.create followed by constructor.call. This is necessary for backwards compatibility with libraries relying on v1 behavior of Intl constructors. Collator does not get the workaround, since polyfills do not include it, and there are not any known instances of v2 incompatible libraries. The workaround involves checking for an object that inherits from the *Format constructor, but was not actually initialized with that type. A substitute instance is created and attached to the object using a private name. The prototype functions then check for the private property to use in place of the original object. Since this behavior is not part of the v2 spec, it should be removed as soon as the incompatible behavior is no longer in common use. * runtime/CommonIdentifiers.h: * runtime/IntlDateTimeFormatConstructor.cpp: (JSC::callIntlDateTimeFormat): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeGetterFormat): (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions): * runtime/IntlNumberFormatConstructor.cpp: (JSC::callIntlNumberFormat): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototypeGetterFormat): (JSC::IntlNumberFormatPrototypeFuncResolvedOptions): 2016-03-09 Saam barati Add proper JSON.stringify support for Proxy when the target is an array https://bugs.webkit.org/show_bug.cgi?id=155180 Reviewed by Darin Adler. This patch makes the following type of program true: `JSON.stringify(new Proxy([25], {})) === "[25]"` We need to change the JSON stringifier to use the IsArray test in section 7.2.2 of ES6 spec instead of the JSC inherits(JSArray::info()) test. This patch also adds tests for general JSON.stringify support of Proxy. * runtime/ArrayConstructor.cpp: (JSC::arrayConstructorIsArray): (JSC::arrayConstructorPrivateFuncIsArrayConstructor): * runtime/ArrayConstructor.h: (JSC::isArray): * runtime/JSONObject.cpp: (JSC::Stringifier::Holder::object): (JSC::Stringifier::appendStringifiedValue): (JSC::Stringifier::startNewLine): (JSC::Stringifier::Holder::Holder): * tests/es6.yaml: * tests/stress/proxy-json.js: Added. (assert): (test): 2016-03-09 Saam Barati ES6: Implement lexical scoping for function definitions in strict mode https://bugs.webkit.org/show_bug.cgi?id=152844 Reviewed by Geoffrey Garen. This patch implements block scoping for function definitions in strict mode. The implementation works as follows: - If we're in sloppy mode, function declarations work exactly as they did before this patch. I.e, function declarations are hoisted and declared like "var" variables. - If you're in strict mode and at the top of a function scope or program scope, function declarations still work like they used to. They are defined like "var" variables. This is necessary for backwards compatibility because ES5 strict mode allowed duplicate function declarations at the top-most scope of a program/function. - If you're in strict mode and inside a block statement or a switch statement, function declarations are now block scoped. All function declarations within a block are hoisted to the beginning of the block. They are not hoisted out of the block like they are in sloppy mode. This allows for the following types of programs: ``` function foo() { function bar() { return 20; } { function bar() { return 30; } bar(); // 30 } bar(); // 20 } ``` * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::instantiateLexicalVariables): (JSC::BytecodeGenerator::emitPrefillStackTDZVariables): (JSC::BytecodeGenerator::pushLexicalScope): (JSC::BytecodeGenerator::pushLexicalScopeInternal): (JSC::BytecodeGenerator::initializeBlockScopedFunctions): (JSC::BytecodeGenerator::popLexicalScope): (JSC::BytecodeGenerator::liftTDZCheckIfPossible): (JSC::BytecodeGenerator::pushTDZVariables): (JSC::BytecodeGenerator::getVariablesUnderTDZ): (JSC::BytecodeGenerator::emitNewRegExp): (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): (JSC::BytecodeGenerator::emitNewFunctionExpression): (JSC::BytecodeGenerator::emitNewArrowFunctionExpression): * bytecompiler/BytecodeGenerator.h: * parser/ASTBuilder.h: (JSC::ASTBuilder::createSourceElements): (JSC::ASTBuilder::features): (JSC::ASTBuilder::numConstants): (JSC::ASTBuilder::createFuncDeclStatement): (JSC::ASTBuilder::createClassDeclStatement): (JSC::ASTBuilder::createBlockStatement): (JSC::ASTBuilder::createTryStatement): (JSC::ASTBuilder::createSwitchStatement): (JSC::ASTBuilder::Scope::Scope): (JSC::ASTBuilder::funcDeclarations): Deleted. * parser/NodeConstructors.h: (JSC::CaseBlockNode::CaseBlockNode): (JSC::SwitchNode::SwitchNode): (JSC::BlockNode::BlockNode): * parser/Nodes.cpp: (JSC::ScopeNode::ScopeNode): (JSC::ScopeNode::singleStatement): (JSC::ProgramNode::ProgramNode): (JSC::ModuleProgramNode::ModuleProgramNode): (JSC::EvalNode::EvalNode): (JSC::FunctionNode::FunctionNode): (JSC::VariableEnvironmentNode::VariableEnvironmentNode): * parser/Nodes.h: (JSC::VariableEnvironmentNode::VariableEnvironmentNode): (JSC::VariableEnvironmentNode::lexicalVariables): (JSC::VariableEnvironmentNode::functionStack): (JSC::ScopeNode::captures): (JSC::ScopeNode::varDeclarations): (JSC::ScopeNode::neededConstants): (JSC::ProgramNode::startColumn): (JSC::ProgramNode::endColumn): (JSC::EvalNode::startColumn): (JSC::EvalNode::endColumn): (JSC::ModuleProgramNode::startColumn): (JSC::ModuleProgramNode::endColumn): (JSC::ScopeNode::functionStack): Deleted. * parser/Parser.cpp: (JSC::Parser::parseInner): (JSC::Parser::didFinishParsing): (JSC::Parser::parseStatementListItem): (JSC::Parser::parseSwitchStatement): (JSC::Parser::parseBlockStatement): (JSC::Parser::parseStatement): (JSC::Parser::parseFunctionInfo): (JSC::getMetadata): (JSC::Parser::parseFunctionDeclaration): (JSC::Parser::parseExportDeclaration): * parser/Parser.h: (JSC::Scope::declareVariable): (JSC::Scope::declareFunction): (JSC::Scope::appendFunction): (JSC::Scope::takeFunctionDeclarations): (JSC::Scope::declareLexicalVariable): (JSC::Parser::currentVariableScope): (JSC::Parser::currentLexicalDeclarationScope): (JSC::Parser::currentFunctionScope): (JSC::Parser::pushScope): (JSC::Parser::popScopeInternal): (JSC::Parser::declareVariable): (JSC::Parser::declareFunction): (JSC::Parser::hasDeclaredVariable): (JSC::Parser::isFunctionMetadataNode): (JSC::Parser::parse): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createFuncDeclStatement): (JSC::SyntaxChecker::createClassDeclStatement): (JSC::SyntaxChecker::createBlockStatement): (JSC::SyntaxChecker::createExprStatement): (JSC::SyntaxChecker::createIfStatement): (JSC::SyntaxChecker::createContinueStatement): (JSC::SyntaxChecker::createTryStatement): (JSC::SyntaxChecker::createSwitchStatement): (JSC::SyntaxChecker::createWhileStatement): (JSC::SyntaxChecker::createWithStatement): (JSC::SyntaxChecker::createDoWhileStatement): * parser/VariableEnvironment.h: (JSC::VariableEnvironmentEntry::isExported): (JSC::VariableEnvironmentEntry::isImported): (JSC::VariableEnvironmentEntry::isImportedNamespace): (JSC::VariableEnvironmentEntry::isFunction): (JSC::VariableEnvironmentEntry::setIsCaptured): (JSC::VariableEnvironmentEntry::setIsConst): (JSC::VariableEnvironmentEntry::setIsExported): (JSC::VariableEnvironmentEntry::setIsImported): (JSC::VariableEnvironmentEntry::setIsImportedNamespace): (JSC::VariableEnvironmentEntry::setIsFunction): (JSC::VariableEnvironmentEntry::clearIsVar): (JSC::VariableEnvironment::VariableEnvironment): (JSC::VariableEnvironment::begin): (JSC::VariableEnvironment::end): * tests/es6.yaml: * tests/stress/block-scoped-function-declarations.js: Added. (assert): (test): (f.foo.bar): (f.foo.): (f.foo): (f): (assert.foo.): (assert.foo): (assert.foo.foo): (assert.foo.bar): (assert.foo.switch.case.1): (assert.foo.switch.case.2): (assert.foo.switch.foo): (assert.foo.switch.bar): 2016-03-09 Saam barati Array.isArray support for Proxy https://bugs.webkit.org/show_bug.cgi?id=155179 Reviewed by Mark Lam. This patch implements Array.isArray to be compliant with the ES6 spec. Specifically, it needs to interface properly with Proxy arguments. https://tc39.github.io/ecma262/#sec-isarray * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::getCallData): (JSC::arrayConstructorIsArray): (JSC::arrayConstructorPrivateFuncIsArrayConstructor): * runtime/ArrayPrototype.cpp: (JSC::speciesConstructArray): * runtime/ProxyObject.cpp: (JSC::ProxyObject::revoke): (JSC::ProxyObject::isRevoked): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: (JSC::ProxyObject::target): (JSC::ProxyObject::handler): * tests/es6.yaml: * tests/stress/proxy-is-array.js: Added. (assert): (test): 2016-03-09 Benjamin Poulain [JSC] Fix the ARM64 MacroAssembler after r197816 https://bugs.webkit.org/show_bug.cgi?id=155268 Reviewed by Mark Lam. The patch tries to generate instructions that do not exist, causing quite fun stuff at runtime. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load8): (JSC::MacroAssemblerARM64::store16): (JSC::MacroAssemblerARM64::store8): 2016-03-09 Commit Queue Unreviewed, rolling out r197873. https://bugs.webkit.org/show_bug.cgi?id=155262 "Crashes some JSC tests" (Requested by mlam on #webkit). Reverted changeset: "Add dumping of function expression names in CodeBlock bytecode dump." https://bugs.webkit.org/show_bug.cgi?id=155248 http://trac.webkit.org/changeset/197873 2016-03-09 Oliver Hunt Fix old iOS * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps): 2016-03-09 Oliver Hunt Wincairo buildfix https://bugs.webkit.org/show_bug.cgi?id=155245 Reviewed by Mark Lam. Fix up exports for a few symbols * jit/ExecutableAllocator.h: * jit/ExecutableAllocatorFixedVMPool.cpp: 2016-03-09 Mark Lam Add dumping of function expression names in CodeBlock bytecode dump. https://bugs.webkit.org/show_bug.cgi?id=155248 Reviewed by Filip Pizlo. Because ... [ 19] new_func_exp loc5, loc3, f0:foo ... is more informative than [ 19] new_func_exp loc5, loc3, f0 Anonymous functions will be dumped as . * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpFunctionExpr): (JSC::CodeBlock::dumpBytecode): * bytecode/CodeBlock.h: 2016-03-09 Michael Saboff [ES6] Implement RegExp sticky flag and related functionality https://bugs.webkit.org/show_bug.cgi?id=155177 Reviewed by Saam Barati. Implemented the ES6 RegExp sticky functionality. There are two main behavior changes when the sticky flag is specified. 1) Matching starts at lastIndex and lastIndex is updated after the match. 2) The regular expression is only matched from the start position in the string. See ES6 section 21.2.5.2.2 for details. Changed both the Yarr interpreter and jit to not loop to the next character for sticky RegExp's. Updated RegExp exec and match, and stringProtoFuncMatch to handle lastIndex changes. Restructured the way flags are passed to and through YarrPatterns to use RegExpFlags instead of individual bools. Updated tests for 'y' flag and new behavior. * bytecode/CodeBlock.cpp: (JSC::regexpToSourceString): * inspector/ContentSearchUtilities.cpp: (Inspector::ContentSearchUtilities::findMagicComment): * runtime/CommonIdentifiers.h: * runtime/RegExp.cpp: (JSC::regExpFlags): (JSC::RegExpFunctionalTestCollector::outputOneTest): (JSC::RegExp::finishCreation): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/RegExp.h: * runtime/RegExpKey.h: * runtime/RegExpObjectInlines.h: (JSC::RegExpObject::execInline): (JSC::RegExpObject::matchInline): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncCompile): (JSC::flagsString): (JSC::regExpProtoGetterMultiline): (JSC::regExpProtoGetterSticky): (JSC::regExpProtoGetterUnicode): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncMatch): * tests/es6.yaml: * tests/stress/static-getter-in-names.js: (shouldBe): * yarr/RegularExpression.cpp: (JSC::Yarr::RegularExpression::Private::compile): * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::tryConsumeBackReference): (JSC::Yarr::Interpreter::matchAssertionBOL): (JSC::Yarr::Interpreter::matchAssertionEOL): (JSC::Yarr::Interpreter::matchAssertionWordBoundary): (JSC::Yarr::Interpreter::matchDotStarEnclosure): (JSC::Yarr::Interpreter::matchDisjunction): (JSC::Yarr::Interpreter::Interpreter): (JSC::Yarr::ByteCompiler::atomPatternCharacter): * yarr/YarrInterpreter.h: (JSC::Yarr::BytecodePattern::BytecodePattern): (JSC::Yarr::BytecodePattern::estimatedSizeInBytes): (JSC::Yarr::BytecodePattern::ignoreCase): (JSC::Yarr::BytecodePattern::multiline): (JSC::Yarr::BytecodePattern::sticky): (JSC::Yarr::BytecodePattern::unicode): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::matchCharacterClass): (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals): (JSC::Yarr::YarrGenerator::generateAssertionBOL): (JSC::Yarr::YarrGenerator::generateAssertionEOL): (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce): (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed): (JSC::Yarr::YarrGenerator::generateDotStarEnclosure): (JSC::Yarr::YarrGenerator::backtrack): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor): (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter): (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets): (JSC::Yarr::YarrPatternConstructor::optimizeBOL): (JSC::Yarr::YarrPattern::compile): (JSC::Yarr::YarrPattern::YarrPattern): * yarr/YarrPattern.h: (JSC::Yarr::YarrPattern::reset): (JSC::Yarr::YarrPattern::nonwordcharCharacterClass): (JSC::Yarr::YarrPattern::ignoreCase): (JSC::Yarr::YarrPattern::multiline): (JSC::Yarr::YarrPattern::sticky): (JSC::Yarr::YarrPattern::unicode): 2016-03-09 Mark Lam FunctionExecutable::ecmaName() should not be based on inferredName(). https://bugs.webkit.org/show_bug.cgi?id=155203 Reviewed by Michael Saboff. The ES6 rules for how a function name should be inferred closely matches JSC's implementation with one exception: var o = {} o.foo = function() {} JSC's inferredName for o.foo would be "foo". ES6 specifies that o.foo.name is "". The fix is to add a distinct FunctionExecutable::ecmaName() which applies the ES6 rules for inferring the initial value of Function.name. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): * bytecode/UnlinkedFunctionExecutable.h: * parser/ASTBuilder.h: (JSC::ASTBuilder::createAssignResolve): (JSC::ASTBuilder::createGetterOrSetterProperty): (JSC::ASTBuilder::createProperty): (JSC::ASTBuilder::makeAssignNode): * parser/Nodes.h: * runtime/Executable.h: * runtime/JSFunction.cpp: (JSC::JSFunction::reifyName): * tests/es6.yaml: 2016-03-09 Michael Saboff Harden JSC Root element functions from bad values https://bugs.webkit.org/show_bug.cgi?id=155234 Reviewed by Saam Barati. Changed jsCast() to jsDynamicCast() in Root related function to protect against being called with non-Root arguments. * jsc.cpp: (functionCreateElement): (functionGetElement): (functionSetElementRoot): 2016-03-09 Benjamin Poulain [JSC] Pick how to OSR Enter to FTL at runtime instead of compile time https://bugs.webkit.org/show_bug.cgi?id=155217 Reviewed by Filip Pizlo. This patch addresses 2 types of problems with tiering up to FTL with OSR Entry in a loop: -When there are nested loops, it is generally valuable to enter an outer loop rather than an inner loop. -When tiering up at a point that cannot OSR Enter, we are at the mercy of the outer loop frequency to compile the right entry point. The first case is significant in the test "gaussian-blur". That test has 4 nested loops. When we have an OSR Entry, the analysis phases have to be pesimistic where we enter: we do not really know what constraint can be proven from the DFG code that was running. In "gaussian-blur", integer-range analysis removes pretty much all overflow checks in the inner loops of where we entered. The more outside we enter, the better code we generate. Since we spend the most iterations in the inner loop, we naturally tend to OSR Enter into the 2 most inner loops, making the most pessimistic assumptions. To avoid such problems, I changed how we decide where to OSR Enter. Previously, the last CheckTierUpAndOSREnter to cross the threshold was where we take the entry point for FTL. What happens now is that the entry point is not decied when compiling the CheckTierUp variants. Instead, all the information we need is gathered during compilation and keept on the JITCode to be used at runtime. When we try to tier up and decide to OSR Enter, we use the information we have to pick a good outer loop for OSR Entry. Now the problem is outer loop do not CheckTierUpAndOSREnter often, wasting several miliseconds before entering the newly compiled FTL code. To solve that, every CheckTierUpAndOSREnter has its own trigger that bypass the counter. When the FTL Code is compiled, the trigger is set and we enter through the right CheckTierUpAndOSREnter immediately. --- This new mechanism also solves a problem of ai-astar. When we try to tier up in ai-astar, we had nothing to compile until the outer loop is reached. To make sure we reached the CheckTierUpAndOSREnter in a reasonable time, we had CheckTierUpWithNestedTriggerAndOSREnter with a special trigger. With the new mechanism, we can do much better: -When we keep hitting CheckTierUpInLoop, we now have all the information we need to already start compiling the outer loop. Instead of waiting for the outer loop to be reached a few times, we compile it as soon as the inner loop is hammering CheckTierUpInLoop. -With the new triggers, the very next time we hit the outer loop, we OSR Enter. This allow us to compile what we need sooner and enter sooner. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): Deleted. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): Deleted. * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): Deleted. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): Deleted. * dfg/DFGJITCode.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::JITCompiler): (JSC::DFG::JITCompiler::compileEntryExecutionFlag): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPlan.h: (JSC::DFG::Plan::canTierUpAndOSREnter): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): Deleted. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): Deleted. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): Deleted. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap): (JSC::DFG::TierUpCheckInjectionPhase::findLoopsContainingLoopHintWithoutOSREnter): Deleted. * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp: (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback): (JSC::DFG::RefToFTLForOSREntryDeferredCompilationCallback::create): (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously): (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete): * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h: 2016-03-08 Filip Pizlo DFG should be able to constant-fold strings https://bugs.webkit.org/show_bug.cgi?id=155200 Reviewed by Geoffrey Garen. This adds constant-folding of string1 + string2 and string.length. The actual folding rule is easy, but there are some gotchas. The problem is that the DFG cannot allocate new JSString objects until we are on the main thread. So, DFG IR must have a node for a JSValue string constant that hasn't been created yet - i.e. it doesn't have any concrete JSValue bits yet. We have the ability to speak of such things, using LazyJSValue. But that's a class, not a node type. This patch now adds a node type, LazyJSConstant, which is a Node that holds a LazyJSValue. This puts us in a weird situation: AI uses JSValue to represent constants. It would take a lot of work to change it to use LazyJSValue. So, this implements the constant folding in StrengthReductionPhase. I created a bug and put a FIXME about moving these rules into AI. OTOH, our experience in B3 shows that constant folding in strength reduction is quite nice. It would totally make sense to have strength reduction have constant folding rules that mirror the rules in AI, or to factor out the AI constant folding rules, the same way that B3 factors out those rules into Value methods. Another issue is how to represent the cumulative result of possibly many foldings. I initially considered adding LazyJSValue kinds that represented concatenation. Folding the concatenation to a constant meand that this constant was actually a LazyJSValue that represented the concatenation of two other things. But this would get super messy if we wanted to fold an operation that uses the results of another folded operation. So, the JIT thread folds string operations by creating a WTF::String that contains the result. The DFG::Graph holds a +1 on the underlying StringImpl, so we can pass the StringImpl* around without reference counting. The LazyJSValue now has a special kind that means: we created this StringImpl* on the JIT thread, and once the JIT is done, we will relinquish ownership of it. LazyJSValue has some magic to emit code for these to-be-created-JSStrings while also transferring ownership of the StringImpl from the JIT thread to the main thread and registering the JSString with the GC. This just implements folding for concatenation and GetArrayLength. It's just a proof of concept for evil things I want to do later. This change is a 2.5x speed-up on the string concatenation microbenchmarks I added in this patch. * 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/DFGFrozenValue.cpp: (JSC::DFG::FrozenValue::emptySingleton): (JSC::DFG::FrozenValue::tryGetString): (JSC::DFG::FrozenValue::dumpInContext): * dfg/DFGFrozenValue.h: (JSC::DFG::FrozenValue::strength): * dfg/DFGGraph.h: * dfg/DFGLazyJSValue.cpp: (JSC::DFG::LazyJSValue::newString): (JSC::DFG::LazyJSValue::getValue): (JSC::DFG::equalToStringImpl): (JSC::DFG::LazyJSValue::tryGetStringImpl): (JSC::DFG::LazyJSValue::tryGetString): (JSC::DFG::LazyJSValue::strictEqual): (JSC::DFG::LazyJSValue::switchLookupValue): (JSC::DFG::LazyJSValue::emit): (JSC::DFG::LazyJSValue::dumpInContext): * dfg/DFGLazyJSValue.h: (JSC::DFG::LazyJSValue::LazyJSValue): (JSC::DFG::LazyJSValue::knownStringImpl): (JSC::DFG::LazyJSValue::kind): (JSC::DFG::LazyJSValue::tryGetValue): (JSC::DFG::LazyJSValue::character): (JSC::DFG::LazyJSValue::stringImpl): * dfg/DFGMayExit.cpp: (JSC::DFG::mayExit): * dfg/DFGNode.cpp: (JSC::DFG::Node::convertToIdentityOn): (JSC::DFG::Node::convertToLazyJSConstant): (JSC::DFG::Node::convertToPutHint): (JSC::DFG::Node::convertToPutClosureVarHint): (JSC::DFG::Node::tryGetString): (JSC::DFG::Node::promotedLocationDescriptor): * dfg/DFGNode.h: (JSC::DFG::Node::convertToConstant): (JSC::DFG::Node::convertToConstantStoragePointer): (JSC::DFG::Node::castConstant): (JSC::DFG::Node::hasLazyJSValue): (JSC::DFG::Node::lazyJSValue): (JSC::DFG::Node::initializationValueForActivation): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex): (JSC::DFG::SpeculativeJIT::compileLazyJSConstant): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileInt52Constant): (JSC::FTL::DFG::LowerDFGToB3::compileLazyJSConstant): (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep): 2016-03-08 Joseph Pecoraro Web Inspector: Memory Timeline should show MemoryPressure events https://bugs.webkit.org/show_bug.cgi?id=155158 Reviewed by Brian Burg. * inspector/protocol/Memory.json: 2016-03-08 Joseph Pecoraro Web Inspector: Add Heap domain start/stop tracking commands https://bugs.webkit.org/show_bug.cgi?id=155190 Reviewed by Brian Burg. * inspector/agents/InspectorHeapAgent.cpp: (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend): (Inspector::InspectorHeapAgent::startTracking): (Inspector::InspectorHeapAgent::stopTracking): * inspector/agents/InspectorHeapAgent.h: * inspector/protocol/Heap.json: 2016-03-08 Joseph Pecoraro Web Inspector: Add a way to create a Heap Snapshot https://bugs.webkit.org/show_bug.cgi?id=155188 Reviewed by Brian Burg. * inspector/agents/InspectorHeapAgent.h: * inspector/protocol/Heap.json: * inspector/agents/InspectorHeapAgent.cpp: (Inspector::InspectorHeapAgent::snapshot): Take a heap snapshot and return the JSON string result. * inspector/protocol/Debugger.json: Remove unused optional inferredName. Our displayName would be inferred. 2016-03-08 Oliver Hunt Fix ios bot build. * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps): 2016-03-08 Mark Lam Implement Function.name support for getters/setters and inferring name of function properties. https://bugs.webkit.org/show_bug.cgi?id=154865 Rubber-stamped by Joseph Pecoraro. Follow up to the fix for this bug: adding a few small clean-ups for issues Joe pointed out in the bug. * runtime/JSBoundSlotBaseFunction.cpp: (JSC::JSBoundSlotBaseFunction::create): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): 2016-03-08 Oliver Hunt Start moving to separated writable and executable mappings in the JIT https://bugs.webkit.org/show_bug.cgi?id=155178 Reviewed by Fil Pizlo. Start moving to a separate writable and executable heap for the various JITs. As part of our work to harden the JIT against various attacks, we're moving away from our current RWX heap and on to using separate RW and X mappings. This means that simply leaking the location of the executable mapping is not sufficient to compromise JSC, so we can continue to use direct executable pointers in our GC objects (which we need for performance), but keep the writable pointer in only a single location so that we are less likely to leak the address. To further obscure the address of the writable region we place it in an execute only region of memory so that it is not possible to read the location from anywhere. That means an attacker must have at least partial control of PC (to call jitMemCopy) before they can start to attack the JIT. This work is initially ARM64 only, as we use as the jitMemCopy is currently specific to that platform's calling conventions and layout. We're just landing it in the current form so that we can at least ensure it doesn't regress. * Configurations/FeatureDefines.xcconfig: * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::ldp): (JSC::ARM64Assembler::ldnp): (JSC::ARM64Assembler::fillNops): (JSC::ARM64Assembler::stp): (JSC::ARM64Assembler::stnp): (JSC::ARM64Assembler::replaceWithJump): (JSC::ARM64Assembler::replaceWithLoad): (JSC::ARM64Assembler::replaceWithAddressComputation): (JSC::ARM64Assembler::setPointer): (JSC::ARM64Assembler::repatchInt32): (JSC::ARM64Assembler::repatchCompact): (JSC::ARM64Assembler::linkJumpOrCall): (JSC::ARM64Assembler::linkCompareAndBranch): (JSC::ARM64Assembler::linkConditionalBranch): (JSC::ARM64Assembler::linkTestAndBranch): (JSC::ARM64Assembler::loadStoreRegisterPairOffset): (JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): (JSC::LinkBuffer::allocate): * assembler/LinkBuffer.h: (JSC::LinkBuffer::LinkBuffer): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::sub64): (JSC::MacroAssemblerARM64::load64): (JSC::MacroAssemblerARM64::loadPair64): (JSC::MacroAssemblerARM64::loadPair64WithNonTemporalAccess): (JSC::MacroAssemblerARM64::load8): (JSC::MacroAssemblerARM64::store64): (JSC::MacroAssemblerARM64::storePair64): (JSC::MacroAssemblerARM64::storePair64WithNonTemporalAccess): (JSC::MacroAssemblerARM64::store8): (JSC::MacroAssemblerARM64::branchAdd64): (JSC::MacroAssemblerARM64::branchSub64): * jit/ExecutableAllocator.h: (JSC::performJITMemcpy): * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps): (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator): * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/Options.h: 2016-03-08 Mark Lam Implement Function.name support for getters/setters and inferring name of function properties. https://bugs.webkit.org/show_bug.cgi?id=154865 Reviewed by Geoffrey Garen. 1. toString() no longer uses the value of Function.name as the name of the function in the returned string, because ... i. Function.name is supposed to be configurable. Hence, it can be made writable and can be set to any JSValue, or deleted. ii. Function.prototype.toString() is supposed to produce a string that can be eval'ed. Hence, for JS functions, the function name in the produced string must be a legal function name (and not some arbitrary value set in Function.name). For example, while a number is a legal value for Function.name, it is not legal as the function name in the toString() string. Instead, we'll always use the original name from the JS source that the function was parsed from. 2. JSFunction::name() now always return the original name, not the value of the Function.name property. As a result, it also no longer needs an ExecState* arg. If the original name is an empty string, JSFunction::name() will use the inferred name. 3. For JS functions, the original name can be attained from their FunctionExecutable object. For host/native functions (which do not have a FunctionExecutable), we get the "original" name from its NativeExecutable. 4. The m_hostFunctionStubMap now keys its NativeExecutable pointers using the original name, in addition to the native function and constructor pointers. This is needed because we want a different NativeExecutable for functions with a different name (to satisfy (3) above). 5. Changed JSBoundFunction to store the name of its bound function in its NativeExecutable. This will later be used to generate the toString() string. It's Function.name value is eagerly initialized at construction time. 6. Function.name for getters/setters are now prefixed with "get"/"set". This was done both for the JSBoundSlotBaseFunctions and JS definable get/set functions. 7. Added InternalFunction::m_originalName so that we can use it to generate the toString() string. We're storing it as a JSString instead of a WTF::String only because we want InternalFunction to be continue to be trivially destructible. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::functionDetails): * jit/JITThunks.cpp: (JSC::JITThunks::finalize): (JSC::JITThunks::hostFunctionStub): * jit/JITThunks.h: * runtime/Executable.h: * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncToString): * runtime/InternalFunction.cpp: (JSC::InternalFunction::finishCreation): (JSC::InternalFunction::visitChildren): (JSC::InternalFunction::name): (JSC::InternalFunction::displayName): * runtime/InternalFunction.h: * runtime/JSBoundFunction.cpp: (JSC::JSBoundFunction::create): (JSC::JSBoundFunction::visitChildren): (JSC::JSBoundFunction::toStringName): Deleted. * runtime/JSBoundFunction.h: (JSC::JSBoundFunction::boundThis): (JSC::JSBoundFunction::boundArgs): (JSC::JSBoundFunction::createStructure): * runtime/JSBoundSlotBaseFunction.cpp: (JSC::boundSlotBaseFunctionCall): (JSC::JSBoundSlotBaseFunction::create): * runtime/JSFunction.cpp: (JSC::JSFunction::initializeRareData): (JSC::JSFunction::name): (JSC::JSFunction::displayName): (JSC::JSFunction::calculatedDisplayName): (JSC::JSFunction::reifyName): * runtime/JSFunction.h: * tests/es6.yaml: 2016-03-08 Commit Queue Unreviewed, rolling out r197793 and r197799. https://bugs.webkit.org/show_bug.cgi?id=155195 something weird happened while landing this and everything broke (Requested by olliej on #webkit). Reverted changesets: "Start moving to separated writable and executable mappings in the JIT" https://bugs.webkit.org/show_bug.cgi?id=155178 http://trac.webkit.org/changeset/197793 "arm64 build fix after r197793." http://trac.webkit.org/changeset/197799 2016-03-08 Alex Christensen arm64 build fix after r197793. * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): (JSC::FixedVMPoolExecutableAllocator::initializeBulletproofJIT): (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator): Use consistent ENABLE macro. It looks like it was partially renamed. 2016-03-08 Filip Pizlo Regexp matching should incur less call overhead https://bugs.webkit.org/show_bug.cgi?id=155181 Reviewed by Geoffrey Garen. Previously we had DFG/FTL code call into the DFGOperation, which then called in to RegExpObject, which then called into createRegExpMatchesArray, which then called into RegExp, which then called the code generated by Yarr. Now we have DFG/FTL code call into the DFGOperation, which does all of the things and calls into code generated by Yarr. This is another tiny Octane/regexp speed-up. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOperations.cpp: * runtime/RegExp.cpp: (JSC::regExpFlags): (JSC::RegExp::compile): (JSC::RegExp::match): (JSC::RegExp::compileMatchOnly): (JSC::RegExp::deleteCode): (JSC::RegExpFunctionalTestCollector::clearRegExp): Deleted. (JSC::RegExp::compileIfNecessary): Deleted. (JSC::RegExp::compileIfNecessaryMatchOnly): Deleted. * runtime/RegExp.h: * runtime/RegExpInlines.h: Added. (JSC::RegExpFunctionalTestCollector::clearRegExp): (JSC::RegExp::compileIfNecessary): (JSC::RegExp::matchInline): (JSC::RegExp::compileIfNecessaryMatchOnly): * runtime/RegExpMatchesArray.cpp: (JSC::createEmptyRegExpMatchesArray): (JSC::createStructureImpl): (JSC::tryCreateUninitializedRegExpMatchesArray): Deleted. (JSC::createRegExpMatchesArray): Deleted. * runtime/RegExpMatchesArray.h: (JSC::tryCreateUninitializedRegExpMatchesArray): (JSC::createRegExpMatchesArray): * runtime/RegExpObject.cpp: (JSC::RegExpObject::put): (JSC::RegExpObject::exec): (JSC::RegExpObject::match): (JSC::getLastIndexAsUnsigned): Deleted. * runtime/RegExpObject.h: (JSC::RegExpObject::getLastIndex): (JSC::RegExpObject::test): (JSC::RegExpObject::testInline): * runtime/RegExpObjectInlines.h: Added. (JSC::getRegExpObjectLastIndexAsUnsigned): (JSC::RegExpObject::execInline): (JSC::RegExpObject::matchInline): 2016-03-08 Mark Lam synthesizePrototype() and friends need to be followed by exception checks (or equivalent). https://bugs.webkit.org/show_bug.cgi?id=155169 Reviewed by Geoffrey Garen. With the exception checks, we may end up throwing new exceptions over an existing one that has been thrown but not handled yet, thereby obscuring it. It may also mean that the VM will continue running on potentially unstable state, which may have undesirable consequences. I first observed this in some failed assertion while running tests on a patch for https://bugs.webkit.org/show_bug.cgi?id=154865. Performance is neutral with this patch (tested on x86_64). 1. Deleted JSNotAnObject, and removed all uses of it. 2. Added exception checks, when needed, following calls to synthesizePrototype() and JSValue::toObject(). The cases that do not need an exception check are the ones that already ensures that JSValue::toObject() is only called on a value that is convertible to an object. In those cases, I added an assertion that no exception was thrown after the call. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/ScriptCallStackFactory.cpp: (Inspector::createScriptCallStackFromException): * interpreter/Interpreter.cpp: * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncJoin): (JSC::arrayProtoFuncConcat): (JSC::arrayProtoFuncPop): (JSC::arrayProtoFuncPush): (JSC::arrayProtoFuncReverse): (JSC::arrayProtoFuncShift): (JSC::arrayProtoFuncSlice): (JSC::arrayProtoFuncSplice): (JSC::arrayProtoFuncUnShift): (JSC::arrayProtoFuncIndexOf): (JSC::arrayProtoFuncLastIndexOf): (JSC::arrayProtoFuncValues): (JSC::arrayProtoFuncEntries): (JSC::arrayProtoFuncKeys): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/ExceptionHelpers.cpp: * runtime/JSCJSValue.cpp: (JSC::JSValue::toObjectSlowCase): (JSC::JSValue::toThisSlowCase): (JSC::JSValue::synthesizePrototype): (JSC::JSValue::putToPrimitive): (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCJSValueInlines.h: (JSC::JSValue::getPropertySlot): (JSC::JSValue::get): * runtime/JSFunction.cpp: * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncProtoGetter): * runtime/JSNotAnObject.cpp: Removed. * runtime/JSNotAnObject.h: Removed. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorDefineProperties): (JSC::objectConstructorCreate): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncValueOf): (JSC::objectProtoFuncHasOwnProperty): (JSC::objectProtoFuncIsPrototypeOf): (JSC::objectProtoFuncToString): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2016-03-08 Oliver Hunt Start moving to separated writable and executable mappings in the JIT https://bugs.webkit.org/show_bug.cgi?id=155178 Reviewed by Filip Pizlo. Start moving to a separate writable and executable heap for the various JITs. As part of our work to harden the JIT against various attacks, we're moving away from our current RWX heap and on to using separate RW and X mappings. This means that simply leaking the location of the executable mapping is not sufficient to compromise JSC, so we can continue to use direct executable pointers in our GC objects (which we need for performance), but keep the writable pointer in only a single location so that we are less likely to leak the address. To further obscure the address of the writable region we place it in an execute only region of memory so that it is not possible to read the location from anywhere. That means an attacker must have at least partial control of PC (to call jitMemCopy) before they can start to attack the JIT. This work is initially ARM64 only, as we use as the jitMemCopy is currently specific to that platform's calling conventions and layout. We're just landing it in the current form so that we can at least ensure it doesn't regress. * Configurations/FeatureDefines.xcconfig: * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::ldp): (JSC::ARM64Assembler::ldnp): (JSC::ARM64Assembler::fillNops): (JSC::ARM64Assembler::stp): (JSC::ARM64Assembler::stnp): (JSC::ARM64Assembler::replaceWithJump): (JSC::ARM64Assembler::replaceWithLoad): (JSC::ARM64Assembler::replaceWithAddressComputation): (JSC::ARM64Assembler::setPointer): (JSC::ARM64Assembler::repatchInt32): (JSC::ARM64Assembler::repatchCompact): (JSC::ARM64Assembler::linkJumpOrCall): (JSC::ARM64Assembler::linkCompareAndBranch): (JSC::ARM64Assembler::linkConditionalBranch): (JSC::ARM64Assembler::linkTestAndBranch): (JSC::ARM64Assembler::loadStoreRegisterPairOffset): (JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal): * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::copyCompactAndLinkCode): (JSC::LinkBuffer::allocate): * assembler/LinkBuffer.h: (JSC::LinkBuffer::LinkBuffer): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::sub64): (JSC::MacroAssemblerARM64::load64): (JSC::MacroAssemblerARM64::loadPair64): (JSC::MacroAssemblerARM64::loadPair64WithNonTemporalAccess): (JSC::MacroAssemblerARM64::load8): (JSC::MacroAssemblerARM64::store64): (JSC::MacroAssemblerARM64::storePair64): (JSC::MacroAssemblerARM64::storePair64WithNonTemporalAccess): (JSC::MacroAssemblerARM64::store8): (JSC::MacroAssemblerARM64::branchAdd64): (JSC::MacroAssemblerARM64::branchSub64): * jit/ExecutableAllocator.h: (JSC::performJITMemcpy): * jit/ExecutableAllocatorFixedVMPool.cpp: (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): (JSC::FixedVMPoolExecutableAllocator::initializeBulletproofJIT): (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator): * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/Options.h: 2016-03-08 Michael Saboff [ES6] Regular Expression canonicalization tables for Unicode need to be updated to use Unicode CaseFolding.txt https://bugs.webkit.org/show_bug.cgi?id=155114 Reviewed by Darin Adler. Extracted out the Unicode canonicalization table creation from YarrCanonicalizeUnicode.js into a new Python script, generateYarrCanonicalizeUnicode. That script generates the Unicode tables as the file YarrCanonicalizeUnicode.cpp in DerivedSources/JavaScriptCore. Updated the processing of ignore case to make the ASCII short cuts dependent on whether or not we are a Unicode pattern. Renamed yarr/YarrCanonicalizeUnicode.{cpp,js} back to their prior names, YarrCanonicalizeUCS2.{cpp,js}. Renamed yarr/YarrCanonicalizeUnicode.h to YarrCanonicalize.h as it declares both the legacy UCS2 and Unicode tables. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * generateYarrCanonicalizeUnicode: Added. * ucd: Added. * ucd/CaseFolding.txt: Added. The current verion, 8.0, of the Unicode CaseFolding table. * yarr/YarrCanonicalizeUCS2.cpp: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.cpp. * yarr/YarrCanonicalize.h: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.h. * yarr/YarrCanonicalizeUCS2.js: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUnicode.js. (printHeader): * yarr/YarrCanonicalizeUnicode.cpp: Removed. * yarr/YarrCanonicalizeUnicode.h: Removed. * yarr/YarrCanonicalizeUnicode.js: Removed. * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::tryConsumeBackReference): * yarr/YarrJIT.cpp: * yarr/YarrPattern.cpp: (JSC::Yarr::CharacterClassConstructor::putChar): 2016-03-08 Andreas Kling WeakBlock::visit() should check for a WeakHandleOwner before consulting mark bits. Reviewed by Darin Adler. Reorder the checks in WeakBlock::visit() so we don't look at the mark bits in MarkedBlock unless the current WeakImpl has a WeakHandleOwner we need to consult. I was originally hoping to make an optimization that could skip over entire WeakBlocks if they didn't have a single WeakHandleOwner, but it turns out that scenario is not as common as I suspected. * heap/WeakBlock.cpp: (JSC::WeakBlock::visit): 2016-03-07 Saam barati [ES6] Implement revocable proxies https://bugs.webkit.org/show_bug.cgi?id=154321 Reviewed by Mark Lam. This patch is a straight forward implementation of Proxy.revocable with respect to section 26.2.2.1 of the ECMAScript spec. https://tc39.github.io/ecma262/#sec-proxy.revocable This patch also fixes a bug in Proxy where we were incorrectly caching "in", i.e, `"x" in proxy`. We should never blatantly cache this because caching is observable behavior by users of the language. We could come up with a smarter caching scheme that caches only if the Proxy's handler doesn't have a "has" property, i.e, we don't have to call out to JS code. But for now, it's easiest to disable caching. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::moduleRecordStructure): (JSC::JSGlobalObject::moduleNamespaceObjectStructure): (JSC::JSGlobalObject::proxyObjectStructure): (JSC::JSGlobalObject::proxyRevokeStructure): (JSC::JSGlobalObject::wasmModuleStructure): * runtime/ProxyConstructor.cpp: (JSC::ProxyConstructor::create): (JSC::ProxyConstructor::ProxyConstructor): (JSC::makeRevocableProxy): (JSC::proxyRevocableConstructorThrowError): (JSC::ProxyConstructor::finishCreation): (JSC::constructProxyObject): * runtime/ProxyConstructor.h: (JSC::ProxyConstructor::createStructure): * runtime/ProxyObject.cpp: (JSC::ProxyObject::finishCreation): (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (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): (JSC::ProxyObject::getPrototype): (JSC::ProxyObject::revoke): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: (JSC::ProxyObject::create): * runtime/ProxyRevoke.cpp: Added. (JSC::ProxyRevoke::create): (JSC::ProxyRevoke::ProxyRevoke): (JSC::ProxyRevoke::finishCreation): (JSC::performProxyRevoke): (JSC::ProxyRevoke::getCallData): (JSC::ProxyRevoke::visitChildren): * runtime/ProxyRevoke.h: Added. (JSC::ProxyRevoke::createStructure): (JSC::ProxyRevoke::proxy): (JSC::ProxyRevoke::setProxyToNull): * tests/stress/proxy-has-property.js: (assert): (assert.let.handler.has): (assert.let.foo): * tests/stress/proxy-revoke.js: Added. (assert): (throw.new.Error.): (throw.new.Error): (callAllHandlers): (shouldThrowNullHandler): (allHandlersShouldThrow): (i.let.trap.of.traps.trap.string_appeared_here.func): (i.let.trap.of.traps.else.func): (i.Proxy.revocable): 2016-03-07 Csaba Osztrogonác Fix the ARM build after r197687 https://bugs.webkit.org/show_bug.cgi?id=155128 Reviewed by Saam Barati. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::moveZeroToDouble): 2016-03-07 Filip Pizlo Reduce the number of instructions needed to record the last regexp result https://bugs.webkit.org/show_bug.cgi?id=155161 Reviewed by Sam Weinig. This tightens up RegExpCachedResult::record(). My profiling shows that we spend just over 1% of the time in Octane/regexp in this function. This function had two obvious redundancies: 1) It executed the write barrier on owner twice. It only needs to execute it once. Since the same RegExpConstructor is likely to be used many times, it makes sense to do the barrier without looking at the 'to' objects at all. In steady state, this means that the RegExpConstructor will simply be OldGrey so this one barrier will always skip the slow path. 2) It cleared some fields that didn't need to be cleared, since we can just use m_reified to indicate that the fields are not meaningful anymore. This is meant to be a microscopic regexp speed-up. * runtime/RegExpCachedResult.cpp: (JSC::RegExpCachedResult::visitChildren): (JSC::RegExpCachedResult::lastResult): * runtime/RegExpCachedResult.h: (JSC::RegExpCachedResult::record): 2016-03-07 Filip Pizlo createRegExpMatchesArray should allocate substrings more quickly https://bugs.webkit.org/show_bug.cgi?id=155160 Reviewed by Sam Weinig. This was calling a version of jsSubstring() that isn't inlineable because it was doing a lot of checks in finishCreation(). In particular, it was checking that the base string is not itself a substring and that it's been resolved. We don't need those checks here, since the string must have been resolved prior to regexp processing. This patch is also smart about whether to do checks for the empty and full substrings. In the matches array loop, these checks are super unlikely to be profitable, so we just unconditionally allocate the substring. This removes those checks and makes the allocation inlineable. It looks like a 1% speed-up on Octane/regexp. * runtime/JSString.h: (JSC::jsSubstring): (JSC::jsSubstringOfResolved): * runtime/RegExpMatchesArray.cpp: (JSC::createRegExpMatchesArray): 2016-03-07 Benjamin Poulain [JSC] Small clean up of how we use SSA's valuesAtHead https://bugs.webkit.org/show_bug.cgi?id=155152 Reviewed by Filip Pizlo. liveAtHead and valuesAtHead contain the same nodes, we do not need the extra look up. This also opens the way to use the same kind of liveness analysis as Air (where live values at head do not use a set). * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::beginBasicBlock): (JSC::DFG::InPlaceAbstractState::merge): 2016-03-07 Brian Burg Web Inspector: the protocol generator should generate factory method stubs for protocol types https://bugs.webkit.org/show_bug.cgi?id=155103 Reviewed by Timothy Hatcher. Generate stubs with unique names so that parsing methods can be used reflectively at runtime, based on the protocol version that's loaded. * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/scripts/codegen/__init__.py: * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py: Added. For each type in a domain, add a method of the form -[ProtocolTypeConversions _parseXXX:fromPayload]. This is in a category method, and the selector is only ever looked up at runtime. (ObjCProtocolTypeConversionsHeaderGenerator.generate_output): * inspector/scripts/generate-inspector-protocol-bindings.py: (generate_from_specification): Rebaseline test results with new generator output. * 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-03-07 Filip Pizlo RegExp.prototype.exec() should call into Yarr at most once https://bugs.webkit.org/show_bug.cgi?id=155139 Reviewed by Saam Barati. For apparently no good reason, RegExp.prototype.match() was calling into Yarr twice, almost as if it was hoping that the non-matching case was so common that it was best to have the matching case do the work all over again. This is a 4% speed-up on Octane/regexp. It's also a matter of common sense: we should not be in the business of presuming whether someone's match will succeed or fail. The increased cost of running Yarr twice is so much larger than whatever savings we were getting from running a match-only regexp that this is just not a good overall deal for the engine. Also, it's interesting that we are seeing a 4% speed-up on regexp despite the fact that a majority (almost a supermajority, I think) of calls into RegExp.prototype.match() are failed matches. So, this change is a 4% speed-up despite being a slow down on the common case. That tells you just how bad the old behavior was on the uncommon case. * runtime/MatchResult.h: (MatchResult::MatchResult): (MatchResult::failed): (MatchResult::operator bool): * runtime/RegExpCachedResult.cpp: (JSC::RegExpCachedResult::lastResult): * runtime/RegExpConstructor.h: (JSC::RegExpConstructor::setMultiline): (JSC::RegExpConstructor::multiline): (JSC::RegExpConstructor::performMatch): (JSC::RegExpConstructor::recordMatch): * runtime/RegExpMatchesArray.cpp: (JSC::createRegExpMatchesArray): (JSC::createEmptyRegExpMatchesArray): (JSC::createStructureImpl): * runtime/RegExpMatchesArray.h: (JSC::createRegExpMatchesArray): * runtime/RegExpObject.cpp: (JSC::RegExpObject::put): (JSC::getLastIndexAsUnsigned): (JSC::RegExpObject::exec): (JSC::RegExpObject::match): * runtime/RegExpObject.h: (JSC::RegExpObject::getLastIndex): (JSC::RegExpObject::test): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncMatch): 2016-03-07 Joseph Pecoraro Heap Snapshot should include different Edge types and data (Property, Index, Variable) https://bugs.webkit.org/show_bug.cgi?id=154937 Reviewed by Geoffrey Garen. * heap/SlotVisitor.cpp: (JSC::SlotVisitor::appendHidden): * heap/SlotVisitor.h: * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::appendHidden): (JSC::SlotVisitor::appendValuesHidden): Add new visit methods to visit a reference without snapshotting the edge. * heap/Heap.cpp: (JSC::AddExtraHeapSnapshotEdges::AddExtraHeapSnapshotEdges): (JSC::AddExtraHeapSnapshotEdges::operator()): (JSC::Heap::addHeapSnapshotEdges): (JSC::Heap::removeDeadHeapSnapshotNodes): (JSC::Heap::collectImpl): * heap/Heap.h: After marking, visit the live cells for a chance to record extra heap snapshotting information about the cell. * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::appendNode): (JSC::HeapSnapshotBuilder::appendEdge): (JSC::HeapSnapshotBuilder::appendPropertyNameEdge): (JSC::HeapSnapshotBuilder::appendVariableNameEdge): (JSC::HeapSnapshotBuilder::appendIndexEdge): (JSC::HeapSnapshotBuilder::json): * heap/HeapSnapshotBuilder.h: (JSC::HeapSnapshotEdge::HeapSnapshotEdge): Construct edges with extra data. * runtime/ClassInfo.h: * runtime/JSCell.cpp: (JSC::JSCell::heapSnapshot): * runtime/JSCell.h: Add a new method to provide cells with an opportunity to provide extra heap snapshotting information. * runtime/JSObject.cpp: (JSC::JSObject::visitButterfly): (JSC::JSObject::visitChildren): (JSC::JSObject::heapSnapshot): (JSC::JSFinalObject::visitChildren): * runtime/JSObject.h: Capture object property names and index names when heap snapshotting. Do not include them as internal edges in normal visitChildren. * runtime/JSEnvironmentRecord.cpp: (JSC::JSEnvironmentRecord::visitChildren): (JSC::JSEnvironmentRecord::heapSnapshot): * runtime/JSEnvironmentRecord.h: * runtime/JSSegmentedVariableObject.cpp: (JSC::JSSegmentedVariableObject::visitChildren): (JSC::JSSegmentedVariableObject::heapSnapshot): * runtime/JSSegmentedVariableObject.h: Capture scope variable names when heap snapshotting. * runtime/Structure.cpp: (JSC::Structure::visitChildren): * runtime/Structure.h: * runtime/StructureInlines.h: (JSC::Structure::propertyTable): When performing a heap snapshotting collection, don't clear the property table so that accessing the table during this GC is okay. * tests/heapProfiler/driver/driver.js: * tests/heapProfiler/property-edge-types.js: Added. * tests/heapProfiler/variable-edge-types.js: Added. Tests covering the different edge types and data we capture. 2016-03-07 Saam barati [ES6] Implement Proxy.[[GetPrototypeOf]] https://bugs.webkit.org/show_bug.cgi?id=155099 Reviewed by Mark Lam. This patch is a straight forward implementation of Proxy.[[GetPrototypeOf]] with respect to section 9.5.1 of the ECMAScript spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-getprototypeof * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::setPrototype): (JSC::ProxyObject::performGetPrototype): (JSC::ProxyObject::getPrototype): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: * tests/es6.yaml: * tests/stress/proxy-get-prototype-of.js: Added. (assert): (throw.new.Error.let.handler.get getPrototypeOf): (throw.new.Error.get let): (throw.new.Error.get catch): (throw.new.Error): (assert.let.handler.getPrototypeOf): (assert.get let): (assert.get catch): (assert.): (let.handler.getPrototypeOf): (get let): (let.handler.has): 2016-03-07 Brian Burg Web Inspector: rename generated *EnumConversionHelpers.h to *TypeConversions.h https://bugs.webkit.org/show_bug.cgi?id=155121 Reviewed by Timothy Hatcher. Split out this renaming from the work to generate factory method stubs for types. * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/scripts/codegen/__init__.py: * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py: (ObjCConfigurationImplementationGenerator.generate_output): * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py: (ObjCFrontendDispatcherImplementationGenerator.generate_output): * inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objc_conversion_helpers.py. * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator.generate_output): * inspector/scripts/codegen/objc_generator_templates.py: * inspector/scripts/generate-inspector-protocol-bindings.py: (generate_from_specification): Rebaseline tests after changing generator order. * 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-03-07 Benjamin Poulain [JSC] Improve and64() and or64() with immediate on x86 https://bugs.webkit.org/show_bug.cgi?id=155104 Reviewed by Geoffrey Garen. GetButterflyReadOnly was doing: movq 0x8(%rbx), %r9 movq $0xfffffffffffffffc, %r11 andq %r11, %r9 There is no need for the move to load the immediate, andq sign extend its immediate. With this patch, we have: movq 0x8(%rbx), %r9 andq $0xfffffffffffffffc, %r9 * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::and64): (JSC::MacroAssemblerX86_64::or64): 2016-03-07 Brian Burg Web Inspector: It should be possible to initialize generated ObjC protocol types from an NSDictionary payload https://bugs.webkit.org/show_bug.cgi?id=155102 Reviewed by Timothy Hatcher. In Objective-C code, we sometimes prefer to parse JSON using Cocoa rather than the InspectorValue classes. Support initializing protocol objects directly from an NSDictionary payload. This delegates validation of values to the setter methods that already exist on the protocol object classes. * inspector/scripts/codegen/generate_objc_header.py: (ObjCHeaderGenerator._generate_type_interface): * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator.generate_type_implementation): (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_payload): * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator.payload_to_objc_expression_for_member): Add a new helper method to generate an expression to unpack the value from an NSDictionary. If it's not a primitive, the setter performs validation of the value's kind using -[NSObject isKindOfClass:]. Rebaseline relevant tests. * 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/events-with-optional-parameters.json-result: * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result: * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result: * inspector/scripts/tests/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result: 2016-03-07 Benjamin Poulain [JSC] Simplify the overflow check of ArithAbs https://bugs.webkit.org/show_bug.cgi?id=155063 Reviewed by Geoffrey Garen. The only integer that overflow abs(int32) is INT_MIN. For some reason, our code testing for that case was checking the top bit of the result specifically. The code required a large immediate on x86 and an extra register on ARM64. This patch turns the overflow check into a branch on the sign of the result. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArithAbs): * jit/ThunkGenerators.cpp: (JSC::absThunkGenerator): * tests/stress/arith-abs-overflow.js: Added. (opaqueAbs): 2016-03-07 Benjamin Poulain [JSC] Improve how DFG zero Floating Point registers https://bugs.webkit.org/show_bug.cgi?id=155096 Reviewed by Geoffrey Garen. DFG had a weird way of zeroing a FPR: -zero a GP. -move that to a FP. Filip added moveZeroToDouble() for B3. This patch uses that in the lower tiers. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::moveZeroToDouble): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): * jit/ThunkGenerators.cpp: (JSC::floorThunkGenerator): (JSC::roundThunkGenerator): 2016-03-07 Andreas Kling REGRESSION (r197303): Web Inspector crashes web process when inspecting an element on TOT Reviewed by Geoffrey Garen. Guard against null pointer dereference for UnlinkedCodeBlocks that don't have any control flow profiling data. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::hasOpProfileControlFlowBytecodeOffsets): 2016-03-07 Benjamin Poulain [JSC] Remove a useless "Move" from baseline-JIT op_mul's fast path https://bugs.webkit.org/show_bug.cgi?id=155071 Reviewed by Geoffrey Garen. We do not need to multiply to a scratch and then move the result to the destination. We can just multiply to the destination. * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_mul): * jit/JITMulGenerator.cpp: (JSC::JITMulGenerator::generateFastPath): 2016-03-07 Yusuke Suzuki [JSC] StringObject.{put, defineOwnProperty} should realize indexed properties https://bugs.webkit.org/show_bug.cgi?id=155089 Reviewed by Geoffrey Garen. Through implementing Reflect.set[1], we found StringObject does not obey the spec. StringObject::put should call putByIndex if the given propertyName is index. And StringObject::defineOwnProperty should recognize indexed properties since JSObject::defineOwnIndexedProperty is specialized to JSObject layout. Before calling JSObject::defineOwnProperty, StringObject should handle its special indexed own properties. It is responsibility of StringObject::defineOwnProperty. And the logic is cleaned up by using validateAndApplyPropertyDescriptor. [1]: https://bugs.webkit.org/show_bug.cgi?id=155024 * runtime/StringObject.cpp: (JSC::StringObject::put): (JSC::StringObject::putByIndex): (JSC::isStringOwnProperty): (JSC::StringObject::defineOwnProperty): (JSC::StringObject::deleteProperty): * tests/stress/string-object-define-own-property.js: Added. (shouldBe): (shouldThrow): * tests/stress/string-object-put-by-index.js: Added. (shouldBe): (shouldThrow): (testSloppy): (testStrict): 2016-03-06 Brian Burg Web Inspector: the protocol generator should have separate prefix options for Objective-C classes and filenames https://bugs.webkit.org/show_bug.cgi?id=155101 Reviewed by Timothy Hatcher. It should be possible to generate Objective-C protocol types without prefixing all class names. The prefixes are only necessary when the generated files are part of a framework, but this isn't how the generated Objective-C frontend files are used. Add a separate framework setting and switch over code to use the 'protocol_group' in filenames, and the 'objc_prefix' for Objective-C enum and class prefixes. No tests need to be rebaselined because tests always set the protocol_group and objc_prefix to the same value. * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py: (ObjCBackendDispatcherHeaderGenerator.output_filename): * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py: (ObjCConfigurationImplementationGenerator.output_filename): (ObjCConfigurationImplementationGenerator.generate_output): * inspector/scripts/codegen/generate_objc_configuration_header.py: (ObjCConfigurationHeaderGenerator.output_filename): (ObjCConfigurationHeaderGenerator.generate_output): (ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains): * inspector/scripts/codegen/generate_objc_configuration_implementation.py: (ObjCBackendDispatcherImplementationGenerator.output_filename): (ObjCBackendDispatcherImplementationGenerator.generate_output): (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains): * inspector/scripts/codegen/generate_objc_conversion_helpers.py: (ObjCConversionHelpersGenerator.output_filename): * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py: (ObjCFrontendDispatcherImplementationGenerator.output_filename): (ObjCFrontendDispatcherImplementationGenerator.generate_output): * inspector/scripts/codegen/generate_objc_header.py: (ObjCHeaderGenerator.output_filename): * inspector/scripts/codegen/generate_objc_internal_header.py: (ObjCInternalHeaderGenerator.output_filename): (ObjCInternalHeaderGenerator.generate_output): * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator.output_filename): (ObjCProtocolTypesImplementationGenerator.generate_output): * inspector/scripts/codegen/models.py: * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator): (ObjCGenerator.protocol_name): (ObjCGenerator.objc_prefix): 2016-03-06 Brian Burg Unreviewed, rebaseline inspector protocol generator tests after r197563. * 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/generate-domains-with-feature-guards.json-result: 2016-03-06 Benjamin Poulain [JSC] Improve DFG's Int32 ArithMul if one operand is a constant https://bugs.webkit.org/show_bug.cgi?id=155066 Reviewed by Filip Pizlo. When multiplying an integer by a constant, DFG was doing quite a bit worse than baseline JIT. We were loading the constant into a register, doing the multiply, the checking the result and both operands for negative zero. This patch changes: -Use the multiply-by-immediate form on x86. -Do as few checks as possible to detect negative-zero. In most cases, this reduce the negative-zero checks to zero or one TEST+JUMP. * assembler/MacroAssembler.h: (JSC::MacroAssembler::mul32): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMul): 2016-03-06 Benjamin Poulain [JSC] Remove a superfluous Move in front of every double unboxing https://bugs.webkit.org/show_bug.cgi?id=155064 Reviewed by Saam Barati. Double unboxing was always doing: Move source, scratch Add64 tag, scratch IntToDouble scratch, fp We do not need to "Move" to copy the source. Both x86 and ARM64 have an efficient 3 operands Add instruction. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileDoubleRep): (JSC::DFG::SpeculativeJIT::speculateRealNumber): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::unboxDouble): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::unboxDoubleWithoutAssertions): (JSC::AssemblyHelpers::unboxDouble): (JSC::AssemblyHelpers::unboxDoubleNonDestructive): 2016-03-06 Benjamin Poulain [JSC] Use 3 operands Add in more places https://bugs.webkit.org/show_bug.cgi?id=155082 Reviewed by Filip Pizlo. * assembler/MacroAssembler.h: (JSC::MacroAssembler::addPtr): (JSC::MacroAssembler::add32): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::add32): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithAdd): The case with child1 constant is useless. The canonical form will have the constant as child2. Also add register reuse for the fast-add. Registers are a scarce resource on x86. * jit/CCallHelpers.h: (JSC::CCallHelpers::prepareForTailCallSlow): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generate): 2016-03-06 Benjamin Poulain [JSC] Improve codegen of Compare and Test https://bugs.webkit.org/show_bug.cgi?id=155055 Reviewed by Filip Pizlo. This patch introduces a few improvements on how we lower Compare and Test with immediates: -Add certain Immediate forms of ARM64. -Use CBZ/CBNZ when possible on ARM64. -When possible, convert a CMP into a TST On some hardware, we can issue more TST simultaneously. On x86, any TST+Jump is candidate for macro-fusion. They are also smaller. (sections 3.4.2.2 and 3.5.1.9) -Do not load the mask immediate of a TST if it only contains ones (mostly useful for ARM64 since that would not have been a valid immediate). * assembler/MacroAssembler.h: (JSC::MacroAssembler::compare32): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare): (JSC::MacroAssemblerARM64::moveDoubleConditionallyAfterFloatingPointCompare): This is somewhat unrelated but I found that out while working on moveDoubleConditionallyTest32: If "thenCase" and "dest" are assigned the same register by the allocator, then the first (f)fcsel would override the "thenCase" and the second fcsel would always be "elseCase". This is covered by testb3 but was only uncovered after recent "Move" removals in lowering. (JSC::MacroAssemblerARM64::moveConditionally32): (JSC::MacroAssemblerARM64::moveConditionally64): (JSC::MacroAssemblerARM64::moveConditionallyTest32): (JSC::MacroAssemblerARM64::moveDoubleConditionally32): (JSC::MacroAssemblerARM64::moveDoubleConditionally64): (JSC::MacroAssemblerARM64::moveDoubleConditionallyTest32): (JSC::MacroAssemblerARM64::branch32): (JSC::MacroAssemblerARM64::branch64): (JSC::MacroAssemblerARM64::branchTest32): (JSC::MacroAssemblerARM64::test32): The version taking an immediate was guarded by (cond == Zero) || (cond == NonZero). That is overzealous, and only needed for CBZ/CBNZ. (JSC::MacroAssemblerARM64::branchTest64): (JSC::MacroAssemblerARM64::compare32): (JSC::MacroAssemblerARM64::compare64): (JSC::MacroAssemblerARM64::commuteCompareToZeroIntoTest): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::moveConditionally32): (JSC::MacroAssemblerX86Common::moveConditionallyTest32): (JSC::MacroAssemblerX86Common::branch32): (JSC::MacroAssemblerX86Common::test32): (JSC::MacroAssemblerX86Common::branchTest32): (JSC::MacroAssemblerX86Common::compare32): (JSC::MacroAssemblerX86Common::commuteCompareToZeroIntoTest): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::compare64): (JSC::MacroAssemblerX86_64::branch64): (JSC::MacroAssemblerX86_64::moveConditionally64): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::createGenericCompare): Unfortunately this cannot be abstracted by the MacroAssembler. Those immediates are not valid, we have to pick the better for right away. * b3/air/AirOpcode.opcodes: * b3/testb3.cpp: (JSC::B3::int64Operands): (JSC::B3::modelCompare): (JSC::B3::testCompareImpl): (JSC::B3::testCompare): (JSC::B3::b3Pow): (JSC::B3::testPowDoubleByIntegerLoop): Some versions of pow(double, int) do not return the exact same bits as our integer loop. Added a new version to have the same behavior as the B3 loop. (JSC::B3::run): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileInt32Compare): Comparing to an immediate is super common. Do not waste a register for that! 2016-03-06 Filip Pizlo Unreviewed, fix build. This was a messed up merge. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): 2016-03-06 Filip Pizlo DFG should know how to speculate StringOrOther https://bugs.webkit.org/show_bug.cgi?id=155094 Reviewed by Saam Barati. Any code that processes the regexp matches array was previously doing a relatively expensive Branch(Untyped:). This introduces a new use kind called StringOrOther, which is perfect for code that loops over the matches array and branches on the entries being non-empty. To do this, I needed to introduce code into the FTL that creates new blocks. We still had that awful FTL_NEW_BLOCK idiom since the only way to debug LLVM IR was to ascribe names to basic blocks. B3 IR is inherently more debuggable since unlike LLVM, B3 knows how to always respect code origin, and it knows how to print the code origin nicely in the dumps. So, rather than continue using FTL_NEW_BLOCK(m_out, ("things")), I replaced all of that stuff with m_out.newBlock(). It's much nicer that way. This is a tiny speed-up on Octane/regexp at best. I was hoping for more. Oh well. * bytecode/SpeculatedType.h: (JSC::isStringSpeculation): (JSC::isStringOrOtherSpeculation): (JSC::isSymbolSpeculation): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateString): (JSC::DFG::Node::shouldSpeculateStringOrOther): (JSC::DFG::Node::shouldSpeculateStringObject): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileStringZeroLength): (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther): (JSC::DFG::SpeculativeJIT::emitStringBranch): (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch): (JSC::DFG::SpeculativeJIT::compileConstantStoragePointer): (JSC::DFG::SpeculativeJIT::speculateObjectOrOther): (JSC::DFG::SpeculativeJIT::speculateString): (JSC::DFG::SpeculativeJIT::speculateStringOrOther): (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::emitBranch): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::emitBranch): * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep): (JSC::FTL::DFG::LowerDFGToB3::compileBooleanToNumber): (JSC::FTL::DFG::LowerDFGToB3::compileToThis): (JSC::FTL::DFG::LowerDFGToB3::compileArithMul): (JSC::FTL::DFG::LowerDFGToB3::compileArithDiv): (JSC::FTL::DFG::LowerDFGToB3::compileArithMod): (JSC::FTL::DFG::LowerDFGToB3::compileArithMinOrMax): (JSC::FTL::DFG::LowerDFGToB3::compileArithPow): (JSC::FTL::DFG::LowerDFGToB3::compileArithRound): (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructure): (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): (JSC::FTL::DFG::LowerDFGToB3::compileGetById): (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage): (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (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::compileCopyRest): (JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength): (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize): (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): (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::compileMultiGetByOffset): (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset): (JSC::FTL::DFG::LowerDFGToB3::compileNotifyWrite): (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileSwitch): (JSC::FTL::DFG::LowerDFGToB3::compileIsString): (JSC::FTL::DFG::LowerDFGToB3::compileIsObject): (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull): (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction): (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf): (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty): (JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty): (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname): (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorStructurePname): (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorGenericPname): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::compileCheckWatchdogTimer): (JSC::FTL::DFG::LowerDFGToB3::checkStructure): (JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32): (JSC::FTL::DFG::LowerDFGToB3::checkInferredType): (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl): (JSC::FTL::DFG::LowerDFGToB3::loadVectorWithBarrier): (JSC::FTL::DFG::LowerDFGToB3::copyBarrier): (JSC::FTL::DFG::LowerDFGToB3::loadVectorReadOnly): (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject): (JSC::FTL::DFG::LowerDFGToB3::nonSpeculativeCompare): (JSC::FTL::DFG::LowerDFGToB3::stringsEqual): (JSC::FTL::DFG::LowerDFGToB3::allocateCell): (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject): (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorageAndGetEnd): (JSC::FTL::DFG::LowerDFGToB3::allocateObject): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::boolify): (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined): (JSC::FTL::DFG::LowerDFGToB3::contiguousPutByValOutOfBounds): (JSC::FTL::DFG::LowerDFGToB3::switchString): (JSC::FTL::DFG::LowerDFGToB3::switchStringRecurse): (JSC::FTL::DFG::LowerDFGToB3::buildTypeOf): (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32): (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32): (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToJSValue): (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52): (JSC::FTL::DFG::LowerDFGToB3::convertDoubleToInt32): (JSC::FTL::DFG::LowerDFGToB3::speculate): (JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther): (JSC::FTL::DFG::LowerDFGToB3::speculateObjectOrOther): (JSC::FTL::DFG::LowerDFGToB3::speculateString): (JSC::FTL::DFG::LowerDFGToB3::speculateStringOrOther): (JSC::FTL::DFG::LowerDFGToB3::speculateStringIdent): (JSC::FTL::DFG::LowerDFGToB3::speculateStringOrStringObject): (JSC::FTL::DFG::LowerDFGToB3::speculateRealNumber): (JSC::FTL::DFG::LowerDFGToB3::speculateNotStringVar): (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier): (JSC::FTL::DFG::LowerDFGToB3::callCheck): * ftl/FTLOutput.cpp: (JSC::FTL::Output::initialize): (JSC::FTL::Output::newBlock): (JSC::FTL::Output::check): * ftl/FTLOutput.h: (JSC::FTL::Output::setFrequency): (JSC::FTL::Output::insertNewBlocksBefore): 2016-03-06 Saam Barati [[GetPrototypeOf]] should be a fully virtual method in the method table https://bugs.webkit.org/show_bug.cgi?id=155002 Reviewed by Filip Pizlo. This patch makes us more consistent with how the ES6 specification models the [[GetPrototypeOf]] trap. Moving this method into ClassInfo::methodTable is a prerequisite for implementing Proxy.[[GetPrototypeOf]]. This patch still allows directly accessing the prototype for situations where this is the desired behavior. This is equivalent to getting the internal [[Prototype]] field as described in the specification. * API/JSObjectRef.cpp: (JSObjectGetPrototype): (JSObjectSetPrototype): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): (JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): * jit/JITOperations.cpp: * jit/JITOperations.h: * jsc.cpp: (functionCreateProxy): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArrayPrototype.cpp: (JSC::speciesConstructArray): * runtime/ClassInfo.h: * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncBind): * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototypeGetterCompare): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeGetterFormat): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototypeGetterFormat): * runtime/JSBoundFunction.cpp: (JSC::hasInstanceBoundFunction): (JSC::getBoundFunctionStructure): (JSC::JSBoundFunction::create): * runtime/JSBoundFunction.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSCell.cpp: (JSC::JSCell::setPrototype): (JSC::JSCell::getPrototype): * runtime/JSCell.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::hasLegacyProfiler): (JSC::lastInPrototypeChain): (JSC::JSGlobalObject::objectPrototypeIsSane): (JSC::JSGlobalObject::arrayPrototypeChainIsSane): (JSC::JSGlobalObject::stringPrototypeChainIsSane): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::finishCreation): * runtime/JSGlobalObjectFunctions.cpp: (JSC::GlobalFuncProtoGetterFunctor::GlobalFuncProtoGetterFunctor): (JSC::GlobalFuncProtoGetterFunctor::operator()): (JSC::globalFuncProtoGetter): * runtime/JSLexicalEnvironment.cpp: (JSC::JSLexicalEnvironment::getOwnPropertySlot): * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): (JSC::JSObject::putInlineSlow): (JSC::JSObject::setPrototypeWithCycleCheck): (JSC::JSObject::setPrototype): (JSC::JSObject::getPrototype): (JSC::JSObject::defaultHasInstance): (JSC::objectPrivateFuncInstanceOf): (JSC::JSObject::getPropertyNames): (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype): (JSC::JSObject::attemptToInterceptPutByIndexOnHole): (JSC::JSObject::getGenericPropertyNames): * runtime/JSObject.h: (JSC::JSObject::finishCreation): (JSC::JSObject::JSObject): (JSC::JSObject::getPrototypeDirect): (JSC::JSObject::getPrototype): (JSC::JSObject::getOwnNonIndexPropertySlot): (JSC::JSObject::getPropertySlot): (JSC::JSObject::getNonIndexPropertySlot): (JSC::JSObject::prototype): Deleted. * runtime/JSObjectInlines.h: (JSC::JSObject::canPerformFastPutInline): * runtime/JSProxy.cpp: (JSC::JSProxy::setTarget): * runtime/JSTypedArrayViewConstructor.cpp: (JSC::constructTypedArrayView): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructorGetPrototypeOfFunctor::ObjectConstructorGetPrototypeOfFunctor): (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()): (JSC::objectConstructorGetPrototypeOf): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncIsPrototypeOf): * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performSetPrototype): * runtime/StructureInlines.h: (JSC::Structure::isValid): * tests/stress/proxy-has-property.js: (assert.let.h1.has): (assert.let.h2.has): (assert): 2016-03-06 Commit Queue Unreviewed, rolling out r197645. https://bugs.webkit.org/show_bug.cgi?id=155097 "Doesn't build properly when building entire webkit" (Requested by saamyjoon on #webkit). Reverted changeset: "[[GetPrototypeOf]] should be a fully virtual method in the method table" https://bugs.webkit.org/show_bug.cgi?id=155002 http://trac.webkit.org/changeset/197645 2016-03-06 Saam barati [[GetPrototypeOf]] should be a fully virtual method in the method table https://bugs.webkit.org/show_bug.cgi?id=155002 Reviewed by Filip Pizlo. This patch makes us more consistent with how the ES6 specification models the [[GetPrototypeOf]] trap. Moving this method into ClassInfo::methodTable is a prerequisite for implementing Proxy.[[GetPrototypeOf]]. This patch still allows directly accessing the prototype for situations where this is the desired behavior. This is equivalent to getting the internal [[Prototype]] field as described in the specification. * API/JSObjectRef.cpp: (JSObjectGetPrototype): (JSObjectSetPrototype): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): (JSC::DFG::SpeculativeJIT::compileCheckTypeInfoFlags): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_instanceof): (JSC::JIT::emitSlow_op_instanceof): * jit/JITOperations.cpp: * jit/JITOperations.h: * jsc.cpp: (functionCreateProxy): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArrayPrototype.cpp: (JSC::speciesConstructArray): * runtime/ClassInfo.h: * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncBind): * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototypeGetterCompare): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeGetterFormat): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototypeGetterFormat): * runtime/JSBoundFunction.cpp: (JSC::hasInstanceBoundFunction): (JSC::getBoundFunctionStructure): (JSC::JSBoundFunction::create): * runtime/JSBoundFunction.h: * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSCell.cpp: (JSC::JSCell::setPrototype): (JSC::JSCell::getPrototype): * runtime/JSCell.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::hasLegacyProfiler): (JSC::lastInPrototypeChain): (JSC::JSGlobalObject::objectPrototypeIsSane): (JSC::JSGlobalObject::arrayPrototypeChainIsSane): (JSC::JSGlobalObject::stringPrototypeChainIsSane): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::finishCreation): * runtime/JSGlobalObjectFunctions.cpp: (JSC::GlobalFuncProtoGetterFunctor::GlobalFuncProtoGetterFunctor): (JSC::GlobalFuncProtoGetterFunctor::operator()): (JSC::globalFuncProtoGetter): * runtime/JSLexicalEnvironment.cpp: (JSC::JSLexicalEnvironment::getOwnPropertySlot): * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): (JSC::JSObject::putInlineSlow): (JSC::JSObject::setPrototypeWithCycleCheck): (JSC::JSObject::setPrototype): (JSC::JSObject::getPrototype): (JSC::JSObject::defaultHasInstance): (JSC::objectPrivateFuncInstanceOf): (JSC::JSObject::getPropertyNames): (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype): (JSC::JSObject::attemptToInterceptPutByIndexOnHole): (JSC::JSObject::getGenericPropertyNames): * runtime/JSObject.h: (JSC::JSObject::finishCreation): (JSC::JSObject::JSObject): (JSC::JSObject::getPrototypeDirect): (JSC::JSObject::getPrototype): (JSC::JSObject::getOwnNonIndexPropertySlot): (JSC::JSObject::getPropertySlot): (JSC::JSObject::getNonIndexPropertySlot): (JSC::JSObject::prototype): Deleted. * runtime/JSObjectInlines.h: (JSC::JSObject::canPerformFastPutInline): * runtime/JSProxy.cpp: (JSC::JSProxy::setTarget): * runtime/JSTypedArrayViewConstructor.cpp: (JSC::constructTypedArrayView): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructorGetPrototypeOfFunctor::ObjectConstructorGetPrototypeOfFunctor): (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()): (JSC::objectConstructorGetPrototypeOf): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncIsPrototypeOf): * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performSetPrototype): * runtime/StructureInlines.h: (JSC::Structure::isValid): * tests/stress/proxy-has-property.js: (assert.let.h1.has): (assert.let.h2.has): (assert): 2016-03-06 Filip Pizlo RegExpMatchesArray doesn't know how to have a bad time https://bugs.webkit.org/show_bug.cgi?id=155069 Reviewed by Yusuke Suzuki. In trunk if we are having a bad time, the regexp matches array is still allocated with a non-slow-put indexing shape, which makes it have the wrong behavior on indexed setters on the prototype chain. Getting this to work right requires introducing bad time code paths into the regexp matches array. It also requires something more drastic: making this code not play games with the global object. The code that creates the matches array needs to have the actual global object of the regexp native function that it's logically created by. This is totally different from how we've handled global objects in the past because it means that the global object is not a constant. Normally we can make it a constant because a script executable will know its global object. But with native functions, it's the function instance that knows the global object - not the native executable. When we inline a native intrinsic, we are guaranteed to know the native executable but we're not guaranteed to know the functon instance. This means that the global object may be a variable that gets computed by looking at the instance at run-time. So, the RegExpExec/RegExpTest nodes in DFG IR now take a global object child. That also meant adding a new node type, GetGlobalObject, which does the thing to the callee that CallFrame::lexicalGlobalObject() would have done. Eventually, we'll probably have to make other native intrinsics also use GetGlobalObject. It turns out that this really isn't so bad because usually it's constant-folded anyway, since although the intrinsic code supports executable-based inlining (which leaves the callee instance as an unknown), it happens rarely for intrinsics. So, conveying the global object via a child isn't any worse than conveying it via meta-data, and it's probably better than telling the inliner not to do executable-based inlining of native intrinsics. That would have been a confusing special-case. This is perf-neutral on my machines but it fixes a bug and it unlocks some interesting possibilities. For example, RegExpExec can now make a firm promise about the type of array it's creating. This also contains some other changes: - We are now using Structure::addPropertyTransition() in a lot of places even though it was meant to be an internal method with a quirky contract - for example if only works if you know that there is not existing transition. This relaxes this constraint. - Restores the use of "*" for heap references in JSString.h. It's very unusual to have heap references pointed at with "&", since we don't currently do that anywhere. The fact that it was using the wrong reference type also meant that the code couldn't elegantly make use of some our GC pointer helpers like jsCast<>. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::attemptToInlineCall): (JSC::DFG::ByteCodeParser::handleMinMax): (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/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileSkipScope): (JSC::DFG::SpeculativeJIT::compileGetGlobalObject): (JSC::DFG::SpeculativeJIT::compileGetArrayLength): * 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::compileSkipScope): (JSC::FTL::DFG::LowerDFGToB3::compileGetGlobalObject): (JSC::FTL::DFG::LowerDFGToB3::compileGetClosureVar): (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec): (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest): (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp): * jit/JITOperations.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::haveABadTime): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: * runtime/JSObject.h: (JSC::JSObject::putDirectInternal): * runtime/JSString.h: (JSC::jsString): (JSC::jsSubstring): * runtime/RegExpCachedResult.cpp: (JSC::RegExpCachedResult::lastResult): * runtime/RegExpMatchesArray.cpp: (JSC::tryCreateUninitializedRegExpMatchesArray): (JSC::createRegExpMatchesArray): (JSC::createStructureImpl): (JSC::createRegExpMatchesArrayStructure): (JSC::createRegExpMatchesArraySlowPutStructure): * runtime/RegExpMatchesArray.h: * runtime/RegExpObject.cpp: (JSC::RegExpObject::put): (JSC::RegExpObject::exec): (JSC::RegExpObject::match): * runtime/RegExpObject.h: (JSC::RegExpObject::getLastIndex): (JSC::RegExpObject::test): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncTest): (JSC::regExpProtoFuncExec): (JSC::regExpProtoFuncCompile): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncMatch): * runtime/Structure.cpp: (JSC::Structure::suggestedArrayStorageTransition): (JSC::Structure::addPropertyTransition): (JSC::Structure::addNewPropertyTransition): * runtime/Structure.h: * tests/stress/regexp-matches-array-bad-time.js: Added. * tests/stress/regexp-matches-array-slow-put.js: Added. 2016-03-06 Yusuke Suzuki [JSC] RegExp#lastIndex should handle writable attribute when defining in defineOwnProperty path https://bugs.webkit.org/show_bug.cgi?id=155093 Reviewed by Filip Pizlo. Before this patch, `setLastIndex(ExecState* exec, size_t lastIndex)` always overwrites the existing value regardless of writable attribute. And when defining RegExp#lastIndex in defineOwnProperty, we need to define the value first before making the attribute readonly. After changing the writable attribute, we cannot define the value. * runtime/RegExpObject.cpp: (JSC::RegExpObject::defineOwnProperty): * runtime/RegExpObject.h: (JSC::RegExpObject::setLastIndex): * tests/stress/regexp-last-index-writable.js: Added. (shouldBe): (shouldThrow): (regExpLastIndex): 2016-03-05 Filip Pizlo The most aggressive form of RegExpTest/RegExpExec should speculate more aggressively than just cell https://bugs.webkit.org/show_bug.cgi?id=154900 Reviewed by Saam Barati. These old operations used to speculate cell. That's what they did when they were first introduced. That was probably about as good as they could do back then because we didn't have very powerful checks. Now we have powerful checks, so we can do this right. The most profitable thing to check is that child1 is a RegExpObject and child2 is a JSString. Sometimes though, we will not know what child2 is even though we know that child1 is a RegExpObject. So, this patch means that RegExpExec/RegExpTest have the following overloads: RegExpExec(RegExpObject:, String:) RegExpExec(RegExpObject:, Untyped:) RegExpExec(Untyped:, Untyped:) This shaves off some type checks in Octane/regexp. It also cleans up some problems in our modeling of the effectfulness of these operations. * 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.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec): (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest): * jit/JITOperations.h: 2016-03-05 Yusuke Suzuki [ES6] Support Reflect.construct https://bugs.webkit.org/show_bug.cgi?id=147330 Reviewed by Saam Barati. Based on Saam's r196868, this patch adds support for Reflect.construct. This patch implements OrdinaryCreateFromConstructor[1] for fallback cases. This path is rarely taken. For example, Reflect.construct(function () { }, [], Map); In this case, the `new.target` becomes `Map`. So we should create an object that `__proto__` is `Map.prototype`. And to allow forward declaration (and encouraging strong type checking), we change ConstructType, CallType to C++11 enum class. [1]: http://ecma-international.org/ecma-262/6.0/#sec-ordinarycreatefromconstructor * API/JSCallbackConstructor.cpp: (JSC::JSCallbackConstructor::getConstructData): * API/JSCallbackFunction.cpp: (JSC::JSCallbackFunction::getCallData): * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::getConstructData): (JSC::JSCallbackObject::getCallData): * API/JSObjectRef.cpp: (JSObjectIsFunction): (JSObjectCallAsFunction): (JSObjectIsConstructor): (JSObjectCallAsConstructor): * API/ObjCCallbackFunction.mm: (JSC::ObjCCallbackFunction::getCallData): (JSC::ObjCCallbackFunction::getConstructData): * bindings/ScriptFunctionCall.cpp: (Deprecated::ScriptFunctionCall::call): * bindings/ScriptValue.cpp: (Deprecated::ScriptValue::isFunction): * builtins/ReflectObject.js: * dfg/DFGOperations.cpp: * inspector/InjectedScriptManager.cpp: (Inspector::InjectedScriptManager::createInjectedScript): * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::handleHostCall): * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::getConstructData): (JSC::ArrayConstructor::getCallData): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncToString): (JSC::arrayProtoFuncToLocaleString): (JSC::getLength): Deleted. * runtime/BooleanConstructor.cpp: (JSC::BooleanConstructor::getConstructData): (JSC::BooleanConstructor::getCallData): * runtime/CallData.cpp: (JSC::call): * runtime/CallData.h: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/ConstructData.cpp: (JSC::construct): * runtime/ConstructData.h: * runtime/DateConstructor.cpp: (JSC::DateConstructor::getConstructData): (JSC::DateConstructor::getCallData): * runtime/DatePrototype.cpp: (JSC::dateProtoFuncToJSON): * runtime/Error.h: (JSC::StrictModeTypeErrorFunction::getConstructData): (JSC::StrictModeTypeErrorFunction::getCallData): * runtime/ErrorConstructor.cpp: (JSC::ErrorConstructor::getConstructData): (JSC::ErrorConstructor::getCallData): * runtime/ExceptionHelpers.cpp: (JSC::errorDescriptionForValue): * runtime/FunctionConstructor.cpp: (JSC::FunctionConstructor::getConstructData): (JSC::FunctionConstructor::getCallData): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::getCallData): (JSC::functionProtoFuncToString): (JSC::functionProtoFuncBind): * runtime/GeneratorFunctionConstructor.cpp: (JSC::GeneratorFunctionConstructor::getCallData): (JSC::GeneratorFunctionConstructor::getConstructData): * runtime/InternalFunction.cpp: (JSC::InternalFunction::getCallData): * runtime/IntlCollatorConstructor.cpp: (JSC::IntlCollatorConstructor::getConstructData): (JSC::IntlCollatorConstructor::getCallData): * runtime/IntlDateTimeFormatConstructor.cpp: (JSC::IntlDateTimeFormatConstructor::getConstructData): (JSC::IntlDateTimeFormatConstructor::getCallData): * runtime/IntlNumberFormatConstructor.cpp: (JSC::IntlNumberFormatConstructor::getConstructData): (JSC::IntlNumberFormatConstructor::getCallData): * runtime/IteratorOperations.cpp: (JSC::iteratorNext): (JSC::iteratorClose): * runtime/JSArray.h: (JSC::getLength): * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::getConstructData): (JSC::JSArrayBufferConstructor::getCallData): * runtime/JSBoundFunction.cpp: (JSC::boundFunctionCall): (JSC::boundFunctionConstruct): (JSC::JSBoundFunction::create): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::isFunction): (JSC::JSValue::isConstructor): * runtime/JSCell.cpp: (JSC::JSCell::getCallData): (JSC::JSCell::getConstructData): * runtime/JSFunction.cpp: (JSC::JSFunction::getCallData): (JSC::JSFunction::getConstructData): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewWithArguments): (JSC::JSGenericTypedArrayViewConstructor::getConstructData): (JSC::JSGenericTypedArrayViewConstructor::getCallData): * runtime/JSInternalPromise.cpp: (JSC::JSInternalPromise::then): * runtime/JSInternalPromiseConstructor.cpp: (JSC::JSInternalPromiseConstructor::getConstructData): (JSC::JSInternalPromiseConstructor::getCallData): * runtime/JSJob.cpp: (JSC::JSJobMicrotask::run): * runtime/JSONObject.cpp: (JSC::Stringifier::Stringifier): (JSC::Stringifier::toJSONImpl): (JSC::Stringifier::appendStringifiedValue): (JSC::JSONProtoFuncParse): * runtime/JSObject.cpp: (JSC::callToPrimitiveFunction): (JSC::JSObject::hasInstance): (JSC::JSObject::getMethod): * runtime/JSObject.h: (JSC::getCallData): (JSC::getConstructData): * runtime/JSPromise.cpp: (JSC::JSPromise::initialize): * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::getConstructData): (JSC::JSPromiseConstructor::getCallData): * runtime/JSPromiseDeferred.cpp: (JSC::newPromiseCapability): (JSC::callFunction): * runtime/JSTypedArrayViewConstructor.cpp: (JSC::constructTypedArrayView): (JSC::JSTypedArrayViewConstructor::getConstructData): (JSC::JSTypedArrayViewConstructor::getCallData): * runtime/MapConstructor.cpp: (JSC::constructMap): (JSC::MapConstructor::getConstructData): (JSC::MapConstructor::getCallData): * runtime/ModuleLoaderObject.cpp: (JSC::ModuleLoaderObject::provide): (JSC::ModuleLoaderObject::loadAndEvaluateModule): (JSC::ModuleLoaderObject::loadModule): (JSC::ModuleLoaderObject::linkAndEvaluateModule): * runtime/NativeErrorConstructor.cpp: (JSC::NativeErrorConstructor::getConstructData): (JSC::NativeErrorConstructor::getCallData): * runtime/NullGetterFunction.cpp: (JSC::NullGetterFunction::getCallData): (JSC::NullGetterFunction::getConstructData): * runtime/NullSetterFunction.cpp: (JSC::NullSetterFunction::getCallData): (JSC::NullSetterFunction::getConstructData): * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::getConstructData): (JSC::NumberConstructor::getCallData): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::getConstructData): (JSC::ObjectConstructor::getCallData): (JSC::toPropertyDescriptor): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncDefineGetter): (JSC::objectProtoFuncDefineSetter): (JSC::objectProtoFuncToLocaleString): * runtime/Operations.cpp: (JSC::jsTypeStringForValue): (JSC::jsIsObjectTypeOrNull): (JSC::jsIsFunctionType): * runtime/ProxyConstructor.cpp: (JSC::ProxyConstructor::getConstructData): (JSC::ProxyConstructor::getCallData): * runtime/ProxyObject.cpp: (JSC::ProxyObject::finishCreation): (JSC::performProxyCall): (JSC::ProxyObject::getCallData): (JSC::performProxyConstruct): (JSC::ProxyObject::getConstructData): * runtime/ReflectObject.cpp: (JSC::reflectObjectConstruct): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::getConstructData): (JSC::RegExpConstructor::getCallData): * runtime/RuntimeType.h: * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::processUnverifiedStackTraces): * runtime/SetConstructor.cpp: (JSC::constructSet): (JSC::SetConstructor::getConstructData): (JSC::SetConstructor::getCallData): * runtime/StringConstructor.cpp: (JSC::StringConstructor::getConstructData): (JSC::StringConstructor::getCallData): * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): (JSC::operationStringProtoFuncReplaceRegExpEmptyStr): (JSC::operationStringProtoFuncReplaceRegExpString): (JSC::replaceUsingStringSearch): * runtime/SymbolConstructor.cpp: (JSC::SymbolConstructor::getConstructData): (JSC::SymbolConstructor::getCallData): * runtime/WeakMapConstructor.cpp: (JSC::constructWeakMap): (JSC::WeakMapConstructor::getConstructData): (JSC::WeakMapConstructor::getCallData): * runtime/WeakSetConstructor.cpp: (JSC::constructWeakSet): (JSC::WeakSetConstructor::getConstructData): (JSC::WeakSetConstructor::getCallData): * tests/es6.yaml: * tests/stress/reflect-construct.js: Added. (shouldBe): (shouldThrow): (shouldThrow.array.get length): (shouldThrow.array.get 0): (array.get length): (array.get 0): (shouldBe.Reflect.construct): (shouldBe.Reflect.construct.Hello): (3.shouldBe.Reflect.construct.Hello): (3.newTarget): (0.shouldBe.Reflect.construct): (shouldBe.A): (shouldBe.B): (nativeConstructorTest.DerivedMap): (nativeConstructorTest.FailedMap): (set noInline): 2016-03-04 Andreas Kling [iOS] Throw away compiled RegExp code when navigating to a new page. Reviewed by Anders Carlsson. Add a mechanism to have the VM discard all RegExp bytecode and JIT code. * runtime/VM.cpp: (JSC::VM::deleteAllRegExpCode): * runtime/VM.h: 2016-03-04 David Kilzer REGRESSION (r197531): JavaScriptCore ASan build fails due to weak external symbol Reviewed by Alexey Proskuryakov. * runtime/JSObject.cpp: (JSC::JSObject::ordinaryToPrimitive): Don't mark this method inline since it's also used in DatePrototype.cpp, and is declared as a public class method. * runtime/JSObject.h: (JSC::JSObject::ordinaryToPrimitive): Don't export this method since it is not used outside of JavaScriptCore. 2016-03-04 Alex Christensen Remove vcxproj build system https://bugs.webkit.org/show_bug.cgi?id=154388 Rubber-stamped by Brent Fulgham. * JavaScriptCore.vcxproj/JavaScriptCore.sln: Removed. * JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: Removed. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Removed. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreCF.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreCFLite.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreDLL.cpp: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreDebug.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj.filters: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedCommon.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd: Removed. * JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd: Removed. * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreProduction.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreRelease.props: Removed. * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props: Removed. * JavaScriptCore.vcxproj/build-generated-files.pl: Removed. * JavaScriptCore.vcxproj/copy-files.cmd: Removed. 2016-03-04 Chris Dumez Location.reload should not be writable https://bugs.webkit.org/show_bug.cgi?id=154989 Reviewed by Gavin Barraclough. After r196770, operations marked as [Unforgeable] in the IDL (such as Location.reload) are correctly reported as not writable by Object.getOwnPropertyDescriptor(). Trying to set such property in JS is correctly ignored (or throws in strict mode) if the object has previously been reified. However, due to a bug in putEntry(), it was still possible to override the property if the object was not reified yet. This patch fixes the issue by checking in putEntry() that entries that are functions are not ReadOnly before calling putDirect(). * runtime/Lookup.h: (JSC::putEntry): 2016-03-04 Skachkov Oleksandr [ES6] Arrow function syntax. Lexical bind "super" inside of the arrow function in generator. https://bugs.webkit.org/show_bug.cgi?id=152575 Reviewed by Yusuke Suzuki. Added support of the 'SuperProperty' in arrow function within of the generator method of class. Before patch parser did not recognize that current arrow function is declated inside of the generator and raise SyntaxError. * parser/Parser.cpp: (JSC::Parser::parseFunctionInfo): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::isGeneratorBoundary): (JSC::Scope::setIsFunction): (JSC::Scope::setIsGenerator): (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope): * tests/stress/arrowfunction-lexical-bind-superproperty.js: 2016-03-03 Filip Pizlo DFG/FTL should inline accesses to RegExpObject::m_lastIndex https://bugs.webkit.org/show_bug.cgi?id=155003 Reviewed by Benjamin Poulain. The Octane/regexp benchmark sets RegExps' lastIndex a lot. I could imagine this being something that people want to do. Right now, I'm not convinced that making the RegExp object be more plain-JS would be a good idea considering that pretty much all uses of it will require some special compiler magic. Also, it's good that this patch teaches the compiler how to reason about lastIndex since some of my other plans for regexp involve having the compiler treat more regexp stuff as intrinsic. This is a smaller Octane/regexp speed-up than I hoped - maybe around 1%. It's an enormous speed-up on the microbenchmarks attached to this patch. * dfg/DFGAbstractHeap.h: * 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/DFGHeapLocation.h: * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal): (JSC::DFG::SpeculativeJIT::compileGetRegExpObjectLastIndex): (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStoreBarrierInsertionPhase.cpp: * ftl/FTLAbstractHeapRepository.cpp: * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace): (JSC::FTL::DFG::LowerDFGToB3::compileGetRegExpObjectLastIndex): (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex): (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack): (JSC::FTL::DFG::LowerDFGToB3::lowObject): (JSC::FTL::DFG::LowerDFGToB3::lowRegExpObject): (JSC::FTL::DFG::LowerDFGToB3::lowString): * runtime/RegExpObject.h: (JSC::RegExpObject::createStructure): (JSC::RegExpObject::offsetOfLastIndex): 2016-03-03 Chris Dumez Regression(r196770): Unable to use HipChat Mac app https://bugs.webkit.org/show_bug.cgi?id=154999 Reviewed by Darin Adler. Add a setter to PutPropertySlot to override the 'isStrictMode' flag. * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::setStrictMode): 2016-03-03 Benjamin Poulain [JSC] Add support for MADD, MSUB and MNEG to Air https://bugs.webkit.org/show_bug.cgi?id=154997 Reviewed by Filip Pizlo. ARM64 can do an Add/Sub in the Multiply units. LLVM was doing so but we lost that when switching to B3. This patch adds those instructions in Air. There are more ALUs than multiply units, thus we are more likely to successfully schedule a Multiply+Add than 2 Multiply. I am conservative and only emit a multiply-add if the value can be interned. As far as I can tell from what is generated by LLVM, that backend had the same rule. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::multiplyAdd32): (JSC::MacroAssemblerARM64::multiplySub32): (JSC::MacroAssemblerARM64::multiplyNeg32): (JSC::MacroAssemblerARM64::multiplyAdd64): (JSC::MacroAssemblerARM64::multiplySub64): (JSC::MacroAssemblerARM64::multiplyNeg64): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::lower): * b3/air/AirOpcode.opcodes: * b3/testb3.cpp: (JSC::B3::populateWithInterestingValues): (JSC::B3::floatingPointOperands): (JSC::B3::int64Operands): (JSC::B3::int32Operands): (JSC::B3::testMulAddArgsLeft): (JSC::B3::testMulAddArgsRight): (JSC::B3::testMulAddArgsLeft32): (JSC::B3::testMulAddArgsRight32): (JSC::B3::testMulSubArgsLeft): (JSC::B3::testMulSubArgsRight): (JSC::B3::testMulSubArgsLeft32): (JSC::B3::testMulSubArgsRight32): (JSC::B3::testMulNegArgs): (JSC::B3::testMulNegArgs32): (JSC::B3::run): 2016-03-03 Saam Barati [ES6] Implement Proxy.[[SetPrototypeOf]] https://bugs.webkit.org/show_bug.cgi?id=154931 Reviewed by Ryosuke Niwa. This patch is a straight forward implementation of Proxy.[[SetPrototypeOf]] with respect to section 9.5.2 of the ECMAScript spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-setprototypeof-v * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): * runtime/ProxyObject.cpp: (JSC::ProxyObject::put): (JSC::ProxyObject::getGenericPropertyNames): (JSC::ProxyObject::performSetPrototype): (JSC::ProxyObject::setPrototype): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: * tests/es6.yaml: * tests/stress/proxy-set-prototype-of.js: Added. (assert): (throw.new.Error.let.handler.get setPrototypeOf): (throw.new.Error.set let): (throw.new.Error.set catch): (throw.new.Error): (assert.let.handler.setPrototypeOf): (assert.set let): (assert.set catch): (let.handler.setPrototypeOf): (set let): (set catch): 2016-03-03 Keith Miller JSArrayBuffers should be collected less aggressively https://bugs.webkit.org/show_bug.cgi?id=154982 Reviewed by Geoffrey Garen. We are currently too aggressive in our collection of ArrayBuffer wrappers. There are three cases where we need to avoid collecting ArrayBuffer wrappers. 1. If the wrapper has custom properties. 2. If the wrapper is a subclass of ArrayBuffer. 3. If the wrapper is in a WeakMap/WeakSet. Currently, we only pass the first case in WebCore and none in the jsc CLI. This patch removes some optimizations that cause us to collect when we should not. Namely, always skipping the object unless it has custom properties. Additionally, in the case of subclassing, we also need a way for custom JSArrayBuffer objects to register themselves as the wrapper for an ArrayBuffer class. Finally, this patch fixes an issue where views would not mark their ArrayBuffer as an opaque root. This patch also moves an associated ASSERT that the ArrayBuffer held by a view is not null in JSGenericTypedArrayView::visitChildren into JSArrayBufferView::visitChildren, where we add the opaque root. * runtime/JSArrayBuffer.cpp: (JSC::JSArrayBuffer::finishCreation): (JSC::JSArrayBuffer::create): (JSC::JSArrayBuffer::createWithoutWrapping): * runtime/JSArrayBuffer.h: * runtime/JSArrayBufferView.cpp: (JSC::JSArrayBufferView::visitChildren): * runtime/JSArrayBufferView.h: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::visitChildren): Deleted. * runtime/SimpleTypedArrayController.cpp: (JSC::SimpleTypedArrayController::toJS): (JSC::SimpleTypedArrayController::registerWrapper): (JSC::SimpleTypedArrayController::JSArrayBufferOwner::isReachableFromOpaqueRoots): (JSC::SimpleTypedArrayController::JSArrayBufferOwner::finalize): * runtime/SimpleTypedArrayController.h: * runtime/TypedArrayController.h: 2016-03-03 Filip Pizlo Octane/regexp's Exec function should benefit from array length accessor inlining https://bugs.webkit.org/show_bug.cgi?id=154994 Reviewed by Benjamin Poulain. It does: var thingy = blahbitty.blah; if (thingy) foo = thingy.length; So, 'thingy' is SpecArray | SpecOther, which prevents the array length accessor inlining from kicking in. Our strategy for this elsewhere in the DFG is to allow a one-time speculation that we won't see SpecOther, since *usually* we see SpecOther mixed with other stuff in cases like this where there is some null check guarding the code. This gives another slight speed-up on Octane/regexp. * bytecode/SpeculatedType.h: (JSC::isCellSpeculation): (JSC::isCellOrOtherSpeculation): (JSC::isNotCellSpeculation): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateCell): (JSC::DFG::Node::shouldSpeculateCellOrOther): (JSC::DFG::Node::shouldSpeculateNotCell): 2016-03-03 Saam Barati Add Proxy tests for exceptions that depend on an object being non-extensible and having configurable properties https://bugs.webkit.org/show_bug.cgi?id=154745 Reviewed by Geoffrey Garen. This patch is mostly an implementation of Proxy.[[OwnPropertyKeys]] with respect to section 9.5.11 of the ECMAScript spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys This patch also changes call sites of getOwnPropertyNames and getPropertyNames to expect that an exception can be thrown. * dfg/DFGOperations.cpp: * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::iteratorEntries): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * runtime/IntlObject.cpp: (JSC::supportedLocales): * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::get): (JSC::JSValue::put): * runtime/JSONObject.cpp: (JSC::Stringifier::Holder::appendNextProperty): (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::getPropertyNames): (JSC::JSObject::getGenericPropertyNames): * runtime/JSObject.h: (JSC::makeIdentifier): (JSC::createListFromArrayLike): * runtime/JSPropertyNameEnumerator.h: (JSC::propertyNameEnumerator): * runtime/JSPropertyNameIterator.cpp: (JSC::JSPropertyNameIterator::create): * runtime/MapConstructor.cpp: (JSC::constructMap): * runtime/ObjectConstructor.cpp: (JSC::defineProperties): (JSC::objectConstructorSeal): (JSC::objectConstructorFreeze): (JSC::objectConstructorIsSealed): (JSC::objectConstructorIsFrozen): (JSC::ownPropertyKeys): * runtime/ProxyObject.cpp: (JSC::ProxyObject::getOwnPropertySlotByIndex): (JSC::ProxyObject::deleteProperty): (JSC::ProxyObject::deletePropertyByIndex): (JSC::ProxyObject::defineOwnProperty): (JSC::ProxyObject::performGetOwnPropertyNames): (JSC::ProxyObject::getOwnPropertyNames): (JSC::ProxyObject::getOwnNonIndexPropertyNames): (JSC::ProxyObject::getStructurePropertyNames): (JSC::ProxyObject::getGenericPropertyNames): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: (JSC::ProxyObject::create): (JSC::ProxyObject::createStructure): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::add): (JSC::Structure::getPropertyNamesFromStructure): (JSC::Structure::checkConsistency): (JSC::Structure::canCachePropertyNameEnumerator): (JSC::Structure::canAccessPropertiesQuicklyForEnumeration): (JSC::Structure::canAccessPropertiesQuickly): Deleted. * runtime/Structure.h: * runtime/WeakMapConstructor.cpp: (JSC::constructWeakMap): * tests/es6.yaml: * tests/stress/proxy-own-keys.js: Added. (assert): (throw.new.Error.let.handler.ownKeys): (throw.new.Error): (assert.let.handler.get ownKeys): (assert.let.handler.ownKeys): (let.handler.ownKeys): (i.catch): (shallowEq): (let.handler.getOwnPropertyDescriptor): (i.set assert): (set add): (set assert): (set if): 2016-03-03 Keith Miller Array prototype JS builtins should support Symbol.species https://bugs.webkit.org/show_bug.cgi?id=154710 Reviewed by Geoffrey Garen. Add support for Symbol.species in the Array.prototype JS builtin functions. * builtins/ArrayPrototype.js: (filter): (map): * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::finishCreation): (JSC::arrayConstructorPrivateFuncIsArrayConstructor): * runtime/ArrayConstructor.h: (JSC::ArrayConstructor::create): * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * tests/stress/array-species-functions.js: (id): 2016-03-03 Michael Saboff [ES6] Make Unicode RegExp pattern parsing conform to the spec https://bugs.webkit.org/show_bug.cgi?id=154988 Reviewed by Benjamin Poulain. Updated RegExp pattern processing with 'u' (Unicode) flag to conform to the spec (https://tc39.github.io/ecma262/2016/#sec-patterns). In the spec, the grammar is annotated with [U] annotations. Productions that are prefixed with [+U] are only available with the Unicode flags while productions prefixed with [~U] are only available without the Unicode flag. Added flags argument to Yarr::checkSyntax() so we can catch Unicode flag related parsing errors at syntax checking time. Restricted what escapes are available for non Unicode patterns. Most of this is defined in the IdentityEscape rule in the pattern grammar. Added \- as a CharacterClass only escape in Unicode patterns. Updated the tests for these changes. Made changes suggested in https://bugs.webkit.org/show_bug.cgi?id=154842#c22 after change set r197426 was landed. * parser/ASTBuilder.h: (JSC::ASTBuilder::createRegExp): * parser/Parser.cpp: (JSC::Parser::parsePrimaryExpression): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createRegExp): * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::InputStream::readChecked): (JSC::Yarr::Interpreter::InputStream::readSurrogatePairChecked): (JSC::Yarr::Interpreter::InputStream::reread): (JSC::Yarr::Interpreter::InputStream::uncheckInput): (JSC::Yarr::Interpreter::InputStream::atStart): (JSC::Yarr::Interpreter::InputStream::atEnd): (JSC::Yarr::Interpreter::testCharacterClass): (JSC::Yarr::Interpreter::backtrackPatternCharacter): (JSC::Yarr::Interpreter::matchDisjunction): (JSC::Yarr::ByteCompiler::atomPatternCharacter): * yarr/YarrParser.h: (JSC::Yarr::Parser::Parser): (JSC::Yarr::Parser::isIdentityEscapeAnError): (JSC::Yarr::Parser::parseEscape): (JSC::Yarr::Parser::parse): * yarr/YarrPattern.cpp: (JSC::Yarr::CharacterClassConstructor::putChar): (JSC::Yarr::CharacterClassConstructor::putRange): (JSC::Yarr::CharacterClassConstructor::addSorted): (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets): * yarr/YarrSyntaxChecker.cpp: (JSC::Yarr::SyntaxChecker::disjunction): (JSC::Yarr::checkSyntax): * yarr/YarrSyntaxChecker.h: 2016-03-03 Saam barati [ES6] Implement Proxy.[[DefineOwnProperty]] https://bugs.webkit.org/show_bug.cgi?id=154759 Reviewed by Geoffrey Garen and Mark Lam. This patch is a straight forward implementation of Proxy.[[DefineOwnProperty]] with respect to section 9.5.6 of the ECMAScript spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-defineownproperty-p-desc * runtime/ObjectConstructor.cpp: (JSC::objectConstructorGetOwnPropertyDescriptor): (JSC::objectConstructorGetOwnPropertyDescriptors): * runtime/ObjectConstructor.h: (JSC::constructEmptyObject): (JSC::constructObjectFromPropertyDescriptor): * runtime/ProxyObject.cpp: (JSC::ProxyObject::isExtensible): (JSC::ProxyObject::performDefineOwnProperty): (JSC::ProxyObject::defineOwnProperty): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: * tests/es6.yaml: * tests/stress/proxy-define-own-property.js: Added. (assert): (throw.new.Error): (assert.let.handler.get defineProperty): (assert.let.handler.defineProperty): (let.handler.defineProperty): (i.catch): (assert.try.): (assert.set get catch): (assert.let.setter): (assert.let.getter): (assert.set get let.handler.defineProperty): (assert.set get let): (assert.): 2016-03-03 Keith Miller [ES6] Add support for Symbol.toPrimitive https://bugs.webkit.org/show_bug.cgi?id=154877 Reviewed by Saam Barati. This patch adds suport for Symbol.toPrimitive. Since we don't currently generate snippits for one side of a binary operation we only need to change the JSObject::ToPrimitive function and update some optimizations in the DFG that need to know how conversions to primitive values should work. As of ES6, the date prototype is also no longer special cased in the ToPrimitive operation. Instead, Date.prototype has a Symbol.species function that replicates the old behavior. * bytecode/ObjectPropertyConditionSet.cpp: (JSC::generateConditionsForPropertyMissConcurrently): * bytecode/ObjectPropertyConditionSet.h: * dfg/DFGGraph.cpp: (JSC::DFG::Graph::watchConditions): (JSC::DFG::Graph::canOptimizeStringObjectAccess): * dfg/DFGGraph.h: * runtime/CommonIdentifiers.h: * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): (JSC::dateProtoFuncToPrimitiveSymbol): * runtime/Error.cpp: (JSC::throwTypeError): * runtime/Error.h: * runtime/JSCJSValueInlines.h: (JSC::toPreferredPrimitiveType): * runtime/JSObject.cpp: (JSC::callToPrimitiveFunction): (JSC::JSObject::ordinaryToPrimitive): (JSC::JSObject::defaultValue): (JSC::JSObject::toPrimitive): (JSC::JSObject::getPrimitiveNumber): (JSC::callDefaultValueFunction): Deleted. (JSC::throwTypeError): Deleted. * runtime/JSObject.h: (JSC::JSObject::toPrimitive): Deleted. * runtime/SmallStrings.h: * runtime/SymbolPrototype.cpp: (JSC::SymbolPrototype::finishCreation): * runtime/SymbolPrototype.h: (JSC::SymbolPrototype::create): * tests/es6.yaml: * tests/stress/date-symbol-toprimitive.js: Added. * tests/stress/ropes-symbol-toprimitive.js: Added. (ropify): (String.prototype.Symbol.toPrimitive): * tests/stress/symbol-toprimitive.js: Added. (foo.Symbol.toPrimitive): (catch): 2016-03-03 Filip Pizlo DFG should be able to compile StringReplace https://bugs.webkit.org/show_bug.cgi?id=154979 Reviewed by Benjamin Poulain. Adds support for StringReplace to the DFG tier. This is a 3% speed-up on Octane/regexp. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateFinalObject): (JSC::DFG::SpeculativeJIT::speculateRegExpObject): (JSC::DFG::SpeculativeJIT::speculateObjectOrOther): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITOperations.h: 2016-03-03 Saam barati [[SetPrototypeOf]] isn't properly implemented everywhere https://bugs.webkit.org/show_bug.cgi?id=154943 Reviewed by Benjamin Poulain. We were copy-pasting implememntation bits that belong in OrdinarySetPrototypeOf in a few different places that call O.[[SetPrototypeOf]](v) rather than having those bits in OrdinarySetPrototypeOf itself. We need to put those copy-pasted bits into OrdinarySetPrototypeOf and not the call sites of O.[[SetPrototypeOf]](v) because O.[[SetPrototypeOf]](v) won't always call into OrdinarySetPrototypeOf. This is needed for correctness because this behavior is now observable with the ES6 Proxy object. * runtime/ClassInfo.h: * runtime/JSCell.cpp: (JSC::JSCell::isExtensible): (JSC::JSCell::setPrototype): * runtime/JSCell.h: * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncProtoSetter): * runtime/JSObject.cpp: (JSC::JSObject::setPrototypeDirect): (JSC::JSObject::setPrototypeWithCycleCheck): (JSC::JSObject::setPrototype): (JSC::JSObject::allowsAccessFrom): * runtime/JSObject.h: (JSC::JSObject::mayInterceptIndexedAccesses): * runtime/ObjectConstructor.cpp: (JSC::objectConstructorSetPrototypeOf): * runtime/ReflectObject.cpp: (JSC::reflectObjectSetPrototypeOf): 2016-03-03 Alex Christensen Fix Windows build after r197489. * jsc.cpp: 2016-03-02 Filip Pizlo RegExpExec/RegExpTest should not unconditionally speculate cell https://bugs.webkit.org/show_bug.cgi?id=154901 Reviewed by Benjamin Poulain. This is a three part change. It all started with a simple goal: end the rage-recompiles in Octane/regexp by enabling the DFG and FTL to do untyped RegExpExec/RegExpTest. This keeps us in the optimized code when you do a regexp match on a number, for example. While implementing this, I realized that DFGOperations.cpp was bad at exception checking. When it did check for exceptions, it used exec->hadException() instead of vm.exception(). So I fixed that. I also made sure that the regexp operations checked for exception after doing toString(). Unfortunately, the introduction of untyped RegExpExec/RegExpTest caused a regression on Octane/regexp. This was because we were simultaneously scheduling replacement and OSR compiles of some large functions with the FTL JIT. The OSR compiles were not useful. This was a regression from the previous changes to make OSR compiles happen sooner. The problem is that this change also removed the throttling of OSR compiles even in those cases where we suspect that replacement is more likely. This patch reintroduces that throttling, but only in the replacement path. This change ends up being neutral overall. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec): (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest): (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp): * tests/stress/regexp-exec-effect-after-exception.js: Added. 2016-03-02 Benjamin Poulain [JSC] JSCell_freeListNext and JSCell_structureID are considered not overlapping https://bugs.webkit.org/show_bug.cgi?id=154947 Reviewed by Filip Pizlo. This bug was discovered while testing https://bugs.webkit.org/show_bug.cgi?id=154894. The problem was that JSCell_freeListNext and JSCell_structureID were considered as disjoint. When reordering instructions, the scheduler could move the write of the StructureID first to reduce dependencies. This would erase half of JSCell_freeListNext before we get a chance to load the value. This patch changes the hierarchy to make sure nothing is written until JSCell_freeListNext is processed. All credits for this patch go to Filip. * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): * ftl/FTLAbstractHeapRepository.h: 2016-03-02 Benjamin Poulain [JSC] Improve Select of Doubles based on Double condition https://bugs.webkit.org/show_bug.cgi?id=154572 Reviewed by Filip Pizlo. Octane has a bunch of Select on Double based on comparing Doubles. A few nodes generate that: ValueRep, Min, Max, etc. On ARM64, we can improve our code a lot. ARM can do a select based on flags with the FCSEL instruction. On x86, this patch adds aggressive aliasing for moveDoubleConditionallyXXX. This has obviously a much more limited impact. * assembler/MacroAssembler.h: (JSC::MacroAssembler::moveDoubleConditionally32): Deleted. (JSC::MacroAssembler::moveDoubleConditionally64): Deleted. (JSC::MacroAssembler::moveDoubleConditionallyTest32): Deleted. (JSC::MacroAssembler::moveDoubleConditionallyTest64): Deleted. (JSC::MacroAssembler::moveDoubleConditionallyDouble): Deleted. (JSC::MacroAssembler::moveDoubleConditionallyFloat): Deleted. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::moveDoubleConditionallyAfterFloatingPointCompare): (JSC::MacroAssemblerARM64::moveDoubleConditionallyDouble): (JSC::MacroAssemblerARM64::moveDoubleConditionallyFloat): (JSC::MacroAssemblerARM64::moveConditionally32): (JSC::MacroAssemblerARM64::moveDoubleConditionally32): (JSC::MacroAssemblerARM64::moveDoubleConditionally64): (JSC::MacroAssemblerARM64::moveDoubleConditionallyTest32): (JSC::MacroAssemblerARM64::moveDoubleConditionallyTest64): (JSC::MacroAssemblerARM64::branch64): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::moveConditionally32): (JSC::MacroAssemblerX86Common::moveDoubleConditionally32): (JSC::MacroAssemblerX86Common::moveDoubleConditionallyTest32): (JSC::MacroAssemblerX86Common::moveDoubleConditionallyDouble): (JSC::MacroAssemblerX86Common::moveDoubleConditionallyFloat): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::moveDoubleConditionally64): (JSC::MacroAssemblerX86_64::moveDoubleConditionallyTest64): * b3/air/AirInstInlines.h: (JSC::B3::Air::Inst::shouldTryAliasingDef): * b3/air/AirOpcode.opcodes: * b3/testb3.cpp: (JSC::B3::populateWithInterestingValues): (JSC::B3::floatingPointOperands): (JSC::B3::int64Operands): (JSC::B3::int32Operands): (JSC::B3::testSelectCompareFloat): (JSC::B3::testSelectCompareFloatToDouble): (JSC::B3::testSelectDoubleCompareDouble): (JSC::B3::testSelectDoubleCompareDoubleWithAliasing): (JSC::B3::testSelectFloatCompareFloat): (JSC::B3::testSelectFloatCompareFloatWithAliasing): (JSC::B3::run): 2016-03-02 Joseph Pecoraro Add ability to generate a Heap Snapshot https://bugs.webkit.org/show_bug.cgi?id=154847 Reviewed by Mark Lam. This adds HeapSnapshot, HeapSnapshotBuilder, and HeapProfiler. HeapProfiler hangs off of the VM and holds the list of snapshots. I expect to add other HeapProfiling features, such as allocation tracking, to the profiler. HeapSnapshot contains a collection of live cells and their identifiers. It can point to a previous HeapSnapshot, to ensure that a cell that already received an identifier maintains the same identifier across multiple snapshots. When a snapshotted cell gets garbage collected, the cell will be swept from the HeapSnapshot at the end of collection to ensure the list contains only live cells. When building a HeapSnapshot nodes are added in increasing node identifier order. When done building, the list of nodes is complete and the snapshot is finalized. At this point the nodes are sorted by JSCell* address to allow for quick lookup of a JSCell*. HeapSnapshotBuilder is where snapshotting begins. The builder will initiate a specialized heap snapshotting garbage collection. During this collection the builder will be notified of all marked (live) cells, and connections between cells, as seen by SlotVisitors. The builder can reference the previous, readonly, HeapSnapshots to avoid creating new nodes for cells that have already been snapshotted. When it is determined that we are visiting a live cell for the first time, we give the cell a unique identifier and add it to the the snapshot we are building. Since edge data is costly, and of little long term utility, this data is only held by the builder for serialization, and not stored long term with the HeapSnapshot node data. The goals of HeapSnapshotting at this time are: - minimal impact on performance when not profiling the heap - unique identifier for cells, so they may be identified across multiple snapshots - nodes and edges to be able to construct a graph of which nodes reference/retain which other nodes - node data - identifier, type (class name), size - edge data - from cell, to cell, type / data (to come in a follow-up patch) * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Add new files to the build. * heap/Heap.cpp: (JSC::Heap::isHeapSnapshotting): (JSC::RemoveDeadHeapSnapshotNodes::RemoveDeadHeapSnapshotNodes): (JSC::RemoveDeadHeapSnapshotNodes::operator()): (JSC::Heap::removeDeadHeapSnapshotNodes): (JSC::Heap::collectImpl): After every collection, sweep dead cells from in memory snapshots. * runtime/VM.cpp: (JSC::VM::ensureHeapProfiler): * runtime/VM.h: (JSC::VM::heapProfiler): * heap/Heap.h: * heap/HeapProfiler.cpp: Added. (JSC::HeapProfiler::HeapProfiler): (JSC::HeapProfiler::~HeapProfiler): (JSC::HeapProfiler::mostRecentSnapshot): (JSC::HeapProfiler::appendSnapshot): (JSC::HeapProfiler::clearSnapshots): (JSC::HeapProfiler::setActiveSnapshotBuilder): * heap/HeapProfiler.h: Added. (JSC::HeapProfiler::vm): (JSC::HeapProfiler::activeSnapshotBuilder): VM and Heap can look at the profiler to determine if we are building a snapshot, or the "head" snapshot to use for sweeping. * heap/HeapSnapshot.cpp: Added. (JSC::HeapSnapshot::HeapSnapshot): (JSC::HeapSnapshot::~HeapSnapshot): (JSC::HeapSnapshot::appendNode): Add a node to the unfinalized list of new cells. (JSC::HeapSnapshot::sweepCell): (JSC::HeapSnapshot::shrinkToFit): Collect a list of cells for sweeping and then remove them all at once in shrinkToFit. This is done to avoid thrashing of individual removes that could cause many overlapping moves within the Vector. (JSC::HeapSnapshot::finalize): Sort the list, and also cache the bounding start/stop identifiers. No other snapshot can contain an identifier in this range, so it will improve lookup of a node from an identifier. (JSC::HeapSnapshot::nodeForCell): (JSC::HeapSnapshot::nodeForObjectIdentifier): Search helpers. * heap/HeapSnapshotBuilder.h: Added. (JSC::HeapSnapshotNode::HeapSnapshotNode): (JSC::HeapSnapshotEdge::HeapSnapshotEdge): Node and Edge struct types the builder creates. * heap/HeapSnapshotBuilder.cpp: Added. (JSC::HeapSnapshotBuilder::getNextObjectIdentifier): (JSC::HeapSnapshotBuilder::HeapSnapshotBuilder): (JSC::HeapSnapshotBuilder::~HeapSnapshotBuilder): (JSC::HeapSnapshotBuilder::buildSnapshot): (JSC::HeapSnapshotBuilder::appendNode): (JSC::HeapSnapshotBuilder::appendEdge): When building the snapshot, generating the next identifier, and appending to any of the lists must be guarded by a lock because SlotVisitors running in parallel may be accessing the builder. (JSC::HeapSnapshotBuilder::hasExistingNodeForCell): Looking up if a node already exists in a previous snapshot can be done without a lock because at this point the data is readonly. (JSC::edgeTypeToNumber): (JSC::edgeTypeToString): (JSC::HeapSnapshotBuilder::json): JSON serialization of a heap snapshot contains node and edge data. * heap/SlotVisitor.h: * heap/SlotVisitor.cpp: (JSC::SlotVisitor::didStartMarking): (JSC::SlotVisitor::reset): Set/clear the active snapshot builder to know if this will be a snapshotting GC or not. (JSC::SlotVisitor::append): (JSC::SlotVisitor::setMarkedAndAppendToMarkStack): Inform the builder of a new node or edge. (JSC::SlotVisitor::visitChildren): Remember the current cell we are visiting so that if we need to inform the builder of edges we know the "from" cell. * jsc.cpp: (SimpleObject::SimpleObject): (SimpleObject::create): (SimpleObject::finishCreation): (SimpleObject::visitChildren): (SimpleObject::createStructure): (SimpleObject::hiddenValue): (SimpleObject::setHiddenValue): Create a new class "SimpleObject" that can be used by heap snapshotting tests. It is easy to filter for this new class name and test internal edge relationships created by garbage collection visiting the cell. (functionCreateSimpleObject): (functionGetHiddenValue): (functionSetHiddenValue): Expose methods to create and interact with a SimpleObject. (functionGenerateHeapSnapshot): Expose methods to create a heap snapshot. This currently automatically turns the serialized string into a JSON object. That may change. * tests/heapProfiler.yaml: Added. * tests/heapProfiler/basic-edges.js: Added. (excludeStructure): * tests/heapProfiler/basic-nodes.js: Added. (hasDifferentSizeNodes): (hasAllInternalNodes): Add tests for basic node and edge data. * tests/heapProfiler/driver/driver.js: Added. (assert): (CheapHeapSnapshotNode): (CheapHeapSnapshotEdge): (CheapHeapSnapshotEdge.prototype.get from): (CheapHeapSnapshotEdge.prototype.get to): (CheapHeapSnapshot): (CheapHeapSnapshot.prototype.get nodes): (CheapHeapSnapshot.prototype.get edges): (CheapHeapSnapshot.prototype.nodeWithIdentifier): (CheapHeapSnapshot.prototype.nodesWithClassName): (CheapHeapSnapshot.prototype.classNameFromTableIndex): (CheapHeapSnapshot.prototype.edgeTypeFromTableIndex): (createCheapHeapSnapshot): (HeapSnapshotNode): (HeapSnapshotEdge): (HeapSnapshot): (HeapSnapshot.prototype.nodesWithClassName): (createHeapSnapshot): Add two HeapSnapshot representations. CheapHeapSnapshot creates two lists of node and edge data that lazily creates objects as needed. HeapSnapshot creates an object for each node and edge. This is wasteful but easier to use. 2016-03-02 Filip Pizlo RegExpPrototype should check for exceptions after calling toString and doing so should not be expensive https://bugs.webkit.org/show_bug.cgi?id=154927 Reviewed by Saam Barati. While working on regexp optimizations, I found that RegExpPrototype calls toString(), an effectful operation that could do anything, without then checking for hadException(). So I added a call to hadException(). But that regressed Octane/regexp by 5%! That's a lot! It turns out that exec->hadException() is soooper slow. So, I made it cheaper to check for exceptions from toString(): there is now a variant called toStringFast() that returns null iff it throws an exception. This allowed me to add the exception check without regressing perf. Note that toString() must retain its old behavior of returning an empty string on exception. There is just too much code that relies on that behavior. * runtime/JSCJSValue.cpp: (JSC::JSValue::isValidCallee): (JSC::JSValue::toStringSlowCase): (JSC::JSValue::toWTFStringSlowCase): * runtime/JSCJSValue.h: (JSC::JSValue::asValue): * runtime/JSString.h: (JSC::JSValue::toString): (JSC::JSValue::toStringFast): (JSC::JSValue::toWTFString): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncTest): (JSC::regExpProtoFuncExec): (JSC::regExpProtoFuncCompile): 2016-03-02 Saam barati clean up JSObject::isExtensibleInline and JSObject::setPrototypeOfInline, and rename setPrototypeOf to setPrototype https://bugs.webkit.org/show_bug.cgi?id=154942 Reviewed by Benjamin Poulain. These don't need to be inlined in the way they are. Doing dynamic dispatch is ok performance wise until we have evidence stating otherwise. * API/JSObjectRef.cpp: (JSObjectSetPrototype): (JSObjectHasProperty): * runtime/ClassInfo.h: * runtime/IntlCollatorConstructor.cpp: (JSC::constructIntlCollator): * runtime/IntlDateTimeFormatConstructor.cpp: (JSC::constructIntlDateTimeFormat): * runtime/IntlNumberFormatConstructor.cpp: (JSC::constructIntlNumberFormat): * runtime/JSCell.cpp: (JSC::JSCell::isExtensible): (JSC::JSCell::setPrototype): (JSC::JSCell::setPrototypeOf): Deleted. * runtime/JSCell.h: * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncProtoSetter): * runtime/JSObject.cpp: (JSC::JSObject::setPrototypeWithCycleCheck): (JSC::JSObject::setPrototype): (JSC::JSObject::allowsAccessFrom): (JSC::JSObject::isExtensible): (JSC::JSObject::reifyAllStaticProperties): (JSC::JSObject::defineOwnNonIndexProperty): (JSC::JSObject::setPrototypeOf): Deleted. * runtime/JSObject.h: (JSC::JSObject::mayInterceptIndexedAccesses): (JSC::JSObject::indexingShouldBeSparse): (JSC::JSObject::setPrototypeOfInline): Deleted. (JSC::JSObject::isExtensibleInline): Deleted. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorSetPrototypeOf): (JSC::objectConstructorIsSealed): (JSC::objectConstructorIsFrozen): (JSC::objectConstructorIsExtensible): * runtime/ProxyObject.cpp: (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::performPreventExtensions): (JSC::ProxyObject::performIsExtensible): * runtime/ReflectObject.cpp: (JSC::reflectObjectIsExtensible): (JSC::reflectObjectSetPrototypeOf): * runtime/StringObject.cpp: (JSC::StringObject::defineOwnProperty): 2016-03-02 Konstantin Tokarev [cmake] Moved PRE/POST_BUILD_COMMAND to WEBKIT_FRAMEWORK. https://bugs.webkit.org/show_bug.cgi?id=154651 Reviewed by Alex Christensen. * CMakeLists.txt: Moved shared code to WEBKIT_FRAMEWORK macro. 2016-03-02 Saam barati [[SetPrototypeOf]] should be a fully virtual method in ClassInfo::methodTable https://bugs.webkit.org/show_bug.cgi?id=154897 Reviewed by Filip Pizlo. This patch makes us more consistent with how the ES6 specification models the [[SetPrototypeOf]] trap. Moving this method into ClassInfo::methodTable is a prerequisite for implementing Proxy.[[SetPrototypeOf]]. This patch still allows directly setting the prototype for situations where this is the desired behavior. This is equivalent to setting the internal [[Prototype]] field as described in the specification. * API/JSClassRef.cpp: (OpaqueJSClass::prototype): * API/JSObjectRef.cpp: (JSObjectMake): (JSObjectSetPrototype): (JSObjectHasProperty): * API/JSWrapperMap.mm: (makeWrapper): * runtime/ClassInfo.h: * runtime/IntlCollatorConstructor.cpp: (JSC::constructIntlCollator): * runtime/IntlDateTimeFormatConstructor.cpp: (JSC::constructIntlDateTimeFormat): * runtime/IntlNumberFormatConstructor.cpp: (JSC::constructIntlNumberFormat): * runtime/JSCell.cpp: (JSC::JSCell::isExtensible): (JSC::JSCell::setPrototypeOf): * runtime/JSCell.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::resetPrototype): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncProtoSetter): * runtime/JSObject.cpp: (JSC::JSObject::switchToSlowPutArrayStorage): (JSC::JSObject::setPrototypeDirect): (JSC::JSObject::setPrototypeWithCycleCheck): (JSC::JSObject::setPrototypeOf): (JSC::JSObject::allowsAccessFrom): (JSC::JSObject::setPrototype): Deleted. * runtime/JSObject.h: (JSC::JSObject::setPrototypeOfInline): (JSC::JSObject::mayInterceptIndexedAccesses): * runtime/JSProxy.cpp: (JSC::JSProxy::setTarget): * runtime/ObjectConstructor.cpp: (JSC::objectConstructorSetPrototypeOf): * runtime/ReflectObject.cpp: (JSC::reflectObjectSetPrototypeOf): 2016-03-02 Saam barati SIGSEGV in Proxy [[Get]] and [[Set]] recursion https://bugs.webkit.org/show_bug.cgi?id=154854 Reviewed by Yusuke Suzuki. We need to be aware of the possibility that the VM may recurse and that we can stack overflow. * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performPut): * tests/stress/proxy-get-and-set-recursion-stack-overflow.js: Added. (assert): (testStackOverflowGet): (testStackOverflowIndexedGet): (testStackOverflowSet): (testStackOverflowIndexedSet): 2016-03-02 Benjamin Poulain [JSC] Use a Move without REX byte when possible https://bugs.webkit.org/show_bug.cgi?id=154801 Reviewed by Alex Christensen. Filip wrote an optimization in the register allocator to use 32bit "Move" when we don't care about the top bytes. When I moved the commutative ops to the fake 3 operands instruction I largely destroyed this since all the "Moves" became full register. In this patch, I switch back to 32bit "Moves" for 32bit operations. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::and32): (JSC::MacroAssemblerX86Common::lshift32): (JSC::MacroAssemblerX86Common::mul32): (JSC::MacroAssemblerX86Common::or32): (JSC::MacroAssemblerX86Common::rshift32): (JSC::MacroAssemblerX86Common::urshift32): (JSC::MacroAssemblerX86Common::xor32): (JSC::MacroAssemblerX86Common::branchAdd32): (JSC::MacroAssemblerX86Common::branchMul32): (JSC::MacroAssemblerX86Common::branchSub32): (JSC::MacroAssemblerX86Common::move32IfNeeded): 2016-03-01 Benjamin Poulain [JSC] Simplify ArithMod(ArithMod(x, const1), const2) if const2 >= const1 https://bugs.webkit.org/show_bug.cgi?id=154904 Reviewed by Saam Barati. The ASM test "ubench" has a "x % 10 % 255". The second modulo should be eliminated. This is a 15% improvement on ASMJS' ubench. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): * tests/stress/arith-modulo-twice.js: Added. (opaqueModuloSmaller): (opaqueModuloEqual): (opaqueModuloLarger): (opaqueModuloSmallerNeg): (opaqueModuloEqualNeg): (opaqueModuloLargerNeg): (opaqueExpectedOther): 2016-03-01 Ryosuke Niwa Unreviewed. Update the status of Proxy objects to "In Development". * features.json: 2016-03-01 Commit Queue Unreviewed, rolling out r197226 and r197256. https://bugs.webkit.org/show_bug.cgi?id=154910 Caused crashes on Mac 32-bit and on ARM (Requested by ap on #webkit). Reverted changesets: "Remove the on demand executable allocator" https://bugs.webkit.org/show_bug.cgi?id=154749 http://trac.webkit.org/changeset/197226 "CLoop build fix." http://trac.webkit.org/changeset/197256 2016-03-01 Joseph Pecoraro Simplify some StringBuilder appends https://bugs.webkit.org/show_bug.cgi?id=154902 Reviewed by Mark Lam. * runtime/ExceptionHelpers.cpp: (JSC::notAFunctionSourceAppender): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::stackTracesAsJSON): Use StringBuilder::append(char) instead of append(char*) where possible. 2016-03-01 Keith Miller Promise.prototype.then should use Symbol.species to construct the return Promise https://bugs.webkit.org/show_bug.cgi?id=154862 Reviewed by Saam Barati. * builtins/PromisePrototype.js: * tests/stress/promise-species-functions.js: Added. (Symbol.species): (id): (funcThrows): (makeC): (test.species): (test.speciesThrows): (test): 2016-03-01 Michael Saboff [ES6] Add support for Unicode regular expressions https://bugs.webkit.org/show_bug.cgi?id=154842 Reviewed by Filip Pizlo. Added processing of Unicode regular expressions to the Yarr interpreter. Changed parsing of regular expression patterns and PatternTerms to process characters as UChar32 in the Yarr code. The parser converts matched surrogate pairs into the appropriate Unicode character when the expression is parsed. When matching a unicode expression and reading source characters, we convert proper surrogate pair into a Unicode character and advance the source cursor, "pos", one more position. The exception to this is when we know when generating a fixed character atom that we need to match a unicode character that doesn't fit in 16 bits. The code calls this an extendedUnicodeCharacter and has a helper to determine this. Added 'u' flag and 'unicode' identifier to regular expression classes. Added an "isUnicode" parameter to YarrPattern pattern() and internal users of that function. Updated the generation of the canonicalization tables to include a new set a tables that follow the ES 6.0, 21.2.2.8.2 Step 2. Renamed the YarrCanonicalizeUCS2.* files to YarrCanonicalizeUnicode.*. Added a new Layout/js test that tests the added functionality. Updated other tests that have minor es6 unicode checks and look for valid flags. Ran the ChakraCore Unicode regular expression tests as well. * CMakeLists.txt: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/ContentSearchUtilities.cpp: (Inspector::ContentSearchUtilities::findMagicComment): * yarr/RegularExpression.cpp: (JSC::Yarr::RegularExpression::Private::compile): Updated use of pattern(). * runtime/CommonIdentifiers.h: * runtime/RegExp.cpp: (JSC::regExpFlags): (JSC::RegExpFunctionalTestCollector::outputOneTest): (JSC::RegExp::finishCreation): (JSC::RegExp::compile): (JSC::RegExp::compileMatchOnly): * runtime/RegExp.h: * runtime/RegExpKey.h: * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncCompile): (JSC::flagsString): (JSC::regExpProtoGetterMultiline): (JSC::regExpProtoGetterUnicode): (JSC::regExpProtoGetterFlags): Updated for new 'y' (unicode) flag. Add check to use the interpreter for unicode regular expressions. * tests/es6.yaml: * tests/stress/static-getter-in-names.js: Updated tests for new flag and for passing the minimal es6 regular expression processing. * yarr/Yarr.h: Updated the size of information now kept for backtracking. * yarr/YarrCanonicalizeUCS2.cpp: Removed. * yarr/YarrCanonicalizeUCS2.h: Removed. * yarr/YarrCanonicalizeUCS2.js: Removed. * yarr/YarrCanonicalizeUnicode.cpp: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUCS2.cpp. * yarr/YarrCanonicalizeUnicode.h: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUCS2.h. (JSC::Yarr::canonicalCharacterSetInfo): (JSC::Yarr::canonicalRangeInfoFor): (JSC::Yarr::getCanonicalPair): (JSC::Yarr::isCanonicallyUnique): (JSC::Yarr::areCanonicallyEquivalent): (JSC::Yarr::rangeInfoFor): Deleted. * yarr/YarrCanonicalizeUnicode.js: Copied from Source/JavaScriptCore/yarr/YarrCanonicalizeUCS2.js. (printHeader): (printFooter): (hex): (canonicalize): (canonicalizeUnicode): (createUCS2CanonicalGroups): (createUnicodeCanonicalGroups): (cu.in.groupedCanonically.characters.sort): Deleted. (cu.in.groupedCanonically.else): Deleted. Refactored to output two sets of tables, one for UCS2 and one for Unicode. The UCS2 tables follow the legacy canonicalization rules now specified in ES 6.0, 21.2.2.8.2 Step 3. The new Unicode tables follow the rules specified in ES 6.0, 21.2.2.8.2 Step 2. Eliminated the unused Latin1 tables. * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::InputStream::InputStream): (JSC::Yarr::Interpreter::InputStream::readChecked): (JSC::Yarr::Interpreter::InputStream::readSurrogatePairChecked): (JSC::Yarr::Interpreter::InputStream::reread): (JSC::Yarr::Interpreter::InputStream::prev): (JSC::Yarr::Interpreter::testCharacterClass): (JSC::Yarr::Interpreter::checkCharacter): (JSC::Yarr::Interpreter::checkSurrogatePair): (JSC::Yarr::Interpreter::checkCasedCharacter): (JSC::Yarr::Interpreter::tryConsumeBackReference): (JSC::Yarr::Interpreter::backtrackPatternCharacter): (JSC::Yarr::Interpreter::matchCharacterClass): (JSC::Yarr::Interpreter::backtrackCharacterClass): (JSC::Yarr::Interpreter::matchParenthesesTerminalEnd): (JSC::Yarr::Interpreter::matchDisjunction): (JSC::Yarr::Interpreter::Interpreter): (JSC::Yarr::ByteCompiler::assertionWordBoundary): (JSC::Yarr::ByteCompiler::atomPatternCharacter): * yarr/YarrInterpreter.h: (JSC::Yarr::ByteTerm::ByteTerm): (JSC::Yarr::BytecodePattern::BytecodePattern): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::optimizeAlternative): (JSC::Yarr::YarrGenerator::matchCharacterClassRange): (JSC::Yarr::YarrGenerator::matchCharacterClass): (JSC::Yarr::YarrGenerator::notAtEndOfInput): (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals): (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce): (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed): (JSC::Yarr::YarrGenerator::generatePatternCharacterGreedy): (JSC::Yarr::YarrGenerator::backtrackPatternCharacterNonGreedy): * yarr/YarrParser.h: (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter): (JSC::Yarr::Parser::Parser): (JSC::Yarr::Parser::parseEscape): (JSC::Yarr::Parser::consumePossibleSurrogatePair): (JSC::Yarr::Parser::parseCharacterClass): (JSC::Yarr::Parser::parseTokens): (JSC::Yarr::Parser::parse): (JSC::Yarr::Parser::atEndOfPattern): (JSC::Yarr::Parser::patternRemaining): (JSC::Yarr::Parser::peek): (JSC::Yarr::parse): * yarr/YarrPattern.cpp: (JSC::Yarr::CharacterClassConstructor::CharacterClassConstructor): (JSC::Yarr::CharacterClassConstructor::append): (JSC::Yarr::CharacterClassConstructor::putChar): (JSC::Yarr::CharacterClassConstructor::putUnicodeIgnoreCase): (JSC::Yarr::CharacterClassConstructor::putRange): (JSC::Yarr::CharacterClassConstructor::charClass): (JSC::Yarr::CharacterClassConstructor::addSorted): (JSC::Yarr::CharacterClassConstructor::addSortedRange): (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor): (JSC::Yarr::YarrPatternConstructor::assertionWordBoundary): (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter): (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBegin): (JSC::Yarr::YarrPatternConstructor::atomCharacterClassAtom): (JSC::Yarr::YarrPatternConstructor::atomCharacterClassRange): (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets): (JSC::Yarr::YarrPattern::compile): (JSC::Yarr::YarrPattern::YarrPattern): * yarr/YarrPattern.h: (JSC::Yarr::CharacterRange::CharacterRange): (JSC::Yarr::CharacterClass::CharacterClass): (JSC::Yarr::PatternTerm::PatternTerm): (JSC::Yarr::YarrPattern::reset): * yarr/YarrSyntaxChecker.cpp: (JSC::Yarr::SyntaxChecker::assertionBOL): (JSC::Yarr::SyntaxChecker::assertionEOL): (JSC::Yarr::SyntaxChecker::assertionWordBoundary): (JSC::Yarr::SyntaxChecker::atomPatternCharacter): (JSC::Yarr::SyntaxChecker::atomBuiltInCharacterClass): (JSC::Yarr::SyntaxChecker::atomCharacterClassBegin): (JSC::Yarr::SyntaxChecker::atomCharacterClassAtom): (JSC::Yarr::checkSyntax): 2016-03-01 Saam barati Remove FIXMEs and add valid test cases after necessary patch has landed. Rubber stamped by Mark Lam. * tests/stress/proxy-prevent-extensions.js: (assert.Object.isSealed): (assert): 2016-03-01 Saam barati [ES6] Implement Proxy.[[IsExtensible]] https://bugs.webkit.org/show_bug.cgi?id=154872 Reviewed by Oliver Hunt. This patch is a direct implementation of Proxy.[[IsExtensible]] with respect to section 9.5.3 of the ECMAScript 6 spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-isextensible * runtime/ProxyObject.cpp: (JSC::ProxyObject::preventExtensions): (JSC::ProxyObject::performIsExtensible): (JSC::ProxyObject::isExtensible): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: * tests/es6.yaml: * tests/stress/proxy-is-extensible.js: Added. (assert): (throw.new.Error.let.handler.get isExtensible): (throw.new.Error): (assert.let.handler.isExtensible): (assert.): (let.handler.isExtensible): 2016-03-01 Saam barati [ES6] Implement Proxy.[[PreventExtensions]] https://bugs.webkit.org/show_bug.cgi?id=154873 Reviewed by Oliver Hunt. This patch is a direct implementation of Proxy.[[PreventExtensions]] with respect to section 9.5.4 of the ECMAScript 6 spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-preventextensions * runtime/ProxyObject.cpp: (JSC::ProxyObject::deletePropertyByIndex): (JSC::ProxyObject::performPreventExtensions): (JSC::ProxyObject::preventExtensions): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: * tests/es6.yaml: * tests/stress/proxy-prevent-extensions.js: Added. (assert): (throw.new.Error.let.handler.get preventExtensions): (throw.new.Error): (assert.let.handler.preventExtensions): (assert.): (let.handler.preventExtensions): (assert.Object.isSealed.let.handler.preventExtensions): (assert.Object.isSealed): 2016-03-01 Filip Pizlo FTL should simplify StringReplace with an empty replacement string https://bugs.webkit.org/show_bug.cgi?id=154871 Reviewed by Michael Saboff. This is a simple and hugely profitable change. If we do a string.replace(/things/, ""), then this calls directly into StringPrototype's replace-with-empty-string logic instead of going through stuff that does checks before reaching that same conclusion. This speeds up Octane/regexp by about 6-10%. It also speeds up the attached microbenchmark by about 7%. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace): * runtime/StringPrototype.cpp: (JSC::jsSpliceSubstringsWithSeparators): (JSC::removeUsingRegExpSearch): (JSC::replaceUsingRegExpSearch): (JSC::operationStringProtoFuncReplaceRegExpEmptyStr): (JSC::operationStringProtoFuncReplaceRegExpString): * runtime/StringPrototype.h: 2016-03-01 Alex Christensen Reduce size of internal windows build output https://bugs.webkit.org/show_bug.cgi?id=154763 Reviewed by Brent Fulgham. * JavaScriptCore.vcxproj/JavaScriptCore.proj: 2016-03-01 Saam barati [[IsExtensible]] should be a virtual method in the method table https://bugs.webkit.org/show_bug.cgi?id=154799 Reviewed by Mark Lam. This patch makes us more consistent with how the ES6 specification models the [[IsExtensible]] trap. Moving this method into ClassInfo::methodTable is a prerequisite for implementing Proxy.[[IsExtensible]]. * runtime/ClassInfo.h: * runtime/JSCell.cpp: (JSC::JSCell::preventExtensions): (JSC::JSCell::isExtensible): * runtime/JSCell.h: * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncProtoSetter): * runtime/JSObject.cpp: (JSC::JSObject::preventExtensions): (JSC::JSObject::isExtensible): (JSC::JSObject::reifyAllStaticProperties): (JSC::JSObject::defineOwnIndexedProperty): (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage): (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage): (JSC::JSObject::defineOwnNonIndexProperty): (JSC::JSObject::defineOwnProperty): * runtime/JSObject.h: (JSC::JSObject::isSealed): (JSC::JSObject::isFrozen): (JSC::JSObject::isExtensibleImpl): (JSC::JSObject::isStructureExtensible): (JSC::JSObject::isExtensibleInline): (JSC::JSObject::indexingShouldBeSparse): (JSC::JSObject::putDirectInternal): (JSC::JSObject::isExtensible): Deleted. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorSetPrototypeOf): (JSC::objectConstructorIsSealed): (JSC::objectConstructorIsFrozen): (JSC::objectConstructorIsExtensible): (JSC::objectConstructorIs): * runtime/ProxyObject.cpp: (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): * runtime/ReflectObject.cpp: (JSC::reflectObjectIsExtensible): (JSC::reflectObjectSetPrototypeOf): * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayValueMap::putEntry): (JSC::SparseArrayValueMap::putDirect): * runtime/StringObject.cpp: (JSC::StringObject::defineOwnProperty): * runtime/Structure.cpp: (JSC::Structure::isSealed): (JSC::Structure::isFrozen): * runtime/Structure.h: 2016-03-01 Filip Pizlo Unreviewed, fix CLOOP build. * jit/JITOperations.h: 2016-03-01 Skachkov Oleksandr [ES6] Arrow function. Some not used byte code is emited https://bugs.webkit.org/show_bug.cgi?id=154639 Reviewed by Saam Barati. Currently bytecode that is generated for arrow function is not optimal. Current fix removed following unnecessary bytecode: 1.create_lexical_environment not emited always for arrow function, only if some of features(this/super/arguments/eval) is used inside of the arrow function. 2.load 'this' from arrow function scope in constructor is done only if super contains in arrow function * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::isSuperCallUsedInInnerArrowFunction): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::ThisNode::emitBytecode): (JSC::FunctionNode::emitBytecode): * parser/Nodes.h: (JSC::ScopeNode::doAnyInnerArrowFunctionsUseAnyFeature): * tests/stress/arrowfunction-lexical-bind-supercall-4.js: 2016-02-29 Filip Pizlo Turn String.prototype.replace into an intrinsic https://bugs.webkit.org/show_bug.cgi?id=154835 Reviewed by Michael Saboff. Octane/regexp spends a lot of time in String.prototype.replace(). That function does a lot of checks to see if the parameters are what they are likely to often be (a string, a regexp, and a string). The intuition of this patch is that it's good to remove those checks and it's good to call the native function as directly as possible. This yields a 10% speed-up on a replace microbenchmark and a 3% speed-up on Octane/regexp. It also improves Octane/jquery. This is only the beginning of what I want to do with replace optimizations. The other optimizations will rely on StringReplace being revealed as a construct in DFG IR. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/SpeculatedType.cpp: (JSC::dumpSpeculation): (JSC::speculationToAbbreviatedString): (JSC::speculationFromClassInfo): * bytecode/SpeculatedType.h: (JSC::isStringOrStringObjectSpeculation): (JSC::isRegExpObjectSpeculation): (JSC::isBoolInt32Speculation): * 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/DFGNode.h: (JSC::DFG::Node::shouldSpeculateStringOrStringObject): (JSC::DFG::Node::shouldSpeculateRegExpObject): (JSC::DFG::Node::shouldSpeculateSymbol): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculateFinalObject): (JSC::DFG::SpeculativeJIT::speculateRegExpObject): (JSC::DFG::SpeculativeJIT::speculateObjectOrOther): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): (JSC::DFG::isCell): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp): (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace): (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack): (JSC::FTL::DFG::LowerDFGToB3::speculate): (JSC::FTL::DFG::LowerDFGToB3::speculateFinalObject): (JSC::FTL::DFG::LowerDFGToB3::speculateRegExpObject): (JSC::FTL::DFG::LowerDFGToB3::speculateString): * jit/JITOperations.h: * runtime/Intrinsic.h: * runtime/JSType.h: * runtime/RegExpObject.h: (JSC::RegExpObject::createStructure): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::removeUsingRegExpSearch): (JSC::replaceUsingRegExpSearch): (JSC::operationStringProtoFuncReplaceRegExpString): (JSC::replaceUsingStringSearch): (JSC::stringProtoFuncRepeat): (JSC::replace): (JSC::stringProtoFuncReplace): (JSC::operationStringProtoFuncReplaceGeneric): (JSC::stringProtoFuncToString): * runtime/StringPrototype.h: 2016-03-01 Commit Queue Unreviewed, rolling out r197056. https://bugs.webkit.org/show_bug.cgi?id=154870 broke win ews (Requested by alexchristensen on #webkit). Reverted changeset: "[cmake] Moved PRE/POST_BUILD_COMMAND to WEBKIT_FRAMEWORK." https://bugs.webkit.org/show_bug.cgi?id=154651 http://trac.webkit.org/changeset/197056 2016-02-29 Saam barati [[PreventExtensions]] should be a virtual method in the method table. https://bugs.webkit.org/show_bug.cgi?id=154800 Reviewed by Yusuke Suzuki. This patch makes us more consistent with how the ES6 specification models the [[PreventExtensions]] trap. Moving this method into ClassInfo::methodTable is a prerequisite for implementing Proxy.[[PreventExtensions]]. * runtime/ClassInfo.h: * runtime/JSCell.cpp: (JSC::JSCell::getGenericPropertyNames): (JSC::JSCell::preventExtensions): * runtime/JSCell.h: * runtime/JSModuleNamespaceObject.cpp: (JSC::JSModuleNamespaceObject::JSModuleNamespaceObject): (JSC::JSModuleNamespaceObject::finishCreation): (JSC::JSModuleNamespaceObject::destroy): * runtime/JSModuleNamespaceObject.h: (JSC::JSModuleNamespaceObject::create): (JSC::JSModuleNamespaceObject::moduleRecord): * runtime/JSObject.cpp: (JSC::JSObject::freeze): (JSC::JSObject::preventExtensions): (JSC::JSObject::reifyAllStaticProperties): * runtime/JSObject.h: (JSC::JSObject::isSealed): (JSC::JSObject::isFrozen): (JSC::JSObject::isExtensible): * runtime/ObjectConstructor.cpp: (JSC::objectConstructorSeal): (JSC::objectConstructorFreeze): (JSC::objectConstructorPreventExtensions): (JSC::objectConstructorIsSealed): * runtime/ReflectObject.cpp: (JSC::reflectObjectPreventExtensions): * runtime/Structure.cpp: (JSC::Structure::Structure): (JSC::Structure::preventExtensionsTransition): * runtime/Structure.h: 2016-02-29 Yusuke Suzuki [JSC] Private symbols should not be trapped by proxy handler https://bugs.webkit.org/show_bug.cgi?id=154817 Reviewed by Mark Lam. Since the runtime has some assumptions on the properties associated with the private symbols, ES6 Proxy should not trap these property operations. For example, in ArrayIteratorPrototype.js var itemKind = this.@arrayIterationKind; if (itemKind === @undefined) throw new @TypeError("%ArrayIteratorPrototype%.next requires that |this| be an Array Iterator instance"); Here, we assume that only the array iterator has the @arrayIterationKind property that value is non-undefined. But If we implement Proxy with the get handler, that returns a non-undefined value for every operations, we accidentally assumes that the given value is an array iterator. To avoid these situation, we perform the default operations onto property operations with private symbols. * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::performPut): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::deleteProperty): (JSC::ProxyObject::deletePropertyByIndex): * tests/stress/proxy-basic.js: * tests/stress/proxy-with-private-symbols.js: Added. (assert): (let.handler.getOwnPropertyDescriptor): 2016-02-29 Filip Pizlo regress/script-tests/double-pollution-putbyoffset.js.ftl-eager timed out because of a lock ordering deadlock involving InferredType and CodeBlock https://bugs.webkit.org/show_bug.cgi?id=154841 Reviewed by Benjamin Poulain. Here's the deadlock: Main thread: 1) Change an InferredType. This acquires InferredType::m_lock. 2) Fire watchpoint set. This triggers CodeBlock invalidation, which acquires CodeBlock::m_lock. DFG thread: 1) Iterate over the information in a CodeBlock. This acquires CodeBlock::m_lock. 2) Ask an InferredType for its descriptor(). This acquires InferredType::m_lock. I think that the DFG thread's ordering should be legal, because the best logic for lock hierarchies is that locks that protect the largest set of stuff should be acquired first. This means that the main thread shouldn't be holding the InferredType::m_lock when firing watchpoint sets. That's what this patch ensures. At the time of writing, this test was deadlocking for me on trunk 100% of the time. With this change I cannot get it to deadlock. * runtime/InferredType.cpp: (JSC::InferredType::willStoreValueSlow): (JSC::InferredType::makeTopSlow): (JSC::InferredType::set): (JSC::InferredType::removeStructure): (JSC::InferredType::InferredStructureWatchpoint::fireInternal): * runtime/InferredType.h: 2016-02-29 Yusuke Suzuki [DFG][FTL][B3] Support floor and ceil https://bugs.webkit.org/show_bug.cgi?id=154683 Reviewed by Filip Pizlo. This patch implements and fixes the following things. 1. Implement Ceil and Floor in DFG, FTL and B3 x86 SSE 4.2 and ARM64 have round instructions that can directly perform Ceil or Floor. This patch leverages this functionality. We introduce ArithFloor and ArithCeil. During DFG phase, these nodes attempt to convert itself to Identity (in Fixup phase). As the same to ArithRound, it tracks arith rounding mode. And if these nodes are required to emit machine codes, we emit rounding machine code if it is supported in the current machine. For example, in x86, we emit `round`. This `Floor` functionality is nice for @toInteger in builtin. That is used for Array.prototype.{forEach, map, every, some, reduce...} And according to the benchmark results, Kraken audio-oscillator is slightly improved due to its frequent Math.round and Math.floor calls. 2. Implement Floor in B3 and Air As the same to Ceil in B3, we add a new B3 IR and Air opcode, Floor. This Floor is leveraged to implement ArithFloor in DFG. 3. Fix ArithRound operation Currently, we used cvtsd2si (in x86) to convert double value to int32. And we also used this to implement Math.round, like, cvtsd2si(value + 0.5). However, this implementation is not correct. Because cvtsd2si is not floor operation. It is trucate operation. This is OK for positive numbers. But NG for negative numbers. For example, the current implementation accidentally rounds `-0.6` to `-0.0`. This should be `-1.0`. Using Ceil and Floor instructions, we implement correct ArithRound. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::supportsFloatingPointRounding): (JSC::MacroAssemblerARM::ceilDouble): (JSC::MacroAssemblerARM::floorDouble): (JSC::MacroAssemblerARM::supportsFloatingPointCeil): Deleted. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::supportsFloatingPointRounding): (JSC::MacroAssemblerARM64::floorFloat): (JSC::MacroAssemblerARM64::supportsFloatingPointCeil): Deleted. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::supportsFloatingPointRounding): (JSC::MacroAssemblerARMv7::ceilDouble): (JSC::MacroAssemblerARMv7::floorDouble): (JSC::MacroAssemblerARMv7::supportsFloatingPointCeil): Deleted. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::ceilDouble): (JSC::MacroAssemblerMIPS::floorDouble): (JSC::MacroAssemblerMIPS::supportsFloatingPointRounding): (JSC::MacroAssemblerMIPS::supportsFloatingPointCeil): Deleted. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::supportsFloatingPointRounding): (JSC::MacroAssemblerSH4::ceilDouble): (JSC::MacroAssemblerSH4::floorDouble): (JSC::MacroAssemblerSH4::supportsFloatingPointCeil): Deleted. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::floorDouble): (JSC::MacroAssemblerX86Common::floorFloat): (JSC::MacroAssemblerX86Common::supportsFloatingPointRounding): (JSC::MacroAssemblerX86Common::supportsFloatingPointCeil): Deleted. * b3/B3ConstDoubleValue.cpp: (JSC::B3::ConstDoubleValue::floorConstant): * b3/B3ConstDoubleValue.h: * b3/B3ConstFloatValue.cpp: (JSC::B3::ConstFloatValue::floorConstant): * b3/B3ConstFloatValue.h: * b3/B3LowerMacrosAfterOptimizations.cpp: * 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::floorConstant): (JSC::B3::Value::isRounded): (JSC::B3::Value::effects): (JSC::B3::Value::key): (JSC::B3::Value::typeFor): * b3/B3Value.h: * b3/air/AirFixPartialRegisterStalls.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.cpp: (JSC::B3::testFloorCeilArg): (JSC::B3::testFloorArg): (JSC::B3::testFloorImm): (JSC::B3::testFloorMem): (JSC::B3::testFloorFloorArg): (JSC::B3::testCeilFloorArg): (JSC::B3::testFloorIToD64): (JSC::B3::testFloorIToD32): (JSC::B3::testFloorArgWithUselessDoubleConversion): (JSC::B3::testFloorArgWithEffectfulDoubleConversion): (JSC::B3::run): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArithMode.cpp: (WTF::printInternal): * dfg/DFGArithMode.h: * 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/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (JSC::DFG::Graph::roundShouldSpeculateInt32): * dfg/DFGNode.h: (JSC::DFG::Node::arithNodeFlags): (JSC::DFG::Node::hasHeapPrediction): (JSC::DFG::Node::hasArithRoundingMode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithRounding): (JSC::DFG::SpeculativeJIT::compileArithRound): Deleted. * 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::compileArithRound): (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor): (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil): * ftl/FTLOutput.h: (JSC::FTL::Output::doubleFloor): * jit/ThunkGenerators.cpp: (JSC::ceilThunkGenerator): * tests/stress/math-ceil-arith-rounding-mode.js: Added. (firstCareAboutZeroSecondDoesNot): (firstDoNotCareAboutZeroSecondDoes): (warmup): (verifyNegativeZeroIsPreserved): * tests/stress/math-ceil-basics.js: Added. (mathCeilOnIntegers): (mathCeilOnDoubles): (mathCeilOnBooleans): (uselessMathCeil): (mathCeilWithOverflow): (mathCeilConsumedAsDouble): (mathCeilDoesNotCareAboutMinusZero): (mathCeilNoArguments): (mathCeilTooManyArguments): (testMathCeilOnConstants): (mathCeilStructTransition): (Math.ceil): * tests/stress/math-floor-arith-rounding-mode.js: Added. (firstCareAboutZeroSecondDoesNot): (firstDoNotCareAboutZeroSecondDoes): (warmup): (verifyNegativeZeroIsPreserved): * tests/stress/math-floor-basics.js: Added. (mathFloorOnIntegers): (mathFloorOnDoubles): (mathFloorOnBooleans): (uselessMathFloor): (mathFloorWithOverflow): (mathFloorConsumedAsDouble): (mathFloorDoesNotCareAboutMinusZero): (mathFloorNoArguments): (mathFloorTooManyArguments): (testMathFloorOnConstants): (mathFloorStructTransition): (Math.floor): * tests/stress/math-round-should-not-use-truncate.js: Added. (mathRoundDoesNotCareAboutMinusZero): * tests/stress/math-rounding-infinity.js: Added. (shouldBe): (testRound): (testFloor): (testCeil): * tests/stress/math-rounding-nan.js: Added. (shouldBe): (testRound): (testFloor): (testCeil): * tests/stress/math-rounding-negative-zero.js: Added. (shouldBe): (testRound): (testFloor): (testCeil): (testRoundNonNegativeZero): (testRoundNonNegativeZero2): 2016-02-29 Joseph Pecoraro Add new MethodTable method to get an estimated size for a cell https://bugs.webkit.org/show_bug.cgi?id=154838 Reviewed by Filip Pizlo. The new class method estimatedSize(JSCell*) estimates the size for a single cell. As the name implies, this is meant to be an approximation. It is more important that big objects report a large size, then to get perfect size information for all objects in the heap. Base implementation (JSCell): - returns the MarkedBlock bucket size for this cell. - This gets us the object size include inline storage. Basically a better sizeof. Subclasses with "Extra Memory Cost": - Any class that reports extra memory (reportExtraMemoryVisited) should include that in the estimated size. - E.g. CodeBlock, JSGenericTypedArrayView, WeakMapData, etc. Subclasses with "Copied Space" storage: - Any class with data in copied space (copyBackingStore) should include that in the estimated size. - E.g. JSObject, JSGenericTypedArrayView, JSMap, JSSet, DirectArguments, etc. Add reportExtraMemoryVisited for UnlinkedCodeBlock's compressed unlinked instructions because this can be larger than 1kb, which is significant. This has one special case for RegExp generated bytecode / JIT code, which does not currently fall into the extra memory cost or copied space storage. In practice I haven't seen this grow to a significant cost. * runtime/ClassInfo.h: Add the new estimatedSize method to the table. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::visitChildren): (JSC::UnlinkedCodeBlock::estimatedSize): (JSC::UnlinkedCodeBlock::setInstructions): * bytecode/UnlinkedCodeBlock.h: Report an extra memory cost for unlinked code blocks like we do for linked code blocks. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::estimatedSize): * bytecode/CodeBlock.h: * bytecode/UnlinkedInstructionStream.cpp: (JSC::UnlinkedInstructionStream::sizeInBytes): * bytecode/UnlinkedInstructionStream.h: * runtime/DirectArguments.cpp: (JSC::DirectArguments::estimatedSize): * runtime/DirectArguments.h: * runtime/JSCell.cpp: (JSC::JSCell::estimatedSizeInBytes): (JSC::JSCell::estimatedSize): * runtime/JSCell.h: * runtime/JSGenericTypedArrayView.h: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::estimatedSize): * runtime/JSMap.cpp: (JSC::JSMap::estimatedSize): * runtime/JSMap.h: * runtime/JSObject.cpp: (JSC::JSObject::visitButterfly): * runtime/JSObject.h: * runtime/JSSet.cpp: (JSC::JSSet::estimatedSize): * runtime/JSSet.h: * runtime/JSString.cpp: (JSC::JSString::estimatedSize): * runtime/JSString.h: * runtime/MapData.h: (JSC::MapDataImpl::capacityInBytes): * runtime/WeakMapData.cpp: (JSC::WeakMapData::estimatedSize): (JSC::WeakMapData::visitChildren): * runtime/WeakMapData.h: Implement estimated size following the pattern of reporting extra visited size, or copy space memory. * runtime/RegExp.cpp: (JSC::RegExp::estimatedSize): * runtime/RegExp.h: * yarr/YarrInterpreter.h: (JSC::Yarr::ByteDisjunction::estimatedSizeInBytes): (JSC::Yarr::BytecodePattern::estimatedSizeInBytes): * yarr/YarrJIT.h: (JSC::Yarr::YarrCodeBlock::size): Include generated bytecode / JITCode to a RegExp's size. 2016-02-29 Filip Pizlo SpeculatedType should be easier to edit https://bugs.webkit.org/show_bug.cgi?id=154840 Reviewed by Mark Lam. We used to specify the bitmasks in SpeculatedType.h using hex codes. This used to work great because we didn't have so many masks and you could use the mask to visually see which ones overlapped. It also made it easy to visualize subset relationships. But now we have a lot of masks with a lot of confusing overlaps, and it's no longer possible to just see their relationship by looking at hex codes. Worse, the use of hex codes makes it super annoying to move the bits around. For example, right now we have two bits free, but if we wanted to reclaim them by editing the old hex masks, it would be a nightmare. So this patch replaces the hex masks with shift expressions (1u << 15 for example) and it makes any derived masks (i.e. masks that are the bit-or of other masks) be expressed using an or expression (SpecFoo | SpecBar | SpecBaz for example). This makes it easier to see the relationships and it makes it easier to take bits for new types. * bytecode/SpeculatedType.h: 2016-02-29 Keith Miller OverridesHasInstance constant folding is wrong https://bugs.webkit.org/show_bug.cgi?id=154833 Reviewed by Filip Pizlo. The current implementation of OverridesHasInstance constant folding is incorrect. Since it relies on OSR exit information it has been moved to the StrengthReductionPhase. Normally, such an optimazation would be put in FixupPhase, however, there are a number of cases where we don't determine an edge of OverridesHasInstance is a constant until after fixup. Performing the optimization during StrengthReductionPhase means we can defer our decision until later. In the future we should consider creating a version of this optimization that does not depend on OSR exit information and move the optimization back to ConstantFoldingPhase. * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): Deleted. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): 2016-02-28 Filip Pizlo B3 should have global store elimination https://bugs.webkit.org/show_bug.cgi?id=154658 Reviewed by Benjamin Poulain. Implements fairly comprehensive global store elimination: 1) If you store the result of a load with no interference in between, remove the store. 2) If you store the same thing you stored previously, remove the store. 3) If you store something that you either loaded previously or stored previously along arbitrarily many paths, remove the store. 4) If you store to something that is stored to again in the future with no interference in between, remove the store. Rule (4) is super relevant to FTL since the DFG does not eliminate redundant PutStructures. A constructor that produces a large object will have many redundant stores to the same base pointer, offset, and heap range, with no code to observe that heap raneg in between. This doesn't have a decisive effect on major benchmarks, but it's an enormous win for microbenchmarks: - 30% faster to construct an object with many fields. - 5x faster to do many stores to a global variable. The compile time cost should be very small. Although the optimization is global, it aborts as soon as it sees anything that would confound store elimination. For rules (1)-(3), we piggy-back the existing load elimination, which gives up on interfering stores. For rule (4), we search forward through the current block and then globally a block at a time (skipping block contents thanks to summary data), which could be expensive. But rule (4) aborts as soon as it sees a read, write, or end block (Return or Oops). Any Check will claim to read TOP. Any Patchpoint that results from an InvalidationPoint will claim to read TOP, as will any Patchpoints for ICs. Those are usually sprinkled all over the program. In other words, this optimization rarely kicks in. When it does kick in, it makes programs run faster. When it doesn't kick in, it's usually O(1) because there are reasons for aborting all over a "normal" program so the search will halt almost immediately. This of course raises the question: how much more in compile time do we pay when the optimization does kick in? The optimization kicks in the most for the microbenchmarks I wrote for this patch. Amazingly, the effect of the optimization a wash for compile time: whatever cost we pay doing the O(n^2) searches is balanced by the massive reduction in work in the backend. On one of the two microbenchmarks, overall compile time actually shrank with this optimization even though CSE itself cost more. That's not too surprising - the backend costs much more per instruction, so things that remove instructions before we get to the backend tend to be a good idea. We could consider adding a more aggressive version of this in the future, which could sink stores into checks. That could be crazy fun: https://bugs.webkit.org/show_bug.cgi?id=152162#c3 But mainly, I'm adding this optimization because it was super fun to implement during the WebAssembly CG summit. * b3/B3EliminateCommonSubexpressions.cpp: * b3/B3MemoryValue.h: * b3/B3SuccessorCollection.h: (JSC::B3::SuccessorCollection::begin): (JSC::B3::SuccessorCollection::end): (JSC::B3::SuccessorCollection::const_iterator::const_iterator): (JSC::B3::SuccessorCollection::const_iterator::operator*): (JSC::B3::SuccessorCollection::const_iterator::operator++): (JSC::B3::SuccessorCollection::const_iterator::operator==): (JSC::B3::SuccessorCollection::const_iterator::operator!=): 2016-02-29 Filip Pizlo Make it cheap to #include "JITOperations.h" https://bugs.webkit.org/show_bug.cgi?id=154836 Reviewed by Mark Lam. Prior to this change, this header included the whole world even though it did't have any definitions. This patch turns almost all of the includes into forward declarations. Right now this header is very cheap to include. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGSpeculativeJIT.h: * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/Repatch.h: * runtime/CommonSlowPaths.h: (JSC::encodeResult): Deleted. (JSC::decodeResult): Deleted. * runtime/SlowPathReturnType.h: Added. (JSC::encodeResult): (JSC::decodeResult): 2016-02-28 Filip Pizlo FTL should be able to run everything in Octane/regexp https://bugs.webkit.org/show_bug.cgi?id=154266 Reviewed by Saam Barati. Adds FTL support for NewRegexp, RegExpTest, and RegExpExec. I couldn't figure out how to make the RegExpExec peephole optimization work in FTL. This optimizations shouldn't be a DFG backend optimization anyway - if we need this optimization then it should be a strength reduction rule over IR. That way, it can be shared by all backends. I measured whether removing that optimization had any effect on performance separately from measuring the performance of this patch. Removing that optimization did not change our score on any benchmarks. This patch does have an overall negative effect on the Octane/regexp score. This is presumably because tiering up to the FTL has no value to the code in the regexp test. Or maybe it's something else. No matter - the overall effect on the Octane score is not statistically significant and we don't want this kind of coverage blocked by the fact that adding coverage hurts a benchmark. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGNode.h: (JSC::DFG::Node::setIndexingType): (JSC::DFG::Node::hasRegexpIndex): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNotifyWrite): (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull): (JSC::DFG::SpeculativeJIT::compileRegExpExec): Deleted. * 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::compileCheckWatchdogTimer): (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec): (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest): (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp): (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack): * tests/stress/ftl-regexp-exec.js: Added. * tests/stress/ftl-regexp-test.js: Added. 2016-02-28 Andreas Kling Make JSFunction.name allocation fully lazy. Reviewed by Saam Barati. We were reifying the "name" field on functions lazily, but created the string value itself up front. This patch gets rid of the up-front allocation, saving us a JSString allocation per function in most cases. * builtins/BuiltinExecutables.cpp: (JSC::createExecutableInternal): * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::visitChildren): * bytecode/UnlinkedFunctionExecutable.h: * runtime/CodeCache.cpp: (JSC::CodeCache::getFunctionExecutableFromGlobalCode): * runtime/Executable.h: * runtime/JSFunction.cpp: (JSC::JSFunction::reifyName): 2016-02-28 Andreas Kling REGRESSION(r197303): 4 jsc tests failing on bots. Unreviewed follow-up fix. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset): This function can still get called with !m_rareData, in case the type profiler is active but this particular code block doesn't have type profiler data. Handle it gracefully. 2016-02-28 Andreas Kling Shrink UnlinkedCodeBlock a bit. Reviewed by Anders Carlsson. Move profiler-related members of UnlinkedCodeBlock into its RareData structure, saving 40 bytes, and then reorder the other members of UnlinkedCodeBlock to save another 24 bytes, netting a nice total 64. The VM member was removed entirely since UnlinkedCodeBlock is a cell and can retrieve its VM through MarkedBlock header lookup. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::vm): (JSC::UnlinkedCodeBlock::typeProfilerExpressionInfoForBytecodeOffset): (JSC::UnlinkedCodeBlock::addTypeProfilerExpressionInfo): (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted. * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::addRegExp): (JSC::UnlinkedCodeBlock::addConstant): (JSC::UnlinkedCodeBlock::addFunctionDecl): (JSC::UnlinkedCodeBlock::addFunctionExpr): (JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset): (JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets): (JSC::UnlinkedCodeBlock::vm): Deleted. 2016-02-27 Filip Pizlo FTL should lower its abstract heaps to B3 heap ranges https://bugs.webkit.org/show_bug.cgi?id=154782 Reviewed by Saam Barati. The FTL can describe the abstract heaps (points-to sets) that a memory operation will affect. The abstract heaps are arranged as a hierarchy. We used to transform this into TBAA hierarchies in LLVM, but we never got around to wiring this up to B3's equivalent notion - the HeapRange. That's what this patch fixes. B3 has a minimalistic alias analysis. It represents abstract heaps using unsigned 32-bit integers. There are 1<<32 abstract heaps. The B3 client can describe what an operation affects by specifying a heap range: a begin...end pair that says that the operation affects all abstract heaps H such that begin <= H < end. This peculiar scheme was a deliberate attempt to distill what the abstract heap hierarchy is all about. We can assign begin...end numbers to abstract heaps so that: - A heap's end is greater than its begin. - A heap's begin is greater than or equal to its parent's begin. - A heap's end is less than or equal to its parent's end. This is easy to do using a recursive traversal of the abstract heap hierarchy. I almost went for the iterative traversal, which is a splendid algorithm, but it's totally unnecessary here since we tightly control the height of the heap hierarchy. Because abstract heaps are produced on-the-fly by FTL lowering, due to the fact that we generate new ones for field names and constant indices we encounter, we can't actually decorate the B3 instructions we create in lowering until all lowering is done. Adding a new abstract heap to the hierarchy after ranges were already computed would require updating the ranges of any heaps "to the right" of that heap in the hierarchy. This patch solves that problem by recording the associations between abstract heaps and their intended roles in the generated IR, and then decorating all of the relevant B3 values after we compute the ranges of the hierarchy after lowering. This is perf-neutral. I was hoping for a small speed-up, but I could not detect a speed-up on any benchmark. That's not too surprising. We already have very precise CSE in the DFG, so there aren't many opportunities left for the B3 CSE and it may have already been getting the big ones even without alias analysis. Even without a speed-up, this patch is valuable because it makes it easier to implement other optimizations, like store elimination. * b3/B3HeapRange.h: (JSC::B3::HeapRange::HeapRange): * ftl/FTLAbstractHeap.cpp: (JSC::FTL::AbstractHeap::AbstractHeap): (JSC::FTL::AbstractHeap::changeParent): (JSC::FTL::AbstractHeap::compute): (JSC::FTL::AbstractHeap::shallowDump): (JSC::FTL::AbstractHeap::dump): (JSC::FTL::AbstractHeap::deepDump): (JSC::FTL::AbstractHeap::badRangeError): (JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap): (JSC::FTL::IndexedAbstractHeap::baseIndex): (JSC::FTL::IndexedAbstractHeap::atSlow): (JSC::FTL::IndexedAbstractHeap::initialize): (JSC::FTL::AbstractHeap::decorateInstruction): Deleted. (JSC::FTL::AbstractField::dump): Deleted. * ftl/FTLAbstractHeap.h: (JSC::FTL::AbstractHeap::AbstractHeap): (JSC::FTL::AbstractHeap::isInitialized): (JSC::FTL::AbstractHeap::initialize): (JSC::FTL::AbstractHeap::parent): (JSC::FTL::AbstractHeap::heapName): (JSC::FTL::AbstractHeap::range): (JSC::FTL::AbstractHeap::offset): (JSC::FTL::IndexedAbstractHeap::atAnyIndex): (JSC::FTL::IndexedAbstractHeap::at): (JSC::FTL::IndexedAbstractHeap::operator[]): (JSC::FTL::IndexedAbstractHeap::returnInitialized): (JSC::FTL::IndexedAbstractHeap::WithoutZeroOrOneHashTraits::constructDeletedValue): (JSC::FTL::IndexedAbstractHeap::WithoutZeroOrOneHashTraits::isDeletedValue): (JSC::FTL::AbstractHeap::changeParent): Deleted. (JSC::FTL::AbstractField::AbstractField): Deleted. (JSC::FTL::AbstractField::initialize): Deleted. (JSC::FTL::AbstractField::offset): Deleted. * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): (JSC::FTL::AbstractHeapRepository::~AbstractHeapRepository): (JSC::FTL::AbstractHeapRepository::decorateMemory): (JSC::FTL::AbstractHeapRepository::decorateCCallRead): (JSC::FTL::AbstractHeapRepository::decorateCCallWrite): (JSC::FTL::AbstractHeapRepository::decoratePatchpointRead): (JSC::FTL::AbstractHeapRepository::decoratePatchpointWrite): (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions): * ftl/FTLAbstractHeapRepository.h: (JSC::FTL::AbstractHeapRepository::forArrayType): (JSC::FTL::AbstractHeapRepository::HeapForValue::HeapForValue): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * ftl/FTLOutput.cpp: (JSC::FTL::Output::load): (JSC::FTL::Output::load8SignExt32): (JSC::FTL::Output::load8ZeroExt32): (JSC::FTL::Output::load16SignExt32): (JSC::FTL::Output::load16ZeroExt32): (JSC::FTL::Output::store): (JSC::FTL::Output::store32As8): (JSC::FTL::Output::store32As16): (JSC::FTL::Output::baseIndex): * ftl/FTLOutput.h: (JSC::FTL::Output::address): (JSC::FTL::Output::absolute): (JSC::FTL::Output::load8SignExt32): (JSC::FTL::Output::load8ZeroExt32): (JSC::FTL::Output::load16SignExt32): (JSC::FTL::Output::load16ZeroExt32): (JSC::FTL::Output::load32): (JSC::FTL::Output::load64): (JSC::FTL::Output::loadPtr): (JSC::FTL::Output::loadDouble): (JSC::FTL::Output::store32): (JSC::FTL::Output::store64): (JSC::FTL::Output::storePtr): (JSC::FTL::Output::storeDouble): (JSC::FTL::Output::ascribeRange): (JSC::FTL::Output::nonNegative32): (JSC::FTL::Output::load32NonNegative): (JSC::FTL::Output::equal): (JSC::FTL::Output::notEqual): * ftl/FTLTypedPointer.h: (JSC::FTL::TypedPointer::operator!): (JSC::FTL::TypedPointer::heap): (JSC::FTL::TypedPointer::value): 2016-02-28 Skachkov Oleksandr [ES6] Arrow function syntax. Emit loading&putting this/super only if they are used in arrow function https://bugs.webkit.org/show_bug.cgi?id=153981 Reviewed by Saam Barati. In first iteration of implemenation arrow function, we emit load and store variables 'this', 'arguments', 'super', 'new.target' in case if arrow function is exist even variables are not used in arrow function. Current patch added logic that prevent from emiting those varibles if they are not used in arrow function. During syntax analyze parser store information about using variables in arrow function inside of the ordinary function scope and then put to BytecodeGenerator through UnlinkedCodeBlock * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded): (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction): (JSC::BytecodeGenerator::isArgumentsUsedInInnerArrowFunction): (JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction): (JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction): (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope): (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope): (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::ThisNode::emitBytecode): (JSC::EvalFunctionCallNode::emitBytecode): (JSC::FunctionNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createBracketAccess): (JSC::ASTBuilder::createDotAccess): (JSC::ASTBuilder::usesSuperCall): (JSC::ASTBuilder::usesSuperProperty): (JSC::ASTBuilder::makeFunctionCallNode): * parser/Nodes.cpp: (JSC::ScopeNode::ScopeNode): (JSC::ProgramNode::ProgramNode): (JSC::ModuleProgramNode::ModuleProgramNode): (JSC::EvalNode::EvalNode): (JSC::FunctionNode::FunctionNode): * parser/Nodes.h: (JSC::ScopeNode::innerArrowFunctionCodeFeatures): (JSC::ScopeNode::doAnyInnerArrowFunctionsUseArguments): (JSC::ScopeNode::doAnyInnerArrowFunctionsUseSuperCall): (JSC::ScopeNode::doAnyInnerArrowFunctionsUseSuperProperty): (JSC::ScopeNode::doAnyInnerArrowFunctionsUseEval): (JSC::ScopeNode::doAnyInnerArrowFunctionsUseThis): (JSC::ScopeNode::doAnyInnerArrowFunctionsUseNewTarget): (JSC::ScopeNode::doAnyInnerArrowFunctionUseAnyFeature): (JSC::ScopeNode::usesSuperCall): (JSC::ScopeNode::usesSuperProperty): * parser/Parser.cpp: (JSC::Parser::parseProperty): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::parseMemberExpression): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::isArrowFunctionBoundary): (JSC::Scope::innerArrowFunctionFeatures): (JSC::Scope::setInnerArrowFunctionUsesSuperCall): (JSC::Scope::setInnerArrowFunctionUsesSuperProperty): (JSC::Scope::setInnerArrowFunctionUsesEval): (JSC::Scope::setInnerArrowFunctionUsesThis): (JSC::Scope::setInnerArrowFunctionUsesNewTarget): (JSC::Scope::setInnerArrowFunctionUsesArguments): (JSC::Scope::setInnerArrowFunctionUsesEvalAndUseArgumentsIfNeeded): (JSC::Scope::collectFreeVariables): (JSC::Scope::mergeInnerArrowFunctionFeatures): (JSC::Scope::fillParametersForSourceProviderCache): (JSC::Scope::restoreFromSourceProviderCache): (JSC::Scope::setIsFunction): (JSC::Scope::setIsArrowFunction): (JSC::Parser::closestParentNonArrowFunctionNonLexicalScope): (JSC::Parser::pushScope): (JSC::Parser::popScopeInternal): (JSC::Parser::parse): * parser/ParserModes.h: * parser/SourceProviderCacheItem.h: (JSC::SourceProviderCacheItem::SourceProviderCacheItem): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createFunctionMetadata): * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js: * tests/stress/arrowfunction-lexical-bind-arguments-strict.js: * tests/stress/arrowfunction-lexical-bind-newtarget.js: * tests/stress/arrowfunction-lexical-bind-superproperty.js: * tests/stress/arrowfunction-lexical-bind-this-8.js: Added. 2016-02-28 Saam barati ProxyObject.[[GetOwnProperty]] is partially broken because it doesn't propagate information back to the slot https://bugs.webkit.org/show_bug.cgi?id=154768 Reviewed by Ryosuke Niwa. This fixes a big bug with ProxyObject.[[GetOwnProperty]]: http://www.ecma-international.org/ecma-262/6.0/index.html#sec-proxy-object-internal-methods-and-internal-slots-getownproperty-p We weren't correctly propagating the result of this operation to the out PropertySlot& parameter. This patch fixes that and adds tests. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorGetOwnPropertyDescriptor): I added a missing exception check after object allocation because I saw that it was missing while reading the code. * runtime/PropertyDescriptor.cpp: (JSC::PropertyDescriptor::setUndefined): (JSC::PropertyDescriptor::slowGetterSetter): (JSC::PropertyDescriptor::getter): * runtime/PropertyDescriptor.h: (JSC::PropertyDescriptor::attributes): (JSC::PropertyDescriptor::value): * runtime/ProxyObject.cpp: (JSC::ProxyObject::performInternalMethodGetOwnProperty): * tests/es6.yaml: * tests/stress/proxy-get-own-property.js: (let.handler.getOwnPropertyDescriptor): (set get let.handler.return): (set get let.handler.getOwnPropertyDescriptor): (set get let): (set get let.a): (let.b): (let.setter): (let.getter): 2016-02-27 Andy VanWagoner Intl.Collator uses POSIX locale (detected by js/intl-collator.html on iOS Simulator) https://bugs.webkit.org/show_bug.cgi?id=152448 Reviewed by Darin Adler. Add defaultLanguage to the globalObjectMethodTable and use it for the default locale in Intl object initializations. Fall back to ICU default locale only if the defaultLanguage function is null, or returns an empty string. * jsc.cpp: * runtime/IntlCollator.cpp: (JSC::IntlCollator::initializeCollator): * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::initializeDateTimeFormat): * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::initializeNumberFormat): * runtime/IntlObject.cpp: (JSC::defaultLocale): (JSC::lookupMatcher): (JSC::bestFitMatcher): (JSC::resolveLocale): * runtime/IntlObject.h: * runtime/JSGlobalObject.cpp: * runtime/JSGlobalObject.h: * runtime/StringPrototype.cpp: (JSC::toLocaleCase): 2016-02-27 Oliver Hunt CLoop build fix. * jit/ExecutableAllocatorFixedVMPool.cpp: 2016-02-26 Oliver Hunt Remove the on demand executable allocator https://bugs.webkit.org/show_bug.cgi?id=154749 Reviewed by Geoffrey Garen. Remove all the DemandExecutable code and executable allocator ifdefs. * CMakeLists.txt: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * jit/ExecutableAllocator.cpp: Removed. (JSC::DemandExecutableAllocator::DemandExecutableAllocator): Deleted. (JSC::DemandExecutableAllocator::~DemandExecutableAllocator): Deleted. (JSC::DemandExecutableAllocator::bytesAllocatedByAllAllocators): Deleted. (JSC::DemandExecutableAllocator::bytesCommittedByAllocactors): Deleted. (JSC::DemandExecutableAllocator::dumpProfileFromAllAllocators): Deleted. (JSC::DemandExecutableAllocator::allocateNewSpace): Deleted. (JSC::DemandExecutableAllocator::notifyNeedPage): Deleted. (JSC::DemandExecutableAllocator::notifyPageIsFree): Deleted. (JSC::DemandExecutableAllocator::allocators): Deleted. (JSC::DemandExecutableAllocator::allocatorsMutex): Deleted. (JSC::ExecutableAllocator::initializeAllocator): Deleted. (JSC::ExecutableAllocator::ExecutableAllocator): Deleted. (JSC::ExecutableAllocator::~ExecutableAllocator): Deleted. (JSC::ExecutableAllocator::isValid): Deleted. (JSC::ExecutableAllocator::underMemoryPressure): Deleted. (JSC::ExecutableAllocator::memoryPressureMultiplier): Deleted. (JSC::ExecutableAllocator::allocate): Deleted. (JSC::ExecutableAllocator::committedByteCount): Deleted. (JSC::ExecutableAllocator::dumpProfile): Deleted. (JSC::ExecutableAllocator::getLock): Deleted. (JSC::ExecutableAllocator::isValidExecutableMemory): Deleted. (JSC::ExecutableAllocator::reprotectRegion): Deleted. * jit/ExecutableAllocator.h: * jit/ExecutableAllocatorFixedVMPool.cpp: * jit/JITStubRoutine.h: (JSC::JITStubRoutine::canPerformRangeFilter): Deleted. (JSC::JITStubRoutine::filteringStartAddress): Deleted. (JSC::JITStubRoutine::filteringExtentSize): Deleted. 2016-02-26 Joseph Pecoraro Reduce direct callers of Structure::findStructuresAndMapForMaterialization https://bugs.webkit.org/show_bug.cgi?id=154751 Reviewed by Mark Lam. * runtime/Structure.cpp: (JSC::Structure::toStructureShape): This property name iteration is identical to Structure::forEachPropertyConcurrently. Share the code and reduce callers to the subtle findStructuresAndMapForMaterialization. 2016-02-26 Mark Lam Function.name and Function.length should be configurable. https://bugs.webkit.org/show_bug.cgi?id=154604 Reviewed by Saam Barati. According to https://tc39.github.io/ecma262/#sec-ecmascript-language-functions-and-classes, "Unless otherwise specified, the name property of a built-in Function object, if it exists, has the attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }." Similarly, "the length property of a built-in Function object has the attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }." This patch makes Function.name and Function.length configurable. We do this by lazily reifying the JSFunction name and length properties on first access. We track whether each of these properties have been reified using flags in the FunctionRareData. On first access, if not already reified, we will put the property into the object with its default value and attributes and set the reified flag. Thereafter, we rely on the base JSObject to handle access to the property. Also, lots of test results have to be re-baselined because the old Function.length has attribute DontDelete, which is in conflict with the ES6 requirement that it is configurable. * runtime/FunctionRareData.h: (JSC::FunctionRareData::hasReifiedLength): (JSC::FunctionRareData::setHasReifiedLength): (JSC::FunctionRareData::hasReifiedName): (JSC::FunctionRareData::setHasReifiedName): - Flags for tracking whether each property has been reified. * runtime/JSFunction.cpp: (JSC::JSFunction::finishCreation): (JSC::JSFunction::createBuiltinFunction): - Host and builtin functions currently always reify their name and length properties. Currently, for builtins, the default names that are used may differ from the executable name. For now, we'll stay with keeping this alternate approach to getting the name and length properties for host and builtin functions. However, we need their default attribute to be configurable as well. (JSC::JSFunction::getOwnPropertySlot): (JSC::JSFunction::getOwnNonIndexPropertyNames): (JSC::JSFunction::put): (JSC::JSFunction::deleteProperty): (JSC::JSFunction::defineOwnProperty): (JSC::JSFunction::reifyLength): (JSC::JSFunction::reifyName): (JSC::JSFunction::reifyLazyPropertyIfNeeded): (JSC::JSFunction::lengthGetter): Deleted. (JSC::JSFunction::nameGetter): Deleted. * runtime/JSFunction.h: * runtime/JSFunctionInlines.h: (JSC::JSFunction::hasReifiedLength): (JSC::JSFunction::hasReifiedName): * tests/es6.yaml: - 4 new passing tests. * tests/mozilla/ecma/Array/15.4.4.3-1.js: * tests/mozilla/ecma/Array/15.4.4.4-1.js: * tests/mozilla/ecma/Array/15.4.4.4-2.js: * tests/mozilla/ecma/GlobalObject/15.1.2.1-1.js: * tests/mozilla/ecma/GlobalObject/15.1.2.2-1.js: * tests/mozilla/ecma/GlobalObject/15.1.2.3-1.js: * tests/mozilla/ecma/GlobalObject/15.1.2.4.js: * tests/mozilla/ecma/GlobalObject/15.1.2.5-1.js: * tests/mozilla/ecma/GlobalObject/15.1.2.6.js: * tests/mozilla/ecma/GlobalObject/15.1.2.7.js: * tests/mozilla/ecma/String/15.5.4.10-1.js: * tests/mozilla/ecma/String/15.5.4.11-1.js: * tests/mozilla/ecma/String/15.5.4.11-5.js: * tests/mozilla/ecma/String/15.5.4.12-1.js: * tests/mozilla/ecma/String/15.5.4.6-2.js: * tests/mozilla/ecma/String/15.5.4.7-2.js: * tests/mozilla/ecma/String/15.5.4.8-1.js: * tests/mozilla/ecma/String/15.5.4.9-1.js: - Rebase expected test results. * tests/stress/function-configurable-properties.js: Added. 2016-02-26 Keith Miller Folding of OverridesHasInstance DFG nodes shoud happen in constant folding not fixup https://bugs.webkit.org/show_bug.cgi?id=154743 Reviewed by Mark Lam. * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): 2016-02-26 Keith Miller Native Typed Array functions should use Symbol.species https://bugs.webkit.org/show_bug.cgi?id=154569 Reviewed by Michael Saboff. This patch adds support for Symbol.species in the native Typed Array prototype functions. Additionally, now that other types of typedarrays are creatable inside the slice we use the JSGenericTypedArrayView::set function, which has been beefed up, to put everything into the correct place. * runtime/JSDataView.cpp: (JSC::JSDataView::set): * runtime/JSDataView.h: * runtime/JSGenericTypedArrayView.h: * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewFromIterator): (JSC::constructGenericTypedArrayViewWithArguments): (JSC::constructGenericTypedArrayView): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::setWithSpecificType): (JSC::JSGenericTypedArrayView::set): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::speciesConstruct): (JSC::genericTypedArrayViewProtoFuncSet): (JSC::genericTypedArrayViewProtoFuncSlice): (JSC::genericTypedArrayViewProtoFuncSubarray): * tests/stress/typedarray-slice.js: (subclasses.typedArrays.map): (testSpecies): (forEach): (subclasses.forEach): (testSpeciesRemoveConstructor): (testSpeciesWithSameBuffer): * tests/stress/typedarray-subarray.js: Added. (subclasses.typedArrays.map): (testSpecies): (forEach): (subclasses.forEach): (testSpeciesRemoveConstructor): 2016-02-26 Benjamin Poulain [JSC] Add32(Imm, Tmp, Tmp) does not ZDef the destination if Imm is zero https://bugs.webkit.org/show_bug.cgi?id=154704 Reviewed by Geoffrey Garen. If the Imm is zero, we should still zero the top bits to match the definition in AirOpcodes. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::add32): * b3/testb3.cpp: 2016-02-26 Oliver Hunt Make testRegExp not crash when given an invalid regexp https://bugs.webkit.org/show_bug.cgi?id=154732 Reviewed by Mark Lam. * testRegExp.cpp: (parseRegExpLine): 2016-02-26 Benjamin Poulain [JSC] Add the test for r197155 https://bugs.webkit.org/show_bug.cgi?id=154715 Reviewed by Mark Lam. Silly me. I forgot the test in the latest patch update. * tests/stress/class-syntax-tdz-osr-entry-in-loop.js: Added. 2016-02-26 Yusuke Suzuki [DFG] Drop unnecessary proved type branch in ToPrimitive https://bugs.webkit.org/show_bug.cgi?id=154716 Reviewed by Geoffrey Garen. This branching based on the proved types is unnecessary because this is already handled in constant folding phase. In fact, the DFGSpeculativeJIT64.cpp case is already removed in r164243. This patch removes the remaining JIT32_64 case. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2016-02-25 Benjamin Poulain [JSC] Be aggressive with OSR Entry to FTL if the DFG function was only used for OSR Entry itself https://bugs.webkit.org/show_bug.cgi?id=154575 Reviewed by Filip Pizlo. I noticed that imaging-gaussian-blur spends most of its samples in DFG code despite executing most of the loop iterations in FTL. On this particular test, the main function is only entered once and have a very heavy loop there. What happens is DFG starts by compiling the full function in FTL. That takes about 8 to 10 milliseconds during which the DFG code makes very little progress. The calls to triggerOSREntryNow() try to OSR Enter for a while then finally start compiling something. By the time the function is ready, we have wasted a lot of time in DFG code. What this patch does is set a flag when a DFG function is entered. If we try to triggerOSREntryNow() and the flag was never set, we start compiling both the full function and the one for OSR Entry. * dfg/DFGJITCode.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileEntryExecutionFlag): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGJITCompiler.h: * dfg/DFGOperations.cpp: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::Plan): Deleted. * dfg/DFGPlan.h: * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): 2016-02-25 Benjamin Poulain [JSC] Temporal Dead Zone checks on "this" are eliminated when doing OSR Entry to FTL https://bugs.webkit.org/show_bug.cgi?id=154664 Reviewed by Saam Barati. When doing OSR Enter into a constructor, we lose the information that this may have been set to empty by a previously executed block. All the code just assumed the type for a FlushedJS value and thus not an empty value. It was then okay to eliminate the TDZ checks. In this patch, the values on root entry now assume they may be empty. As a result, the SetArgument() for "this" has "empty" as possible type and the TDZ checks are no longer eliminated. * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): 2016-02-25 Ada Chan Update the definition of ENABLE_VIDEO_PRESENTATION_MODE for Mac platform https://bugs.webkit.org/show_bug.cgi?id=154702 Reviewed by Dan Bernstein. * Configurations/FeatureDefines.xcconfig: 2016-02-25 Saam barati [ES6] for...in iteration doesn't comply with the specification https://bugs.webkit.org/show_bug.cgi?id=154665 Reviewed by Michael Saboff. If you read ForIn/OfHeadEvaluation inside the spec: https://tc39.github.io/ecma262/#sec-runtime-semantics-forin-div-ofheadevaluation-tdznames-expr-iterationkind It calls EnumerateObjectProperties(obj) to get a set of properties to enumerate over (it models this "set" as en ES6 generator function). EnumerateObjectProperties is defined in section 13.7.5.15: https://tc39.github.io/ecma262/#sec-enumerate-object-properties The implementation calls Reflect.getOwnPropertyDescriptor(.) on the properties it sees. We must do the same by modeling the operation as a [[GetOwnProperty]] instead of a [[HasProperty]] internal method call. * jit/JITOperations.cpp: * jit/JITOperations.h: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/JSObject.cpp: (JSC::JSObject::hasProperty): (JSC::JSObject::hasPropertyGeneric): * runtime/JSObject.h: * tests/stress/proxy-get-own-property.js: (assert): (let.handler.getOwnPropertyDescriptor): (i.set assert): 2016-02-25 Saam barati [ES6] Implement Proxy.[[Set]] https://bugs.webkit.org/show_bug.cgi?id=154511 Reviewed by Filip Pizlo. This patch is mostly an implementation of Proxy.[[Set]] with respect to section 9.5.9 of the ECMAScript spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-set-p-v-receiver This patch also changes JSObject::putInline and JSObject::putByIndex to be aware that a Proxy in the prototype chain will intercept property accesses. * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype): * runtime/JSObject.h: * runtime/JSObjectInlines.h: (JSC::JSObject::canPerformFastPutInline): (JSC::JSObject::putInline): * runtime/JSType.h: * runtime/ProxyObject.cpp: (JSC::ProxyObject::getOwnPropertySlotByIndex): (JSC::ProxyObject::performPut): (JSC::ProxyObject::put): (JSC::ProxyObject::putByIndexCommon): (JSC::ProxyObject::putByIndex): (JSC::performProxyCall): (JSC::ProxyObject::getCallData): (JSC::performProxyConstruct): (JSC::ProxyObject::deletePropertyByIndex): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: (JSC::ProxyObject::create): (JSC::ProxyObject::createStructure): (JSC::ProxyObject::target): (JSC::ProxyObject::handler): * tests/es6.yaml: * tests/stress/proxy-set.js: Added. (assert): (throw.new.Error.let.handler.set 45): (throw.new.Error): (let.target.set x): (let.target.get x): (set let): 2016-02-25 Benjamin Poulain [JSC] Remove a useless "Move" in the lowering of Select https://bugs.webkit.org/show_bug.cgi?id=154670 Reviewed by Geoffrey Garen. I left the Move instruction when creating the aliasing form of Select. On ARM64, that meant a useless move for any case that can't be coalesced. On x86, that meant an extra constraint on child2, making it stupidly hard to alias child1. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::createSelect): Deleted. 2016-02-24 Joseph Pecoraro Web Inspector: Expose Proxy target and handler internal properties to Inspector https://bugs.webkit.org/show_bug.cgi?id=154663 Reviewed by Timothy Hatcher. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::getInternalProperties): Expose the ProxyObject's target and handler. 2016-02-24 Nikos Andronikos [web-animations] Add AnimationTimeline, DocumentTimeline and add extensions to Document interface https://bugs.webkit.org/show_bug.cgi?id=151688 Reviewed by Dean Jackson. Enables the WEB_ANIMATIONS compiler switch. * Configurations/FeatureDefines.xcconfig: 2016-02-24 Konstantin Tokarev [cmake] Moved PRE/POST_BUILD_COMMAND to WEBKIT_FRAMEWORK. https://bugs.webkit.org/show_bug.cgi?id=154651 Reviewed by Alex Christensen. * CMakeLists.txt: Moved shared code to WEBKIT_FRAMEWORK macro. 2016-02-24 Commit Queue Unreviewed, rolling out r197033. https://bugs.webkit.org/show_bug.cgi?id=154649 "It broke JSC tests when 'this' was loaded from global scope" (Requested by saamyjoon on #webkit). Reverted changeset: "[ES6] Arrow function syntax. Emit loading&putting this/super only if they are used in arrow function" https://bugs.webkit.org/show_bug.cgi?id=153981 http://trac.webkit.org/changeset/197033 2016-02-24 Saam Barati [ES6] Implement Proxy.[[Delete]] https://bugs.webkit.org/show_bug.cgi?id=154607 Reviewed by Mark Lam. This patch implements Proxy.[[Delete]] with respect to section 9.5.10 of the ECMAScript spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-delete-p * runtime/ProxyObject.cpp: (JSC::ProxyObject::getConstructData): (JSC::ProxyObject::performDelete): (JSC::ProxyObject::deleteProperty): (JSC::ProxyObject::deletePropertyByIndex): * runtime/ProxyObject.h: * tests/es6.yaml: * tests/stress/proxy-delete.js: Added. (assert): (throw.new.Error.let.handler.get deleteProperty): (throw.new.Error): (assert.let.handler.deleteProperty): (let.handler.deleteProperty): 2016-02-24 Filip Pizlo Stackmaps have problems with double register constraints https://bugs.webkit.org/show_bug.cgi?id=154643 Reviewed by Geoffrey Garen. This is currently a benign bug. I found it while playing. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::fillStackmap): * b3/testb3.cpp: (JSC::B3::testURShiftSelf64): (JSC::B3::testPatchpointDoubleRegs): (JSC::B3::zero): (JSC::B3::run): 2016-02-24 Skachkov Oleksandr [ES6] Arrow function syntax. Emit loading&putting this/super only if they are used in arrow function https://bugs.webkit.org/show_bug.cgi?id=153981 Reviewed by Saam Barati. In first iteration of implemenation arrow function, we emit load and store variables 'this', 'arguments', 'super', 'new.target' in case if arrow function is exist even variables are not used in arrow function. Current patch added logic that prevent from emiting those varibles if they are not used in arrow function. During syntax analyze parser store information about using variables in arrow function inside of the ordinary function scope and then put to BytecodeGenerator through UnlinkedCodeBlock * bytecode/ExecutableInfo.h: (JSC::ExecutableInfo::ExecutableInfo): (JSC::ExecutableInfo::arrowFunctionCodeFeatures): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::arrowFunctionCodeFeatures): (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseArguments): (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseSuperCall): (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseSuperProperty): (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseEval): (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseThis): (JSC::UnlinkedCodeBlock::doAnyInnerArrowFunctionsUseNewTarget): * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): * bytecode/UnlinkedFunctionExecutable.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded): (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment): (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction): (JSC::BytecodeGenerator::isArgumentsUsedInInnerArrowFunction): (JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction): (JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction): (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope): (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope): (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::ThisNode::emitBytecode): (JSC::EvalFunctionCallNode::emitBytecode): (JSC::FunctionCallValueNode::emitBytecode): (JSC::FunctionNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createFunctionMetadata): * parser/Nodes.cpp: (JSC::FunctionMetadataNode::FunctionMetadataNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::Parser::parseGeneratorFunctionSourceElements): (JSC::Parser::parseFunctionBody): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseProperty): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::parseMemberExpression): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::isArrowFunctionBoundary): (JSC::Scope::innerArrowFunctionFeatures): (JSC::Scope::setInnerArrowFunctionUseSuperCall): (JSC::Scope::setInnerArrowFunctionUseSuperProperty): (JSC::Scope::setInnerArrowFunctionUseEval): (JSC::Scope::setInnerArrowFunctionUseThis): (JSC::Scope::setInnerArrowFunctionUseNewTarget): (JSC::Scope::setInnerArrowFunctionUseArguments): (JSC::Scope::setInnerArrowFunctionUseEvalAndUseArgumentsIfNeeded): (JSC::Scope::collectFreeVariables): (JSC::Scope::mergeInnerArrowFunctionFeatures): (JSC::Scope::fillParametersForSourceProviderCache): (JSC::Scope::restoreFromSourceProviderCache): (JSC::Scope::setIsFunction): (JSC::Scope::setIsArrowFunction): (JSC::Parser::closestParentNonArrowFunctionNonLexicalScope): (JSC::Parser::pushScope): (JSC::Parser::popScopeInternal): * parser/ParserModes.h: * parser/SourceProviderCacheItem.h: (JSC::SourceProviderCacheItem::SourceProviderCacheItem): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createFunctionMetadata): * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js: * tests/stress/arrowfunction-lexical-bind-arguments-strict.js: * tests/stress/arrowfunction-lexical-bind-newtarget.js: * tests/stress/arrowfunction-lexical-bind-superproperty.js: * tests/stress/arrowfunction-lexical-bind-this-8.js: Added. 2016-02-23 Brian Burg Web Inspector: teach the Objective-C protocol generators about --frontend and --backend directives https://bugs.webkit.org/show_bug.cgi?id=154615 Reviewed by Timothy Hatcher. Some of the generated Objective-C bindings are only relevant to code acting as the protocol backend. Add a per-generator setting mechanism and propagate --frontend and --backend to all generators. Use the setting in a few generators to omit code that's not needed. Also fix a few places where the code emits the wrong Objective-C class prefix. There is some common non-generated code that must always have the RWIProtocol prefix. Lastly, change includes to use RWIProtocolJSONObjectPrivate.h instead of *Internal.h. The macros defined in the internal header now need to be used outside of the framework. * inspector/scripts/codegen/generate_objc_conversion_helpers.py: Use OBJC_STATIC_PREFIX along with the file name and use different include syntax depending on the target framework. * inspector/scripts/codegen/generate_objc_header.py: (ObjCHeaderGenerator.generate_output): For now, omit generating command protocol and event dispatchers when generating for --frontend. (ObjCHeaderGenerator._generate_type_interface): Use OBJC_STATIC_PREFIX along with the unprefixed file name. * inspector/scripts/codegen/generate_objc_internal_header.py: Use RWIProtocolJSONObjectPrivate.h instead. * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator.generate_output): Include the Internal header if it's being generated (only for --backend). * inspector/scripts/codegen/generator.py: (Generator.__init__): (Generator.set_generator_setting): (Generator): (Generator.get_generator_setting): Crib a simple setting system from the Framework class. Make the names more obnoxious. (Generator.string_for_file_include): Inspired by the replay input generator, this is a function that uses the proper syntax for a file include depending on the file's framework and target framework. * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator.and): (ObjCGenerator.and.objc_prefix): (ObjCGenerator): (ObjCGenerator.objc_type_for_raw_name): (ObjCGenerator.objc_class_for_raw_name): Whitelist the 'Automation' domain for the ObjC generators. Revise use of OBJC_STATIC_PREFIX. * inspector/scripts/generate-inspector-protocol-bindings.py: (generate_from_specification): Change the generators to use for the frontend. Propagate --frontend and --backend. * 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: Rebaseline tests. They now correctly include RWIProtocolJSONObject.h and the like. 2016-02-23 Saam barati arrayProtoFuncConcat doesn't check for an exception after allocating an array https://bugs.webkit.org/show_bug.cgi?id=154621 Reviewed by Michael Saboff. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncConcat): 2016-02-23 Dan Bernstein [Xcode] Linker errors display mangled names, but no longer should https://bugs.webkit.org/show_bug.cgi?id=154632 Reviewed by Sam Weinig. * Configurations/Base.xcconfig: Stop setting LINKER_DISPLAYS_MANGLED_NAMES to YES. 2016-02-23 Gavin Barraclough Remove HIDDEN_PAGE_DOM_TIMER_THROTTLING feature define https://bugs.webkit.org/show_bug.cgi?id=112323 Reviewed by Chris Dumez. This feature is controlled by a runtime switch, and defaults off. * Configurations/FeatureDefines.xcconfig: 2016-02-23 Keith Miller JSC stress tests' standalone-pre.js should exit on the first failure by default https://bugs.webkit.org/show_bug.cgi?id=154565 Reviewed by Mark Lam. Currently, if a test writer does not call finishJSTest() at the end of any test using stress/resources/standalone-pre.js then the test can fail without actually reporting an error to the harness. By default, we should throw on the first error so, in the event someone does not call finishJSTest() the harness will still notice the error. * tests/stress/regress-151324.js: * tests/stress/resources/standalone-pre.js: (testFailed): 2016-02-23 Saam barati Make JSObject::getMethod have fewer branches https://bugs.webkit.org/show_bug.cgi?id=154603 Reviewed by Mark Lam. Writing code with fewer branches is almost always better. * runtime/JSObject.cpp: (JSC::JSObject::getMethod): 2016-02-23 Filip Pizlo B3::Value doesn't self-destruct virtually enough (Causes many leaks in LowerDFGToB3::appendOSRExit) https://bugs.webkit.org/show_bug.cgi?id=154592 Reviewed by Saam Barati. If Foo has a virtual destructor, then: foo->Foo::~Foo() does a non-virtual call to Foo's destructor. Even if foo points to a subclass of Foo that overrides the destructor, this syntax will not call that override. foo->~Foo() does a virtual call to the destructor, and so if foo points to a subclass, you get the subclass's override. In B3, we used this->Value::~Value() thinking that it would call the subclass's override. This caused leaks because this didn't actually call the subclass's override. This fixes the problem by using this->~Value() instead. * b3/B3ControlValue.cpp: (JSC::B3::ControlValue::convertToJump): (JSC::B3::ControlValue::convertToOops): * b3/B3Value.cpp: (JSC::B3::Value::replaceWithIdentity): (JSC::B3::Value::replaceWithNop): (JSC::B3::Value::replaceWithPhi): 2016-02-23 Brian Burg Web Inspector: the protocol generator's Objective-C name prefix should be configurable https://bugs.webkit.org/show_bug.cgi?id=154596 Reviewed by Timothy Hatcher. In order to support different generated protocol sets that don't have conflicting file and type names, allow the Objective-C prefix to be configurable based on the target framework. Each name also has the implicit prefix 'Protocol' appended to the per-target framework prefix. For example, the existing protocol for remote inspection has the prefix 'RWI' and is generated as 'RWIProtocol'. The WebKit framework has the 'Automation' prefix and is generated as 'AutomationProtocol'. To make this change, convert ObjCGenerator to be a subclass of Generator and use the instance method model() to find the target framework and its setting for 'objc_prefix'. Make all ObjC generators subclass ObjCGenerator so they can use these instance methods that used to be static methods. This is a large but mechanical change to use self instead of ObjCGenerator. * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py: (ObjCBackendDispatcherHeaderGenerator): (ObjCBackendDispatcherHeaderGenerator.__init__): (ObjCBackendDispatcherHeaderGenerator.output_filename): (ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations): (ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain): * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py: (ObjCConfigurationImplementationGenerator): (ObjCConfigurationImplementationGenerator.__init__): (ObjCConfigurationImplementationGenerator.output_filename): (ObjCConfigurationImplementationGenerator.generate_output): (ObjCConfigurationImplementationGenerator._generate_success_block_for_command): (ObjCConfigurationImplementationGenerator._generate_success_block_for_command.and): (ObjCConfigurationImplementationGenerator._generate_conversions_for_command): * inspector/scripts/codegen/generate_objc_configuration_header.py: (ObjCConfigurationHeaderGenerator): (ObjCConfigurationHeaderGenerator.__init__): (ObjCConfigurationHeaderGenerator.output_filename): (ObjCConfigurationHeaderGenerator.generate_output): (ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains): (ObjCConfigurationHeaderGenerator._generate_properties_for_domain): * inspector/scripts/codegen/generate_objc_configuration_implementation.py: (ObjCBackendDispatcherImplementationGenerator): (ObjCBackendDispatcherImplementationGenerator.__init__): (ObjCBackendDispatcherImplementationGenerator.output_filename): (ObjCBackendDispatcherImplementationGenerator.generate_output): (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains): (ObjCBackendDispatcherImplementationGenerator._generate_ivars): (ObjCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain): (ObjCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain): * inspector/scripts/codegen/generate_objc_conversion_helpers.py: (ObjCConversionHelpersGenerator): (ObjCConversionHelpersGenerator.__init__): (ObjCConversionHelpersGenerator.output_filename): (ObjCConversionHelpersGenerator.generate_output): (ObjCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_declaration): (ObjCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_member): (ObjCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_parameter): * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py: (ObjCFrontendDispatcherImplementationGenerator): (ObjCFrontendDispatcherImplementationGenerator.__init__): (ObjCFrontendDispatcherImplementationGenerator.output_filename): (ObjCFrontendDispatcherImplementationGenerator.generate_output): (ObjCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations): (ObjCFrontendDispatcherImplementationGenerator._generate_event): (ObjCFrontendDispatcherImplementationGenerator._generate_event.and): (ObjCFrontendDispatcherImplementationGenerator._generate_event_signature): (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters): * inspector/scripts/codegen/generate_objc_header.py: (ObjCHeaderGenerator): (ObjCHeaderGenerator.__init__): (ObjCHeaderGenerator.output_filename): (ObjCHeaderGenerator.generate_output): (ObjCHeaderGenerator._generate_forward_declarations): (ObjCHeaderGenerator._generate_anonymous_enum_for_declaration): (ObjCHeaderGenerator._generate_anonymous_enum_for_member): (ObjCHeaderGenerator._generate_anonymous_enum_for_parameter): (ObjCHeaderGenerator._generate_type_interface): (ObjCHeaderGenerator._generate_init_method_for_required_members): (ObjCHeaderGenerator._generate_member_property): (ObjCHeaderGenerator._generate_command_protocols): (ObjCHeaderGenerator._generate_single_command_protocol): (ObjCHeaderGenerator._callback_block_for_command): (ObjCHeaderGenerator._generate_event_interfaces): (ObjCHeaderGenerator._generate_single_event_interface): * inspector/scripts/codegen/generate_objc_internal_header.py: (ObjCInternalHeaderGenerator): (ObjCInternalHeaderGenerator.__init__): (ObjCInternalHeaderGenerator.output_filename): (ObjCInternalHeaderGenerator.generate_output): (ObjCInternalHeaderGenerator._generate_event_dispatcher_private_interfaces): * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator): (ObjCProtocolTypesImplementationGenerator.__init__): (ObjCProtocolTypesImplementationGenerator.output_filename): (ObjCProtocolTypesImplementationGenerator.generate_output): (ObjCProtocolTypesImplementationGenerator.generate_type_implementation): (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members): (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members.and): (ObjCProtocolTypesImplementationGenerator._generate_setter_for_member): (ObjCProtocolTypesImplementationGenerator._generate_setter_for_member.and): (ObjCProtocolTypesImplementationGenerator._generate_getter_for_member): * inspector/scripts/codegen/models.py: * inspector/scripts/codegen/objc_generator.py: (ObjCTypeCategory.category_for_type): (ObjCGenerator): (ObjCGenerator.__init__): (ObjCGenerator.objc_prefix): (ObjCGenerator.objc_name_for_type): (ObjCGenerator.objc_enum_name_for_anonymous_enum_declaration): (ObjCGenerator.objc_enum_name_for_anonymous_enum_member): (ObjCGenerator.objc_enum_name_for_anonymous_enum_parameter): (ObjCGenerator.objc_enum_name_for_non_anonymous_enum): (ObjCGenerator.objc_class_for_type): (ObjCGenerator.objc_class_for_array_type): (ObjCGenerator.objc_accessor_type_for_member): (ObjCGenerator.objc_accessor_type_for_member_internal): (ObjCGenerator.objc_type_for_member): (ObjCGenerator.objc_type_for_member_internal): (ObjCGenerator.objc_type_for_param): (ObjCGenerator.objc_type_for_param_internal): (ObjCGenerator.objc_protocol_export_expression_for_variable): (ObjCGenerator.objc_protocol_import_expression_for_member): (ObjCGenerator.objc_protocol_import_expression_for_parameter): (ObjCGenerator.objc_protocol_import_expression_for_variable): (ObjCGenerator.objc_to_protocol_expression_for_member): (ObjCGenerator.protocol_to_objc_expression_for_member): Change the prefix for the 'Test' target framework to be 'Test.' Rebaseline results. * 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-02-23 Mark Lam Debug assertion failure while loading http://kangax.github.io/compat-table/es6/. https://bugs.webkit.org/show_bug.cgi?id=154542 Reviewed by Saam Barati. According to the spec, the constructors of the following types "are not intended to be called as a function and will throw an exception". These types are: TypedArrays - https://tc39.github.io/ecma262/#sec-typedarray-constructors Map - https://tc39.github.io/ecma262/#sec-map-constructor Set - https://tc39.github.io/ecma262/#sec-set-constructor WeakMap - https://tc39.github.io/ecma262/#sec-weakmap-constructor WeakSet - https://tc39.github.io/ecma262/#sec-weakset-constructor ArrayBuffer - https://tc39.github.io/ecma262/#sec-arraybuffer-constructor DataView - https://tc39.github.io/ecma262/#sec-dataview-constructor Promise - https://tc39.github.io/ecma262/#sec-promise-constructor Proxy - https://tc39.github.io/ecma262/#sec-proxy-constructor This patch does the foillowing: 1. Ensures that these constructors can be called but will throw a TypeError when called. 2. Makes all these objects use throwConstructorCannotBeCalledAsFunctionTypeError() in their implementation to be consistent. 3. Change the error message to "calling XXX constructor without new is invalid". This is clearer because the error is likely due to the user forgetting to use the new operator on these constructors. * runtime/Error.h: * runtime/Error.cpp: (JSC::throwConstructorCannotBeCalledAsFunctionTypeError): - Added a convenience function to throw the TypeError. * runtime/JSArrayBufferConstructor.cpp: (JSC::constructArrayBuffer): (JSC::callArrayBuffer): (JSC::JSArrayBufferConstructor::getCallData): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::callGenericTypedArrayView): (JSC::JSGenericTypedArrayViewConstructor::getCallData): * runtime/JSPromiseConstructor.cpp: (JSC::callPromise): * runtime/MapConstructor.cpp: (JSC::callMap): * runtime/ProxyConstructor.cpp: (JSC::callProxy): (JSC::ProxyConstructor::getCallData): * runtime/SetConstructor.cpp: (JSC::callSet): * runtime/WeakMapConstructor.cpp: (JSC::callWeakMap): * runtime/WeakSetConstructor.cpp: (JSC::callWeakSet): * tests/es6.yaml: - The typed_arrays_%TypedArray%[Symbol.species].js test now passes. * tests/stress/call-non-calleable-constructors-as-function.js: Added. (test): * tests/stress/map-constructor.js: (testCallTypeError): * tests/stress/promise-cannot-be-called.js: (shouldThrow): * tests/stress/proxy-basic.js: * tests/stress/set-constructor.js: * tests/stress/throw-from-ftl-call-ic-slow-path-cells.js: (i.catch): * tests/stress/throw-from-ftl-call-ic-slow-path-undefined.js: (i.catch): * tests/stress/throw-from-ftl-call-ic-slow-path.js: (i.catch): * tests/stress/weak-map-constructor.js: (testCallTypeError): * tests/stress/weak-set-constructor.js: - Updated error message string. 2016-02-23 Alexey Proskuryakov ASan build fix. Let's not export a template function that is only used in InspectorBackendDispatcher.cpp. * inspector/InspectorBackendDispatcher.h: 2016-02-23 Brian Burg Connect WebAutomationSession to its backend dispatcher as if it were an agent and add stub implementations https://bugs.webkit.org/show_bug.cgi?id=154518 Reviewed by Timothy Hatcher. * inspector/InspectorBackendDispatcher.h: Export all the classes since they are used by WebKit::WebAutomationSession. 2016-02-22 Brian Burg Web Inspector: add 'Automation' protocol domain and generate its backend classes separately in WebKit2 https://bugs.webkit.org/show_bug.cgi?id=154509 Reviewed by Timothy Hatcher. Add a new 'WebKit' framework, which is used to generate protocol code in WebKit2. Add --backend and --frontend flags to the main generator script. These allow a framework to trigger two different sets of generators so they can be separately generated and compiled. * inspector/scripts/codegen/models.py: (Framework.fromString): (Frameworks): Add new framework. * inspector/scripts/generate-inspector-protocol-bindings.py: If neither --backend or --frontend is specified, assume both are wanted. This matches the behavior for JavaScriptCore and WebInspector frameworks. (generate_from_specification): Generate C++ files for the backend and Objective-C files for the frontend. 2016-02-22 Saam barati JSGlobalObject doesn't visit ProxyObjectStructure during GC https://bugs.webkit.org/show_bug.cgi?id=154564 Rubber stamped by Mark Lam. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::visitChildren): 2016-02-22 Saam barati InternalFunction::createSubclassStructure doesn't take into account that get() might throw https://bugs.webkit.org/show_bug.cgi?id=154548 Reviewed by Mark Lam and Geoffrey Garen and Andreas Kling. InternalFunction::createSubclassStructure calls newTarget.get(...) which can throw an exception. Neither the function nor the call sites of the function took this into account. This patch audits the call sites of the function to make it work in the event that an exception is thrown. * runtime/BooleanConstructor.cpp: (JSC::constructWithBooleanConstructor): * runtime/DateConstructor.cpp: (JSC::constructDate): * runtime/ErrorConstructor.cpp: (JSC::Interpreter::constructWithErrorConstructor): * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/InternalFunction.cpp: (JSC::InternalFunction::createSubclassStructure): * runtime/JSArrayBufferConstructor.cpp: (JSC::constructArrayBuffer): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayView): * runtime/JSGlobalObject.h: (JSC::constructEmptyArray): (JSC::constructArray): (JSC::constructArrayNegativeIndexed): * runtime/JSPromiseConstructor.cpp: (JSC::constructPromise): * runtime/MapConstructor.cpp: (JSC::constructMap): * runtime/NativeErrorConstructor.cpp: (JSC::Interpreter::constructWithNativeErrorConstructor): * runtime/NumberConstructor.cpp: (JSC::constructWithNumberConstructor): * runtime/RegExpConstructor.cpp: (JSC::getRegExpStructure): (JSC::constructRegExp): (JSC::constructWithRegExpConstructor): * runtime/SetConstructor.cpp: (JSC::constructSet): * runtime/StringConstructor.cpp: (JSC::constructWithStringConstructor): (JSC::StringConstructor::getConstructData): * runtime/WeakMapConstructor.cpp: (JSC::constructWeakMap): * runtime/WeakSetConstructor.cpp: (JSC::constructWeakSet): * tests/stress/create-subclass-structure-might-throw.js: Added. (assert): 2016-02-22 Ting-Wei Lan Fix build and implement functions to retrieve registers on FreeBSD https://bugs.webkit.org/show_bug.cgi?id=152258 Reviewed by Michael Catanzaro. * heap/MachineStackMarker.cpp: (pthreadSignalHandlerSuspendResume): struct ucontext is not specified in POSIX and it is not available on FreeBSD. Replacing it with ucontext_t fixes the build problem. (JSC::MachineThreads::Thread::Registers::stackPointer): (JSC::MachineThreads::Thread::Registers::framePointer): (JSC::MachineThreads::Thread::Registers::instructionPointer): (JSC::MachineThreads::Thread::Registers::llintPC): * heap/MachineStackMarker.h: 2016-02-22 Saam barati JSValue::isConstructor and JSValue::isFunction should check getConstructData and getCallData https://bugs.webkit.org/show_bug.cgi?id=154552 Reviewed by Mark Lam. ES6 Proxy breaks our isFunction() and isConstructor() JSValue methods. They return false on a Proxy with internal [[Call]] and [[Construct]] properties. It seems safest, most forward looking, and most adherent to the specification to check getCallData() and getConstructData() to implement these functions. * runtime/InternalFunction.cpp: (JSC::InternalFunction::createSubclassStructure): * runtime/JSCJSValueInlines.h: (JSC::JSValue::isFunction): (JSC::JSValue::isConstructor): 2016-02-22 Keith Miller Bound functions should use the prototype of the function being bound https://bugs.webkit.org/show_bug.cgi?id=154195 Reviewed by Geoffrey Garen. Per ES6, the result of Function.prototype.bind should have the same prototype as the the function being bound. In order to avoid creating a new structure each time a function is bound we store the new structure in our structure map. However, we cannot currently store structures that have a different GlobalObject than their prototype. In the rare case that the GlobalObject differs or the prototype of the bindee is null we create a new structure each time. To further minimize new structures, as well as making structure lookup faster, we also store the structure in the RareData of the function we are binding. * runtime/FunctionRareData.cpp: (JSC::FunctionRareData::visitChildren): * runtime/FunctionRareData.h: (JSC::FunctionRareData::getBoundFunctionStructure): (JSC::FunctionRareData::setBoundFunctionStructure): * runtime/JSBoundFunction.cpp: (JSC::getBoundFunctionStructure): (JSC::JSBoundFunction::create): * tests/es6.yaml: * tests/stress/bound-function-uses-prototype.js: Added. (testChangeProto.foo): (testChangeProto): (testBuiltins): * tests/stress/class-subclassing-function.js: 2016-02-22 Keith Miller Unreviewed, fix stress test to not print on success. * tests/stress/call-apply-builtin-functions-dont-use-iterators.js: (catch): Deleted. 2016-02-22 Keith Miller Use Symbol.species in the builtin TypedArray.prototype functions https://bugs.webkit.org/show_bug.cgi?id=153384 Reviewed by Geoffrey Garen. This patch adds the use of species constructors to the TypedArray.prototype map and filter functions. It also adds a new private function typedArrayGetOriginalConstructor that returns the TypedArray constructor used to originally create a TypedArray instance. There are no ES6 tests to update for this patch as species creation for these functions is not tested in the compatibility table. * builtins/TypedArrayPrototype.js: (map): (filter): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::typedArrayConstructor): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::typedArrayViewPrivateFuncGetOriginalConstructor): * runtime/JSTypedArrayViewPrototype.h: * tests/stress/typedarray-filter.js: (subclasses.typedArrays.map): (prototype.accept): (testSpecies): (accept): (forEach): (subclasses.forEach): (testSpeciesRemoveConstructor): * tests/stress/typedarray-map.js: (subclasses.typedArrays.map): (prototype.id): (testSpecies): (id): (forEach): (subclasses.forEach): (testSpeciesRemoveConstructor): 2016-02-22 Keith Miller Builtins that should not rely on iteration do. https://bugs.webkit.org/show_bug.cgi?id=154475 Reviewed by Geoffrey Garen. When changing the behavior of varargs calls to use ES6 iterators the call builtin function's use of a varargs call was overlooked. The use of iterators is observable outside the scope of the the call function, thus it must be reimplemented. * builtins/FunctionPrototype.js: (call): * tests/stress/call-apply-builtin-functions-dont-use-iterators.js: Added. (test): (addAll): (catch): 2016-02-22 Konstantin Tokarev [JSC shell] Don't put empty arguments array to VM. https://bugs.webkit.org/show_bug.cgi?id=154516 Reviewed by Geoffrey Garen. This allows arrowfunction-lexical-bind-arguments-top-level test to pass in jsc as well as in browser. * jsc.cpp: (GlobalObject::finishCreation): 2016-02-22 Konstantin Tokarev [cmake] Moved library setup code to WEBKIT_FRAMEWORK macro. https://bugs.webkit.org/show_bug.cgi?id=154450 Reviewed by Alex Christensen. * CMakeLists.txt: 2016-02-22 Commit Queue Unreviewed, rolling out r196891. https://bugs.webkit.org/show_bug.cgi?id=154539 it broke Production builds (Requested by brrian on #webkit). Reverted changeset: "Web Inspector: add 'Automation' protocol domain and generate its backend classes separately in WebKit2" https://bugs.webkit.org/show_bug.cgi?id=154509 http://trac.webkit.org/changeset/196891 2016-02-21 Joseph Pecoraro CodeBlock always visits its unlinked code twice https://bugs.webkit.org/show_bug.cgi?id=154494 Reviewed by Saam Barati. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitChildren): The unlinked code is always visited in stronglyVisitStrongReferences. 2016-02-21 Brian Burg Web Inspector: add 'Automation' protocol domain and generate its backend classes separately in WebKit2 https://bugs.webkit.org/show_bug.cgi?id=154509 Reviewed by Timothy Hatcher. Add a new 'WebKit' framework, which is used to generate protocol code in WebKit2. Add --backend and --frontend flags to the main generator script. These allow a framework to trigger two different sets of generators so they can be separately generated and compiled. * inspector/scripts/codegen/models.py: (Framework.fromString): (Frameworks): Add new framework. * inspector/scripts/generate-inspector-protocol-bindings.py: If neither --backend or --frontend is specified, assume both are wanted. This matches the behavior for JavaScriptCore and WebInspector frameworks. (generate_from_specification): Generate C++ files for the backend and Objective-C files for the frontend. 2016-02-21 Sukolsak Sakshuwong Improvements to Intl code https://bugs.webkit.org/show_bug.cgi?id=154486 Reviewed by Darin Adler. This patch does several things: - Use std::unique_ptr to store ICU objects. - Pass Vector::size() to ICU functions that take a buffer size instead of Vector::capacity(). - If U_SUCCESS(status) is true, it means there is no error, but there could be warnings. ICU functions ignore warnings. So, there is no need to reset status to U_ZERO_ERROR. - Remove the initialization of the String instance variables of IntlDateTimeFormat. These values are never read and cause unnecessary memory allocation. - Fix coding style. - Some small optimization. * runtime/IntlCollator.cpp: (JSC::IntlCollator::UCollatorDeleter::operator()): (JSC::IntlCollator::createCollator): (JSC::IntlCollator::compareStrings): (JSC::IntlCollator::~IntlCollator): Deleted. * runtime/IntlCollator.h: * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::UDateFormatDeleter::operator()): (JSC::defaultTimeZone): (JSC::canonicalizeTimeZoneName): (JSC::toDateTimeOptionsAnyDate): (JSC::IntlDateTimeFormat::initializeDateTimeFormat): (JSC::IntlDateTimeFormat::weekdayString): (JSC::IntlDateTimeFormat::format): (JSC::IntlDateTimeFormat::~IntlDateTimeFormat): Deleted. (JSC::localeData): Deleted. * runtime/IntlDateTimeFormat.h: * runtime/IntlDateTimeFormatConstructor.cpp: * runtime/IntlNumberFormatConstructor.cpp: * runtime/IntlObject.cpp: (JSC::numberingSystemsForLocale): 2016-02-21 Skachkov Oleksandr Remove arrowfunction test cases that rely on arguments variable in jsc https://bugs.webkit.org/show_bug.cgi?id=154517 Reviewed by Yusuke Suzuki. Allow to jsc has the same behavior in javascript as browser has * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js: * tests/stress/arrowfunction-lexical-bind-arguments-strict.js: 2016-02-21 Brian Burg Web Inspector: it should be possible to omit generated code guarded by INSPECTOR_ALTERNATE_DISPATCHERS https://bugs.webkit.org/show_bug.cgi?id=154508 Reviewed by Timothy Hatcher. In preparation for being able to generate protocol files for WebKit2, make it possible to not emit generated code that's guarded by ENABLE(INSPECTOR_ALTERNATE_DISPATCHERS). This code is not needed by backend dispatchers generated outside of JavaScriptCore. We can't just define it to 0 for WebKit2, since it's defined to 1 in in the configurations where the code is actually used. Add a new opt-in Framework configuration option that turns on generating this code. Adjust how the code is generated so that it can be easily excluded. * inspector/scripts/codegen/cpp_generator_templates.py: Make a separate template for the declarations that are guarded. Add an initializer expression so the order of initalizers doesn't matter. * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: (CppBackendDispatcherHeaderGenerator.generate_output): Add a setting check. (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain): If the declarations are needed, they will be appended to the end of the declarations list. * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py: (CppBackendDispatcherImplementationGenerator.generate_output): Add a setting check. (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): Add a setting check. * inspector/scripts/codegen/models.py: Set the 'alternate_dispatchers' setting to True for Framework.JavaScriptCore only. It's not needed elsewhere. Rebaseline affected tests. * 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/generate-domains-with-feature-guards.json-result: 2016-02-21 Brian Burg Web Inspector: clean up generator selection in generate-inspector-protocol-bindings.py https://bugs.webkit.org/show_bug.cgi?id=154505 Reviewed by Timothy Hatcher. It should be possible to generate code for a framework using some generators that other frameworks also use. Right now the generator selection code assumes that use of a generator is mutually exclusive among non-test frameworks. Make this code explicitly switch on the framework. Reorder generators alpabetically within each case. * inspector/scripts/generate-inspector-protocol-bindings.py: (generate_from_specification): Rebaseline tests that are affected by generator reorderings. * 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-02-19 Saam Barati [ES6] Implement Proxy.[[Construct]] https://bugs.webkit.org/show_bug.cgi?id=154440 Reviewed by Oliver Hunt. This patch is mostly an implementation of Proxy.[[Construct]] with respect to section 9.5.13 of the ECMAScript spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-construct-argumentslist-newtarget This patch also changes op_create_this to accept new.target's that aren't JSFunctions. This is necessary implementing Proxy.[[Construct]] because we might construct a JSFunction with a new.target being a Proxy. This will also be needed when we implement Reflect.construct. * dfg/DFGOperations.cpp: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_create_this): (JSC::JIT::emitSlow_op_create_this): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_create_this): (JSC::JIT::emitSlow_op_create_this): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/ProxyObject.cpp: (JSC::ProxyObject::finishCreation): (JSC::ProxyObject::visitChildren): (JSC::performProxyConstruct): (JSC::ProxyObject::getConstructData): * runtime/ProxyObject.h: * tests/es6.yaml: * tests/stress/proxy-construct.js: Added. (assert): (throw.new.Error.let.target): (throw.new.Error): (assert.let.target): (assert.let.handler.get construct): (let.target): (let.handler.construct): (i.catch): (assert.let.handler.construct): (assert.let.construct): (assert.else.assert.let.target): (assert.else.assert.let.construct): (assert.else.assert): (new.proxy.let.target): (new.proxy.let.construct): (new.proxy): 2016-02-19 Sukolsak Sakshuwong [INTL] Implement Number Format Functions https://bugs.webkit.org/show_bug.cgi?id=147605 Reviewed by Darin Adler. This patch implements Intl.NumberFormat.prototype.format() according to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.) * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::UNumberFormatDeleter::operator()): (JSC::IntlNumberFormat::initializeNumberFormat): (JSC::IntlNumberFormat::createNumberFormat): (JSC::IntlNumberFormat::formatNumber): (JSC::IntlNumberFormatFuncFormatNumber): Deleted. * runtime/IntlNumberFormat.h: * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatFuncFormatNumber): 2016-02-18 Gavin Barraclough JSObject::getPropertySlot - index-as-propertyname, override on prototype, & shadow https://bugs.webkit.org/show_bug.cgi?id=154416 Reviewed by Geoff Garen. Here's the bug. Suppose you call JSObject::getOwnProperty and - - PropertyName contains an index, - An object on the prototype chain overrides getOwnPropertySlot, and has that index property, - The base of the access (or another object on the prototype chain) shadows that property. JSObject::getPropertySlot is written assuming the common case is that propertyName is not an index, and as such walks up the prototype chain looking for non-index properties before it tries calling parseIndex. At the point we reach an object on the prototype chain overriding getOwnPropertySlot (which would potentially return the property) we may have already skipped over non-overriding objects that contain the property in index storage. * runtime/JSObject.h: (JSC::JSObject::getOwnNonIndexPropertySlot): - renamed from inlineGetOwnPropertySlot to better describe behaviour; added ASSERT guarding that this method never returns index properties - if it ever does, this is unsafe for getPropertySlot. (JSC::JSObject::getOwnPropertySlot): - inlineGetOwnPropertySlot -> getOwnNonIndexPropertySlot. (JSC::JSObject::getPropertySlot): - In case of object overriding getOwnPropertySlot check if propertyName is an index. (JSC::JSObject::getNonIndexPropertySlot): - called by getPropertySlot if we encounter an object that overrides getOwnPropertySlot, in order to avoid repeated calls to parseIndex. (JSC::JSObject::inlineGetOwnPropertySlot): Deleted. - this was renamed to getOwnNonIndexPropertySlot. (JSC::JSObject::fastGetOwnPropertySlot): Deleted. - this was folded back in to getPropertySlot. 2016-02-19 Saam Barati [ES6] Implement Proxy.[[Call]] https://bugs.webkit.org/show_bug.cgi?id=154425 Reviewed by Mark Lam. This patch is a straight forward implementation of Proxy.[[Call]] with respect to section 9.5.12 of the ECMAScript spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-call-thisargument-argumentslist * runtime/ProxyObject.cpp: (JSC::ProxyObject::finishCreation): (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::getOwnPropertySlotByIndex): (JSC::performProxyCall): (JSC::ProxyObject::getCallData): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: (JSC::ProxyObject::create): * tests/es6.yaml: * tests/stress/proxy-call.js: Added. (assert): (throw.new.Error.let.target): (throw.new.Error.let.handler.apply): (throw.new.Error): (assert.let.target): (assert.let.handler.get apply): (let.target): (let.handler.apply): (i.catch): (assert.let.handler.apply): 2016-02-19 Csaba Osztrogonác Remove more LLVM related dead code after r196729 https://bugs.webkit.org/show_bug.cgi?id=154387 Reviewed by Filip Pizlo. * Configurations/CompileRuntimeToLLVMIR.xcconfig: Removed. * Configurations/LLVMForJSC.xcconfig: Removed. * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.props: Removed. * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj: Removed. * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj.filters: Removed. * JavaScriptCore.xcodeproj/project.pbxproj: * disassembler/X86Disassembler.cpp: 2016-02-19 Joseph Pecoraro Add isJSString(JSCell*) variant to avoid Cell->JSValue->Cell conversion https://bugs.webkit.org/show_bug.cgi?id=154442 Reviewed by Saam Barati. * runtime/JSString.h: (JSC::isJSString): 2016-02-19 Joseph Pecoraro Remove unused SymbolTable::createNameScopeTable https://bugs.webkit.org/show_bug.cgi?id=154443 Reviewed by Saam Barati. * runtime/SymbolTable.h: 2016-02-18 Benjamin Poulain [JSC] Improve the instruction selection of Select https://bugs.webkit.org/show_bug.cgi?id=154432 Reviewed by Filip Pizlo. Plenty of code but this patch is pretty dumb: -On ARM64: use the 3 operand form of CSEL instead of forcing a source to be alised to the destination. This gives more freedom to the register allocator and it is one less Move to process per Select. -On x86, introduce a fake 3 operands form and use aggressive aliasing to try to alias both sources to the destination. If aliasing succeed on the "elseCase", the condition of the Select is reverted in the MacroAssembler. If no aliasing is possible and we end up with 3 registers, the missing move instruction is generated by the MacroAssembler. The missing move is generated after testing the values because the destination can use the same register as one of the test operand. Experimental testing seems to indicate there is no macro-fusion on CMOV, there is no measurable cost to having the move there. * assembler/MacroAssembler.h: (JSC::MacroAssembler::isInvertible): (JSC::MacroAssembler::invert): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::moveConditionallyDouble): (JSC::MacroAssemblerARM64::moveConditionallyFloat): (JSC::MacroAssemblerARM64::moveConditionallyAfterFloatingPointCompare): (JSC::MacroAssemblerARM64::moveConditionally32): (JSC::MacroAssemblerARM64::moveConditionally64): (JSC::MacroAssemblerARM64::moveConditionallyTest32): (JSC::MacroAssemblerARM64::moveConditionallyTest64): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::moveConditionallyDouble): (JSC::MacroAssemblerX86Common::moveConditionallyFloat): (JSC::MacroAssemblerX86Common::moveConditionally32): (JSC::MacroAssemblerX86Common::moveConditionallyTest32): (JSC::MacroAssemblerX86Common::invert): (JSC::MacroAssemblerX86Common::isInvertible): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::moveConditionally64): (JSC::MacroAssemblerX86_64::moveConditionallyTest64): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::createSelect): (JSC::B3::Air::LowerToAir::lower): * b3/air/AirInstInlines.h: (JSC::B3::Air::Inst::shouldTryAliasingDef): * b3/air/AirOpcode.opcodes: 2016-02-18 Gyuyoung Kim [CMake][GTK] Clean up llvm guard in PlatformGTK.cmake https://bugs.webkit.org/show_bug.cgi?id=154430 Reviewed by Saam Barati. llvm isn't used anymore. * PlatformGTK.cmake: Remove USE_LLVM_DISASSEMBLER guard. 2016-02-18 Saam Barati Implement Proxy.[[HasProperty]] https://bugs.webkit.org/show_bug.cgi?id=154313 Reviewed by Filip Pizlo. This patch is a straight forward implementation of Proxy.[[HasProperty]] with respect to section 9.5.7 of the ECMAScript spec. https://tc39.github.io/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-hasproperty-p * runtime/ProxyObject.cpp: (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::performHasProperty): (JSC::ProxyObject::getOwnPropertySlotCommon): * runtime/ProxyObject.h: * tests/es6.yaml: * tests/stress/proxy-basic.js: (assert): (let.handler.has): * tests/stress/proxy-has-property.js: Added. (assert): (throw.new.Error.let.handler.get has): (throw.new.Error): (assert.let.handler.has): (let.handler.has): (getOwnPropertyDescriptor): (i.catch): 2016-02-18 Saam Barati Proxy's don't properly handle Symbols as PropertyKeys. https://bugs.webkit.org/show_bug.cgi?id=154385 Reviewed by Mark Lam and Yusuke Suzuki. We were converting all PropertyKeys to strings, even when the PropertyName was a Symbol. In the spec, PropertyKeys are either a Symbol or a String. We now respect that in Proxy.[[Get]] and Proxy.[[GetOwnProperty]]. * runtime/Completion.cpp: (JSC::profiledEvaluate): (JSC::createSymbolForEntryPointModule): (JSC::identifierToJSValue): Deleted. * runtime/Identifier.h: (JSC::parseIndex): * runtime/IdentifierInlines.h: (JSC::Identifier::fromString): (JSC::identifierToJSValue): (JSC::identifierToSafePublicJSValue): * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): * tests/es6.yaml: * tests/stress/proxy-basic.js: (let.handler.getOwnPropertyDescriptor): 2016-02-18 Saam Barati Follow up fix to Implement Proxy.[[GetOwnProperty]] https://bugs.webkit.org/show_bug.cgi?id=154314 Reviewed by Filip Pizlo. Part of the implementation was broken because of how JSObject::getOwnPropertyDescriptor worked. I've fixed JSObject::getOwnPropertyDescriptor to be able to handle ProxyObject. * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertyDescriptor): * runtime/ProxyObject.cpp: (JSC::ProxyObject::performInternalMethodGetOwnProperty): * tests/stress/proxy-get-own-property.js: (assert): (assert.let.handler.get getOwnPropertyDescriptor): 2016-02-18 Saam Barati Implement Proxy.[[GetOwnProperty]] https://bugs.webkit.org/show_bug.cgi?id=154314 Reviewed by Filip Pizlo. This patch implements Proxy.[[GetOwnProperty]]. It's a straight forward implementation as described in section 9.5.5 of the specification: http://www.ecma-international.org/ecma-262/6.0/index.html#sec-proxy-object-internal-methods-and-internal-slots-getownproperty-p * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncBind): * runtime/JSObject.cpp: (JSC::validateAndApplyPropertyDescriptor): (JSC::JSObject::defineOwnNonIndexProperty): (JSC::JSObject::defineOwnProperty): (JSC::JSObject::getGenericPropertyNames): (JSC::JSObject::getMethod): * runtime/JSObject.h: (JSC::JSObject::butterflyAddress): (JSC::makeIdentifier): * runtime/ProxyObject.cpp: (JSC::performProxyGet): (JSC::ProxyObject::performInternalMethodGetOwnProperty): (JSC::ProxyObject::getOwnPropertySlotCommon): (JSC::ProxyObject::getOwnPropertySlot): (JSC::ProxyObject::getOwnPropertySlotByIndex): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: * tests/es6.yaml: * tests/stress/proxy-basic.js: (let.handler.get null): * tests/stress/proxy-get-own-property.js: Added. (assert): (throw.new.Error.let.handler.getOwnPropertyDescriptor): (throw.new.Error): (let.handler.getOwnPropertyDescriptor): (i.catch): (assert.let.handler.getOwnPropertyDescriptor): 2016-02-18 Andreas Kling JSString resolution of substrings should use StringImpl sharing optimization. Reviewed by Antti Koivisto. When resolving a JSString that's actually a substring of another JSString, use the StringImpl sharing optimization to create a new string pointing into the parent one, instead of copying out the bytes of the string. This dramatically reduces peak memory usage on Gerrit diff viewer pages. Another approach to this would be to induce GC far more frequently due to the added cost of copying out these substrings. It would reduce the risk of prolonging the life of strings only kept alive by substrings. This patch chooses to trade that risk for less GC and lower peak memory. * runtime/JSString.cpp: (JSC::JSRopeString::resolveRope): 2016-02-18 Chris Dumez Crash on SES selftest page when loading the page while WebInspector is open https://bugs.webkit.org/show_bug.cgi?id=154378 Reviewed by Mark Lam. Do a partial revert of r196676 so that JSObject::getOwnPropertyDescriptor() returns early again if it detects that getOwnPropertySlot() returns a non-own property. This check was removed in r196676 because we assumed that only JSDOMWindow::getOwnPropertySlot() could return non-own properties. However, as it turns out, DebuggerScope::getOwnPropertySlot() does so as well. Not having the check would lead to crashes when using the debugger because we would get a slot with the CustomAccessor attribute but getDirect() would then fail to return the property (because it is not an own property). We would then cast the value returned by getDirect() to a CustomGetterSetter* and dereference it. * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertyDescriptor): 2016-02-18 Filip Pizlo Unreviewed, fix VS build. I didn't know we still did that, but apparently there's a bot for that. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: 2016-02-18 Filip Pizlo Unreviewed, fix CMake build. This got messed up when rebasing. * CMakeLists.txt: 2016-02-18 Csaba Osztrogonác Fix the !ENABLE(DFG_JIT) build after r195865 https://bugs.webkit.org/show_bug.cgi?id=154391 Reviewed by Filip Pizlo. * runtime/SamplingProfiler.cpp: (JSC::tryGetBytecodeIndex): 2016-02-17 Filip Pizlo Remove remaining references to LLVM, and make sure comments refer to the backend as "B3" not "LLVM" https://bugs.webkit.org/show_bug.cgi?id=154383 Reviewed by Saam Barati. I did a grep -i llvm of all of our code and did one of the following for each occurence: - Renamed it to B3. This is appropriate when we were using "LLVM" to mean "the FTL backend". - Removed the reference because I found it to be dead. In some cases it was a dead comment: it was telling us things about what LLVM did and that's just not relevant anymore. In other cases it was dead code that I forgot to delete in a previous patch. - Edited the comment in some smart way. There were comments talking about what LLVM did that were still of interest. In some cases, I added a FIXME to consider changing the code below the comment on the grounds that it was written in a weird way to placate LLVM and so we can do it better now. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGOSRAvailabilityAnalysisPhase.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThread): (JSC::DFG::Plan::compileInThreadImpl): (JSC::DFG::Plan::compileTimeStats): * dfg/DFGPutStackSinkingPhase.cpp: * dfg/DFGSSAConversionPhase.h: * dfg/DFGStaticExecutionCountEstimationPhase.h: * dfg/DFGUnificationPhase.cpp: (JSC::DFG::UnificationPhase::run): * disassembler/ARM64Disassembler.cpp: (JSC::tryToDisassemble): Deleted. * disassembler/X86Disassembler.cpp: (JSC::tryToDisassemble): * ftl/FTLAbstractHeap.cpp: (JSC::FTL::IndexedAbstractHeap::initialize): * ftl/FTLAbstractHeap.h: * ftl/FTLFormattedValue.h: * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::finalizeFunction): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLocation.cpp: (JSC::FTL::Location::restoreInto): * ftl/FTLLowerDFGToB3.cpp: Copied from Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.cpp. (JSC::FTL::DFG::ftlUnreachable): (JSC::FTL::DFG::LowerDFGToB3::LowerDFGToB3): (JSC::FTL::DFG::LowerDFGToB3::compileBlock): (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate): (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset): (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance): (JSC::FTL::DFG::LowerDFGToB3::isBoolean): (JSC::FTL::DFG::LowerDFGToB3::unboxBoolean): (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier): (JSC::FTL::lowerDFGToB3): (JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM): Deleted. (JSC::FTL::DFG::LowerDFGToLLVM::compileBlock): Deleted. (JSC::FTL::DFG::LowerDFGToLLVM::compileArithNegate): Deleted. (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiGetByOffset): Deleted. (JSC::FTL::DFG::LowerDFGToLLVM::compileOverridesHasInstance): Deleted. (JSC::FTL::DFG::LowerDFGToLLVM::isBoolean): Deleted. (JSC::FTL::DFG::LowerDFGToLLVM::unboxBoolean): Deleted. (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier): Deleted. (JSC::FTL::lowerDFGToLLVM): Deleted. * ftl/FTLLowerDFGToB3.h: Copied from Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.h. * ftl/FTLLowerDFGToLLVM.cpp: Removed. * ftl/FTLLowerDFGToLLVM.h: Removed. * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLWeight.h: (JSC::FTL::Weight::frequencyClass): (JSC::FTL::Weight::inverse): (JSC::FTL::Weight::scaleToTotal): Deleted. * ftl/FTLWeightedTarget.h: (JSC::FTL::rarely): (JSC::FTL::unsure): * jit/CallFrameShuffler64.cpp: (JSC::CallFrameShuffler::emitDisplace): * jit/RegisterSet.cpp: (JSC::RegisterSet::ftlCalleeSaveRegisters): * llvm: Removed. * llvm/InitializeLLVMLinux.cpp: Removed. * llvm/InitializeLLVMWin.cpp: Removed. * llvm/library: Removed. * llvm/library/LLVMTrapCallback.h: Removed. * llvm/library/libllvmForJSC.version: Removed. * runtime/Options.cpp: (JSC::recomputeDependentOptions): (JSC::Options::initialize): * runtime/Options.h: * wasm/WASMFunctionB3IRGenerator.h: Copied from Source/JavaScriptCore/wasm/WASMFunctionLLVMIRGenerator.h. * wasm/WASMFunctionLLVMIRGenerator.h: Removed. * wasm/WASMFunctionParser.cpp: 2016-02-18 Csaba Osztrogonác [cmake] Build system cleanup https://bugs.webkit.org/show_bug.cgi?id=154337 Reviewed by Žan Doberšek. * CMakeLists.txt: 2016-02-17 Mark Lam Callers of JSString::value() should check for exceptions thereafter. https://bugs.webkit.org/show_bug.cgi?id=154346 Reviewed by Geoffrey Garen. JSString::value() can throw an exception if the JS string is a rope and value() needs to resolve the rope but encounters an OutOfMemory error. If value() is not able to resolve the rope, it will return a null string (in addition to throwing the exception). If a caller does not check for exceptions after calling JSString::value(), they may eventually use the returned null string and crash the VM. The fix is to add all the necessary exception checks, and do the appropriate handling if needed. * jsc.cpp: (functionRun): (functionLoad): (functionReadFile): (functionCheckSyntax): (functionLoadWebAssembly): (functionLoadModule): (functionCheckModuleSyntax): * runtime/DateConstructor.cpp: (JSC::dateParse): (JSC::dateNow): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncEval): * tools/JSDollarVMPrototype.cpp: (JSC::functionPrint): 2016-02-17 Benjamin Poulain [JSC] ARM64: Support the immediate format used for bit operations in Air https://bugs.webkit.org/show_bug.cgi?id=154327 Reviewed by Filip Pizlo. ARM64 supports a pretty rich form of immediates for bit operation. There are two formats used to encode repeating patterns and common input in a dense form. In this patch, I add 2 new type of Arg: BitImm32 and BitImm64. Those represents the valid immediate forms for bit operation. On x86, any 32bits value is valid. On ARM64, all the encoding form are tried and the immediate is used when possible. The arg type Imm64 is renamed to BigImm to better represent what it is: an immediate that does not fit into Imm. * assembler/ARM64Assembler.h: (JSC::LogicalImmediate::create32): Deleted. (JSC::LogicalImmediate::create64): Deleted. (JSC::LogicalImmediate::value): Deleted. (JSC::LogicalImmediate::isValid): Deleted. (JSC::LogicalImmediate::is64bit): Deleted. (JSC::LogicalImmediate::LogicalImmediate): Deleted. (JSC::LogicalImmediate::mask): Deleted. (JSC::LogicalImmediate::partialHSB): Deleted. (JSC::LogicalImmediate::highestSetBit): Deleted. (JSC::LogicalImmediate::findBitRange): Deleted. (JSC::LogicalImmediate::encodeLogicalImmediate): Deleted. * assembler/AssemblerCommon.h: (JSC::ARM64LogicalImmediate::create32): (JSC::ARM64LogicalImmediate::create64): (JSC::ARM64LogicalImmediate::value): (JSC::ARM64LogicalImmediate::isValid): (JSC::ARM64LogicalImmediate::is64bit): (JSC::ARM64LogicalImmediate::ARM64LogicalImmediate): (JSC::ARM64LogicalImmediate::mask): (JSC::ARM64LogicalImmediate::partialHSB): (JSC::ARM64LogicalImmediate::highestSetBit): (JSC::ARM64LogicalImmediate::findBitRange): (JSC::ARM64LogicalImmediate::encodeLogicalImmediate): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::and64): (JSC::MacroAssemblerARM64::or64): (JSC::MacroAssemblerARM64::xor64): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::bitImm): (JSC::B3::Air::LowerToAir::bitImm64): (JSC::B3::Air::LowerToAir::appendBinOp): * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::dump): (WTF::printInternal): * b3/air/AirArg.h: (JSC::B3::Air::Arg::bitImm): (JSC::B3::Air::Arg::bitImm64): (JSC::B3::Air::Arg::isBitImm): (JSC::B3::Air::Arg::isBitImm64): (JSC::B3::Air::Arg::isSomeImm): (JSC::B3::Air::Arg::value): (JSC::B3::Air::Arg::isGP): (JSC::B3::Air::Arg::isFP): (JSC::B3::Air::Arg::hasType): (JSC::B3::Air::Arg::isValidBitImmForm): (JSC::B3::Air::Arg::isValidBitImm64Form): (JSC::B3::Air::Arg::isValidForm): (JSC::B3::Air::Arg::asTrustedImm32): (JSC::B3::Air::Arg::asTrustedImm64): * b3/air/AirOpcode.opcodes: * b3/air/opcode_generator.rb: 2016-02-17 Keith Miller Spread operator should be allowed when not the first argument of parameter list https://bugs.webkit.org/show_bug.cgi?id=152721 Reviewed by Saam Barati. Spread arguments to functions should now be ES6 compliant. Before we would only take a spread operator if it was the sole argument to a function. Additionally, we would not use the Symbol.iterator on the object to generate the arguments. Instead we would do a loop up to the length mapping indexed properties to the corresponding argument. We fix both these issues by doing an AST transformation from foo(...a, b, ...c, d) to foo(...[...a, b, ...c, d]) (where the spread on the rhs uses the old spread semantics). This solution has the downside of requiring the allocation of another object and copying each element twice but avoids a large change to the vm calling convention. * interpreter/Interpreter.cpp: (JSC::loadVarargs): * parser/ASTBuilder.h: (JSC::ASTBuilder::createElementList): * parser/Parser.cpp: (JSC::Parser::parseArguments): (JSC::Parser::parseArgument): (JSC::Parser::parseMemberExpression): * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createElementList): * tests/es6.yaml: * tests/stress/spread-calling.js: Added. (testFunction): (testEmpty): (makeObject): (otherIterator.return.next): (otherIterator): (totalIter): (throwingIter.return.next): (throwingIter): (i.catch): 2016-02-17 Brian Burg Remove a wrong cast in RemoteInspector::receivedSetupMessage https://bugs.webkit.org/show_bug.cgi?id=154361 Reviewed by Joseph Pecoraro. * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::receivedSetupMessage): Not only is this cast unnecessary (the constructor accepts the base class), but it is wrong since the target could be an automation target. Remove it. 2016-02-17 Filip Pizlo Rename FTLB3Blah to FTLBlah https://bugs.webkit.org/show_bug.cgi?id=154365 Rubber stamped by Geoffrey Garen, Benjamin Poulain, Awesome Kling, and Saam Barati. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * ftl/FTLB3Compile.cpp: Removed. * ftl/FTLB3Output.cpp: Removed. * ftl/FTLB3Output.h: Removed. * ftl/FTLCompile.cpp: Copied from Source/JavaScriptCore/ftl/FTLB3Compile.cpp. * ftl/FTLOutput.cpp: Copied from Source/JavaScriptCore/ftl/FTLB3Output.cpp. * ftl/FTLOutput.h: Copied from Source/JavaScriptCore/ftl/FTLB3Output.h. 2016-02-17 Filip Pizlo Remove LLVM dependencies from WebKit https://bugs.webkit.org/show_bug.cgi?id=154323 Reviewed by Antti Koivisto and Benjamin Poulain. We have switched all ports that use the FTL JIT to using B3 as the backend. This renders all LLVM-related code dead, including the disassembler, which was only reachable when you were on a platform that already had an in-tree disassembler. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGCommon.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThread): (JSC::DFG::Plan::compileInThreadImpl): (JSC::DFG::Plan::compileTimeStats): * disassembler/ARM64Disassembler.cpp: (JSC::tryToDisassemble): * disassembler/ARMv7Disassembler.cpp: (JSC::tryToDisassemble): * disassembler/Disassembler.cpp: (JSC::disassemble): (JSC::disassembleAsynchronously): * disassembler/Disassembler.h: (JSC::tryToDisassemble): * disassembler/LLVMDisassembler.cpp: Removed. * disassembler/LLVMDisassembler.h: Removed. * disassembler/UDis86Disassembler.cpp: (JSC::tryToDisassembleWithUDis86): * disassembler/UDis86Disassembler.h: (JSC::tryToDisassembleWithUDis86): * disassembler/X86Disassembler.cpp: (JSC::tryToDisassemble): * ftl/FTLAbbreviatedTypes.h: * ftl/FTLAbbreviations.h: Removed. * ftl/FTLAbstractHeap.cpp: (JSC::FTL::AbstractHeap::decorateInstruction): (JSC::FTL::AbstractHeap::dump): (JSC::FTL::AbstractField::dump): (JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap): (JSC::FTL::IndexedAbstractHeap::~IndexedAbstractHeap): (JSC::FTL::IndexedAbstractHeap::baseIndex): (JSC::FTL::IndexedAbstractHeap::dump): (JSC::FTL::NumberedAbstractHeap::NumberedAbstractHeap): (JSC::FTL::NumberedAbstractHeap::dump): (JSC::FTL::AbsoluteAbstractHeap::AbsoluteAbstractHeap): (JSC::FTL::AbstractHeap::tbaaMetadataSlow): Deleted. * ftl/FTLAbstractHeap.h: (JSC::FTL::AbstractHeap::AbstractHeap): (JSC::FTL::AbstractHeap::heapName): (JSC::FTL::IndexedAbstractHeap::atAnyIndex): (JSC::FTL::NumberedAbstractHeap::atAnyNumber): (JSC::FTL::AbsoluteAbstractHeap::atAnyAddress): (JSC::FTL::AbstractHeap::tbaaMetadata): Deleted. * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLB3Compile.cpp: * ftl/FTLB3Output.cpp: (JSC::FTL::Output::Output): (JSC::FTL::Output::check): (JSC::FTL::Output::load): (JSC::FTL::Output::store): * ftl/FTLB3Output.h: * ftl/FTLCommonValues.cpp: (JSC::FTL::CommonValues::CommonValues): (JSC::FTL::CommonValues::initializeConstants): * ftl/FTLCommonValues.h: (JSC::FTL::CommonValues::initialize): Deleted. * ftl/FTLCompile.cpp: Removed. * ftl/FTLCompileBinaryOp.cpp: Removed. * ftl/FTLCompileBinaryOp.h: Removed. * ftl/FTLDWARFDebugLineInfo.cpp: Removed. * ftl/FTLDWARFDebugLineInfo.h: Removed. * ftl/FTLDWARFRegister.cpp: Removed. * ftl/FTLDWARFRegister.h: Removed. * ftl/FTLDataSection.cpp: Removed. * ftl/FTLDataSection.h: Removed. * ftl/FTLExceptionHandlerManager.cpp: Removed. * ftl/FTLExceptionHandlerManager.h: Removed. * ftl/FTLExceptionTarget.cpp: * ftl/FTLExceptionTarget.h: * ftl/FTLExitThunkGenerator.cpp: Removed. * ftl/FTLExitThunkGenerator.h: Removed. * ftl/FTLFail.cpp: (JSC::FTL::fail): * ftl/FTLInlineCacheDescriptor.h: Removed. * ftl/FTLInlineCacheSize.cpp: Removed. * ftl/FTLInlineCacheSize.h: Removed. * ftl/FTLIntrinsicRepository.cpp: Removed. * ftl/FTLIntrinsicRepository.h: Removed. * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::~JITCode): (JSC::FTL::JITCode::initializeB3Code): (JSC::FTL::JITCode::initializeB3Byproducts): (JSC::FTL::JITCode::initializeAddressForCall): (JSC::FTL::JITCode::contains): (JSC::FTL::JITCode::ftl): (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite): (JSC::FTL::JITCode::initializeExitThunks): Deleted. (JSC::FTL::JITCode::addHandle): Deleted. (JSC::FTL::JITCode::addDataSection): Deleted. (JSC::FTL::JITCode::exitThunks): Deleted. * ftl/FTLJITCode.h: (JSC::FTL::JITCode::b3Code): (JSC::FTL::JITCode::handles): Deleted. (JSC::FTL::JITCode::dataSections): Deleted. * ftl/FTLJITFinalizer.cpp: (JSC::FTL::JITFinalizer::codeSize): (JSC::FTL::JITFinalizer::finalizeFunction): * ftl/FTLJITFinalizer.h: * ftl/FTLJSCall.cpp: Removed. * ftl/FTLJSCall.h: Removed. * ftl/FTLJSCallBase.cpp: Removed. * ftl/FTLJSCallBase.h: Removed. * ftl/FTLJSCallVarargs.cpp: Removed. * ftl/FTLJSCallVarargs.h: Removed. * ftl/FTLJSTailCall.cpp: Removed. * ftl/FTLJSTailCall.h: Removed. * ftl/FTLLazySlowPath.cpp: (JSC::FTL::LazySlowPath::LazySlowPath): (JSC::FTL::LazySlowPath::generate): * ftl/FTLLazySlowPath.h: (JSC::FTL::LazySlowPath::createGenerator): (JSC::FTL::LazySlowPath::patchableJump): (JSC::FTL::LazySlowPath::done): (JSC::FTL::LazySlowPath::usedRegisters): (JSC::FTL::LazySlowPath::callSiteIndex): (JSC::FTL::LazySlowPath::stub): (JSC::FTL::LazySlowPath::patchpoint): Deleted. * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLocation.cpp: (JSC::FTL::Location::forValueRep): (JSC::FTL::Location::dump): (JSC::FTL::Location::forStackmaps): Deleted. * ftl/FTLLocation.h: (JSC::FTL::Location::forRegister): (JSC::FTL::Location::forIndirect): (JSC::FTL::Location::forConstant): (JSC::FTL::Location::kind): (JSC::FTL::Location::hasReg): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::LowerDFGToLLVM): (JSC::FTL::DFG::LowerDFGToLLVM::lower): (JSC::FTL::DFG::LowerDFGToLLVM::createPhiVariables): (JSC::FTL::DFG::LowerDFGToLLVM::compileNode): (JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon): (JSC::FTL::DFG::LowerDFGToLLVM::compilePhi): (JSC::FTL::DFG::LowerDFGToLLVM::compileDoubleConstant): (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd): (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat): (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub): (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul): (JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv): (JSC::FTL::DFG::LowerDFGToLLVM::compileArithNegate): (JSC::FTL::DFG::LowerDFGToLLVM::compileBitAnd): (JSC::FTL::DFG::LowerDFGToLLVM::compileBitOr): (JSC::FTL::DFG::LowerDFGToLLVM::compileBitXor): (JSC::FTL::DFG::LowerDFGToLLVM::compileBitRShift): (JSC::FTL::DFG::LowerDFGToLLVM::compileBitLShift): (JSC::FTL::DFG::LowerDFGToLLVM::compileBitURShift): (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById): (JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterfly): (JSC::FTL::DFG::LowerDFGToLLVM::compileMakeRope): (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall): (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToLLVM::compileLoadVarargs): (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint): (JSC::FTL::DFG::LowerDFGToLLVM::compileIsUndefined): (JSC::FTL::DFG::LowerDFGToLLVM::compileIn): (JSC::FTL::DFG::LowerDFGToLLVM::getById): (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyWithBarrier): (JSC::FTL::DFG::LowerDFGToLLVM::stringsEqual): (JSC::FTL::DFG::LowerDFGToLLVM::emitRightShiftSnippet): (JSC::FTL::DFG::LowerDFGToLLVM::allocateCell): (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath): (JSC::FTL::DFG::LowerDFGToLLVM::speculate): (JSC::FTL::DFG::LowerDFGToLLVM::callCheck): (JSC::FTL::DFG::LowerDFGToLLVM::preparePatchpointForExceptions): (JSC::FTL::DFG::LowerDFGToLLVM::lowBlock): (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitDescriptor): (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation): (JSC::FTL::DFG::LowerDFGToLLVM::buildExitArguments): (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForAvailability): (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForNode): (JSC::FTL::DFG::LowerDFGToLLVM::probe): (JSC::FTL::DFG::LowerDFGToLLVM::crash): (JSC::FTL::DFG::LowerDFGToLLVM::compileUntypedBinaryOp): Deleted. (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException): Deleted. (JSC::FTL::DFG::LowerDFGToLLVM::emitOSRExitCall): Deleted. (JSC::FTL::DFG::LowerDFGToLLVM::callStackmap): Deleted. * ftl/FTLOSRExit.cpp: (JSC::FTL::OSRExitDescriptor::OSRExitDescriptor): (JSC::FTL::OSRExitDescriptor::validateReferences): (JSC::FTL::OSRExitDescriptor::emitOSRExit): (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle): (JSC::FTL::OSRExit::OSRExit): (JSC::FTL::OSRExit::codeLocationForRepatch): (JSC::FTL::OSRExit::gatherRegistersToSpillForCallIfException): Deleted. (JSC::FTL::OSRExit::spillRegistersToSpillSlot): Deleted. (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot): Deleted. (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck): Deleted. (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation): Deleted. (JSC::FTL::OSRExit::needsRegisterRecoveryOnGenericUnwindOSRExitPath): Deleted. * ftl/FTLOSRExit.h: (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite): (JSC::FTL::OSRExitDescriptorImpl::OSRExitDescriptorImpl): Deleted. * ftl/FTLOSRExitCompilationInfo.h: Removed. * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileRecovery): (JSC::FTL::compileStub): (JSC::FTL::compileFTLOSRExit): * ftl/FTLOSRExitHandle.cpp: * ftl/FTLOSRExitHandle.h: * ftl/FTLOutput.cpp: Removed. * ftl/FTLOutput.h: Removed. * ftl/FTLPatchpointExceptionHandle.cpp: * ftl/FTLPatchpointExceptionHandle.h: * ftl/FTLStackMaps.cpp: Removed. * ftl/FTLStackMaps.h: Removed. * ftl/FTLState.cpp: (JSC::FTL::State::State): (JSC::FTL::State::~State): (JSC::FTL::State::dumpState): Deleted. * ftl/FTLState.h: * ftl/FTLUnwindInfo.cpp: Removed. * ftl/FTLUnwindInfo.h: Removed. * ftl/FTLValueRange.cpp: (JSC::FTL::ValueRange::decorateInstruction): * ftl/FTLValueRange.h: (JSC::FTL::ValueRange::ValueRange): (JSC::FTL::ValueRange::begin): (JSC::FTL::ValueRange::end): * ftl/FTLWeight.h: (JSC::FTL::Weight::value): (JSC::FTL::Weight::frequencyClass): (JSC::FTL::Weight::scaleToTotal): * llvm/InitializeLLVM.cpp: Removed. * llvm/InitializeLLVM.h: Removed. * llvm/InitializeLLVMMac.cpp: Removed. * llvm/InitializeLLVMPOSIX.cpp: Removed. * llvm/InitializeLLVMPOSIX.h: Removed. * llvm/LLVMAPI.cpp: Removed. * llvm/LLVMAPI.h: Removed. * llvm/LLVMAPIFunctions.h: Removed. * llvm/LLVMHeaders.h: Removed. * llvm/library/LLVMAnchor.cpp: Removed. * llvm/library/LLVMExports.cpp: Removed. * llvm/library/LLVMOverrides.cpp: Removed. * llvm/library/config_llvm.h: Removed. 2016-02-17 Benjamin Poulain [JSC] Remove the overflow check on ArithAbs when possible https://bugs.webkit.org/show_bug.cgi?id=154325 Reviewed by Filip Pizlo. This patch adds support for ArithMode for ArithAbs. It is useful for kraken tests where Math.abs() is used on values for which the range is known. For example, imaging-gaussian-blur has two Math.abs() with integers that are always in a small range around zero. The IntegerRangeOptimizationPhase detects the range correctly so we can just update the ArithMode depending on the input. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::convertToArithNegate): (JSC::DFG::Node::hasArithMode): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAbs): * tests/stress/arith-abs-integer-range-optimization.js: Added. (negativeRange): (negativeRangeIncludingZero): (negativeRangeWithOverflow): (positiveRange): (positiveRangeIncludingZero): (rangeWithoutOverflow): * tests/stress/arith-abs-with-bitwise-or-zero.js: Added. (opaqueAbs): 2016-02-17 Chris Dumez SES selftest page crashes on nightly r196694 https://bugs.webkit.org/show_bug.cgi?id=154350 Reviewed by Mark Lam. SES selftest page crashes after r196001 / r196145 when calling Object.getOwnPropertyDescriptor(window, "length") after the window has been reified and "length" has been shadowed by a value property. It was crashing in JSObject::getOwnPropertyDescriptor() because we are getting a slot that has attribute "CustomAccessor" but the property is not a CustomGetterSetter. In this case, since window.length is [Replaceable] and has been set to a numeric value, it makes that the property is not a CustomGetterSetter. However, the "CustomAccessor" attribute should have been dropped from the slot when window.length was shadowed. Therefore, this code path should not be exercised at all when calling getOwnPropertyDescriptor(). The issue was that putDirectInternal() was updating the slot attributes only if the "Accessor" flag has changed, but not the "customAccessor" flag. This patch fixes the issue. * runtime/JSObject.h: (JSC::JSObject::putDirectInternal): 2016-02-17 Saam barati Implement Proxy [[Get]] https://bugs.webkit.org/show_bug.cgi?id=154081 Reviewed by Michael Saboff. This patch implements ProxyObject and ProxyConstructor. Their implementations are straight forward and follow the spec. The largest change in this patch is adding a second parameter to PropertySlot's constructor that specifies the internal method type of the getOwnPropertySlot inquiry. We use getOwnPropertySlot to implement more than one Internal Method in the spec. Because of this, we need InternalMethodType to give us context about which Internal Method we're executing. Specifically, Proxy will call into different handlers based on this information. InternalMethodType is an enum with the following values: - Get This corresponds to [[Get]] internal method in the spec. - GetOwnProperty This corresponds to [[GetOwnProperty]] internal method in the spec. - HasProperty This corresponds to [[HasProperty]] internal method in the spec. - VMInquiry This is basically everything else that isn't one of the above types. This value also mandates that getOwnPropertySlot does not perform any user observable effects. I.e, it can't call a JS function. The other non-VMInquiry InternalMethodTypes are allowed to perform user observable effects. I.e, in future patches, ProxyObject will implement InternalMethodType::HasProperty and InternalMethodType::GetOwnProperty, which will both be defined to call user defined JS functions, which clearly have the right to perform user observable effects. This patch implements getOwnPropertySlot of ProxyObject under InternalMethodType::Get. * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::put): (JSC::JSCallbackObject::staticFunctionGetter): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * debugger/DebuggerScope.cpp: (JSC::DebuggerScope::caughtValue): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/ArrayPrototype.cpp: (JSC::getProperty): * runtime/CommonIdentifiers.h: * runtime/JSCJSValueInlines.h: (JSC::JSValue::get): * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnNonIndexPropertyNames): (JSC::JSFunction::put): (JSC::JSFunction::defineOwnProperty): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewWithArguments): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::defineOwnProperty): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::regExpMatchesArrayStructure): (JSC::JSGlobalObject::moduleRecordStructure): (JSC::JSGlobalObject::moduleNamespaceObjectStructure): (JSC::JSGlobalObject::proxyObjectStructure): (JSC::JSGlobalObject::wasmModuleStructure): * runtime/JSModuleEnvironment.cpp: (JSC::JSModuleEnvironment::getOwnPropertySlot): * runtime/JSModuleNamespaceObject.cpp: (JSC::callbackGetter): * runtime/JSONObject.cpp: (JSC::Stringifier::Holder::appendNextProperty): (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::hasProperty): (JSC::JSObject::deleteProperty): (JSC::JSObject::hasOwnProperty): (JSC::JSObject::getOwnPropertyDescriptor): * runtime/JSObject.h: (JSC::JSObject::getDirectIndex): (JSC::JSObject::get): * runtime/JSScope.cpp: (JSC::abstractAccess): * runtime/ObjectConstructor.cpp: (JSC::toPropertyDescriptor): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncLookupGetter): (JSC::objectProtoFuncLookupSetter): (JSC::objectProtoFuncToString): * runtime/PropertySlot.h: (JSC::attributesForStructure): (JSC::PropertySlot::PropertySlot): (JSC::PropertySlot::isCacheableGetter): (JSC::PropertySlot::isCacheableCustom): (JSC::PropertySlot::internalMethodType): (JSC::PropertySlot::disableCaching): (JSC::PropertySlot::getValue): * runtime/ProxyConstructor.cpp: Added. (JSC::ProxyConstructor::create): (JSC::ProxyConstructor::ProxyConstructor): (JSC::ProxyConstructor::finishCreation): (JSC::constructProxyObject): (JSC::ProxyConstructor::getConstructData): (JSC::ProxyConstructor::getCallData): * runtime/ProxyConstructor.h: Added. (JSC::ProxyConstructor::createStructure): * runtime/ProxyObject.cpp: Added. (JSC::ProxyObject::ProxyObject): (JSC::ProxyObject::finishCreation): (JSC::performProxyGet): (JSC::ProxyObject::getOwnPropertySlotCommon): (JSC::ProxyObject::getOwnPropertySlot): (JSC::ProxyObject::getOwnPropertySlotByIndex): (JSC::ProxyObject::visitChildren): * runtime/ProxyObject.h: Added. (JSC::ProxyObject::create): (JSC::ProxyObject::createStructure): (JSC::ProxyObject::target): (JSC::ProxyObject::handler): * runtime/ReflectObject.cpp: (JSC::reflectObjectGet): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::StackFrame::nameFromCallee): * tests/es6.yaml: * tests/stress/proxy-basic.js: Added. (assert): (let.handler.get null): (get let): (let.handler.get switch): (let.handler): (let.theTarget.get x): * tests/stress/proxy-in-proto-chain.js: Added. (assert): * tests/stress/proxy-of-a-proxy.js: Added. (assert): (throw.new.Error.): * tests/stress/proxy-property-descriptor.js: Added. (assert): (set Object): * wasm/WASMModuleParser.cpp: (JSC::WASMModuleParser::getImportedValue): 2016-02-17 Mark Lam StringPrototype functions should check for exceptions after calling JSString::value(). https://bugs.webkit.org/show_bug.cgi?id=154340 Reviewed by Filip Pizlo. JSString::value() can throw an exception if the JS string is a rope and value() needs to resolve the rope but encounters an OutOfMemory error. If value() is not able to resolve the rope, it will return a null string (in addition to throwing the exception). If StringPrototype functions do not check for exceptions after calling JSString::value(), they may eventually use the returned null string and crash the VM. The fix is to add all the necessary exception checks, and do the appropriate handling if needed. Also in a few place where when an exception is detected, we return JSValue(), I changed it to return jsUndefined() instead to be consistent with the rest of the file. * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): (JSC::stringProtoFuncMatch): (JSC::stringProtoFuncSlice): (JSC::stringProtoFuncSplit): (JSC::stringProtoFuncLocaleCompare): (JSC::stringProtoFuncBig): (JSC::stringProtoFuncSmall): (JSC::stringProtoFuncBlink): (JSC::stringProtoFuncBold): (JSC::stringProtoFuncFixed): (JSC::stringProtoFuncItalics): (JSC::stringProtoFuncStrike): (JSC::stringProtoFuncSub): (JSC::stringProtoFuncSup): (JSC::stringProtoFuncFontcolor): (JSC::stringProtoFuncFontsize): (JSC::stringProtoFuncAnchor): (JSC::stringProtoFuncLink): (JSC::trimString): 2016-02-17 Commit Queue Unreviewed, rolling out r196675. https://bugs.webkit.org/show_bug.cgi?id=154344 "Causes major slowdowns on deltablue-varargs" (Requested by keith_miller on #webkit). Reverted changeset: "Spread operator should be allowed when not the first argument of parameter list" https://bugs.webkit.org/show_bug.cgi?id=152721 http://trac.webkit.org/changeset/196675 2016-02-17 Gavin Barraclough JSDOMWindow::put should not do the same thing twice https://bugs.webkit.org/show_bug.cgi?id=154334 Reviewed by Chris Dumez. It either calls JSGlobalObject::put or Base::put. Hint: these are basically the same thing. In the latter case it might call lookupPut. That's redundant; JSObject::put handles static table entries. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::hasOwnPropertyForWrite): Deleted. - no longer needed. 2016-02-16 Filip Pizlo FTL_USES_B3 should be unconditionally true https://bugs.webkit.org/show_bug.cgi?id=154324 Reviewed by Benjamin Poulain. * dfg/DFGCommon.h: 2016-02-16 Filip Pizlo FTL should support CompareEq(String:, String:) https://bugs.webkit.org/show_bug.cgi?id=154269 rdar://problem/24499921 Reviewed by Benjamin Poulain. Looks like a slight pdfjs slow-down, probably because we're having some recompilations. I think we should land the increased coverage first and fix the issues after, especially since the regression is so small and doesn't have a statistically significant effect on the overall score. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq): (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareStrictEq): (JSC::FTL::DFG::LowerDFGToLLVM::nonSpeculativeCompare): (JSC::FTL::DFG::LowerDFGToLLVM::stringsEqual): * tests/stress/ftl-string-equality.js: Added. * tests/stress/ftl-string-ident-equality.js: Added. * tests/stress/ftl-string-strict-equality.js: Added. 2016-02-16 Filip Pizlo FTL should support NewTypedArray https://bugs.webkit.org/show_bug.cgi?id=154268 Reviewed by Saam Barati. 3% speed-up on pdfjs. This was already covered by many different tests. Rolling this back in after fixing the butterfly argument. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileNode): (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize): (JSC::FTL::DFG::LowerDFGToLLVM::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToLLVM::compileAllocatePropertyStorage): (JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorageAndGetEnd): (JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorage): (JSC::FTL::DFG::LowerDFGToLLVM::allocateObject): 2016-02-16 Gavin Barraclough JSDOMWindow::getOwnPropertySlot should just call getStaticPropertySlot https://bugs.webkit.org/show_bug.cgi?id=154257 Reviewed by Chris Dumez. * runtime/Lookup.h: (JSC::getStaticPropertySlot): (JSC::getStaticFunctionSlot): (JSC::getStaticValueSlot): - this could all do with a little more love. But enforce the basic precedence: (1) regular storage properties always win over static table properties. (2) if properties have been reified, don't consult the static tables. (3) only if the property is not present on the object & not reified should the static hashtable be consulted. 2016-02-16 Gavin Barraclough JSDOMWindow::getOwnPropertySlot should not search photo chain https://bugs.webkit.org/show_bug.cgi?id=154102 Reviewed by Chris Dumez. Should only return *own* properties. * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertyDescriptor): - remove hack/special-case for DOMWindow; we no longer need this. 2016-02-16 Keith Miller Spread operator should be allowed when not the first argument of parameter list https://bugs.webkit.org/show_bug.cgi?id=152721 Reviewed by Saam Barati. Spread arguments to functions should now be ES6 compliant. Before we would only take a spread operator if it was the sole argument to a function. Additionally, we would not use the Symbol.iterator on the object to generate the arguments. Instead we would do a loop up to the length mapping indexed properties to the corresponding argument. We fix both these issues by doing an AST transformation from foo(...a, b, ...c, d) to foo(...[...a, b, ...c, d]) (where the spread on the rhs uses the old spread semantics). This solution has the downside of requiring the allocation of another object and copying each element twice but avoids a large change to the vm calling convention. * interpreter/Interpreter.cpp: (JSC::loadVarargs): * parser/ASTBuilder.h: (JSC::ASTBuilder::createElementList): * parser/Parser.cpp: (JSC::Parser::parseArguments): (JSC::Parser::parseArgument): (JSC::Parser::parseMemberExpression): * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createElementList): * tests/es6.yaml: * tests/stress/spread-calling.js: Added. (testFunction): (testEmpty): (makeObject): (otherIterator.return.next): (otherIterator): (totalIter): (throwingIter.return.next): (throwingIter): (i.catch): 2016-02-16 Benjamin Poulain [JSC] Enable B3 on ARM64 https://bugs.webkit.org/show_bug.cgi?id=154275 Reviewed by Mark Lam. The port passes more tests than LLVM now, let's use it by default. * dfg/DFGCommon.h: 2016-02-16 Commit Queue Unreviewed, rolling out r196652. https://bugs.webkit.org/show_bug.cgi?id=154315 This change caused LayoutTest crashes (Requested by ryanhaddad on #webkit). Reverted changeset: "FTL should support NewTypedArray" https://bugs.webkit.org/show_bug.cgi?id=154268 http://trac.webkit.org/changeset/196652 2016-02-16 Brian Burg RemoteInspector should forward new automation session requests to its client https://bugs.webkit.org/show_bug.cgi?id=154260 Reviewed by Timothy Hatcher. * inspector/remote/RemoteInspector.h: * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::xpcConnectionReceivedMessage): (Inspector::RemoteInspector::listingForAutomationTarget): Use the correct key for the session identifier in the listing. The name() override for RemoteAutomationTarget is actually the session identifier. (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage): * inspector/remote/RemoteInspectorConstants.h: Add new constants. 2016-02-16 Saam barati SamplingProfiler still fails with ASan enabled https://bugs.webkit.org/show_bug.cgi?id=154301 Reviewed by Filip Pizlo. To fix this issue, I've come up with unsafe versions of all operations that load memory from the thread's call frame. All these new unsafe methods are marked with SUPPRESS_ASAN. * interpreter/CallFrame.cpp: (JSC::CallFrame::callSiteAsRawBits): (JSC::CallFrame::unsafeCallSiteAsRawBits): (JSC::CallFrame::callSiteIndex): (JSC::CallFrame::unsafeCallSiteIndex): (JSC::CallFrame::stack): (JSC::CallFrame::callerFrame): (JSC::CallFrame::unsafeCallerFrame): (JSC::CallFrame::friendlyFunctionName): * interpreter/CallFrame.h: (JSC::ExecState::calleeAsValue): (JSC::ExecState::callee): (JSC::ExecState::unsafeCallee): (JSC::ExecState::codeBlock): (JSC::ExecState::unsafeCodeBlock): (JSC::ExecState::scope): (JSC::ExecState::callerFrame): (JSC::ExecState::callerFrameOrVMEntryFrame): (JSC::ExecState::unsafeCallerFrameOrVMEntryFrame): (JSC::ExecState::callerFrameOffset): (JSC::ExecState::callerFrameAndPC): (JSC::ExecState::unsafeCallerFrameAndPC): * interpreter/Register.h: (JSC::Register::codeBlock): (JSC::Register::asanUnsafeCodeBlock): (JSC::Register::unboxedInt32): (JSC::Register::tag): (JSC::Register::unsafeTag): (JSC::Register::payload): * interpreter/VMEntryRecord.h: (JSC::VMEntryRecord::prevTopCallFrame): (JSC::VMEntryRecord::unsafePrevTopCallFrame): (JSC::VMEntryRecord::prevTopVMEntryFrame): (JSC::VMEntryRecord::unsafePrevTopVMEntryFrame): * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::walk): (JSC::FrameWalker::advanceToParentFrame): (JSC::FrameWalker::isAtTop): (JSC::FrameWalker::resetAtMachineFrame): 2016-02-16 Filip Pizlo FTL should support NewTypedArray https://bugs.webkit.org/show_bug.cgi?id=154268 Reviewed by Saam Barati. 3% speed-up on pdfjs. This was already covered by many different tests. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileNode): (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize): (JSC::FTL::DFG::LowerDFGToLLVM::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToLLVM::compileAllocatePropertyStorage): (JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorageAndGetEnd): (JSC::FTL::DFG::LowerDFGToLLVM::allocateBasicStorage): (JSC::FTL::DFG::LowerDFGToLLVM::allocateObject): 2016-02-16 Saam barati stress/sampling-profiler-deep-stack.js fails on ARM 32bit https://bugs.webkit.org/show_bug.cgi?id=154255 Reviewed by Mark Lam. The bug here wasn't in the implementation of the sampling profiler itself. Rather, it was a bug in the test. JSC wasn't spending a lot of time in a function that the test assumed a lot of time was spent in. That's because the DFG was doing a good job at optimizing the function at the leaf of the recursion. Because of that, we often wouldn't sample it. I fixed this by making the leaf function do more work. * tests/stress/sampling-profiler-deep-stack.js: (platformSupportsSamplingProfiler.foo): 2016-02-16 Chris Dumez [Web IDL] Operations should be on the instance for global objects or if [Unforgeable] https://bugs.webkit.org/show_bug.cgi?id=154120 Reviewed by Gavin Barraclough. Have putEntry() take a thisValue parameter in addition to the base, instead of relying on PropertySlot::thisValue() because this did not always do the right thing. In particular, when JSDOMWindow::put() was called to set a function, it would end up setting the new value on the JSDOMWindowShell instead of the actual JSDOMWindow. JSDOMWindow::getOwnPropertySlot() would then not be able to find it. Therefore the following would fail: $ window.open = "test" $ console.log(window.open) // prints the native function instead of "test" * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): 2016-02-16 Keith Miller ClonedArguments should not materialize its special properties unless they are being changed or deleted https://bugs.webkit.org/show_bug.cgi?id=154128 Reviewed by Filip Pizlo. Before we would materialize ClonedArguments whenever they were being accessed. However this would cause the IC to miss every time as the structure for the arguments object would change as we went to IC it. Thus on the next function call we would miss the cache since the new arguments object would not have materialized the value. * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::getOwnPropertySlot): * tests/stress/cloned-arguments-modification.js: Added. (foo): 2016-02-16 Filip Pizlo FTL should support StringFromCharCode https://bugs.webkit.org/show_bug.cgi?id=154267 rdar://problem/24192536 Reviewed by Mark Lam. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): Fix a bug preventing the UntypedUse from being effective. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileNode): (JSC::FTL::DFG::LowerDFGToLLVM::compileStringFromCharCode): Implement the opcode. * tests/stress/string-from-char-code-slow.js: Added. 2016-02-15 Benjamin Poulain [JSC] BranchAdd can override arguments of its stackmap https://bugs.webkit.org/show_bug.cgi?id=154274 Reviewed by Filip Pizlo. With the 3 operands BranchAdd added in r196513, we can run into a register allocation such that the destination register is also used by a value in the stack map. It use to be that BranchAdd was a 2 operand instruction. In that form, the destination is also one of the source and can be recovered through Sub. There is no conflict between destination and the stackmap. After r196513, the destination has its own value. It is uncommon on x86 because of the aggressive aliasing but that can happen. On ARM, that's a standard form since there is no need for aliasing. Since the arguments of the stackmap are of type EarlyUse, they appeared as not interfering with the destination. When the register allocator gives the same register to the destination and something in the stack map, the result of BranchAdd destroys the value kept alive for the stackmap. In this patch, I introduce a concept very similar to ForceLateUse to keep the argument of the stackmap live in CheckAdd. The new role is "ForceLateUseUnlessRecoverable". In this mode, anything that is not also an input argument becomes LateUse. As such, it interferes with the destination of CheckAdd. The arguments are recovered by the slow patch of CheckAdd. They remain Early use. This new modes ensure that destination can be aliased to the source when that's useful, while making sure it is not aliased with another value that needs to be live on exit. * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::forEachArg): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::lower): * b3/B3PatchpointSpecial.cpp: (JSC::B3::PatchpointSpecial::forEachArg): * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::forEachArgImpl): (WTF::printInternal): * b3/B3StackmapSpecial.h: * b3/B3StackmapValue.h: 2016-02-15 Joseph Pecoraro Web Inspector: Web Workers have no access to console for debugging https://bugs.webkit.org/show_bug.cgi?id=26237 Reviewed by Timothy Hatcher. * inspector/ConsoleMessage.h: Add accessor for MessageLevel. 2016-02-15 Mark Lam [ARMv7] stress/op_rshift.js and stress/op_urshift.js are failing. https://bugs.webkit.org/show_bug.cgi?id=151514 Reviewed by Filip Pizlo. The issue turns out to be trivial: on ARMv7 (and traditional ARM too), arithmetic shift right (ASR) and logical shift right (LSR) takes an immediate shift amount from 1-32. See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cjacbgca.html. An immediate shift amount of 0 is interpreted as a shift of 32 bits. Meanwhile, our macro assembler is expecting the immediate shift value to be between 0-31. As a result, a shift amount of 0 is being wrongly encoded with 0 bits which means shift right by 32 bits. The fix is to check if the shift amount is 0, and if so, emit a move. Else, emit the right shift as usual. This issue does not affect left shifts, as the immediate shift amount for left shifts is between 0-31 as our macro assembler expects. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::rshift32): (JSC::MacroAssemblerARM::urshift32): (JSC::MacroAssemblerARM::sub32): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::rshift32): (JSC::MacroAssemblerARMv7::urshift32): * tests/stress/op_rshift.js: * tests/stress/op_urshift.js: - Un-skip these tests. They should always pass now. 2016-02-15 Filip Pizlo Parser::parseVariableDeclarationList should null check the node before attempting to create a new CommaExpr https://bugs.webkit.org/show_bug.cgi?id=154244 rdar://problem/24290670 Reviewed by Michael Saboff. * parser/ASTBuilder.h: (JSC::ASTBuilder::appendToCommaExpr): Catch the bug sooner in debug. * parser/Parser.cpp: (JSC::Parser::parseVariableDeclarationList): Fix the bug. * tests/stress/for-let-comma.js: Added. This used to crash in debug and release. 2016-02-15 Benjamin Poulain [JSC] Improve the interface of Inst::shouldTryAliasingDef() https://bugs.webkit.org/show_bug.cgi?id=154227 Reviewed by Andreas Kling. Using Optional<> instead of a bool+reference looks cleaner at the call sites. * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::shouldTryAliasingDef): * b3/B3CheckSpecial.h: * b3/air/AirCustom.h: (JSC::B3::Air::PatchCustom::shouldTryAliasingDef): * b3/air/AirInst.h: * b3/air/AirInstInlines.h: (JSC::B3::Air::Inst::shouldTryAliasingDef): * b3/air/AirIteratedRegisterCoalescing.cpp: * b3/air/AirSpecial.cpp: (JSC::B3::Air::Special::shouldTryAliasingDef): * b3/air/AirSpecial.h: 2016-02-14 Brian Burg WKAutomationDelegate's requestAutomationSession should take a suggested session identifier https://bugs.webkit.org/show_bug.cgi?id=154012 Reviewed by Darin Adler. Add a string parameter to the client method for requesting a new session. * inspector/remote/RemoteInspector.h: 2016-02-13 Timothy Hatcher Fix WebAssembly bug URL in the feature list. * features.json: 2016-02-12 Sukolsak Sakshuwong Change the last RefPtr::get() to release() in String.prototype.normalize https://bugs.webkit.org/show_bug.cgi?id=154211 Reviewed by Ryosuke Niwa. Change the last RefPtr::get() to release() in String.prototype.normalize. * runtime/StringPrototype.cpp: (JSC::normalize): 2016-02-12 Saam barati [ES6] we have an incorrect syntax error when a callee of a function expression has the same name as a top-level lexical declaration https://bugs.webkit.org/show_bug.cgi?id=154143 Reviewed by Benjamin Poulain. We were raising syntax errors on the following type of programs when we shouldn't have been. ``` (function foo() { const foo = 20; }); ``` * parser/Parser.cpp: (JSC::Parser::parseFunctionInfo): * parser/Parser.h: (JSC::Scope::computeLexicallyCapturedVariablesAndPurgeCandidates): (JSC::Scope::declareCallee): (JSC::Scope::declareVariable): (JSC::Scope::hasDeclaredVariable): (JSC::Scope::hasLexicallyDeclaredVariable): (JSC::Scope::hasDeclaredParameter): (JSC::Scope::declareWrite): (JSC::Scope::getCapturedVars): 2016-02-12 Benjamin Poulain [JSC] ZeroExtend and SignExtend use incorrect addressing on ARM64 https://bugs.webkit.org/show_bug.cgi?id=154208 Reviewed by Filip Pizlo. When lowering: @1 = Load32(@x) @2 = SExt8(@1) LowerToAir would see there is a form of SignExtend8To32 (an alias for Load8S) and use that. There are two problems with that: 1) If we have an Addr, it went through legalizeMemoryOffsets() for a 32bits load. If used on an other kind of load, there is no guarantee the addressing is still valid. 2) If we have an Index, it is computed for the 32bits MemoryValue. The computed index is not valid for the 8bits load. (2) could be fixed by changing LowerToAir to use the current instruction width instead of the B3ValueWidth but that's a bit tricky. We should just embrace that one of our target is a Load-Store architecture. In this patch, I just disabled the faulty forms on ARM64. We still need those operations to be fast, this will be addressed in: https://bugs.webkit.org/show_bug.cgi?id=154207 I also strengthened the m_allowScratchRegister assertion. The instructions that do not invalidate the temporary did not run the assertion, making this harder to debug. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load8): (JSC::MacroAssemblerARM64::store64): (JSC::MacroAssemblerARM64::store32): (JSC::MacroAssemblerARM64::loadDouble): (JSC::MacroAssemblerARM64::storeDouble): (JSC::MacroAssemblerARM64::branch32): (JSC::MacroAssemblerARM64::branch64): (JSC::MacroAssemblerARM64::getCachedDataTempRegisterIDAndInvalidate): (JSC::MacroAssemblerARM64::getCachedMemoryTempRegisterIDAndInvalidate): (JSC::MacroAssemblerARM64::dataMemoryTempRegister): (JSC::MacroAssemblerARM64::cachedMemoryTempRegister): (JSC::MacroAssemblerARM64::load): (JSC::MacroAssemblerARM64::store): * b3/air/AirOpcode.opcodes: 2016-02-12 Michael Saboff offlineasm: Emit Dwarf2 file and location directives to allow for debugging .asm files https://bugs.webkit.org/show_bug.cgi?id=152703 Reviewed by Mark Lam. Added support to output Dwarf2 .file and .loc assembler directives to provide the debugging information needed to correlate the offline assembler generated code with the source lines in the .asm files. Changed the tracking of file data to include a file index that was provided to the .file directive. That index is used when emitting the .loc directives. * offlineasm/arm.rb: * offlineasm/arm64.rb: * offlineasm/asm.rb: * offlineasm/backends.rb: * offlineasm/config.rb: * offlineasm/parser.rb: * offlineasm/x86.rb: 2016-02-12 Saam barati The parser doesn't properly protect against global variable references in builtins https://bugs.webkit.org/show_bug.cgi?id=154144 Reviewed by Geoffrey Garen. This patch fixes our global variable reference detection algorithm that was broken. After fixing the algorithm, I detected many places where we were incorrectly using global variables. I've fixed all those. * builtins/BuiltinExecutables.cpp: (JSC::createExecutableInternal): * builtins/NumberPrototype.js: (toLocaleString): * builtins/PromiseConstructor.js: (race): (reject): (resolve): * parser/Nodes.cpp: (JSC::ProgramNode::ProgramNode): (JSC::ModuleProgramNode::ModuleProgramNode): (JSC::ProgramNode::setClosedVariables): Deleted. * parser/Nodes.h: (JSC::ScopeNode::setClosedVariables): Deleted. (JSC::ProgramNode::closedVariables): Deleted. * parser/Parser.cpp: (JSC::Parser::parseInner): (JSC::Parser::didFinishParsing): * parser/Parser.h: (JSC::Scope::setIsLexicalScope): (JSC::Scope::isLexicalScope): (JSC::Scope::closedVariableCandidates): (JSC::Scope::declaredVariables): (JSC::Scope::lexicalVariables): (JSC::Scope::finalizeLexicalEnvironment): (JSC::Parser::positionBeforeLastNewline): (JSC::Parser::locationBeforeLastToken): (JSC::Parser::isFunctionMetadataNode): (JSC::parse): (JSC::Parser::closedVariables): Deleted. 2016-02-12 Filip Pizlo JSObject::putByIndexBeyondVectorLengthWithoutAttributes needs to go to the sparse map based on MAX_STORAGE_VECTOR_INDEX https://bugs.webkit.org/show_bug.cgi?id=154201 rdar://problem/24291387 Reviewed by Saam Barati. I decided against adding a test for this, because it runs for a very long time. * runtime/JSObject.cpp: (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): Fix the bug. * runtime/StringPrototype.cpp: (JSC::stringProtoFuncSplit): Fix a related bug: if this code creates an array that would have hit the above bug, then it would probably manifest as a spin or as swapping. 2016-02-12 Jonathan Davis Add WebAssembly to the status page https://bugs.webkit.org/show_bug.cgi?id=154199 Reviewed by Timothy Hatcher. * features.json: 2016-02-12 Brian Burg Web Inspector: disambiguate the various identifier and connection types in RemoteInspector https://bugs.webkit.org/show_bug.cgi?id=154130 Reviewed by Joseph Pecoraro. There are multiple identifier types: - connection identifier, a string UUID for a remote debugger process. - session identifier, a string UUID for a remote driver/debugger instance. - page/target identifier, a number unique within a single process. There are multiple connection types: - RemoteInspectorXPCConnection, a connection from RemoteInspectorXPCConnectionor to a relay. - RemoteConnectionToTarget, a class that bridges to targets' dispatch queues. Use consistent variable and getter names so that these don't get confused and so that the code is easier to read. This is especially an improvement when working with multiple target types or connection types within the same function. * inspector/remote/RemoteConnectionToTarget.h: * inspector/remote/RemoteConnectionToTarget.mm: Remove the member for m_identifier since we can ask the target for its target identifier or use a default value via WTF::Optional. There's no reason to cache the value. (Inspector::RemoteTargetHandleRunSourceWithInfo): (Inspector::RemoteConnectionToTarget::targetIdentifier): (Inspector::RemoteConnectionToTarget::destination): (Inspector::RemoteConnectionToTarget::setup): (Inspector::RemoteConnectionToTarget::sendMessageToFrontend): Bail out if the target pointer was somehow cleared and we can't get a useful target identifier. (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget): Deleted. * inspector/remote/RemoteControllableTarget.h: * inspector/remote/RemoteInspectionTarget.cpp: (Inspector::RemoteInspectionTarget::pauseWaitingForAutomaticInspection): (Inspector::RemoteInspectionTarget::unpauseForInitializedInspector): * inspector/remote/RemoteInspector.h: * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::nextAvailableTargetIdentifier): (Inspector::RemoteInspector::registerTarget): (Inspector::RemoteInspector::unregisterTarget): (Inspector::RemoteInspector::updateTarget): (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage): (Inspector::RemoteInspector::sendMessageToRemote): (Inspector::RemoteInspector::setupFailed): (Inspector::RemoteInspector::setupCompleted): (Inspector::RemoteInspector::stopInternal): (Inspector::RemoteInspector::setupXPCConnectionIfNeeded): (Inspector::RemoteInspector::xpcConnectionFailed): (Inspector::RemoteInspector::listingForInspectionTarget): (Inspector::RemoteInspector::listingForAutomationTarget): (Inspector::RemoteInspector::pushListingsNow): (Inspector::RemoteInspector::pushListingsSoon): (Inspector::RemoteInspector::updateHasActiveDebugSession): (Inspector::RemoteInspector::receivedSetupMessage): (Inspector::RemoteInspector::receivedDataMessage): (Inspector::RemoteInspector::receivedDidCloseMessage): (Inspector::RemoteInspector::receivedIndicateMessage): (Inspector::RemoteInspector::receivedProxyApplicationSetupMessage): (Inspector::RemoteInspector::receivedConnectionDiedMessage): (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage): (Inspector::RemoteInspector::nextAvailableIdentifier): Deleted. * inspector/remote/RemoteInspectorConstants.h: 2016-02-12 Benjamin Poulain [JSC] On x86, improve the selection of which value are selected for the UseDef part of commutative operations https://bugs.webkit.org/show_bug.cgi?id=154151 Reviewed by Filip Pizlo. Previously, when an instruction destroy an argument with a UseDef use, we would try to pick a good target for the UseDef while doing instruction selection. For example: @x = Add(@1, @2) can be lowered to: Move @1 Tmp3 Add @2 Tmp3 or Move @2 Tmp3 Add @1 Tmp3 The choice of which value ends up copied is done by preferRightForResult() at lowering time. There are two common problems with the code we generate: 1) It is based on UseCount. If a value is at its last use, it is a good target for coalescing even with a use-count > 1. 2) When both values are at their last use, the best choice depends on the register pressure of each. We don't have that information until we do register allocation. This patch implements a simple idea to minimize how many of those Moves are needed. Each commutative operation gets a 3 op variant. The register allocator then attempts to alias *both* of them to the destination. Since our aliasing is conservative, it removes as many copy as possible without causing spilling. There was an unexpected cool impovement too. If you have: Move Tmp1, Tmp2 BranchAdd32 Tmp3, Tmp2 we would previously restore Tmp2 by substracting Tmp3 from the result. We can now just use Tmp1. That removes quite a few Sub from the slow paths. The problem is that simple idea uncoverred a bunch of issues that had to be fixed too. I detail them inline below. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::and64): * assembler/MacroAssemblerX86Common.h: Most addition are adding an Address version of the 3 operands opcodes. The reason for this is allow the complex addressing forms of instructions when spilling. (JSC::MacroAssemblerX86Common::and32): (JSC::MacroAssemblerX86Common::mul32): (JSC::MacroAssemblerX86Common::or32): (JSC::MacroAssemblerX86Common::xor32): (JSC::MacroAssemblerX86Common::moveDouble): This was an unexpected discovery: removing tons of Move32 made floating-point heavy code much slower. It turns out the MoveDouble we were using has partial register dependencies. The x86 optimization manual, Chapter 3, section 3.4.1.13 lists the move instructions executed directly on the frontend. That's what we use now. (JSC::MacroAssemblerX86Common::addDouble): (JSC::MacroAssemblerX86Common::addFloat): (JSC::MacroAssemblerX86Common::mulDouble): (JSC::MacroAssemblerX86Common::mulFloat): (JSC::MacroAssemblerX86Common::andDouble): (JSC::MacroAssemblerX86Common::andFloat): (JSC::MacroAssemblerX86Common::xorDouble): (JSC::MacroAssemblerX86Common::xorFloat): If the destination is not aliased, the version taking an address use LoadFloat/LoadDouble instead of direct addressing. That is because this: Move Tmp1, Tmp2 Op [Tmp3], Tmp2 is slower than Move [Tmp3] Tmp2 Op Tmp1, Tmp2 (sometimes significantly). I am not exactly sure why. (JSC::MacroAssemblerX86Common::branchAdd32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::and64): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::and64): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::and32): (JSC::MacroAssemblerX86Common::mul32): (JSC::MacroAssemblerX86Common::or32): (JSC::MacroAssemblerX86Common::xor32): (JSC::MacroAssemblerX86Common::moveDouble): (JSC::MacroAssemblerX86Common::addDouble): (JSC::MacroAssemblerX86Common::addFloat): (JSC::MacroAssemblerX86Common::mulDouble): (JSC::MacroAssemblerX86Common::mulFloat): (JSC::MacroAssemblerX86Common::andDouble): (JSC::MacroAssemblerX86Common::andFloat): (JSC::MacroAssemblerX86Common::xorDouble): (JSC::MacroAssemblerX86Common::xorFloat): (JSC::MacroAssemblerX86Common::branchAdd32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::and64): (JSC::MacroAssemblerX86_64::mul64): (JSC::MacroAssemblerX86_64::xor64): (JSC::MacroAssemblerX86_64::branchAdd64): * assembler/X86Assembler.h: (JSC::X86Assembler::movapd_rr): (JSC::X86Assembler::movaps_rr): * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::shouldTryAliasingDef): (JSC::B3::CheckSpecial::generate): * b3/B3CheckSpecial.h: * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::lower): * b3/air/AirCustom.h: (JSC::B3::Air::PatchCustom::shouldTryAliasingDef): * b3/air/AirInst.h: * b3/air/AirInstInlines.h: (JSC::B3::Air::Inst::shouldTryAliasingDef): * b3/air/AirIteratedRegisterCoalescing.cpp: Aliasing the operands is done the same way as any coalescing. There were problem with considering all those coalescing as equivalent for the result. Moves are mostly generated for Upsilon-Phis. Getting rid of those tends to give better loops. Sometimes, blocks have only Phis and a Jump. Coalescing those moves gets rids of the block entirely. Where it go interesting was that something like: Move Tmp1, Tmp2 Op Tmp3, Tmp2 was significantly better than: Op Tmp1, Tmp3 Move Tmp1, Tmp4 even in the same basic block. To get back to the same performance when, I had to prioritize regular Moves operations over argument coalescing. Another argument for doing this is that the alias has a shorter life in the hardware because the operation itself gets a new virtual register from the bank. * b3/air/AirOpcode.opcodes: * b3/air/AirSpecial.cpp: (JSC::B3::Air::Special::shouldTryAliasingDef): * b3/air/AirSpecial.h: * b3/testb3.cpp: (JSC::B3::testCheckAddArgumentAliasing64): (JSC::B3::testCheckAddArgumentAliasing32): (JSC::B3::testCheckAddSelfOverflow64): (JSC::B3::testCheckAddSelfOverflow32): (JSC::B3::testCheckMulArgumentAliasing64): (JSC::B3::testCheckMulArgumentAliasing32): (JSC::B3::run): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitSaveOrCopyCalleeSavesFor): This ruined my week. When regenerating the frame of an inlined function that was called through a tail call, we were ignoring r13 for some reason. Since this patch makes it more likely to increase the degree of each Tmp, the number of register used increased and r13 was more commonly used. When getting out of OSRExit, we would have that value trashed :( The fix is simply to restore it like the other two Baseline callee saved register. 2016-02-12 Yusuke Suzuki [ES6] Implement @@search https://bugs.webkit.org/show_bug.cgi?id=143889 Reviewed by Darin Adler. Implement RegExp.prototype[@@search]. In ES6, String.prototype.search delegates the actual matching to it instead of executing RegExp matching inside String.prototype.search method itself. By customizing @@search method, we can change the behavior of String.prototype.search for derived / customized RegExp object. * CMakeLists.txt: * DerivedSources.make: * builtins/BuiltinNames.h: (JSC::BuiltinNames::BuiltinNames): Deleted. * builtins/BuiltinUtils.h: * builtins/StringPrototype.js: (search): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): (JSC::regExpProtoFuncSearch): * runtime/RegExpPrototype.h: (JSC::RegExpPrototype::create): * runtime/StringPrototype.cpp: (JSC::StringPrototype::getOwnPropertySlot): (JSC::StringPrototype::finishCreation): Deleted. (JSC::stringProtoFuncSearch): Deleted. * runtime/StringPrototype.h: * tests/es6.yaml: * tests/stress/regexp-search.js: Added. (shouldBe): (shouldThrow): (errorKey.toString): (primitive.of.primitives.shouldThrow): (testRegExpSearch): (testSearch): (testBoth): (alwaysUnmatch): 2016-02-12 Keith Miller AdaptiveInferredPropertyValueWatchpoint can trigger a GC that frees its CodeBlock and thus itself https://bugs.webkit.org/show_bug.cgi?id=154146 Reviewed by Filip Pizlo. Consider the following: there is some CodeBlock, C, that is watching some object, O, with a structure, S, for replacements. Also, suppose that C has no references anymore and is due to be GCed. Now, when some new property is added to O, S will create a new structure S' and fire its transition watchpoints. Since C is watching S for replacements it will attempt to have its AdaptiveInferredPropertyValueWatchpoint relocate itself to S'. To do so, it needs it allocate RareData on S'. This allocation may cause a GC, which frees C while still executing its watchpoint handler. The solution to this is to defer GC while running AdaptiveInferredPropertyValueWatchpointBase handlers. * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp: (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire): 2016-02-12 Gavin Barraclough Separate out !allowsAccess path in JSDOMWindowCustom getOwnPropertySlot https://bugs.webkit.org/show_bug.cgi?id=154156 Reviewed by Chris Dumez. * runtime/CommonIdentifiers.h: - added new property names, needed by jsDOMWindowGetOwnPropertySlotDisallowAccess. 2016-02-12 Sukolsak Sakshuwong Update ICU header files to version 52 https://bugs.webkit.org/show_bug.cgi?id=154160 Reviewed by Alex Christensen. Update ICU header files to version 52 to allow the use of newer APIs. * icu/unicode/localpointer.h: * icu/unicode/platform.h: * icu/unicode/ptypes.h: * icu/unicode/putil.h: * icu/unicode/ucal.h: * icu/unicode/uchar.h: * icu/unicode/ucnv.h: * icu/unicode/ucol.h: * icu/unicode/uconfig.h: * icu/unicode/udat.h: * icu/unicode/udatpg.h: * icu/unicode/udisplaycontext.h: Added. * icu/unicode/uenum.h: * icu/unicode/uformattable.h: Added. * icu/unicode/uiter.h: * icu/unicode/uloc.h: * icu/unicode/umachine.h: * icu/unicode/unorm2.h: * icu/unicode/unum.h: * icu/unicode/urename.h: * icu/unicode/uscript.h: * icu/unicode/uset.h: * icu/unicode/ustring.h: * icu/unicode/utf.h: * icu/unicode/utf16.h: * icu/unicode/utf8.h: * icu/unicode/utf_old.h: * icu/unicode/utypes.h: * icu/unicode/uvernum.h: * icu/unicode/uversion.h: 2016-02-12 Filip Pizlo Fast path in JSObject::defineOwnIndexedProperty() forgets to check for the posibility of a descriptor that doesn't have a value https://bugs.webkit.org/show_bug.cgi?id=154175 rdar://problem/24291497 Reviewed by Geoffrey Garen. * runtime/JSObject.cpp: (JSC::JSObject::defineOwnIndexedProperty): Fix the bug. * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayValueMap::putEntry): Catch the bug sooner in debug. (JSC::SparseArrayValueMap::putDirect): * tests/stress/sparse-define-empty-descriptor.js: Added. This used to crash in release. 2016-02-11 Brian Burg Web Inspector: RemoteInspector's listings should include whether an AutomationTarget is paired https://bugs.webkit.org/show_bug.cgi?id=154077 Reviewed by Joseph Pecoraro. Instead of not generating a listing for the target when it is occupied, generate the listing with a 'paired' flag. The old flag was redundant because a _WKAutomationDelegate will not create a session if it doesn't support automation or it already has an active session. * inspector/remote/RemoteAutomationTarget.cpp: (Inspector::RemoteAutomationTarget::setIsPaired): (Inspector::RemoteAutomationTarget::setAutomationAllowed): Deleted. * inspector/remote/RemoteAutomationTarget.h: Return false for remoteControlAllowed() if the target is already paired. This function is used by RemoteInspector to deny incoming connections. * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::listingForAutomationTarget): * inspector/remote/RemoteInspectorConstants.h: 2016-02-11 Filip Pizlo DFG::ByteCodeParser needs to null check the result of presenceLike() https://bugs.webkit.org/show_bug.cgi?id=154135 rdar://problem/24291586 Reviewed by Geoffrey Garen. ByteCodeParser::presenceLike() could return a null object property condition if it detects a contradiction. That could happen due to bogus profiling. It's totally OK - we just need to bail from using a property condition when that happens. * bytecode/ObjectPropertyCondition.h: (JSC::ObjectPropertyCondition::equivalence): (JSC::ObjectPropertyCondition::operator bool): (JSC::ObjectPropertyCondition::object): (JSC::ObjectPropertyCondition::condition): (JSC::ObjectPropertyCondition::operator!): Deleted. * bytecode/PropertyCondition.h: (JSC::PropertyCondition::equivalence): (JSC::PropertyCondition::operator bool): (JSC::PropertyCondition::kind): (JSC::PropertyCondition::uid): (JSC::PropertyCondition::operator!): Deleted. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::check): (JSC::DFG::ByteCodeParser::load): 2016-02-11 Benjamin Poulain [JSC] SqrtFloat and CeilFloat also suffer from partial register stalls https://bugs.webkit.org/show_bug.cgi?id=154131 Reviewed by Filip Pizlo. Looks like I forgot to update this when adding Float support. Credit to Filip for finding this issue. * b3/air/AirFixPartialRegisterStalls.cpp: 2016-02-11 Filip Pizlo Cannot call initializeIndex() if we didn't create the array using tryCreateUninitialized() https://bugs.webkit.org/show_bug.cgi?id=154126 Reviewed by Saam Barati. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSplice): 2016-02-11 Sukolsak Sakshuwong [INTL] Implement Intl.NumberFormat.prototype.resolvedOptions () https://bugs.webkit.org/show_bug.cgi?id=147602 Reviewed by Darin Adler. This patch implements Intl.NumberFormat.prototype.resolvedOptions() according to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.) * runtime/IntlDateTimeFormat.cpp: (JSC::localeData): * runtime/IntlNumberFormat.cpp: (JSC::localeData): (JSC::computeCurrencySortKey): (JSC::extractCurrencySortKey): (JSC::computeCurrencyDigits): (JSC::IntlNumberFormat::initializeNumberFormat): (JSC::IntlNumberFormat::styleString): (JSC::IntlNumberFormat::currencyDisplayString): (JSC::IntlNumberFormat::resolvedOptions): (JSC::IntlNumberFormat::setBoundFormat): * runtime/IntlNumberFormat.h: * runtime/IntlNumberFormatConstructor.cpp: (JSC::constructIntlNumberFormat): (JSC::callIntlNumberFormat): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototypeFuncResolvedOptions): * runtime/IntlObject.cpp: (JSC::intlNumberOption): (JSC::numberingSystemsForLocale): (JSC::getNumberingSystemsForLocale): Deleted. * runtime/IntlObject.h: 2016-02-11 Filip Pizlo MacroAssemblerX86 should be happy with shift(cx, cx) https://bugs.webkit.org/show_bug.cgi?id=154124 Reviewed by Saam Barati. Prior to this change the assembler asserted that shift_amount and dest cannot be the same. That's a good assertion for when shift_amount is not in cx. But if it's in cx already then it's OK for them to be the same. Air will sometimes do shift(cx, cx) if you do "x << x" and the coalescing got particularly clever. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::lshift32): (JSC::MacroAssemblerX86Common::rshift32): (JSC::MacroAssemblerX86Common::urshift32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::lshift64): (JSC::MacroAssemblerX86_64::rshift64): (JSC::MacroAssemblerX86_64::urshift64): * b3/testb3.cpp: (JSC::B3::testLShiftSelf32): (JSC::B3::testRShiftSelf32): (JSC::B3::testURShiftSelf32): (JSC::B3::testLShiftSelf64): (JSC::B3::testRShiftSelf64): (JSC::B3::testURShiftSelf64): (JSC::B3::run): 2016-02-11 Saam barati The sampling profiler's stack walker methods should be marked with SUPPRESS_ASAN https://bugs.webkit.org/show_bug.cgi?id=154123 Reviewed by Mark Lam. The entire premise of the sampling profiler is to load from another thread's memory. We should SUPPRESS_ASAN on the methods that do this. * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::FrameWalker): (JSC::FrameWalker::walk): (JSC::FrameWalker::advanceToParentFrame): (JSC::FrameWalker::isAtTop): (JSC::FrameWalker::resetAtMachineFrame): 2016-02-11 Csaba Osztrogonác Unreviewed typo fix after r190063. * dfg/DFGSpeculativeJIT.cpp: Removed property svn:executable. * dfg/DFGSpeculativeJIT.h: Removed property svn:executable. * jit/JIT.h: Removed property svn:executable. * jit/JITInlines.h: Removed property svn:executable. * jit/JITOpcodes.cpp: Removed property svn:executable. 2016-02-11 Csaba Osztrogonác Unreviewed typo fix after r190063. * dfg/DFGSpeculativeJIT.cpp: Removed property svn:executable. * dfg/DFGSpeculativeJIT.h: Removed property svn:executable. * jit/JIT.h: Removed property svn:executable. * jit/JITInlines.h: Removed property svn:executable. * jit/JITOpcodes.cpp: Removed property svn:executable. 2016-02-10 Keith Miller Symbol.species accessors on builtin constructors should be configurable https://bugs.webkit.org/show_bug.cgi?id=154097 Reviewed by Benjamin Poulain. We did not have the Symbol.species accessors on our builtin constructors marked as configurable. This does not accurately follow the ES6 spec as the ES6 spec states that all default accessors on builtins should be configurable. This means that we need an additional watchpoint on ArrayConstructor to make sure that no users re-configures Symbol.species. * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::finishCreation): * runtime/ArrayPrototype.cpp: (JSC::speciesConstructArray): (JSC::ArrayPrototype::setConstructor): (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): * runtime/ArrayPrototype.h: (JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties): (JSC::ArrayPrototype::didChangeConstructorProperty): Deleted. * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::finishCreation): * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::finishCreation): * runtime/JSTypedArrayViewConstructor.cpp: (JSC::JSTypedArrayViewConstructor::finishCreation): * runtime/MapConstructor.cpp: (JSC::MapConstructor::finishCreation): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::finishCreation): * runtime/SetConstructor.cpp: (JSC::SetConstructor::finishCreation): * tests/stress/array-species-config-array-constructor.js: Added. (A): * tests/stress/symbol-species.js: (testSymbolSpeciesOnConstructor): 2016-02-10 Benjamin Poulain [JSC] The destination of Sqrt should be Def, not UseDef https://bugs.webkit.org/show_bug.cgi?id=154086 Reviewed by Geoffrey Garen. An unfortunate copy-paste: the destination of SqrtDouble and SqrtFloat was defined as UseDef. As a result, the argument would be interfering with everything defined prior. * b3/air/AirOpcode.opcodes: 2016-02-10 Chris Dumez [Web IDL] interface objects should be Function objects https://bugs.webkit.org/show_bug.cgi?id=154038 Reviewed by Geoffrey Garen. Update functionProtoFuncToString() to handle JSObjects that have the TypeOfShouldCallGetCallData flag and are callable, as these behave like functions and use ClassInfo::className() as function name in this case. * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncToString): 2016-02-10 Chris Dumez Attributes on the Window instance should be configurable unless [Unforgeable] https://bugs.webkit.org/show_bug.cgi?id=153920 Reviewed by Darin Adler. Marking the Window instance attributes as configurable but cause getOwnPropertyDescriptor() to report them as configurable, as expected. However, trying to delete them would actually lead to unexpected behavior because: - We did not reify custom accessor properties (most of the Window properties are custom accessors) upon deletion. - For non-reified static properties marked as configurable, JSObject::deleteProperty() would attempt to call the property setter with undefined. As a result, calling delete window.name would cause window.name to become the string "undefined" instead of the undefined value. * runtime/JSObject.cpp: (JSC::getClassPropertyNames): Now that we reify ALL properties, we only need to check the property table if we have not reified. As a result, I dropped the 'didReify' parameter for this function and instead only call this function if we have not yet reified. (JSC::JSObject::putInlineSlow): Only call putEntry() if we have not reified: Drop the '|| !(entry->attributes() & BuiltinOrFunctionOrAccessor)' check as such properties now get reified as well. (JSC::JSObject::deleteProperty): - Call reifyAllStaticProperties() instead of reifyStaticFunctionsForDelete() so that we now reify all properties upon deletion, including the custom accessors. reifyStaticFunctionsForDelete() is now removed and the same reification function is now used by: deletion, getOwnPropertyDescriptor() and eager reification of the prototype objects in the bindings. - Drop code that falls back to calling the static property setter with undefined if we cannot find the property in the property storage. As we now reify ALL properties, the code removing the property from the property storage should succeed, provided that the property actually exists. (JSC::JSObject::getOwnNonIndexPropertyNames): Only call getClassPropertyNames() if we have not reified. We should no longer check the static property table after reifying now that we reify all properties. (JSC::JSObject::reifyAllStaticProperties): Merge with reifyStaticFunctionsForDelete(). The only behavior change is the flattening to an uncacheable dictionary, like reifyStaticFunctionsForDelete() used to do. * runtime/JSObject.h: 2016-02-10 Commit Queue Unreviewed, rolling out r196251. https://bugs.webkit.org/show_bug.cgi?id=154078 Large regression on Dromaeo needs explanation (Requested by kling on #webkit). Reverted changeset: "Visiting a WeakBlock should report bytes visited, since we reported them allocated." https://bugs.webkit.org/show_bug.cgi?id=153978 http://trac.webkit.org/changeset/196251 2016-02-10 Csaba Osztrogonác REGRESSION(r196331): It made ~180 JSC tests crash on ARMv7 Linux https://bugs.webkit.org/show_bug.cgi?id=154064 Reviewed by Mark Lam. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generate): Added EABI_32BIT_DUMMY_ARG where it is necessary. * dfg/DFGSpeculativeJIT.h: Fixed the comment. * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArgumentsWithExecState): Added. * wasm/WASMFunctionCompiler.h: Fixed the comment. 2016-02-09 Keith Miller calling methods off super in a class constructor should check for TDZ https://bugs.webkit.org/show_bug.cgi?id=154060 Reviewed by Ryosuke Niwa. In a class constructor we need to check for TDZ when calling a method off the super class. This is because, for super method calls, we use the derived class's newly constructed object as the super method's this value. * bytecompiler/NodesCodegen.cpp: (JSC::FunctionCallDotNode::emitBytecode): * tests/stress/super-method-calls-check-tdz.js: Added. (Base): (Derived): (test): 2016-02-09 Filip Pizlo Don't crash if we fail to parse a builtin https://bugs.webkit.org/show_bug.cgi?id=154047 rdar://problem/24300617 Reviewed by Mark Lam. Crashing probably seemed like a good idea at the time, but we could get here in case of a near stack overflow, so that the parser bails because of recursion. * parser/Parser.h: (JSC::parse): 2016-02-07 Gavin Barraclough GetValueFunc/PutValueFunc should not take both slotBase and thisValue https://bugs.webkit.org/show_bug.cgi?id=154009 Reviewed by Geoff Garen. In JavaScript there are two types of properties - regular value properties, and accessor properties. One difference between these is how they are reflected by getOwnPropertyDescriptor, and another is what object they operate on in the case of a prototype access. If you access a value property of a prototype object it return a value pertinent to the prototype, but in the case of a prototype object returning an accessor, then the accessor function is applied to the base object of the access. JSC supports special 'custom' properties implemented as a c++ callback, and these custom properties can be used to implement either value- or accessor-like behavior. getOwnPropertyDescriptor behavior is selected via the CustomAccessor attribute. Value- or accessor-like object selection is current supported by passing both the slotBase and the thisValue to the callback,and hoping it uses the right one. This is probably inefficient, bug-prone, and leads to crazy like JSBoundSlotBaseFunction. Instead, just pass one thisValue to the callback functions, consistent with CustomAccessor. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::JSCallbackObject::getStaticValue): (JSC::JSCallbackObject::staticFunctionGetter): (JSC::JSCallbackObject::callbackGetter): - Merged slotBase & thisValue to custom property callbacks. * bytecode/PolymorphicAccess.cpp: (JSC::AccessCase::generate): - Modified the call being JIT generated - GetValueFunc/PutValueFunc now only take 3, rather than 4 arguments. Selects which one to keep/drop based on access type. (WTF::printInternal): * bytecode/PolymorphicAccess.h: (JSC::AccessCase::isGet): (JSC::AccessCase::isPut): (JSC::AccessCase::isIn): (JSC::AccessCase::doesCalls): (JSC::AccessCase::isGetter): * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeForStubInfo): * jit/Repatch.cpp: (JSC::tryCacheGetByID): (JSC::tryCachePutByID): - Split the CustomGetter/Setter access types into Value/Accessor variants. * jsc.cpp: (WTF::CustomGetter::getOwnPropertySlot): (WTF::CustomGetter::customGetter): (WTF::RuntimeArray::RuntimeArray): (WTF::RuntimeArray::lengthGetter): - Merged slotBase & thisValue to custom property callbacks. * runtime/CustomGetterSetter.cpp: (JSC::callCustomSetter): - Pass 3 arguments when calling PutValueFunc. * runtime/CustomGetterSetter.h: * runtime/JSBoundSlotBaseFunction.cpp: (JSC::boundSlotBaseFunctionCall): (JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): - callCustomSetter currently takes a flag to distinguish value/accessor calls. * runtime/JSFunction.cpp: (JSC::retrieveArguments): (JSC::JSFunction::argumentsGetter): (JSC::retrieveCallerFunction): (JSC::JSFunction::callerGetter): (JSC::JSFunction::lengthGetter): (JSC::JSFunction::nameGetter): * runtime/JSFunction.h: * runtime/JSModuleNamespaceObject.cpp: (JSC::JSModuleNamespaceObject::visitChildren): (JSC::callbackGetter): - Merged slotBase & thisValue to custom property callbacks. * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): - callCustomSetter currently takes a flag to distinguish value/accessor calls. * runtime/Lookup.h: (JSC::putEntry): - split PutPropertySlot setCustom into Value/Accessor variants. * runtime/PropertySlot.cpp: (JSC::PropertySlot::functionGetter): (JSC::PropertySlot::customGetter): * runtime/PropertySlot.h: (JSC::PropertySlot::PropertySlot): (JSC::PropertySlot::getValue): - added customGetter helper to call GetValueFunc. * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::setNewProperty): (JSC::PutPropertySlot::setCustomValue): (JSC::PutPropertySlot::setCustomAccessor): (JSC::PutPropertySlot::setThisValue): (JSC::PutPropertySlot::customSetter): (JSC::PutPropertySlot::context): (JSC::PutPropertySlot::isStrictMode): (JSC::PutPropertySlot::isCacheablePut): (JSC::PutPropertySlot::isCacheableSetter): (JSC::PutPropertySlot::isCacheableCustom): (JSC::PutPropertySlot::isCustomAccessor): (JSC::PutPropertySlot::isInitialization): (JSC::PutPropertySlot::cachedOffset): (JSC::PutPropertySlot::setCustomProperty): Deleted. - split PutPropertySlot setCustom into Value/Accessor variants. * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::getOwnPropertySlot): (JSC::regExpConstructorDollar1): (JSC::regExpConstructorDollar2): (JSC::regExpConstructorDollar3): (JSC::regExpConstructorDollar4): (JSC::regExpConstructorDollar5): (JSC::regExpConstructorDollar6): (JSC::regExpConstructorDollar7): (JSC::regExpConstructorDollar8): (JSC::regExpConstructorDollar9): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): (JSC::setRegExpConstructorInput): (JSC::setRegExpConstructorMultiline): * runtime/RegExpObject.cpp: (JSC::RegExpObject::defineOwnProperty): (JSC::regExpObjectSetLastIndexStrict): (JSC::regExpObjectSetLastIndexNonStrict): (JSC::RegExpObject::put): - Merged slotBase & thisValue to custom property callbacks. 2016-02-09 Filip Pizlo Spread expressions are not fair game for direct binding https://bugs.webkit.org/show_bug.cgi?id=154042 rdar://problem/24291413 Reviewed by Saam Barati. Prior to this change we crashed on this: var [x] = [...y]; Because NodesCodegen thinks that this is a direct binding. It's not, because we cannot directly generate bytecode for "...y". This is a unique property of spread expressions, so its sufficient to just bail out of direct binding if we see a spread expression. That's what this patch does. * bytecompiler/NodesCodegen.cpp: (JSC::ArrayPatternNode::emitDirectBinding): * tests/stress/spread-in-tail.js: Added. (foo): (catch): 2016-02-09 Commit Queue Unreviewed, rolling out r196286. https://bugs.webkit.org/show_bug.cgi?id=154026 Looks like 5% iOS PLT regression (Requested by kling on #webkit). Reverted changeset: "[iOS] Throw away some unlinked code when navigating to a new page." https://bugs.webkit.org/show_bug.cgi?id=154014 http://trac.webkit.org/changeset/196286 2016-02-08 Keith Miller Error construction for inlined operations should not use the inliner's CodeBlock https://bugs.webkit.org/show_bug.cgi?id=154021 Reviewed by Mark Lam. Previously, if one function, A, was inlined into another function, B, in the DFG/FTL we would use B's DFG/FTL CodeBlock to construct source information about the Error. We would correctly compute the bytecodeOffset in A for the an expression but we would not use one of A's CodeBlocks when looking up source. This caused crashes during operationIn as we expected to be able to find the text "in" in the source. * runtime/ErrorInstance.cpp: (JSC::appendSourceToError): * tests/stress/inlined-error-gets-correct-codeblock-for-bytecodeoffset.js: Added. (map): (n): (one): (catch): 2016-02-08 Saam Barati runtimeTypeForValue should protect against seeing TDZ value https://bugs.webkit.org/show_bug.cgi?id=154023 rdar://problem/24291413 Reviewed by Michael Saboff. There are a few back traces I've seen from crashes that bottom out inside runtimeTypeForValue. I haven't been able to reproduce any such crash, but it's likely that we're encountering the empty JSValue. It's better to just have this function protect against seeing the empty value instead of dereferencing a null pointer when it thinks the value is a cell. * runtime/RuntimeType.cpp: (JSC::runtimeTypeForValue): 2016-02-08 Andreas Kling [iOS] Throw away some unlinked code when navigating to a new page. Reviewed by Gavin Barraclough. * runtime/VM.cpp: (JSC::VM::deleteAllCodeExceptCaches): (JSC::VM::deleteAllLinkedCode): Deleted. * runtime/VM.h: 2016-02-08 Filip Pizlo B3::foldPathConstants() needs to execute its insertion set https://bugs.webkit.org/show_bug.cgi?id=154020 Reviewed by Saam Barati. * b3/B3FoldPathConstants.cpp: * b3/testb3.cpp: (JSC::B3::testFoldPathEqual): Added this. It used to crash in validation. (JSC::B3::run): 2016-02-08 Yusuke Suzuki [JSC] Introduce @isObject bytecode intrinsic and use it instead of JS implemented one https://bugs.webkit.org/show_bug.cgi?id=153976 Reviewed by Darin Adler. Use bytecode op_is_object directly. * builtins/GlobalObject.js: (isObject): Deleted. * bytecode/BytecodeIntrinsicRegistry.h: * bytecompiler/NodesCodegen.cpp: (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString): (JSC::BytecodeIntrinsicNode::emit_intrinsic_isObject): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): Deleted. 2016-02-08 Yusuke Suzuki {Map,Set}.prototype.forEach should be visible as own properties https://bugs.webkit.org/show_bug.cgi?id=153974 Reviewed by Darin Adler. Now, Map and Set uses builtin tables. We should inlude it in class info. * runtime/MapPrototype.cpp: * runtime/SetPrototype.cpp: 2016-02-08 Filip Pizlo Baseline JIT should not require its input to be constant-propagated https://bugs.webkit.org/show_bug.cgi?id=154011 rdar://problem/24290933 Reviewed by Mark Lam. * jit/JITArithmetic.cpp: (JSC::JIT::emitBitBinaryOpFastPath): (JSC::JIT::emitRightShiftFastPath): (JSC::JIT::emit_op_add): (JSC::JIT::emit_op_div): (JSC::JIT::emit_op_mul): 2016-02-08 Filip Pizlo CodeCache should give up on evals if there are variables under TDZ https://bugs.webkit.org/show_bug.cgi?id=154002 rdar://problem/24300998 Reviewed by Mark Lam. Disable the code cache optimization because our approach to TDZ for scoped variables - using a separate check_tdz opcode when logically it's the get_from_scope's job to do it - makes caching code impossible if there are any variables in TDZ. We should do the right thing in the future, and fold the TDZ check into the get_from_scope. This is better not only because it will restore caching, but because our bytecode for heap accesses is usually at the highest practically doable level of abstraction, so that ICs, compilers and caches can see the intended meaning of the bytecode more easily. This doesn't appear to slow anything down, but that's just because we don't have enough ES6 benchmarks. I've filed: https://bugs.webkit.org/show_bug.cgi?id=154010 * runtime/CodeCache.cpp: (JSC::CodeCache::getGlobalCodeBlock): 2016-02-08 Skachkov Oleksandr [ES6] Arrow function syntax. Using 'super' in arrow function that declared out of the class should lead to Syntax error https://bugs.webkit.org/show_bug.cgi?id=150893 Reviewed by Saam Barati. 'super' and 'super()' inside of the arrow function should lead to syntax error if they are used out of the class context or they wrapped by ordinary function. Now JSC returns ReferenceError but should return SyntaxError according to the following specs: http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors and http://www.ecma-international.org/ecma-262/6.0/#sec-arrow-function-definitions-runtime-semantics-evaluation Curren patch implemented only one case when super/super() are used inside of the arrow function Case when super/super() are used within the eval: class A {} class B extends A { costructor() { eval("super()");} } is not part of this patch and will be implemented in this issue https://bugs.webkit.org/show_bug.cgi?id=153864. The same for case when eval with super/super() is invoked in arrow function will be implemented in issue https://bugs.webkit.org/show_bug.cgi?id=153977. * parser/Parser.cpp: (JSC::Parser::parseFunctionInfo): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::setExpectedSuperBinding): (JSC::Scope::expectedSuperBinding): (JSC::Scope::setConstructorKind): (JSC::Scope::constructorKind): (JSC::Parser::closestParentNonArrowFunctionNonLexicalScope): * tests/stress/arrowfunction-lexical-bind-supercall-4.js: * tests/stress/arrowfunction-lexical-bind-superproperty.js: 2016-02-08 Filip Pizlo Parser should detect error before calls to parseAssignmentExpression() https://bugs.webkit.org/show_bug.cgi?id=153975 rdar://problem/24291231 Reviewed by Saam Barati. Fixes a very hard-to-create situation that an internal test picked up. * parser/Parser.cpp: (JSC::Parser::parseVariableDeclarationList): (JSC::Parser::parseAssignmentExpression): 2016-02-08 Andreas Kling Visiting a WeakBlock should report bytes visited, since we reported them allocated. Reviewed by Darin Adler. When creating a WeakBlock, we tell Heap that we've allocated 1 KB (WeakBlock::blockSize) of memory. Consequently, when visiting a WeakBlock, we should also report 1 KB of memory visited. Otherwise Heap will think that those 1 KB already went away. This was causing us to underestimate heap size, which affects collection scheduling. * heap/SlotVisitor.h: (JSC::SlotVisitor::reportMemoryVisited): * heap/WeakBlock.cpp: (JSC::WeakBlock::visit): 2016-02-07 Saam barati Follow up patch to: [ES6] bound functions .name property should be "bound " + the target function's name https://bugs.webkit.org/show_bug.cgi?id=153796 Reviewed by Darin Adler. This follow-up patch addresses some comments/suggestions by Ryosuke, Darin, and Joe. It simplifies JSBoundFunction::toStringName and adds some tests for bound names. * runtime/JSBoundFunction.cpp: (JSC::hasInstanceBoundFunction): (JSC::JSBoundFunction::create): (JSC::JSBoundFunction::toStringName): 2016-02-07 Filip Pizlo String.match should defend against matches that would crash the VM https://bugs.webkit.org/show_bug.cgi?id=153964 rdar://problem/24301119 Reviewed by Saam Barati. This fixes a crash in an internal test case. * runtime/ArgList.cpp: (JSC::MarkedArgumentBuffer::slowAppend): Use best practices to ensure that the size we compute makes sense. Crash if it stops making sense, since most users of this API assume that they are creating something small enough to fit on the stack. * runtime/ArgList.h: (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer): (JSC::MarkedArgumentBuffer::size): (JSC::MarkedArgumentBuffer::operator new): Deleted. These were ineffective. According to the debugger, we were still calling system malloc. So, I changed the code to use fastMalloc() directly. (JSC::MarkedArgumentBuffer::operator delete): Deleted. * runtime/StringPrototype.cpp: (JSC::stringProtoFuncMatch): Explicitly defend against absurd sizes. Of course, it's still possible to crash the VM on OOME. That's sort of always been the philosophy of JSC - we don't guarantee that you'll get a nice-looking error whenever you run out of memory, since in a GC'd environment you can't really guarantee those things. But, if you have a match that obvious won't fit in memory, then reporting an error is useful in case this is a developer experimenting with a buggy regexp. 2016-02-07 Dan Bernstein [Cocoa] Replace __has_include guards around inclusion of Apple-internal-SDK headers with USE(APPLE_INTERNAL_SDK) https://bugs.webkit.org/show_bug.cgi?id=153963 Reviewed by Sam Weinig. * inspector/remote/RemoteInspectorXPCConnection.mm: 2016-02-06 Filip Pizlo FTL must store the call site index before runtime calls, even if it's the tail call slow path https://bugs.webkit.org/show_bug.cgi?id=153955 rdar://problem/24290970 Reviewed by Saam Barati. This is necessary because you could throw an exception in a host call on the tail call's slow path. That'll route us to lookupExceptionHandler(), which unwinds starting with the call site index of our frame. Bad things happen if it's not set. Prior to this patch it was possible for the call site index field to be uninitialized, which meant that the throwing machinery was making a wild guess about where we are. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall): * tests/stress/tail-call-host-call-throw.js: Added. 2016-02-06 Darin Adler Finish auditing call sites of upper() and lower(), eliminate many, and rename the functions https://bugs.webkit.org/show_bug.cgi?id=153905 Reviewed by Sam Weinig. * runtime/IntlObject.cpp: (JSC::canonicalLangTag): Use converToASCIIUppercase on the language tag. * runtime/StringPrototype.cpp: (JSC::stringProtoFuncToLowerCase): Tweak style and update for name change. (JSC::stringProtoFuncToUpperCase): Ditto. 2016-02-06 Chris Dumez Object.getOwnPropertyDescriptor() does not work on sub-frame's window https://bugs.webkit.org/show_bug.cgi?id=153925 Reviewed by Darin Adler. Calling Object.getOwnPropertyDescriptor() on a sub-frame's window was returning undefined for that window's own properties. The reason was that the check getOwnPropertySlot() is using to make sure the PropertySlot is not for a property coming from the prototype was wrong. The check was checking that 'this != slotBase' which works fine unless this is a JSProxy (e.g. JSDOMWindowShell). To handle proxies, the code was also checking that 'slotBase.toThis() != this', attempting to get the slotBase/Window's proxy. However, due to the implementation of toThis(), we were getting the lexical global object's proxy instead of slotBase's proxy. To avoid this issue, the new code explicitly checks if 'this' is a JSProxy and makes sure 'JSProxy::target() != slotBase', instead of using toThis(). * runtime/JSObject.cpp: (JSC::JSObject::getOwnPropertyDescriptor): 2016-02-06 Andreas Kling [iOS] Throw away linked code when navigating to a new page. Reviewed by Gavin Barraclough. Add a VM API for throwing away linked code only. * runtime/VM.cpp: (JSC::VM::deleteAllLinkedCode): * runtime/VM.h: 2016-02-06 Commit Queue Unreviewed, rolling out r196104. https://bugs.webkit.org/show_bug.cgi?id=153940 Regressed Speedometer on iOS (Requested by kling on #webkit). Reverted changeset: "[iOS] Throw away linked code when navigating to a new page." https://bugs.webkit.org/show_bug.cgi?id=153851 http://trac.webkit.org/changeset/196104 2016-02-05 Alex Christensen Fix internal Windows build https://bugs.webkit.org/show_bug.cgi?id=153930 Reviewed by Mark Lam. * JavaScriptCore.vcxproj/JavaScriptCore.proj: I made a typo in r196144. 2016-02-05 Saam barati Web Inspector: Include SamplingProfiler's expression-level data for stack frames in the protocol https://bugs.webkit.org/show_bug.cgi?id=153455 Reviewed by Joseph Pecoraro. We now send the sampling profiler's expression-level line/column info in the inspector protocol. * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::buildSamples): * inspector/protocol/ScriptProfiler.json: * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::StackFrame::hasExpressionInfo): 2016-02-05 Saam barati follow-up to: JSC Sampling Profiler: (host) is confusing in cases where I would expect to see JS name https://bugs.webkit.org/show_bug.cgi?id=153663 Rubber stamped by Joseph Pecoraro. We were performing operations that required us to hold the VM lock even when we might not have been holding it. We now ensure we're holding it. * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::InspectorScriptProfilerAgent::trackingComplete): 2016-02-05 Filip Pizlo Arrayify for a typed array shouldn't create a monster https://bugs.webkit.org/show_bug.cgi?id=153908 rdar://problem/24290639 Reviewed by Mark Lam. Previously if you convinced the DFG to emit an Arrayify to ArrayStorage and then gave it a typed array, you'd corrupt the object. * runtime/JSArrayBufferView.cpp: (WTF::printInternal): * runtime/JSArrayBufferView.h: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::visitChildren): (JSC::JSGenericTypedArrayView::slowDownAndWasteMemory): * runtime/JSObject.cpp: (JSC::JSObject::copyButterfly): (JSC::JSObject::enterDictionaryIndexingMode): (JSC::JSObject::ensureInt32Slow): (JSC::JSObject::ensureDoubleSlow): (JSC::JSObject::ensureContiguousSlow): (JSC::JSObject::ensureArrayStorageSlow): (JSC::JSObject::growOutOfLineStorage): (JSC::getBoundSlotBaseFunctionForGetterSetter): * runtime/Structure.h: * tests/stress/arrayify-array-storage-typed-array.js: Added. This test failed. * tests/stress/arrayify-int32-typed-array.js: Added. This test case already had other protections, but we beefed them up. 2016-02-04 Joseph Pecoraro Web Inspector: InspectorTimelineAgent doesn't need to recompile functions because it now uses the sampling profiler https://bugs.webkit.org/show_bug.cgi?id=153500 Reviewed by Timothy Hatcher. Be more explicit about enabling legacy profiling. * jsc.cpp: * runtime/Executable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::hasLegacyProfiler): (JSC::JSGlobalObject::createProgramCodeBlock): (JSC::JSGlobalObject::createEvalCodeBlock): (JSC::JSGlobalObject::createModuleProgramCodeBlock): (JSC::JSGlobalObject::hasProfiler): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::supportsLegacyProfiling): (JSC::JSGlobalObject::supportsProfiling): Deleted. 2016-02-04 Keith Miller ArrayPrototype should have a destroy function https://bugs.webkit.org/show_bug.cgi?id=153847 Reviewed by Filip Pizlo. ArrayPrototype should have an destroy function as it now has a unique_ptr member that needs to be freed at the end of the object's life cycle. Also, this patch adds an option, gcAtEnd, that will cause jsc.cpp to do a garbage collection before exiting. * jsc.cpp: (runJSC): (jscmain): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::create): (JSC::ArrayPrototype::destroy): * runtime/ArrayPrototype.h: * runtime/Options.h: 2016-02-04 Filip Pizlo REGRESSION(192409): Cannot rely on add32() to zero-extend https://bugs.webkit.org/show_bug.cgi?id=153897 Unreviewed rollout of r192409. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::add32): (JSC::MacroAssemblerARM64::add64): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::add32): * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::add32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::add32): (JSC::MacroAssemblerX86Common::add8): (JSC::MacroAssemblerX86Common::branchAdd32): (JSC::MacroAssemblerX86Common::generateTest32): (JSC::MacroAssemblerX86Common::clz32AfterBsr): (JSC::MacroAssemblerX86Common::add32AndSetFlags): Deleted. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::add32): (JSC::MacroAssemblerX86_64::add64): (JSC::MacroAssemblerX86_64::branchAdd64): (JSC::MacroAssemblerX86_64::repatchCall): (JSC::MacroAssemblerX86_64::clz64AfterBsr): (JSC::MacroAssemblerX86_64::add64AndSetFlags): Deleted. 2016-02-04 Andreas Kling Remove dead ENABLE(BYTECODE_COMMENTS) cruft. Reviewed by Antti Koivisto. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted. * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::shrinkToFit): Deleted. 2016-02-04 Saam barati JSC Sampling Profiler: (host) is confusing in cases where I would expect to see JS name https://bugs.webkit.org/show_bug.cgi?id=153663 Reviewed by Geoffrey Garen. We now collect the Callee in the processed StackFrame when the Callee is a valid GC object. We later ask the Callee for it's .displayName or .name property. When we don't have a valid callee, we will still use the Executable for this information. This helps us come up with good names for frames where the Callee object is a bound function or an InternalFunction. * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::InspectorScriptProfilerAgent::addEvent): (Inspector::buildSamples): (Inspector::InspectorScriptProfilerAgent::trackingComplete): * runtime/SamplingProfiler.cpp: (JSC::reportStats): (JSC::FrameWalker::walk): (JSC::SamplingProfiler::processUnverifiedStackTraces): (JSC::SamplingProfiler::visit): (JSC::SamplingProfiler::shutdown): (JSC::SamplingProfiler::clearData): (JSC::SamplingProfiler::StackFrame::nameFromCallee): (JSC::SamplingProfiler::StackFrame::displayName): (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests): (JSC::SamplingProfiler::stackTracesAsJSON): * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame): (JSC::SamplingProfiler::StackFrame::StackFrame): * tests/stress/sampling-profiler-basic.js: (platformSupportsSamplingProfiler.nothing): (platformSupportsSamplingProfiler.top): * tests/stress/sampling-profiler-bound-function-name.js: Added. (platformSupportsSamplingProfiler.foo): (platformSupportsSamplingProfiler.bar): (platformSupportsSamplingProfiler.let.baz): (platformSupportsSamplingProfiler): * tests/stress/sampling-profiler-display-name.js: Added. (platformSupportsSamplingProfiler.foo): (platformSupportsSamplingProfiler.baz): (platformSupportsSamplingProfiler.): (platformSupportsSamplingProfiler.bar): (platformSupportsSamplingProfiler.jaz): (platformSupportsSamplingProfiler.makeFunction.let.result): (platformSupportsSamplingProfiler.makeFunction): * tests/stress/sampling-profiler-internal-function-name.js: Added. (platformSupportsSamplingProfiler.foo): (platformSupportsSamplingProfiler.bar): (platformSupportsSamplingProfiler): 2016-02-04 Chris Dumez Object.getOwnPropertyDescriptor() returns incomplete descriptor for instance properties https://bugs.webkit.org/show_bug.cgi?id=153817 Reviewed by Geoffrey Garen. Extend support for Object.getOwnPropertyDescriptor() on native bindings to instance properties (e.g. Unforgeable properties or Global object properties) so that the returned descriptor has getter / setter functions, as expected. * runtime/JSObject.cpp: (JSC::JSObject::reifyAllStaticProperties): Add method that reifies all static properties, including the custom accessors. This is similar to what is done eagerly on the prototype objects in the bindings code. (JSC::JSObject::getOwnPropertyDescriptor): getOwnPropertyDescriptor() would previously fails for custom accessors that are on the instance because getDirect() does not check the static property table and those custom accessors were not reified (We only reified all properties eagerly - including custom accessors - on prototype objects. To address this issue, we now call reifyAllStaticProperties() if the call to getDirect() fails and then call getDirect() again. This fix is however insufficient for Window properties because |this| is a JSDOMWindowShell / JSProxy in this case and getDirect() / reifyAllStaticProperties() would fail as the proxy does not actually have the properties. This issue was addressed by checking if |this| is a JSProxy and then using JSProxy::target() instead of |this| for the calls to getDirect() and for the reification. * runtime/JSObject.h: * runtime/Lookup.h: (JSC::reifyStaticProperty): (JSC::reifyStaticProperties): Move most code in reifyStaticProperties() to a separate function so the code can be shared with JSObject::reifyAllStaticProperties(). reifyStaticProperties() is currently called by the bindings on the prototype objects. 2016-02-04 Alex Christensen Fix internal Windows build https://bugs.webkit.org/show_bug.cgi?id=153886 Reviewed by Mark Lam. * JavaScriptCore.vcxproj/JavaScriptCore.proj: In r190253 I changed the directory of the headers from AppleInternal/include/JavaScriptCore to AppleInternal/include/private/JavaScriptCore. This is ok for WebCore and WebKit, but not other projects, such as CFNetwork, which expect the public API headers to be in the old location. This used to be done by a combination of copy-files.cmd and the old JavaScriptCore.proj. This change copies all the API headers, which copies everything in copy-files.cmd except APIShims.h which does not exist any more. It copies additional headers that were not copied before, but I think this is beneficial so we do not forget to add new public headers to a list of public headers to be copied in the internal build. Having extra public headers in the internal Windows build is not a problem because only internal clients use the internal Windows build. 2016-02-03 Yusuke Suzuki [JSC] Make some classes non JSDestructibleObject https://bugs.webkit.org/show_bug.cgi?id=153838 Reviewed by Geoffrey Garen. SymbolPrototype, JSMapIterator and JSSetIterator are trivially destructible. So there is no need to inherit JSDestructibleObject. * runtime/JSMapIterator.cpp: (JSC::JSMapIterator::destroy): Deleted. * runtime/JSMapIterator.h: * runtime/JSSetIterator.cpp: (JSC::JSSetIterator::destroy): Deleted. * runtime/JSSetIterator.h: * runtime/MapData.h: * runtime/SymbolPrototype.h: 2016-02-03 Yusuke Suzuki [JSC] Symbol structure has unnecessary flags https://bugs.webkit.org/show_bug.cgi?id=153840 Reviewed by Saam Barati. * runtime/Symbol.h: * tests/stress/symbol-get-own-property.js: Added. (shouldBe): 2016-02-03 Andreas Kling [iOS] Throw away linked code when navigating to a new page. Reviewed by Gavin Barraclough. Add a VM API for throwing away linked code only. * runtime/VM.cpp: (JSC::VM::deleteAllLinkedCode): * runtime/VM.h: 2016-02-03 Michael Catanzaro [GTK][EFL] Switch FTL to B3 https://bugs.webkit.org/show_bug.cgi?id=153478 Reviewed by Csaba Osztrogonác. Conditionalize code to make it possible to build FTL completely without LLVM. * CMakeLists.txt: * dfg/DFGCommon.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * ftl/FTLAbbreviatedTypes.h: * ftl/FTLFail.cpp: (JSC::FTL::fail): * ftl/FTLState.cpp: (JSC::FTL::State::State): (JSC::FTL::State::~State): 2016-02-03 Carlos Garcia Campos Unreviewed. Fix JavaScriptCore build with B3 enabled. Include for UINT_MAX. * b3/B3StackSlot.h: * b3/air/AirStackSlot.h: 2016-02-02 Caitlin Potter JSSymbolTableObject::deleteProperty() crashes deleting Symbols https://bugs.webkit.org/show_bug.cgi?id=153816 Reviewed by Darin Adler. Changes JSSymbolTableObject::deleteProperty() to check if its symbolTable() contains the property's uid() rather than publicName(). This ensures that it will not crash in the case of Symbols. * runtime/JSSymbolTableObject.cpp: (JSC::JSSymbolTableObject::deleteProperty): * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js: (testGlobalProxy): * tests/stress/regress-153816.js: Added. (deleteSymbolFromJSSymbolTableObject): 2016-02-02 Benjamin Poulain [JSC] Do not copy FP when lowering FramePointer https://bugs.webkit.org/show_bug.cgi?id=153769 Reviewed by Michael Saboff. That extra move is just wasted time. The fewer Moves we have, the happier IRC is. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::tmp): (JSC::B3::Air::LowerToAir::lower): 2016-02-02 Keith Miller DFG, FTL, B3, and Air should all have a unique option for printing their graphs https://bugs.webkit.org/show_bug.cgi?id=153815 Reviewed by Benjamin Poulain. This patch adds a new printing option for each of the DFG/FTL compilation phases. * b3/B3Common.cpp: (JSC::B3::shouldDumpIR): (JSC::B3::shouldDumpIRAtEachPhase): * b3/B3Common.h: * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3PhaseScope.cpp: (JSC::B3::PhaseScope::PhaseScope): * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): * b3/air/AirPhaseScope.cpp: (JSC::B3::Air::PhaseScope::PhaseScope): * dfg/DFGCFAPhase.cpp: (JSC::DFG::CFAPhase::run): * dfg/DFGCommon.h: (JSC::DFG::shouldDumpGraphAtEachPhase): * dfg/DFGPhase.cpp: (JSC::DFG::Phase::beginPhase): * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/Options.h: 2016-02-02 Caitlin Potter [JSC] make Object.getOwnPropertyDescriptors() work with non-JSObject types https://bugs.webkit.org/show_bug.cgi?id=153814 Reviewed by Yusuke Suzuki. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorGetOwnPropertyDescriptors): * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js: (testGlobalProxy): 2016-02-02 Aakash Jain Remove references to CallFrameInlines.h https://bugs.webkit.org/show_bug.cgi?id=153810 Reviewed by Mark Lam. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: 2016-02-02 Caitlin Potter [JSC] Implement Object.getOwnPropertyDescriptors() proposal https://bugs.webkit.org/show_bug.cgi?id=153799 Reviewed by Darin Adler. Implements the Object.getOwnPropertyDescriptors() proposal, which reached Stage 3 in the TC39 process in January 2016. https://github.com/tc39/proposal-object-getownpropertydescriptors The method extracts a set of property descriptor objects, which can be safely used via `Object.create()`. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorGetOwnPropertyDescriptors): 2016-02-02 Filip Pizlo B3 should be able to compile trivial self-loops https://bugs.webkit.org/show_bug.cgi?id=153802 rdar://problem/24465632 Reviewed by Michael Saboff. Tail-duplicating a self-loop would mean doing a kind of loop unrolling. It wouldn't be profitable even if it did work. It turns out that it doesn't work, because we edit the target block before reading the source block, which breaks if the target and source block are the same. This disables tail duplication of self-loops, adds a test, and adds better validation for this issue. * b3/B3DuplicateTails.cpp: * b3/B3Procedure.cpp: (JSC::B3::Procedure::resetReachability): * b3/testb3.cpp: (JSC::B3::testComputeDivisionMagic): (JSC::B3::testTrivialInfiniteLoop): (JSC::B3::zero): (JSC::B3::run): 2016-02-02 Saam barati [ES6] bound functions .name property should be "bound " + the target function's name https://bugs.webkit.org/show_bug.cgi?id=153796 Reviewed by Mark Lam. See http://tc39.github.io/ecma262/#sec-function.prototype.bind for details. What the spec says: ``` function foo() { } foo.bind(null).name === "bound foo" (function bar() { }).bind(null).name === "bound bar" ``` * runtime/FunctionPrototype.cpp: (JSC::functionProtoFuncToString): * runtime/JSBoundFunction.cpp: (JSC::hasInstanceBoundFunction): (JSC::JSBoundFunction::create): (JSC::JSBoundFunction::visitChildren): (JSC::JSBoundFunction::toStringName): * runtime/JSBoundFunction.h: (JSC::JSBoundFunction::boundThis): (JSC::JSBoundFunction::boundArgs): (JSC::JSBoundFunction::createStructure): * tests/es6.yaml: 2016-02-02 Filip Pizlo Get rid of anonymous stack slots https://bugs.webkit.org/show_bug.cgi?id=151128 Reviewed by Mark Lam. When I first designed stack slots, the idea was that an "anonymous" stack slot was one that behaved exactly like a C variable: if it never escaped, it would not need to get stack space for the entire lifetime of the function - it could get any slab of stack so long as it didn't interfere with other stack slots that would be live at the same time. The reason I called them "anonymous" is that external code could not get its address. This felt like it gave the stack slot anonymity. But it was never a good name for this concept. Then I had the register allocator lower temporaries to anonymous stack slots when it spilled them. Spilling became the sole client of anonymous stack slots. Then I realized that there was an aspect of how spill slots work that make them want slightly different semantics than a normal C variable. A C variable is a proper memory location - you could do a store to only some bytes in the variable, and it's reasonable to expect that this will not destroy the other bytes in the variable. But that means that to compute their liveness, you have to do something like a per-byte liveness. That's overkill for spill slots. You want any store to the spill slot to kill the whole slot even if it writes to just part of the slot. This matches how temporaries work. So rather than implement per-byte liveness, I decided to change the semantics of anonymous stack slots to make them work like how I wanted spill slots to work. This was quite dirty, and put B3 in the awkward situation that B3's anonymous stack slots behaved like spill slots. But it was OK since nobody used anonymous stack slots in B3. Then I added tail duplication, which required having a mechanism for introducing non-SSA variables in B3. I decided to use anonymous stack slots for this purpose. All of a sudden this all felt like it made sense: anonymous stack slots were just like variables! Hooray for the amazing foresight of anonymous stack slots! But then I realized that this was all very bad. We want B3 to be able to optimize Store and Load operations by reasoning about how they affect bytes in memory. For example, if you do a Load of a 64-bit value, and then you modify just the low 32 bits of that value, and then you do a 64-bit store back to the same location, then it would be better to transform this into 32-bit operations. We don't do this optimization yet, but it's the kind of thing that we want B3 to be able to do. To do it, we need Store to mean that it only affects N bytes starting at the pointer, where N is the size of the thing being stored. But that's not what Store means for anonymous stack slots. For anonymous slots, storing to any byte in the slot clobbers all bytes in the slot. We were never clear if you need to store directly to an anonymous slot to get this behavior, or if any pointer that points to an anoymous slot must exhibit this behavior when stored to. Neither kinds of semantics make sense to me. This change fixes the problem by eradicating anonymous stack slots. In B3, they are replaced with Variables. In Air, they are replaced with a different stack slot kind, called Spill. There is no such thing as stack slot kinds in B3 anymore, all B3 stack slots are locked. In Air, there is still the concept of stack slot kind - Locked or Spill. B3 Variables are awesome. They are exactly what they seem to be. They have a type. They are declared at the top level in the Procedure. You can access them with new opcodes, Get and Set. This greatly simplifies demoting SSA values to variables and promoting them back to SSA. I even made the instruction selector do the right things for variables, which means that introducing variables won't hurt instruction selection (there will be extra moves, but IRC will kill them). It's great to have non-SSA variables as an explicit concept in IR because it means that you don't have to do any magic to use them - they Just Work. Air spill slots behave almost like anonymous stack slots, with one exception: you cannot escape them. We validate this by making it illegal to UseAddr on a spill slot. This removes the need to answer awkward questions like: does a 32-bit Def on a pointer that may point to a 64-bit spill slot do anything to the 32 bits above the pointer? Does it write zero to it? Does it write zero to it just when the pointer actually points to a spill slot or always? These are silly questions, and we don't have to answer them because the only way to refer to a spill slot is directly. No escaping means no aliasing. This doesn't affect performance. It just makes the compiler more fun to work with by removing some cognitive dissonance. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3ArgumentRegValue.h: * b3/B3CCallValue.h: * b3/B3CheckValue.cpp: (JSC::B3::CheckValue::cloneImpl): (JSC::B3::CheckValue::CheckValue): * b3/B3CheckValue.h: * b3/B3Const32Value.h: * b3/B3Const64Value.h: * b3/B3ConstDoubleValue.h: * b3/B3ConstFloatValue.h: * b3/B3ConstPtrValue.h: (JSC::B3::ConstPtrValue::ConstPtrValue): * b3/B3ControlValue.cpp: (JSC::B3::ControlValue::convertToJump): (JSC::B3::ControlValue::convertToOops): (JSC::B3::ControlValue::dumpMeta): * b3/B3ControlValue.h: * b3/B3Effects.cpp: (JSC::B3::Effects::interferes): (JSC::B3::Effects::dump): * b3/B3Effects.h: (JSC::B3::Effects::mustExecute): * b3/B3EliminateCommonSubexpressions.cpp: * b3/B3FixSSA.cpp: (JSC::B3::demoteValues): (JSC::B3::fixSSA): * b3/B3FixSSA.h: * b3/B3IndexMap.h: (JSC::B3::IndexMap::resize): (JSC::B3::IndexMap::clear): (JSC::B3::IndexMap::size): (JSC::B3::IndexMap::operator[]): * b3/B3IndexSet.h: (JSC::B3::IndexSet::contains): (JSC::B3::IndexSet::size): (JSC::B3::IndexSet::isEmpty): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::run): (JSC::B3::Air::LowerToAir::lower): * b3/B3MemoryValue.h: * b3/B3Opcode.cpp: (WTF::printInternal): * b3/B3Opcode.h: * b3/B3PatchpointValue.cpp: (JSC::B3::PatchpointValue::cloneImpl): (JSC::B3::PatchpointValue::PatchpointValue): * b3/B3PatchpointValue.h: * b3/B3Procedure.cpp: (JSC::B3::Procedure::Procedure): (JSC::B3::Procedure::addBlock): (JSC::B3::Procedure::addStackSlot): (JSC::B3::Procedure::addVariable): (JSC::B3::Procedure::clone): (JSC::B3::Procedure::addIntConstant): (JSC::B3::Procedure::dump): (JSC::B3::Procedure::deleteStackSlot): (JSC::B3::Procedure::deleteVariable): (JSC::B3::Procedure::deleteValue): (JSC::B3::Procedure::deleteOrphans): (JSC::B3::Procedure::calleeSaveRegisters): (JSC::B3::Procedure::addValueImpl): (JSC::B3::Procedure::setBlockOrderImpl): (JSC::B3::Procedure::addAnonymousStackSlot): Deleted. (JSC::B3::Procedure::addStackSlotIndex): Deleted. (JSC::B3::Procedure::addValueIndex): Deleted. * b3/B3Procedure.h: (JSC::B3::Procedure::setBlockOrder): (JSC::B3::Procedure::stackSlots): (JSC::B3::Procedure::variables): (JSC::B3::Procedure::values): (JSC::B3::Procedure::StackSlotsCollection::StackSlotsCollection): Deleted. (JSC::B3::Procedure::StackSlotsCollection::size): Deleted. (JSC::B3::Procedure::StackSlotsCollection::at): Deleted. (JSC::B3::Procedure::StackSlotsCollection::operator[]): Deleted. (JSC::B3::Procedure::StackSlotsCollection::iterator::iterator): Deleted. (JSC::B3::Procedure::StackSlotsCollection::iterator::operator*): Deleted. (JSC::B3::Procedure::StackSlotsCollection::iterator::operator++): Deleted. (JSC::B3::Procedure::StackSlotsCollection::iterator::operator==): Deleted. (JSC::B3::Procedure::StackSlotsCollection::iterator::operator!=): Deleted. (JSC::B3::Procedure::StackSlotsCollection::iterator::findNext): Deleted. (JSC::B3::Procedure::StackSlotsCollection::begin): Deleted. (JSC::B3::Procedure::StackSlotsCollection::end): Deleted. (JSC::B3::Procedure::ValuesCollection::ValuesCollection): Deleted. (JSC::B3::Procedure::ValuesCollection::iterator::iterator): Deleted. (JSC::B3::Procedure::ValuesCollection::iterator::operator*): Deleted. (JSC::B3::Procedure::ValuesCollection::iterator::operator++): Deleted. (JSC::B3::Procedure::ValuesCollection::iterator::operator==): Deleted. (JSC::B3::Procedure::ValuesCollection::iterator::operator!=): Deleted. (JSC::B3::Procedure::ValuesCollection::iterator::findNext): Deleted. (JSC::B3::Procedure::ValuesCollection::begin): Deleted. (JSC::B3::Procedure::ValuesCollection::end): Deleted. (JSC::B3::Procedure::ValuesCollection::size): Deleted. (JSC::B3::Procedure::ValuesCollection::at): Deleted. (JSC::B3::Procedure::ValuesCollection::operator[]): Deleted. * b3/B3ProcedureInlines.h: (JSC::B3::Procedure::add): * b3/B3ReduceStrength.cpp: * b3/B3SlotBaseValue.h: * b3/B3SparseCollection.h: Added. (JSC::B3::SparseCollection::SparseCollection): (JSC::B3::SparseCollection::add): (JSC::B3::SparseCollection::addNew): (JSC::B3::SparseCollection::remove): (JSC::B3::SparseCollection::size): (JSC::B3::SparseCollection::isEmpty): (JSC::B3::SparseCollection::at): (JSC::B3::SparseCollection::operator[]): (JSC::B3::SparseCollection::iterator::iterator): (JSC::B3::SparseCollection::iterator::operator*): (JSC::B3::SparseCollection::iterator::operator++): (JSC::B3::SparseCollection::iterator::operator==): (JSC::B3::SparseCollection::iterator::operator!=): (JSC::B3::SparseCollection::iterator::findNext): (JSC::B3::SparseCollection::begin): (JSC::B3::SparseCollection::end): * b3/B3StackSlot.cpp: (JSC::B3::StackSlot::deepDump): (JSC::B3::StackSlot::StackSlot): * b3/B3StackSlot.h: (JSC::B3::StackSlot::byteSize): (JSC::B3::StackSlot::index): (JSC::B3::StackSlot::setOffsetFromFP): (JSC::B3::StackSlot::kind): Deleted. (JSC::B3::StackSlot::isLocked): Deleted. * b3/B3StackSlotKind.cpp: Removed. * b3/B3StackSlotKind.h: Removed. * b3/B3StackmapValue.cpp: (JSC::B3::StackmapValue::dumpMeta): (JSC::B3::StackmapValue::StackmapValue): * b3/B3StackmapValue.h: * b3/B3SwitchValue.cpp: (JSC::B3::SwitchValue::cloneImpl): (JSC::B3::SwitchValue::SwitchValue): * b3/B3SwitchValue.h: * b3/B3UpsilonValue.h: * b3/B3Validate.cpp: * b3/B3Value.cpp: (JSC::B3::Value::replaceWithIdentity): (JSC::B3::Value::replaceWithNop): (JSC::B3::Value::replaceWithPhi): (JSC::B3::Value::dump): (JSC::B3::Value::effects): (JSC::B3::Value::checkOpcode): * b3/B3Value.h: * b3/B3Variable.cpp: Added. (JSC::B3::Variable::~Variable): (JSC::B3::Variable::dump): (JSC::B3::Variable::deepDump): (JSC::B3::Variable::Variable): * b3/B3Variable.h: Added. (JSC::B3::Variable::type): (JSC::B3::Variable::index): (JSC::B3::DeepVariableDump::DeepVariableDump): (JSC::B3::DeepVariableDump::dump): (JSC::B3::deepDump): * b3/B3VariableValue.cpp: Added. (JSC::B3::VariableValue::~VariableValue): (JSC::B3::VariableValue::dumpMeta): (JSC::B3::VariableValue::cloneImpl): (JSC::B3::VariableValue::VariableValue): * b3/B3VariableValue.h: Added. * b3/air/AirAllocateStack.cpp: (JSC::B3::Air::allocateStack): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::addStackSlot): (JSC::B3::Air::Code::addSpecial): (JSC::B3::Air::Code::cCallSpecial): * b3/air/AirCode.h: (JSC::B3::Air::Code::begin): (JSC::B3::Air::Code::end): (JSC::B3::Air::Code::stackSlots): (JSC::B3::Air::Code::specials): (JSC::B3::Air::Code::forAllTmps): (JSC::B3::Air::Code::StackSlotsCollection::StackSlotsCollection): Deleted. (JSC::B3::Air::Code::StackSlotsCollection::size): Deleted. (JSC::B3::Air::Code::StackSlotsCollection::at): Deleted. (JSC::B3::Air::Code::StackSlotsCollection::operator[]): Deleted. (JSC::B3::Air::Code::StackSlotsCollection::iterator::iterator): Deleted. (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator*): Deleted. (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator++): Deleted. (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator==): Deleted. (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator!=): Deleted. (JSC::B3::Air::Code::StackSlotsCollection::begin): Deleted. (JSC::B3::Air::Code::StackSlotsCollection::end): Deleted. (JSC::B3::Air::Code::SpecialsCollection::SpecialsCollection): Deleted. (JSC::B3::Air::Code::SpecialsCollection::size): Deleted. (JSC::B3::Air::Code::SpecialsCollection::at): Deleted. (JSC::B3::Air::Code::SpecialsCollection::operator[]): Deleted. (JSC::B3::Air::Code::SpecialsCollection::iterator::iterator): Deleted. (JSC::B3::Air::Code::SpecialsCollection::iterator::operator*): Deleted. (JSC::B3::Air::Code::SpecialsCollection::iterator::operator++): Deleted. (JSC::B3::Air::Code::SpecialsCollection::iterator::operator==): Deleted. (JSC::B3::Air::Code::SpecialsCollection::iterator::operator!=): Deleted. (JSC::B3::Air::Code::SpecialsCollection::begin): Deleted. (JSC::B3::Air::Code::SpecialsCollection::end): Deleted. * b3/air/AirFixObviousSpills.cpp: * b3/air/AirInstInlines.h: * b3/air/AirIteratedRegisterCoalescing.cpp: * b3/air/AirLiveness.h: * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirSpecial.cpp: (JSC::B3::Air::Special::Special): * b3/air/AirSpecial.h: * b3/air/AirSpillEverything.cpp: (JSC::B3::Air::spillEverything): * b3/air/AirStackSlot.cpp: (JSC::B3::Air::StackSlot::dump): (JSC::B3::Air::StackSlot::deepDump): (JSC::B3::Air::StackSlot::StackSlot): * b3/air/AirStackSlot.h: (JSC::B3::Air::StackSlot::byteSize): (JSC::B3::Air::StackSlot::kind): (JSC::B3::Air::StackSlot::isLocked): (JSC::B3::Air::StackSlot::isSpill): (JSC::B3::Air::StackSlot::index): (JSC::B3::Air::StackSlot::ensureSize): * b3/air/AirStackSlotKind.cpp: Copied from Source/JavaScriptCore/b3/B3StackSlotKind.cpp. (WTF::printInternal): * b3/air/AirStackSlotKind.h: Copied from Source/JavaScriptCore/b3/B3StackSlotKind.h. * b3/air/opcode_generator.rb: * b3/air/testair.cpp: (JSC::B3::Air::testShuffleBroadcastAllRegs): (JSC::B3::Air::testShuffleShiftAllRegs): (JSC::B3::Air::testShuffleRotateAllRegs): * b3/testb3.cpp: (JSC::B3::testStackSlot): (JSC::B3::testStoreLoadStackSlot): * ftl/FTLB3Output.cpp: (JSC::FTL::Output::lockedStackSlot): (JSC::FTL::Output::neg): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint): 2016-02-02 Yusuke Suzuki [JSC] Introduce BytecodeIntrinsic constant rep like @undefined https://bugs.webkit.org/show_bug.cgi?id=153737 Reviewed by Darin Adler. This patch enhances existing BytecodeIntrinsic mechanism to accept `@xxx` form, that will be used to represent bytecode intrinsic constants. After this change, we can use 2 forms for bytecode intrinsics. (1) Function form (like, @toString(value)) and (2) Constant form (like @undefined). Bytecode intrinsic constants allow us to easily expose constant values from C++ world. For example, we can expose ArrayIterationKind flags to JS world without using private global variables. Exposed constant values are loaded from bytecodes directly through constant registers. While previously we expose them through private global variables, bytecode intrinsic constants can be loaded directly from CodeBlock. And later, it will become JSConstant in DFG. And by using this mechanism, we implement several constants. @undefined, @arrayIterationKindKeyValue etc. * builtins/ArrayConstructor.js: (from): * builtins/ArrayIteratorPrototype.js: (next): * builtins/ArrayPrototype.js: (reduce): (reduceRight): (every): (forEach): (filter): (map): (some): (fill): (find): (findIndex): (includes): (sort.compactSparse): (sort.compactSlow): (sort.compact): (sort): (copyWithin): * builtins/DatePrototype.js: (toLocaleString.toDateTimeOptionsAnyAll): (toLocaleString): (toLocaleDateString.toDateTimeOptionsDateDate): (toLocaleDateString): (toLocaleTimeString.toDateTimeOptionsTimeTime): (toLocaleTimeString): * builtins/GeneratorPrototype.js: (generatorResume): * builtins/GlobalObject.js: (isDictionary): * builtins/InternalPromiseConstructor.js: (internalAll.newResolveElement): (internalAll): * builtins/IteratorPrototype.js: (symbolIteratorGetter): (symbolIterator): Deleted. * builtins/MapPrototype.js: (forEach): * builtins/ModuleLoaderObject.js: (newRegistryEntry): (forceFulfillPromise): (commitInstantiated): (requestFetch): (requestTranslate): (requestInstantiate): (requestLink): (provide): * builtins/PromiseConstructor.js: (all.newResolveElement): (all): (race): (reject): (resolve): * builtins/PromiseOperations.js: (newPromiseCapability.executor): (newPromiseCapability): (rejectPromise): (fulfillPromise): (createResolvingFunctions.resolve): (createResolvingFunctions.reject): (createResolvingFunctions): (promiseReactionJob): (promiseResolveThenableJob): (initializePromise): * builtins/PromisePrototype.js: (catch): (then): * builtins/SetPrototype.js: (forEach): * builtins/StringConstructor.js: (raw): * builtins/StringIteratorPrototype.js: (next): * builtins/StringPrototype.js: (localeCompare): * builtins/TypedArrayConstructor.js: (of): (from): * builtins/TypedArrayPrototype.js: (every): (find): (findIndex): (forEach): (some): (reduce): (reduceRight): (map): (filter): * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): (JSC::BytecodeIntrinsicRegistry::lookup): * bytecode/BytecodeIntrinsicRegistry.h: * bytecompiler/NodesCodegen.cpp: * parser/ASTBuilder.h: (JSC::ASTBuilder::createResolve): (JSC::ASTBuilder::makeFunctionCallNode): * parser/NodeConstructors.h: (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode): * parser/Nodes.h: (JSC::ExpressionNode::isBytecodeIntrinsicNode): (JSC::BytecodeIntrinsicNode::type): (JSC::BytecodeIntrinsicNode::emitter): * parser/Parser.cpp: (JSC::Parser::parseProperty): (JSC::Parser::parsePrimaryExpression): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createResolve): * runtime/CommonIdentifiers.cpp: (JSC::CommonIdentifiers::CommonIdentifiers): Deleted. * runtime/CommonIdentifiers.h: (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry): Deleted. * runtime/IteratorPrototype.cpp: (JSC::IteratorPrototype::finishCreation): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): Deleted. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: (JSC::VM::bytecodeIntrinsicRegistry): 2016-02-02 Per Arne Vollan [B3][Win64] Compile fixes. https://bugs.webkit.org/show_bug.cgi?id=153605 Reviewed by Filip Pizlo. Fix remaining compile errors on Win64. * CMakeLists.txt: * b3/B3CFG.h: (JSC::B3::CFG::newMap): * ftl/FTLJITCode.h: 2016-02-01 Chris Dumez object.__lookupGetter__() / object.__lookupSetter__() does not work for native bindings https://bugs.webkit.org/show_bug.cgi?id=153765 Reviewed by Oliver Hunt. Add support for CustomAccessor slots to objectProtoFuncLookupGetter() and objectProtoFuncLookupSetter() by return getOwnPropertyDescriptor().get / set. getOwnPropertyDescriptor() now correctly deals with CustomAccessors since r196001. * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncLookupGetter): (JSC::objectProtoFuncLookupSetter): 2016-02-01 Chris Dumez Native Bindings Descriptors are Incomplete https://bugs.webkit.org/show_bug.cgi?id=140575 Reviewed by Oliver Hunt. This patch is based on initial work by Joe Pecoraro and Matthew Mirman. This patch was initially rolled out for breaking chromeexperiments.com, presumably because our IDL attributes were not marked as [configurable] at the time. However, since r190104, our IDL attributes are now configurable. Based on local testing, chromeexperiments.com seems to be working fine now. * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/InjectedScriptSource.js: (endsWith): (InjectedScript.prototype.processProperties): * runtime/JSBoundSlotBaseFunction.cpp: Added. (JSC::boundSlotBaseFunctionCall): (JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction): (JSC::JSBoundSlotBaseFunction::create): (JSC::JSBoundSlotBaseFunction::visitChildren): (JSC::JSBoundSlotBaseFunction::finishCreation): * runtime/JSBoundSlotBaseFunction.h: Added. (JSC::JSBoundSlotBaseFunction::createStructure): (JSC::JSBoundSlotBaseFunction::boundSlotBase): (JSC::JSBoundSlotBaseFunction::customGetterSetter): (JSC::JSBoundSlotBaseFunction::isSetter): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): * runtime/JSObject.cpp: (JSC::getBoundSlotBaseFunctionForGetterSetter): (JSC::JSObject::getOwnPropertyDescriptor): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2016-02-01 Joseph Pecoraro Web Inspector: High Level Memory Overview Instrument https://bugs.webkit.org/show_bug.cgi?id=153516 Reviewed by Brian Burg. * CMakeLists.txt: * Configurations/FeatureDefines.xcconfig: * DerivedSources.make: * inspector/protocol/Memory.json: Added. * inspector/scripts/codegen/generator.py: New Memory domain guarded by ENABLE(RESOURCE_USAGE). This feature flag was already used in WebCore. 2016-02-01 Benjamin Poulain [JSC] IRC can coalesce the frame pointer with a Tmp that is modified https://bugs.webkit.org/show_bug.cgi?id=153694 Reviewed by Filip Pizlo. Let's say we have: Move(FP, Tmp1) Add64(#1, Tmp1) If we were to coalesce the Move, we would modify the frame pointer. Well, that's exactly what was happening with IRC. Since the epilogue is not know to Air before IRC, the liveness analysis never discovers that FP is live when Tmp1 is UseDef by Add64. Adding FP would a be a problem anyway for a bunch of reasons. I tried two ways to prevent IRC to override IRC: 1) Add an interference edge with FP for all non-duplication Defs. 2) Let coalesce() know about FP and constraint any coalescing with a re-Def. The two are within margin of error for performance. The second one was considerably more complicated. This patch implements the first one. Some extra note: -It is very important to not increment the degree of a Tmp when making it interfere with FP. FP is not a valid color, it is not counted in the "K" colors considered for coloring. Increasing the degree with the edge to FP would make every stage pessimistic since there is an extra degree that can never be removed. -I put "interferenceEdges" and "adjacencyList" in an inconsistent state. This is intentional, "interferenceEdges" is used to test the existence of an edge, "adjacencyList" is used to go over all the edges. In this case, we don't want the edge with FP to be considered when pruning the graph. * b3/air/AirIteratedRegisterCoalescing.cpp: One branch could be transformed into an assertion: TmpLiveness is type specific now. * b3/testb3.cpp: (JSC::B3::testOverrideFramePointer): (JSC::B3::run): 2016-02-01 Csaba Osztrogonác Unreviewed speculative buildfix. * dfg/DFGCommon.h: FTL_USES_B3 should be false if FTL JIT is disabled. 2016-01-31 Dan Bernstein [Cocoa] Remove unused definition of HAVE_HEADER_DETECTION_H https://bugs.webkit.org/show_bug.cgi?id=153729 Reviewed by Sam Weinig. After r141700, HAVE_HEADER_DETECTION_H is no longer used. * Configurations/Base.xcconfig: 2016-01-30 Filip Pizlo B3->Air lowering should use MoveFloat more https://bugs.webkit.org/show_bug.cgi?id=153714 Reviewed by Sam Weinig. This is a very minor and benign bug. It just means that we will use the more canonical MoveFloat instruction when moving floats, rather than using MoveDouble. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::relaxedMoveForType): 2016-01-31 Yusuke Suzuki Should not predict OtherObj for ToThis with primitive types under strict mode https://bugs.webkit.org/show_bug.cgi?id=153544 Reviewed by Filip Pizlo. Currently, ToThis predicates OtherObj for primitive values. But it's not true in strict mode. In strict mode, ToThis does nothing on primitive values. In this patch, we 1. fix prediction. Handles primitive types in strict mode. And we also handles StringObject. 2. convert it to Identity if the argument should be predicted as primitive types. This optimization is important to implement Primitive.prototype.methods[1]. Otherwise, we always got BadType OSR exits. [1]: https://bugs.webkit.org/show_bug.cgi?id=143889 * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupToThis): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * tests/stress/to-this-boolean.js: Added. (Boolean.prototype.negate): (Boolean.prototype.negate2): * tests/stress/to-this-double.js: Added. (Number.prototype.negate): * tests/stress/to-this-int32.js: Added. (Number.prototype.negate): * tests/stress/to-this-int52.js: Added. (Number.prototype.negate): * tests/stress/to-this-number.js: Added. (Number.prototype.negate): * tests/stress/to-this-string.js: Added. (String.prototype.prefix): (String.prototype.first): (String.prototype.second): * tests/stress/to-this-symbol.js: Added. (Symbol.prototype.identity): (Symbol.prototype.identity2): 2016-01-31 Guillaume Emont [mips] don't save to a callee saved register too early https://bugs.webkit.org/show_bug.cgi?id=153463 If we save $gp to $s4 in pichdr, then in some cases, we were overwriting $s4 before LLInt's pushCalleeSaves() is called (as pichdr is at the very beginning of a function). Now we save $gp to $s4 at the end of pushCalleeSaves(). Reviewed by Michael Saboff. * offlineasm/mips.rb: * llint/LowLevelInterpreter.asm: Move the saving of $gp to $s4 from pichdr to pushCalleeSaves(). Take the opportunity to only save $s4 as we never use the other callee saved registers. 2016-01-30 Commit Queue Unreviewed, rolling out r195799 and r195828. https://bugs.webkit.org/show_bug.cgi?id=153722 Caused assertion failures, severely affecting EWS (Requested by ap on #webkit). Reverted changesets: "Web Inspector: InspectorTimelineAgent doesn't need to recompile functions because it now uses the sampling profiler" https://bugs.webkit.org/show_bug.cgi?id=153500 http://trac.webkit.org/changeset/195799 "Attempt to fix the Windows build after r195799" http://trac.webkit.org/changeset/195828 2016-01-30 Yusuke Suzuki [B3] JetStream/quicksort.c fails/hangs on Linux with GCC https://bugs.webkit.org/show_bug.cgi?id=153647 Reviewed by Filip Pizlo. In B3ComputeDivisionMagic, we accidentally perform sub, add operation onto signed integer. (In this case, int32_t) But integer overflow is undefined behavior in C![1][2] As a result, in GCC 4.9 release build, computeDivisionMagic(2) returns unexpected value. `divisor = 2` `d = 2` `signedMin = INT32_MIN = -2147483647 (-0x7fffffff)` `t = signedMin` `anc = t - 1 - (t % ad)` Oops, we performed overflow operation! So, `anc` value becomes undefined. In this patch, we first cast all the operated values to unsigned one. Reading the code, there are no operations that depends on signedness. (For example, we used aboveEqual like unsigned operations for comparison.) [1]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html [2]: http://dl.acm.org/citation.cfm?id=2522728 * b3/B3ComputeDivisionMagic.h: (JSC::B3::computeDivisionMagic): * b3/testb3.cpp: (JSC::B3::testComputeDivisionMagic): (JSC::B3::run): 2016-01-30 Andreas Kling Shrink Heap::m_executables after cleaning it. Reviewed by Darin Adler. The Heap::m_executables Vector was never shrunk down, despite sometimes getting pretty huge (~500kB in my longest-running WebContent process.) After GC has finished pruning unmarked Executables, shrink the Vector. * heap/Heap.cpp: (JSC::Heap::clearUnmarkedExecutables): 2016-01-29 Ada Chan Enable VIDEO_PRESENTATION_MODE only in Debug and Release builds on Mac https://bugs.webkit.org/show_bug.cgi?id=153665 Reviewed by Dan Bernstein. * Configurations/FeatureDefines.xcconfig: 2016-01-30 Yusuke Suzuki [B3] REGRESSION(r195882): Should break early after modConstant replaceWithNewValue succeeds https://bugs.webkit.org/show_bug.cgi?id=153711 Reviewed by Filip Pizlo. Should break after modConstant replaceWithNewValue succeeds. m_value is already replaced with Identity if modConstant succeeds. So it does not have any children. m_value->child(1) breaks testb3. * b3/B3ReduceStrength.cpp: 2016-01-30 Yusuke Suzuki Enable SamplingProfiler on POSIX environment https://bugs.webkit.org/show_bug.cgi?id=153584 Reviewed by Michael Saboff. In this patch, we implement suspend and resume mechanizm for POSIX threads. And with GLIBC, we can retrieve registers from it. We take the following strategy. Suspend side. 1. install sigaction to the threads. 2. in the profiler (suspend / resume callers), emit signal with pthread_kill and wait with POSIX semaphore. 3. in the signal handler, up the POSIX semaphore. Use sem_post because it is the async-signal-safe function in POSIX. 4. in the signal handler, perform sigsuspend to stop the thread until being resumed. 5. in the profiler, we can be waken up from the semaphore because (3) ups. Resume side. 1. in the profiler, emit signal and wait on the semaphore. 2. in the signal handler, it is waken up from the sigsuspend. 3. in the signal handler, up the semaphore. 4. in the profiler, the profiler is waken up from the semaphore. It is ensured that the given thread is resumed by the signal. * heap/MachineStackMarker.cpp: (pthreadSignalHandlerSuspendResume): (JSC::MachineThreads::Thread::Thread): (JSC::MachineThreads::Thread::~Thread): (JSC::MachineThreads::Thread::suspend): (JSC::MachineThreads::Thread::resume): (JSC::MachineThreads::Thread::getRegisters): (JSC::MachineThreads::Thread::Registers::stackPointer): (JSC::MachineThreads::Thread::Registers::framePointer): (JSC::MachineThreads::Thread::Registers::instructionPointer): (JSC::MachineThreads::Thread::Registers::llintPC): (JSC::MachineThreads::Thread::freeRegisters): * heap/MachineStackMarker.h: * runtime/SamplingProfiler.cpp: (JSC::reportStats): * tests/stress/call-varargs-from-inlined-code-with-odd-number-of-arguments.js: * tests/stress/call-varargs-from-inlined-code.js: * tests/stress/v8-earley-boyer-strict.js: 2016-01-29 Filip Pizlo B3 should reduce Mod(value, constant) to Div and Mul so that our Div optimizations can do things https://bugs.webkit.org/show_bug.cgi?id=153693 Reviewed by Saam Barati. The most efficient way to handle Mod(value, constant) is to reduce it to Sub(value, Mul(Div(value, constant), constant)) and then let the Div optimizations do their thing. In the future we could add special handling of Mod(value, 1 << constant), but it's not obvious that this would produce better code than reducing through Div, if we also make sure that we have great optimizations for Mul and Div. * b3/B3ReduceStrength.cpp: 2016-01-29 Keith Miller Array.prototype native functions should use Symbol.species to construct the result https://bugs.webkit.org/show_bug.cgi?id=153660 Reviewed by Saam Barati. This patch adds support for Symbol.species in the Array.prototype native functions. We make an optimization to avoid regressions on some benchmarks by using an adaptive watchpoint to check if Array.prototype.constructor is ever changed. * runtime/ArrayPrototype.cpp: (JSC::putLength): (JSC::setLength): (JSC::speciesConstructArray): (JSC::arrayProtoFuncConcat): (JSC::arrayProtoFuncSlice): (JSC::arrayProtoFuncSplice): (JSC::ArrayPrototype::setConstructor): (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint): (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire): * runtime/ArrayPrototype.h: (JSC::ArrayPrototype::didChangeConstructorProperty): * runtime/ConstructData.cpp: (JSC::construct): * runtime/ConstructData.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * tests/es6.yaml: * tests/stress/array-species-functions.js: Added. (Symbol.species): (funcThrows): (test.species): (test): 2016-01-29 Filip Pizlo CallLinkStatus should trust BadCell exit sites whenever there is no stub https://bugs.webkit.org/show_bug.cgi?id=153691 Reviewed by Benjamin Poulain. This fixes a regression in our treatment of inlining failure exit sites when deciding if we should inline a call. A long time ago, a BadCell exit site would ensure that a CallLinkStatus returned takesSlowPath. But then we added closure calls. A BadCell exit site might just mean that we should do closure call inlining. We added a BadExecutable exit site to indicate that even closure call inlining had failed. BadCell would no longer force CallLinkStatus to return takesSlowPath, but BadExecutable would stuff do so. But then we unified the IR for checking functions and executables, and the DFG stopped using the BadExecutable exit kind. Probably this change disabled our ability to use exit site counting for deciding when to takesSlowPath. But this isn't necessarily a disaster, since any time you exited in this way, you'd be taken to a baseline call inline cache, and that inline cache would record the slow path. But then we introduced polymorphic call inlining. Polymorphic call inlining means that call unlinking, like when one of the callees is optimized, will reset the stub. We also made it so that the stub is like a gate for the slow path count. A clear inline cache must first cause the creation of a stub and then cause it to overflow before the slow path is counted. So, if the DFG or FTL exits on a cell check associated with a particular callsite being speculatively inlined, then it's possible that nobody will know about the exit because: - The exit kind is BadCell but CallLinkStatus needs BadExecutable to disable inlining. - Between when we tiered up to the DFG (or FTL) and when the exit happened, one of the callees was tiered up, causing the baseline CallLinkInfo to be unlinked. Therefore, after the exit, the inline cache is in a reset state and will not count the call as taking slow path. The challenge when dealing with this is that often, we will have an super early compilation of a minimorphic call site before we have seen all of its small set of callees. For example we may have seen only one of two possible callees. That early compilation will OSR exit, and in trunk, will be recompiled with bimorphic speculative inlining. That's a pretty good outcome. Basically, we are trusting that if during the time that the function has been running prior to a given compilation, a callsite has only seen a small number of callees, then it's safe to assume that it won't see another one anytime soon. So, simply forcing the CallLinkStatus to set takesSlowPath any time there was a BadCell exit would hurt our performance in some cases, because trunk prior to this change would have their final compilation use speculative inlining, and this change would make guarded inlining instead. The compromise that I came up with relies on the fact that a CallLinkInfo must be reset quite frequently for it to routinely happen in between tier-up to DFG (or FTL) and an exit. So, most likely, such a CallLinkInfo will also show up as being clear when the CallLinkStatus is built during DFG profiling. The CallLinkStatus will then fall back on the CallLinkInfo's lastSeenCallee field, which is persistent across resets. This change just makes it so that CallLinkStatus sets takesSlowPath if there is a BadCell exit and the status had to be inferred from the lastSeenCallee. This change reduces pointless recompilations in gbemu. It's an 11% speed-up on gbemu. It doesn't seem to hurt any benchmarks. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): (JSC::CallLinkStatus::computeExitSiteData): (JSC::CallLinkStatus::computeFromCallLinkInfo): * bytecode/CallLinkStatus.h: (JSC::CallLinkStatus::CallLinkStatus): (JSC::CallLinkStatus::at): (JSC::CallLinkStatus::operator[]): (JSC::CallLinkStatus::isProved): (JSC::CallLinkStatus::isBasedOnStub): (JSC::CallLinkStatus::canOptimize): (JSC::CallLinkStatus::maxNumArguments): (JSC::CallLinkStatus::ExitSiteData::ExitSiteData): Deleted. 2016-01-29 Saam barati Pack FunctionExecutable and UnlinkedFunctionExecutable harder https://bugs.webkit.org/show_bug.cgi?id=153687 Reviewed by Andreas Kling. This patch reduces FunctionExecutable from 120 to 104 bytes. This patch reduces UnlinkedFunctionExecutable from 144 to 136 bytes. * bytecode/ExecutableInfo.h: * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): * bytecode/UnlinkedFunctionExecutable.h: * parser/ParserModes.h: (JSC::functionNameScopeIsDynamic): * runtime/Executable.cpp: (JSC::ScriptExecutable::ScriptExecutable): * runtime/Executable.h: (JSC::ScriptExecutable::needsActivation): (JSC::ScriptExecutable::isArrowFunctionContext): (JSC::ScriptExecutable::isStrictMode): (JSC::ScriptExecutable::derivedContextType): (JSC::ScriptExecutable::ecmaMode): (JSC::ScriptExecutable::finishCreation): 2016-01-29 Saam barati JSC Sampling Profiler: Come up with a (program counter => CodeOrigin) mapping https://bugs.webkit.org/show_bug.cgi?id=152629 Reviewed by Filip Pizlo. This patch implements a mapping from PC to CodeOrigin that lives off of JITed CodeBlocks. We build this mapping while JITing code, and then we compress it and store it on the CodeBlock. We only build the mapping if a debugger has ever been attached to any global object. CodeBlock consults this mapping when searching for a CodeOrigin for a given PC, but it also consults other code ranges off the main path that may own the PC. Specifically, it searches through inline caches, OSRExits, and LazySlowPaths. To find PC info for the LLInt, we also save the LLInt pc when taking a stack trace where the top frame is in LLInt code. This patch also cleans up code inside the SamplingProfier. I realized a bug in the SamplingProfiler's implementation. We used to walk the inline stack while gathering a stack trace. This is wrong. It's super dangerous to do this because we might pause the JSC process while it's modifying its CodeOrigin table. We used to walk the inline stack while taking a stack trace because doing so could save us from having to verify a particular stack trace. This patch changes that. We now have to verify all stack traces taken. This verification step includes walking the inline stack. Because we have a PC=>CodeOrigin map, we can now gather more detailed information about the top-frame we pause. This allows us to correctly observe inlining. It also allows us to observe expression-level line/column information for the top frame. The reason we don't consult this mapping for parent frames is that all parent frames should set the CallSiteIndex on the call frame header, which means we can consult that value to get inlining and expression-level line/column information. * CMakeLists.txt: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::Label::Label): (JSC::AbstractMacroAssembler::Label::operator==): (JSC::AbstractMacroAssembler::Label::isSet): * assembler/AssemblerBuffer.h: (JSC::AssemblerLabel::labelAtOffset): (JSC::AssemblerLabel::operator==): * b3/B3Generate.cpp: * b3/B3Origin.h: (JSC::B3::Origin::data): (JSC::B3::Origin::operator==): * b3/B3PCToOriginMap.h: Added. (JSC::B3::PCToOriginMap::PCToOriginMap): (JSC::B3::PCToOriginMap::appendItem): (JSC::B3::PCToOriginMap::ranges): * b3/B3Procedure.h: (JSC::B3::Procedure::pcToOriginMap): (JSC::B3::Procedure::releasePCToOriginMap): * b3/air/AirGenerate.cpp: (JSC::B3::Air::generate): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): (JSC::CodeBlock::setPCToCodeOriginMap): (JSC::CodeBlock::findPC): * bytecode/CodeBlock.h: (JSC::CodeBlock::jitCodeMap): (JSC::CodeBlock::bytecodeOffset): * bytecode/CodeOrigin.h: (JSC::CodeOrigin::operator==): (JSC::CodeOriginHash::hash): (JSC::CodeOriginHash::equal): * bytecode/InlineCallFrame.h: (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock): (JSC::CodeOrigin::walkUpInlineStack): * bytecode/PolymorphicAccess.h: (JSC::PolymorphicAccess::containsPC): * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::visitWeakReferences): (JSC::StructureStubInfo::containsPC): * bytecode/StructureStubInfo.h: * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::hasExpressionInfo): (JSC::UnlinkedCodeBlock::expressionInfo): (JSC::UnlinkedCodeBlock::setThisRegister): * debugger/Debugger.cpp: (JSC::Debugger::attach): * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::validateReferences): (JSC::DFG::JITCode::findPC): * dfg/DFGJITCode.h: (JSC::DFG::JITCode::commonDataOffset): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::JITCompiler): (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded): (JSC::DFG::JITCompiler::setEndOfMainPath): (JSC::DFG::JITCompiler::setEndOfCode): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::setStartOfCode): (JSC::DFG::JITCompiler::setForNode): (JSC::DFG::JITCompiler::addCallSite): (JSC::DFG::JITCompiler::pcToCodeOriginMapBuilder): (JSC::DFG::JITCompiler::setEndOfMainPath): Deleted. (JSC::DFG::JITCompiler::setEndOfCode): Deleted. * dfg/DFGSlowPathGenerator.h: (JSC::DFG::SlowPathGenerator::call): (JSC::DFG::SlowPathGenerator::origin): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::addSlowPathGenerator): (JSC::DFG::SpeculativeJIT::runSlowPathGenerators): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * dfg/DFGSpeculativeJIT.h: * ftl/FTLB3Compile.cpp: (JSC::FTL::compile): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite): (JSC::FTL::JITCode::findPC): * ftl/FTLJITCode.h: (JSC::FTL::JITCode::b3Code): * heap/MachineStackMarker.cpp: (JSC::MachineThreads::Thread::Registers::instructionPointer): (JSC::MachineThreads::Thread::Registers::llintPC): (JSC::MachineThreads::Thread::freeRegisters): * heap/MachineStackMarker.h: * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::InspectorScriptProfilerAgent::addEvent): (Inspector::buildSamples): (Inspector::InspectorScriptProfilerAgent::trackingComplete): * jit/JIT.cpp: (JSC::JIT::JIT): (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): (JSC::JIT::privateCompile): * jit/JIT.h: * jit/JITCode.h: (JSC::JITCode::findPC): * jit/PCToCodeOriginMap.cpp: Added. (JSC::PCToCodeOriginMapBuilder::PCToCodeOriginMapBuilder): (JSC::PCToCodeOriginMapBuilder::appendItem): (JSC::PCToCodeOriginMap::PCToCodeOriginMap): (JSC::PCToCodeOriginMap::~PCToCodeOriginMap): (JSC::PCToCodeOriginMap::memorySize): (JSC::PCToCodeOriginMap::findPC): * jit/PCToCodeOriginMap.h: Added. (JSC::PCToCodeOriginMapBuilder::defaultCodeOrigin): (JSC::PCToCodeOriginMapBuilder::didBuildMapping): * jsc.cpp: (functionSamplingProfilerStackTraces): * llint/LLIntPCRanges.h: (JSC::LLInt::isLLIntPC): * llint/LowLevelInterpreter.asm: * runtime/Options.h: * runtime/SamplingProfiler.cpp: (JSC::reportStats): (JSC::FrameWalker::FrameWalker): (JSC::FrameWalker::walk): (JSC::FrameWalker::resetAtMachineFrame): (JSC::FrameWalker::isValidFramePointer): (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::~SamplingProfiler): (JSC::tryGetBytecodeIndex): (JSC::SamplingProfiler::processUnverifiedStackTraces): (JSC::SamplingProfiler::visit): (JSC::SamplingProfiler::noticeVMEntry): (JSC::SamplingProfiler::clearData): (JSC::SamplingProfiler::StackFrame::displayName): (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests): (JSC::SamplingProfiler::StackFrame::functionStartLine): (JSC::SamplingProfiler::StackFrame::functionStartColumn): (JSC::SamplingProfiler::StackFrame::sourceID): (JSC::SamplingProfiler::StackFrame::url): (JSC::SamplingProfiler::releaseStackTraces): (JSC::SamplingProfiler::stackTracesAsJSON): (WTF::printInternal): (JSC::SamplingProfiler::StackFrame::startLine): Deleted. (JSC::SamplingProfiler::StackFrame::startColumn): Deleted. (JSC::SamplingProfiler::stackTraces): Deleted. * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame): (JSC::SamplingProfiler::StackFrame::StackFrame): (JSC::SamplingProfiler::StackTrace::StackTrace): (JSC::SamplingProfiler::totalTime): (JSC::SamplingProfiler::setStopWatch): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: (JSC::VM::setShouldBuildPCToCodeOriginMapping): (JSC::VM::shouldBuilderPCToCodeOriginMapping): * tests/stress/sampling-profiler-basic.js: (platformSupportsSamplingProfiler.top): (platformSupportsSamplingProfiler.jaz): (platformSupportsSamplingProfiler.kaz): 2016-01-29 Saam barati Remove our notion of having a single activation register https://bugs.webkit.org/show_bug.cgi?id=153673 Reviewed by Filip Pizlo. We have many functions lurking around where we think a function might only have one activation register. This is clearly wrong now that ES6 has block scoping. This patch removes this false notion. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): * bytecode/CodeBlock.h: (JSC::CodeBlock::scopeRegister): (JSC::CodeBlock::codeType): (JSC::CodeBlock::setActivationRegister): Deleted. (JSC::CodeBlock::activationRegister): Deleted. (JSC::CodeBlock::uncheckedActivationRegister): Deleted. (JSC::CodeBlock::needsActivation): Deleted. * bytecode/ExecutableInfo.h: (JSC::ExecutableInfo::ExecutableInfo): (JSC::ExecutableInfo::usesEval): (JSC::ExecutableInfo::isStrictMode): (JSC::ExecutableInfo::isConstructor): (JSC::ExecutableInfo::isClassContext): (JSC::ExecutableInfo::needsActivation): Deleted. * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::isArrowFunctionContext): (JSC::UnlinkedCodeBlock::isClassContext): (JSC::UnlinkedCodeBlock::setThisRegister): (JSC::UnlinkedCodeBlock::setScopeRegister): (JSC::UnlinkedCodeBlock::usesGlobalObject): (JSC::UnlinkedCodeBlock::setGlobalObjectRegister): (JSC::UnlinkedCodeBlock::thisRegister): (JSC::UnlinkedCodeBlock::scopeRegister): (JSC::UnlinkedCodeBlock::addPropertyAccessInstruction): (JSC::UnlinkedCodeBlock::needsFullScopeChain): Deleted. (JSC::UnlinkedCodeBlock::setActivationRegister): Deleted. (JSC::UnlinkedCodeBlock::activationRegister): Deleted. (JSC::UnlinkedCodeBlock::hasActivationRegister): Deleted. * bytecode/UnlinkedFunctionExecutable.cpp: (JSC::generateUnlinkedFunctionCodeBlock): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeVarLexicalEnvironment): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::destinationForAssignResult): (JSC::BytecodeGenerator::leftHandSideNeedsCopy): (JSC::BytecodeGenerator::emitNodeForLeftHandSide): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::inliningCost): (JSC::DFG::ByteCodeParser::parseCodeBlock): * dfg/DFGGraph.h: (JSC::DFG::Graph::hasExitSite): (JSC::DFG::Graph::activationRegister): Deleted. (JSC::DFG::Graph::uncheckedActivationRegister): Deleted. (JSC::DFG::Graph::machineActivationRegister): Deleted. (JSC::DFG::Graph::uncheckedMachineActivationRegister): Deleted. * dfg/DFGStackLayoutPhase.cpp: (JSC::DFG::StackLayoutPhase::run): * interpreter/CallFrame.cpp: (JSC::CallFrame::callSiteIndex): (JSC::CallFrame::stack): (JSC::CallFrame::callerFrame): (JSC::CallFrame::friendlyFunctionName): (JSC::CallFrame::hasActivation): Deleted. (JSC::CallFrame::uncheckedActivation): Deleted. (JSC::CallFrame::lexicalEnvironment): Deleted. (JSC::CallFrame::lexicalEnvironmentOrNullptr): Deleted. (JSC::CallFrame::setActivation): Deleted. * interpreter/CallFrame.h: (JSC::ExecState::scope): (JSC::ExecState::setCallerFrame): (JSC::ExecState::setScope): (JSC::ExecState::init): * interpreter/Register.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Executable.h: (JSC::ScriptExecutable::usesEval): (JSC::ScriptExecutable::usesArguments): (JSC::ScriptExecutable::isArrowFunctionContext): (JSC::ScriptExecutable::isStrictMode): (JSC::ScriptExecutable::derivedContextType): (JSC::ScriptExecutable::needsActivation): Deleted. * runtime/JSLexicalEnvironment.h: (JSC::asActivation): (JSC::Register::lexicalEnvironment): Deleted. 2016-01-29 Filip Pizlo Air:fixObviousSpills should handle floats and doubles https://bugs.webkit.org/show_bug.cgi?id=153197 Reviewed by Saam Barati. This adds the most obvious handling of float spills, where we just enable load elimination on float spill code. * b3/air/AirFixObviousSpills.cpp: 2016-01-29 Andreas Kling Shrink CodeBlock! Reviewed by Saam Barati. Shrink CodeBlock by 112 bytes (from 640 to 528) by employing these sophisticated tricks: - Remove members that are not used by anyone. - Don't cache both VM* and Heap* in members. - Reorder members to minimize struct padding. - Use RefCountedArray instead of Vector for arrays that never resize. - Put a not-always-present HashMap in a std::unique_ptr. This increases CodeBlock space efficiency by 20%, as we can now fit 30 of them in a MarkedBlock, up from 25.) * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::setNumParameters): (JSC::CodeBlock::jettison): (JSC::CodeBlock::noticeIncomingCall): (JSC::CodeBlock::resultProfileForBytecodeOffset): * bytecode/CodeBlock.h: (JSC::CodeBlock::setJITCode): (JSC::CodeBlock::capabilityLevelState): (JSC::CodeBlock::codeType): (JSC::CodeBlock::ensureResultProfile): (JSC::CodeBlock::heap): 2016-01-29 Saam barati Exits from exceptions shouldn't jettison code https://bugs.webkit.org/show_bug.cgi?id=153564 Reviewed by Geoffrey Garen. We create two new exit kinds for exception-handling OSRExits: - ExceptionCheck: an exception check after a C call. - GenericUnwind: an OSR exit executes because it's jumped to from genericUnwind machinery. Having these two new exit kinds allows us to remove fields from various OSRExit variants that store booleans indicating if the exit is an exception handler, and if so, what kind of exception handler. Most of this patch is just removing those old fields and adding new equivalent functions. This patch also implements the policy that we should never consider jettisoning code from exits that happen from an exception check to an op_catch (it might be worth considering a similar policy for 'throw'). We're choosing this policy because it will almost never be more expensive, in total, to execute the OSR exit than to execute the baseline variant of the code. When an exception is thrown, we do really expensive work, like call through to genericUnwind, and also create an error object with a stack trace. The cost of OSR exiting here is small in comparison to those other operations. And penalizing a CodeBlock for OSR exiting from an exception is silly because the basis of our implementation of exception handling in the upper tiers is to OSR exit on a caught exception. So we used to penalize ourselves for having an implementation that is correct w.r.t our design goals. I've verified this hypothesis with on v8-raytrace by adding a new benchmark that throws with very high frequency. Implementing this policy on that benchmark results in about a 4-5% speed up. * bytecode/ExitKind.cpp: (JSC::exitKindToString): (JSC::exitKindMayJettison): (JSC::exitKindIsCountable): Deleted. * bytecode/ExitKind.h: * dfg/DFGJITCode.cpp: (JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::noticeOSREntry): (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit): (JSC::DFG::JITCompiler::exceptionCheck): (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded): * dfg/DFGJITCompiler.h: * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::OSRExit): * dfg/DFGOSRExit.h: (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite): * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::OSRExitBase): (JSC::DFG::OSRExitBase::isExceptionHandler): (JSC::DFG::OSRExitBase::isGenericUnwindHandler): (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::handleExitCounts): (JSC::DFG::osrWriteBarrier): (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGOSRExitCompilerCommon.h: (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk): * ftl/FTLCompile.cpp: (JSC::FTL::mmAllocateDataSection): * ftl/FTLExitThunkGenerator.cpp: (JSC::FTL::ExitThunkGenerator::emitThunk): * ftl/FTLJITCode.cpp: (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::callCheck): (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException): (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation): * ftl/FTLOSRExit.cpp: (JSC::FTL::OSRExitDescriptor::emitOSRExit): (JSC::FTL::OSRExitDescriptor::emitOSRExitLater): (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle): (JSC::FTL::OSRExit::OSRExit): (JSC::FTL::OSRExit::spillRegistersToSpillSlot): (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot): (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck): (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation): (JSC::FTL::exceptionTypeWillArriveAtOSRExitFromGenericUnwind): Deleted. (JSC::FTL::OSRExit::willArriveAtOSRExitFromGenericUnwind): Deleted. * ftl/FTLOSRExit.h: * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): (JSC::FTL::compileFTLOSRExit): * ftl/FTLPatchpointExceptionHandle.cpp: (JSC::FTL::PatchpointExceptionHandle::scheduleExitCreation): (JSC::FTL::PatchpointExceptionHandle::scheduleExitCreationForUnwind): (JSC::FTL::PatchpointExceptionHandle::PatchpointExceptionHandle): (JSC::FTL::PatchpointExceptionHandle::createHandle): * ftl/FTLPatchpointExceptionHandle.h: 2016-01-28 Yusuke Suzuki [B3] REGRESSION(r195395): testComplex(64, 128) asserts on Linux with GCC https://bugs.webkit.org/show_bug.cgi?id=153422 Reviewed by Filip Pizlo. Previously proc.values() returns ValuesCollection (Not reference!). values.values takes const ValueCollection&. And later it produces IndexSet::Iterable, it holds const ValueCollection& as its member. But IndexSet::Iterable is just an instance. So after creating this, the lifetime of the ValueCollection const reference finished. To fix that, we hold ValuesCollection as a member of Procedure. And change the signature to const ValuesCollection& Procedure::values(). * b3/B3Procedure.cpp: (JSC::B3::Procedure::Procedure): * b3/B3Procedure.h: (JSC::B3::Procedure::values): 2016-01-28 Joseph Pecoraro Web Inspector: InspectorTimelineAgent doesn't need to recompile functions because it now uses the sampling profiler https://bugs.webkit.org/show_bug.cgi?id=153500 Reviewed by Timothy Hatcher. Be more explicit about enabling legacy profiling. * jsc.cpp: * runtime/Executable.cpp: (JSC::ScriptExecutable::newCodeBlockFor): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::hasLegacyProfiler): (JSC::JSGlobalObject::createProgramCodeBlock): (JSC::JSGlobalObject::createEvalCodeBlock): (JSC::JSGlobalObject::createModuleProgramCodeBlock): (JSC::JSGlobalObject::hasProfiler): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::supportsLegacyProfiling): (JSC::JSGlobalObject::supportsProfiling): Deleted. 2016-01-28 Yusuke Suzuki Fix the B3 build with GCC 4.9.3 https://bugs.webkit.org/show_bug.cgi?id=151624 Reviewed by Filip Pizlo. Due to GCC 4.9's compiler issue[1], method calls inside (2 or so) nested lambdas need to use `this` to avoid internal compiler errors. [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272 * b3/air/AirIteratedRegisterCoalescing.cpp: 2016-01-28 Filip Pizlo LowerToAir::preferRightForResult() should resolve use count ties by selecting the child that is closest in an idom walk https://bugs.webkit.org/show_bug.cgi?id=153583 Reviewed by Benjamin Poulain. This undoes the AsmBench/n-body regression in r195654 while preserving that revision's Kraken progression. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::LowerToAir): (JSC::B3::Air::LowerToAir::preferRightForResult): 2016-01-28 Benjamin Poulain [JSC] B3 Tail Call with Varargs do not restore callee saved registers https://bugs.webkit.org/show_bug.cgi?id=153579 Reviewed by Michael Saboff. We were trashing the callee saved registers in Tail Calls. I just copied the code from DFG to fix this :) * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs): 2016-01-27 Filip Pizlo B3 IntRange analysis should know more about shifting https://bugs.webkit.org/show_bug.cgi?id=153568 Reviewed by Benjamin Poulain. This teaches the IntRange analysis that the result of a right shift is usually better than the worst-case mask based on the shift amount. In fact, you can reach useful conclusions from looking at the IntRange of the input. This helps because Octane/crypto does something like: CheckMul((@x & $268435455) >> 14, @y >> 14, ...) If you consider just the shifts, then this may overflow. But if you consider that @x is first masked, then the IntRange coming out of the first shift is tight enough to prove that the CheckMul cannot overflow. * b3/B3ReduceStrength.cpp: * b3/testb3.cpp: 2016-01-27 Benjamin Poulain [JSC] adjustFrameAndStackInOSRExitCompilerThunk() can trash values in FTL https://bugs.webkit.org/show_bug.cgi?id=153536 Reviewed by Saam Barati. Workaround to get B3 working on ARM. * dfg/DFGOSRExitCompilerCommon.h: (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk): The code was using the scratch registers in a few places. I initially tried to make is not use scratch registers anywhere but that looked super fragile. Instead, I just preserve the scratch registers. That's easy and it should be relatively cheap compared to everything done on OSR Exits. 2016-01-27 Konstantin Tokarev [mips] Use reinterpret_cast_ptr to suppress alignment warnings. https://bugs.webkit.org/show_bug.cgi?id=153424 Reviewed by Darin Adler. * runtime/JSGenericTypedArrayView.h: (JSC::JSGenericTypedArrayView::sortFloat): 2016-01-27 Per Arne Vollan [FTL][Win64] Compile fix. https://bugs.webkit.org/show_bug.cgi?id=153555 Reviewed by Alex Christensen. MSVC does not accept preprocessor conditionals in macros. * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): 2016-01-27 Filip Pizlo Air::TmpWidth uses a stale pointer into its HashMap after it calls add() https://bugs.webkit.org/show_bug.cgi?id=153546 Reviewed by Saam Barati. * b3/air/AirTmpWidth.cpp: (JSC::B3::Air::TmpWidth::recompute): 2016-01-27 Alexey Proskuryakov Remove ENABLE_CURRENTSRC https://bugs.webkit.org/show_bug.cgi?id=153545 Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2016-01-26 Benjamin Poulain [JSC] When lowering B3 to Air, preferRightForResult() should prefer values from the same block https://bugs.webkit.org/show_bug.cgi?id=153477 Reviewed by Filip Pizlo. In cases like this: Block #0 @1 = something @2 = Jump #1 Block #1 @3 = something else @4 = Add(@3, @1) ... @42 = Branch(@x, #1, #2) B3LowerToAir would pick @1 for the argument copied for what goes into the UseDef side of Add. This created a bunch of moves that could never be coalesced. In Kraken's imaging-desaturate, there were enough Moves to slow down the hot loop. Ideally, we should not use UseCount for lowering. We should use the real liveness for preferRightForResult(), and a loop-weighted use-count for effective addresses. The problem is keeping the cost low for those simple helpers. In this patch, I went with a simple heuristic: prioritize the value defined in the same block for UseDef. There is one other way that would be cheap but a bit invasive: -Get rid of UseDef. -Make every ops, 3 operands. -Tell the register allocator to attempt aliasing of the 2 uses with the def. -If the allocator fails, just add a move as needed. For now, the simple heuristic seems okay for the cases have. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::preferRightForResult): 2016-01-26 Filip Pizlo Tail duplication should break critical edges first https://bugs.webkit.org/show_bug.cgi?id=153530 Reviewed by Benjamin Poulain. This speeds up Octane/boyer. * b3/B3DuplicateTails.cpp: 2016-01-26 Joseph Pecoraro Generalize ResourceUsageData gathering to be used outside of ResourceUsageOverlay https://bugs.webkit.org/show_bug.cgi?id=153509 Reviewed by Andreas Kling. * heap/Heap.h: * heap/HeapInlines.h: (JSC::Heap::didAllocateBlock): (JSC::Heap::didFreeBlock): Rename the ENABLE flag. 2016-01-26 Csaba Osztrogonác [B3] Fix control reaches end of non-void function GCC warning after r195139 https://bugs.webkit.org/show_bug.cgi?id=153426 Reviewed by Michael Catanzaro. * b3/air/AirArg.h: (JSC::B3::Air::Arg::cooled): 2016-01-26 Saam barati testb3 and testAir should be compiled under -O0 https://bugs.webkit.org/show_bug.cgi?id=153520 Reviewed by Benjamin Poulain. * JavaScriptCore.xcodeproj/project.pbxproj: 2016-01-26 Filip Pizlo B3's integer range analysis should know that Mul'ing two sufficiently small numbers will yield a number that still has a meaningful range https://bugs.webkit.org/show_bug.cgi?id=153518 Reviewed by Benjamin Poulain. Octane/encrypt had an addition overflow check that can be proved away by being sufficiently sneaky about the analysis of adds, multiplies, and shifts. I almost added these optimizations to the DFG integer range optimization phase. That phase is very complicated. B3's integer range analysis is trivial. So I added it to B3. Eventually we'll want this same machinery in the DFG also. 8% speed-up on Octane/encrypt. * b3/B3ReduceStrength.cpp: * b3/B3Value.cpp: (JSC::B3::Value::dump): Dumping a constant value's name now dumps its value. This makes a huge difference for reading IR. (JSC::B3::Value::cloneImpl): (JSC::B3::Value::deepDump): 2016-01-26 Filip Pizlo It should be possible to disable FTL for a range like we disable DFG for a range https://bugs.webkit.org/show_bug.cgi?id=153511 Reviewed by Geoffrey Garen. * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::TierUpCheckInjectionPhase::run): * runtime/Options.h: 2016-01-26 Filip Pizlo Shifts by an amount computed using BitAnd with a mask that subsumes the shift's own mask should be rewired around the BitAnd https://bugs.webkit.org/show_bug.cgi?id=153505 Reviewed by Saam Barati. Turn this: Shl(@x, BitAnd(@y, 63)) Into this: Shl(@x, @y) It matters for Octane/crypto. We should also stop FTL from generating such code, but even if we did that, we'd still want this optimization in case user code did the BitAnd. Also we can't stop the FTL from generating such code yet, because when targetting LLVM, you must mask your shifts this way. * b3/B3ReduceStrength.cpp: 2016-01-26 Filip Pizlo The thing that B3 uses to describe a stack slot should not be a Value https://bugs.webkit.org/show_bug.cgi?id=153491 rdar://problem/24349446 Reviewed by Geoffrey Garen and Saam Barati. Prior to this change, B3 represented stack slots by having a StackSlotValue that carried two meanings: - It represented a stack slot. - It was a kind of Value for getting the base of the stack slot. This seems like a good idea until you consider the following issues. 1) A Value can be killed if it is on an unreachable path, or if it has no effects and nobody refers to it. But the FTL uses StackSlotValue to allocate space on the stack. When it does this, it doesn't want it to be killed. It will dereference the object, so killing it is a bug. 2) A premise of B3 is that it should be always legal to perform the following transformation on a value: value->replaceWithIdentity(insertionSet.insertValue(index, proc.clone(value))); This inserts a new value just before the old one. The new value is a clone of the old one. Then the old one is essentially deleted (anything that becomes an identity dies shortly thereafter). Problem (1) prevents this from being legal, which breaks a major premise of B3 IR. 3) A premise of B3 is that it should be always legal to perform the following transformation on a value: Before: @42 = Thing(...) After: Branch(@doesntMatter, #yes, #no) BB#yes: @42_one = Thing(...) Upsilon(@42_one, ^42) Jump(#done) BB#no: @42_two = Thing(...) Upsilon(@42_two, ^42) Jump(#done) BB#done: @42 = Phi() But prior to this change, such a transformation makes absolutely no sense for StackSlot. It will "work" in the sense that the compiler will proceed undaunted, but it will disable SSA fix-up for the cloned stack slot and we will end up allocating two stack slots instead of one, and then we will assume that they both escape, which will disable efficient stack allocation. Note that the moral equivalent of this transformation could already happen due to tail duplication, and the only reason why it's not a bug right now is that we happen to hoist stack slots to the root block. But the whole point of our stack slots was supposed to be that they do not have to be hoisted. This change fixes this issue by splitting StackSlotValue into two things: SlotBaseValue, which is a pure operation for getting the base address of a StackSlot, and StackSlot, which is a representation of the actual stack slot. StackSlot cannot get duplicated and can only be killed if it's anonymous. SlotBaseValue can be killed, moved, cloned, hoisted, etc. Since it has no effects and it has a ValueKey, it's one of the most permissive Values in the IR, just as one would hope (after all, there is actually zero code that needs to execute to evaluate SlotBaseValue). This fixes a crash that we saw with GuardMalloc and ASan. It also makes the IR a lot more easy to reason about. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3EliminateCommonSubexpressions.cpp: * b3/B3FixSSA.cpp: (JSC::B3::demoteValues): (JSC::B3::fixSSA): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::run): (JSC::B3::Air::LowerToAir::effectiveAddr): (JSC::B3::Air::LowerToAir::lower): * b3/B3Opcode.cpp: (WTF::printInternal): * b3/B3Opcode.h: * b3/B3Procedure.cpp: (JSC::B3::Procedure::setBlockOrderImpl): (JSC::B3::Procedure::addStackSlot): (JSC::B3::Procedure::addAnonymousStackSlot): (JSC::B3::Procedure::clone): (JSC::B3::Procedure::dump): (JSC::B3::Procedure::blocksInPostOrder): (JSC::B3::Procedure::deleteStackSlot): (JSC::B3::Procedure::deleteValue): (JSC::B3::Procedure::calleeSaveRegisters): (JSC::B3::Procedure::addStackSlotIndex): (JSC::B3::Procedure::addValueIndex): * b3/B3Procedure.h: (JSC::B3::Procedure::setBlockOrder): (JSC::B3::Procedure::StackSlotsCollection::StackSlotsCollection): (JSC::B3::Procedure::StackSlotsCollection::size): (JSC::B3::Procedure::StackSlotsCollection::at): (JSC::B3::Procedure::StackSlotsCollection::operator[]): (JSC::B3::Procedure::StackSlotsCollection::iterator::iterator): (JSC::B3::Procedure::StackSlotsCollection::iterator::operator*): (JSC::B3::Procedure::StackSlotsCollection::iterator::operator++): (JSC::B3::Procedure::StackSlotsCollection::iterator::operator==): (JSC::B3::Procedure::StackSlotsCollection::iterator::operator!=): (JSC::B3::Procedure::StackSlotsCollection::iterator::findNext): (JSC::B3::Procedure::StackSlotsCollection::begin): (JSC::B3::Procedure::StackSlotsCollection::end): (JSC::B3::Procedure::stackSlots): (JSC::B3::Procedure::ValuesCollection::ValuesCollection): * b3/B3ReduceStrength.cpp: * b3/B3SlotBaseValue.cpp: Copied from Source/JavaScriptCore/b3/B3StackSlotValue.cpp. (JSC::B3::SlotBaseValue::~SlotBaseValue): (JSC::B3::SlotBaseValue::dumpMeta): (JSC::B3::SlotBaseValue::cloneImpl): (JSC::B3::StackSlotValue::~StackSlotValue): Deleted. (JSC::B3::StackSlotValue::dumpMeta): Deleted. (JSC::B3::StackSlotValue::cloneImpl): Deleted. * b3/B3SlotBaseValue.h: Copied from Source/JavaScriptCore/b3/B3StackSlotValue.h. * b3/B3StackSlot.cpp: Added. (JSC::B3::StackSlot::~StackSlot): (JSC::B3::StackSlot::dump): (JSC::B3::StackSlot::deepDump): (JSC::B3::StackSlot::StackSlot): * b3/B3StackSlot.h: Added. (JSC::B3::StackSlot::byteSize): (JSC::B3::StackSlot::kind): (JSC::B3::StackSlot::isLocked): (JSC::B3::StackSlot::index): (JSC::B3::StackSlot::offsetFromFP): (JSC::B3::StackSlot::setOffsetFromFP): (JSC::B3::DeepStackSlotDump::DeepStackSlotDump): (JSC::B3::DeepStackSlotDump::dump): (JSC::B3::deepDump): * b3/B3StackSlotValue.cpp: Removed. * b3/B3StackSlotValue.h: Removed. * b3/B3Validate.cpp: * b3/B3Value.cpp: (JSC::B3::Value::effects): (JSC::B3::Value::key): (JSC::B3::Value::checkOpcode): * b3/B3ValueKey.cpp: (JSC::B3::ValueKey::materialize): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::addBlock): (JSC::B3::Air::Code::addStackSlot): (JSC::B3::Air::Code::addSpecial): * b3/air/AirCode.h: * b3/air/AirStackSlot.cpp: (JSC::B3::Air::StackSlot::setOffsetFromFP): (JSC::B3::Air::StackSlot::dump): (JSC::B3::Air::StackSlot::deepDump): (JSC::B3::Air::StackSlot::StackSlot): * b3/air/AirStackSlot.h: (JSC::B3::Air::StackSlot::alignment): (JSC::B3::Air::StackSlot::b3Slot): (JSC::B3::Air::StackSlot::offsetFromFP): (WTF::printInternal): (JSC::B3::Air::StackSlot::value): Deleted. * b3/testb3.cpp: (JSC::B3::testStackSlot): (JSC::B3::testStoreLoadStackSlot): * ftl/FTLB3Compile.cpp: * ftl/FTLB3Output.cpp: (JSC::FTL::Output::appendTo): (JSC::FTL::Output::lockedStackSlot): (JSC::FTL::Output::neg): * ftl/FTLB3Output.h: (JSC::FTL::Output::framePointer): (JSC::FTL::Output::constBool): (JSC::FTL::Output::constInt32): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::lower): * ftl/FTLState.h: 2016-01-26 Benjamin Poulain Remove a useless #include https://bugs.webkit.org/show_bug.cgi?id=153474 Reviewed by Alexey Proskuryakov. * b3/B3ReduceStrength.cpp: 2016-01-26 Alex Christensen [Win] Fix clean build after r195545. ​https://bugs.webkit.org/show_bug.cgi?id=153434 * CMakeLists.txt: * PlatformWin.cmake: Derived sources need to be copied after the build, but everything else should be copied before. This should fix ews issues like the one seen in bug 153473. 2016-01-25 Filip Pizlo FTLB3Output should maintain good block order like the LLVM one does https://bugs.webkit.org/show_bug.cgi?id=152222 Reviewed by Geoffrey Garen. This fixes FTLB3Output to emit an ordered B3 IR. This makes inspecting IR *a lot* easier. It will also be a performance win whenever we use range-based data structures for liveness. Also two small other changes: - Added some more dumping in integer range optimization phase. - Refined the disassembler's printing of instruction width suffixes so that "jzl" is not a thing. It was using "l" as the suffix because jumps take a 32-bit immediate. * b3/B3Procedure.cpp: (JSC::B3::Procedure::addBlock): (JSC::B3::Procedure::setBlockOrderImpl): (JSC::B3::Procedure::clone): * b3/B3Procedure.h: (JSC::B3::Procedure::frontendData): (JSC::B3::Procedure::setBlockOrder): * dfg/DFGIntegerRangeOptimizationPhase.cpp: * disassembler/udis86/udis86_syn-att.c: (ud_translate_att): * ftl/FTLB3Output.cpp: (JSC::FTL::Output::initialize): (JSC::FTL::Output::newBlock): (JSC::FTL::Output::applyBlockOrder): (JSC::FTL::Output::appendTo): * ftl/FTLB3Output.h: (JSC::FTL::Output::setFrequency): (JSC::FTL::Output::insertNewBlocksBefore): (JSC::FTL::Output::callWithoutSideEffects): (JSC::FTL::Output::newBlock): Deleted. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::lower): 2016-01-25 Skachkov Oleksandr [ES6] Arrow function syntax. Arrow function specific features. Lexical bind "arguments" https://bugs.webkit.org/show_bug.cgi?id=145132 Reviewed by Saam Barati. Added support of ES6 arrow function specific feature, lexical bind of arguments. http://www.ecma-international.org/ecma-262/6.0/#sec-arrow-function-definitions-runtime-semantics-evaluation 'arguments' variable in arrow function must resolve to a binding in a lexically enclosing environment. In srict mode it points to arguments object, and in non-stric mode it points to arguments object or varible with name 'arguments' if it was declared. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::setSourceParseMode): (JSC::Scope::isArrowFunction): (JSC::Scope::collectFreeVariables): (JSC::Scope::setIsArrowFunction): * tests/es6.yaml: * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js: Added. * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-2.js: Added. * tests/stress/arrowfunction-lexical-bind-arguments-strict.js: Added. 2016-01-25 Benjamin Poulain [JSC] We should never use x18 on iOS ARM64 https://bugs.webkit.org/show_bug.cgi?id=153461 Reviewed by Filip Pizlo. The register x18 is reserved in the iOS variant of the ARM64 ABI. The weird thing is: if you use it, its value will change completely randomly. It looks like it is changed by the system on interrupts. This patch adds x18 to the reserved register and add assertions to the assembler to prevent similar problems in the future. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::xOrSp): (JSC::ARM64Assembler::xOrZr): * assembler/AbstractMacroAssembler.h: (JSC::isIOS): Deleted. * assembler/AssemblerCommon.h: (JSC::isIOS): * jit/RegisterSet.cpp: (JSC::RegisterSet::reservedHardwareRegisters): 2016-01-25 Commit Queue Unreviewed, rolling out r195550. https://bugs.webkit.org/show_bug.cgi?id=153471 broke animometer bot (and now we have crash logs!) (Requested by kling on #webkit). Reverted changeset: "Restore CodeBlock jettison code Geoff accidentally removed" https://bugs.webkit.org/show_bug.cgi?id=151241 http://trac.webkit.org/changeset/195550 2016-01-25 Andreas Kling MarkedSpace should have more precise allocators. Reviewed by Geoffrey Garen. The four classes responsible for the bulk of MarkedBlock allocations today are: - FunctionCodeBlock (640 bytes) - UnlinkedFunctionCodeBlock (304 bytes) - FunctionExecutable (168 bytes) - UnlinkedFunctionExecutable (144 bytes) Due to the size class distribution in MarkedSpace, we've been wasting quite a lot of heap space on these objects. Our "precise" allocators allowed allocation sizes in 16-byte increments up to 128 bytes, but after that point, we'd only allocate in 256-byte size increments. Thus each instance of those classes would waste space as follows: - FunctionCodeBlock (768-byte cell, 128 bytes wasted) - UnlinkedFunctionCodeBlock (512-byte cell, 208 bytes wasted) - FunctionExecutable(256-byte cell, 88 bytes wasted) - UnlinkedFunctionExecutable(256-byte cell, 112 bytes wasted) This patch raises the limit for precise allocations from 128 to 768, allowing us to allocate these objects with far better space efficiency. The cost of this is 7kB worth of MarkedAllocators and 70 (~2x) more allocators to iterate whenever we iterate all the allocators. * heap/MarkedSpace.h: * heap/MarkedSpace.cpp: (JSC::MarkedSpace::MarkedSpace): (JSC::MarkedSpace::resetAllocators): (JSC::MarkedSpace::forEachAllocator): (JSC::MarkedSpace::isPagedOut): 2016-01-25 Filip Pizlo Fix the comment about FTL_USES_B3. * dfg/DFGCommon.h: 2016-01-25 Filip Pizlo Switch FTL to B3 on X86_64/Mac https://bugs.webkit.org/show_bug.cgi?id=153445 Rubber stamped by Geoffrey Garen. This finally switches from LLVM to B3 in the FTL on X86_64 on the Mac. We recommend that other X86_64 platforms make the switch as well. We will be focusing our performance work on B3 rather than LLVM in the future. ARM64 support is also coming soon, so we will be able to remove FTL LLVM code once that lands. Right now this mostly appears as perf-neutral on the major tests. However, it does have the following immediate benefits: - Dramatic reduction in FTL compile times, on the order of 5x-10x. This means huge speed-ups in shorter-running tests like V8Spider (21%) and JSRegress (8%). - It makes the FTL simpler and more robust because we don't have to do stackmap section parsing. This makes it easier to add new FTL features. We are already working on features, like the sampling profiler, which will only have a FTL B3 implementation. - Speed-ups on some throughput benchmarks like mandreel, richards, imaging-gaussian-blur. It's still a slow down on other throughput benchmarks, though. We started writing B3 in October, so it's pretty awesome that the throughput of the code it generates is already on par with LLVM. This does not fundamentally change how the FTL works. FTL was built to lower DFG IR to a C-like SSA IR, and then rely on powerful SSA optimizations and comprehensive instruction selection and register allocation to turn that code into something that runs fast. B3 also has a C-like SSA IR, has an instruction selector that is in some ways more powerful than LLVM's (B3 does global instruction selection rather than block-local like LLVM), and it has a register allocator that is in some ways more powerful also (B3 uses IRC, a mature graph coloring allocator, while LLVM does not do graph coloring). We expect FTL B3's performance to improve a lot after we turn it on and can focus our efforts on tuning it. I didn't find any test regressions after running both JSC tests and layout tests. Basic browsing still works. JetStream performance difference is within the margin of error. EWS is happy. * dfg/DFGCommon.h: 2016-01-25 Andreas Kling Restore CodeBlock jettison code Geoff accidentally removed https://bugs.webkit.org/show_bug.cgi?id=151241 Rubber-stamped by Geoffrey Garen. Geoff meant to add this back in but missed. Then he added it back in, but it was rolled out due to a crash on Animometer. I can no longer produce a crash on Animometer, either with today's version of the benchmark, or the one that existed at the time of the rollout. Given this, let's roll it back in and see how it goes. * bytecode/CodeBlock.cpp: (JSC::timeToLive): (JSC::CodeBlock::shouldJettisonDueToOldAge): 2016-01-22 Filip Pizlo mandreel should run just as fast in FTL B3 as FTL LLVM https://bugs.webkit.org/show_bug.cgi?id=153394 Reviewed by Gavin Barraclough. This fixes two performance bugs and one disassembler bug. - B3 now turns Branches into Jumps when they are dominated by a Check on the same condition. This is like the opposite of foldPathConstants() was doing. - Air now supports adding to 8-bit or 16-bit memory locations on x86. B3 now knows how to lower Store8(Add(Load8Z(...))) and various other things to these new instructions. - Disassembler now knows to print out the instruction's width, whenever it has one. Previously, we'd print movb, movw, movl, and movq as "mov", which is unhelpful if you're storing an immediate, for example. This adds a bunch of tests for the new instruction forms. This is a big speed-up on mandreel. It makes us just as fast as LLVM on that benchmark. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::add32): (JSC::MacroAssemblerX86Common::add8): (JSC::MacroAssemblerX86Common::add16): (JSC::MacroAssemblerX86Common::add32AndSetFlags): (JSC::MacroAssemblerX86Common::clz32AfterBsr): * assembler/X86Assembler.h: (JSC::X86Assembler::addl_rm): (JSC::X86Assembler::addb_rm): (JSC::X86Assembler::addw_rm): (JSC::X86Assembler::addl_ir): (JSC::X86Assembler::addl_im): (JSC::X86Assembler::addb_im): (JSC::X86Assembler::addw_im): (JSC::X86Assembler::addq_rr): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::addr): (JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode): (JSC::B3::Air::LowerToAir::loadPromise): (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp): (JSC::B3::Air::LowerToAir::lower): * b3/B3PureCSE.cpp: (JSC::B3::PureCSE::clear): (JSC::B3::PureCSE::findMatch): (JSC::B3::PureCSE::process): * b3/B3PureCSE.h: * b3/B3ReduceStrength.cpp: * b3/air/AirOpcode.opcodes: * b3/testb3.cpp: (JSC::B3::testNegPtr): (JSC::B3::testStoreAddLoad32): (JSC::B3::testStoreAddLoadImm32): (JSC::B3::testStoreAddLoad8): (JSC::B3::testStoreAddLoadImm8): (JSC::B3::testStoreAddLoad16): (JSC::B3::testStoreAddLoadImm16): (JSC::B3::testStoreAddLoad64): (JSC::B3::testStoreAddLoadImm64): (JSC::B3::testStoreAddLoad32Index): (JSC::B3::testStoreAddLoadImm32Index): (JSC::B3::testStoreAddLoad8Index): (JSC::B3::testStoreAddLoadImm8Index): (JSC::B3::testStoreAddLoad16Index): (JSC::B3::testStoreAddLoadImm16Index): (JSC::B3::testStoreAddLoad64Index): (JSC::B3::testStoreAddLoadImm64Index): (JSC::B3::testStoreSubLoad): (JSC::B3::run): (JSC::B3::testStoreAddLoad): Deleted. * disassembler/udis86/udis86_syn-att.c: (ud_translate_att): 2016-01-25 Alex Christensen [Win] Copy forwarding headers before building a project https://bugs.webkit.org/show_bug.cgi?id=153434 Reviewed by Brent Fulgham. * CMakeLists.txt: * PlatformWin.cmake: 2016-01-25 Andreas Kling Reduce number of Structures created at startup. Reviewed by Darin Adler. For *Constructor and *Prototype objects that are only created once per JSGlobalObject, build up the Structures using addPropertyWithoutTransition() helpers to avoid creating tons of transitions that would just end up floating around and never getting used. * inspector/JSInjectedScriptHostPrototype.cpp: (Inspector::JSInjectedScriptHostPrototype::finishCreation): * inspector/JSJavaScriptCallFramePrototype.cpp: (Inspector::JSJavaScriptCallFramePrototype::finishCreation): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): * runtime/ConsolePrototype.cpp: (JSC::ConsolePrototype::finishCreation): * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::finishCreation): * runtime/JSArrayBufferPrototype.cpp: (JSC::JSArrayBufferPrototype::finishCreation): * runtime/JSObject.cpp: (JSC::JSObject::putDirectNativeFunctionWithoutTransition): (JSC::JSObject::putDirectBuiltinFunctionWithoutTransition): Deleted. * runtime/JSObject.h: * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::addOwnInternalSlots): * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototype::addOwnInternalSlots): * runtime/JSTypedArrayViewConstructor.cpp: (JSC::JSTypedArrayViewConstructor::finishCreation): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): * runtime/MapIteratorPrototype.cpp: (JSC::MapIteratorPrototype::finishCreation): * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/NumberPrototype.cpp: (JSC::NumberPrototype::finishCreation): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): * runtime/ObjectPrototype.cpp: (JSC::ObjectPrototype::finishCreation): * runtime/SetIteratorPrototype.cpp: (JSC::SetIteratorPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): * runtime/WeakMapPrototype.cpp: (JSC::WeakMapPrototype::finishCreation): * runtime/WeakSetPrototype.cpp: (JSC::WeakSetPrototype::finishCreation): 2016-01-22 Filip Pizlo B3 should strength-reduce division by a constant https://bugs.webkit.org/show_bug.cgi?id=153386 Reviewed by Benjamin Poulain. You can turn a 32-bit division by a constant into a 64-bit multiplication by a constant plus some shifts. A book called "Hacker's Delight" has a bunch of math about this. The hard part is finding the constant by which to multiply, and the amount by which to shift. The book tells you some theroems, but you still have to turn that into code by thinking deep thoughts. Luckily I was able to avoid that because it turns out that LLVM already has code for this. It's called APInt::magic(), where APInt is their class for reasoning about integers. The code has a compatible license to ours and we have already in the past taken code from LLVM. So, that's what this patch does. The LLVM code is localized in B3ComputeDivisionMagic.h. Then reduceStrength() uses that to construct the multiply+shift sequence. This is an enormous speed-up on AsmBench-0.9/bigfib.cpp.js. It makes us as fast on that test as LLVM. It reduces our deficit on AsmBench to 1.5%. Previously it was 4.5%. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3ComputeDivisionMagic.h: Added. (JSC::B3::computeDivisionMagic): * b3/B3ReduceStrength.cpp: 2016-01-22 Saam barati genericUnwind might overflow the instructions() vector when catching an FTL exception https://bugs.webkit.org/show_bug.cgi?id=153383 Reviewed by Benjamin Poulain. * jit/JITExceptions.cpp: (JSC::genericUnwind): 2016-01-22 Mark Lam We should OSR exit with Int52Overflow when we fail to make an Int52 where we expect one. https://bugs.webkit.org/show_bug.cgi?id=153379 Reviewed by Filip Pizlo. In DFG::Graph::addShouldSpeculateMachineInt(), we check !hasExitSite(add, Int52Overflow) when determining whether it's ok to speculate that an operand is of type Int52 or not. However, the Int52Rep code that converts a double to Int52 will OSR exit with exit kind BadType instead. This renders the hasExitSite() check in addShouldSpeculateMachineInt() useless. This patch fixes this by changing Int52Rep to OSR exit with exit kind Int52Overflow instead when it fails to convert a double to an Int52. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): (JSC::DFG::SpeculativeJIT::typeCheck): (JSC::DFG::SpeculativeJIT::usedRegisters): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::needsTypeCheck): (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::typeCheck): (JSC::FTL::DFG::LowerDFGToLLVM::appendTypeCheck): (JSC::FTL::DFG::LowerDFGToLLVM::doubleToStrictInt52): 2016-01-22 Saam barati Current implementation of Parser::createSavePoint is a foot gun https://bugs.webkit.org/show_bug.cgi?id=153293 Reviewed by Oliver Hunt. The previous use of SavePoint (up until this patch) really meant that we're saving the LexerState. This was so poorly named that it was being misused all over our parser. For example, anything that parsed an AssignmentExpression between saving/restoring really wanted to save both Lexer state and Parser state. This patch changes SavePoint to mean save all the state. The old SavePoint is renamed to LexerState with corresponding internalLexerState functions. The old State() function is renamed to internalParserState(). * parser/Parser.cpp: (JSC::Parser::Parser): (JSC::Parser::parseInner): (JSC::Parser::isArrowFunctionParameters): (JSC::Parser::parseSourceElements): (JSC::Parser::declareRestOrNormalParameter): (JSC::Parser::parseAssignmentElement): (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseForStatement): (JSC::Parser::parseStatement): (JSC::Parser::parseFunctionParameters): (JSC::Parser::parseFunctionInfo): (JSC::Parser::parseClass): (JSC::Parser::parseExpression): (JSC::Parser::parseAssignmentExpression): (JSC::Parser::parseYieldExpression): (JSC::Parser::parseConditionalExpression): (JSC::Parser::parseBinaryExpression): (JSC::Parser::parseObjectLiteral): (JSC::Parser::parseStrictObjectLiteral): (JSC::Parser::parseArrayLiteral): (JSC::Parser::parsePrimaryExpression): (JSC::Parser::parseMemberExpression): (JSC::Parser::parseUnaryExpression): * parser/Parser.h: (JSC::Parser::hasError): (JSC::Parser::internalSaveParserState): (JSC::Parser::restoreParserState): (JSC::Parser::internalSaveLexerState): (JSC::Parser::restoreLexerState): (JSC::Parser::createSavePointForError): (JSC::Parser::createSavePoint): (JSC::Parser::restoreSavePointWithError): (JSC::Parser::restoreSavePoint): (JSC::Parser::saveState): Deleted. (JSC::Parser::restoreState): Deleted. 2016-01-22 Keith Miller Unreviewed. fnormal => normal. * tests/es6.yaml: 2016-01-22 Keith Miller Unreviewed. Forgot to git stash pop some of the changes. This should mark the rest of the es6 tests as passing. * tests/es6.yaml: 2016-01-22 Keith Miller Unreviewed. Mark es6 tests as passing. * tests/es6.yaml: 2016-01-22 Saam barati op_profile_type 32-bit LLInt implementation has a bug https://bugs.webkit.org/show_bug.cgi?id=153368 Reviewed by Michael Saboff. r189293 changed which registers were used, specifically using t5 instead of t4. That change forgot to replace t4 with t5 in one specific instance. * llint/LowLevelInterpreter32_64.asm: 2016-01-22 Filip Pizlo B3 should reduce obvious forms of Shl(SShr) https://bugs.webkit.org/show_bug.cgi?id=153362 Reviewed by Mark Lam and Saam Barati. This is a 40% speed-up in AsmBench-0.9/dry.c.js. * b3/B3ReduceStrength.cpp: * b3/testb3.cpp: (JSC::B3::testStore16Load16Z): (JSC::B3::testSShrShl32): (JSC::B3::testSShrShl64): (JSC::B3::zero): (JSC::B3::run): 2016-01-22 Alex Christensen Fix internal Windows build https://bugs.webkit.org/show_bug.cgi?id=153364 Reviewed by Brent Fulgham. * PlatformWin.cmake: The internal build does not build JavaScriptCore with WTF, so it does not automatically link to winmm.lib like it does when everything is built together. 2016-01-22 Keith Miller Equivalence PropertyCondition needs to check the offset it uses to load the value from is not invalidOffset https://bugs.webkit.org/show_bug.cgi?id=152912 Reviewed by Mark Lam. When checking the validity of an Equivalence PropertyCondition we do not check that the offset returned by the structure of the object in the equivalence condition is valid. The offset might be wrong for many reasons. The one we now test for is when the GlobalObject has a property that becomes a variable the property is deleted thus the offset is now invalid. * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint): * tests/stress/global-property-into-variable-get-from-scope.js: Added. 2016-01-22 Keith Miller [ES6] Add Symbol.species properties to the relevant constructors https://bugs.webkit.org/show_bug.cgi?id=153339 Reviewed by Michael Saboff. This patch adds Symbol.species to the RegExp, Array, TypedArray, Map, Set, ArrayBuffer, and Promise constructors. The functions that use these properties will be added in a later patch. * builtins/GlobalObject.js: (speciesGetter): * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::finishCreation): * runtime/ArrayConstructor.h: (JSC::ArrayConstructor::create): * runtime/BooleanConstructor.h: (JSC::BooleanConstructor::create): * runtime/CommonIdentifiers.h: * runtime/DateConstructor.h: (JSC::DateConstructor::create): * runtime/ErrorConstructor.h: (JSC::ErrorConstructor::create): * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::finishCreation): (JSC::JSArrayBufferConstructor::create): * runtime/JSArrayBufferConstructor.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSInternalPromiseConstructor.cpp: (JSC::JSInternalPromiseConstructor::create): * runtime/JSInternalPromiseConstructor.h: * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::create): (JSC::JSPromiseConstructor::finishCreation): * runtime/JSPromiseConstructor.h: * runtime/JSTypedArrayViewConstructor.cpp: (JSC::JSTypedArrayViewConstructor::finishCreation): (JSC::JSTypedArrayViewConstructor::create): Deleted. * runtime/JSTypedArrayViewConstructor.h: (JSC::JSTypedArrayViewConstructor::create): * runtime/MapConstructor.cpp: (JSC::MapConstructor::finishCreation): * runtime/MapConstructor.h: (JSC::MapConstructor::create): * runtime/NumberConstructor.h: (JSC::NumberConstructor::create): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::finishCreation): * runtime/RegExpConstructor.h: (JSC::RegExpConstructor::create): * runtime/SetConstructor.cpp: (JSC::SetConstructor::finishCreation): * runtime/SetConstructor.h: (JSC::SetConstructor::create): * runtime/StringConstructor.h: (JSC::StringConstructor::create): * runtime/SymbolConstructor.h: (JSC::SymbolConstructor::create): * runtime/WeakMapConstructor.h: (JSC::WeakMapConstructor::create): * runtime/WeakSetConstructor.h: (JSC::WeakSetConstructor::create): * tests/stress/symbol-species.js: Added. (testSymbolSpeciesOnConstructor): 2016-01-21 Benjamin Poulain [JSC] The IRC allocator can mess up the degree of Tmps interfering with move-related Tmps https://bugs.webkit.org/show_bug.cgi?id=153340 Reviewed by Filip Pizlo. The JavaScriptCore tests uncovered an interested bug in the iterated register coalescing allocator. When coalescing a move under the right conditions, it is possible to mess-up the graph for the Tmps interfering with the coalesced Tmps. Some context first: -When coalescing a move, we alias one Tmp to another. Let say that we had Move X, Y the coalescing may alias Y to X: Y->X. -Since X and Y are equivalent after coalescing, any interference edge with Y is "moved" to X. The way this was done was to add an edge to X for every edge there was with Y. Say we had an edge R--Y, we add an edge R--X. Adding an edge increases the degree of R and Y. The degree of R was then fixed by calling decrementDegree() on it. -decrementDegree() is non trivial. It will move the Tmp to the right list for further processing if the Tmp's degree becomes lower than the number of available registers. The bug appear in a particular case. Say we have 3 Tmp, A, B, and C. -A and B are move related, they can be coalesced. -A has an interference edge with C. -B does not have and interfence edge with C. -C's degree is exactly the number of avaialble registers/colors minus one (k - 1). -> This implies C is already in its list. We coalesce A and B into B (A->B). -The first step, addEdgeDistinct() adds an edge between B and C. The degrees of B and C are increased by one. The degree of C becomes k. -Next, decrementDegree() is called on C. Its degree decreases to k-1. Because of the change from k to k-1, decrementDegree() adds C to a list again. We have two kinds of bugs depending on the test: -A Tmp can be added to the simplifyWorklist several time. -A Tmp can be in both simplifyWorklist and freezeWorklist (because its move-related status changed since the last decrementDegree()). In both cases, the Tmps interfering with the duplicated Tmp will end up with a degree lower than their real value. * b3/air/AirIteratedRegisterCoalescing.cpp: 2016-01-21 Andreas Kling Add some missing WTF_MAKE_FAST_ALLOCATED in JavaScriptCore. Reviewed by Alex Christensen. Saw these things getting system malloc()'ed in an Instruments trace. * inspector/InspectorAgentBase.h: * jit/CallFrameShuffleData.h: * jit/CallFrameShuffler.h: * jit/RegisterAtOffsetList.h: * runtime/GenericOffset.h: 2016-01-21 Yusuke Suzuki [ES6] Catch parameter should accept BindingPattern https://bugs.webkit.org/show_bug.cgi?id=152385 Reviewed by Saam Barati. This patch implements destructuring in catch parameter. Catch parameter accepts binding pattern and binding identifier. It creates lexical bindings. And "yield" and "let" are specially handled as is the same to function parameters. In addition to that, we make destructuring parsing errors more descriptive. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitPushCatchScope): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::TryNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createTryStatement): * parser/NodeConstructors.h: (JSC::TryNode::TryNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::Parser::createBindingPattern): (JSC::Parser::tryParseDestructuringPatternExpression): (JSC::Parser::parseBindingOrAssignmentElement): (JSC::destructuringKindToVariableKindName): (JSC::Parser::parseDestructuringPattern): (JSC::Parser::parseTryStatement): (JSC::Parser::parseFormalParameters): (JSC::Parser::parseFunctionParameters): * parser/Parser.h: (JSC::Parser::destructuringKindFromDeclarationType): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createTryStatement): * tests/es6.yaml: * tests/es6/destructuring_in_catch_heads.js: Added. (test): * tests/stress/catch-parameter-destructuring.js: Added. (shouldBe): (shouldThrow): (prototype.call): (catch): (shouldThrow.try.throw.get error): (initialize): (array): (generator.gen): (generator): * tests/stress/catch-parameter-syntax.js: Added. (testSyntax): (testSyntaxError): * tests/stress/reserved-word-with-escape.js: (testSyntaxError.String.raw.a): (String.raw.SyntaxError.Cannot.use.the.keyword.string_appeared_here.as.a.name): * tests/stress/yield-named-variable.js: 2016-01-21 Filip Pizlo Unreviewed, fix build. * b3/B3EliminateCommonSubexpressions.cpp: 2016-01-21 Filip Pizlo B3 CSE should be able to match a full redundancy even if none of the matches dominate the value in question https://bugs.webkit.org/show_bug.cgi?id=153321 Reviewed by Benjamin Poulain. I once learned that LLVM's GVN can manufacture Phi functions. I don't know the details but I'm presuming that it involves: if (p) tmp1 = *ptr else tmp2 = *ptr tmp3 = *ptr // Replace this with Phi(tmp1, tmp2). This adds such an optimization to our CSE. The idea is that we search through basic blocks until we find the value we want, a side effect, or the start of the procedure. If we find a value that matches our search criteria, we record it and ignore the predecessors. If we find a side effect or the start of the procedure, we give up the whole search. This ensures that if we come out of the search without giving up, we'll have a set of matches that are fully redundant. CSE could then create a Phi graph by using SSACalculator. But the recent work on FixSSA revealed a much more exciting option: create a stack slot! In case there is more than one match, CSE now creates a stack slot that each match stores to, and replaces the redundant instruction with a loadfrom the stack slot. The stack slot is anonymous, which ensures that FixSSA will turn it into an optimal Phi graph or whatever. This is a significant speed-up on Octane/richards. * b3/B3DuplicateTails.cpp: * b3/B3EliminateCommonSubexpressions.cpp: * b3/B3FixSSA.cpp: (JSC::B3::fixSSA): * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3Procedure.h: (JSC::B3::Procedure::setFrontendData): (JSC::B3::Procedure::frontendData): * b3/testb3.cpp: * ftl/FTLState.cpp: (JSC::FTL::State::State): 2016-01-21 Filip Pizlo Air should know that CeilDouble has the partial register stall issue https://bugs.webkit.org/show_bug.cgi?id=153338 Rubber stamped by Benjamin Poulain. This is a 8% speed-up on Kraken with B3 enabled, mostly because of a 2.4x speed-up on audio-oscillator. * b3/air/AirFixPartialRegisterStalls.cpp: 2016-01-21 Andy VanWagoner [INTL] Implement Array.prototype.toLocaleString in ECMA-402 https://bugs.webkit.org/show_bug.cgi?id=147614 Reviewed by Benjamin Poulain. The primary changes in the ECMA-402 version, and the existing implementation are passing the arguments on to each element's toLocaleString call, and missing/undefined/null elements become empty string instead of being skipped. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncToLocaleString): 2016-01-21 Per Arne Vollan [B3][Win64] Compile fixes. https://bugs.webkit.org/show_bug.cgi?id=153312 Reviewed by Alex Christensen. Since MSVC has several overloads of sin, cos, pow, and log, we need to specify which one we want to use. * ftl/FTLB3Output.h: (JSC::FTL::Output::doubleSin): (JSC::FTL::Output::doubleCos): (JSC::FTL::Output::doublePow): (JSC::FTL::Output::doubleLog): 2016-01-21 Benjamin Poulain [JSC] foldPathConstants() makes invalid assumptions with Switch https://bugs.webkit.org/show_bug.cgi?id=153324 Reviewed by Filip Pizlo. If a Switch() has two cases pointing to the same basic block, foldPathConstants() was adding two override for that block with two different constants. If the block with the Switch dominates the target, both override were equally valid and we were assuming any of the constants as the value in the target block. See testSwitchTargettingSameBlockFoldPathConstant() for an example that breaks. This patch adds checks to ignore any block that is reached more than once by the control value. * b3/B3FoldPathConstants.cpp: * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/testb3.cpp: (JSC::B3::testSwitchTargettingSameBlock): (JSC::B3::testSwitchTargettingSameBlockFoldPathConstant): (JSC::B3::run): 2016-01-21 Filip Pizlo Unreviewed, undo DFGCommon.h change that accidentally enabled the B3 JIT. * dfg/DFGCommon.h: 2016-01-21 Filip Pizlo Move32 should have an Imm, Tmp form https://bugs.webkit.org/show_bug.cgi?id=153313 Reviewed by Mark Lam. This enables some useful optimizations, like constant propagation in fixObviousSpills(). * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::zeroExtend32ToPtr): (JSC::MacroAssemblerX86Common::move): * b3/air/AirOpcode.opcodes: 2016-01-21 Filip Pizlo B3 should have load elimination https://bugs.webkit.org/show_bug.cgi?id=153288 Reviewed by Geoffrey Garen. This adds a complete GCSE pass that includes load elimination. It would have been super hard to make this work as part of the reduceStrength() fixpoint, since GCSE needs to analyze control flow and reduceStrength() is messing with control flow. So, I did a compromise: I factored out the pure CSE that reduceStrength() was already doing, and now we have: - reduceStrength() still does pure CSE using the new PureCSE helper. - eliminateCommonSubexpressions() is a separate phase that does general CSE. It uses the PureCSE helper for pure values and does its own special thing for memory values. Unfortunately, this doesn't help any benchmark right now. It doesn't hurt anything, either, and it's likely to become a bigger pay-off once we implement other features, like mapping FTL's abstract heaps onto B3's heap ranges. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3EliminateCommonSubexpressions.cpp: Added. (JSC::B3::eliminateCommonSubexpressions): * b3/B3EliminateCommonSubexpressions.h: Added. * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3HeapRange.h: (JSC::B3::HeapRange::HeapRange): * b3/B3InsertionSet.h: (JSC::B3::InsertionSet::InsertionSet): (JSC::B3::InsertionSet::isEmpty): (JSC::B3::InsertionSet::code): (JSC::B3::InsertionSet::appendInsertion): * b3/B3MemoryValue.h: * b3/B3PureCSE.cpp: Added. (JSC::B3::PureCSE::PureCSE): (JSC::B3::PureCSE::~PureCSE): (JSC::B3::PureCSE::clear): (JSC::B3::PureCSE::process): * b3/B3PureCSE.h: Added. * b3/B3ReduceStrength.cpp: * b3/B3ReduceStrength.h: * b3/B3Validate.cpp: 2016-01-21 Keith Miller Fix bug in TypedArray.prototype.set and add tests https://bugs.webkit.org/show_bug.cgi?id=153309 Reviewed by Michael Saboff. This patch fixes an issue with TypedArray.prototype.set where we would assign a double to an unsigned without checking that the double was in the range of the unsigned. Additionally, the patch also adds tests for set for cases that were not covered before. * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncSet): * tests/stress/typedarray-set.js: Added. 2016-01-19 Ada Chan Make it possible to enable VIDEO_PRESENTATION_MODE on other Cocoa platforms. https://bugs.webkit.org/show_bug.cgi?id=153218 Reviewed by Eric Carlson. * Configurations/FeatureDefines.xcconfig: 2016-01-21 Per Arne Vollan [B3][CMake] Add missing source file. https://bugs.webkit.org/show_bug.cgi?id=153303 Reviewed by Csaba Osztrogonác. * CMakeLists.txt: 2016-01-20 Commit Queue Unreviewed, rolling out r195375. https://bugs.webkit.org/show_bug.cgi?id=153300 Caused crashes on GuardMalloc (Requested by ap on #webkit). Reverted changeset: "TypedArray's .buffer does not return the JSArrayBuffer that was passed to it on creation." https://bugs.webkit.org/show_bug.cgi?id=153281 http://trac.webkit.org/changeset/195375 2016-01-19 Filip Pizlo B3 should have basic path specialization https://bugs.webkit.org/show_bug.cgi?id=153200 Reviewed by Benjamin Poulain. This adds two different kind of path specializations: - Check(Select) where the Select results are constants is specialized into a Branch instead of a Select and duplicated paths where the results of the Select are folded. - Tail duplication. A jump to a small block causes the block's contents to be copied over the Jump. Both optimizations required being able to clone Values. We can now do that using proc.clone(value). Check(Select) specialization needed some utilities for walking graphs of Values. Tail duplication needed SSA fixup, so I added a way to demote values to anonymous stack slots (B3's equivalent of non-SSA variables) and a way to "fix SSA", i.e. to allocate anonymous stack slots to SSA values along with an optimal Phi graph. This is a big speed-up on Octane/deltablue. It's a 2.2% speed-up on Octane overall. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3ArgumentRegValue.cpp: (JSC::B3::ArgumentRegValue::dumpMeta): (JSC::B3::ArgumentRegValue::cloneImpl): * b3/B3ArgumentRegValue.h: * b3/B3BasicBlock.cpp: (JSC::B3::BasicBlock::append): (JSC::B3::BasicBlock::appendNonTerminal): (JSC::B3::BasicBlock::removeLast): * b3/B3BasicBlock.h: (JSC::B3::BasicBlock::values): * b3/B3BasicBlockInlines.h: (JSC::B3::BasicBlock::appendNew): (JSC::B3::BasicBlock::appendNewNonTerminal): (JSC::B3::BasicBlock::replaceLastWithNew): * b3/B3BlockInsertionSet.h: * b3/B3BreakCriticalEdges.cpp: Added. (JSC::B3::breakCriticalEdges): * b3/B3BreakCriticalEdges.h: Added. * b3/B3CCallValue.cpp: (JSC::B3::CCallValue::~CCallValue): (JSC::B3::CCallValue::cloneImpl): * b3/B3CCallValue.h: * b3/B3CheckValue.cpp: (JSC::B3::CheckValue::convertToAdd): (JSC::B3::CheckValue::cloneImpl): (JSC::B3::CheckValue::CheckValue): * b3/B3CheckValue.h: * b3/B3Const32Value.cpp: (JSC::B3::Const32Value::dumpMeta): (JSC::B3::Const32Value::cloneImpl): * b3/B3Const32Value.h: * b3/B3Const64Value.cpp: (JSC::B3::Const64Value::dumpMeta): (JSC::B3::Const64Value::cloneImpl): * b3/B3Const64Value.h: * b3/B3ConstDoubleValue.cpp: (JSC::B3::ConstDoubleValue::dumpMeta): (JSC::B3::ConstDoubleValue::cloneImpl): * b3/B3ConstDoubleValue.h: * b3/B3ConstFloatValue.cpp: (JSC::B3::ConstFloatValue::dumpMeta): (JSC::B3::ConstFloatValue::cloneImpl): * b3/B3ConstFloatValue.h: * b3/B3ControlValue.cpp: (JSC::B3::ControlValue::dumpMeta): (JSC::B3::ControlValue::cloneImpl): * b3/B3ControlValue.h: * b3/B3DuplicateTails.cpp: Added. (JSC::B3::duplicateTails): * b3/B3DuplicateTails.h: Added. * b3/B3FixSSA.cpp: Added. (JSC::B3::demoteValues): (JSC::B3::fixSSA): * b3/B3FixSSA.h: Added. * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3IndexSet.h: (JSC::B3::IndexSet::Iterable::Iterable): (JSC::B3::IndexSet::values): (JSC::B3::IndexSet::indices): * b3/B3InsertionSet.cpp: (JSC::B3::InsertionSet::insertIntConstant): (JSC::B3::InsertionSet::insertBottom): (JSC::B3::InsertionSet::execute): * b3/B3InsertionSet.h: * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::run): (JSC::B3::Air::LowerToAir::tmp): * b3/B3MemoryValue.cpp: (JSC::B3::MemoryValue::dumpMeta): (JSC::B3::MemoryValue::cloneImpl): * b3/B3MemoryValue.h: * b3/B3OriginDump.cpp: Added. (JSC::B3::OriginDump::dump): * b3/B3OriginDump.h: (JSC::B3::OriginDump::OriginDump): (JSC::B3::OriginDump::dump): Deleted. * b3/B3PatchpointValue.cpp: (JSC::B3::PatchpointValue::dumpMeta): (JSC::B3::PatchpointValue::cloneImpl): (JSC::B3::PatchpointValue::PatchpointValue): * b3/B3PatchpointValue.h: * b3/B3Procedure.cpp: (JSC::B3::Procedure::addBlock): (JSC::B3::Procedure::clone): (JSC::B3::Procedure::addIntConstant): (JSC::B3::Procedure::addBottom): (JSC::B3::Procedure::addBoolConstant): (JSC::B3::Procedure::deleteValue): * b3/B3Procedure.h: * b3/B3ReduceStrength.cpp: * b3/B3SSACalculator.cpp: Added. (JSC::B3::SSACalculator::Variable::dump): (JSC::B3::SSACalculator::Variable::dumpVerbose): (JSC::B3::SSACalculator::Def::dump): (JSC::B3::SSACalculator::SSACalculator): (JSC::B3::SSACalculator::~SSACalculator): (JSC::B3::SSACalculator::reset): (JSC::B3::SSACalculator::newVariable): (JSC::B3::SSACalculator::newDef): (JSC::B3::SSACalculator::nonLocalReachingDef): (JSC::B3::SSACalculator::reachingDefAtTail): (JSC::B3::SSACalculator::dump): * b3/B3SSACalculator.h: Added. (JSC::B3::SSACalculator::Variable::index): (JSC::B3::SSACalculator::Variable::Variable): (JSC::B3::SSACalculator::Def::variable): (JSC::B3::SSACalculator::Def::block): (JSC::B3::SSACalculator::Def::value): (JSC::B3::SSACalculator::Def::Def): (JSC::B3::SSACalculator::variable): (JSC::B3::SSACalculator::computePhis): (JSC::B3::SSACalculator::phisForBlock): (JSC::B3::SSACalculator::reachingDefAtHead): * b3/B3StackSlotKind.h: * b3/B3StackSlotValue.cpp: (JSC::B3::StackSlotValue::dumpMeta): (JSC::B3::StackSlotValue::cloneImpl): * b3/B3StackSlotValue.h: * b3/B3SwitchValue.cpp: (JSC::B3::SwitchValue::dumpMeta): (JSC::B3::SwitchValue::cloneImpl): (JSC::B3::SwitchValue::SwitchValue): * b3/B3SwitchValue.h: * b3/B3UpsilonValue.cpp: (JSC::B3::UpsilonValue::dumpMeta): (JSC::B3::UpsilonValue::cloneImpl): * b3/B3UpsilonValue.h: * b3/B3Validate.cpp: * b3/B3Value.cpp: (JSC::B3::Value::replaceWithNop): (JSC::B3::Value::replaceWithPhi): (JSC::B3::Value::dump): (JSC::B3::Value::cloneImpl): (JSC::B3::Value::dumpChildren): (JSC::B3::Value::deepDump): * b3/B3Value.h: (JSC::B3::DeepValueDump::DeepValueDump): (JSC::B3::DeepValueDump::dump): (JSC::B3::deepDump): * b3/B3ValueInlines.h: (JSC::B3::Value::asNumber): (JSC::B3::Value::walk): * b3/B3ValueKey.cpp: (JSC::B3::ValueKey::intConstant): (JSC::B3::ValueKey::dump): * b3/B3ValueKey.h: (JSC::B3::ValueKey::ValueKey): (JSC::B3::ValueKey::opcode): (JSC::B3::ValueKey::type): (JSC::B3::ValueKey::childIndex): * b3/air/AirCode.h: (JSC::B3::Air::Code::forAllTmps): (JSC::B3::Air::Code::isFastTmp): * b3/air/AirIteratedRegisterCoalescing.cpp: * b3/air/AirUseCounts.h: (JSC::B3::Air::UseCounts::UseCounts): (JSC::B3::Air::UseCounts::operator[]): (JSC::B3::Air::UseCounts::dump): * b3/testb3.cpp: (JSC::B3::testSelectInvert): (JSC::B3::testCheckSelect): (JSC::B3::testCheckSelectCheckSelect): (JSC::B3::testPowDoubleByIntegerLoop): (JSC::B3::run): * runtime/Options.h: 2016-01-20 Benjamin Poulain [JSC] Fix a typo in the Air definition of CeilDouble/CeilFloat https://bugs.webkit.org/show_bug.cgi?id=153286 Reviewed by Mark Lam. * b3/air/AirOpcode.opcodes: The second argument should a Def. The previous definition was adding useless constraints on the allocation of the second argument. 2016-01-20 Benjamin Poulain [JSC] The register allocator can use a dangling pointer when selecting a spill candidate https://bugs.webkit.org/show_bug.cgi?id=153287 Reviewed by Mark Lam. A tricky bug I discovered while experimenting with live range breaking. We have the following initial conditions: -UseCounts is slow, so we only compute it once for all the iterations of the allocator. -The only new Tmps we create are for spills and refills. They are unspillable by definition so it is fine to not update UseCounts accordingly. But, in selectSpill(), we go over all the spill candidates and select the best one based on its score. The score() lambda uses useCounts, it cannot be used with a new Tmps created for something we already spilled. The first time we use score is correct, we started by skipping all the unspillable Tmps from the candidate. The next use was incorrect: we were checking unspillableTmps *after* calling score(). The existing tests did not catch this due to back luck. I added an assertion to find similar problems in the future. * b3/air/AirIteratedRegisterCoalescing.cpp: * b3/air/AirUseCounts.h: 2016-01-20 Saam barati Fix CLoop build after bug https://bugs.webkit.org/show_bug.cgi?id=152766 Unreviewed build fix. * inspector/agents/InspectorScriptProfilerAgent.h: 2016-01-20 Andy VanWagoner [INTL] Implement Date.prototype.toLocaleTimeString in ECMA-402 https://bugs.webkit.org/show_bug.cgi?id=147613 Reviewed by Darin Adler. Implement toLocaleTimeString in builtin JavaScript. * builtins/DatePrototype.js: (toLocaleTimeString.toDateTimeOptionsTimeTime): (toLocaleTimeString): * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): 2016-01-20 Saam barati Web Inspector: Hook the sampling profiler into the Timelines UI https://bugs.webkit.org/show_bug.cgi?id=152766 Reviewed by Joseph Pecoraro. This patch adds some necessary functions to SamplingProfiler::StackFrame to allow it to give data to the Inspector for the timelines UI. i.e, the sourceID of the executable of a stack frame. This patch also swaps in the SamplingProfiler in place of the LegacyProfiler inside InspectorScriptProfilerAgent. It adds the necessary protocol data to allow the SamplingProfiler's data to hook into the timelines UI. * debugger/Debugger.cpp: (JSC::Debugger::setProfilingClient): (JSC::Debugger::willEvaluateScript): (JSC::Debugger::didEvaluateScript): (JSC::Debugger::toggleBreakpoint): * debugger/Debugger.h: * debugger/ScriptProfilingScope.h: (JSC::ScriptProfilingScope::ScriptProfilingScope): (JSC::ScriptProfilingScope::~ScriptProfilingScope): * inspector/agents/InspectorScriptProfilerAgent.cpp: (Inspector::InspectorScriptProfilerAgent::willDestroyFrontendAndBackend): (Inspector::InspectorScriptProfilerAgent::startTracking): (Inspector::InspectorScriptProfilerAgent::stopTracking): (Inspector::InspectorScriptProfilerAgent::isAlreadyProfiling): (Inspector::InspectorScriptProfilerAgent::willEvaluateScript): (Inspector::InspectorScriptProfilerAgent::didEvaluateScript): (Inspector::InspectorScriptProfilerAgent::addEvent): (Inspector::buildSamples): (Inspector::InspectorScriptProfilerAgent::trackingComplete): (Inspector::buildAggregateCallInfoInspectorObject): Deleted. (Inspector::buildInspectorObject): Deleted. (Inspector::buildProfileInspectorObject): Deleted. * inspector/agents/InspectorScriptProfilerAgent.h: * inspector/protocol/ScriptProfiler.json: * jsc.cpp: (functionSamplingProfilerStackTraces): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::start): (JSC::SamplingProfiler::stop): (JSC::SamplingProfiler::clearData): (JSC::SamplingProfiler::StackFrame::displayName): (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests): (JSC::SamplingProfiler::StackFrame::startLine): (JSC::SamplingProfiler::StackFrame::startColumn): (JSC::SamplingProfiler::StackFrame::sourceID): (JSC::SamplingProfiler::StackFrame::url): (JSC::SamplingProfiler::stackTraces): (JSC::SamplingProfiler::stackTracesAsJSON): (JSC::displayName): Deleted. (JSC::SamplingProfiler::stacktracesAsJSON): Deleted. * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::StackFrame::StackFrame): (JSC::SamplingProfiler::getLock): (JSC::SamplingProfiler::setTimingInterval): (JSC::SamplingProfiler::totalTime): (JSC::SamplingProfiler::setStopWatch): (JSC::SamplingProfiler::stackTraces): Deleted. * tests/stress/sampling-profiler-anonymous-function.js: (platformSupportsSamplingProfiler.baz): (platformSupportsSamplingProfiler): * tests/stress/sampling-profiler-basic.js: (platformSupportsSamplingProfiler.nothing): (platformSupportsSamplingProfiler.top): * tests/stress/sampling-profiler/samplingProfiler.js: (doesTreeHaveStackTrace): 2016-01-20 Keith Miller TypedArray's .buffer does not return the JSArrayBuffer that was passed to it on creation. https://bugs.webkit.org/show_bug.cgi?id=153281 Reviewed by Geoffrey Garen. When creating an JSArrayBuffer we should make sure that the backing ArrayBuffer uses the new JSArrayBuffer as its wrapper. This causes issues when we get the buffer of a Typed Array created by passing a JSArrayBuffer as the backing ArrayBuffer does not have a reference to the original JSArrayBuffer and a new object is created. * runtime/JSArrayBuffer.cpp: (JSC::JSArrayBuffer::finishCreation): * tests/stress/typedarray-buffer-neutered.js: Added. (arrays.typedArrays.map): 2016-01-20 Andreas Kling Pack RegisterAtOffset harder. Reviewed by Michael Saboff. Pack the register index and the offset into a single pointer-sized word instead of two. This reduces memory consumption by 620 kB on mobile theverge.com. The packing doesn't succeed on MSVC for some reason, so I've left out the static assertion about class size in those builds. * jit/RegisterAtOffset.cpp: * jit/RegisterAtOffset.h: 2016-01-20 Per Arne Vollan [B3][Win64] Compile fix. https://bugs.webkit.org/show_bug.cgi?id=153278 Reviewed by Filip Pizlo. MSVC does not accept that a class declared as exported also have members declared as exported. * b3/B3Const32Value.h: * b3/B3ControlValue.h: 2016-01-19 Keith Miller [ES6] Fix various issues with TypedArrays. https://bugs.webkit.org/show_bug.cgi?id=153245 Reviewed by Geoffrey Garen. This patch fixes a couple of issues with TypedArrays: 1) We were not checking if a view had been neutered and throwing an error if it had in the our TypedArray.prototype functions. 2) The TypedArray.prototype.set function had a couple of minor issues with checking for the offset being negative. 3) The JSArrayBufferView class did not check if the backing store had been neutered when computing the offset even though the view's vector pointer had been set to NULL. This meant that under some conditions we could, occasionally, return a garbage number as the offset. Now, we only neuter views if the backing ArrayBuffer's view is actually transfered. * jsc.cpp: (GlobalObject::finishCreation): (functionNeuterTypedArray): * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::isNeutered): * runtime/JSArrayBufferViewInlines.h: (JSC::JSArrayBufferView::byteOffset): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncSet): (JSC::genericTypedArrayViewProtoFuncEntries): (JSC::genericTypedArrayViewProtoFuncCopyWithin): (JSC::genericTypedArrayViewProtoFuncFill): (JSC::genericTypedArrayViewProtoFuncIndexOf): (JSC::genericTypedArrayViewProtoFuncJoin): (JSC::genericTypedArrayViewProtoFuncKeys): (JSC::genericTypedArrayViewProtoFuncLastIndexOf): (JSC::genericTypedArrayViewProtoFuncReverse): (JSC::genericTypedArrayViewPrivateFuncSort): (JSC::genericTypedArrayViewProtoFuncSlice): (JSC::genericTypedArrayViewProtoFuncSubarray): (JSC::typedArrayViewProtoFuncValues): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::typedArrayViewPrivateFuncLength): (JSC::typedArrayViewPrivateFuncSort): Deleted. * tests/stress/typedarray-functions-with-neutered.js: Added. (getGetter): (unit): (args.new.Int32Array): (arrays.typedArrays.map): (checkProtoFunc.throwsCorrectError): (checkProtoFunc): (test): 2016-01-19 Andy VanWagoner [INTL] Implement Date.prototype.toLocaleDateString in ECMA-402 https://bugs.webkit.org/show_bug.cgi?id=147612 Reviewed by Benjamin Poulain. Implement toLocaleDateString in builtin JavaScript. Remove comments with spec steps, and instead link to the new HTML version of the spec. Avoids creating an extra empty object in the prototype chain of the options object in ToDateTimeOptions. The version used in toLocaleString was updated to match as well. * builtins/DatePrototype.js: (toLocaleString.toDateTimeOptionsAnyAll): (toLocaleString): (toLocaleDateString.toDateTimeOptionsDateDate): (toLocaleDateString): * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): 2016-01-19 Benjamin Poulain [JSC] fixSpillSlotZDef() crashes on ARM64 https://bugs.webkit.org/show_bug.cgi?id=153246 Reviewed by Geoffrey Garen. Moving an immediate to memory is not a valid instruction on ARM64. This patch adds a small workaround for this specific case: an instruction to zero a chunk of memory. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::storeZero32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::storeZero32): * b3/air/AirFixSpillSlotZDef.h: (JSC::B3::Air::fixSpillSlotZDef): * b3/air/AirOpcode.opcodes: 2016-01-19 Enrica Casucci Add support for DataDetectors in WK (iOS). https://bugs.webkit.org/show_bug.cgi?id=152989 rdar://problem/22855960 Reviewed by Tim Horton. Adding feature definition for data detection. * Configurations/FeatureDefines.xcconfig: 2016-01-19 Per Arne Vollan [B3][Win64] Compile and warning fixes. https://bugs.webkit.org/show_bug.cgi?id=153234 Reviewed by Alex Christensen. The size of 'long' is 4 bytes on Win64. We can use 'long long' instead, when we want the size to be 8 bytes. * b3/B3LowerMacrosAfterOptimizations.cpp: * b3/B3ReduceStrength.cpp: 2016-01-19 Csaba Osztrogonác [cmake] Fix the B3 build after r195159 https://bugs.webkit.org/show_bug.cgi?id=153232 Reviewed by Yusuke Suzuki. * CMakeLists.txt: 2016-01-19 Commit Queue Unreviewed, rolling out r195300. https://bugs.webkit.org/show_bug.cgi?id=153244 enrica wants more time to fix Windows (Requested by thorton on #webkit). Reverted changeset: "Add support for DataDetectors in WK (iOS)." https://bugs.webkit.org/show_bug.cgi?id=152989 http://trac.webkit.org/changeset/195300 2016-01-19 Filip Pizlo Reconsider B3's constant motion policy https://bugs.webkit.org/show_bug.cgi?id=152202 Reviewed by Geoffrey Garen. This changes moveConstants() to hoist constants. This is a speed-up on things like mandreel. It has a generally positive impact on the Octane score, but it's within margin of error. This also changes IRC to make it a bit more likely to spill constants. We don't want it to spill them too much, because we can't rely on fixObviousSpills() to always replace a load of a constant from the stack with the constant itself, especially in case of instructions that need an extra register to materialize the immediate. Also fixed DFG graph dumping to print a bit less things. It was trying to print the results of constant property inference, and this sometimes caused crashes when you dumped the graph at an inopportune time. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3MoveConstants.cpp: * b3/air/AirArg.h: * b3/air/AirArgInlines.h: Added. (JSC::B3::Air::ArgThingHelper::is): (JSC::B3::Air::ArgThingHelper::as): (JSC::B3::Air::ArgThingHelper::forEachFast): (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): (JSC::B3::Air::Arg::as): (JSC::B3::Air::Arg::forEachFast): (JSC::B3::Air::Arg::forEach): * b3/air/AirIteratedRegisterCoalescing.cpp: * b3/air/AirUseCounts.h: (JSC::B3::Air::UseCounts::UseCounts): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): 2016-01-19 Enrica Casucci Add support for DataDetectors in WK (iOS). https://bugs.webkit.org/show_bug.cgi?id=152989 rdar://problem/22855960 Reviewed by Tim Horton. Adding feature definition. * Configurations/FeatureDefines.xcconfig: 2016-01-17 Filip Pizlo FTL B3 should be just as fast as FTL LLVM on Octane/crypto https://bugs.webkit.org/show_bug.cgi?id=153113 Reviewed by Saam Barati. This is the result of a hacking rampage to close the gap between FTL B3 and FTL LLVM on Octane/crypto. It was a very successful rampage. The biggest change in this patch is the introduction of a phase called fixObviousSpills() that fixes patterns like: Store register to stack slot and then use stack slot: Move %rcx, (stack42) Foo use:(stack42) // replace (stack42) with %rcx here. Load stack slot into register and then use stack slot: Move (stack42), %rcx Foo use:(stack42) // replace (stack42) with %rcx here. Store constant into stack slot and then use stack slot: Move $42, %rcx Move %rcx, (stack42) Bar def:%rcx // %rcx isn't available anymore, but we still know that (stack42) is $42 Foo use:(stack42) // replace (stack42) with $42 here. This phases does these fixups by doing a global forward flow that propagates sets of must-aliases. Also added a phase to report register pressure. It pretty-prints code alongside the set of in-use registers above each instruction. Using this phase, I found that our register allocator is actually doing a pretty awesome job. I had previously feared that we'd have to make substantial changes to register allocation. I don't have such a fear anymore, at least for Octane/crypto. In the future, we can check how the regalloc is performing just by enabling logAirRegisterPressure. Also fixed some FTL codegen pathologies. We were using bitOr where we meant to use a conditional or. LLVM likes to canonicalize boolean expressions this way. B3, on the other hand, doesn't do this canonicalization and doesn't have logic to decompose it into sequences of branches. Also added strength reductions for checked arithmetic. It turns out that LLVM learned how to reduce checked multiply to unchecked multiply in some obvious cases that our existing DFG optimizations lacked. Ideally, our DFG integer range optimization phase would cover this. But the cases of interest were dead simple - the incoming values to the CheckMul were obviously too small to cause overflow. I added such reasoning to B3's strength reduction. Finally, this fixes some bugs with how we were handling subwidth spill slots. The register allocator was making two mistakes. First, it might cause a Width64 def or use of a 4-byte spill slot. In that case, it would extend the size of the spill slot to ensure that the use or def is safe. Second, it emulates ZDef on Tmp behavior by emitting a Move32 to initialize the high bits of a spill slot. But this is unsound because of the liveness semantics of spill slots. They cannot have more than one def to initialize their value. I fixed that by making allocateStack() be the thing that fixes ZDefs. That's a change to ZDef semantics: now, ZDef on an anonymous stack slot means that the high bits are zero-filled. I wasn't able to construct a test for this. It might be a hypothetical bug, but still, I like how this simplifies the register allocator. This is a ~0.7% speed-up on Octane. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::hiddenBranch): (JSC::B3::CheckSpecial::forEachArg): (JSC::B3::CheckSpecial::commitHiddenBranch): Deleted. * b3/B3CheckSpecial.h: * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::fillStackmap): (JSC::B3::Air::LowerToAir::lower): * b3/B3StackmapValue.h: * b3/air/AirAllocateStack.cpp: (JSC::B3::Air::allocateStack): * b3/air/AirAllocateStack.h: * b3/air/AirArg.h: (JSC::B3::Air::Arg::callArg): (JSC::B3::Air::Arg::stackAddr): (JSC::B3::Air::Arg::isValidScale): * b3/air/AirBasicBlock.cpp: (JSC::B3::Air::BasicBlock::deepDump): (JSC::B3::Air::BasicBlock::dumpHeader): (JSC::B3::Air::BasicBlock::dumpFooter): * b3/air/AirBasicBlock.h: * b3/air/AirCCallSpecial.cpp: (JSC::B3::Air::CCallSpecial::CCallSpecial): (JSC::B3::Air::CCallSpecial::~CCallSpecial): * b3/air/AirCode.h: (JSC::B3::Air::Code::lastPhaseName): (JSC::B3::Air::Code::setEnableRCRS): (JSC::B3::Air::Code::enableRCRS): * b3/air/AirCustom.cpp: (JSC::B3::Air::PatchCustom::isValidForm): (JSC::B3::Air::CCallCustom::isValidForm): * b3/air/AirCustom.h: (JSC::B3::Air::PatchCustom::isValidFormStatic): (JSC::B3::Air::PatchCustom::admitsStack): (JSC::B3::Air::PatchCustom::isValidForm): Deleted. * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::ShufflePair::dump): (JSC::B3::Air::createShuffle): (JSC::B3::Air::emitShuffle): * b3/air/AirEmitShuffle.h: * b3/air/AirFixObviousSpills.cpp: Added. (JSC::B3::Air::fixObviousSpills): * b3/air/AirFixObviousSpills.h: Added. * b3/air/AirFixSpillSlotZDef.h: Removed. * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): (JSC::B3::Air::generate): * b3/air/AirHandleCalleeSaves.cpp: (JSC::B3::Air::handleCalleeSaves): * b3/air/AirInst.h: * b3/air/AirInstInlines.h: (JSC::B3::Air::Inst::reportUsedRegisters): (JSC::B3::Air::Inst::admitsStack): (JSC::B3::Air::isShiftValid): * b3/air/AirIteratedRegisterCoalescing.cpp: * b3/air/AirLiveness.h: (JSC::B3::Air::AbstractLiveness::AbstractLiveness): (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::begin): (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::end): (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::contains): (JSC::B3::Air::AbstractLiveness::LocalCalc::live): (JSC::B3::Air::AbstractLiveness::LocalCalc::isLive): (JSC::B3::Air::AbstractLiveness::LocalCalc::execute): (JSC::B3::Air::AbstractLiveness::rawLiveAtHead): (JSC::B3::Air::AbstractLiveness::Iterable::begin): (JSC::B3::Air::AbstractLiveness::Iterable::end): (JSC::B3::Air::AbstractLiveness::Iterable::contains): (JSC::B3::Air::AbstractLiveness::liveAtTail): (JSC::B3::Air::AbstractLiveness::workset): * b3/air/AirLogRegisterPressure.cpp: Added. (JSC::B3::Air::logRegisterPressure): * b3/air/AirLogRegisterPressure.h: Added. * b3/air/AirOptimizeBlockOrder.cpp: (JSC::B3::Air::blocksInOptimizedOrder): (JSC::B3::Air::optimizeBlockOrder): * b3/air/AirOptimizeBlockOrder.h: * b3/air/AirReportUsedRegisters.cpp: (JSC::B3::Air::reportUsedRegisters): * b3/air/AirReportUsedRegisters.h: * b3/air/AirSpillEverything.cpp: (JSC::B3::Air::spillEverything): * b3/air/AirStackSlot.h: (JSC::B3::Air::StackSlot::isLocked): (JSC::B3::Air::StackSlot::index): (JSC::B3::Air::StackSlot::ensureSize): (JSC::B3::Air::StackSlot::alignment): * b3/air/AirValidate.cpp: * ftl/FTLB3Compile.cpp: (JSC::FTL::compile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMul): (JSC::FTL::DFG::LowerDFGToLLVM::compileArithDiv): (JSC::FTL::DFG::LowerDFGToLLVM::compileArithMod): * jit/RegisterSet.h: (JSC::RegisterSet::get): (JSC::RegisterSet::setAll): (JSC::RegisterSet::merge): (JSC::RegisterSet::filter): * runtime/Options.h: 2016-01-19 Filip Pizlo Unreviewed, undo unintended commit. * dfg/DFGCommon.h: 2016-01-18 Filip Pizlo Fix Air shuffling assertions https://bugs.webkit.org/show_bug.cgi?id=153213 Reviewed by Saam Barati. Fixes some assertions that I was seeing running JSC tests. Adds a new Air test. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::store8): (JSC::MacroAssemblerX86Common::getUnusedRegister): * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::emitShuffle): * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/testair.cpp: (JSC::B3::Air::testShuffleRotateWithFringe): (JSC::B3::Air::testShuffleRotateWithFringeInWeirdOrder): (JSC::B3::Air::testShuffleRotateWithLongFringe): (JSC::B3::Air::run): 2016-01-19 Konstantin Tokarev [mips] Logical instructions allow immediates in range 0..0xffff, not 0x7fff https://bugs.webkit.org/show_bug.cgi?id=152693 Reviewed by Michael Saboff. * offlineasm/mips.rb: 2016-01-18 Saam barati assertions in BytecodeUseDef.h about opcode length are off by one https://bugs.webkit.org/show_bug.cgi?id=153215 Reviewed by Dan Bernstein. * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): 2016-01-18 Saam barati FTL doesn't do proper spilling for exception handling when GetById/Snippets go to slow path https://bugs.webkit.org/show_bug.cgi?id=153186 Reviewed by Michael Saboff. Michael was investigating a bug he found while doing the new JSC calling convention work and it turns out to be a latent bug in FTL try/catch machinery. After I looked at the code again, I realized that what I had previously written is wrong in a subtle way. The FTL callOperation machinery will remove its result register from the set of registers it needs to spill. This is not correct when we have try/catch. We may want to do value recovery on the value that the result register is prior to the call after the call throws an exception. The case that we were solving before was when the resultRegister == baseRegister in a GetById, or left/rightRegister == resultRegister in a Snippet. This code is correct in wanting to spill in that case, even though it might spill when we don't need it to (i.e the result is not needed for value recovery). Once I investigated this bug further, I realized that the previous rule is just a partial subset of the rule that says we should spill anytime the result is a register we might do value recovery on. This patch implements the rule that says we always want to spill the result when we will do value recovery on it if an exception is thrown. * ftl/FTLCompile.cpp: (JSC::FTL::mmAllocateDataSection): * tests/stress/ftl-try-catch-getter-throw-interesting-value-recovery.js: Added. (assert): (random): (identity): (let.o2.get f): (let.o3.get f): (foo): (i.else): 2016-01-18 Konstantin Tokarev [MIPS] LLInt: fix calculation of Global Offset Table https://bugs.webkit.org/show_bug.cgi?id=150381 Offlineasm adds a .cpload $t9 when we create a label in MIPS, which computes address of GOT. However, this instruction requires $t9 to contain address of current function. So we need to set $t9 to pcBase, otherwise GOT-related calculations will be invalid. Since offlineasm does not allow direct move to $t9 on MIPS, added new instruction setcallreg which does exactly that. Reviewed by Michael Saboff. * llint/LowLevelInterpreter.asm: * offlineasm/instructions.rb: * offlineasm/mips.rb: 2016-01-18 Csaba Osztrogonác REGRESSION(r194601): Fix the jsc timeout option of jsc.cpp https://bugs.webkit.org/show_bug.cgi?id=153204 Reviewed by Michael Catanzaro. * jsc.cpp: (main): 2016-01-18 Csaba Osztrogonác [cmake] Add testair to the build system https://bugs.webkit.org/show_bug.cgi?id=153126 Reviewed by Michael Catanzaro. * shell/CMakeLists.txt: 2016-01-17 Jeremy Huddleston Sequoia Ensure that CF_AVAILABLE is undefined when building webkit-gtk https://bugs.webkit.org/show_bug.cgi?id=152720 This change ensures that CF_AVAILABLE is correctly a no-op to address build failure that was observed when building on older versions of OSX. Previously, CF_AVAILABLE may have been unexpectedly re-defined to the system header value based on include-order. Reviewed by Michael Catanzaro. * API/WebKitAvailability.h: 2016-01-17 Julien Brianceau [mips] Fix regT2 and regT3 trampling in MacroAssembler https://bugs.webkit.org/show_bug.cgi?id=153131 Mips $t2 and $t3 registers were used as temporary registers in MacroAssemblerMIPS.h, whereas they are mapped to regT2 and regT3 in LLInt and GPRInfo. This patch rearranges register mapping for the mips architecture: - use $t0 and $t1 as temp registers in LLInt (as in MacroAssembler) - use $t7 and $t8 as temp registers in MacroAssembler (as in LLInt) - remove $t6 from temp registers list in LLInt - update GPRInfo.h accordingly - add mips macroScratchRegisters() list in RegisterSet.cpp Reviewed by Michael Saboff. * assembler/MacroAssemblerMIPS.h: * jit/GPRInfo.h: (JSC::GPRInfo::toRegister): (JSC::GPRInfo::toIndex): * jit/RegisterSet.cpp: (JSC::RegisterSet::macroScratchRegisters): (JSC::RegisterSet::calleeSaveRegisters): * offlineasm/mips.rb: 2016-01-16 Skachkov Oleksandr [ES6] Arrow function syntax. Arrow function should support the destructuring parameters. https://bugs.webkit.org/show_bug.cgi?id=146934 Reviewed by Saam Barati. Added support of destructuring parameters, before arrow function expect only simple parameters, e.g. (), (x), (x, y) or x in assigment expressio. To support destructuring parameters added additional check that check for destructuring paramters if check does not pass for simple parameters. * parser/Parser.cpp: (JSC::Parser::isArrowFunctionParameters): (JSC::Parser::parseAssignmentExpression): * parser/Parser.h: 2016-01-15 Benjamin Poulain [JSC] Legalize Memory Offsets for ARM64 before lowering to Air https://bugs.webkit.org/show_bug.cgi?id=153065 Reviewed by Mark Lam. Reviewed by Filip Pizlo. On ARM64, we cannot use signed 32bits offset for memory addressing. There are two available addressing: signed 9bits and unsigned scaled 12bits. Air already knows about it. In this patch, the offsets are changed to something valid for ARM64 prior to lowering. When an offset is invalid, it is just computed before the instruction and used as the base for addressing. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3LegalizeMemoryOffsets.cpp: Added. (JSC::B3::legalizeMemoryOffsets): * b3/B3LegalizeMemoryOffsets.h: Added. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::effectiveAddr): Deleted. * b3/testb3.cpp: (JSC::B3::testLoadWithOffsetImpl): (JSC::B3::testLoadOffsetImm9Max): (JSC::B3::testLoadOffsetImm9MaxPlusOne): (JSC::B3::testLoadOffsetImm9MaxPlusTwo): (JSC::B3::testLoadOffsetImm9Min): (JSC::B3::testLoadOffsetImm9MinMinusOne): (JSC::B3::testLoadOffsetScaledUnsignedImm12Max): (JSC::B3::testLoadOffsetScaledUnsignedOverImm12Max): (JSC::B3::run): 2016-01-15 Alex Christensen Fix internal Windows build https://bugs.webkit.org/show_bug.cgi?id=153142 Reviewed by Brent Fulgham. The internal Windows build builds JavaScriptCore from a directory that is not called JavaScriptCore. Searching for JavaScriptCore/API/APICast.h fails because it is in SomethingElse/API/APICast.h. Since we are including the JavaScriptCore directory, it is not necessary to have JavaScriptCore in the forwarding headers, but removing it allows builds form directories that are not named JavaScriptCore. * ForwardingHeaders/JavaScriptCore/APICast.h: * ForwardingHeaders/JavaScriptCore/JSBase.h: * ForwardingHeaders/JavaScriptCore/JSCTestRunnerUtils.h: * ForwardingHeaders/JavaScriptCore/JSContextRef.h: * ForwardingHeaders/JavaScriptCore/JSObjectRef.h: * ForwardingHeaders/JavaScriptCore/JSRetainPtr.h: * ForwardingHeaders/JavaScriptCore/JSStringRef.h: * ForwardingHeaders/JavaScriptCore/JSStringRefCF.h: * ForwardingHeaders/JavaScriptCore/JSValueRef.h: * ForwardingHeaders/JavaScriptCore/JavaScript.h: * ForwardingHeaders/JavaScriptCore/JavaScriptCore.h: * ForwardingHeaders/JavaScriptCore/OpaqueJSString.h: * ForwardingHeaders/JavaScriptCore/WebKitAvailability.h: 2016-01-15 Per Arne Vollan [B3][Win64] Compile fixes. https://bugs.webkit.org/show_bug.cgi?id=153127 Reviewed by Alex Christensen. MSVC have several overloads of fmod, pow, and ceil. We need to suggest to MSVC which one we want to use. * b3/B3LowerMacros.cpp: * b3/B3LowerMacrosAfterOptimizations.cpp: * b3/B3MathExtras.cpp: (JSC::B3::powDoubleInt32): * b3/B3ReduceStrength.cpp: 2016-01-15 Filip Pizlo Air needs a Shuffle instruction https://bugs.webkit.org/show_bug.cgi?id=152952 Reviewed by Saam Barati. This adds an instruction called Shuffle. Shuffle allows you to simultaneously perform multiple moves to perform arbitrary permutations over registers and memory. We call these rotations. It also allows you to perform "shifts", like (a => b, b => c): after the shift, c will have b's old value, b will have a's old value, and a will be unchanged. Shifts can use immediates as their source. Shuffle is added as a custom instruction, since it has a variable number of arguments. It takes any number of triplets of arguments, where each triplet describes one mapping of the shuffle. For example, to represent (a => b, b => c), we might say: Shuffle %a, %b, 64, %b, %c, 64 Note the "64"s, those are width arguments that describe how many bits of the register are being moved. Each triplet is referred to as a "shuffle pair". We call it a pair because the most relevant part of it is the pair of registers or memroy locations (i.e. %a, %b form one of the pairs in the example). For GP arguments, the width follows ZDef semantics. In the future, we will be able to use Shuffle for a lot of things. This patch is modest about how to use it: - C calling convention argument marshalling. Previously we used move instructions. But that's problematic since it introduces artificial interference between the argument registers and the inputs. Using Shuffle removes that interference. This helps a bit. - Cold C calls. This is what really motivated me to write this patch. If we have a C call on a cold path, then we want it to appear to the register allocator like it doesn't clobber any registers. Only after register allocation should we handle the clobbering by simply saving all of the live volatile registers to the stack. If you imagine the saving and the argument marshalling, you can see how before the call, we want to have a Shuffle that does both of those things. This is important. If argument marshalling was separate from the saving, then we'd still appear to clobber argument registers. Doing them together as one Shuffle means that the cold call doesn't appear to even clobber the argument registers. Unfortunately, I was wrong about cold C calls being the dominant problem with our register allocator right now. Fixing this revealed other problems in my current tuning benchmark, Octane/encrypt. Nonetheless, this is a small speed-up across the board, and gives us some functionality we will need to implement other optimizations. Relanding after fixing production build. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/AbstractMacroAssembler.h: (JSC::isX86_64): (JSC::isIOS): (JSC::optimizeForARMv7IDIVSupported): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::zeroExtend32ToPtr): (JSC::MacroAssemblerX86Common::swap32): (JSC::MacroAssemblerX86Common::moveConditionally32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch): (JSC::MacroAssemblerX86_64::swap64): (JSC::MacroAssemblerX86_64::move64ToDouble): * assembler/X86Assembler.h: (JSC::X86Assembler::xchgl_rr): (JSC::X86Assembler::xchgl_rm): (JSC::X86Assembler::xchgq_rr): (JSC::X86Assembler::xchgq_rm): (JSC::X86Assembler::movl_rr): * b3/B3CCallValue.h: * b3/B3Compilation.cpp: (JSC::B3::Compilation::Compilation): (JSC::B3::Compilation::~Compilation): * b3/B3Compilation.h: (JSC::B3::Compilation::code): * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::run): (JSC::B3::Air::LowerToAir::createSelect): (JSC::B3::Air::LowerToAir::lower): (JSC::B3::Air::LowerToAir::marshallCCallArgument): Deleted. * b3/B3OpaqueByproducts.h: (JSC::B3::OpaqueByproducts::count): * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::isArgValidForValue): (JSC::B3::StackmapSpecial::isArgValidForRep): * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::isStackMemory): (JSC::B3::Air::Arg::isRepresentableAs): (JSC::B3::Air::Arg::usesTmp): (JSC::B3::Air::Arg::canRepresent): (JSC::B3::Air::Arg::isCompatibleType): (JSC::B3::Air::Arg::dump): (WTF::printInternal): * b3/air/AirArg.h: (JSC::B3::Air::Arg::forEachType): (JSC::B3::Air::Arg::isWarmUse): (JSC::B3::Air::Arg::cooled): (JSC::B3::Air::Arg::isEarlyUse): (JSC::B3::Air::Arg::imm64): (JSC::B3::Air::Arg::immPtr): (JSC::B3::Air::Arg::addr): (JSC::B3::Air::Arg::special): (JSC::B3::Air::Arg::widthArg): (JSC::B3::Air::Arg::operator==): (JSC::B3::Air::Arg::isImm64): (JSC::B3::Air::Arg::isSomeImm): (JSC::B3::Air::Arg::isAddr): (JSC::B3::Air::Arg::isIndex): (JSC::B3::Air::Arg::isMemory): (JSC::B3::Air::Arg::isRelCond): (JSC::B3::Air::Arg::isSpecial): (JSC::B3::Air::Arg::isWidthArg): (JSC::B3::Air::Arg::isAlive): (JSC::B3::Air::Arg::base): (JSC::B3::Air::Arg::hasOffset): (JSC::B3::Air::Arg::offset): (JSC::B3::Air::Arg::width): (JSC::B3::Air::Arg::isGPTmp): (JSC::B3::Air::Arg::isGP): (JSC::B3::Air::Arg::isFP): (JSC::B3::Air::Arg::isType): (JSC::B3::Air::Arg::isGPR): (JSC::B3::Air::Arg::isValidForm): (JSC::B3::Air::Arg::forEachTmpFast): * b3/air/AirBasicBlock.h: (JSC::B3::Air::BasicBlock::insts): (JSC::B3::Air::BasicBlock::appendInst): (JSC::B3::Air::BasicBlock::append): * b3/air/AirCCallingConvention.cpp: Added. (JSC::B3::Air::computeCCallingConvention): (JSC::B3::Air::cCallResult): (JSC::B3::Air::buildCCall): * b3/air/AirCCallingConvention.h: Added. * b3/air/AirCode.h: (JSC::B3::Air::Code::proc): * b3/air/AirCustom.cpp: Added. (JSC::B3::Air::CCallCustom::isValidForm): (JSC::B3::Air::CCallCustom::generate): (JSC::B3::Air::ShuffleCustom::isValidForm): (JSC::B3::Air::ShuffleCustom::generate): * b3/air/AirCustom.h: (JSC::B3::Air::PatchCustom::forEachArg): (JSC::B3::Air::PatchCustom::generate): (JSC::B3::Air::CCallCustom::forEachArg): (JSC::B3::Air::CCallCustom::isValidFormStatic): (JSC::B3::Air::CCallCustom::admitsStack): (JSC::B3::Air::CCallCustom::hasNonArgNonControlEffects): (JSC::B3::Air::ColdCCallCustom::forEachArg): (JSC::B3::Air::ShuffleCustom::forEachArg): (JSC::B3::Air::ShuffleCustom::isValidFormStatic): (JSC::B3::Air::ShuffleCustom::admitsStack): (JSC::B3::Air::ShuffleCustom::hasNonArgNonControlEffects): * b3/air/AirEmitShuffle.cpp: Added. (JSC::B3::Air::ShufflePair::dump): (JSC::B3::Air::emitShuffle): * b3/air/AirEmitShuffle.h: Added. (JSC::B3::Air::ShufflePair::ShufflePair): (JSC::B3::Air::ShufflePair::src): (JSC::B3::Air::ShufflePair::dst): (JSC::B3::Air::ShufflePair::width): * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): * b3/air/AirGenerate.h: * b3/air/AirInsertionSet.cpp: (JSC::B3::Air::InsertionSet::insertInsts): (JSC::B3::Air::InsertionSet::execute): * b3/air/AirInsertionSet.h: (JSC::B3::Air::InsertionSet::insertInst): (JSC::B3::Air::InsertionSet::insert): * b3/air/AirInst.h: (JSC::B3::Air::Inst::operator bool): (JSC::B3::Air::Inst::append): * b3/air/AirLowerAfterRegAlloc.cpp: Added. (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirLowerAfterRegAlloc.h: Added. * b3/air/AirLowerMacros.cpp: Added. (JSC::B3::Air::lowerMacros): * b3/air/AirLowerMacros.h: Added. * b3/air/AirOpcode.opcodes: * b3/air/AirRegisterPriority.h: (JSC::B3::Air::regsInPriorityOrder): * b3/air/testair.cpp: Added. (hiddenTruthBecauseNoReturnIsStupid): (usage): (JSC::B3::Air::compile): (JSC::B3::Air::invoke): (JSC::B3::Air::compileAndRun): (JSC::B3::Air::testSimple): (JSC::B3::Air::loadConstantImpl): (JSC::B3::Air::loadConstant): (JSC::B3::Air::loadDoubleConstant): (JSC::B3::Air::testShuffleSimpleSwap): (JSC::B3::Air::testShuffleSimpleShift): (JSC::B3::Air::testShuffleLongShift): (JSC::B3::Air::testShuffleLongShiftBackwards): (JSC::B3::Air::testShuffleSimpleRotate): (JSC::B3::Air::testShuffleSimpleBroadcast): (JSC::B3::Air::testShuffleBroadcastAllRegs): (JSC::B3::Air::testShuffleTreeShift): (JSC::B3::Air::testShuffleTreeShiftBackward): (JSC::B3::Air::testShuffleTreeShiftOtherBackward): (JSC::B3::Air::testShuffleMultipleShifts): (JSC::B3::Air::testShuffleRotateWithFringe): (JSC::B3::Air::testShuffleRotateWithLongFringe): (JSC::B3::Air::testShuffleMultipleRotates): (JSC::B3::Air::testShuffleShiftAndRotate): (JSC::B3::Air::testShuffleShiftAllRegs): (JSC::B3::Air::testShuffleRotateAllRegs): (JSC::B3::Air::testShuffleSimpleSwap64): (JSC::B3::Air::testShuffleSimpleShift64): (JSC::B3::Air::testShuffleSwapMixedWidth): (JSC::B3::Air::testShuffleShiftMixedWidth): (JSC::B3::Air::testShuffleShiftMemory): (JSC::B3::Air::testShuffleShiftMemoryLong): (JSC::B3::Air::testShuffleShiftMemoryAllRegs): (JSC::B3::Air::testShuffleShiftMemoryAllRegs64): (JSC::B3::Air::combineHiLo): (JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth): (JSC::B3::Air::testShuffleRotateMemory): (JSC::B3::Air::testShuffleRotateMemory64): (JSC::B3::Air::testShuffleRotateMemoryMixedWidth): (JSC::B3::Air::testShuffleRotateMemoryAllRegs64): (JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth): (JSC::B3::Air::testShuffleSwapDouble): (JSC::B3::Air::testShuffleShiftDouble): (JSC::B3::Air::run): (run): (main): * b3/testb3.cpp: (JSC::B3::testCallSimple): (JSC::B3::testCallRare): (JSC::B3::testCallRareLive): (JSC::B3::testCallSimplePure): (JSC::B3::run): 2016-01-15 Andy VanWagoner [INTL] Implement Date.prototype.toLocaleString in ECMA-402 https://bugs.webkit.org/show_bug.cgi?id=147611 Reviewed by Benjamin Poulain. Expose dateProtoFuncGetTime as thisTimeValue for builtins. Remove unused code in DateTimeFormat toDateTimeOptions, and make the function specific to the call in initializeDateTimeFormat. Properly throw when the options parameter is null. Add toLocaleString in builtin JavaScript, with it's own specific branch of toDateTimeOptions. * CMakeLists.txt: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/DatePrototype.js: Added. (toLocaleString.toDateTimeOptionsAnyAll): (toLocaleString): * runtime/CommonIdentifiers.h: * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): * runtime/DatePrototype.h: * runtime/IntlDateTimeFormat.cpp: (JSC::toDateTimeOptionsAnyDate): (JSC::IntlDateTimeFormat::initializeDateTimeFormat): (JSC::toDateTimeOptions): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): 2016-01-15 Konstantin Tokarev [mips] Implemented emitFunctionPrologue/Epilogue https://bugs.webkit.org/show_bug.cgi?id=152947 Reviewed by Michael Saboff. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::popPair): (JSC::MacroAssemblerMIPS::pushPair): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitFunctionPrologue): (JSC::AssemblyHelpers::emitFunctionEpilogueWithEmptyFrame): (JSC::AssemblyHelpers::emitFunctionEpilogue): 2016-01-15 Commit Queue Unreviewed, rolling out r195084. https://bugs.webkit.org/show_bug.cgi?id=153132 Broke Production build (Requested by ap on #webkit). Reverted changeset: "Air needs a Shuffle instruction" https://bugs.webkit.org/show_bug.cgi?id=152952 http://trac.webkit.org/changeset/195084 2016-01-15 Julien Brianceau [mips] Add countLeadingZeros32 implementation in macro assembler https://bugs.webkit.org/show_bug.cgi?id=152886 Revie