diff options
Diffstat (limited to 'Source/JavaScriptCore/ChangeLog-2013-04-24')
| -rw-r--r-- | Source/JavaScriptCore/ChangeLog-2013-04-24 | 29044 |
1 files changed, 29044 insertions, 0 deletions
diff --git a/Source/JavaScriptCore/ChangeLog-2013-04-24 b/Source/JavaScriptCore/ChangeLog-2013-04-24 new file mode 100644 index 000000000..d3b5d15cd --- /dev/null +++ b/Source/JavaScriptCore/ChangeLog-2013-04-24 @@ -0,0 +1,29044 @@ +2013-04-23 Filip Pizlo <fpizlo@apple.com> + + DFG CFA filters CheckFunction in a really weird way, and assumes that the function's structure won't change + https://bugs.webkit.org/show_bug.cgi?id=115077 + + Reviewed by Oliver Hunt. + + The filtering did three things that are unusual: + + 1) AbstractValue::filterByValue() assumed that the passed value's structure wouldn't change, in + the sense that at it assumed it could use that value's *current* structure to do structure + filtering. Filtering by structure only makes sense if you can prove that the given value will + always have that structure (for example by either using a watchpoing or emitting code that + checks that structure at run-time). + + 2) AbstractValue::filterByValue() and the CheckFunction case in AbstractState::executeEffects() + tried to invalidate the CFA based on whether the filtration led to an empty value. This is + well-intentioned, but it's not how the CFA currently works. It's inconsistent with other + parts of the CFA. We shouldn't introduce this feature into just one kind of filtration and + not have it elsewhere. + + 3) The attempt to detect when the value was empty was actually implemented incorrectly. It + relied on AbstractValue::validate(). That method says that a concrete value does not belong + to the abstract value if it has a different structure. This makes sense for the other place + where AbstractValue::validate() is called: during OSR entry, where we are talking about a + JSValue that we see *right now*. It doesn't make sense in the CFA, since in the CFA any + value we observe in the code is a value whose structure may change when the code starts + running, and so we cannot use the value's current structure to infer things about the code + when it starts running. + + I fixed the above problems by (1) changing filterByValue() to not filter the structure, (2) + changing filterByValue() and the CheckFunction case to not invalidate the CFA, and (3) + making sure that nobody else was misusing AbstractValue::validate() (they weren't). + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::executeEffects): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::filterByValue): + +2013-04-23 Oliver Hunt <oliver@apple.com> + + Default ParserError() initialiser doesn't initialise all fields + https://bugs.webkit.org/show_bug.cgi?id=115074 + + Reviewed by Joseph Pecoraro. + + Only the jsc command prompt depended on this, but we'll fix it to + be on the safe side. + + * parser/ParserError.h: + (JSC::ParserError::ParserError): + +2013-04-23 Christophe Dumez <ch.dumez@sisa.samsung.com> + + Global constructors should be configurable and not enumerable + https://bugs.webkit.org/show_bug.cgi?id=110573 + + Reviewed by Geoffrey Garen. + + Update JSObject::deleteProperty() so that mark to set the property + value to undefined if it is in static hashtable of properties. The + previous code was not doing anything in this case and this meant + we could not remove builtin DOMWindow properties such as + "ProgressEvent" even if marked as Deletable. + + * runtime/JSObject.cpp: + (JSC::JSObject::deleteProperty): + * runtime/Lookup.h: + (JSC): + (JSC::putEntry): + (JSC::lookupPut): + +2013-04-23 Geoffrey Garen <ggaren@apple.com> + + Filled out more cases of branch folding in bytecode when emitting + expressions into a branching context + https://bugs.webkit.org/show_bug.cgi?id=115057 + + Reviewed by Filip Pizlo. + + This covers a few cases like: + + - while (true) { } + - while (1) { } + - if (x) break; + - if (x) continue; + - if (boolean_expr == boolean_const) { } + - if (boolean_expr == 1_or_0) { } + - if (bitop == 1_or_0) { } + + This also works, but will bring shame on your family: + + - while ("hello world") { } + + No change on the benchmarks we track, but a 2.5X speedup on a microbenchmark + that uses these techniques. + + * JavaScriptCore.order: Order! + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitNewArray): + (JSC::BytecodeGenerator::emitThrowReferenceError): + (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded): + * bytecompiler/BytecodeGenerator.h: + (JSC::BytecodeGenerator::shouldEmitDebugHooks): Updated ancillary code + for interface simplifications. + + * bytecompiler/NodesCodegen.cpp: + (JSC::ConstantNode::emitBytecodeInConditionContext): Constants can + jump unconditionally when used within a condition context. + + (JSC::ConstantNode::emitBytecode): + (JSC::StringNode::jsValue): Gave constants a common base class so I + could implement their codegen just once. + + (JSC::BinaryOpNode::emitBytecodeInConditionContext): + (JSC::canFoldToBranch): + (JSC::BinaryOpNode::tryFoldToBranch): Fold (!/=)= and (!/=)== where + appropriate. A lot of cases are not appropriate because of the surprising + type conversion semantics of ==. For example, if (number == true) { } is + not the same as if (number) { } because the former will up-convert true + to number and then do numeric comparison. + + (JSC::singleStatement): + (JSC::IfElseNode::tryFoldBreakAndContinue): + (JSC::IfElseNode::emitBytecode): + (JSC::ContinueNode::trivialTarget): + (JSC::BreakNode::trivialTarget): Fold "if (expression) break" and + "if (expression) continue" into direct jumps from expression. + + * parser/ASTBuilder.h: + (ASTBuilder): + (JSC::ASTBuilder::createIfStatement): + * parser/NodeConstructors.h: + (JSC::ConstantNode::ConstantNode): + (JSC): + (JSC::NullNode::NullNode): + (JSC::BooleanNode::BooleanNode): + (JSC::NumberNode::NumberNode): + (JSC::StringNode::StringNode): + (JSC::IfElseNode::IfElseNode): + * parser/Nodes.h: + (JSC::ExpressionNode::isConstant): + (JSC::ExpressionNode::isBoolean): + (JSC::StatementNode::isBreak): + (JSC::StatementNode::isContinue): + (ConstantNode): + (JSC::ConstantNode::isPure): + (JSC::ConstantNode::isConstant): + (NullNode): + (JSC::NullNode::jsValue): + (JSC::BooleanNode::value): + (JSC::BooleanNode::isBoolean): + (JSC::BooleanNode::jsValue): + (JSC::NumberNode::value): + (NumberNode): + (JSC::NumberNode::jsValue): + (StringNode): + (BinaryOpNode): + (IfElseNode): + (ContinueNode): + (JSC::ContinueNode::isContinue): + (BreakNode): + (JSC::BreakNode::isBreak): + * parser/Parser.cpp: + (JSC::::parseIfStatement): + * parser/ResultType.h: + (JSC::ResultType::definitelyIsBoolean): + (ResultType): + * runtime/JSCJSValueInlines.h: + (JSC::JSValue::pureToBoolean): + * runtime/JSCell.h: + * runtime/JSCellInlines.h: + (JSC::JSCell::pureToBoolean): Updated for interface changes above. + +2013-04-23 Mark Lam <mark.lam@apple.com> + + Simplify the baseline JIT loop hint call site. + https://bugs.webkit.org/show_bug.cgi?id=115052. + + Reviewed by Geoffrey Garen. + + Moved the watchdog timer check after the JIT optimization check. This + ensures that the JIT opimization counter is incremented on every loop + hint even if the watchdog timer fires. + + Removed the code that allows the JIT OSR to happen if the watchdog + timer fires but does not result in a termination. It is extremely rare + that the JIT optimization counter would trigger an OSR on the same pass + as when the watchdog timer fire. If it does happen, we'll simply hold + off on servicing the watchdog timer until the next pass (because it's + not time critical). + + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_loop_hint): + (JSC::JIT::emitSlow_op_loop_hint): + +2013-04-23 Roger Fong <roger_fong@apple.com> + + AppleWin build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + +2013-04-18 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Update public header documentation + https://bugs.webkit.org/show_bug.cgi?id=114841 + + Reviewed by Geoffrey Garen. + + Added documentation for the newly added object lifetime-related stuff. + + * API/JSManagedValue.h: + * API/JSVirtualMachine.h: + +2013-04-22 Mark Lam <mark.lam@apple.com> + + Fix a typo in MacroAssemblerARMv7.h. + https://bugs.webkit.org/show_bug.cgi?id=115011. + + Reviewed by Geoffrey Garen. + + * assembler/ARMAssembler.h: Fix a comment. + * assembler/ARMv7Assembler.h: Added some comments. + * assembler/MacroAssemblerARMv7.h: + - ARMAssembler::PL should be ARMv7Assembler::ConditionPL. + +2013-04-22 Julien Brianceau <jbrianceau@nds.com> + + Add branchAdd32 missing implementation in SH4 base JIT. + This should fix SH4 build, broken since r148893. + https://bugs.webkit.org/show_bug.cgi?id=114993. + + Reviewed by Oliver Hunt. + + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::branchAdd32): + (MacroAssemblerSH4): + +2013-04-22 Benjamin Poulain <bpoulain@apple.com> + + Windows build fix after r148921 + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-22 Benjamin Poulain <benjamin@webkit.org> + + Remove the memory instrumentation code + https://bugs.webkit.org/show_bug.cgi?id=114931 + + Reviewed by Andreas Kling. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-22 Mark Lam <mark.lam@apple.com> + + Fix broken 32-bit build to green the bots. + https://bugs.webkit.org/show_bug.cgi?id=114968. + + Unreviewed. + + Basically, I moved a JIT::emit_op_loop_hint() and JIT::emitSlow_op_loop_hint() + into common code where they belong, instead of the 64-bit specific section. + + Also fixed some SH4 assertions failures which were also caused by + https://bugs.webkit.org/show_bug.cgi?id=114963. Thanks to Julien Brianceau + for pointing this out. + + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::branchAdd32): + * jit/JITOpcodes.cpp: + (JSC): + (JSC::JIT::emit_op_loop_hint): + (JSC::JIT::emitSlow_op_loop_hint): + +2013-04-22 Oliver Hunt <oliver@apple.com> + + Perform null check before trying to use the result of readline() + + RS=Gavin + + * jsc.cpp: + (runInteractive): + +2013-04-22 Oliver Hunt <oliver@apple.com> + + Fix assertions to account for new Vector layout + + RS=Gavin + + * llint/LLIntData.cpp: + (JSC::LLInt::Data::performAssertions): + +2013-04-22 Mark Lam <mark.lam@apple.com> + + Change baseline JIT watchdog timer check to use the proper fast slow path + infrastructure. + https://bugs.webkit.org/show_bug.cgi?id=114963. + + Reviewed by Oliver Hunt. + + Edit: The PositiveOrZero condition is added because it is needed for + the JIT optimization check. Previously, the JIT check branches around + the slow path if the test result is 'Signed' i.e. negative. Since we + now need to test for a condition that branches to the slow path (not + around it), we need the complement of 'Signed / Negative' i.e. Positive + or zero. + + SH4 parts contributed by Julien Brianceau. + + * assembler/ARMAssembler.h: + * assembler/MacroAssemblerARM.h: + * assembler/MacroAssemblerARMv7.h: + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::branchAdd32): + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::branchAdd32): + * assembler/MacroAssemblerX86Common.h: + * assembler/SH4Assembler.h: + * jit/JIT.cpp: + (JSC::JIT::emitEnterOptimizationCheck): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + (JSC::JIT::emitEnterOptimizationCheck): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_loop_hint): + (JSC::JIT::emitSlow_op_loop_hint): + (JSC::JIT::emit_op_enter): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_enter): + +2013-04-22 Andreas Kling <akling@apple.com> + + Shrink baseline size of WTF::Vector on 64-bit by switching to unsigned capacity and size. + <http://webkit.org/b/97268> + <rdar://problem/12376519> + + Reviewed by Sam Weinig. + + Update LLInt WTF::Vector offset constants to match the new memory layout. + + * llint/LowLevelInterpreter.asm: + +2013-04-21 Oliver Hunt <oliver@apple.com> + + JS Lexer and Parser should be more informative when they encounter errors + https://bugs.webkit.org/show_bug.cgi?id=114924 + + Reviewed by Filip Pizlo. + + Add new tokens to represent the various ways that parsing and lexing have failed. + This gives us the ability to produce better error messages in some cases, + and to indicate whether or not the failure was due to invalid source, or simply + early termination. + + The jsc prompt now makes use of this so that you can write functions that + are more than one line long. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::generate): + * jsc.cpp: + (stringFromUTF): + (jscSource): + (runInteractive): + * parser/Lexer.cpp: + (JSC::::parseFourDigitUnicodeHex): + (JSC::::parseIdentifierSlowCase): + (JSC::::parseString): + (JSC::::parseStringSlowCase): + (JSC::::lex): + * parser/Lexer.h: + (UnicodeHexValue): + (JSC::Lexer::UnicodeHexValue::UnicodeHexValue): + (JSC::Lexer::UnicodeHexValue::valueType): + (JSC::Lexer::UnicodeHexValue::isValid): + (JSC::Lexer::UnicodeHexValue::value): + (Lexer): + * parser/Parser.h: + (JSC::Parser::getTokenName): + (JSC::Parser::updateErrorMessageSpecialCase): + (JSC::::parse): + * parser/ParserError.h: + (ParserError): + (JSC::ParserError::ParserError): + * parser/ParserTokens.h: + * runtime/Completion.cpp: + (JSC): + (JSC::checkSyntax): + * runtime/Completion.h: + (JSC): + +2013-04-21 Mark Lam <mark.lam@apple.com> + + Refactor identical inline functions in JSVALUE64 and JSVALUE32_64 sections + out into the common section. + https://bugs.webkit.org/show_bug.cgi?id=114910. + + Reviewed by Filip Pizlo. + + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::callOperation): + +2013-04-20 Allan Sandfeld Jensen <allan.jensen@digia.com> + + LLint should be able to use x87 instead of SSE for floating pointer + https://bugs.webkit.org/show_bug.cgi?id=112239 + + Reviewed by Filip Pizlo. + + Implements LLInt floating point operations in x87, to ensure we support + x86 without SSE2. + + X86 (except 64bit) now defaults to using x87 instructions in order to + support all 32bit x86 back to i686. The implementation uses the fucomi + instruction from i686 which sets the new minimum. + + The FPU registers must always be empty on entering or exiting a function. + We make sure to only use two X87 registers, and they are always emptied + before calling deeper functions or returning from the LLInt. + + * jit/JITStubs.cpp: + (JSC): Empty FPU registers before exiting. + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * offlineasm/instructions.rb: + * offlineasm/x86.rb: + +2013-04-19 Roger Fong <roger_fong@apple.com> + + Remove uses of WebKit_Source from AppleWin build in JavaScriptCore. + + * JavaScriptCore.vcxproj/JavaScriptCore.make: + * JavaScriptCore.vcxproj/build-generated-files.sh: + * JavaScriptCore.vcxproj/copy-files.cmd: + * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: + +2013-04-19 Benjamin Poulain <bpoulain@apple.com> + + Rename JSStringJoiner::build() to join() + https://bugs.webkit.org/show_bug.cgi?id=114845 + + Reviewed by Geoffrey Garen. + + The method name build() came from StringBuilder history. It does not make much + sense on the StringJoiner. + + * runtime/ArrayPrototype.cpp: + (JSC::arrayProtoFuncToString): + (JSC::arrayProtoFuncToLocaleString): + (JSC::arrayProtoFuncJoin): + * runtime/JSStringJoiner.cpp: + (JSC::JSStringJoiner::join): + * runtime/JSStringJoiner.h: + (JSStringJoiner): + +2013-04-19 Roger Fong <roger_fong@apple.com> + + Unreviewed. WebKit_Source is incorrectly set. + + * JavaScriptCore.vcxproj/JavaScriptCore.make: + +2013-04-19 Martin Robinson <mrobinson@igalia.com> + + [GTK] JSCore.gir.in has a few problems + https://bugs.webkit.org/show_bug.cgi?id=114710 + + Reviewed by Philippe Normand. + + * GNUmakefile.am: Add the gobject introspection steps for JavaScriptCore here, + because they are shared between WebKit1 and WebKit2. + * JavaScriptCore.gir.in: Added. Moved from the WebKit1 directory. Now written + as foreign interfaces and referencing the javascriptcoregtk library. + +2013-04-18 Benjamin Poulain <bpoulain@apple.com> + + Use StringJoiner to create the JSString of arrayProtoFuncToString + https://bugs.webkit.org/show_bug.cgi?id=114779 + + Reviewed by Geoffrey Garen. + + The function arrayProtoFuncToString was just a glorified JSStringJoiner. + This patch replaces it by JSStringJoiner to simplify the code and enjoy any optimization + made on JSStringJoiner. + + For some reason, this makes the execution 3.4% faster, despite having almost identical code. + + * runtime/ArrayPrototype.cpp: + (JSC::arrayProtoFuncToString): + +2013-04-18 Oliver Hunt <oliver@apple.com> + + StackFrame::column() returning bogus value + https://bugs.webkit.org/show_bug.cgi?id=114840 + + Reviewed by Gavin Barraclough. + + Don't add one part of the expression offset to the other part of the expression. + Make StackFrame::toString() include the column info. + + * interpreter/Interpreter.cpp: + (JSC::StackFrame::expressionInfo): + (JSC::StackFrame::toString): + +2013-04-18 Mark Hahnenberg <mhahnenberg@apple.com> + + Crash beneath JSC::JIT::privateCompileSlowCases @ stephenrdonaldson.com + https://bugs.webkit.org/show_bug.cgi?id=114774 + + Reviewed by Geoffrey Garen. + + We're not linking up all of the slow cases in the baseline JIT when compiling put_to_base. + + * jit/JITOpcodes.cpp: + (JSC::JIT::emitSlow_op_put_to_base): + +2013-04-18 Mark Lam <mark.lam@apple.com> + + Interpreter entry points should throw the TerminatedExecutionException from the caller frame. + https://bugs.webkit.org/show_bug.cgi?id=114816. + + Reviewed by Oliver Hunt. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + +2013-04-18 Gabor Rapcsanyi <rgabor@webkit.org> + + LLInt ARM backend should not use the d8 register as scratch register + https://bugs.webkit.org/show_bug.cgi?id=114811 + + Reviewed by Filip Pizlo. + + The d8 register must preserved across function calls and should + not used as scratch register. Changing it to d6. + + * offlineasm/arm.rb: + +2013-04-18 Geoffrey Garen <ggaren@apple.com> + + Removed HeapTimer::synchronize + https://bugs.webkit.org/show_bug.cgi?id=114832 + + Reviewed by Mark Hahnenberg. + + HeapTimer::synchronize was a flawed attempt to make HeapTimer thread-safe. + Instead, we use proper locking now. + + This is a slight API change, since the GC timer will now only fire in the + run loop that created the JS VM, even if another run loop later executes + some JS. + + * API/APIShims.h: + (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock): + * heap/HeapTimer.cpp: + (JSC): + * heap/HeapTimer.h: + (HeapTimer): + +2013-04-17 Geoffrey Garen <ggaren@apple.com> + + Renamed JSGlobalData to VM + https://bugs.webkit.org/show_bug.cgi?id=114777 + + Reviewed by Phil Pizlo. + + * API/APICast.h: + (JSC): + (toJS): + (toRef): + * API/APIShims.h: + (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock): + (APIEntryShimWithoutLock): + (JSC::APIEntryShim::APIEntryShim): + (APIEntryShim): + (JSC::APIEntryShim::~APIEntryShim): + (JSC::APICallbackShim::APICallbackShim): + (JSC::APICallbackShim::~APICallbackShim): + (APICallbackShim): + * API/JSAPIWrapperObject.h: + (JSAPIWrapperObject): + * API/JSAPIWrapperObject.mm: + (JSC::::createStructure): + (JSC::JSAPIWrapperObject::JSAPIWrapperObject): + (JSC::JSAPIWrapperObject::finishCreation): + (JSC::JSAPIWrapperObject::visitChildren): + * API/JSBase.cpp: + (JSGarbageCollect): + (JSReportExtraMemoryCost): + (JSSynchronousGarbageCollectForDebugging): + * API/JSCallbackConstructor.cpp: + (JSC::JSCallbackConstructor::JSCallbackConstructor): + (JSC::JSCallbackConstructor::finishCreation): + * API/JSCallbackConstructor.h: + (JSC::JSCallbackConstructor::createStructure): + * API/JSCallbackFunction.cpp: + (JSC::JSCallbackFunction::finishCreation): + (JSC::JSCallbackFunction::create): + * API/JSCallbackFunction.h: + (JSCallbackFunction): + (JSC::JSCallbackFunction::createStructure): + * API/JSCallbackObject.cpp: + (JSC::::create): + (JSC::::createStructure): + * API/JSCallbackObject.h: + (JSC::JSCallbackObjectData::setPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): + (JSCallbackObject): + (JSC::JSCallbackObject::setPrivateProperty): + * API/JSCallbackObjectFunctions.h: + (JSC::::JSCallbackObject): + (JSC::::finishCreation): + (JSC::::put): + (JSC::::staticFunctionGetter): + * API/JSClassRef.cpp: + (OpaqueJSClassContextData::OpaqueJSClassContextData): + (OpaqueJSClass::contextData): + (OpaqueJSClass::prototype): + * API/JSClassRef.h: + (OpaqueJSClassContextData): + * API/JSContext.mm: + (-[JSContext setException:]): + (-[JSContext initWithGlobalContextRef:]): + (+[JSContext contextWithGlobalContextRef:]): + * API/JSContextRef.cpp: + (JSContextGroupCreate): + (JSContextGroupRelease): + (JSGlobalContextCreate): + (JSGlobalContextCreateInGroup): + (JSGlobalContextRetain): + (JSGlobalContextRelease): + (JSContextGetGroup): + (JSContextCreateBacktrace): + * API/JSObjectRef.cpp: + (JSObjectMake): + (JSObjectMakeConstructor): + (JSObjectMakeFunction): + (JSObjectSetPrototype): + (JSObjectHasProperty): + (JSObjectGetProperty): + (JSObjectSetProperty): + (JSObjectDeleteProperty): + (JSObjectGetPrivateProperty): + (JSObjectSetPrivateProperty): + (JSObjectDeletePrivateProperty): + (OpaqueJSPropertyNameArray::OpaqueJSPropertyNameArray): + (OpaqueJSPropertyNameArray): + (JSObjectCopyPropertyNames): + (JSPropertyNameArrayRelease): + (JSPropertyNameAccumulatorAddName): + * API/JSScriptRef.cpp: + (OpaqueJSScript::create): + (OpaqueJSScript::vm): + (OpaqueJSScript::OpaqueJSScript): + (OpaqueJSScript): + (parseScript): + * API/JSVirtualMachine.mm: + (scanExternalObjectGraph): + * API/JSVirtualMachineInternal.h: + (JSC): + * API/JSWrapperMap.mm: + (makeWrapper): + * API/ObjCCallbackFunction.h: + (JSC::ObjCCallbackFunction::createStructure): + * API/ObjCCallbackFunction.mm: + (JSC::ObjCCallbackFunction::create): + * API/OpaqueJSString.cpp: + (OpaqueJSString::identifier): + * API/OpaqueJSString.h: + (JSC): + (OpaqueJSString): + * GNUmakefile.list.am: + * JSCTypedArrayStubs.h: + (JSC): + * JavaScriptCore.order: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + * JavaScriptCore.xcodeproj/project.pbxproj: + * KeywordLookupGenerator.py: + (Trie.printSubTreeAsC): + * Target.pri: + * assembler/ARMAssembler.cpp: + (JSC::ARMAssembler::executableCopy): + * assembler/ARMAssembler.h: + (ARMAssembler): + * assembler/AssemblerBuffer.h: + (JSC::AssemblerBuffer::executableCopy): + * assembler/AssemblerBufferWithConstantPool.h: + (JSC::AssemblerBufferWithConstantPool::executableCopy): + * assembler/LinkBuffer.cpp: + (JSC::LinkBuffer::linkCode): + * assembler/LinkBuffer.h: + (JSC): + (JSC::LinkBuffer::LinkBuffer): + (LinkBuffer): + * assembler/MIPSAssembler.h: + (JSC::MIPSAssembler::executableCopy): + * assembler/SH4Assembler.h: + (JSC::SH4Assembler::executableCopy): + * assembler/X86Assembler.h: + (JSC::X86Assembler::executableCopy): + (JSC::X86Assembler::X86InstructionFormatter::executableCopy): + * bytecode/CallLinkInfo.cpp: + (JSC::CallLinkInfo::unlink): + * bytecode/CallLinkInfo.h: + (CallLinkInfo): + * bytecode/CodeBlock.cpp: + (JSC::dumpStructure): + (JSC::CodeBlock::printStructures): + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::~CodeBlock): + (JSC::CodeBlock::visitStructures): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::createActivation): + (JSC::CodeBlock::unlinkCalls): + (JSC::CodeBlock::unlinkIncomingCalls): + (JSC::CodeBlock::findClosureCallForReturnPC): + (JSC::ProgramCodeBlock::jettisonImpl): + (JSC::EvalCodeBlock::jettisonImpl): + (JSC::FunctionCodeBlock::jettisonImpl): + (JSC::CodeBlock::predictedMachineCodeSize): + (JSC::CodeBlock::usesOpcode): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::appendWeakReference): + (JSC::CodeBlock::appendWeakReferenceTransition): + (JSC::CodeBlock::setJITCode): + (JSC::CodeBlock::setGlobalData): + (JSC::CodeBlock::vm): + (JSC::CodeBlock::valueProfileForBytecodeOffset): + (JSC::CodeBlock::addConstant): + (JSC::CodeBlock::setConstantRegisters): + (CodeBlock): + (JSC::CodeBlock::WeakReferenceTransition::WeakReferenceTransition): + * bytecode/EvalCodeCache.h: + (JSC::EvalCodeCache::getSlow): + * bytecode/GetByIdStatus.cpp: + (JSC::GetByIdStatus::computeFromLLInt): + (JSC::GetByIdStatus::computeForChain): + (JSC::GetByIdStatus::computeFor): + * bytecode/GetByIdStatus.h: + (GetByIdStatus): + * bytecode/Instruction.h: + (JSC::Instruction::Instruction): + * bytecode/ObjectAllocationProfile.h: + (JSC::ObjectAllocationProfile::initialize): + (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): + * bytecode/PolymorphicAccessStructureList.h: + (JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::set): + (JSC::PolymorphicAccessStructureList::PolymorphicAccessStructureList): + * bytecode/PolymorphicPutByIdList.h: + (JSC::PutByIdAccess::transition): + (JSC::PutByIdAccess::replace): + * bytecode/PreciseJumpTargets.cpp: + (JSC::computePreciseJumpTargets): + * bytecode/PutByIdStatus.cpp: + (JSC::PutByIdStatus::computeFromLLInt): + (JSC::PutByIdStatus::computeFor): + * bytecode/PutByIdStatus.h: + (JSC): + (PutByIdStatus): + * bytecode/ResolveGlobalStatus.cpp: + (JSC::computeForStructure): + * bytecode/SamplingTool.cpp: + (JSC::SamplingTool::notifyOfScope): + * bytecode/SamplingTool.h: + (JSC::ScriptSampleRecord::ScriptSampleRecord): + (SamplingTool): + * bytecode/StructureStubInfo.h: + (JSC::StructureStubInfo::initGetByIdSelf): + (JSC::StructureStubInfo::initGetByIdProto): + (JSC::StructureStubInfo::initGetByIdChain): + (JSC::StructureStubInfo::initPutByIdTransition): + (JSC::StructureStubInfo::initPutByIdReplace): + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::generateFunctionCodeBlock): + (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): + (JSC::UnlinkedFunctionExecutable::link): + (JSC::UnlinkedFunctionExecutable::fromGlobalCode): + (JSC::UnlinkedFunctionExecutable::codeBlockFor): + (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): + * bytecode/UnlinkedCodeBlock.h: + (JSC::UnlinkedFunctionExecutable::create): + (UnlinkedFunctionExecutable): + (JSC::UnlinkedFunctionExecutable::finishCreation): + (JSC::UnlinkedFunctionExecutable::createStructure): + (JSC::UnlinkedCodeBlock::addRegExp): + (JSC::UnlinkedCodeBlock::addConstant): + (JSC::UnlinkedCodeBlock::addFunctionDecl): + (JSC::UnlinkedCodeBlock::addFunctionExpr): + (JSC::UnlinkedCodeBlock::vm): + (UnlinkedCodeBlock): + (JSC::UnlinkedCodeBlock::finishCreation): + (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock): + (JSC::UnlinkedProgramCodeBlock::create): + (JSC::UnlinkedProgramCodeBlock::addFunctionDeclaration): + (JSC::UnlinkedProgramCodeBlock::UnlinkedProgramCodeBlock): + (JSC::UnlinkedProgramCodeBlock::createStructure): + (JSC::UnlinkedEvalCodeBlock::create): + (JSC::UnlinkedEvalCodeBlock::UnlinkedEvalCodeBlock): + (JSC::UnlinkedEvalCodeBlock::createStructure): + (JSC::UnlinkedFunctionCodeBlock::create): + (JSC::UnlinkedFunctionCodeBlock::UnlinkedFunctionCodeBlock): + (JSC::UnlinkedFunctionCodeBlock::createStructure): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::addConstant): + (JSC::BytecodeGenerator::emitLoad): + (JSC::BytecodeGenerator::emitDirectPutById): + (JSC::BytecodeGenerator::addStringConstant): + (JSC::BytecodeGenerator::expectedFunctionForIdentifier): + (JSC::BytecodeGenerator::emitThrowReferenceError): + (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + (JSC::BytecodeGenerator::vm): + (JSC::BytecodeGenerator::propertyNames): + (JSC::BytecodeGenerator::makeFunction): + * bytecompiler/NodesCodegen.cpp: + (JSC::RegExpNode::emitBytecode): + (JSC::ArrayNode::toArgumentList): + (JSC::ApplyFunctionCallDotNode::emitBytecode): + (JSC::InstanceOfNode::emitBytecode): + * debugger/Debugger.cpp: + (JSC::Debugger::recompileAllJSFunctions): + (JSC::evaluateInGlobalCallFrame): + * debugger/Debugger.h: + (JSC): + * debugger/DebuggerActivation.cpp: + (JSC::DebuggerActivation::DebuggerActivation): + (JSC::DebuggerActivation::finishCreation): + * debugger/DebuggerActivation.h: + (JSC::DebuggerActivation::create): + (JSC::DebuggerActivation::createStructure): + (DebuggerActivation): + * debugger/DebuggerCallFrame.cpp: + (JSC::DebuggerCallFrame::evaluate): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::executeEffects): + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::AssemblyHelpers): + (JSC::DFG::AssemblyHelpers::vm): + (JSC::DFG::AssemblyHelpers::debugCall): + (JSC::DFG::AssemblyHelpers::emitExceptionCheck): + (AssemblyHelpers): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::ByteCodeParser): + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + (JSC::DFG::ByteCodeParser::parseCodeBlock): + * dfg/DFGByteCodeParser.h: + (JSC): + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::CCallHelpers): + * dfg/DFGCapabilities.cpp: + (JSC::DFG::canHandleOpcodes): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::reportToProfiler): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGDriver.h: + (JSC): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::isStringPrototypeMethodSane): + (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::Graph): + * dfg/DFGGraph.h: + (Graph): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::JITCompiler): + (JSC::DFG::JITCompiler::linkOSRExits): + (JSC::DFG::JITCompiler::link): + (JSC::DFG::JITCompiler::compile): + (JSC::DFG::JITCompiler::compileFunction): + * dfg/DFGJITCompiler.h: + (JSC): + * dfg/DFGOSREntry.cpp: + (JSC::DFG::prepareOSREntry): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + (JSC::DFG::putByVal): + (JSC::DFG::operationPutByValInternal): + (JSC::getHostCallReturnValueWithExecState): + * dfg/DFGPhase.h: + (JSC::DFG::Phase::vm): + * dfg/DFGRepatch.cpp: + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::tryBuildGetByIDProtoList): + (JSC::DFG::emitPutReplaceStub): + (JSC::DFG::emitPutTransitionStub): + (JSC::DFG::tryCachePutByID): + (JSC::DFG::tryBuildPutByIdList): + (JSC::DFG::linkSlowFor): + (JSC::DFG::dfgLinkFor): + (JSC::DFG::dfgLinkSlowFor): + (JSC::DFG::dfgLinkClosureCall): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::typedArrayDescriptor): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): + (JSC::DFG::SpeculativeJIT::compileGetByValOnString): + (JSC::DFG::SpeculativeJIT::compileFromCharCode): + (JSC::DFG::SpeculativeJIT::compileMakeRope): + (JSC::DFG::SpeculativeJIT::compileStringEquality): + (JSC::DFG::SpeculativeJIT::compileToStringOnCell): + (JSC::DFG::SpeculativeJIT::speculateObject): + (JSC::DFG::SpeculativeJIT::speculateObjectOrOther): + (JSC::DFG::SpeculativeJIT::speculateString): + (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::prepareForExternalCall): + (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage): + (JSC::DFG::SpeculativeJIT::emitAllocateJSObject): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGThunks.cpp: + (JSC::DFG::osrExitGenerationThunkGenerator): + (JSC::DFG::throwExceptionFromCallSlowPathGenerator): + (JSC::DFG::slowPathFor): + (JSC::DFG::linkForThunkGenerator): + (JSC::DFG::linkCallThunkGenerator): + (JSC::DFG::linkConstructThunkGenerator): + (JSC::DFG::linkClosureCallThunkGenerator): + (JSC::DFG::virtualForThunkGenerator): + (JSC::DFG::virtualCallThunkGenerator): + (JSC::DFG::virtualConstructThunkGenerator): + * dfg/DFGThunks.h: + (JSC): + (DFG): + * heap/BlockAllocator.h: + (JSC): + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::tryAllocateSlowCase): + (JSC::CopiedSpace::tryReallocate): + * heap/CopiedSpaceInlines.h: + (JSC::CopiedSpace::tryAllocate): + * heap/GCThreadSharedData.cpp: + (JSC::GCThreadSharedData::GCThreadSharedData): + (JSC::GCThreadSharedData::reset): + * heap/GCThreadSharedData.h: + (JSC): + (GCThreadSharedData): + * heap/HandleSet.cpp: + (JSC::HandleSet::HandleSet): + (JSC::HandleSet::~HandleSet): + (JSC::HandleSet::grow): + * heap/HandleSet.h: + (JSC): + (HandleSet): + (JSC::HandleSet::vm): + * heap/Heap.cpp: + (JSC::Heap::Heap): + (JSC): + (JSC::Heap::lastChanceToFinalize): + (JSC::Heap::protect): + (JSC::Heap::unprotect): + (JSC::Heap::stack): + (JSC::Heap::getConservativeRegisterRoots): + (JSC::Heap::markRoots): + (JSC::Heap::deleteAllCompiledCode): + (JSC::Heap::collect): + (JSC::Heap::isValidAllocation): + * heap/Heap.h: + (JSC): + (Heap): + (JSC::Heap::vm): + * heap/HeapTimer.cpp: + (JSC::HeapTimer::HeapTimer): + (JSC::HeapTimer::timerDidFire): + (JSC::HeapTimer::timerEvent): + * heap/HeapTimer.h: + (JSC): + (HeapTimer): + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::IncrementalSweeper): + (JSC::IncrementalSweeper::sweepNextBlock): + (JSC::IncrementalSweeper::willFinishSweeping): + (JSC::IncrementalSweeper::create): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * heap/Local.h: + (Local): + (JSC::::Local): + (JSC::LocalStack::LocalStack): + (JSC::LocalStack::push): + (LocalStack): + * heap/LocalScope.h: + (JSC): + (LocalScope): + (JSC::LocalScope::LocalScope): + * heap/MachineStackMarker.cpp: + (JSC::MachineThreads::addCurrentThread): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::allocateSlowCase): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::MarkedBlock): + * heap/MarkedBlock.h: + (JSC::MarkedBlock::vm): + * heap/SlotVisitor.cpp: + (JSC::SlotVisitor::SlotVisitor): + (JSC::SlotVisitor::setup): + * heap/Strong.h: + (JSC): + (Strong): + (JSC::Strong::operator=): + * heap/StrongInlines.h: + (JSC::::Strong): + (JSC::::set): + * heap/SuperRegion.h: + (JSC): + * heap/WeakSet.cpp: + * heap/WeakSet.h: + (WeakSet): + (JSC::WeakSet::WeakSet): + (JSC::WeakSet::vm): + * interpreter/AbstractPC.cpp: + (JSC::AbstractPC::AbstractPC): + * interpreter/AbstractPC.h: + (JSC): + (AbstractPC): + * interpreter/CachedCall.h: + (JSC::CachedCall::CachedCall): + * interpreter/CallFrame.h: + (ExecState): + (JSC::ExecState::clearException): + (JSC::ExecState::clearSupplementaryExceptionInfo): + (JSC::ExecState::exception): + (JSC::ExecState::hadException): + (JSC::ExecState::propertyNames): + (JSC::ExecState::emptyList): + (JSC::ExecState::interpreter): + (JSC::ExecState::heap): + (JSC::ExecState::arrayConstructorTable): + (JSC::ExecState::arrayPrototypeTable): + (JSC::ExecState::booleanPrototypeTable): + (JSC::ExecState::dateTable): + (JSC::ExecState::dateConstructorTable): + (JSC::ExecState::errorPrototypeTable): + (JSC::ExecState::globalObjectTable): + (JSC::ExecState::jsonTable): + (JSC::ExecState::mathTable): + (JSC::ExecState::numberConstructorTable): + (JSC::ExecState::numberPrototypeTable): + (JSC::ExecState::objectConstructorTable): + (JSC::ExecState::privateNamePrototypeTable): + (JSC::ExecState::regExpTable): + (JSC::ExecState::regExpConstructorTable): + (JSC::ExecState::regExpPrototypeTable): + (JSC::ExecState::stringConstructorTable): + (JSC::ExecState::abstractReturnPC): + * interpreter/CallFrameClosure.h: + (CallFrameClosure): + * interpreter/Interpreter.cpp: + (JSC): + (JSC::eval): + (JSC::loadVarargs): + (JSC::Interpreter::Interpreter): + (JSC::Interpreter::dumpRegisters): + (JSC::Interpreter::unwindCallFrame): + (JSC::appendSourceToError): + (JSC::getCallerInfo): + (JSC::Interpreter::getStackTrace): + (JSC::Interpreter::addStackTraceIfNecessary): + (JSC::Interpreter::throwException): + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + (JSC::Interpreter::prepareForRepeatCall): + (JSC::Interpreter::retrieveArgumentsFromVMCode): + (JSC::Interpreter::retrieveCallerFromVMCode): + * interpreter/Interpreter.h: + (JSC): + (JSC::TopCallFrameSetter::TopCallFrameSetter): + (JSC::TopCallFrameSetter::~TopCallFrameSetter): + (TopCallFrameSetter): + (JSC::NativeCallFrameTracer::NativeCallFrameTracer): + (Interpreter): + * interpreter/JSStack.cpp: + (JSC::JSStack::JSStack): + * interpreter/JSStack.h: + (JSC): + * jit/ClosureCallStubRoutine.cpp: + (JSC::ClosureCallStubRoutine::ClosureCallStubRoutine): + * jit/ClosureCallStubRoutine.h: + (ClosureCallStubRoutine): + * jit/ExecutableAllocator.cpp: + (JSC::ExecutableAllocator::ExecutableAllocator): + (JSC::ExecutableAllocator::allocate): + * jit/ExecutableAllocator.h: + (JSC): + (ExecutableAllocator): + * jit/ExecutableAllocatorFixedVMPool.cpp: + (JSC::ExecutableAllocator::ExecutableAllocator): + (JSC::ExecutableAllocator::allocate): + * jit/GCAwareJITStubRoutine.cpp: + (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine): + (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject): + (JSC::createJITStubRoutine): + * jit/GCAwareJITStubRoutine.h: + (GCAwareJITStubRoutine): + (MarkingGCAwareJITStubRoutineWithOneObject): + (JSC): + * jit/JIT.cpp: + (JSC::JIT::JIT): + (JSC::JIT::privateCompile): + (JSC::JIT::linkFor): + (JSC::JIT::linkSlowCall): + * jit/JIT.h: + (JSC::JIT::compile): + (JSC::JIT::compileClosureCall): + (JSC::JIT::compileGetByIdProto): + (JSC::JIT::compileGetByIdSelfList): + (JSC::JIT::compileGetByIdProtoList): + (JSC::JIT::compileGetByIdChainList): + (JSC::JIT::compileGetByIdChain): + (JSC::JIT::compilePutByIdTransition): + (JSC::JIT::compileGetByVal): + (JSC::JIT::compilePutByVal): + (JSC::JIT::compileCTINativeCall): + (JSC::JIT::compilePatchGetArrayLength): + (JIT): + * jit/JITCall.cpp: + (JSC::JIT::compileLoadVarargs): + (JSC::JIT::compileCallEvalSlowCase): + (JSC::JIT::compileOpCallSlowCase): + (JSC::JIT::privateCompileClosureCall): + * jit/JITCall32_64.cpp: + (JSC::JIT::compileLoadVarargs): + (JSC::JIT::compileCallEvalSlowCase): + (JSC::JIT::compileOpCallSlowCase): + (JSC::JIT::privateCompileClosureCall): + * jit/JITCode.h: + (JSC): + (JSC::JITCode::execute): + * jit/JITDriver.h: + (JSC::jitCompileIfAppropriate): + (JSC::jitCompileFunctionIfAppropriate): + * jit/JITExceptions.cpp: + (JSC::genericThrow): + (JSC::jitThrow): + * jit/JITExceptions.h: + (JSC): + * jit/JITInlines.h: + (JSC::JIT::emitLoadCharacterString): + (JSC::JIT::updateTopCallFrame): + * jit/JITOpcodes.cpp: + (JSC::JIT::privateCompileCTINativeCall): + (JSC::JIT::emit_op_new_object): + (JSC::JIT::emit_op_to_primitive): + (JSC::JIT::emit_op_catch): + (JSC::JIT::emit_op_convert_this): + (JSC::JIT::emitSlow_op_convert_this): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::privateCompileCTINativeCall): + (JSC::JIT::emit_op_new_object): + (JSC::JIT::emit_op_to_primitive): + (JSC::JIT::emitSlow_op_eq): + (JSC::JIT::emitSlow_op_neq): + (JSC::JIT::compileOpStrictEq): + (JSC::JIT::emit_op_catch): + (JSC::JIT::emit_op_convert_this): + (JSC::JIT::emitSlow_op_convert_this): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::stringGetByValStubGenerator): + (JSC::JIT::emitSlow_op_get_by_val): + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdSelfList): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + (JSC::JIT::privateCompileGetByVal): + (JSC::JIT::privateCompilePutByVal): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::stringGetByValStubGenerator): + (JSC::JIT::emitSlow_op_get_by_val): + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdSelfList): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + * jit/JITStubs.cpp: + (JSC::ctiTrampoline): + (JSC): + (JSC::performPlatformSpecificJITAssertions): + (JSC::tryCachePutByID): + (JSC::tryCacheGetByID): + (JSC::returnToThrowTrampoline): + (JSC::throwExceptionFromOpCall): + (JSC::DEFINE_STUB_FUNCTION): + (JSC::getPolymorphicAccessStructureListSlot): + (JSC::jitCompileFor): + (JSC::lazyLinkFor): + (JSC::putByVal): + * jit/JITStubs.h: + (JSC): + (JITStackFrame): + * jit/JITThunks.cpp: + (JSC::JITThunks::ctiNativeCall): + (JSC::JITThunks::ctiNativeConstruct): + (JSC::JITThunks::ctiStub): + (JSC::JITThunks::hostFunctionStub): + * jit/JITThunks.h: + (JSC): + (JITThunks): + * jit/JITWriteBarrier.h: + (JSC): + (JSC::JITWriteBarrierBase::set): + (JSC::JITWriteBarrier::set): + * jit/SpecializedThunkJIT.h: + (JSC::SpecializedThunkJIT::loadJSStringArgument): + (JSC::SpecializedThunkJIT::finalize): + * jit/ThunkGenerator.h: + (JSC): + * jit/ThunkGenerators.cpp: + (JSC::generateSlowCaseFor): + (JSC::linkForGenerator): + (JSC::linkCallGenerator): + (JSC::linkConstructGenerator): + (JSC::linkClosureCallGenerator): + (JSC::virtualForGenerator): + (JSC::virtualCallGenerator): + (JSC::virtualConstructGenerator): + (JSC::stringLengthTrampolineGenerator): + (JSC::nativeForGenerator): + (JSC::nativeCallGenerator): + (JSC::nativeConstructGenerator): + (JSC::stringCharLoad): + (JSC::charToString): + (JSC::charCodeAtThunkGenerator): + (JSC::charAtThunkGenerator): + (JSC::fromCharCodeThunkGenerator): + (JSC::sqrtThunkGenerator): + (JSC::floorThunkGenerator): + (JSC::ceilThunkGenerator): + (JSC::roundThunkGenerator): + (JSC::expThunkGenerator): + (JSC::logThunkGenerator): + (JSC::absThunkGenerator): + (JSC::powThunkGenerator): + * jit/ThunkGenerators.h: + (JSC): + * jsc.cpp: + (GlobalObject): + (GlobalObject::create): + (GlobalObject::createStructure): + (GlobalObject::finishCreation): + (GlobalObject::addFunction): + (GlobalObject::addConstructableFunction): + (functionDumpCallFrame): + (functionJSCStack): + (functionReleaseExecutableMemory): + (functionRun): + (main): + (runWithScripts): + (jscmain): + * llint/LLIntData.cpp: + (JSC::LLInt::Data::performAssertions): + * llint/LLIntData.h: + (JSC): + (Data): + (JSC::LLInt::Data::performAssertions): + * llint/LLIntEntrypoints.cpp: + (JSC::LLInt::getFunctionEntrypoint): + (JSC::LLInt::getEvalEntrypoint): + (JSC::LLInt::getProgramEntrypoint): + * llint/LLIntEntrypoints.h: + (JSC): + (LLInt): + (JSC::LLInt::getEntrypoint): + * llint/LLIntExceptions.cpp: + (JSC::LLInt::interpreterThrowInCaller): + (JSC::LLInt::returnToThrow): + (JSC::LLInt::callToThrow): + * llint/LLIntOffsetsExtractor.cpp: + * llint/LLIntSlowPaths.cpp: + (LLInt): + (JSC::LLInt::llint_trace_operand): + (JSC::LLInt::llint_trace_value): + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (JSC::LLInt::shouldJIT): + (JSC::LLInt::handleHostCall): + (JSC::LLInt::setUpCall): + * llint/LLIntThunks.cpp: + (JSC::LLInt::generateThunkWithJumpTo): + (JSC::LLInt::functionForCallEntryThunkGenerator): + (JSC::LLInt::functionForConstructEntryThunkGenerator): + (JSC::LLInt::functionForCallArityCheckThunkGenerator): + (JSC::LLInt::functionForConstructArityCheckThunkGenerator): + (JSC::LLInt::evalEntryThunkGenerator): + (JSC::LLInt::programEntryThunkGenerator): + * llint/LLIntThunks.h: + (JSC): + (LLInt): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter.cpp: + (JSC::CLoop::execute): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * offlineasm/cloop.rb: + * parser/ASTBuilder.h: + (JSC::ASTBuilder::ASTBuilder): + (JSC::ASTBuilder::createSourceElements): + (JSC::ASTBuilder::createCommaExpr): + (JSC::ASTBuilder::createLogicalNot): + (JSC::ASTBuilder::createUnaryPlus): + (JSC::ASTBuilder::createVoid): + (JSC::ASTBuilder::thisExpr): + (JSC::ASTBuilder::createResolve): + (JSC::ASTBuilder::createObjectLiteral): + (JSC::ASTBuilder::createArray): + (JSC::ASTBuilder::createNumberExpr): + (JSC::ASTBuilder::createString): + (JSC::ASTBuilder::createBoolean): + (JSC::ASTBuilder::createNull): + (JSC::ASTBuilder::createBracketAccess): + (JSC::ASTBuilder::createDotAccess): + (JSC::ASTBuilder::createRegExp): + (JSC::ASTBuilder::createNewExpr): + (JSC::ASTBuilder::createConditionalExpr): + (JSC::ASTBuilder::createAssignResolve): + (JSC::ASTBuilder::createFunctionExpr): + (JSC::ASTBuilder::createFunctionBody): + (JSC::ASTBuilder::createGetterOrSetterProperty): + (JSC::ASTBuilder::createArguments): + (JSC::ASTBuilder::createArgumentsList): + (JSC::ASTBuilder::createProperty): + (JSC::ASTBuilder::createPropertyList): + (JSC::ASTBuilder::createElementList): + (JSC::ASTBuilder::createFormalParameterList): + (JSC::ASTBuilder::createClause): + (JSC::ASTBuilder::createClauseList): + (JSC::ASTBuilder::createFuncDeclStatement): + (JSC::ASTBuilder::createBlockStatement): + (JSC::ASTBuilder::createExprStatement): + (JSC::ASTBuilder::createIfStatement): + (JSC::ASTBuilder::createForLoop): + (JSC::ASTBuilder::createForInLoop): + (JSC::ASTBuilder::createEmptyStatement): + (JSC::ASTBuilder::createVarStatement): + (JSC::ASTBuilder::createReturnStatement): + (JSC::ASTBuilder::createBreakStatement): + (JSC::ASTBuilder::createContinueStatement): + (JSC::ASTBuilder::createTryStatement): + (JSC::ASTBuilder::createSwitchStatement): + (JSC::ASTBuilder::createWhileStatement): + (JSC::ASTBuilder::createDoWhileStatement): + (JSC::ASTBuilder::createLabelStatement): + (JSC::ASTBuilder::createWithStatement): + (JSC::ASTBuilder::createThrowStatement): + (JSC::ASTBuilder::createDebugger): + (JSC::ASTBuilder::createConstStatement): + (JSC::ASTBuilder::appendConstDecl): + (JSC::ASTBuilder::addVar): + (JSC::ASTBuilder::combineCommaNodes): + (JSC::ASTBuilder::Scope::Scope): + (JSC::ASTBuilder::createNumber): + (ASTBuilder): + (JSC::ASTBuilder::makeTypeOfNode): + (JSC::ASTBuilder::makeDeleteNode): + (JSC::ASTBuilder::makeNegateNode): + (JSC::ASTBuilder::makeBitwiseNotNode): + (JSC::ASTBuilder::makeMultNode): + (JSC::ASTBuilder::makeDivNode): + (JSC::ASTBuilder::makeModNode): + (JSC::ASTBuilder::makeAddNode): + (JSC::ASTBuilder::makeSubNode): + (JSC::ASTBuilder::makeLeftShiftNode): + (JSC::ASTBuilder::makeRightShiftNode): + (JSC::ASTBuilder::makeURightShiftNode): + (JSC::ASTBuilder::makeBitOrNode): + (JSC::ASTBuilder::makeBitAndNode): + (JSC::ASTBuilder::makeBitXOrNode): + (JSC::ASTBuilder::makeFunctionCallNode): + (JSC::ASTBuilder::makeBinaryNode): + (JSC::ASTBuilder::makeAssignNode): + (JSC::ASTBuilder::makePrefixNode): + (JSC::ASTBuilder::makePostfixNode): + * parser/Lexer.cpp: + (JSC::Keywords::Keywords): + (JSC::::Lexer): + (JSC::::parseIdentifier): + (JSC::::parseIdentifierSlowCase): + * parser/Lexer.h: + (JSC::Keywords::isKeyword): + (JSC::Keywords::getKeyword): + (Keywords): + (Lexer): + (JSC::::makeIdentifier): + (JSC::::makeRightSizedIdentifier): + (JSC::::makeIdentifierLCharFromUChar): + (JSC::::makeLCharIdentifier): + * parser/NodeConstructors.h: + (JSC::ParserArenaFreeable::operator new): + (JSC::ParserArenaDeletable::operator new): + (JSC::ParserArenaRefCounted::ParserArenaRefCounted): + (JSC::PropertyNode::PropertyNode): + (JSC::ContinueNode::ContinueNode): + (JSC::BreakNode::BreakNode): + (JSC::ForInNode::ForInNode): + * parser/Nodes.cpp: + (JSC::ScopeNode::ScopeNode): + (JSC::ProgramNode::ProgramNode): + (JSC::ProgramNode::create): + (JSC::EvalNode::EvalNode): + (JSC::EvalNode::create): + (JSC::FunctionBodyNode::FunctionBodyNode): + (JSC::FunctionBodyNode::create): + * parser/Nodes.h: + (ParserArenaFreeable): + (ParserArenaDeletable): + (ParserArenaRefCounted): + (ArrayNode): + (ForInNode): + (ContinueNode): + (BreakNode): + (ScopeNode): + (ProgramNode): + (EvalNode): + (FunctionBodyNode): + * parser/Parser.cpp: + (JSC::::Parser): + (JSC::::parseInner): + (JSC::::parseSourceElements): + (JSC::::parseTryStatement): + (JSC::::parseFunctionBody): + (JSC::::parseFunctionInfo): + (JSC::::parseAssignmentExpression): + (JSC::::parseProperty): + (JSC::::parsePrimaryExpression): + (JSC::::parseMemberExpression): + (JSC::::parseUnaryExpression): + * parser/Parser.h: + (JSC): + (JSC::Scope::Scope): + (JSC::Scope::declareVariable): + (JSC::Scope::declareParameter): + (Scope): + (Parser): + (JSC::Parser::pushScope): + (JSC::::parse): + (JSC::parse): + * parser/ParserArena.h: + (IdentifierArena): + (JSC::IdentifierArena::makeIdentifier): + (JSC::IdentifierArena::makeIdentifierLCharFromUChar): + (JSC::IdentifierArena::makeNumericIdentifier): + * parser/SyntaxChecker.h: + (JSC::SyntaxChecker::SyntaxChecker): + (JSC::SyntaxChecker::createProperty): + (JSC::SyntaxChecker::createGetterOrSetterProperty): + * profiler/LegacyProfiler.cpp: + (JSC::LegacyProfiler::startProfiling): + (JSC::LegacyProfiler::stopProfiling): + * profiler/LegacyProfiler.h: + (JSC): + * profiler/ProfilerBytecode.cpp: + (JSC::Profiler::Bytecode::toJS): + * profiler/ProfilerBytecodeSequence.cpp: + (JSC::Profiler::BytecodeSequence::BytecodeSequence): + (JSC::Profiler::BytecodeSequence::addSequenceProperties): + * profiler/ProfilerBytecodes.cpp: + (JSC::Profiler::Bytecodes::toJS): + * profiler/ProfilerCompilation.cpp: + (JSC::Profiler::Compilation::toJS): + * profiler/ProfilerCompiledBytecode.cpp: + (JSC::Profiler::CompiledBytecode::toJS): + * profiler/ProfilerDatabase.cpp: + (JSC::Profiler::Database::Database): + (JSC::Profiler::Database::toJS): + (JSC::Profiler::Database::toJSON): + * profiler/ProfilerDatabase.h: + (Database): + * profiler/ProfilerOSRExit.cpp: + (JSC::Profiler::OSRExit::toJS): + * profiler/ProfilerOrigin.cpp: + (JSC::Profiler::Origin::toJS): + * profiler/ProfilerProfiledBytecodes.cpp: + (JSC::Profiler::ProfiledBytecodes::toJS): + * runtime/ArgList.h: + (MarkedArgumentBuffer): + * runtime/Arguments.cpp: + (JSC::Arguments::putByIndex): + (JSC::Arguments::put): + (JSC::Arguments::deleteProperty): + (JSC::Arguments::defineOwnProperty): + (JSC::Arguments::tearOff): + (JSC::Arguments::didTearOffActivation): + (JSC::Arguments::tearOffForInlineCallFrame): + * runtime/Arguments.h: + (JSC::Arguments::create): + (JSC::Arguments::createStructure): + (Arguments): + (JSC::Arguments::Arguments): + (JSC::Arguments::trySetArgument): + (JSC::Arguments::finishCreation): + * runtime/ArrayConstructor.cpp: + (JSC::ArrayConstructor::finishCreation): + * runtime/ArrayConstructor.h: + (JSC::ArrayConstructor::createStructure): + * runtime/ArrayPrototype.cpp: + (JSC::ArrayPrototype::ArrayPrototype): + (JSC::ArrayPrototype::finishCreation): + (JSC::arrayProtoFuncSort): + (JSC::arrayProtoFuncSplice): + * runtime/ArrayPrototype.h: + (JSC::ArrayPrototype::createStructure): + * runtime/BatchedTransitionOptimizer.h: + (JSC::BatchedTransitionOptimizer::BatchedTransitionOptimizer): + (JSC::BatchedTransitionOptimizer::~BatchedTransitionOptimizer): + (BatchedTransitionOptimizer): + * runtime/BooleanConstructor.cpp: + (JSC::BooleanConstructor::finishCreation): + (JSC::constructBoolean): + (JSC::constructBooleanFromImmediateBoolean): + * runtime/BooleanConstructor.h: + (JSC::BooleanConstructor::createStructure): + * runtime/BooleanObject.cpp: + (JSC::BooleanObject::BooleanObject): + (JSC::BooleanObject::finishCreation): + * runtime/BooleanObject.h: + (BooleanObject): + (JSC::BooleanObject::create): + (JSC::BooleanObject::createStructure): + * runtime/BooleanPrototype.cpp: + (JSC::BooleanPrototype::BooleanPrototype): + (JSC::BooleanPrototype::finishCreation): + (JSC::booleanProtoFuncToString): + * runtime/BooleanPrototype.h: + (JSC::BooleanPrototype::createStructure): + * runtime/Butterfly.h: + (JSC): + (Butterfly): + * runtime/ButterflyInlines.h: + (JSC::Butterfly::createUninitialized): + (JSC::Butterfly::create): + (JSC::Butterfly::growPropertyStorage): + (JSC::Butterfly::createOrGrowArrayRight): + (JSC::Butterfly::growArrayRight): + (JSC::Butterfly::resizeArray): + * runtime/CodeCache.cpp: + (JSC::CodeCache::getCodeBlock): + (JSC::CodeCache::getProgramCodeBlock): + (JSC::CodeCache::getEvalCodeBlock): + (JSC::CodeCache::getFunctionExecutableFromGlobalCode): + * runtime/CodeCache.h: + (JSC): + (JSC::SourceCodeValue::SourceCodeValue): + (CodeCache): + * runtime/CommonIdentifiers.cpp: + (JSC): + (JSC::CommonIdentifiers::CommonIdentifiers): + * runtime/CommonIdentifiers.h: + (CommonIdentifiers): + * runtime/CommonSlowPaths.h: + (JSC::CommonSlowPaths::opIn): + * runtime/Completion.cpp: + (JSC::checkSyntax): + (JSC::evaluate): + * runtime/DateConstructor.cpp: + (JSC::DateConstructor::finishCreation): + * runtime/DateConstructor.h: + (JSC::DateConstructor::createStructure): + * runtime/DateInstance.cpp: + (JSC::DateInstance::DateInstance): + (JSC::DateInstance::finishCreation): + (JSC::DateInstance::calculateGregorianDateTime): + (JSC::DateInstance::calculateGregorianDateTimeUTC): + * runtime/DateInstance.h: + (DateInstance): + (JSC::DateInstance::create): + (JSC::DateInstance::createStructure): + * runtime/DatePrototype.cpp: + (JSC::DatePrototype::finishCreation): + (JSC::dateProtoFuncSetTime): + (JSC::setNewValueFromTimeArgs): + (JSC::setNewValueFromDateArgs): + (JSC::dateProtoFuncSetYear): + (JSC::dateProtoFuncToJSON): + * runtime/DatePrototype.h: + (JSC::DatePrototype::createStructure): + * runtime/Error.cpp: + (JSC::createError): + (JSC::createEvalError): + (JSC::createRangeError): + (JSC::createReferenceError): + (JSC::createSyntaxError): + (JSC::createTypeError): + (JSC::createURIError): + (JSC::addErrorInfo): + (JSC::throwError): + * runtime/Error.h: + (JSC): + (JSC::StrictModeTypeErrorFunction::create): + (JSC::StrictModeTypeErrorFunction::createStructure): + * runtime/ErrorConstructor.cpp: + (JSC::ErrorConstructor::finishCreation): + * runtime/ErrorConstructor.h: + (JSC::ErrorConstructor::createStructure): + * runtime/ErrorInstance.cpp: + (JSC::ErrorInstance::ErrorInstance): + * runtime/ErrorInstance.h: + (JSC::ErrorInstance::createStructure): + (JSC::ErrorInstance::create): + (ErrorInstance): + (JSC::ErrorInstance::finishCreation): + * runtime/ErrorPrototype.cpp: + (JSC::ErrorPrototype::ErrorPrototype): + (JSC::ErrorPrototype::finishCreation): + * runtime/ErrorPrototype.h: + (JSC::ErrorPrototype::createStructure): + * runtime/ExceptionHelpers.cpp: + (JSC::createInterruptedExecutionException): + (JSC::createTerminatedExecutionException): + * runtime/ExceptionHelpers.h: + (JSC): + (JSC::InterruptedExecutionError::InterruptedExecutionError): + (JSC::InterruptedExecutionError::create): + (JSC::InterruptedExecutionError::createStructure): + (JSC::TerminatedExecutionError::TerminatedExecutionError): + (JSC::TerminatedExecutionError::create): + (JSC::TerminatedExecutionError::createStructure): + * runtime/Executable.cpp: + (JSC::jettisonCodeBlock): + (JSC::EvalExecutable::EvalExecutable): + (JSC::ProgramExecutable::ProgramExecutable): + (JSC::FunctionExecutable::FunctionExecutable): + (JSC::EvalExecutable::compileOptimized): + (JSC::EvalExecutable::compileInternal): + (JSC::EvalExecutable::jettisonOptimizedCode): + (JSC::ProgramExecutable::checkSyntax): + (JSC::ProgramExecutable::compileOptimized): + (JSC::ProgramExecutable::jettisonOptimizedCode): + (JSC::ProgramExecutable::initializeGlobalProperties): + (JSC::FunctionExecutable::compileOptimizedForCall): + (JSC::FunctionExecutable::compileOptimizedForConstruct): + (JSC::FunctionExecutable::produceCodeBlockFor): + (JSC::FunctionExecutable::jettisonOptimizedCodeForCall): + (JSC::FunctionExecutable::jettisonOptimizedCodeForConstruct): + (JSC::FunctionExecutable::fromGlobalCode): + * runtime/Executable.h: + (JSC::ExecutableBase::ExecutableBase): + (JSC::ExecutableBase::finishCreation): + (JSC::ExecutableBase::createStructure): + (JSC::NativeExecutable::create): + (JSC::NativeExecutable::createStructure): + (JSC::NativeExecutable::finishCreation): + (JSC::NativeExecutable::NativeExecutable): + (JSC::ScriptExecutable::ScriptExecutable): + (JSC::ScriptExecutable::finishCreation): + (JSC::EvalExecutable::compile): + (EvalExecutable): + (JSC::EvalExecutable::create): + (JSC::EvalExecutable::createStructure): + (JSC::ProgramExecutable::create): + (ProgramExecutable): + (JSC::ProgramExecutable::compile): + (JSC::ProgramExecutable::createStructure): + (JSC::FunctionExecutable::create): + (JSC::FunctionExecutable::compileForCall): + (FunctionExecutable): + (JSC::FunctionExecutable::compileForConstruct): + (JSC::FunctionExecutable::jettisonOptimizedCodeFor): + (JSC::FunctionExecutable::createStructure): + (JSC::JSFunction::JSFunction): + * runtime/ExecutionHarness.h: + (JSC::prepareForExecution): + (JSC::prepareFunctionForExecution): + * runtime/FunctionConstructor.cpp: + (JSC::FunctionConstructor::finishCreation): + * runtime/FunctionConstructor.h: + (JSC::FunctionConstructor::createStructure): + * runtime/FunctionPrototype.cpp: + (JSC::FunctionPrototype::finishCreation): + (JSC::FunctionPrototype::addFunctionProperties): + (JSC::functionProtoFuncBind): + * runtime/FunctionPrototype.h: + (JSC::FunctionPrototype::createStructure): + * runtime/GCActivityCallback.cpp: + (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::doWork): + (JSC::DefaultGCActivityCallback::didAllocate): + * runtime/GCActivityCallback.h: + (JSC::GCActivityCallback::GCActivityCallback): + * runtime/GCActivityCallbackBlackBerry.cpp: + (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::doWork): + (JSC::DefaultGCActivityCallback::didAllocate): + * runtime/GetterSetter.h: + (JSC::GetterSetter::GetterSetter): + (JSC::GetterSetter::create): + (JSC::GetterSetter::setGetter): + (JSC::GetterSetter::setSetter): + (JSC::GetterSetter::createStructure): + * runtime/Identifier.cpp: + (JSC::Identifier::add): + (JSC::Identifier::add8): + (JSC::Identifier::addSlowCase): + (JSC::Identifier::from): + (JSC::Identifier::checkCurrentIdentifierTable): + * runtime/Identifier.h: + (JSC::Identifier::Identifier): + (JSC::Identifier::createLCharFromUChar): + (Identifier): + (JSC::Identifier::add): + * runtime/InternalFunction.cpp: + (JSC::InternalFunction::InternalFunction): + (JSC::InternalFunction::finishCreation): + (JSC::InternalFunction::name): + (JSC::InternalFunction::displayName): + * runtime/InternalFunction.h: + (JSC::InternalFunction::createStructure): + (InternalFunction): + * runtime/JSAPIValueWrapper.h: + (JSC::JSAPIValueWrapper::createStructure): + (JSC::JSAPIValueWrapper::finishCreation): + (JSC::JSAPIValueWrapper::JSAPIValueWrapper): + * runtime/JSActivation.cpp: + (JSC::JSActivation::symbolTablePut): + (JSC::JSActivation::symbolTablePutWithAttributes): + (JSC::JSActivation::getOwnPropertySlot): + (JSC::JSActivation::put): + (JSC::JSActivation::putDirectVirtual): + (JSC::JSActivation::argumentsGetter): + * runtime/JSActivation.h: + (JSActivation): + (JSC::JSActivation::create): + (JSC::JSActivation::createStructure): + (JSC::JSActivation::JSActivation): + (JSC::JSActivation::tearOff): + * runtime/JSArray.cpp: + (JSC::createArrayButterflyInDictionaryIndexingMode): + (JSC::JSArray::setLengthWritable): + (JSC::JSArray::unshiftCountSlowCase): + (JSC::JSArray::setLength): + (JSC::JSArray::push): + (JSC::JSArray::shiftCountWithAnyIndexingType): + (JSC::JSArray::unshiftCountWithArrayStorage): + (JSC::JSArray::unshiftCountWithAnyIndexingType): + (JSC::ContiguousTypeAccessor::setWithValue): + (JSC::JSArray::sortCompactedVector): + (JSC::JSArray::sortVector): + * runtime/JSArray.h: + (JSC::JSArray::JSArray): + (JSArray): + (JSC::JSArray::shiftCountForShift): + (JSC::JSArray::unshiftCountForShift): + (JSC::JSArray::createStructure): + (JSC::createContiguousArrayButterfly): + (JSC::createArrayButterfly): + (JSC): + (JSC::JSArray::create): + (JSC::JSArray::tryCreateUninitialized): + (JSC::constructArray): + * runtime/JSBoundFunction.cpp: + (JSC::JSBoundFunction::create): + (JSC::JSBoundFunction::JSBoundFunction): + * runtime/JSBoundFunction.h: + (JSC::JSBoundFunction::createStructure): + * runtime/JSCJSValue.cpp: + (JSC::JSValue::putToPrimitive): + (JSC::JSValue::toStringSlowCase): + * runtime/JSCJSValue.h: + (JSC): + * runtime/JSCell.h: + (JSCell): + * runtime/JSCellInlines.h: + (JSC::JSCell::JSCell): + (JSC::JSCell::finishCreation): + (JSC::allocateCell): + (JSC::JSCell::setStructure): + (JSC::JSCell::fastGetOwnProperty): + * runtime/JSDateMath.cpp: + (JSC::getDSTOffset): + (JSC::getUTCOffset): + (JSC::parseDate): + * runtime/JSDestructibleObject.h: + (JSC::JSDestructibleObject::JSDestructibleObject): + * runtime/JSFunction.cpp: + (JSC::JSFunction::create): + (JSC::JSFunction::JSFunction): + (JSC::JSFunction::finishCreation): + (JSC::JSFunction::createAllocationProfile): + (JSC::JSFunction::name): + (JSC::JSFunction::displayName): + (JSC::JSFunction::getOwnPropertySlot): + (JSC::JSFunction::deleteProperty): + * runtime/JSFunction.h: + (JSFunction): + (JSC::JSFunction::create): + (JSC::JSFunction::setScope): + (JSC::JSFunction::createStructure): + * runtime/JSGlobalData.cpp: Removed. + * runtime/JSGlobalData.h: Removed. + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + (JSC::JSGlobalObject::~JSGlobalObject): + (JSC::JSGlobalObject::setGlobalThis): + (JSC::JSGlobalObject::init): + (JSC::JSGlobalObject::putDirectVirtual): + (JSC::JSGlobalObject::reset): + (JSC): + (JSC::JSGlobalObject::haveABadTime): + (JSC::JSGlobalObject::createThrowTypeError): + (JSC::JSGlobalObject::resetPrototype): + (JSC::JSGlobalObject::addStaticGlobals): + (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope): + (JSC::JSGlobalObject::createProgramCodeBlock): + (JSC::JSGlobalObject::createEvalCodeBlock): + * runtime/JSGlobalObject.h: + (JSC::JSGlobalObject::create): + (JSGlobalObject): + (JSC::JSGlobalObject::finishCreation): + (JSC::JSGlobalObject::vm): + (JSC::JSGlobalObject::createStructure): + (JSC::ExecState::dynamicGlobalObject): + (JSC::constructEmptyArray): + (DynamicGlobalObjectScope): + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::globalFuncProtoSetter): + * runtime/JSLock.cpp: + (JSC::JSLockHolder::JSLockHolder): + (JSC::JSLockHolder::init): + (JSC::JSLockHolder::~JSLockHolder): + (JSC::JSLock::JSLock): + (JSC::JSLock::willDestroyGlobalData): + (JSC::JSLock::lock): + (JSC::JSLock::unlock): + (JSC::JSLock::DropAllLocks::DropAllLocks): + (JSC::JSLock::DropAllLocks::~DropAllLocks): + * runtime/JSLock.h: + (JSC): + (JSLockHolder): + (JSLock): + (JSC::JSLock::vm): + (DropAllLocks): + * runtime/JSNameScope.h: + (JSC::JSNameScope::createStructure): + (JSC::JSNameScope::finishCreation): + (JSC::JSNameScope::JSNameScope): + * runtime/JSNotAnObject.h: + (JSC::JSNotAnObject::JSNotAnObject): + (JSC::JSNotAnObject::create): + (JSC::JSNotAnObject::createStructure): + * runtime/JSONObject.cpp: + (JSC::JSONObject::JSONObject): + (JSC::JSONObject::finishCreation): + (Holder): + (JSC::Stringifier::Stringifier): + (JSC::Stringifier::stringify): + (JSC::Stringifier::toJSON): + (JSC::Stringifier::appendStringifiedValue): + (JSC::Stringifier::Holder::Holder): + (JSC::Stringifier::Holder::appendNextProperty): + (JSC::Walker::Walker): + (JSC::Walker::walk): + (JSC::JSONProtoFuncParse): + (JSC::JSONProtoFuncStringify): + (JSC::JSONStringify): + * runtime/JSONObject.h: + (JSC::JSONObject::createStructure): + * runtime/JSObject.cpp: + (JSC::JSObject::put): + (JSC::JSObject::putByIndex): + (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): + (JSC::JSObject::enterDictionaryIndexingMode): + (JSC::JSObject::notifyPresenceOfIndexedAccessors): + (JSC::JSObject::createInitialIndexedStorage): + (JSC::JSObject::createInitialUndecided): + (JSC::JSObject::createInitialInt32): + (JSC::JSObject::createInitialDouble): + (JSC::JSObject::createInitialContiguous): + (JSC::JSObject::createArrayStorage): + (JSC::JSObject::createInitialArrayStorage): + (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::genericConvertDoubleToContiguous): + (JSC::JSObject::convertDoubleToContiguous): + (JSC::JSObject::rageConvertDoubleToContiguous): + (JSC::JSObject::convertDoubleToArrayStorage): + (JSC::JSObject::convertContiguousToArrayStorage): + (JSC::JSObject::convertUndecidedForValue): + (JSC::JSObject::convertInt32ForValue): + (JSC::JSObject::setIndexQuicklyToUndecided): + (JSC::JSObject::convertInt32ToDoubleOrContiguousWhilePerformingSetIndex): + (JSC::JSObject::convertDoubleToContiguousWhilePerformingSetIndex): + (JSC::JSObject::ensureInt32Slow): + (JSC::JSObject::ensureDoubleSlow): + (JSC::JSObject::ensureContiguousSlow): + (JSC::JSObject::rageEnsureContiguousSlow): + (JSC::JSObject::ensureArrayStorageSlow): + (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): + (JSC::JSObject::switchToSlowPutArrayStorage): + (JSC::JSObject::putDirectVirtual): + (JSC::JSObject::setPrototype): + (JSC::JSObject::setPrototypeWithCycleCheck): + (JSC::JSObject::putDirectAccessor): + (JSC::JSObject::deleteProperty): + (JSC::JSObject::getPropertySpecificValue): + (JSC::JSObject::getOwnNonIndexPropertyNames): + (JSC::JSObject::seal): + (JSC::JSObject::freeze): + (JSC::JSObject::preventExtensions): + (JSC::JSObject::reifyStaticFunctionsForDelete): + (JSC::JSObject::removeDirect): + (JSC::JSObject::putIndexedDescriptor): + (JSC::JSObject::defineOwnIndexedProperty): + (JSC::JSObject::allocateSparseIndexMap): + (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): + (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage): + (JSC::JSObject::putByIndexBeyondVectorLength): + (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage): + (JSC::JSObject::putDirectIndexBeyondVectorLength): + (JSC::JSObject::putDirectNativeFunction): + (JSC::JSObject::increaseVectorLength): + (JSC::JSObject::ensureLengthSlow): + (JSC::JSObject::growOutOfLineStorage): + (JSC::JSObject::getOwnPropertyDescriptor): + (JSC::putDescriptor): + (JSC::JSObject::putDirectMayBeIndex): + (JSC::DefineOwnPropertyScope::DefineOwnPropertyScope): + (JSC::DefineOwnPropertyScope::~DefineOwnPropertyScope): + (DefineOwnPropertyScope): + (JSC::JSObject::defineOwnNonIndexProperty): + * runtime/JSObject.h: + (JSObject): + (JSC::JSObject::putByIndexInline): + (JSC::JSObject::putDirectIndex): + (JSC::JSObject::setIndexQuickly): + (JSC::JSObject::initializeIndex): + (JSC::JSObject::getDirect): + (JSC::JSObject::getDirectOffset): + (JSC::JSObject::putDirect): + (JSC::JSObject::isSealed): + (JSC::JSObject::isFrozen): + (JSC::JSObject::flattenDictionaryObject): + (JSC::JSObject::ensureInt32): + (JSC::JSObject::ensureDouble): + (JSC::JSObject::ensureContiguous): + (JSC::JSObject::rageEnsureContiguous): + (JSC::JSObject::ensureArrayStorage): + (JSC::JSObject::finishCreation): + (JSC::JSObject::createStructure): + (JSC::JSObject::ensureLength): + (JSC::JSNonFinalObject::createStructure): + (JSC::JSNonFinalObject::JSNonFinalObject): + (JSC::JSNonFinalObject::finishCreation): + (JSC::JSFinalObject::createStructure): + (JSC::JSFinalObject::finishCreation): + (JSC::JSFinalObject::JSFinalObject): + (JSC::JSFinalObject::create): + (JSC::JSObject::setButterfly): + (JSC::JSObject::JSObject): + (JSC::JSObject::inlineGetOwnPropertySlot): + (JSC::JSObject::putDirectInternal): + (JSC::JSObject::setStructureAndReallocateStorageIfNecessary): + (JSC::JSObject::putOwnDataProperty): + (JSC::JSObject::putDirectWithoutTransition): + (JSC): + * runtime/JSPropertyNameIterator.cpp: + (JSC::JSPropertyNameIterator::JSPropertyNameIterator): + (JSC::JSPropertyNameIterator::create): + * runtime/JSPropertyNameIterator.h: + (JSC::JSPropertyNameIterator::createStructure): + (JSC::JSPropertyNameIterator::setCachedStructure): + (JSC::JSPropertyNameIterator::setCachedPrototypeChain): + (JSC::JSPropertyNameIterator::finishCreation): + (JSC::StructureRareData::setEnumerationCache): + * runtime/JSProxy.cpp: + (JSC::JSProxy::setTarget): + * runtime/JSProxy.h: + (JSC::JSProxy::create): + (JSC::JSProxy::createStructure): + (JSC::JSProxy::JSProxy): + (JSC::JSProxy::finishCreation): + (JSProxy): + * runtime/JSScope.cpp: + (JSC::executeResolveOperations): + (JSC::JSScope::resolveContainingScopeInternal): + (JSC::JSScope::resolveWithBase): + (JSC::JSScope::resolveWithThis): + (JSC::JSScope::resolvePut): + * runtime/JSScope.h: + (JSScope): + (JSC::JSScope::JSScope): + (JSC::JSScope::vm): + (JSC::ExecState::vm): + * runtime/JSSegmentedVariableObject.h: + (JSC::JSSegmentedVariableObject::JSSegmentedVariableObject): + (JSC::JSSegmentedVariableObject::finishCreation): + * runtime/JSString.cpp: + (JSC::JSRopeString::RopeBuilder::expand): + (JSC::StringObject::create): + * runtime/JSString.h: + (JSC): + (JSString): + (JSC::JSString::JSString): + (JSC::JSString::finishCreation): + (JSC::JSString::create): + (JSC::JSString::createHasOtherOwner): + (JSC::JSString::createStructure): + (JSRopeString): + (JSC::JSRopeString::RopeBuilder::RopeBuilder): + (JSC::JSRopeString::RopeBuilder::append): + (RopeBuilder): + (JSC::JSRopeString::JSRopeString): + (JSC::JSRopeString::finishCreation): + (JSC::JSRopeString::append): + (JSC::JSRopeString::createNull): + (JSC::JSRopeString::create): + (JSC::jsEmptyString): + (JSC::jsSingleCharacterString): + (JSC::jsSingleCharacterSubstring): + (JSC::jsNontrivialString): + (JSC::jsString): + (JSC::jsSubstring): + (JSC::jsSubstring8): + (JSC::jsOwnedString): + (JSC::jsStringBuilder): + (JSC::inlineJSValueNotStringtoString): + * runtime/JSStringJoiner.cpp: + (JSC::JSStringJoiner::build): + * runtime/JSSymbolTableObject.h: + (JSC::JSSymbolTableObject::JSSymbolTableObject): + (JSC::JSSymbolTableObject::finishCreation): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): + * runtime/JSVariableObject.h: + (JSC::JSVariableObject::JSVariableObject): + * runtime/JSWithScope.h: + (JSC::JSWithScope::create): + (JSC::JSWithScope::createStructure): + (JSC::JSWithScope::JSWithScope): + * runtime/JSWrapperObject.h: + (JSWrapperObject): + (JSC::JSWrapperObject::createStructure): + (JSC::JSWrapperObject::JSWrapperObject): + (JSC::JSWrapperObject::setInternalValue): + * runtime/LiteralParser.cpp: + (JSC::::tryJSONPParse): + (JSC::::makeIdentifier): + (JSC::::parse): + * runtime/Lookup.cpp: + (JSC::HashTable::createTable): + (JSC::setUpStaticFunctionSlot): + * runtime/Lookup.h: + (JSC::HashTable::initializeIfNeeded): + (JSC::HashTable::entry): + (JSC::HashTable::begin): + (JSC::HashTable::end): + (HashTable): + (JSC::lookupPut): + * runtime/MathObject.cpp: + (JSC::MathObject::MathObject): + (JSC::MathObject::finishCreation): + (JSC::mathProtoFuncSin): + * runtime/MathObject.h: + (JSC::MathObject::createStructure): + * runtime/MemoryStatistics.cpp: + * runtime/MemoryStatistics.h: + * runtime/NameConstructor.cpp: + (JSC::NameConstructor::finishCreation): + (JSC::constructPrivateName): + * runtime/NameConstructor.h: + (JSC::NameConstructor::createStructure): + * runtime/NameInstance.cpp: + (JSC::NameInstance::NameInstance): + * runtime/NameInstance.h: + (JSC::NameInstance::createStructure): + (JSC::NameInstance::create): + (NameInstance): + (JSC::NameInstance::finishCreation): + * runtime/NamePrototype.cpp: + (JSC::NamePrototype::NamePrototype): + (JSC::NamePrototype::finishCreation): + * runtime/NamePrototype.h: + (JSC::NamePrototype::createStructure): + * runtime/NativeErrorConstructor.h: + (JSC::NativeErrorConstructor::createStructure): + (JSC::NativeErrorConstructor::finishCreation): + * runtime/NativeErrorPrototype.cpp: + (JSC::NativeErrorPrototype::finishCreation): + * runtime/NumberConstructor.cpp: + (JSC::NumberConstructor::finishCreation): + (JSC::constructWithNumberConstructor): + * runtime/NumberConstructor.h: + (JSC::NumberConstructor::createStructure): + * runtime/NumberObject.cpp: + (JSC::NumberObject::NumberObject): + (JSC::NumberObject::finishCreation): + (JSC::constructNumber): + * runtime/NumberObject.h: + (NumberObject): + (JSC::NumberObject::create): + (JSC::NumberObject::createStructure): + * runtime/NumberPrototype.cpp: + (JSC::NumberPrototype::NumberPrototype): + (JSC::NumberPrototype::finishCreation): + (JSC::integerValueToString): + (JSC::numberProtoFuncToString): + * runtime/NumberPrototype.h: + (JSC::NumberPrototype::createStructure): + * runtime/ObjectConstructor.cpp: + (JSC::ObjectConstructor::finishCreation): + (JSC::objectConstructorGetOwnPropertyDescriptor): + (JSC::objectConstructorSeal): + (JSC::objectConstructorFreeze): + (JSC::objectConstructorPreventExtensions): + (JSC::objectConstructorIsSealed): + (JSC::objectConstructorIsFrozen): + * runtime/ObjectConstructor.h: + (JSC::ObjectConstructor::createStructure): + (JSC::constructEmptyObject): + * runtime/ObjectPrototype.cpp: + (JSC::ObjectPrototype::ObjectPrototype): + (JSC::ObjectPrototype::finishCreation): + (JSC::objectProtoFuncToString): + * runtime/ObjectPrototype.h: + (JSC::ObjectPrototype::createStructure): + * runtime/Operations.cpp: + (JSC::jsTypeStringForValue): + * runtime/Operations.h: + (JSC): + (JSC::jsString): + (JSC::jsStringFromArguments): + (JSC::normalizePrototypeChainForChainAccess): + (JSC::normalizePrototypeChain): + * runtime/PropertyMapHashTable.h: + (JSC::PropertyMapEntry::PropertyMapEntry): + (JSC::PropertyTable::createStructure): + (PropertyTable): + (JSC::PropertyTable::copy): + * runtime/PropertyNameArray.h: + (JSC::PropertyNameArray::PropertyNameArray): + (JSC::PropertyNameArray::vm): + (JSC::PropertyNameArray::addKnownUnique): + (PropertyNameArray): + * runtime/PropertyTable.cpp: + (JSC::PropertyTable::create): + (JSC::PropertyTable::clone): + (JSC::PropertyTable::PropertyTable): + * runtime/PrototypeMap.cpp: + (JSC::PrototypeMap::emptyObjectStructureForPrototype): + * runtime/RegExp.cpp: + (JSC::RegExp::RegExp): + (JSC::RegExp::finishCreation): + (JSC::RegExp::createWithoutCaching): + (JSC::RegExp::create): + (JSC::RegExp::compile): + (JSC::RegExp::compileIfNecessary): + (JSC::RegExp::match): + (JSC::RegExp::compileMatchOnly): + (JSC::RegExp::compileIfNecessaryMatchOnly): + * runtime/RegExp.h: + (JSC): + (RegExp): + (JSC::RegExp::createStructure): + * runtime/RegExpCache.cpp: + (JSC::RegExpCache::lookupOrCreate): + (JSC::RegExpCache::RegExpCache): + (JSC::RegExpCache::addToStrongCache): + * runtime/RegExpCache.h: + (RegExpCache): + * runtime/RegExpCachedResult.cpp: + (JSC::RegExpCachedResult::lastResult): + (JSC::RegExpCachedResult::setInput): + * runtime/RegExpCachedResult.h: + (JSC::RegExpCachedResult::RegExpCachedResult): + (JSC::RegExpCachedResult::record): + * runtime/RegExpConstructor.cpp: + (JSC::RegExpConstructor::RegExpConstructor): + (JSC::RegExpConstructor::finishCreation): + (JSC::constructRegExp): + * runtime/RegExpConstructor.h: + (JSC::RegExpConstructor::createStructure): + (RegExpConstructor): + (JSC::RegExpConstructor::performMatch): + * runtime/RegExpMatchesArray.cpp: + (JSC::RegExpMatchesArray::RegExpMatchesArray): + (JSC::RegExpMatchesArray::create): + (JSC::RegExpMatchesArray::finishCreation): + (JSC::RegExpMatchesArray::reifyAllProperties): + * runtime/RegExpMatchesArray.h: + (RegExpMatchesArray): + (JSC::RegExpMatchesArray::createStructure): + * runtime/RegExpObject.cpp: + (JSC::RegExpObject::RegExpObject): + (JSC::RegExpObject::finishCreation): + (JSC::RegExpObject::match): + * runtime/RegExpObject.h: + (JSC::RegExpObject::create): + (JSC::RegExpObject::setRegExp): + (JSC::RegExpObject::setLastIndex): + (JSC::RegExpObject::createStructure): + * runtime/RegExpPrototype.cpp: + (JSC::regExpProtoFuncCompile): + * runtime/RegExpPrototype.h: + (JSC::RegExpPrototype::createStructure): + * runtime/SmallStrings.cpp: + (JSC::SmallStrings::initializeCommonStrings): + (JSC::SmallStrings::createEmptyString): + (JSC::SmallStrings::createSingleCharacterString): + (JSC::SmallStrings::initialize): + * runtime/SmallStrings.h: + (JSC): + (JSC::SmallStrings::singleCharacterString): + (SmallStrings): + * runtime/SparseArrayValueMap.cpp: + (JSC::SparseArrayValueMap::SparseArrayValueMap): + (JSC::SparseArrayValueMap::finishCreation): + (JSC::SparseArrayValueMap::create): + (JSC::SparseArrayValueMap::createStructure): + (JSC::SparseArrayValueMap::putDirect): + (JSC::SparseArrayEntry::put): + * runtime/SparseArrayValueMap.h: + * runtime/StrictEvalActivation.cpp: + (JSC::StrictEvalActivation::StrictEvalActivation): + * runtime/StrictEvalActivation.h: + (JSC::StrictEvalActivation::create): + (JSC::StrictEvalActivation::createStructure): + * runtime/StringConstructor.cpp: + (JSC::StringConstructor::finishCreation): + * runtime/StringConstructor.h: + (JSC::StringConstructor::createStructure): + * runtime/StringObject.cpp: + (JSC::StringObject::StringObject): + (JSC::StringObject::finishCreation): + (JSC::constructString): + * runtime/StringObject.h: + (JSC::StringObject::create): + (JSC::StringObject::createStructure): + (StringObject): + * runtime/StringPrototype.cpp: + (JSC::StringPrototype::StringPrototype): + (JSC::StringPrototype::finishCreation): + (JSC::removeUsingRegExpSearch): + (JSC::replaceUsingRegExpSearch): + (JSC::stringProtoFuncMatch): + (JSC::stringProtoFuncSearch): + (JSC::stringProtoFuncSplit): + * runtime/StringPrototype.h: + (JSC::StringPrototype::createStructure): + * runtime/StringRecursionChecker.h: + (JSC::StringRecursionChecker::performCheck): + (JSC::StringRecursionChecker::~StringRecursionChecker): + * runtime/Structure.cpp: + (JSC::StructureTransitionTable::add): + (JSC::Structure::Structure): + (JSC::Structure::materializePropertyMap): + (JSC::Structure::despecifyDictionaryFunction): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::removePropertyTransition): + (JSC::Structure::changePrototypeTransition): + (JSC::Structure::despecifyFunctionTransition): + (JSC::Structure::attributeChangeTransition): + (JSC::Structure::toDictionaryTransition): + (JSC::Structure::toCacheableDictionaryTransition): + (JSC::Structure::toUncacheableDictionaryTransition): + (JSC::Structure::sealTransition): + (JSC::Structure::freezeTransition): + (JSC::Structure::preventExtensionsTransition): + (JSC::Structure::takePropertyTableOrCloneIfPinned): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::isSealed): + (JSC::Structure::isFrozen): + (JSC::Structure::flattenDictionaryStructure): + (JSC::Structure::addPropertyWithoutTransition): + (JSC::Structure::removePropertyWithoutTransition): + (JSC::Structure::allocateRareData): + (JSC::Structure::cloneRareDataFrom): + (JSC::Structure::copyPropertyTable): + (JSC::Structure::copyPropertyTableForPinning): + (JSC::Structure::get): + (JSC::Structure::despecifyFunction): + (JSC::Structure::despecifyAllFunctions): + (JSC::Structure::putSpecificValue): + (JSC::Structure::createPropertyMap): + (JSC::Structure::getPropertyNamesFromStructure): + (JSC::Structure::prototypeChainMayInterceptStoreTo): + * runtime/Structure.h: + (Structure): + (JSC::Structure::finishCreation): + (JSC::Structure::setPrototypeWithoutTransition): + (JSC::Structure::setGlobalObject): + (JSC::Structure::setObjectToStringValue): + (JSC::Structure::materializePropertyMapIfNecessary): + (JSC::Structure::materializePropertyMapIfNecessaryForPinning): + (JSC::Structure::setPreviousID): + * runtime/StructureChain.cpp: + (JSC::StructureChain::StructureChain): + * runtime/StructureChain.h: + (JSC::StructureChain::create): + (JSC::StructureChain::createStructure): + (JSC::StructureChain::finishCreation): + (StructureChain): + * runtime/StructureInlines.h: + (JSC::Structure::create): + (JSC::Structure::createStructure): + (JSC::Structure::get): + (JSC::Structure::setEnumerationCache): + (JSC::Structure::prototypeChain): + (JSC::Structure::propertyTable): + * runtime/StructureRareData.cpp: + (JSC::StructureRareData::createStructure): + (JSC::StructureRareData::create): + (JSC::StructureRareData::clone): + (JSC::StructureRareData::StructureRareData): + * runtime/StructureRareData.h: + (StructureRareData): + * runtime/StructureRareDataInlines.h: + (JSC::StructureRareData::setPreviousID): + (JSC::StructureRareData::setObjectToStringValue): + * runtime/StructureTransitionTable.h: + (StructureTransitionTable): + (JSC::StructureTransitionTable::setSingleTransition): + * runtime/SymbolTable.h: + (JSC::SharedSymbolTable::create): + (JSC::SharedSymbolTable::createStructure): + (JSC::SharedSymbolTable::SharedSymbolTable): + * runtime/VM.cpp: Copied from Source/JavaScriptCore/runtime/JSGlobalData.cpp. + (JSC::VM::VM): + (JSC::VM::~VM): + (JSC::VM::createContextGroup): + (JSC::VM::create): + (JSC::VM::createLeaked): + (JSC::VM::sharedInstanceExists): + (JSC::VM::sharedInstance): + (JSC::VM::sharedInstanceInternal): + (JSC::VM::getHostFunction): + (JSC::VM::ClientData::~ClientData): + (JSC::VM::resetDateCache): + (JSC::VM::startSampling): + (JSC::VM::stopSampling): + (JSC::VM::discardAllCode): + (JSC::VM::dumpSampleData): + (JSC::VM::addSourceProviderCache): + (JSC::VM::clearSourceProviderCaches): + (JSC::VM::releaseExecutableMemory): + (JSC::releaseExecutableMemory): + (JSC::VM::gatherConservativeRoots): + (JSC::VM::addRegExpToTrace): + (JSC::VM::dumpRegExpTrace): + * runtime/VM.h: Copied from Source/JavaScriptCore/runtime/JSGlobalData.h. + (VM): + (JSC::VM::isSharedInstance): + (JSC::VM::usingAPI): + (JSC::VM::isInitializingObject): + (JSC::VM::setInitializingObjectClass): + (JSC::WeakSet::heap): + * runtime/WriteBarrier.h: + (JSC): + (JSC::WriteBarrierBase::set): + (JSC::WriteBarrierBase::setMayBeNull): + (JSC::WriteBarrierBase::setEarlyValue): + (JSC::WriteBarrier::WriteBarrier): + * testRegExp.cpp: + (GlobalObject): + (GlobalObject::create): + (GlobalObject::createStructure): + (GlobalObject::finishCreation): + (main): + (testOneRegExp): + (parseRegExpLine): + (runFromFiles): + (realMain): + * yarr/YarrInterpreter.h: + (BytecodePattern): + * yarr/YarrJIT.cpp: + (YarrGenerator): + (JSC::Yarr::YarrGenerator::compile): + (JSC::Yarr::jitCompile): + * yarr/YarrJIT.h: + (JSC): + +2013-04-18 Xuefei Ren <xren@blackberry.com> + + remove build warning(unused parameter) + https://bugs.webkit.org/show_bug.cgi?id=114670 + + Reviewed by Rob Buis. + + remove warning in Source/JavaScriptCore/runtime/GCActivityCallbackBlackBerry.cpp + + * runtime/GCActivityCallbackBlackBerry.cpp: + (JSC::DefaultGCActivityCallback::didAllocate): + +2013-04-18 Jonathan Liu <net147@gmail.com> + + Implement JIT for MinGW-w64 64-bit + https://bugs.webkit.org/show_bug.cgi?id=114580 + + Reviewed by Jocelyn Turcotte. + + * jit/JITStubs.cpp: + (JSC): + +2013-04-17 Mark Lam <mark.lam@apple.com> + + Avoid using a branch range that is too far for some CPU architectures. + https://bugs.webkit.org/show_bug.cgi?id=114782. + + Reviewed by David Kilzer. + + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2013-04-17 Julien Brianceau <jbrianceau@nds.com> + + Fix SH4 build (broken since r148639). + https://bugs.webkit.org/show_bug.cgi?id=114773. + + Allow longer displacements for specific branches in SH4 LLINT. + + Reviewed by Oliver Hunt. + + * offlineasm/sh4.rb: + +2013-04-14 Roger Fong <roger_fong@apple.com> + + Unreviewed. More Windows build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-14 Roger Fong <roger_fong@apple.com> + + Unreviewed. Windows build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-17 Mark Lam <mark.lam@apple.com> + + Fix broken build. Replaced a static const with a #define. + https://bugs.webkit.org/show_bug.cgi?id=114577. + + Unreviewed. + + * runtime/Watchdog.cpp: + (JSC::Watchdog::Watchdog): + (JSC::Watchdog::isEnabled): + +2013-04-17 Mark Lam <mark.lam@apple.com> + + Add LLINT and baseline JIT support for timing out scripts. + https://bugs.webkit.org/show_bug.cgi?id=114577. + + Reviewed by Geoffrey Garen. + + Introduces the new Watchdog class which is used to track script + execution time, and initiate script termination if needed. + + * API/JSContextRef.cpp: + (internalScriptTimeoutCallback): + (JSContextGroupSetExecutionTimeLimit): + (JSContextGroupClearExecutionTimeLimit): + * API/JSContextRefPrivate.h: + - Added new script execution time limit APIs. + * API/tests/testapi.c: + (currentCPUTime): + (shouldTerminateCallback): + (cancelTerminateCallback): + (extendTerminateCallback): + (main): + - Added new API tests for script execution time limit. + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitLoopHint): + - loop hints are needed for the llint as well. Hence, it will be + emitted unconditionally. + * interpreter/Interpreter.cpp: + (JSC::Interpreter::addStackTraceIfNecessary): + (JSC::Interpreter::throwException): + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + - Added checks for script termination before entering script code. + * jit/JIT.cpp: + (JSC::JIT::emitWatchdogTimerCheck): + * jit/JIT.h: + (JSC::JIT::emit_op_loop_hint): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION(void, handle_watchdog_timer)): + * jit/JITStubs.h: + * llint/LLIntExceptions.cpp: + (JSC::LLInt::doThrow): + - Factored out some common code from returnToThrow() and callToThrow(). + (JSC::LLInt::returnToThrow): + (JSC::LLInt::callToThrow): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL(slow_path_handle_watchdog_timer)): + * llint/LLIntSlowPaths.h: + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/ExceptionHelpers.cpp: + (JSC::throwTerminatedExecutionException): + - Also removed the now unused InterruptedExecutionException. + * runtime/ExceptionHelpers.h: + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + - Added watchdog, and removed the now obsolete Terminator. + * runtime/Terminator.h: Removed. + * runtime/Watchdog.cpp: Added. + (JSC::Watchdog::Watchdog): + (JSC::Watchdog::~Watchdog): + (JSC::Watchdog::setTimeLimit): + (JSC::Watchdog::didFire): + (JSC::Watchdog::isEnabled): + (JSC::Watchdog::fire): + (JSC::Watchdog::arm): + (JSC::Watchdog::disarm): + (JSC::Watchdog::startCountdownIfNeeded): + (JSC::Watchdog::startCountdown): + (JSC::Watchdog::stopCountdown): + (JSC::Watchdog::Scope::Scope): + (JSC::Watchdog::Scope::~Scope): + * runtime/Watchdog.h: Added. + (Watchdog): + (JSC::Watchdog::didFire): + (JSC::Watchdog::timerDidFireAddress): + (JSC::Watchdog::isArmed): + (Watchdog::Scope): + * runtime/WatchdogMac.cpp: Added. + (JSC::Watchdog::initTimer): + (JSC::Watchdog::destroyTimer): + (JSC::Watchdog::startTimer): + (JSC::Watchdog::stopTimer): + * runtime/WatchdogNone.cpp: Added. + (JSC::Watchdog::initTimer): + (JSC::Watchdog::destroyTimer): + (JSC::Watchdog::startTimer): + (JSC::Watchdog::stopTimer): + +2013-04-14 Roger Fong <roger_fong@apple.com> + + Unreviewed. VS2010 Windows build fix. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd: + +2013-04-14 Roger Fong <roger_fong@apple.com> + + Copy make-file-export-generator script to the the Source folders of the projects that use it. + <rdar://problem/13675604> + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorBuildCmd.cmd: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/make-export-file-generator: Copied from Source/WebCore/make-export-file-generator. + +2013-04-17 Brent Fulgham <bfulgham@webkit.org> + + [Windows, WinCairo] Stop individually building WTF files in JSC. + https://bugs.webkit.org/show_bug.cgi?id=114705 + + Reviewed by Anders Carlsson. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + Export additional String/fastMalloc symbols needed by JSC program. + * JavaScriptCore.vcproj/jsc/jsc.vcproj: Don't manually build + WTF implementation files (a second time!) in this project. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + Export additional String/fastMalloc symbols needed by JSC program. + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Don't manually + build WTF implementation files (a second time!) in this project. + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Ditto. + +2013-04-17 Mark Lam <mark.lam@apple.com> + + releaseExecutableMemory() should canonicalize cell liveness data before + it scans the GC roots. + https://bugs.webkit.org/show_bug.cgi?id=114733. + + Reviewed by Mark Hahnenberg. + + * heap/Heap.cpp: + (JSC::Heap::canonicalizeCellLivenessData): + * heap/Heap.h: + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::releaseExecutableMemory): + +2013-04-16 Commit Queue <rniwa@webkit.org> + + Unreviewed, rolling out r148576. + http://trac.webkit.org/changeset/148576 + https://bugs.webkit.org/show_bug.cgi?id=114714 + + WebCore is building some of these same files (Requested by + bfulgham on #webkit). + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcproj/jsc/jsc.vcproj: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: + +2013-04-16 Brent Fulgham <bfulgham@webkit.org> + + [Windows, WinCairo] Stop individually building WTF files in JSC. + https://bugs.webkit.org/show_bug.cgi?id=114705 + + Reviewed by Anders Carlsson. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + Export additional String/fastMalloc symbols needed by JSC program. + * JavaScriptCore.vcproj/jsc/jsc.vcproj: Don't manually build + WTF implementation files (a second time!) in this project. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + Export additional String/fastMalloc symbols needed by JSC program. + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Don't manually + build WTF implementation files (a second time!) in this project. + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Ditto. + +2013-04-16 Patrick Gansterer <paroga@webkit.org> + + [CMake] Do not use JAVASCRIPTCORE_DIR in add_custom_command() of JavaScriptCore project + https://bugs.webkit.org/show_bug.cgi?id=114265 + + Reviewed by Brent Fulgham. + + Use CMAKE_CURRENT_SOURCE_DIR instead, since it provides the same value and is more + understandable. Also move the GENERATE_HASH_LUT macro into the CMakeLists.txt + of JavaScriptCore to avoid the usage of JAVASCRIPTCORE_DIR there too. + + * CMakeLists.txt: + +2013-04-16 Anders Carlsson <andersca@apple.com> + + Another Windows build fix attempt. + + * runtime/JSGlobalData.h: + (JSGlobalData): + +2013-04-16 Anders Carlsson <andersca@apple.com> + + Try to fix the Windows build. + + * runtime/JSGlobalData.h: + +2013-04-16 Brent Fulgham <bfulgham@webkit.org> + + [Windows] Unreviewed VS2010 build correction. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: + Specify proper link library to avoid mixture of ICU 4.0 and 4.6 + symbols during link. + +2013-04-15 Ryosuke Niwa <rniwa@webkit.org> + + Windows clean build fix after r148479. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-15 Anders Carlsson <andersca@apple.com> + + ScriptWrappable subclasses shouldn't have to include WeakInlines.h + https://bugs.webkit.org/show_bug.cgi?id=114641 + + Reviewed by Alexey Proskuryakov. + + Move back the Weak constructor, destructor and clear() to Weak.h. Add a new weakClearSlowCase function + and put it in Weak.cpp. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * heap/Weak.cpp: Added. + * heap/Weak.h: + * heap/WeakInlines.h: + * heap/WeakSetInlines.h: + +2013-04-15 Mark Hahnenberg <mhahnenberg@apple.com> + + HeapTimer lifetime should be less complicated + https://bugs.webkit.org/show_bug.cgi?id=114529 + + Reviewed by Oliver Hunt. + + Right now our HeapTimer lifetime is rather complicated. HeapTimers are "owned" by the JSGlobalData, + but there's an issue in that there can be races between a thread that is trying to tear down a JSGlobalData + and the HeapTimer's fire function. Our current code for tearing down HeapTimers is an intricate and delicate + dance which probably contains subtle bugs. + + We can make our lives easier by changing things around a bit. + + 1) We should free the API lock from being solely owned by the JSGlobalData so we don't have to worry about + grabbing the lock out of invalid memory when our HeapTimer callback fires. + + 2) We should also make it so that we deref the JSGlobalData first, then unlock the API lock so that when we + have the lock, the JSGlobalData is in one of two states: fully valid or completely destroyed, and we know exactly which one. + + 3) The JSLock can tell us this information by keeping a back pointer to the JSGlobalData. When the JSGlobalData's + destructor is called, it clears this pointer in the JSLock. Other clients of the API lock can then check + this pointer to determine whether or not the JSGlobalData is still around. + + 4) The CFRunLoopTimer will use the API lock as its context rather than the HeapTimer itself. The only way + the HeapTimer's callback can get to the HeapTimer is through the API lock's JSGlobalData pointer. + + 5) The CFRunLoopTimerContext struct has two fields for retain and release callbacks for the context's info field. + We'll provide these callbacks to ref() and deref() the JSLock as necessary. Thus, the timer becomes the other + owner of the JSLock apart from the JSGlobalData. + + * API/APIShims.h: Remove the cruft that was required by the previous design, such as RefGlobalDataTag. + (JSC::APIEntryShimWithoutLock::APIEntryShimWithoutLock): + (JSC::APIEntryShimWithoutLock::~APIEntryShimWithoutLock): + (APIEntryShimWithoutLock): + (JSC::APIEntryShim::APIEntryShim): + (JSC::APIEntryShim::~APIEntryShim): Protect the API lock with a RefPtr, deref the JSGlobalData, which could destroy it, + then unlock the API lock. This ordering prevents others from obtaining the API lock while the JSGlobalData is in the + middle of being torn down. + (JSC::APIEntryShim::init): We now take the lock, then ref the JSGlobalData, which is the opposite order of when we + tear down the shim. + * heap/Heap.cpp: + (JSC::Heap::setActivityCallback): Use PassOwnPtr now. + (JSC::Heap::activityCallback): Ditto. + (JSC::Heap::sweeper): Ditto. + (JSC): + * heap/Heap.h: + (Heap): + * heap/HeapTimer.cpp: + (JSC::retainAPILock): Retain callback for CFRunLoopTimerContext struct. + (JSC::releaseAPILock): Release callback for the CFRunLoopTimerContext struct. + (JSC::HeapTimer::HeapTimer): Use the API lock as the context's info field rather than the HeapTimer. + (JSC::HeapTimer::timerDidFire): Grab the API lock. Return early if the JSGlobalData has already been destroyed. + Otherwise, figure out which kind of HeapTimer we are based on the CFRunLoopTimerRef passed to the callback and + call the HeapTimer's callback. + * heap/HeapTimer.h: + (HeapTimer): + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::create): PassOwnPtr all the things. + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * jsc.cpp: + (jscmain): We use an APIEntryShim instead of a RefPtr for the JSGlobalData because we need to + tear down the JSGlobalData while we still hold the lock, which the APIEntryShim handles correctly. + * runtime/GCActivityCallback.h: + (DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::create): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::~JSGlobalData): Notify the API lock that the JSGlobalData is being torn down. + * runtime/JSGlobalData.h: + (JSGlobalData): + (JSC::JSGlobalData::apiLock): + * runtime/JSLock.cpp: + (JSC::JSLockHolder::JSLockHolder): Ref, then lock (just like the API shim). + (JSC): + (JSC::JSLock::willDestroyGlobalData): + (JSC::JSLockHolder::init): + (JSC::JSLockHolder::~JSLockHolder): Protect, deref, then unlock (just like the API shim). + (JSC::JSLock::JSLock): + * runtime/JSLock.h: Add back pointer to the JSGlobalData and a callback for when the JSGlobalData is being + torn down that clears this pointer to notify other clients (i.e. timer callbacks) that the JSGlobalData is no + longer valid. + (JSLockHolder): + (JSLock): + (JSC::JSLock::globalData): + * testRegExp.cpp: + (realMain): We use an APIEntryShim instead of a RefPtr for the JSGlobalData because we need to + tear down the JSGlobalData while we still hold the lock, which the APIEntryShim handles correctly. + +2013-04-15 Julien Brianceau <jbrianceau@nds.com> + + LLInt SH4 backend implementation + https://bugs.webkit.org/show_bug.cgi?id=112886 + + Reviewed by Oliver Hunt. + + * dfg/DFGOperations.cpp: + (JSC): + * jit/JITStubs.cpp: + * llint/LLIntOfflineAsmConfig.h: + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * offlineasm/arm.rb: + * offlineasm/ast.rb: + * offlineasm/backends.rb: + * offlineasm/instructions.rb: + * offlineasm/mips.rb: + * offlineasm/risc.rb: + * offlineasm/sh4.rb: Added. + +2013-04-15 Patrick Gansterer <paroga@webkit.org> + + [CMake] Add WTF_USE_*_UNICODE variables + https://bugs.webkit.org/show_bug.cgi?id=114556 + + Reviewed by Brent Fulgham. + + WTF_USE_ICU_UNICODE and WTF_USE_WCHAR_UNICODE are used to + reduce duplication in the platform specific CMake files. + + * CMakeLists.txt: + * PlatformEfl.cmake: + +2013-04-13 Patrick Gansterer <paroga@webkit.org> + + Add missing export macro to SymbolTableEntry::freeFatEntrySlow() + + * runtime/SymbolTable.h: + (SymbolTableEntry): + +2013-04-12 Mark Hahnenberg <mhahnenberg@apple.com> + + Block freeing thread should call Region::destroy instead of delete + https://bugs.webkit.org/show_bug.cgi?id=114544 + + Reviewed by Oliver Hunt. + + Since Region doesn't have a virtual destructor, calling delete will not properly clean up all of + the state of the Region. We should call destroy() instead. + + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::releaseFreeRegions): + (JSC::BlockAllocator::blockFreeingThreadMain): + +2013-04-11 Benjamin Poulain <bpoulain@apple.com> + + Merge CharacterClassTable into CharacterClass + https://bugs.webkit.org/show_bug.cgi?id=114409 + + Reviewed by Darin Adler. + + CharacterClassTable is only a pointer and a boolean. + It is a little overkill to make a separate allocation + for that. + + * create_regex_tables: + * yarr/YarrJIT.cpp: + (JSC::Yarr::YarrGenerator::matchCharacterClass): + * yarr/YarrPattern.cpp: + (JSC::Yarr::CharacterClassConstructor::charClass): + * yarr/YarrPattern.h: + (CharacterClass): + (JSC::Yarr::CharacterClass::CharacterClass): + +2013-04-11 Michael Saboff <msaboff@apple.com> + + Added UNLIKELY() suggested in https://bugs.webkit.org/show_bug.cgi?id=114366 + after checking in the original change. + + Rubber-stamped by Jessie Berlin. + + * dfg/DFGOperations.cpp: + +2013-04-10 Benjamin Poulain <benjamin@webkit.org> + + Unify JSC Parser's error and error message + https://bugs.webkit.org/show_bug.cgi?id=114363 + + Reviewed by Geoffrey Garen. + + The parser kept the error state over two attributes: + error and errorMessage. They were changed in sync, + but had some discrepancy (for example, the error message + was always defined to something). + + This patch unifies the two. There is an error if + if the error message is non-null or if the parsing finished + before the end. + + This also gets rid of the allocation of the error message + when instantiating a parser. + + * parser/Parser.cpp: + (JSC::::Parser): + (JSC::::parseInner): + (JSC::::parseSourceElements): + (JSC::::parseVarDeclaration): + (JSC::::parseConstDeclaration): + (JSC::::parseForStatement): + (JSC::::parseSwitchStatement): + (JSC::::parsePrimaryExpression): + * parser/Parser.h: + (JSC::Parser::updateErrorMessage): + (JSC::Parser::updateErrorWithNameAndMessage): + (JSC::Parser::hasError): + (Parser): + +2013-04-10 Oliver Hunt <oliver@apple.com> + + Set trap is not being called for API objects + https://bugs.webkit.org/show_bug.cgi?id=114403 + + Reviewed by Anders Carlsson. + + Intercept putByIndex on the callback object and add tests + to make sure we don't regress in future. + + * API/JSCallbackObject.h: + (JSCallbackObject): + * API/JSCallbackObjectFunctions.h: + (JSC::::putByIndex): + (JSC): + * API/tests/testapi.c: + (PropertyCatchalls_setProperty): + * API/tests/testapi.js: + +2013-04-10 Benjamin Poulain <bpoulain@apple.com> + + Mass remove all the empty directories + + Rubberstamped by Ryosuke Niwa. + + * qt/api: Removed. + * qt/benchmarks/qscriptengine: Removed. + * qt/benchmarks/qscriptvalue: Removed. + * qt/tests/qscriptengine: Removed. + * qt/tests/qscriptstring: Removed. + * qt/tests/qscriptvalue: Removed. + * qt/tests/qscriptvalueiterator: Removed. + +2013-04-10 Mark Hahnenberg <mhahnenberg@apple.com> + + JSObject::getOwnNonIndexPropertyNames calculates numCacheableSlots incorrectly + https://bugs.webkit.org/show_bug.cgi?id=114235 + + Reviewed by Filip Pizlo. + + If the object doesn't have any properties but the prototype does, we'll assume those prototype properties are + accessible in the base object's backing store, which is bad. + + * runtime/JSObject.cpp: + (JSC::JSObject::getPropertyNames): + (JSC::JSObject::getOwnNonIndexPropertyNames): + * runtime/PropertyNameArray.h: + (JSC::PropertyNameArray::PropertyNameArray): + (JSC::PropertyNameArray::setNumCacheableSlotsForObject): + (JSC::PropertyNameArray::setBaseObject): + (PropertyNameArray): + +2013-04-10 Patrick Gansterer <paroga@webkit.org> + + Remove code duplicates from MacroAssemblerARM + https://bugs.webkit.org/show_bug.cgi?id=104457 + + Reviewed by Oliver Hunt. + + Reuse some existing methods to avoid duplicated code. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::store8): + (JSC::MacroAssemblerARM::store32): + (JSC::MacroAssemblerARM::swap): + (JSC::MacroAssemblerARM::add32): + (JSC::MacroAssemblerARM::sub32): + +2013-04-10 Michael Saboff <msaboff@apple.com> + + DFG: Negative size for new Array() interpreted as large unsigned int + https://bugs.webkit.org/show_bug.cgi?id=114366 + + Reviewed by Oliver Hunt. + + Added new check in operationNewArrayWithSize() for a negative + size. If size is negative throw a "RangeError: Array size is not a + small enough positive integer" exception. + + * dfg/DFGOperations.cpp: + +2013-04-10 peavo@outlook.com <peavo@outlook.com> + + WinCairo build fails to link. + https://bugs.webkit.org/show_bug.cgi?id=114358 + + Reviewed by Brent Fulgham. + + Export the symbol WTF::MD5::checksum(). + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-08 Anders Carlsson <andersca@apple.com> + + Remove unneeded headers from FrameLoader.h + https://bugs.webkit.org/show_bug.cgi?id=114223 + + Reviewed by Geoffrey Garen. + + Update for WTF changes. + + * bytecode/SpeculatedType.h: + * runtime/JSCJSValue.h: + +2013-04-09 Geoffrey Garen <ggaren@apple.com> + + Removed bitrotted TimeoutChecker code + https://bugs.webkit.org/show_bug.cgi?id=114336 + + Reviewed by Alexey Proskuryakov. + + This mechanism hasn't worked for a while. + + MarkL is working on a new version of this feature with a distinct + implementation. + + * API/APIShims.h: + (JSC::APIEntryShim::~APIEntryShim): + (JSC::APIEntryShim::init): + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGGPRInfo.h: + * jit/JIT.cpp: + * jit/JIT.h: + * jit/JITStubs.cpp: + * jit/JITStubs.h: + * jit/JSInterfaceJIT.h: + (JSInterfaceJIT): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + * runtime/JSGlobalObject.cpp: + * runtime/JSONObject.cpp: + (JSC::Stringifier::appendStringifiedValue): + (JSC::Walker::walk): + * runtime/TimeoutChecker.cpp: Removed. + * runtime/TimeoutChecker.h: Removed. + +2013-04-10 Oliver Hunt <oliver@apple.com> + + REGRESSION (r148073): WebKit Nightly r148082 crashes on launch in JSObjectSetPrivate + https://bugs.webkit.org/show_bug.cgi?id=114341 + + Reviewed by Alexey Proskuryakov. + + Make JSObjectSetPrivate use uncheckedToJS as some clients + clear their private data during finalization for some reason. + + * API/JSObjectRef.cpp: + (JSObjectSetPrivate): + +2013-04-09 Oliver Hunt <oliver@apple.com> + + Add liveness tests to JSC API entry points + https://bugs.webkit.org/show_bug.cgi?id=114318 + + Reviewed by Geoffrey Garen. + + Add simple checks for the existence of a method table on any + JSCells passed across the API. This in turn forces a structure + validity test. + + * API/APICast.h: + (toJS): + (toJSForGC): + (unsafeToJS): + * API/JSObjectRef.cpp: + (JSObjectGetPrivate): + +2013-04-09 Oliver Hunt <oliver@apple.com> + + Rollout last patch as it destroyed everything + + * API/APICast.h: + (toJS): + (toJSForGC): + +2013-04-09 Oliver Hunt <oliver@apple.com> + + Add liveness tests to JSC API entry points + https://bugs.webkit.org/show_bug.cgi?id=114318 + + Reviewed by Filip Pizlo. + + Add simple checks for the existence of a method table on any + JSCells passed across the API. This in turn forces a structure + validity test. + + * API/APICast.h: + (toJS): + (toJSForGC): + +2013-04-09 Balazs Kilvady <kilvadyb@homejinni.com> + + LLInt conditional branch compilation fault on MIPS. + https://bugs.webkit.org/show_bug.cgi?id=114264 + + Reviewed by Filip Pizlo. + + Fix conditional branch compilation in LLInt offlineasm. + + * offlineasm/mips.rb: + +2013-04-08 Mark Hahnenberg <mhahnenberg@apple.com> + + JSObject::getOwnNonIndexPropertyNames calculates numCacheableSlots incorrectly + https://bugs.webkit.org/show_bug.cgi?id=114235 + + Reviewed by Geoffrey Garen. + + Due to the way that numCacheableSlots is currently calculated, checking an object's prototype for enumerable + properties causes us not to cache any properties at all. We should only cache properties on the object itself + since we currently don't take advantage of any sort of name caching for properties in the prototype chain. + This fix undoes a ~2% SunSpider regression caused by http://trac.webkit.org/changeset/147570. + + * runtime/JSObject.cpp: + (JSC::JSObject::getOwnNonIndexPropertyNames): + +2013-04-09 Ryosuke Niwa <rniwa@webkit.org> + + Remove yarr.gyp + https://bugs.webkit.org/show_bug.cgi?id=114247 + + Reviewed by Benjamin Poulain. + + * yarr/yarr.gyp: Removed. + +2013-04-08 Ryosuke Niwa <rniwa@webkit.org> + + Remove JavaScriptCore.gyp/gypi + https://bugs.webkit.org/show_bug.cgi?id=114238 + + Reviewed by Benjamin Poulain. + + * JavaScriptCore.gyp: Removed. + * JavaScriptCore.gyp/.gitignore: Removed. + * JavaScriptCore.gypi: Removed. + +2013-04-08 Vahag Vardanyan <vaag@ispras.ru> + + Adds fromCharCode intrinsic support. + https://bugs.webkit.org/show_bug.cgi?id=104807 + + Reviewed by Oliver Hunt. + + Switch to using fromCharCode intrinsic instead of call operation in some cases. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::executeEffects): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleIntrinsic): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileFromCharCode): + (DFG): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * runtime/StringConstructor.cpp: + (JSC::stringFromCharCode): + (JSC): + * runtime/StringConstructor.h: + (JSC): + +2013-04-08 Benjamin Poulain <benjamin@webkit.org> + + Remove HTML Notification + https://bugs.webkit.org/show_bug.cgi?id=114231 + + Reviewed by Ryosuke Niwa. + + * Configurations/FeatureDefines.xcconfig: + +2013-04-05 Roger Fong <roger_fong@apple.com> + + Build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-08 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to inline string equality comparisons + https://bugs.webkit.org/show_bug.cgi?id=114224 + + Reviewed by Oliver Hunt. + + Inline 8-bit string equality, go to slow path for 16-bit strings. 2x speed-up for string equality + comparisons on 8-bit strings. 20-50% speed-up on JSRegress/HashMap tests. 30% speed-up on + string-fasta. 2% speed-up on SunSpider overall. Some small speed-ups elsewhere. + + This is a gnarly change but we have loads of test coverage already between the HashMap tests and + preexisting DFG string equality tests (which appear to have been designed to test OSR exits, but + also give us good overall coverage on string equality behavior). + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): + (JSC::DFG::SpeculativeJIT::compare): + (JSC::DFG::SpeculativeJIT::compileStrictEq): + (JSC::DFG::SpeculativeJIT::compileStringEquality): + (DFG): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + +2013-04-08 Geoffrey Garen <ggaren@apple.com> + + Stop #include-ing all of JavaScriptCore in every DOM-related file + https://bugs.webkit.org/show_bug.cgi?id=114220 + + Reviewed by Sam Weinig. + + I separated WeakInlines.h from Weak.h so WebCore data types that need + to declare a Weak<T> data member don't have to #include all of the + infrastructure for accessing that data member. + + This also required separating Weak<T> from PassWeak<T> by removing the + WeakImplAccessor class template and pushing code down into its subclasses. + + * API/JSWeakObjectMapRefPrivate.cpp: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/UnlinkedCodeBlock.h: + * heap/PassWeak.h: + (JSC): + (PassWeak): + (JSC::::PassWeak): + (JSC::::operator): + (JSC::::get): + * heap/SlotVisitorInlines.h: + * heap/Weak.h: + (JSC): + (Weak): + * heap/WeakInlines.h: Copied from Source/JavaScriptCore/heap/Weak.h. + (JSC): + (JSC::::Weak): + (JSC::::operator): + (JSC::::get): + (JSC::::was): + (JSC::weakClear): + * jit/JITThunks.h: + * runtime/RegExpCache.h: + * runtime/Structure.h: + * runtime/WeakGCMap.h: + +2013-04-05 Roger Fong <roger_fong@apple.com> + + Windows build fix fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + +2013-04-05 Roger Fong <roger_fong@apple.com> + + Windows build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-08 Oliver Hunt <oliver@apple.com> + + Make resolve more robust in the face of lookup misses + https://bugs.webkit.org/show_bug.cgi?id=114211 + + Reviewed by Filip Pizlo. + + This simply short circuits the resolve operations in the + event that we don't find a path to a property. There's no + repro case for this happening unfortunately. + + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + +2013-04-08 Oliver Hunt <oliver@apple.com> + + Build fix. + + * assembler/ARMv7Assembler.h: + (ARMv7Assembler): + +2013-04-08 Justin Haygood <jhaygood@reaktix.com> + + Allow KeywordLookupGenerator.py to work on Windows with Windows style line endings + https://bugs.webkit.org/show_bug.cgi?id=63234 + + Reviewed by Oliver Hunt. + + * KeywordLookupGenerator.py: + (parseKeywords): + +2013-04-08 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r146669): Assertion hit in JSC::DFG::SpeculativeJIT::fillSpeculateCell() running webgl tests + https://bugs.webkit.org/show_bug.cgi?id=114129 + <rdar://problem/13594898> + + Reviewed by Darin Adler. + + The check to see if we need a cell check when simplifying a GetById or PutById needs to be hoisted to + above where we abstractly execute the instruction, since after we abstracting execute it, it will + seem like it no longer needs the cell check. + + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + +2013-04-07 Oliver Hunt <oliver@apple.com> + + Add bounds checking for WTF::Vector::operator[] + https://bugs.webkit.org/show_bug.cgi?id=89600 + + Reviewed by Filip Pizlo. + + Make a few JSC classes opt-out of release mode bounds checking. + + * assembler/AssemblerBuffer.h: + (AssemblerBuffer): + * assembler/AssemblerBufferWithConstantPool.h: + (AssemblerBufferWithConstantPool): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::bytecodeOffset): + (JSC): + (JSC::replaceExistingEntries): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::bytecodeOffsetForCallAtIndex): + (JSC::CodeBlock::callReturnIndexVector): + (JSC::CodeBlock::codeOrigins): + (RareData): + * bytecode/UnlinkedCodeBlock.h: + (JSC::UnlinkedEvalCodeBlock::adoptVariables): + (UnlinkedEvalCodeBlock): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::emitNewArray): + (JSC::BytecodeGenerator::emitCall): + (JSC::BytecodeGenerator::emitConstruct): + * bytecompiler/BytecodeGenerator.h: + (CallArguments): + (JSC::BytecodeGenerator::instructions): + (BytecodeGenerator): + * bytecompiler/StaticPropertyAnalysis.h: + (JSC::StaticPropertyAnalysis::create): + (JSC::StaticPropertyAnalysis::StaticPropertyAnalysis): + (StaticPropertyAnalysis): + * bytecompiler/StaticPropertyAnalyzer.h: + (StaticPropertyAnalyzer): + (JSC::StaticPropertyAnalyzer::StaticPropertyAnalyzer): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + * parser/ASTBuilder.h: + (ASTBuilder): + * runtime/ArgList.h: + (MarkedArgumentBuffer): + * runtime/ArrayPrototype.cpp: + (JSC::arrayProtoFuncSort): + +2013-04-07 Benjamin Poulain <benjamin@webkit.org> + + Use Vector::reserveInitialCapacity() when possible in JavaScriptCore runtime + https://bugs.webkit.org/show_bug.cgi?id=114111 + + Reviewed by Andreas Kling. + + Almost all the code was already using Vector::reserveInitialCapacity() + and Vector::uncheckedAppend(). Fix the remaining parts. + + * runtime/ArgList.h: + (MarkedArgumentBuffer): The type VectorType is unused. + + * runtime/ArrayPrototype.cpp: + (JSC::arrayProtoFuncSort): + Move the variable closer to where it is needed. + + * runtime/JSArray.cpp: + (JSC::JSArray::setLengthWithArrayStorage): + * runtime/JSObject.cpp: + (JSC::JSObject::getOwnPropertyNames): + +2013-04-07 Patrick Gansterer <paroga@webkit.org> + + Remove references to Skia and V8 from CMake files + https://bugs.webkit.org/show_bug.cgi?id=114130 + + Reviewed by Geoffrey Garen. + + * shell/PlatformBlackBerry.cmake: + +2013-04-07 David Kilzer <ddkilzer@apple.com> + + Remove the rest of SVG_DOM_OBJC_BINDINGS + <http://webkit.org/b/114112> + + Reviewed by Geoffrey Garen. + + * Configurations/FeatureDefines.xcconfig: + - Remove ENABLE_SVG_DOM_OBJC_BINDINGS macro. + +2013-04-07 Oliver Hunt <oliver@apple.com> + + Inspector should display information about non-object exceptions + https://bugs.webkit.org/show_bug.cgi?id=114123 + + Reviewed by Adele Peterson. + + Make sure we store the right stack information, even when throwing + a primitive. + + * interpreter/CallFrame.h: + (JSC::ExecState::clearSupplementaryExceptionInfo): + (ExecState): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::addStackTraceIfNecessary): + (JSC::Interpreter::throwException): + +2013-04-06 Oliver Hunt <oliver@apple.com> + + Unify the many and varied stack trace mechanisms, and make the result sane. + https://bugs.webkit.org/show_bug.cgi?id=114072 + + Reviewed by Filip Pizlo. + + Makes JSC::StackFrame record the bytecode offset and other necessary data + rather than requiring us to perform eager evaluation of the line number, etc. + Then remove most of the users of retrieveLastCaller, as most of them were + using it to create a stack trace in a fairly incomplete and inefficient way. + + StackFrame now also has a couple of helpers to get the line and column info. + + * API/JSContextRef.cpp: + (JSContextCreateBacktrace): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitDebugHook): + * interpreter/Interpreter.cpp: + (JSC): + (JSC::Interpreter::dumpRegisters): + (JSC::Interpreter::unwindCallFrame): + (JSC::getBytecodeOffsetForCallFrame): + (JSC::getCallerInfo): + (JSC::StackFrame::line): + (JSC::StackFrame::column): + (JSC::StackFrame::expressionInfo): + (JSC::StackFrame::toString): + (JSC::Interpreter::getStackTrace): + (JSC::Interpreter::addStackTraceIfNecessary): + (JSC::Interpreter::retrieveCallerFromVMCode): + * interpreter/Interpreter.h: + (StackFrame): + (Interpreter): + * runtime/Error.cpp: + (JSC::throwError): + * runtime/JSGlobalData.h: + (JSC): + (JSGlobalData): + * runtime/JSGlobalObject.cpp: + (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope): + +2013-04-06 Geoffrey Garen <ggaren@apple.com> + + Removed v8 bindings hooks from IDL files + https://bugs.webkit.org/show_bug.cgi?id=114091 + + Reviewed by Anders Carlsson and Sam Weinig. + + * heap/HeapStatistics.h: + +2013-04-03 Roger Fong <roger_fong@apple.com> + + Windows VS2010 build fix. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-06 Zan Dobersek <zdobersek@igalia.com> + + Remove the remaining PLATFORM(CHROMIUM) guard in JavaScriptCore + https://bugs.webkit.org/show_bug.cgi?id=114082 + + Reviewed by Ryosuke Niwa. + + * runtime/JSExportMacros.h: Remove the remaining PLATFORM(CHROMIUM) guard. + +2013-04-06 Ed Bartosh <bartosh@gmail.com> + + --minimal build fails with error: control reaches end of non-void function + https://bugs.webkit.org/show_bug.cgi?id=114085 + + Reviewed by Oliver Hunt. + + * interpreter/Interpreter.cpp: return 0 if JIT is not enabled + (JSC::getBytecodeOffsetForCallFrame): + +2013-04-06 Geoffrey Garen <ggaren@apple.com> + + Try to fix the Windows build. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + Added back a symbol that is exported. + +2013-04-06 Geoffrey Garen <ggaren@apple.com> + + Try to fix the Windows build. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + Removed symbols that aren't exported. + +2013-04-06 Geoffrey Garen <ggaren@apple.com> + + Rolled out 147820 and 147818 because they caused plugins tests to ASSERT + https://bugs.webkit.org/show_bug.cgi?id=114094 + + Reviewed by Anders Carlsson. + + * API/JSContextRef.cpp: + (JSContextCreateBacktrace): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitDebugHook): + * interpreter/Interpreter.cpp: + (JSC): + (JSC::Interpreter::dumpRegisters): + (JSC::Interpreter::unwindCallFrame): + (JSC::getLineNumberForCallFrame): + (JSC::getCallerInfo): + (JSC::Interpreter::getStackTrace): + (JSC::Interpreter::addStackTraceIfNecessary): + (JSC::Interpreter::retrieveCallerFromVMCode): + * interpreter/Interpreter.h: + (StackFrame): + (JSC::StackFrame::toString): + (JSC::StackFrame::friendlyLineNumber): + (Interpreter): + * runtime/Error.cpp: + (JSC::throwError): + * runtime/JSGlobalData.h: + (JSC): + (JSGlobalData): + * runtime/JSGlobalObject.cpp: + (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope): + +2013-04-06 Patrick Gansterer <paroga@webkit.org> + + Unreviewed build fix after r146932. + + * profiler/ProfilerDatabase.cpp: + (Profiler): + +2013-04-06 Patrick Gansterer <paroga@webkit.org> + + Do not call getenv() on Windows CE where it does not exist. + + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + +2013-04-05 Benjamin Poulain <benjamin@webkit.org> + + Second attempt to fix the Windows bot + + Unreviewed. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-05 Benjamin Poulain <bpoulain@apple.com> + + Attempt to fix the Windows bot + + Unreviewed. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + r147825 removed the symbol for nullptr_t. Add it back. + +2013-04-02 Roger Fong <roger_fong@apple.com> + + Build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-05 Oliver Hunt <oliver@apple.com> + + Build fix. + + * interpreter/Interpreter.cpp: + (JSC::getBytecodeOffsetForCallFrame): + +2013-04-05 Oliver Hunt <oliver@apple.com> + + Unify the many and varied stack trace mechanisms, and make the result sane. + https://bugs.webkit.org/show_bug.cgi?id=114072 + + Reviewed by Filip Pizlo. + + Makes JSC::StackFrame record the bytecode offset and other necessary data + rather than requiring us to perform eager evaluation of the line number, etc. + Then remove most of the users of retrieveLastCaller, as most of them were + using it to create a stack trace in a fairly incomplete and inefficient way. + + StackFrame now also has a couple of helpers to get the line and column info. + + * API/JSContextRef.cpp: + (JSContextCreateBacktrace): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitDebugHook): + * interpreter/Interpreter.cpp: + (JSC): + (JSC::Interpreter::dumpRegisters): + (JSC::Interpreter::unwindCallFrame): + (JSC::getBytecodeOffsetForCallFrame): + (JSC::getCallerInfo): + (JSC::StackFrame::line): + (JSC::StackFrame::column): + (JSC::StackFrame::expressionInfo): + (JSC::StackFrame::toString): + (JSC::Interpreter::getStackTrace): + (JSC::Interpreter::addStackTraceIfNecessary): + (JSC::Interpreter::retrieveCallerFromVMCode): + * interpreter/Interpreter.h: + (StackFrame): + (Interpreter): + * runtime/Error.cpp: + (JSC::throwError): + * runtime/JSGlobalData.h: + (JSC): + (JSGlobalData): + * runtime/JSGlobalObject.cpp: + (JSC::DynamicGlobalObjectScope::DynamicGlobalObjectScope): + +2013-04-05 Mark Hahnenberg <mhahnenberg@apple.com> + + tryCacheGetByID sets StructureStubInfo accessType to an incorrect value + https://bugs.webkit.org/show_bug.cgi?id=114068 + + Reviewed by Geoffrey Garen. + + In the case where we have a non-Value cacheable property, we set the StructureStubInfo accessType to + get_by_id_self, but then we don't patch self and instead patch in a get_by_id_self_fail. This leads to + incorrect profiling data so when the DFG compiles the function, it uses a GetByOffset rather than a GetById, + which leads to loading a GetterSetter directly out of an object. + + * jit/JITStubs.cpp: + (JSC::tryCacheGetByID): + (JSC::DEFINE_STUB_FUNCTION): + +2013-04-05 Filip Pizlo <fpizlo@apple.com> + + If CallFrame::trueCallFrame() knows that it's about to read garbage instead of a valid CodeOrigin/InlineCallFrame, then it should give up and return 0 and all callers should be robust against this + https://bugs.webkit.org/show_bug.cgi?id=114062 + + Reviewed by Oliver Hunt. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::canGetCodeOrigin): + (CodeBlock): + * interpreter/CallFrame.cpp: + (JSC::CallFrame::trueCallFrame): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::getStackTrace): + +2013-04-05 Geoffrey Garen <ggaren@apple.com> + + Made USE(JSC) unconditional + https://bugs.webkit.org/show_bug.cgi?id=114058 + + Reviewed by Anders Carlsson. + + * config.h: + +2013-04-05 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, rolling out http://trac.webkit.org/changeset/147729 + + It's causing a bunch of breakage on some more strict compilers: + <inline asm>:1267:2: error: ambiguous instructions require an explicit suffix (could be 'ficomps', or 'ficompl') + + * offlineasm/x86.rb: + +2013-04-05 Roger Fong <roger_fong@apple.com> + + More VS2010 solution makefile fixes. + <rdar://problem/13588964> + + * JavaScriptCore.vcxproj/JavaScriptCore.make: + +2013-04-05 Allan Sandfeld Jensen <allan.jensen@digia.com> + + LLint should be able to use x87 instead of SSE for floating pointer + + https://bugs.webkit.org/show_bug.cgi?id=112239 + + Reviewed by Filip Pizlo. + + Implements LLInt floating point operations in x87, to ensure we support + x86 without SSE2. + + X86 (except 64bit) now defaults to using x87 instructions in order to + support all 32bit x86 back to i686. The implementation uses the fucomi + instruction from i686 which sets the new minimum. + + * offlineasm/x86.rb: + +2013-04-04 Christophe Dumez <ch.dumez@sisa.samsung.com> + + Unreviewed EFL build fix. + + We had undefined reference to `JSC::CodeOrigin::maximumBytecodeIndex'. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::findClosureCallForReturnPC): + (JSC::CodeBlock::bytecodeOffset): + +2013-04-04 Geoffrey Garen <ggaren@apple.com> + + Stop pretending that statements return a value + https://bugs.webkit.org/show_bug.cgi?id=113969 + + Reviewed by Oliver Hunt. + + Expressions have an intrinsic value, which they return to their parent + in the AST. + + Statements just execute for effect in sequence. + + This patch moves emitBytecode into the ExpressionNode and StatementNode + subclasses, and changes the SatementNode subclass to return void. This + eliminates some cruft where we used to return 0, or try to save a bogus + register and return it, as if a statement had a consuming parent in the + AST. + + * bytecompiler/BytecodeGenerator.h: + (JSC::BytecodeGenerator::emitNode): + (BytecodeGenerator): + (JSC::BytecodeGenerator::emitNodeInConditionContext): + * bytecompiler/NodesCodegen.cpp: + (JSC::ConstStatementNode::emitBytecode): + (JSC::BlockNode::emitBytecode): + (JSC::EmptyStatementNode::emitBytecode): + (JSC::DebuggerStatementNode::emitBytecode): + (JSC::ExprStatementNode::emitBytecode): + (JSC::VarStatementNode::emitBytecode): + (JSC::IfNode::emitBytecode): + (JSC::IfElseNode::emitBytecode): + (JSC::DoWhileNode::emitBytecode): + (JSC::WhileNode::emitBytecode): + (JSC::ForNode::emitBytecode): + (JSC::ForInNode::emitBytecode): + (JSC::ContinueNode::emitBytecode): + (JSC::BreakNode::emitBytecode): + (JSC::ReturnNode::emitBytecode): + (JSC::WithNode::emitBytecode): + (JSC::CaseClauseNode::emitBytecode): + (JSC::CaseBlockNode::emitBytecodeForBlock): + (JSC::SwitchNode::emitBytecode): + (JSC::LabelNode::emitBytecode): + (JSC::ThrowNode::emitBytecode): + (JSC::TryNode::emitBytecode): + (JSC::ScopeNode::emitStatementsBytecode): + (JSC::ProgramNode::emitBytecode): + (JSC::EvalNode::emitBytecode): + (JSC::FunctionBodyNode::emitBytecode): + (JSC::FuncDeclNode::emitBytecode): + * parser/NodeConstructors.h: + (JSC::PropertyListNode::PropertyListNode): + (JSC::ArgumentListNode::ArgumentListNode): + * parser/Nodes.h: + (Node): + (ExpressionNode): + (StatementNode): + (ConstStatementNode): + (BlockNode): + (EmptyStatementNode): + (DebuggerStatementNode): + (ExprStatementNode): + (VarStatementNode): + (IfNode): + (IfElseNode): + (DoWhileNode): + (WhileNode): + (ForNode): + (ForInNode): + (ContinueNode): + (BreakNode): + (ReturnNode): + (WithNode): + (LabelNode): + (ThrowNode): + (TryNode): + (ProgramNode): + (EvalNode): + (FunctionBodyNode): + (FuncDeclNode): + (CaseBlockNode): + (SwitchNode): + +2013-04-04 Oliver Hunt <oliver@apple.com> + + Exception stack unwinding doesn't handle inline callframes correctly + https://bugs.webkit.org/show_bug.cgi?id=113952 + + Reviewed by Geoffrey Garen. + + The basic problem here is that the exception stack unwinding was + attempting to be "clever" and avoid doing a correct stack walk + as it "knew" inline callframes couldn't have exception handlers. + + This used to be safe as the exception handling machinery was + designed to fail gently and just claim that no handler existed. + This was "safe" and even "correct" inasmuch as we currently + don't run any code with exception handlers through the dfg. + + This patch fixes the logic by simply making everything uniformly + use the safe stack walking machinery, and making the correct + boundary checks occur everywhere that they should. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::findClosureCallForReturnPC): + (JSC::CodeBlock::bytecodeOffset): + * interpreter/Interpreter.cpp: + (JSC): + (JSC::Interpreter::dumpRegisters): + (JSC::Interpreter::unwindCallFrame): + (JSC::getCallerInfo): + (JSC::Interpreter::getStackTrace): + (JSC::Interpreter::retrieveCallerFromVMCode): + +2013-04-04 Geoffrey Garen <ggaren@apple.com> + + Removed a defunct comment + https://bugs.webkit.org/show_bug.cgi?id=113948 + + Reviewed by Oliver Hunt. + + This is also a convenient way to test the EWS. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC): + +2013-04-04 Martin Robinson <mrobinson@igalia.com> + + [GTK] Remove the gyp build + https://bugs.webkit.org/show_bug.cgi?id=113942 + + Reviewed by Gustavo Noronha Silva. + + * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Removed. + * JavaScriptCore.gyp/redirect-stdout.sh: Removed. + +2013-04-04 Geoffrey Garen <ggaren@apple.com> + + Simplified bytecode generation by merging prefix and postfix nodes + https://bugs.webkit.org/show_bug.cgi?id=113925 + + Reviewed by Filip Pizlo. + + PostfixNode now inherits from PrefixNode, so when we detect that we're + in a context where postifx and prefix are equivalent, PostFixNode can + just call through to PrefixNode codegen, instead of duplicating the + logic. + + * bytecompiler/NodesCodegen.cpp: + (JSC::PostfixNode::emitResolve): + (JSC::PostfixNode::emitBracket): + (JSC::PostfixNode::emitDot): + * parser/NodeConstructors.h: + (JSC::PostfixNode::PostfixNode): + * parser/Nodes.h: + (JSC): + (PrefixNode): + (PostfixNode): + +2013-04-04 Andras Becsi <andras.becsi@digia.com> + + Fix the build with GCC 4.8 + https://bugs.webkit.org/show_bug.cgi?id=113147 + + Reviewed by Allan Sandfeld Jensen. + + Initialize JSObject* exception to suppress warnings that make + the build fail because of -Werror=maybe-uninitialized. + + * runtime/Executable.cpp: + (JSC::FunctionExecutable::compileForCallInternal): + (JSC::FunctionExecutable::compileForConstructInternal): + +2013-04-02 Mark Hahnenberg <mhahnenberg@apple.com> + + get_by_pname can become confused when iterating over objects with static properties + https://bugs.webkit.org/show_bug.cgi?id=113831 + + Reviewed by Geoffrey Garen. + + get_by_pname doesn't take static properties into account when using a JSPropertyNameIterator to directly + access an object's backing store. One way to fix this is to not cache any properties when iterating over + objects with static properties. This patch fixes the bug that was originally reported on swisscom.ch. + + * runtime/JSObject.cpp: + (JSC::JSObject::getOwnNonIndexPropertyNames): + * runtime/JSPropertyNameIterator.cpp: + (JSC::JSPropertyNameIterator::create): + * runtime/PropertyNameArray.h: + (JSC::PropertyNameArray::PropertyNameArray): + (JSC::PropertyNameArray::numCacheableSlots): + (JSC::PropertyNameArray::setNumCacheableSlots): + (PropertyNameArray): + +2013-04-02 Geoffrey Garen <ggaren@apple.com> + + DFG should compile a little sooner + https://bugs.webkit.org/show_bug.cgi?id=113835 + + Unreviewed. + + Rolled out r147511 because it was based on incorrect performance + measurement. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::optimizationThresholdScalingFactor): + +2013-04-02 Geoffrey Garen <ggaren@apple.com> + + DFG should compile a little sooner + https://bugs.webkit.org/show_bug.cgi?id=113835 + + Reviewed by Michael Saboff. + + 2% speedup on SunSpider. + + 2% speedup on JSRegress. + + Neutral on Octane, v8, and Kraken. + + The worst-hit single sub-test is kraken-stanford-crypto-ccm.js, which gets + 18% slower. Since Kraken is neutral overall in its preferred mean, I + think that's OK for now. + + (Our array indexing speculation fails pathologically on + kraken-stanford-crypto-ccm.js. Compiling sooner is a regression because + it triggers those failures sooner. I'm going to file some follow-up bugs + explaining how to fix our speculations on this sub-test, at which point + compiling earlier should become a slight speedup on Kraken overall.) + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::optimizationThresholdScalingFactor): I experimented + with a few different options, including reducing the coefficient 'a'. + A simple linear reduction on instruction count worked best. + +2013-04-01 Benjamin Poulain <benjamin@webkit.org> + + Use Vector::reserveInitialCapacity and Vector::uncheckedAppend for JSC's APIs + https://bugs.webkit.org/show_bug.cgi?id=113651 + + Reviewed by Andreas Kling. + + This removes a bunch of branches on initialization and when + filling the vector. + + * API/JSCallbackConstructor.cpp: + (JSC::constructJSCallback): + * API/JSCallbackFunction.cpp: + (JSC::JSCallbackFunction::call): + * API/JSCallbackObjectFunctions.h: + (JSC::::construct): + (JSC::::call): + * API/JSObjectRef.cpp: + (JSObjectCopyPropertyNames): + +2013-04-01 Mark Hahnenberg <mhahnenberg@apple.com> + + Fixing borked VS 2010 project file + + Unreviewed bot greening. + + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + +2013-04-01 Mark Hahnenberg <mhahnenberg@apple.com> + + One more Windows build fix + + Unreviewed. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-04-01 Mark Hahnenberg <mhahnenberg@apple.com> + + More build fallout fixes. + + Unreviewed build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Add new export symbols. + * heap/SuperRegion.cpp: Windows didn't like "LLU". + +2013-04-01 Mark Hahnenberg <mhahnenberg@apple.com> + + r147324 broke the world + https://bugs.webkit.org/show_bug.cgi?id=113704 + + Unreviewed build fix. + + Remove a bunch of unused variables and use the correctly sized types for 32-bit platforms. + + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::BlockAllocator): + * heap/BlockAllocator.h: + (BlockAllocator): + * heap/Heap.cpp: + (JSC::Heap::Heap): + * heap/SuperRegion.cpp: + (JSC::SuperRegion::SuperRegion): + * heap/SuperRegion.h: + (SuperRegion): + +2013-04-01 Mark Hahnenberg <mhahnenberg@apple.com> + + 32-bit Windows build fix + + Unreviewed build fix. + + * heap/SuperRegion.cpp: + * heap/SuperRegion.h: Use uint64_t instead of size_t. + (SuperRegion): + +2013-04-01 Mark Hahnenberg <mhahnenberg@apple.com> + + EFL build fix + + Unreviewed build fix. + + * CMakeLists.txt: + +2013-03-31 Mark Hahnenberg <mhahnenberg@apple.com> + + Regions should be allocated from the same contiguous segment of virtual memory + https://bugs.webkit.org/show_bug.cgi?id=113662 + + Reviewed by Filip Pizlo. + + Instead of letting the OS spread our Regions all over the place, we should allocate them all within + some range of each other. This change will open the door to some other optimizations, e.g. doing simple + range checks for our write barriers and compressing JSCell pointers to 32-bits. + + Added new SuperRegion class that encapsulates allocating Regions from a contiguous reserved chunk of + virtual address space. It functions very similarly to the FixedVMPoolExecutableAllocator class used by the JIT. + + Also added two new subclasses of Region, NormalRegion and ExcessRegion. + + NormalRegion is the type of Region that is normally allocated when there is available space remaining + in the SuperRegion. If we ever run out of space in the SuperRegion, we fall back to allocating + ExcessRegions, which are identical to how Regions have behaved up until now, i.e. they contain a + PageAllocationAligned. + + We only use the SuperRegion (and NormalRegions) on 64-bit systems, since it doesn't make sense to reserve the + entire 4 GB address space on 32-bit systems just for the JS heap. + + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::BlockAllocator): + * heap/BlockAllocator.h: + (JSC): + (BlockAllocator): + (JSC::BlockAllocator::allocate): + (JSC::BlockAllocator::allocateCustomSize): + (JSC::BlockAllocator::deallocateCustomSize): + * heap/Heap.cpp: + (JSC::Heap::Heap): + (JSC): + (JSC::Heap::didExceedFixedHeapSizeLimit): + * heap/Heap.h: + (Heap): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::create): + * heap/Region.h: + (Region): + (JSC): + (NormalRegion): + (JSC::NormalRegion::base): + (JSC::NormalRegion::size): + (ExcessRegion): + (JSC::ExcessRegion::base): + (JSC::ExcessRegion::size): + (JSC::NormalRegion::NormalRegion): + (JSC::NormalRegion::tryCreate): + (JSC::NormalRegion::tryCreateCustomSize): + (JSC::NormalRegion::reset): + (JSC::ExcessRegion::ExcessRegion): + (JSC::ExcessRegion::~ExcessRegion): + (JSC::ExcessRegion::create): + (JSC::ExcessRegion::createCustomSize): + (JSC::ExcessRegion::reset): + (JSC::Region::Region): + (JSC::Region::initializeBlockList): + (JSC::Region::create): + (JSC::Region::createCustomSize): + (JSC::Region::~Region): + (JSC::Region::destroy): + (JSC::Region::reset): + (JSC::Region::deallocate): + (JSC::Region::base): + (JSC::Region::size): + * heap/SuperRegion.cpp: Added. + (JSC): + (JSC::SuperRegion::SuperRegion): + (JSC::SuperRegion::getAlignedBase): + (JSC::SuperRegion::allocateNewSpace): + (JSC::SuperRegion::notifyNeedPage): + (JSC::SuperRegion::notifyPageIsFree): + * heap/SuperRegion.h: Added. + (JSC): + (SuperRegion): + +2013-04-01 Benjamin Poulain <benjamin@webkit.org> + + Remove an unused variable from the ARMv7 Assembler + https://bugs.webkit.org/show_bug.cgi?id=113653 + + Reviewed by Andreas Kling. + + * assembler/ARMv7Assembler.h: + (ARMv7Assembler): + +2013-03-31 Adam Barth <abarth@webkit.org> + + [Chromium] Yarr should build using a separate GYP file from JavaScriptCore + https://bugs.webkit.org/show_bug.cgi?id=113652 + + Reviewed by Nico Weber. + + This patch moves JavaScriptCore.gyp to yarr.gyp because Chromium only + uses this GYP file to build yarr. + + * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: + * JavaScriptCore.gypi: + * yarr/yarr.gyp: Renamed from Source/JavaScriptCore/JavaScriptCore.gyp/JavaScriptCore.gyp. + +2013-03-31 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, fix a comment. While thinking about TBAA for array accesses, + I realized that we have to be super careful about aliasing of typed arrays. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getByValLoadElimination): + +2013-03-30 Mark Hahnenberg <mhahnenberg@apple.com> + + Move Region into its own header + https://bugs.webkit.org/show_bug.cgi?id=113617 + + Reviewed by Geoffrey Garen. + + BlockAllocator.h is getting a little crowded. We should move the Region class into its own + header, since it's pretty independent from the BlockAllocator. + + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + * JavaScriptCore.xcodeproj/project.pbxproj: + * heap/BlockAllocator.h: + (JSC): + * heap/Region.h: Added. + (JSC): + (DeadBlock): + (JSC::DeadBlock::DeadBlock): + (Region): + (JSC::Region::blockSize): + (JSC::Region::isFull): + (JSC::Region::isEmpty): + (JSC::Region::isCustomSize): + (JSC::Region::create): + (JSC::Region::createCustomSize): + (JSC::Region::Region): + (JSC::Region::~Region): + (JSC::Region::reset): + (JSC::Region::allocate): + (JSC::Region::deallocate): + +2013-03-29 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Remove -[JSManagedValue managedValueWithValue:owner:] + https://bugs.webkit.org/show_bug.cgi?id=113602 + + Reviewed by Geoffrey Garen. + + Since we put the primary way of keeping track of external object graphs (i.e. "managed" references) + in JSVirtualMachine, there is some overlap in the functionality of that interface and JSManagedValue. + Specifically, we no longer need the methods that include an owner, since ownership is now tracked + by JSVirtualMachine. These JSManagedValues will become weak pointers unless they are used + with [JSVirtualMachine addManagedReference:withOwner:], in which case their lifetime is tied to that + of their owner. + + * API/JSManagedValue.h: + * API/JSManagedValue.mm: + (-[JSManagedValue init]): + (-[JSManagedValue initWithValue:]): + (JSManagedValueHandleOwner::isReachableFromOpaqueRoots): + * API/JSVirtualMachine.mm: + (getInternalObjcObject): + * API/tests/testapi.mm: + (-[TextXYZ setOnclick:]): + (-[TextXYZ dealloc]): + +2013-03-29 Geoffrey Garen <ggaren@apple.com> + + Simplified bytecode generation by unforking "condition context" codegen + https://bugs.webkit.org/show_bug.cgi?id=113554 + + Reviewed by Mark Hahnenberg. + + Now, a node that establishes a condition context can always ask its child + nodes to generate into that context. + + This has a few advantages: + + (*) Removes a bunch of code; + + (*) Optimizes a few missed cases like "if (!(x < 2))", "if (!!x)", and + "if (!x || !y)"; + + (*) Paves the way to removing more opcodes. + + * bytecode/Opcode.h: + (JSC): Separated out the branching opcodes for clarity. + * bytecompiler/NodesCodegen.cpp: + (JSC::ExpressionNode::emitBytecodeInConditionContext): All expressions + can be emitted in a condition context now -- the default behavior is + to branch based on the expression's value. + + (JSC::LogicalNotNode::emitBytecodeInConditionContext): + (JSC::LogicalOpNode::emitBytecodeInConditionContext): + (JSC::ConditionalNode::emitBytecode): + (JSC::IfNode::emitBytecode): + (JSC::IfElseNode::emitBytecode): + (JSC::DoWhileNode::emitBytecode): + (JSC::WhileNode::emitBytecode): + (JSC::ForNode::emitBytecode): + * parser/Nodes.h: + (JSC::ExpressionNode::isSubtract): + (ExpressionNode): + (LogicalNotNode): + (LogicalOpNode): Removed lots of code for handling expressions + that couldn't generate into a condition context because all expressions + can now. + +2013-03-28 Geoffrey Garen <ggaren@apple.com> + + Simplified the bytecode by removing op_loop and op_loop_if_* + https://bugs.webkit.org/show_bug.cgi?id=113548 + + Reviewed by Filip Pizlo. + + Regular jumps will suffice. + + These opcodes are identical to branches, except they also do timeout + checking. That style of timeout checking has been broken for a long + time, and when we add back timeout checking, it won't use these opcodes. + + * JavaScriptCore.order: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecode): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/PreciseJumpTargets.cpp: + (JSC::computePreciseJumpTargets): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitJump): + (JSC::BytecodeGenerator::emitJumpIfTrue): + (JSC::BytecodeGenerator::emitJumpIfFalse): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + (JIT): + (JSC): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2013-03-28 Geoffrey Garen <ggaren@apple.com> + + Simplified the bytecode by removing op_jmp_scopes + https://bugs.webkit.org/show_bug.cgi?id=113545 + + Reviewed by Filip Pizlo. + + We already have op_pop_scope and op_jmp, so we don't need op_jmp_scopes. + Using op_jmp_scopes was also adding a "jump to self" to codegen for + return statements, which was pretty silly. + + * JavaScriptCore.order: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecode): + * bytecode/Opcode.h: + (JSC::padOpcodeName): + * bytecode/PreciseJumpTargets.cpp: + (JSC::computePreciseJumpTargets): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitComplexPopScopes): + (JSC::BytecodeGenerator::emitPopScopes): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::ContinueNode::emitBytecode): + (JSC::BreakNode::emitBytecode): + (JSC::ReturnNode::emitBytecode): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + * jit/JIT.h: + * jit/JITOpcodes.cpp: + * jit/JITOpcodes32_64.cpp: + * jit/JITStubs.cpp: + * jit/JITStubs.h: + * llint/LLIntSlowPaths.cpp: + * llint/LLIntSlowPaths.h: + * llint/LowLevelInterpreter.asm: + +2013-03-28 Mark Hahnenberg <mhahnenberg@apple.com> + + Safari hangs during test262 run in CodeCache::pruneSlowCase + https://bugs.webkit.org/show_bug.cgi?id=113469 + + Reviewed by Geoffrey Garen. + + We can end up hanging for quite some time if we add a lot of small keys to the CodeCache. + By the time we get around to pruning the cache, we have a potentially tens or hundreds of + thousands of small entries, which can cause a noticeable hang when pruning them. + + To fix this issue we added a hard cap to the number of entries in the cache because we + could potentially have to remove every element in the map. + + * runtime/CodeCache.cpp: + (JSC::CodeCacheMap::pruneSlowCase): We need to prune until we're both under the hard cap and the + capacity in bytes. + * runtime/CodeCache.h: + (CodeCacheMap): + (JSC::CodeCacheMap::numberOfEntries): Convenience accessor function to the number of entries in + the map that does the cast to size_t of m_map.size() for us. + (JSC::CodeCacheMap::canPruneQuickly): Checks that the total number is under the hard cap. We put this + check inside a function to more accurately describe why we're doing the check and to abstract out + the actual calculation in case we want to coalesce calls to pruneSlowCase in the future. + (JSC::CodeCacheMap::prune): Check the number of entries against our hard cap. If it's greater than + the cap then we need to drop down to pruneSlowCase. + +2013-03-28 Zan Dobersek <zdobersek@igalia.com> + + Unreviewed build fix for the EFL and GTK ports. + + * runtime/CodeCache.cpp: + (JSC::CodeCacheMap::pruneSlowCase): Pass a 0 casted to the int64_t type instead of 0LL + to the std::max call so the arguments' types match. + +2013-03-27 Geoffrey Garen <ggaren@apple.com> + + Unreviewed build fix: Removed a dead field. + + Pointed out by Mark Lam. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::ByteCodeParser): + (ByteCodeParser): + +2013-03-27 Geoffrey Garen <ggaren@apple.com> + + Unreviewed build fix: Removed a dead field. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::ByteCodeParser): + (ByteCodeParser): + +2013-03-27 Geoffrey Garen <ggaren@apple.com> + + Removed some dead code in the DFG bytecode parser + https://bugs.webkit.org/show_bug.cgi?id=113472 + + Reviewed by Sam Weinig. + + Now that Phi creation and liveness analysis are separate passes, we can + remove the vestiges of code that used to do that in the bytecode + parser. + + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::addToGraph): + (JSC::DFG::ByteCodeParser::parse): + +2013-03-27 Filip Pizlo <fpizlo@apple.com> + + JIT and DFG should NaN-check loads from Float32 arrays + https://bugs.webkit.org/show_bug.cgi?id=113462 + <rdar://problem/13490804> + + Reviewed by Mark Hahnenberg. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emitFloatTypedArrayGetByVal): + +2013-03-27 Mark Hahnenberg <mhahnenberg@apple.com> + + CodeCache::m_capacity can becoming negative, producing undefined results in pruneSlowCase + https://bugs.webkit.org/show_bug.cgi?id=113453 + + Reviewed by Geoffrey Garen. + + * runtime/CodeCache.cpp: + (JSC::CodeCacheMap::pruneSlowCase): We make sure that m_minCapacity doesn't drop below zero now. + This prevents m_capacity from doing the same. + +2013-03-27 Filip Pizlo <fpizlo@apple.com> + + DFG should use CheckStructure for typed array checks whenever possible + https://bugs.webkit.org/show_bug.cgi?id=113374 + + Reviewed by Geoffrey Garen. + + We used to do the right thing, but it appears that this regressed at some point. Since the + FixupPhase now has the ability to outright remove spurious CheckStructures on array + operations, it is profitable for the ByteCodeParser to insert CheckStructures whenver there + is a chance that it might be profitable, and when the profiling tells us what structure to + check. + + Also added some code for doing ArrayProfile debugging. + + This is a slightly speed-up. Maybe 3% on Mandreel. + + * bytecode/ArrayProfile.cpp: + (JSC::ArrayProfile::computeUpdatedPrediction): + * dfg/DFGArrayMode.h: + (JSC::DFG::ArrayMode::benefitsFromStructureCheck): + +2013-03-27 Zeno Albisser <zeno@webkit.org> + + [Qt] Remove Qt specific WorkQueueItem definitions. + https://bugs.webkit.org/show_bug.cgi?id=112891 + + This patch is preparation work for removing + WorkQueue related code from TestRunnerQt and + replacing it with generic TestRunner code. + + Reviewed by Benjamin Poulain. + + * API/JSStringRefQt.cpp: + (JSStringCreateWithQString): + Adding a convenience function to create a + JSStringRef from a QString. + * API/JSStringRefQt.h: + +2013-03-26 Filip Pizlo <fpizlo@apple.com> + + REGRESSION: Sometimes, operations on proven strings ignore changes to the string prototype + https://bugs.webkit.org/show_bug.cgi?id=113353 + <rdar://problem/13510778> + + Reviewed by Mark Hahnenberg and Geoffrey Garen. + + ToString should call speculateStringObject() even if you know that it's a string object, since + it calls it to also get the watchpoint. Note that even with this change, if you do + Phantom(Check:StringObject:@a), it might get eliminated just because we proved that @a is a + string object (thereby eliminating the prototype watchpoint); that's fine since ToString is + MustGenerate and never decays to Phantom. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileToStringOnCell): + (JSC::DFG::SpeculativeJIT::speculateStringObject): + (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure): + +2013-03-26 Mark Hahnenberg <mhahnenberg@apple.com> + + REGRESSION(r144131): It made fast/js/regress/string-repeat-arith.html assert on 32 bit + https://bugs.webkit.org/show_bug.cgi?id=112106 + + Rubber stamped by Filip Pizlo. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): Get rid of the case for constants because + we would have done constant folding anyways on a ValueToInt32. + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): Fixed a random compile error with this flag enabled. + +2013-03-26 Filip Pizlo <fpizlo@apple.com> + + JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere + https://bugs.webkit.org/show_bug.cgi?id=113144 + + Reviewed by Geoffrey Garen. + + Forgot to include Geoff's requested change in the original commit. + + * profiler/ProfilerDatabase.cpp: + (Profiler): + +2013-03-25 Filip Pizlo <fpizlo@apple.com> + + JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere + https://bugs.webkit.org/show_bug.cgi?id=113144 + + Reviewed by Geoffrey Garen. + + Added the ability to save profiler output with JSC_enableProfiler=true. It will save it + to the current directory, or JSC_PROFILER_PATH if the latter was specified. + + This works by saving the Profiler::Database either when it is destroyed or atexit(), + whichever happens first. + + This allows use of the profiler from any WebKit client. + + * jsc.cpp: + (jscmain): + * profiler/ProfilerDatabase.cpp: + (Profiler): + (JSC::Profiler::Database::Database): + (JSC::Profiler::Database::~Database): + (JSC::Profiler::Database::registerToSaveAtExit): + (JSC::Profiler::Database::addDatabaseToAtExit): + (JSC::Profiler::Database::removeDatabaseFromAtExit): + (JSC::Profiler::Database::performAtExitSave): + (JSC::Profiler::Database::removeFirstAtExitDatabase): + (JSC::Profiler::Database::atExitCallback): + * profiler/ProfilerDatabase.h: + (JSC::Profiler::Database::databaseID): + (Database): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + +2013-03-25 Filip Pizlo <fpizlo@apple.com> + + ArrayMode should not consider SpecOther when refining the base + https://bugs.webkit.org/show_bug.cgi?id=113271 + + Reviewed by Geoffrey Garen. + + 9% speed-up on Octane/pdfjs. + + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::refine): + +2013-03-26 Csaba Osztrogonác <ossy@webkit.org> + + Fix unused parameter warnings in JITInlines.h + https://bugs.webkit.org/show_bug.cgi?id=112560 + + Reviewed by Zoltan Herczeg. + + * jit/JITInlines.h: + (JSC::JIT::beginUninterruptedSequence): + (JSC::JIT::endUninterruptedSequence): + (JSC): + +2013-03-25 Kent Tamura <tkent@chromium.org> + + Rename ENABLE_INPUT_TYPE_DATETIME + https://bugs.webkit.org/show_bug.cgi?id=113254 + + Reviewed by Kentaro Hara. + + Rename ENABLE_INPUT_TYPE_DATETIME to ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE. + Actually I'd like to remove the code, but we shouldn't remove it yet + because we shipped products with it on some platforms. + + * Configurations/FeatureDefines.xcconfig: + +2013-03-25 Mark Lam <mark.lam@apple.com> + + Offlineasm cloop backend compiles op+branch incorrectly. + https://bugs.webkit.org/show_bug.cgi?id=113146. + + Reviewed by Geoffrey Garen. + + * dfg/DFGRepatch.h: + (JSC::DFG::dfgResetGetByID): + (JSC::DFG::dfgResetPutByID): + - These functions never return when the DFG is dsiabled, not just when + asserts are enabled. Changing the attribute from NO_RETURN_DUE_TO_ASSERT + to NO_RETURN. + * llint/LLIntOfflineAsmConfig.h: + - Added some #defines needed to get the cloop building again. + * offlineasm/cloop.rb: + - Fix cloopEmitOpAndBranchIfOverflow() and cloopEmitOpAndBranch() to + emit code that unconditionally executes the specified operation before + doing the conditional branch. + +2013-03-25 Mark Hahnenberg <mhahnenberg@apple.com> + + JSObject::enterDictionaryIndexingMode doesn't have a case for ALL_BLANK_INDEXING_TYPES + https://bugs.webkit.org/show_bug.cgi?id=113236 + + Reviewed by Geoffrey Garen. + + * runtime/JSObject.cpp: + (JSC::JSObject::enterDictionaryIndexingMode): We forgot blank indexing types. + +2013-03-23 Mark Hahnenberg <mhahnenberg@apple.com> + + HandleSet should use HeapBlocks for storing handles + https://bugs.webkit.org/show_bug.cgi?id=113145 + + Reviewed by Geoffrey Garen. + + * GNUmakefile.list.am: Build project changes. + * JavaScriptCore.gypi: Ditto. + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto. + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto. + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto. + * JavaScriptCore.xcodeproj/project.pbxproj: Ditto. + * heap/BlockAllocator.cpp: Rename the RegionSet to m_fourKBBlockRegionSet because there are + too many block types to include them all in the name now. + (JSC::BlockAllocator::BlockAllocator): + * heap/BlockAllocator.h: + (BlockAllocator): Add the appropriate override for regionSetFor. + (JSC::WeakBlock): + (JSC::MarkStackSegment): + (JSC::HandleBlock): + * heap/HandleBlock.h: Added. + (HandleBlock): New class for HandleBlocks. + (JSC::HandleBlock::blockFor): Static method to get the block of the given HandleNode pointer. Allows + us to quickly figure out which HandleSet the HandleNode belongs to without storing the pointer to it + in the HandleNode. + (JSC::HandleBlock::handleSet): Getter. + * heap/HandleBlockInlines.h: Added. + (JSC::HandleBlock::create): + (JSC::HandleBlock::HandleBlock): + (JSC::HandleBlock::payloadEnd): + (JSC::HandleBlock::payload): + (JSC::HandleBlock::nodes): + (JSC::HandleBlock::nodeAtIndex): + (JSC::HandleBlock::nodeCapacity): + * heap/HandleSet.cpp: + (JSC::HandleSet::~HandleSet): + (JSC::HandleSet::grow): + * heap/HandleSet.h: + (HandleNode): Move the internal Node class from HandleSet to be its own public class so it can be + used by HandleBlock. + (HandleSet): Add a typedef so that Node refers to the new HandleNode class. + (JSC::HandleSet::toHandle): + (JSC::HandleSet::toNode): + (JSC::HandleSet::allocate): + (JSC::HandleSet::deallocate): + (JSC::HandleNode::HandleNode): + (JSC::HandleNode::slot): + (JSC::HandleNode::handleSet): Use the new blockFor static function to get the right HandleBlock and lookup + the HandleSet. + (JSC::HandleNode::setPrev): + (JSC::HandleNode::prev): + (JSC::HandleNode::setNext): + (JSC::HandleNode::next): + (JSC::HandleSet::forEachStrongHandle): + * heap/Heap.h: Friend HandleSet so that it can access the BlockAllocator when allocating HandleBlocks. + +2013-03-22 David Kilzer <ddkilzer@apple.com> + + BUILD FIX (r145119): Make JSValue* properties default to (assign) + <rdar://problem/13380794> + + Reviewed by Mark Hahnenberg. + + Fixes the following build failures: + + Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute] + @property JSValue *onclick; + ^ + Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: default property attrib ute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute] + Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute] + @property JSValue *weakOnclick; + ^ + Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: default property attribute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute] + 4 errors generated. + + * API/tests/testapi.mm: Default to (assign) for JSValue* + properties. + +2013-03-22 Ryosuke Niwa <rniwa@webkit.org> + + testLeakingPrototypesAcrossContexts added in r146682 doesn't compile on Win and fails on Mac + https://bugs.webkit.org/show_bug.cgi?id=113125 + + Reviewed by Mark Hahnenberg + + Remove the test added in r146682 as it's now failing on Mac. + This is the test that was causing a compilation failure on Windows. + + * API/tests/testapi.c: + (main): + +2013-03-22 Ryosuke Niwa <rniwa@webkit.org> + + Fix the typo: WIN -> WINDOWS. + + * API/tests/testapi.c: + (main): + +2013-03-22 Ryosuke Niwa <rniwa@webkit.org> + + I really can't figure out what's wrong with this one. + Temporarily disable the test added by r146682 on Windows since it doesn't compile. + + * API/tests/testapi.c: + (main): + +2013-03-22 Ryosuke Niwa <rniwa@webkit.org> + + Another build fix (after r146693) for r146682. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-03-22 Roger Fong <roger_fong@apple.com> + + Unreviewed. AppleWin build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd: + * JavaScriptCore.vcxproj/copy-files.cmd: + +2013-03-22 Mark Hahnenberg <mhahnenberg@apple.com> + + -[TinyDOMNode dealloc] should call [super dealloc] when ARC is not enabled + https://bugs.webkit.org/show_bug.cgi?id=113054 + + Reviewed by Geoffrey Garen. + + * API/tests/testapi.mm: + (-[TinyDOMNode dealloc]): + +2013-03-22 Mark Hahnenberg <mhahnenberg@apple.com> + + opaqueJSClassData should be cached on JSGlobalObject, not the JSGlobalData + https://bugs.webkit.org/show_bug.cgi?id=113086 + + Reviewed by Geoffrey Garen. + + opaqueJSClassData stores cached prototypes for JSClassRefs in the C API. It doesn't make sense to + share these prototypes within a JSGlobalData across JSGlobalObjects, and in fact doing so will cause + a leak of the original JSGlobalObject that these prototypes were created in. Therefore we should move + this cache to JSGlobalObject where it belongs and where it won't cause memory leaks. + + * API/JSBase.cpp: Needed to add an extern "C" so that testapi.c can use the super secret GC function. + * API/JSClassRef.cpp: We now grab the cached context data from the global object rather than the global data. + (OpaqueJSClass::contextData): + * API/JSClassRef.h: Remove this header because it's unnecessary and causes circular dependencies. + * API/tests/testapi.c: Added a new test that makes sure that using the same JSClassRef in two different contexts + doesn't cause leaks of the original global object. + (leakFinalize): + (nestedAllocateObject): This is a hack to bypass the conservative scan of the GC, which was unnecessarily marking + objects and keeping them alive, ruining the test result. + (testLeakingPrototypesAcrossContexts): + (main): + * API/tests/testapi.mm: extern "C" this so we can continue using it here. + * runtime/JSGlobalData.cpp: Remove JSClassRef related stuff. + (JSC::JSGlobalData::~JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSGlobalObject.h: Add the stuff that JSGlobalData had. We add it to JSGlobalObjectRareData so that + clients who don't use the C API don't have to pay the memory cost of this extra HashMap. + (JSGlobalObject): + (JSGlobalObjectRareData): + (JSC::JSGlobalObject::opaqueJSClassData): + +2013-03-19 Martin Robinson <mrobinson@igalia.com> + + [GTK] Add support for building the WebCore bindings to the gyp build + https://bugs.webkit.org/show_bug.cgi?id=112638 + + Reviewed by Nico Weber. + + * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Export all include directories to direct + dependents and fix the indentation of the libjavascriptcore target. + +2013-03-21 Filip Pizlo <fpizlo@apple.com> + + Fix some minor issues in the DFG's profiling of heap accesses + https://bugs.webkit.org/show_bug.cgi?id=113010 + + Reviewed by Goeffrey Garen. + + 1) If a CodeBlock gets jettisoned by GC, we should count the exit sites. + + 2) If a CodeBlock clears a structure stub during GC, it should record this, and + the DFG should prefer to not inline that access (i.e. treat it as if it had an + exit site). + + 3) If a PutById was seen by the baseline JIT, and the JIT attempted to cache it, + but it chose not to, then assume that it will take slow path. + + 4) If we frequently exited because of a structure check on a weak constant, + don't try to inline that access in the future. + + 5) Treat all exits that were counted as being frequent. + + 81% speed-up on Octane/gbemu. Small speed-ups elsewhere, and no regressions. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::finalizeUnconditionally): + (JSC): + (JSC::CodeBlock::resetStubDuringGCInternal): + (JSC::CodeBlock::reoptimize): + (JSC::CodeBlock::jettison): + (JSC::ProgramCodeBlock::jettisonImpl): + (JSC::EvalCodeBlock::jettisonImpl): + (JSC::FunctionCodeBlock::jettisonImpl): + (JSC::CodeBlock::tallyFrequentExitSites): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::tallyFrequentExitSites): + (ProgramCodeBlock): + (EvalCodeBlock): + (FunctionCodeBlock): + * bytecode/GetByIdStatus.cpp: + (JSC::GetByIdStatus::computeFor): + * bytecode/PutByIdStatus.cpp: + (JSC::PutByIdStatus::computeFor): + * bytecode/StructureStubInfo.h: + (JSC::StructureStubInfo::StructureStubInfo): + (StructureStubInfo): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleGetById): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow): + * dfg/DFGOSRExit.h: + (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite): + (OSRExit): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * runtime/Options.h: + (JSC): + +2013-03-22 Filip Pizlo <fpizlo@apple.com> + + DFG folding of PutById to SimpleReplace should consider the specialized function case + https://bugs.webkit.org/show_bug.cgi?id=113093 + + Reviewed by Geoffrey Garen and Mark Hahnenberg. + + * bytecode/PutByIdStatus.cpp: + (JSC::PutByIdStatus::computeFor): + +2013-03-22 David Kilzer <ddkilzer@apple.com> + + BUILD FIX (r146558): Build testapi.mm with ARC enabled for armv7s + <http://webkit.org/b/112608> + + Fixes the following build failure: + + Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls] + } + ^ + 1 error generated. + + * Configurations/ToolExecutable.xcconfig: Enable ARC for armv7s + architecture. + +2013-03-22 David Kilzer <ddkilzer@apple.com> + + Revert "BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc]" + + This fixes a build failure introduced by this change: + + Source/JavaScriptCore/API/tests/testapi.mm:206:6: error: ARC forbids explicit message send of 'dealloc' + [super dealloc]; + ^ ~~~~~~~ + 1 error generated. + + Not sure why this didn't fail locally on my Mac Pro. + + * API/tests/testapi.mm: + (-[TinyDOMNode dealloc]): Remove call to [super dealloc]. + +2013-03-22 David Kilzer <ddkilzer@apple.com> + + BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc] + <http://webkit.org/b/112608> + + Fixes the following build failure: + + Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls] + } + ^ + 1 error generated. + + * API/tests/testapi.mm: + (-[TinyDOMNode dealloc]): Call [super dealloc]. + +2013-03-22 Ryosuke Niwa <rniwa@webkit.org> + + Leak bots erroneously report JSC::WatchpointSet as leaking + https://bugs.webkit.org/show_bug.cgi?id=107781 + + Reviewed by Filip Pizlo. + + Since leaks doesn't support tagged pointers, avoid using it by flipping the bit flag to indicate + the entry is "fat". We set the flag when the entry is NOT fat; i.e. slim. + + Replaced FatFlag by SlimFlag and initialized m_bits with this flag to indicate that the entry is + initially "slim". + + * runtime/SymbolTable.cpp: + (JSC::SymbolTableEntry::copySlow): Don't set FatFlag since it has been replaced by SlimFlag. + (JSC::SymbolTableEntry::inflateSlow): Ditto. + + * runtime/SymbolTable.h: + (JSC::SymbolTableEntry::Fast::Fast): Set SlimFlag by default. + (JSC::SymbolTableEntry::Fast::isNull): Ignore SlimFlag. + (JSC::SymbolTableEntry::Fast::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag + is not set. + + (JSC::SymbolTableEntry::SymbolTableEntry): Set SlimFlag by default. + (JSC::SymbolTableEntry::SymbolTableEntry::getFast): Set SlimFlag when creating Fast from a fat entry. + (JSC::SymbolTableEntry::isNull): Ignore SlimFlag. + (JSC::SymbolTableEntry::FatEntry::FatEntry): Strip SlimFlag. + (JSC::SymbolTableEntry::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag is unset. + (JSC::SymbolTableEntry::fatEntry): Don't strip FatFlag as this flag doesn't exist anymore. + (JSC::SymbolTableEntry::pack): Preserve SlimFlag. + + (JSC::SymbolTableIndexHashTraits): empty value is no longer zero so don't set emptyValueIsZero true. + +2013-03-21 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Need a good way to preserve custom properties on JS wrappers + https://bugs.webkit.org/show_bug.cgi?id=112608 + + Reviewed by Geoffrey Garen. + + Currently, we just use a weak map, which means that garbage collection can cause a wrapper to + disappear if it isn't directly exported to JavaScript. + + The most straightforward and safe way (with respect to garbage collection and concurrency) is to have + clients add and remove their external references along with their owners. Effectively, the client is + recording the structure of the external object graph so that the garbage collector can make sure to + mark any wrappers that are reachable through either the JS object graph of the external Obj-C object + graph. By keeping these wrappers alive, this has the effect that custom properties on these wrappers + will also remain alive. + + The rule for if an object needs to be tracked by the runtime (and therefore whether the client should report it) is as follows: + For a particular object, its references to its children should be added if: + 1. The child is referenced from JavaScript. + 2. The child contains references to other objects for which (1) or (2) are true. + + * API/JSAPIWrapperObject.mm: + (JSAPIWrapperObjectHandleOwner::finalize): + (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots): A wrapper object is kept alive only if its JSGlobalObject + is marked and its corresponding Objective-C object was added to the set of opaque roots. + (JSC::JSAPIWrapperObject::visitChildren): We now call out to scanExternalObjectGraph, which handles adding all Objective-C + objects to the set of opaque roots. + * API/JSAPIWrapperObject.h: + (JSAPIWrapperObject): + * API/JSContext.mm: Moved dealloc to its proper place in the main implementation. + (-[JSContext dealloc]): + * API/JSVirtualMachine.h: + * API/JSVirtualMachine.mm: + (-[JSVirtualMachine initWithContextGroupRef:]): + (-[JSVirtualMachine dealloc]): + (getInternalObjcObject): Helper funciton to get the Objective-C object out of JSManagedValues or JSValues if there is one. + (-[JSVirtualMachine addManagedReference:withOwner:]): Adds the Objective-C object to the set of objects + owned by the owner object in that particular virtual machine. + (-[JSVirtualMachine removeManagedReference:withOwner:]): Removes the relationship between the two objects. + (-[JSVirtualMachine externalObjectGraph]): + (scanExternalObjectGraph): Does a depth-first search of the external object graph in a particular virtual machine starting at + the specified root. Each new object it encounters it adds to the set of opaque roots. These opaque roots will keep their + corresponding wrapper objects alive if they have them. + * API/JSManagedReferenceInternal.h: Added. + * API/JSVirtualMachine.mm: Added the per-JSVirtualMachine map between objects and the objects they own, which is more formally + known as that virtual machine's external object graph. + * API/JSWrapperMap.mm: + (-[JSWrapperMap dealloc]): We were leaking this before :-( + (-[JSVirtualMachine initWithContextGroupRef:]): + (-[JSVirtualMachine dealloc]): + (-[JSVirtualMachine externalObjectGraph]): + * API/JSVirtualMachineInternal.h: + * API/tests/testapi.mm: Added two new tests using the TinyDOMNode class. The first tests that a custom property added to a wrapper + doesn't vanish after GC, even though that wrapper isn't directly accessible to the JS garbage collector but is accessible through + the external Objective-C object graph. The second test makes sure that adding an object to the external object graph with the same + owner doesn't cause any sort of problems. + (+[TinyDOMNode sharedVirtualMachine]): + (-[TinyDOMNode init]): + (-[TinyDOMNode dealloc]): + (-[TinyDOMNode appendChild:]): + (-[TinyDOMNode numberOfChildren]): + (-[TinyDOMNode childAtIndex:]): + (-[TinyDOMNode removeChildAtIndex:]): + * JavaScriptCore.xcodeproj/project.pbxproj: + * heap/SlotVisitor.h: + (SlotVisitor): + * heap/SlotVisitorInlines.h: + (JSC::SlotVisitor::containsOpaqueRootTriState): Added a new method to SlotVisitor to allow scanExternalObjectGraph to have a + thread-safe view of opaque roots during parallel marking. The set of opaque roots available to any one SlotVisitor isn't guaranteed + to be 100% correct, but that just results in a small duplication of work in scanExternalObjectGraph. To indicate this change for + false negatives we return a TriState that's either true or mixed, but never false. + +2013-03-21 Mark Lam <mark.lam@apple.com> + + Fix O(n^2) op_debug bytecode charPosition to column computation. + https://bugs.webkit.org/show_bug.cgi?id=112957. + + Reviewed by Geoffrey Garen. + + The previous algorithm does a linear reverse scan of the source string + to find the line start for any given char position. This results in a + O(n^2) algortithm when the source string has no line breaks. + + The new algorithm computes a line start column table for a + SourceProvider on first use. This line start table is used to fix up + op_debug's charPosition operand into a column operand when an + UnlinkedCodeBlock is linked into a CodeBlock. The initialization of + the line start table is O(n), and the CodeBlock column fix up is + O(log(n)). + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecode): + (JSC::CodeBlock::CodeBlock): - do column fix up. + * interpreter/Interpreter.cpp: + (JSC::Interpreter::debug): - no need to do column fixup anymore. + * interpreter/Interpreter.h: + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * parser/SourceProvider.cpp: + (JSC::SourceProvider::lineStarts): + (JSC::charPositionExtractor): + (JSC::SourceProvider::charPositionToColumnNumber): + - initialize line start column table if needed. + - look up line start for the given char position. + * parser/SourceProvider.h: + +2013-03-21 Filip Pizlo <fpizlo@apple.com> + + JSC profiler should have an at-a-glance report of the success of DFG optimization + https://bugs.webkit.org/show_bug.cgi?id=112988 + + Reviewed by Geoffrey Garen. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleCall): + (JSC::DFG::ByteCodeParser::handleGetById): + (JSC::DFG::ByteCodeParser::parseBlock): + * profiler/ProfilerCompilation.cpp: + (JSC::Profiler::Compilation::Compilation): + (JSC::Profiler::Compilation::toJS): + * profiler/ProfilerCompilation.h: + (JSC::Profiler::Compilation::noticeInlinedGetById): + (JSC::Profiler::Compilation::noticeInlinedPutById): + (JSC::Profiler::Compilation::noticeInlinedCall): + (Compilation): + * runtime/CommonIdentifiers.h: + +2013-03-21 Mark Lam <mark.lam@apple.com> + + Fix lexer charPosition computation when "rewind"ing the lexer. + https://bugs.webkit.org/show_bug.cgi?id=112952. + + Reviewed by Michael Saboff. + + Changed the Lexer to no longer keep a m_charPosition. Instead, we compute + currentCharPosition() from m_code and m_codeStartPlusOffset, where + m_codeStartPlusOffset is the SourceProvider m_codeStart + the SourceCode + start offset. This ensures that the charPosition is always in sync with + m_code. + + * parser/Lexer.cpp: + (JSC::::setCode): + (JSC::::internalShift): + (JSC::::shift): + (JSC::::lex): + * parser/Lexer.h: + (JSC::Lexer::currentCharPosition): + (JSC::::lexExpectIdentifier): + +2013-03-21 Alberto Garcia <agarcia@igalia.com> + + [BlackBerry] GCActivityCallback: replace JSLock with JSLockHolder + https://bugs.webkit.org/show_bug.cgi?id=112448 + + Reviewed by Xan Lopez. + + This changed in r121381. + + * runtime/GCActivityCallbackBlackBerry.cpp: + (JSC::DefaultGCActivityCallback::doWork): + +2013-03-21 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: wrapperClass holds a static JSClassRef, which causes JSGlobalObjects to leak + https://bugs.webkit.org/show_bug.cgi?id=112856 + + Reviewed by Geoffrey Garen. + + Through a very convoluted path that involves the caching of prototypes on the JSClassRef, we can leak + JSGlobalObjects when inserting an Objective-C object into multiple independent JSContexts. + + * API/JSAPIWrapperObject.cpp: Removed. + * API/JSAPIWrapperObject.h: + (JSAPIWrapperObject): + * API/JSAPIWrapperObject.mm: Copied from Source/JavaScriptCore/API/JSAPIWrapperObject.cpp. Made this an + Objective-C++ file so that we can call release on the wrappedObject. Also added a WeakHandleOwner for + JSAPIWrapperObjects. This will also be used in a future patch for https://bugs.webkit.org/show_bug.cgi?id=112608. + (JSAPIWrapperObjectHandleOwner): + (jsAPIWrapperObjectHandleOwner): + (JSAPIWrapperObjectHandleOwner::finalize): This finalize replaces the old finalize that was done through + the C API. + (JSC::JSAPIWrapperObject::finishCreation): Allocate the WeakImpl. Balanced in finalize. + (JSC::JSAPIWrapperObject::setWrappedObject): We now do the retain of the wrappedObject here rather than in random + places scattered around JSWrapperMap.mm + * API/JSObjectRef.cpp: Added some ifdefs for platforms that don't support the Obj-C API. + (JSObjectGetPrivate): Ditto. + (JSObjectSetPrivate): Ditto. + (JSObjectGetPrivateProperty): Ditto. + (JSObjectSetPrivateProperty): Ditto. + (JSObjectDeletePrivateProperty): Ditto. + * API/JSValueRef.cpp: Ditto. + (JSValueIsObjectOfClass): Ditto. + * API/JSWrapperMap.mm: Remove wrapperClass(). + (objectWithCustomBrand): Change to no longer use a parent class, which was only used to give the ability to + finalize wrapper objects. + (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Change to no longer use wrapperClass(). + (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Ditto. + (tryUnwrapObjcObject): We now check if the object inherits from JSAPIWrapperObject. + * API/tests/testapi.mm: Added a test that exports an Objective-C object to two different JSContexts and makes + sure that the first one is collected properly by using a weak JSManagedValue for the wrapper in the first JSContext. + * CMakeLists.txt: Build file modifications. + * GNUmakefile.list.am: Ditto. + * JavaScriptCore.gypi: Ditto. + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto. + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto. + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto. + * JavaScriptCore.xcodeproj/project.pbxproj: Ditto. + * runtime/JSGlobalObject.cpp: More ifdefs for unsupported platforms. + (JSC::JSGlobalObject::reset): Ditto. + (JSC::JSGlobalObject::visitChildren): Ditto. + * runtime/JSGlobalObject.h: Ditto. + (JSGlobalObject): Ditto. + (JSC::JSGlobalObject::objcCallbackFunctionStructure): Ditto. + +2013-03-21 Anton Muhin <antonm@chromium.org> + + Unreviewed, rolling out r146483. + http://trac.webkit.org/changeset/146483 + https://bugs.webkit.org/show_bug.cgi?id=111695 + + Breaks debug builds. + + * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo. + +2013-03-21 Gabor Rapcsanyi <rgabor@webkit.org> + + Implement LLInt for CPU(ARM_TRADITIONAL) + https://bugs.webkit.org/show_bug.cgi?id=97589 + + Reviewed by Zoltan Herczeg. + + Enable LLInt for ARMv5 and ARMv7 traditional as well. + + * llint/LLIntOfflineAsmConfig.h: + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * offlineasm/arm.rb: + * offlineasm/backends.rb: + * offlineasm/instructions.rb: + +2013-03-20 Cosmin Truta <ctruta@blackberry.com> + + [QNX][ARM] REGRESSION(r135330): Various failures in Octane + https://bugs.webkit.org/show_bug.cgi?id=112863 + + Reviewed by Yong Li. + + This was fixed in http://trac.webkit.org/changeset/146396 on Linux only. + Enable this fix on QNX. + + * assembler/ARMv7Assembler.h: + (ARMv7Assembler): + (JSC::ARMv7Assembler::replaceWithJump): + (JSC::ARMv7Assembler::maxJumpReplacementSize): + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch): + +2013-03-20 Filip Pizlo <fpizlo@apple.com> + + Fix indentation of JSString.h + + Rubber stamped by Mark Hahnenberg. + + * runtime/JSString.h: + +2013-03-20 Filip Pizlo <fpizlo@apple.com> + + "" + x where x is not a string should be optimized by the DFG to some manner of ToString conversion + https://bugs.webkit.org/show_bug.cgi?id=112845 + + Reviewed by Mark Hahnenberg. + + I like to do "" + x. So I decided to make DFG recognize it, and related idioms. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::fixupToPrimitive): + (FixupPhase): + (JSC::DFG::FixupPhase::fixupToString): + (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::resultOfToPrimitive): + (DFG): + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGPredictionPropagationPhase.h: + (DFG): + +2013-03-20 Zoltan Herczeg <zherczeg@webkit.org> + + ARMv7 replaceWithJump ASSERT failure after r135330. + https://bugs.webkit.org/show_bug.cgi?id=103146 + + Reviewed by Filip Pizlo. + + On Linux, the 24 bit distance range of jumps sometimes does not + enough to cover all targets addresses. This patch supports jumps + outside of this range using a mov/movt/bx 10 byte long sequence. + + * assembler/ARMv7Assembler.h: + (ARMv7Assembler): + (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2): + (JSC::ARMv7Assembler::nopw): + (JSC::ARMv7Assembler::label): + (JSC::ARMv7Assembler::replaceWithJump): + (JSC::ARMv7Assembler::maxJumpReplacementSize): + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch): + +2013-03-20 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Fix over-releasing in allocateConstructorAndPrototypeWithSuperClassInfo: + https://bugs.webkit.org/show_bug.cgi?id=112832 + + Reviewed by Geoffrey Garen. + + If either the m_constructor or m_prototype (but not both) is collected, we will call + allocateConstructorAndPrototypeWithSuperClassInfo, which will create a new object to replace the one + that was collected, but at the end of the method we call release on both of them. + This is incorrect since we autorelease the JSValue in the case that the object doesn't need to be + reallocated. Thus we'll end up overreleasing later during the drain of the autorelease pool. + + * API/JSWrapperMap.mm: + (objectWithCustomBrand): We no longer alloc here. We instead call the JSValue valueWithValue class method, + which autoreleases for us. + (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We no longer call release on the + constructor or prototype JSValues. + * API/tests/testapi.mm: Added a new test that crashes on ToT due to over-releasing. + +2013-03-19 Filip Pizlo <fpizlo@apple.com> + + It's called "Hash Consing" not "Hash Consting" + https://bugs.webkit.org/show_bug.cgi?id=112768 + + Rubber stamped by Mark Hahnenberg. + + See http://en.wikipedia.org/wiki/Hash_consing + + * heap/GCThreadSharedData.cpp: + (JSC::GCThreadSharedData::GCThreadSharedData): + (JSC::GCThreadSharedData::reset): + * heap/GCThreadSharedData.h: + (GCThreadSharedData): + * heap/SlotVisitor.cpp: + (JSC::SlotVisitor::SlotVisitor): + (JSC::SlotVisitor::setup): + (JSC::SlotVisitor::reset): + (JSC::JSString::tryHashConsLock): + (JSC::JSString::releaseHashConsLock): + (JSC::JSString::shouldTryHashCons): + (JSC::SlotVisitor::internalAppend): + * heap/SlotVisitor.h: + (SlotVisitor): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + (JSC::JSGlobalData::haveEnoughNewStringsToHashCons): + (JSC::JSGlobalData::resetNewStringsSinceLastHashCons): + * runtime/JSString.h: + (JSC::JSString::finishCreation): + (JSString): + (JSC::JSString::isHashConsSingleton): + (JSC::JSString::clearHashConsSingleton): + (JSC::JSString::setHashConsSingleton): + +2013-03-20 Filip Pizlo <fpizlo@apple.com> + + DFG implementation of op_strcat should inline rope allocations + https://bugs.webkit.org/show_bug.cgi?id=112780 + + Reviewed by Oliver Hunt. + + This gets rid of the StrCat node and adds a MakeRope node. The MakeRope node can + take either two or three operands, and allocates a rope string with either two or + three fibers. (The magic choice of three children for non-VarArg nodes happens to + match exactly with the magic choice of three fibers for rope strings.) + + ValueAdd on KnownString is replaced with MakeRope with two children. + + StrCat gets replaced by an appropriate sequence of MakeRope's. + + MakeRope does not do the dynamic check to see if its children are empty strings. + This is replaced by a static check, instead. The downside is that we may use more + memory if the strings passed to MakeRope turn out to dynamically be empty. The + upside is that we do fewer checks in the cases where either the strings are not + empty, or where the strings are statically known to be empty. I suspect both of + those cases are more common, than the case where the string is dynamically empty. + + This also results in some badness for X86. MakeRope needs six registers if it is + allocating a three-rope. We don't have six registers to spare on X86. Currently, + the code side-steps this problem by just never usign three-ropes in optimized + code on X86. All other architectures, including X86_64, don't have this problem. + + This is a shocking speed-up. 9% progressions on both V8/splay and + SunSpider/date-format-xparb. 1% progression on V8v7 overall, and ~0.5% progression + on SunSpider. 2x speed-up on microbenchmarks that test op_strcat. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::executeEffects): + * dfg/DFGAdjacencyList.h: + (AdjacencyList): + (JSC::DFG::AdjacencyList::removeEdge): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): + * dfg/DFGBackwardsPropagationPhase.cpp: + (JSC::DFG::BackwardsPropagationPhase::propagate): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::putStructureStoreElimination): + (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGDCEPhase.cpp: + (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::createToString): + (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion): + (JSC::DFG::FixupPhase::convertStringAddUse): + (FixupPhase): + (JSC::DFG::FixupPhase::convertToMakeRope): + (JSC::DFG::FixupPhase::fixupMakeRope): + (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileAdd): + (JSC::DFG::SpeculativeJIT::compileMakeRope): + (DFG): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand): + (JSC::DFG::SpeculateCellOperand::~SpeculateCellOperand): + (JSC::DFG::SpeculateCellOperand::gpr): + (JSC::DFG::SpeculateCellOperand::use): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * runtime/JSString.h: + (JSRopeString): + +2013-03-20 Peter Gal <galpeter@inf.u-szeged.hu> + + Implement and32 on MIPS platform + https://bugs.webkit.org/show_bug.cgi?id=112665 + + Reviewed by Zoltan Herczeg. + + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::and32): Added missing method. + (MacroAssemblerMIPS): + +2013-03-20 Mark Lam <mark.lam@apple.com> + + Fix incorrect debugger column number value. + https://bugs.webkit.org/show_bug.cgi?id=112741. + + Reviewed by Oliver Hunt. + + 1. In lexer, parser, and debugger code, renamed column to charPosition. + 2. Convert the charPosition to the equivalent column number before + passing it to the debugger. + 3. Changed ScopeNodes to take both a startLocation and an endLocation. + This allows FunctionBodyNodes, ProgramNodes, and EvalNodess to emit + correct debug hooks with correct starting line and column numbers. + 4. Fixed the Lexer to not reset the charPosition (previously + columnNumber) in Lexer::lex(). + + * JavaScriptCore.order: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecode): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitDebugHook): + * bytecompiler/BytecodeGenerator.h: + (JSC::BytecodeGenerator::emitExpressionInfo): + * bytecompiler/NodesCodegen.cpp: + (JSC::ArrayNode::toArgumentList): + (JSC::ConstStatementNode::emitBytecode): + (JSC::EmptyStatementNode::emitBytecode): + (JSC::DebuggerStatementNode::emitBytecode): + (JSC::ExprStatementNode::emitBytecode): + (JSC::VarStatementNode::emitBytecode): + (JSC::IfNode::emitBytecode): + (JSC::IfElseNode::emitBytecode): + (JSC::DoWhileNode::emitBytecode): + (JSC::WhileNode::emitBytecode): + (JSC::ForNode::emitBytecode): + (JSC::ForInNode::emitBytecode): + (JSC::ContinueNode::emitBytecode): + (JSC::BreakNode::emitBytecode): + (JSC::ReturnNode::emitBytecode): + (JSC::WithNode::emitBytecode): + (JSC::SwitchNode::emitBytecode): + (JSC::LabelNode::emitBytecode): + (JSC::ThrowNode::emitBytecode): + (JSC::TryNode::emitBytecode): + (JSC::ProgramNode::emitBytecode): + (JSC::EvalNode::emitBytecode): + (JSC::FunctionBodyNode::emitBytecode): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::debug): + - convert charPosition to column for the debugger. + * interpreter/Interpreter.h: + * jit/JITStubs.cpp: + (DEFINE_STUB_FUNCTION(void, op_debug)): + * llint/LLIntSlowPaths.cpp: + (LLINT_SLOW_PATH_DECL(slow_op_debug)): + * parser/ASTBuilder.h: + (JSC::ASTBuilder::createFunctionExpr): + (JSC::ASTBuilder::createFunctionBody): + (JSC::ASTBuilder::createGetterOrSetterProperty): + (JSC::ASTBuilder::createFuncDeclStatement): + (JSC::ASTBuilder::createBlockStatement): + (JSC::ASTBuilder::createExprStatement): + (JSC::ASTBuilder::createIfStatement): + (JSC::ASTBuilder::createForLoop): + (JSC::ASTBuilder::createForInLoop): + (JSC::ASTBuilder::createVarStatement): + (JSC::ASTBuilder::createReturnStatement): + (JSC::ASTBuilder::createBreakStatement): + (JSC::ASTBuilder::createContinueStatement): + (JSC::ASTBuilder::createTryStatement): + (JSC::ASTBuilder::createSwitchStatement): + (JSC::ASTBuilder::createWhileStatement): + (JSC::ASTBuilder::createDoWhileStatement): + (JSC::ASTBuilder::createWithStatement): + (JSC::ASTBuilder::createThrowStatement): + (JSC::ASTBuilder::createDebugger): + (JSC::ASTBuilder::createConstStatement): + * parser/Lexer.cpp: + (JSC::::setCode): + (JSC::::internalShift): + (JSC::::shift): + (JSC::::lex): + * parser/Lexer.h: + (JSC::Lexer::currentCharPosition): + (Lexer): + (JSC::::lexExpectIdentifier): + * parser/NodeConstructors.h: + (JSC::Node::Node): + * parser/Nodes.cpp: + (JSC::StatementNode::setLoc): + (JSC::ScopeNode::ScopeNode): + (JSC::ProgramNode::ProgramNode): + (JSC::ProgramNode::create): + (JSC::EvalNode::EvalNode): + (JSC::EvalNode::create): + (JSC::FunctionBodyNode::FunctionBodyNode): + (JSC::FunctionBodyNode::create): + * parser/Nodes.h: + (JSC::Node::charPosition): + (Node): + (StatementNode): + (JSC::StatementNode::lastLine): + (ScopeNode): + (JSC::ScopeNode::startLine): + (JSC::ScopeNode::startCharPosition): + (ProgramNode): + (EvalNode): + (FunctionBodyNode): + * parser/Parser.cpp: + (JSC::::Parser): + (JSC::::parseFunctionBody): + (JSC::::parseFunctionInfo): + * parser/Parser.h: + (JSC::::parse): + * parser/ParserTokens.h: + (JSC::JSTokenLocation::JSTokenLocation): + (JSTokenLocation): + * parser/SyntaxChecker.h: + (JSC::SyntaxChecker::createFunctionBody): + +2013-03-20 Csaba Osztrogonác <ossy@webkit.org> + + REGRESSION(r146089): It broke 20 sputnik tests on ARM traditional and Thumb2 + https://bugs.webkit.org/show_bug.cgi?id=112676 + + Rubber-stamped by Filip Pizlo. + + Add one more EABI_32BIT_DUMMY_ARG to make DFG JIT ARM EABI compatible + again after r146089 similar to https://bugs.webkit.org/show_bug.cgi?id=84449 + + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + +2013-03-19 Michael Saboff <msaboff@apple.com> + + Crash when loading http://www.jqchart.com/jquery/gauges/RadialGauge/LiveData + https://bugs.webkit.org/show_bug.cgi?id=112694 + + Reviewed by Filip Pizlo. + + We were trying to convert an NewArray to a Phantom, but convertToPhantom doesn't handle + nodes with variable arguments. Added code to insert a Phantom node in front of all the + live children of a var args node. Added ASSERT not var args for convertToPhantom to + catch any other similar cases. Added a new convertToPhantomUnchecked() for converting + var arg nodes. + + * dfg/DFGDCEPhase.cpp: + (JSC::DFG::DCEPhase::run): + * dfg/DFGNode.h: + (Node): + (JSC::DFG::Node::setOpAndDefaultNonExitFlags): Added ASSERT(!(m_flags & NodeHasVarArgs)) + (JSC::DFG::Node::setOpAndDefaultNonExitFlagsUnchecked): + (JSC::DFG::Node::convertToPhantomUnchecked): + +2013-03-19 Mark Hahnenberg <mhahnenberg@apple.com> + + Crash in SpeculativeJIT::fillSpeculateIntInternal<false> on http://bellard.org/jslinux + https://bugs.webkit.org/show_bug.cgi?id=112738 + + Reviewed by Filip Pizlo. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixIntEdge): We shouldn't be killing this node because it could be + referenced by other people. + +2013-03-19 Oliver Hunt <oliver@apple.com> + + RELEASE_ASSERT fires in exception handler lookup + + RS=Geoff Garen. + + Temporarily switch this RELEASE_ASSERT into a regular ASSERT + as currently this is producing fairly bad crashiness. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::handlerForBytecodeOffset): + +2013-03-18 Filip Pizlo <fpizlo@apple.com> + + DFG should optimize StringObject.length and StringOrStringObject.length + https://bugs.webkit.org/show_bug.cgi?id=112658 + + Reviewed by Mark Hahnenberg. + + Implemented by injecting a ToString(StringObject:@a) or ToString(StringOrStringObject:@a) prior + to GetArrayLength with ArrayMode(Array::String) if @a is predicted StringObject or + StringOrStringObject. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::createToString): + (FixupPhase): + (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion): + (JSC::DFG::FixupPhase::convertStringAddUse): + +2013-03-19 Gabor Rapcsanyi <rgabor@webkit.org> + + Implement and32 on ARMv7 and ARM traditional platforms + https://bugs.webkit.org/show_bug.cgi?id=112663 + + Reviewed by Zoltan Herczeg. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::and32): Add missing method. + (MacroAssemblerARM): + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::and32): Add missing method. + (MacroAssemblerARMv7): + +2013-03-18 Filip Pizlo <fpizlo@apple.com> + + DFG ToString generic cases should work correctly + https://bugs.webkit.org/show_bug.cgi?id=112654 + <rdar://problem/13447250> + + Reviewed by Geoffrey Garen. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileToStringOnCell): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-03-18 Michael Saboff <msaboff@apple.com> + + Unreviewed build fix for 32 bit builds. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-03-18 Michael Saboff <msaboff@apple.com> + + EFL: Unsafe branch detected in compilePutByValForFloatTypedArray() + https://bugs.webkit.org/show_bug.cgi?id=112609 + + Reviewed by Geoffrey Garen. + + Created local valueFPR and scratchFPR and filled them with valueOp.fpr() and scratch.fpr() + respectively so that if valueOp.fpr() causes a spill during allocation, it occurs before the + branch and also to follow convention. Added register allocation checks to FPRTemporary. + Cleaned up a couple of other places to follow the "AllocatVirtualRegType foo, get machine + reg from foo" pattern. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::fprAllocate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::convertToDouble): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-03-18 Filip Pizlo <fpizlo@apple.com> + + DFG should inline binary string concatenations (i.e. ValueAdd with string children) + https://bugs.webkit.org/show_bug.cgi?id=112599 + + Reviewed by Oliver Hunt. + + This does as advertised: if you do x + y where x and y are strings, you'll get + a fast inlined JSRopeString allocation (along with whatever checks are necessary). + It also does good things if either x or y (or both) are StringObjects, or some + other thing like StringOrStringObject. It also lays the groundwork for making this + fast if either x or y are numbers, or some other reasonably-cheap-to-convert + value. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::executeEffects): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (FixupPhase): + (JSC::DFG::FixupPhase::isStringObjectUse): + (JSC::DFG::FixupPhase::convertStringAddUse): + (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileAdd): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::emitAllocateJSCell): + (JSC::DFG::SpeculativeJIT::emitAllocateJSObject): + * runtime/JSString.h: + (JSC::JSString::offsetOfFlags): + (JSString): + (JSRopeString): + (JSC::JSRopeString::offsetOfFibers): + +2013-03-18 Filip Pizlo <fpizlo@apple.com> + + JSC_NATIVE_FUNCTION() takes an identifier for the name and then uses #name, which is unsafe if name was already #define'd to something else + https://bugs.webkit.org/show_bug.cgi?id=112639 + + Reviewed by Michael Saboff. + + Change it to take a string instead. + + * runtime/JSObject.h: + (JSC): + * runtime/ObjectPrototype.cpp: + (JSC::ObjectPrototype::finishCreation): + * runtime/StringPrototype.cpp: + (JSC::StringPrototype::finishCreation): + +2013-03-18 Brent Fulgham <bfulgham@webkit.org> + + [WinCairo] Get build working under VS2010. + https://bugs.webkit.org/show_bug.cgi?id=112604 + + Reviewed by Tim Horton. + + * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Use CFLite-specific + build target (standard version links against CoreFoundation.lib + instead of CFLite.lib). + * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Added. + * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Added. + * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Added. + +2013-03-18 Roger Fong <roger_fong@apple.com> + + AppleWin VS2010 Debug configuration build fix.. + + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + +2013-03-18 Brent Fulgham <bfulgham@webkit.org> + + [WinCairo] Get build working under VS2010. + https://bugs.webkit.org/show_bug.cgi?id=112604 + + Reviewed by Tim Horton. + + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add build targets for + Debug_WinCairo and Release_WinCairo using CFLite. + * JavaScriptCore.vcxproj/JavaScriptCoreCFLite.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj: + Add Debug_WinCairo and Release_WinCairo build targets to + make sure headers are copied to proper build folder. + * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Ditto. + * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props: Added. + * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: + Add Debug_WinCairo and Release_WinCairo build targets to + make sure headers are copied to proper build folder. + * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: + Ditto. + * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: + Ditto. + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Ditto. + * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Ditto. + * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Ditto. + +2013-03-18 Michael Saboff <msaboff@apple.com> + + Potentially unsafe register allocations in DFG code generation + https://bugs.webkit.org/show_bug.cgi?id=112477 + + Reviewed by Geoffrey Garen. + + Moved allocation of temporary GPRs to be before any generated branches in the functions below. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): + +2013-03-15 Filip Pizlo <fpizlo@apple.com> + + DFG string conversions and allocations should be inlined + https://bugs.webkit.org/show_bug.cgi?id=112376 + + Reviewed by Geoffrey Garen. + + This turns new String(), String(), String.prototype.valueOf(), and + String.prototype.toString() into intrinsics. It gives the DFG the ability to handle + conversions from StringObject to JSString and vice-versa, and also gives it the + ability to handle cases where a variable may be either a StringObject or a JSString. + To do this, I added StringObject to value profiling (and removed the stale + distinction between Myarguments and Foreignarguments). I also cleaned up ToPrimitive + handling, using some of the new functionality but also taking advantage of the + existence of Identity(String:@a). + + This is a 2% SunSpider speed-up. Also there are some speed-ups on V8v7 and Kraken. + On microbenchmarks that stress new String() this is a 14x speed-up. + + * CMakeLists.txt: + * DerivedSources.make: + * DerivedSources.pri: + * GNUmakefile.list.am: + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::hasExitSite): + (JSC): + * bytecode/DFGExitProfile.cpp: + (JSC::DFG::ExitProfile::hasExitSite): + (DFG): + * bytecode/DFGExitProfile.h: + (ExitProfile): + (JSC::DFG::ExitProfile::hasExitSite): + * bytecode/ExitKind.cpp: + (JSC::exitKindToString): + * bytecode/ExitKind.h: + * bytecode/SpeculatedType.cpp: + (JSC::dumpSpeculation): + (JSC::speculationToAbbreviatedString): + (JSC::speculationFromClassInfo): + * bytecode/SpeculatedType.h: + (JSC): + (JSC::isStringObjectSpeculation): + (JSC::isStringOrStringObjectSpeculation): + * create_hash_table: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::executeEffects): + * dfg/DFGAbstractState.h: + (JSC::DFG::AbstractState::filterEdgeByUse): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::handleCall): + (JSC::DFG::ByteCodeParser::emitArgumentPhantoms): + (DFG): + (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::putStructureStoreElimination): + * dfg/DFGEdge.h: + (JSC::DFG::Edge::shift): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::isStringPrototypeMethodSane): + (FixupPhase): + (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess): + (JSC::DFG::FixupPhase::observeUseKindOnNode): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::hasGlobalExitSite): + (Graph): + (JSC::DFG::Graph::hasExitSite): + (JSC::DFG::Graph::clobbersWorld): + * dfg/DFGNode.h: + (JSC::DFG::Node::convertToToString): + (Node): + (JSC::DFG::Node::hasStructure): + (JSC::DFG::Node::shouldSpeculateStringObject): + (JSC::DFG::Node::shouldSpeculateStringOrStringObject): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileToStringOnCell): + (DFG): + (JSC::DFG::SpeculativeJIT::compileNewStringObject): + (JSC::DFG::SpeculativeJIT::speculateObject): + (JSC::DFG::SpeculativeJIT::speculateObjectOrOther): + (JSC::DFG::SpeculativeJIT::speculateString): + (JSC::DFG::SpeculativeJIT::speculateStringObject): + (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject): + (JSC::DFG::SpeculativeJIT::speculate): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand): + (DFG): + (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGUseKind.cpp: + (WTF::printInternal): + * dfg/DFGUseKind.h: + (JSC::DFG::typeFilterFor): + * interpreter/CallFrame.h: + (JSC::ExecState::regExpPrototypeTable): + * runtime/CommonIdentifiers.h: + * runtime/Intrinsic.h: + * runtime/JSDestructibleObject.h: + (JSDestructibleObject): + (JSC::JSDestructibleObject::classInfoOffset): + * runtime/JSGlobalData.cpp: + (JSC): + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::~JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSObject.cpp: + * runtime/JSObject.h: + (JSC): + * runtime/JSWrapperObject.h: + (JSC::JSWrapperObject::allocationSize): + (JSWrapperObject): + (JSC::JSWrapperObject::internalValueOffset): + (JSC::JSWrapperObject::internalValueCellOffset): + * runtime/StringPrototype.cpp: + (JSC): + (JSC::StringPrototype::finishCreation): + (JSC::StringPrototype::create): + * runtime/StringPrototype.h: + (StringPrototype): + +2013-03-18 Filip Pizlo <fpizlo@apple.com> + + ObjectPrototype properties should be eagerly created rather than lazily via static tables + https://bugs.webkit.org/show_bug.cgi?id=112539 + + Reviewed by Oliver Hunt. + + This is the first part of https://bugs.webkit.org/show_bug.cgi?id=112233. Rolling this + in first since it's the less-likely-to-be-broken part. + + * CMakeLists.txt: + * DerivedSources.make: + * DerivedSources.pri: + * GNUmakefile.list.am: + * interpreter/CallFrame.h: + (JSC::ExecState::objectConstructorTable): + * runtime/CommonIdentifiers.h: + * runtime/JSGlobalData.cpp: + (JSC): + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::~JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSObject.cpp: + (JSC::JSObject::putDirectNativeFunction): + (JSC): + * runtime/JSObject.h: + (JSObject): + (JSC): + * runtime/Lookup.cpp: + (JSC::setUpStaticFunctionSlot): + * runtime/ObjectPrototype.cpp: + (JSC): + (JSC::ObjectPrototype::finishCreation): + (JSC::ObjectPrototype::create): + * runtime/ObjectPrototype.h: + (ObjectPrototype): + +2013-03-16 Pratik Solanki <psolanki@apple.com> + + Disable High DPI Canvas on iOS + https://bugs.webkit.org/show_bug.cgi?id=112511 + + Reviewed by Joseph Pecoraro. + + * Configurations/FeatureDefines.xcconfig: + +2013-03-15 Andreas Kling <akling@apple.com> + + Don't also clone StructureRareData when cloning Structure. + <http://webkit.org/b/111672> + + Reviewed by Mark Hahnenberg. + + We were cloning a lot of StructureRareData with only the previousID pointer set since + the enumerationCache is not shared between clones. + + Let the Structure copy constructor decide whether it wants to clone the rare data. + The decision is made by StructureRareData::needsCloning() and will currently always + return false, since StructureRareData only holds on to caches at present. + This may change in the future as more members are added to StructureRareData. + + * runtime/Structure.cpp: + (JSC::Structure::Structure): + (JSC::Structure::cloneRareDataFrom): + * runtime/StructureInlines.h: + (JSC::Structure::create): + +2013-03-15 Mark Hahnenberg <mhahnenberg@apple.com> + + Roll out r145838 + https://bugs.webkit.org/show_bug.cgi?id=112458 + + Unreviewed. Requested by Filip Pizlo. + + * CMakeLists.txt: + * DerivedSources.make: + * DerivedSources.pri: + * GNUmakefile.list.am: + * dfg/DFGOperations.cpp: + * interpreter/CallFrame.h: + (JSC::ExecState::objectPrototypeTable): + * jit/JITStubs.cpp: + (JSC::getByVal): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::getByVal): + * runtime/CommonIdentifiers.h: + * runtime/JSCell.cpp: + (JSC): + * runtime/JSCell.h: + (JSCell): + * runtime/JSCellInlines.h: + (JSC): + (JSC::JSCell::fastGetOwnProperty): + * runtime/JSGlobalData.cpp: + (JSC): + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::~JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSObject.cpp: + (JSC): + * runtime/JSObject.h: + (JSObject): + (JSC): + * runtime/Lookup.cpp: + (JSC::setUpStaticFunctionSlot): + * runtime/ObjectPrototype.cpp: + (JSC): + (JSC::ObjectPrototype::finishCreation): + (JSC::ObjectPrototype::getOwnPropertySlot): + (JSC::ObjectPrototype::getOwnPropertyDescriptor): + * runtime/ObjectPrototype.h: + (JSC::ObjectPrototype::create): + (ObjectPrototype): + * runtime/PropertyMapHashTable.h: + (JSC::PropertyTable::findWithString): + * runtime/Structure.h: + (Structure): + * runtime/StructureInlines.h: + (JSC::Structure::get): + +2013-03-15 Michael Saboff <msaboff@apple.com> + + Cleanup of DFG and Baseline JIT debugging code + https://bugs.webkit.org/show_bug.cgi?id=111871 + + Reviewed by Geoffrey Garen. + + Fixed various debug related issue in baseline and DFG JITs. See below. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::dfgLinkClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL. + * dfg/DFGScratchRegisterAllocator.h: Now use ScratchBuffer::activeLengthPtr() to get + pointer to scratch register length. + (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer): + (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkConsistency): Added missing case labels for DataFormatOSRMarker, + DataFormatDead, and DataFormatArguments and made them RELEASE_ASSERT_NOT_REACHED(); + * jit/JITCall.cpp: + (JSC::JIT::privateCompileClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL. + * jit/JITCall32_64.cpp: + (JSC::JIT::privateCompileClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL. + * runtime/JSGlobalData.h: + (JSC::ScratchBuffer::ScratchBuffer): Fixed buffer allocation alignment to + be on a double boundary. + (JSC::ScratchBuffer::setActiveLength): + (JSC::ScratchBuffer::activeLength): + (JSC::ScratchBuffer::activeLengthPtr): + +2013-03-15 Michael Saboff <msaboff@apple.com> + + Add runtime check for improper register allocations in DFG + https://bugs.webkit.org/show_bug.cgi?id=112380 + + Reviewed by Geoffrey Garen. + + Added framework to check for register allocation within a branch source - target range. All register allocations + are saved using the offset in the code stream where the allocation occurred. Later when a jump is linked, the + currently saved register allocations are checked to make sure that they didn't occur in the range of code that was + jumped over. This protects against the case where an allocation could have spilled register contents to free up + a register and that spill only occurs on one path of a many through the code. A subsequent fill of the spilled + register may load garbage. See https://bugs.webkit.org/show_bug.cgi?id=111777 for one such bug. + This code is protected by the compile time check of #if ENABLE(DFG_REGISTER_ALLOCATION_VALIDATION). + The check is only done during the processing of SpeculativeJIT::compile(Node* node) and its callees. + + * assembler/AbstractMacroAssembler.h: + (JSC::AbstractMacroAssembler::Jump::link): Invoke register allocation checks using source and target of link. + (JSC::AbstractMacroAssembler::Jump::linkTo): Invoke register allocation checks using source and target of link. + (AbstractMacroAssembler): + (RegisterAllocationOffset): New helper class to store the instruction stream offset and compare against a + jump range. + (JSC::AbstractMacroAssembler::RegisterAllocationOffset::RegisterAllocationOffset): + (JSC::AbstractMacroAssembler::RegisterAllocationOffset::check): + (JSC::AbstractMacroAssembler::addRegisterAllocationAtOffset): + (JSC::AbstractMacroAssembler::clearRegisterAllocationOffsets): + (JSC::AbstractMacroAssembler::checkRegisterAllocationAgainstBranchRange): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::allocate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-03-14 Oliver Hunt <oliver@apple.com> + + REGRESSION(r145000): Crash loading arstechnica.com when Safari Web Inspector is open + https://bugs.webkit.org/show_bug.cgi?id=111868 + + Reviewed by Antti Koivisto. + + Don't allow non-local property lookup when the debugger is enabled. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::resolve): + +2013-03-11 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Objective-C functions exposed to JavaScript have the wrong type (object instead of function) + https://bugs.webkit.org/show_bug.cgi?id=105892 + + Reviewed by Geoffrey Garen. + + Changed ObjCCallbackFunction to subclass JSCallbackFunction which already has all of the machinery to call + functions using the C API. Since ObjCCallbackFunction is now a JSCell, we changed the old implementation of + ObjCCallbackFunction to be the internal implementation and keep track of all the proper data so that we + don't have to put all of that in the header, which will now be included from C++ files (e.g. JSGlobalObject.cpp). + + * API/JSCallbackFunction.cpp: Change JSCallbackFunction to allow subclassing. Originally it was internally + passing its own Structure up the chain of constructors, but we now want to be able to pass other Structures as well. + (JSC::JSCallbackFunction::JSCallbackFunction): + (JSC::JSCallbackFunction::create): + * API/JSCallbackFunction.h: + (JSCallbackFunction): + * API/JSWrapperMap.mm: Changed interface to tryUnwrapBlock. + (tryUnwrapObjcObject): + * API/ObjCCallbackFunction.h: + (ObjCCallbackFunction): Moved into the JSC namespace, just like JSCallbackFunction. + (JSC::ObjCCallbackFunction::createStructure): Overridden so that the correct ClassInfo gets used since we have + a destructor. + (JSC::ObjCCallbackFunction::impl): Getter for the internal impl. + * API/ObjCCallbackFunction.mm: + (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): What used to be ObjCCallbackFunction is now + ObjCCallbackFunctionImpl. It handles the Objective-C specific parts of managing callback functions. + (JSC::ObjCCallbackFunctionImpl::~ObjCCallbackFunctionImpl): + (JSC::objCCallbackFunctionCallAsFunction): Same as the old one, but now it casts to ObjCCallbackFunction and grabs the impl + rather than using JSObjectGetPrivate. + (JSC::ObjCCallbackFunction::ObjCCallbackFunction): New bits to allow being part of the JSCell hierarchy. + (JSC::ObjCCallbackFunction::create): + (JSC::ObjCCallbackFunction::destroy): + (JSC::ObjCCallbackFunctionImpl::call): Handles the actual invocation, just like it used to. + (objCCallbackFunctionForInvocation): + (tryUnwrapBlock): Changed to check the ClassInfo for inheritance directly, rather than going through the C API call. + * API/tests/testapi.mm: Added new test to make sure that doing Function.prototype.toString.call(f) won't result in + an error when f is an Objective-C method or block underneath the covers. + * runtime/JSGlobalObject.cpp: Added new Structure for ObjCCallbackFunction. + (JSC::JSGlobalObject::reset): + (JSC::JSGlobalObject::visitChildren): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::objcCallbackFunctionStructure): + +2013-03-14 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Nested dictionaries are not converted properly in the Objective-C binding + https://bugs.webkit.org/show_bug.cgi?id=112377 + + Reviewed by Oliver Hunt. + + Accidental reassignment of the root task in the container conversion logic was causing the last + array or dictionary processed to be returned in the case of nested containers. + + * API/JSValue.mm: + (containerValueToObject): + * API/tests/testapi.mm: + +2013-03-13 Filip Pizlo <fpizlo@apple.com> + + JSObject fast by-string access optimizations should work even on the prototype chain, and even when the result is undefined + https://bugs.webkit.org/show_bug.cgi?id=112233 + + Reviewed by Oliver Hunt. + + Extended the existing fast access path for String keys to work over the entire prototype chain, + not just the self access case. This will fail as soon as it sees an object that intercepts + getOwnPropertySlot, so this patch also ensures that ObjectPrototype does not fall into that + category. This is accomplished by making ObjectPrototype eagerly reify all of its properties. + This is safe for ObjectPrototype because it's so common and we expect all of its properties to + be reified for any interesting programs anyway. A new idiom for adding native functions to + prototypes is introduced, which ought to work well for any other prototypes that we wish to do + this conversion for. + + This is a >60% speed-up in the case that you frequently do by-string lookups that "miss", i.e. + they don't turn up anything. + + * CMakeLists.txt: + * DerivedSources.make: + * DerivedSources.pri: + * GNUmakefile.list.am: + * dfg/DFGOperations.cpp: + * interpreter/CallFrame.h: + (JSC::ExecState::objectConstructorTable): + * jit/JITStubs.cpp: + (JSC::getByVal): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::getByVal): + * runtime/CommonIdentifiers.h: + * runtime/JSCell.cpp: + (JSC::JSCell::getByStringSlow): + (JSC): + * runtime/JSCell.h: + (JSCell): + * runtime/JSCellInlines.h: + (JSC): + (JSC::JSCell::getByStringAndKey): + (JSC::JSCell::getByString): + * runtime/JSGlobalData.cpp: + (JSC): + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::~JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSObject.cpp: + (JSC::JSObject::putDirectNativeFunction): + (JSC): + * runtime/JSObject.h: + (JSObject): + (JSC): + * runtime/Lookup.cpp: + (JSC::setUpStaticFunctionSlot): + * runtime/ObjectPrototype.cpp: + (JSC): + (JSC::ObjectPrototype::finishCreation): + (JSC::ObjectPrototype::create): + * runtime/ObjectPrototype.h: + (ObjectPrototype): + * runtime/PropertyMapHashTable.h: + (JSC::PropertyTable::findWithString): + * runtime/Structure.h: + (Structure): + * runtime/StructureInlines.h: + (JSC::Structure::get): + (JSC): + +2013-03-13 Filip Pizlo <fpizlo@apple.com> + + DFG bytecode parser is too aggressive about getting rid of GetLocals on captured variables + https://bugs.webkit.org/show_bug.cgi?id=112287 + <rdar://problem/13342340> + + Reviewed by Oliver Hunt. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecode): + (JSC::CodeBlock::finalizeUnconditionally): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getLocal): + +2013-03-13 Ryosuke Niwa <rniwa@webkit.org> + + Threaded HTML Parser is missing feature define flags in all but Chromium port's build files + https://bugs.webkit.org/show_bug.cgi?id=112277 + + Reviewed by Adam Barth. + + * Configurations/FeatureDefines.xcconfig: + +2013-03-13 Csaba Osztrogonác <ossy@webkit.org> + + LLINT C loop warning fix for GCC + https://bugs.webkit.org/show_bug.cgi?id=112145 + + Reviewed by Filip Pizlo. + + * llint/LowLevelInterpreter.cpp: + (JSC::CLoop::execute): + +2013-02-13 Simon Hausmann <simon.hausmann@digia.com> + + Add support for convenient conversion from JSStringRef to QString + https://bugs.webkit.org/show_bug.cgi?id=109694 + + Reviewed by Allan Sandfeld Jensen. + + Add JSStringCopyQString helper function that allows for the convenient + extraction of a QString out of a JSStringRef. + + * API/JSStringRefQt.cpp: Added. + (JSStringCopyQString): + * API/JSStringRefQt.h: Added. + * API/OpaqueJSString.h: + (OpaqueJSString): + (OpaqueJSString::qString): + (OpaqueJSString::OpaqueJSString): + * Target.pri: + +2013-03-13 Peter Gal <galpeter@inf.u-szeged.hu> + + Token 'not' is ignored in the offlineasm. + https://bugs.webkit.org/show_bug.cgi?id=111568 + + Reviewed by Filip Pizlo. + + * offlineasm/parser.rb: Build the Not AST node if the 'not' token is found. + +2013-03-12 Tim Horton <timothy_horton@apple.com> + + WTF uses macros for exports. Try to fix the Windows build. Unreviewed. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-03-12 Filip Pizlo <fpizlo@apple.com> + + Array.prototype.sort should at least try to be PTIME even when the array is in some bizarre mode + https://bugs.webkit.org/show_bug.cgi?id=112187 + <rdar://problem/13393550> + + Reviewed by Michael Saboff and Gavin Barraclough. + + If we have an array-like object in crazy mode passed into Array.prototype.sort, and its length is large, + then first copy all elements into a separate, compact, un-holy array and sort that. Then copy back. + This means that sorting will be at worst O(n^2) in the actual number of things in the array, rather than + O(n^2) in the array's length. + + * runtime/ArrayPrototype.cpp: + (JSC::attemptFastSort): + (JSC::performSlowSort): + (JSC): + (JSC::arrayProtoFuncSort): + +2013-03-12 Tim Horton <timothy_horton@apple.com> + + Try to fix the Windows build. + + Not reviewed. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + +2013-03-12 Geoffrey Garen <ggaren@apple.com> + + Try to fix the Windows build. + + Not reviewed. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + Export a thing. + +2013-03-11 Oliver Hunt <oliver@apple.com> + + Harden JSStringJoiner + https://bugs.webkit.org/show_bug.cgi?id=112093 + + Reviewed by Filip Pizlo. + + Harden JSStringJoiner, make it use our CheckedArithmetic + class to simplify everything. + + * runtime/JSStringJoiner.cpp: + (JSC::JSStringJoiner::build): + * runtime/JSStringJoiner.h: + (JSStringJoiner): + (JSC::JSStringJoiner::JSStringJoiner): + (JSC::JSStringJoiner::append): + +2013-03-12 Filip Pizlo <fpizlo@apple.com> + + DFG generic array access cases should not be guarded by CheckStructure even of the profiling tells us that it could be + https://bugs.webkit.org/show_bug.cgi?id=112183 + + Reviewed by Oliver Hunt. + + Slight speed-up on string-unpack-code. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::findAndRemoveUnnecessaryStructureCheck): + (FixupPhase): + (JSC::DFG::FixupPhase::checkArray): + (JSC::DFG::FixupPhase::blessArrayOperation): + +2013-03-12 Gabor Rapcsanyi <rgabor@webkit.org> + + https://bugs.webkit.org/show_bug.cgi?id=112141 + LLInt CLoop backend misses Double2Ints() on 32bit architectures + + Reviewed by Filip Pizlo. + + Implement Double2Ints() in CLoop backend of LLInt on 32bit architectures. + + * llint/LowLevelInterpreter.cpp: + (LLInt): + (JSC::LLInt::Double2Ints): + * offlineasm/cloop.rb: + +2013-03-12 Gabor Rapcsanyi <rgabor@webkit.org> + + Making more sophisticated cache flush on ARM Linux platform + https://bugs.webkit.org/show_bug.cgi?id=111854 + + Reviewed by Zoltan Herczeg. + + The cache flush on ARM Linux invalidates whole pages + instead of just the required area. + + * assembler/ARMAssembler.h: + (ARMAssembler): + (JSC::ARMAssembler::linuxPageFlush): + (JSC::ARMAssembler::cacheFlush): + * assembler/ARMv7Assembler.h: + (ARMv7Assembler): + (JSC::ARMv7Assembler::linuxPageFlush): + (JSC::ARMv7Assembler::cacheFlush): + +2013-03-12 Gabor Rapcsanyi <rgabor@webkit.org> + + Renaming the armv7.rb LLINT backend to arm.rb + https://bugs.webkit.org/show_bug.cgi?id=110565 + + Reviewed by Zoltan Herczeg. + + This is the first step of a unified ARM backend for + all ARM 32 bit architectures in LLInt. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * LLIntOffsetsExtractor.pro: + * offlineasm/arm.rb: Copied from Source/JavaScriptCore/offlineasm/armv7.rb. + * offlineasm/armv7.rb: Removed. + * offlineasm/backends.rb: + * offlineasm/risc.rb: + +2013-03-12 Csaba Osztrogonác <ossy@webkit.org> + + REGRESSION(r145482): It broke 33 jsc tests and zillion layout tests on all platform + https://bugs.webkit.org/show_bug.cgi?id=112112 + + Reviewed by Oliver Hunt. + + Rolling out https://trac.webkit.org/changeset/145482 to unbreak the bots. + + * runtime/JSStringJoiner.cpp: + (JSC::JSStringJoiner::build): + * runtime/JSStringJoiner.h: + (JSStringJoiner): + (JSC::JSStringJoiner::JSStringJoiner): + (JSC::JSStringJoiner::append): + +2013-03-12 Filip Pizlo <fpizlo@apple.com> + + DFG prediction propagation phase should not rerun forward propagation if double voting has already converged + https://bugs.webkit.org/show_bug.cgi?id=111920 + + Reviewed by Oliver Hunt. + + I don't know why we weren't exiting early after double voting if !m_changed. + + This change also removes backwards propagation from the voting fixpoint, since at that + point short-circuiting loops is probably not particularly profitable. Profiling shows + that this reduces the time spent in prediction propagation even further. + + This change appears to be a 1% SunSpider speed-up. + + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::run): + +2013-03-11 Filip Pizlo <fpizlo@apple.com> + + DFG overflow check elimination is too smart for its own good + https://bugs.webkit.org/show_bug.cgi?id=111832 + + Reviewed by Oliver Hunt and Gavin Barraclough. + + Rolling this back in after fixing accidental misuse of JSValue. The code was doing value < someInt + rather than value.asInt32() < someInt. This "worked" when isWithinPowerOfTwo wasn't templatized. + It worked by always being false and always disabling the relvant optimization. + + This improves overflow check elimination in three ways: + + 1) It reduces the amount of time the compiler will spend doing it. + + 2) It fixes bugs where overflow check elimination was overzealous. Precisely, for a binary operation + over @a and @b where both @a and @b will type check that their inputs (@a->children, @b->children) + are int32's and then perform a possibly-overflowing operation, we must be careful not to assume + that @a's non-int32 parts don't matter if at the point that @a runs we have as yet not proved that + @b->children are int32's and that hence @b might produce a large enough result that doubles would + start chopping low bits. The specific implication of this is that for a binary operation to not + propagate that it cares about non-int32 parts (NodeUsedAsNumber), we must prove that at least one + of the inputs is guaranteed to produce a result within 2^32 and that there won't be a tower of such + operations large enough to ultimately produce a double greater than 2^52 (roughly). We achieve the + latter by disabling this optimization for very large basic blocks. It's noteworthy that blocks that + large won't even make it into the DFG currently. + + 3) It makes the overflow check elimination more precise for cases where the inputs to an Add or Sub + are the outputs of a bit-op. For example in (@a + (@b | 0)) | 0, we don't need to propagate + NodeUsedAsNumber to either @a or @b. + + This is neutral on V8v7 and a slight speed-up on compile time benchmarks. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::refine): + * dfg/DFGBackwardsPropagationPhase.cpp: Added. + (DFG): + (BackwardsPropagationPhase): + (JSC::DFG::BackwardsPropagationPhase::BackwardsPropagationPhase): + (JSC::DFG::BackwardsPropagationPhase::run): + (JSC::DFG::BackwardsPropagationPhase::isNotNegZero): + (JSC::DFG::BackwardsPropagationPhase::isNotZero): + (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoForConstant): + (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoNonRecursive): + (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo): + (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags): + (JSC::DFG::BackwardsPropagationPhase::propagate): + (JSC::DFG::performBackwardsPropagation): + * dfg/DFGBackwardsPropagationPhase.h: Added. + (DFG): + * dfg/DFGCPSRethreadingPhase.cpp: + (JSC::DFG::CPSRethreadingPhase::run): + (JSC::DFG::CPSRethreadingPhase::clearIsLoadedFrom): + (CPSRethreadingPhase): + (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): + (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGNodeFlags.cpp: + (JSC::DFG::dumpNodeFlags): + (DFG): + * dfg/DFGNodeFlags.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (PredictionPropagationPhase): + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGUnificationPhase.cpp: + (JSC::DFG::UnificationPhase::run): + * dfg/DFGVariableAccessData.h: + (JSC::DFG::VariableAccessData::VariableAccessData): + (JSC::DFG::VariableAccessData::mergeIsLoadedFrom): + (VariableAccessData): + (JSC::DFG::VariableAccessData::setIsLoadedFrom): + (JSC::DFG::VariableAccessData::isLoadedFrom): + +2013-03-11 Oliver Hunt <oliver@apple.com> + + Harden JSStringJoiner + https://bugs.webkit.org/show_bug.cgi?id=112093 + + Reviewed by Filip Pizlo. + + Harden JSStringJoiner, make it use our CheckedArithmetic + class to simplify everything. + + * runtime/JSStringJoiner.cpp: + (JSC::JSStringJoiner::build): + * runtime/JSStringJoiner.h: + (JSStringJoiner): + (JSC::JSStringJoiner::JSStringJoiner): + (JSC::JSStringJoiner::append): + +2013-03-11 Michael Saboff <msaboff@apple.com> + + Crash beneath operationCreateInlinedArguments running fast/js/dfg-create-inlined-arguments-in-closure-inline.html (32-bit only) + https://bugs.webkit.org/show_bug.cgi?id=112067 + + Reviewed by Geoffrey Garen. + + We weren't setting the tag in SetCallee. Therefore set it to CellTag. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-03-11 Oliver Hunt <oliver@apple.com> + + Make SegmentedVector Noncopyable + https://bugs.webkit.org/show_bug.cgi?id=112059 + + Reviewed by Geoffrey Garen. + + Copying a SegmentedVector is very expensive, and really shouldn't + be necessary. So I've taken the one place where we currently copy + and replaced it with a regular Vector, and replaced the address + dependent logic with a indexing ref instead. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::newLabelScope): + (JSC::BytecodeGenerator::emitComplexJumpScopes): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/LabelScope.h: + (JSC): + (JSC::LabelScopePtr::LabelScopePtr): + (LabelScopePtr): + (JSC::LabelScopePtr::operator=): + (JSC::LabelScopePtr::~LabelScopePtr): + (JSC::LabelScopePtr::operator*): + (JSC::LabelScopePtr::operator->): + * bytecompiler/NodesCodegen.cpp: + (JSC::DoWhileNode::emitBytecode): + (JSC::WhileNode::emitBytecode): + (JSC::ForNode::emitBytecode): + (JSC::ForInNode::emitBytecode): + (JSC::SwitchNode::emitBytecode): + (JSC::LabelNode::emitBytecode): + +2013-03-10 Andreas Kling <akling@apple.com> + + SpeculativeJIT should use OwnPtr<SlowPathGenerator>. + <http://webkit.org/b/111942> + + Reviewed by Anders Carlsson. + + There's no need to include DFGSlowPathGenerator.h from the header as long as the destructor is out-of-line, + so let's use OwnPtr instead of raw pointers + deleteAllValues(). + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::~SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::addSlowPathGenerator): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + +2013-03-09 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r145299. + http://trac.webkit.org/changeset/145299 + https://bugs.webkit.org/show_bug.cgi?id=111928 + + compilation failure with recent clang + (DFGBackwardsPropagationPhase.cpp:132:35: error: comparison of + constant 10 with expression of type 'bool' is always false) + (Requested by thorton on #webkit). + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::refine): + * dfg/DFGBackwardsPropagationPhase.cpp: Removed. + * dfg/DFGBackwardsPropagationPhase.h: Removed. + * dfg/DFGCPSRethreadingPhase.cpp: + (JSC::DFG::CPSRethreadingPhase::run): + (CPSRethreadingPhase): + (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): + (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGNodeFlags.cpp: + (JSC::DFG::nodeFlagsAsString): + (DFG): + * dfg/DFGNodeFlags.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::isNotNegZero): + (PredictionPropagationPhase): + (JSC::DFG::PredictionPropagationPhase::isNotZero): + (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoForConstant): + (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoNonRecursive): + (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwo): + (JSC::DFG::PredictionPropagationPhase::propagate): + (JSC::DFG::PredictionPropagationPhase::mergeDefaultFlags): + * dfg/DFGUnificationPhase.cpp: + (JSC::DFG::UnificationPhase::run): + * dfg/DFGVariableAccessData.h: + (JSC::DFG::VariableAccessData::VariableAccessData): + (VariableAccessData): + +2013-03-08 Filip Pizlo <fpizlo@apple.com> + + DFG overflow check elimination is too smart for its own good + https://bugs.webkit.org/show_bug.cgi?id=111832 + + Reviewed by Oliver Hunt and Gavin Barraclough. + + This improves overflow check elimination in three ways: + + 1) It reduces the amount of time the compiler will spend doing it. + + 2) It fixes bugs where overflow check elimination was overzealous. Precisely, for a binary operation + over @a and @b where both @a and @b will type check that their inputs (@a->children, @b->children) + are int32's and then perform a possibly-overflowing operation, we must be careful not to assume + that @a's non-int32 parts don't matter if at the point that @a runs we have as yet not proved that + @b->children are int32's and that hence @b might produce a large enough result that doubles would + start chopping low bits. The specific implication of this is that for a binary operation to not + propagate that it cares about non-int32 parts (NodeUsedAsNumber), we must prove that at least one + of the inputs is guaranteed to produce a result within 2^32 and that there won't be a tower of such + operations large enough to ultimately produce a double greater than 2^52 (roughly). We achieve the + latter by disabling this optimization for very large basic blocks. It's noteworthy that blocks that + large won't even make it into the DFG currently. + + 3) It makes the overflow check elimination more precise for cases where the inputs to an Add or Sub + are the outputs of a bit-op. For example in (@a + (@b | 0)) | 0, we don't need to propagate + NodeUsedAsNumber to either @a or @b. + + This is neutral on V8v7 and a slight speed-up on compile time benchmarks. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::refine): + * dfg/DFGBackwardsPropagationPhase.cpp: Added. + (DFG): + (BackwardsPropagationPhase): + (JSC::DFG::BackwardsPropagationPhase::BackwardsPropagationPhase): + (JSC::DFG::BackwardsPropagationPhase::run): + (JSC::DFG::BackwardsPropagationPhase::isNotNegZero): + (JSC::DFG::BackwardsPropagationPhase::isNotZero): + (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoForConstant): + (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoNonRecursive): + (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo): + (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags): + (JSC::DFG::BackwardsPropagationPhase::propagate): + (JSC::DFG::performBackwardsPropagation): + * dfg/DFGBackwardsPropagationPhase.h: Added. + (DFG): + * dfg/DFGCPSRethreadingPhase.cpp: + (JSC::DFG::CPSRethreadingPhase::run): + (JSC::DFG::CPSRethreadingPhase::clearIsLoadedFrom): + (CPSRethreadingPhase): + (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): + (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGNodeFlags.cpp: + (JSC::DFG::dumpNodeFlags): + (DFG): + * dfg/DFGNodeFlags.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (PredictionPropagationPhase): + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGUnificationPhase.cpp: + (JSC::DFG::UnificationPhase::run): + * dfg/DFGVariableAccessData.h: + (JSC::DFG::VariableAccessData::VariableAccessData): + (JSC::DFG::VariableAccessData::mergeIsLoadedFrom): + (VariableAccessData): + (JSC::DFG::VariableAccessData::setIsLoadedFrom): + (JSC::DFG::VariableAccessData::isLoadedFrom): + +2013-03-08 Roger Fong <roger_fong@apple.com> + + Makefile fixes. + + * JavaScriptCore.vcxproj/JavaScriptCore.make: + +2013-03-08 Gabor Rapcsanyi <rgabor@webkit.org> + + Cache flush problem on ARMv7 JSC + https://bugs.webkit.org/show_bug.cgi?id=111441 + + Reviewed by Zoltan Herczeg. + + Not proper cache flush causing random crashes on ARMv7 Linux with V8 tests. + The problem is similar to https://bugs.webkit.org/show_bug.cgi?id=77712. + Change the cache fulsh mechanism similar to ARM traditinal and revert the + temporary fix. + + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::cacheFlush): + +2013-03-07 Geoffrey Garen <ggaren@apple.com> + + REGRESSION (r143759): 40% JSBench regression, 20% Octane/closure regression, 40% Octane/jquery regression, 2% Octane regression + https://bugs.webkit.org/show_bug.cgi?id=111797 + + Reviewed by Oliver Hunt. + + The bot's testing configuration stresses the cache's starting guess + of 1MB. + + This patch removes any starting guess, and just uses wall clock time + to discover the initial working set size of an app, in code size. + + * runtime/CodeCache.cpp: + (JSC::CodeCacheMap::pruneSlowCase): Update our timer as we go. + + Also fixed a bug where pruning from 0 to 0 would hang -- that case is + a possibility now that we start with a capacity of 0. + + * runtime/CodeCache.h: + (CodeCacheMap): + (JSC::CodeCacheMap::CodeCacheMap): + (JSC::CodeCacheMap::add): + (JSC::CodeCacheMap::prune): Don't prune if we're in the middle of + discovering the working set size of an app, in code size. + +2013-03-07 Michael Saboff <msaboff@apple.com> + + Crash when updating predictions below JSC::arrayProtoFuncForEach on tuaw.com article + https://bugs.webkit.org/show_bug.cgi?id=111777 + + Reviewed by Filip Pizlo. + + Moved register allocations to be above any generated control flow so that any + resulting spill would be visible to all subsequently generated code. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::compile): + +2013-03-07 Filip Pizlo <fpizlo@apple.com> + + DFG should not get corrupted IR in the case of code that is dead, unreachable, and contains a chain of nodes that use each other in an untyped way + https://bugs.webkit.org/show_bug.cgi?id=111783 + + Reviewed by Mark Hahnenberg. + + Unreachable code is not touched by CFA and so thinks that even untyped uses are checked. + But dead untyped uses don't need checks and hence don't need to be Phantom'd. The DCE knew + this in findTypeCheckRoot() but not in eliminateIrrelevantPhantomChildren(), leading to a + Phantom node that had another Phantom node as one of its kids. + + * dfg/DFGDCEPhase.cpp: + (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren): + +2013-03-07 Filip Pizlo <fpizlo@apple.com> + + The DFG fixpoint is not strictly profitable, and should be straight-lined + https://bugs.webkit.org/show_bug.cgi?id=111764 + + Reviewed by Oliver Hunt and Geoffrey Garen. + + The DFG previously ran optimizations to fixpoint because there exists a circular dependency: + + CSE depends on CFG simplification: CFG simplification merges blocks, and CSE is block-local. + + CFG simplification depends on CFA and constant folding: constant folding reveals branches on + constants. + + CFA depends on CSE: CSE reveals must-alias relationships by proving that two operations + always produce identical values. + + Arguments simplification also depends on CSE, but it ought not depend on anything else. + + Hence we get a cycle like: CFA -> folding -> CFG -> CSE -> CFA. + + Note that before we had sparse conditional CFA, we also had CFA depending on CFG. This ought + not be the case anymore: CFG simplification should not by itself lead to better CFA results. + + My guess is that the weakest link in this cycle is CFG -> CSE. CSE cuts both ways: if you + CSE too much then you increase register pressure. Hence it's not clear that you always want + to CSE after simplifying control flow. This leads to an order of optimization as follows: + + CSE -> arguments -> CFA -> folding -> CFG + + This is a 2.5% speed-up on SunSpider, a 4% speed-up on V8Spider, a possible 0.3% slow-down + on V8v7, nothing on Kraken, and 1.2% speed-up in the JSRegress geomean. I'll take a 2.5% + speed-up over a 0.3% V8v7 speed-up. + + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + +2013-03-07 Roger Fong <roger_fong@apple.com> + + Build fix for AppleWin VS2010. + + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + +2013-03-05 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Need a good way to reference event handlers without causing cycles + https://bugs.webkit.org/show_bug.cgi?id=111088 + + Reviewed by Geoffrey Garen. + + JSManagedValue is like a special kind of weak value. When you create a JSManagedValue, you can + supply an Objective-C object as its "owner". As long as the Objective-C owner object remains + alive and its wrapper remains accessible to the JSC garbage collector (e.g. by being marked by + the global object), the reference to the JavaScript value is strong. As soon as the Objective-C + owner is deallocated or its wrapper becomes inaccessible to the garbage collector, the reference + becomes weak. + + If you do not supply an owner or you use the weakValueWithValue: convenience class method, the + returned JSManagedValue behaves as a normal weak reference. + + This new class allows clients to maintain references to JavaScript values in the Objective-C + heap without creating reference cycles/leaking memory. + + * API/JSAPIWrapperObject.cpp: Added. + (JSC): + (JSC::::createStructure): + (JSC::JSAPIWrapperObject::JSAPIWrapperObject): This is a special JSObject for the Objective-C API that knows + for the purposes of garbage collection/marking that it wraps an opaque Objective-C object. + (JSC::JSAPIWrapperObject::visitChildren): We add the pointer to the wrapped Objective-C object to the set of + opaque roots so that the weak handle owner for JSManagedValues can find it later. + * API/JSAPIWrapperObject.h: Added. + (JSC): + (JSAPIWrapperObject): + (JSC::JSAPIWrapperObject::wrappedObject): + (JSC::JSAPIWrapperObject::setWrappedObject): + * API/JSBase.cpp: + (JSSynchronousGarbageCollect): + * API/JSBasePrivate.h: + * API/JSCallbackObject.cpp: + (JSC): + * API/JSCallbackObject.h: + (JSC::JSCallbackObject::destroy): Moved this to the header so that we don't get link errors with JSAPIWrapperObject. + * API/JSContext.mm: + (-[JSContext initWithVirtualMachine:]): We weren't adding manually allocated/initialized JSVirtualMachine objects to + the global cache of virtual machines. The init methods handle this now rather than contextWithGlobalContextRef, since + not everyone is guaranteed to use the latter. + (-[JSContext initWithGlobalContextRef:]): + (+[JSContext contextWithGlobalContextRef:]): + * API/JSManagedValue.h: Added. + * API/JSManagedValue.mm: Added. + (JSManagedValueHandleOwner): + (managedValueHandleOwner): + (+[JSManagedValue weakValueWithValue:]): + (+[JSManagedValue managedValueWithValue:owner:]): + (-[JSManagedValue init]): We explicitly call the ARC entrypoints to initialize/get the weak owner field since we don't + use ARC when building our framework. + (-[JSManagedValue initWithValue:]): + (-[JSManagedValue initWithValue:owner:]): + (-[JSManagedValue dealloc]): + (-[JSManagedValue value]): + (-[JSManagedValue weakOwner]): + (JSManagedValueHandleOwner::isReachableFromOpaqueRoots): If the Objective-C owner is still alive (i.e. loading the weak field + returns non-nil) and that value was added to the set of opaque roots by the wrapper for that Objective-C owner, then the the + JSObject to which the JSManagedObject refers is still alive. + * API/JSObjectRef.cpp: We have to add explicit checks for the JSAPIWrapperObject, just like the other types of JSCallbackObjects. + (JSObjectGetPrivate): + (JSObjectSetPrivate): + (JSObjectGetPrivateProperty): + (JSObjectSetPrivateProperty): + (JSObjectDeletePrivateProperty): + * API/JSValue.mm: + (objectToValueWithoutCopy): + * API/JSValueRef.cpp: + (JSValueIsObjectOfClass): + * API/JSVirtualMachine.mm: + (-[JSVirtualMachine initWithContextGroupRef:]): + (+[JSVirtualMachine virtualMachineWithContextGroupRef:]): + * API/JSWrapperMap.mm: + (wrapperFinalize): + (makeWrapper): This is our own internal version of JSObjectMake which creates JSAPIWrapperObjects, the Obj-C API + version of JSCallbackObjects. + (createObjectWithCustomBrand): + (-[JSObjCClassInfo wrapperForObject:]): + (tryUnwrapObjcObject): + * API/JavaScriptCore.h: + * API/tests/testapi.mm: Added new tests for the strong and weak uses of JSManagedValue in the context of an + onclick handler for an Objective-C object inserted into a JSContext. + (-[TextXYZ setWeakOnclick:]): + (-[TextXYZ setOnclick:]): + (-[TextXYZ weakOnclick]): + (-[TextXYZ onclick]): + (-[TextXYZ click]): + * CMakeLists.txt: Various build system additions. + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * runtime/JSGlobalObject.cpp: Added the new canonical Structure for the JSAPIWrapperObject class. + (JSC::JSGlobalObject::reset): + (JSC): + (JSC::JSGlobalObject::visitChildren): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::objcWrapperObjectStructure): + +2013-03-06 Filip Pizlo <fpizlo@apple.com> + + ConvertThis should be turned into Identity based on predictions in Fixup, rather than based on proofs in ConstantFolding + https://bugs.webkit.org/show_bug.cgi?id=111674 + + Reviewed by Oliver Hunt. + + This gets rid of the speculated forms of ConvertThis in the backend, and has Fixup + convert them to either Identity(Object:@child) if the child is predicted object, or + Phantom(Other:@child) ; WeakJSConstant(global this object) if it's predicted Other. + + The goal of this is to ensure that the optimization fixpoint doesn't create + Identity's, since doing so requires a rerun of CSE. So far this isn't a speed-up + but I'm hoping this will be a step towards reducing the need to rerun the fixpoint + so as to ultimately reduce compile times. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::executeEffects): + * dfg/DFGAssemblyHelpers.h: + (AssemblyHelpers): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (FixupPhase): + (JSC::DFG::FixupPhase::observeUseKindOnNode): + (JSC::DFG::FixupPhase::setUseKindAndUnboxIfProfitable): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::globalThisObjectFor): + (Graph): + * dfg/DFGNode.h: + (Node): + (JSC::DFG::Node::convertToIdentity): + (JSC::DFG::Node::convertToWeakConstant): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-03-07 Peter Gal <galpeter@inf.u-szeged.hu> + + Children method in LLINT AST Not class should return [@child] + https://bugs.webkit.org/show_bug.cgi?id=90740 + + Reviewed by Filip Pizlo. + + * offlineasm/ast.rb: Fixed the return value of the children method in the Not AST class. + +2013-03-05 Oliver Hunt <oliver@apple.com> + + Bring back eager resolution of function scoped variables + https://bugs.webkit.org/show_bug.cgi?id=111497 + + Reviewed by Geoffrey Garen. + + This reverts the get/put_scoped_var part of the great non-local + variable resolution refactoring. This still leaves all the lazy + variable resolution logic as it's necessary for global property + resolution, and i don't want to make the patch bigger than it + already is. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecode): + (JSC::CodeBlock::CodeBlock): + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::generateFunctionCodeBlock): + (JSC::UnlinkedFunctionExecutable::codeBlockFor): + (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): + * bytecode/UnlinkedCodeBlock.h: + (JSC): + (UnlinkedFunctionExecutable): + (UnlinkedCodeBlock): + (JSC::UnlinkedCodeBlock::usesGlobalObject): + (JSC::UnlinkedCodeBlock::setGlobalObjectRegister): + (JSC::UnlinkedCodeBlock::globalObjectRegister): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::ResolveResult::checkValidity): + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::emitLoadGlobalObject): + (JSC): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::resolveConstDecl): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveBase): + (JSC::BytecodeGenerator::emitResolveBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetStaticVar): + (JSC::BytecodeGenerator::emitPutStaticVar): + * bytecompiler/BytecodeGenerator.h: + (JSC::ResolveResult::lexicalResolve): + (JSC::ResolveResult::isStatic): + (JSC::ResolveResult::depth): + (JSC::ResolveResult::index): + (ResolveResult): + (JSC::ResolveResult::ResolveResult): + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::ResolveNode::isPure): + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::PostfixNode::emitResolve): + (JSC::TypeOfResolveNode::emitBytecode): + (JSC::PrefixNode::emitResolve): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): + (JSC::ConstDeclNode::emitCodeSingle): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCapabilities.cpp: + (JSC::DFG::debugFail): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canInlineOpcode): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + * jit/JIT.h: + (JIT): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_scoped_var): + (JSC): + (JSC::JIT::emit_op_put_scoped_var): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_scoped_var): + (JSC): + (JSC::JIT::emit_op_put_scoped_var): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/CodeCache.cpp: + (JSC::CodeCache::getCodeBlock): + (JSC::CodeCache::getProgramCodeBlock): + (JSC::CodeCache::getEvalCodeBlock): + * runtime/CodeCache.h: + (JSC): + (CodeCache): + * runtime/Executable.cpp: + (JSC::EvalExecutable::compileInternal): + (JSC::FunctionExecutable::produceCodeBlockFor): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::createEvalCodeBlock): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + * runtime/Options.cpp: + (JSC::Options::initialize): + +2013-03-06 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, roll out http://trac.webkit.org/changeset/144989 + + I think we want the assertion that I removed. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::merge): + (JSC::DFG::AbstractState::mergeVariableBetweenBlocks): + * dfg/DFGAbstractState.h: + (AbstractState): + +2013-03-06 Filip Pizlo <fpizlo@apple.com> + + DFG::AbstractState::merge() is still more complicated than it needs to be + https://bugs.webkit.org/show_bug.cgi?id=111619 + + Reviewed by Mark Hahnenberg. + + This method is the one place where we still do some minimal amount of liveness pruning, but the style with + which it is written is awkward, and it makes an assertion about variablesAtTail that will be invalidated + by https://bugs.webkit.org/show_bug.cgi?id=111539. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::merge): + (JSC::DFG::AbstractState::mergeVariableBetweenBlocks): + * dfg/DFGAbstractState.h: + (AbstractState): + +2013-03-06 Filip Pizlo <fpizlo@apple.com> + + DFG should not run full CSE after the optimization fixpoint, since it really just wants store elimination + https://bugs.webkit.org/show_bug.cgi?id=111536 + + Reviewed by Oliver Hunt and Mark Hahnenberg. + + The fixpoint will do aggressive load elimination and pure CSE. There's no need to do it after the fixpoint. + On the other hand, the fixpoint does not profit from doing store elimination (except for SetLocal/Flush). + Previously we had CSE do both, and had it avoid doing some store elimination during the fixpoint by querying + the fixpoint state. This changes CSE to be templated on mode - either NormalCSE or StoreElimination - so + that we explicitly put it into one of those modes depending on where we call it from. The goal is to reduce + time spent doing load elimination after the fixpoint, since that is just wasted cycles. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::CSEPhase): + (JSC::DFG::CSEPhase::run): + (JSC::DFG::CSEPhase::performNodeCSE): + (JSC::DFG::CSEPhase::performBlockCSE): + (JSC::DFG::performCSE): + (DFG): + (JSC::DFG::performStoreElimination): + * dfg/DFGCSEPhase.h: + (DFG): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + +2013-03-06 Andreas Kling <akling@apple.com> + + Pack Structure members better. + <http://webkit.org/b/111593> + <rdar://problem/13359200> + + Reviewed by Mark Hahnenberg. + + Shrink Structure by 8 bytes (now at 104 bytes) on 64-bit by packing the members better. + + * runtime/Structure.cpp: + (JSC::Structure::Structure): + * runtime/Structure.h: + (Structure): + +2013-03-06 Andreas Kling <akling@apple.com> + + Unreviewed, fix Windows build after r144910. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + +2013-03-05 Filip Pizlo <fpizlo@apple.com> + + DFG should not check if nodes are shouldGenerate prior to DCE + https://bugs.webkit.org/show_bug.cgi?id=111520 + + Reviewed by Geoffrey Garen. + + All nodes are live before DCE. We don't need to check that they aren't, because they + definitely will be. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGCFAPhase.cpp: + (JSC::DFG::CFAPhase::performBlockCFA): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::keepOperandAlive): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::pureCSE): + (JSC::DFG::CSEPhase::int32ToDoubleCSE): + (JSC::DFG::CSEPhase::constantCSE): + (JSC::DFG::CSEPhase::weakConstantCSE): + (JSC::DFG::CSEPhase::getCalleeLoadElimination): + (JSC::DFG::CSEPhase::getArrayLengthElimination): + (JSC::DFG::CSEPhase::globalVarLoadElimination): + (JSC::DFG::CSEPhase::scopedVarLoadElimination): + (JSC::DFG::CSEPhase::globalVarWatchpointElimination): + (JSC::DFG::CSEPhase::globalVarStoreElimination): + (JSC::DFG::CSEPhase::scopedVarStoreElimination): + (JSC::DFG::CSEPhase::getByValLoadElimination): + (JSC::DFG::CSEPhase::checkStructureElimination): + (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): + (JSC::DFG::CSEPhase::putStructureStoreElimination): + (JSC::DFG::CSEPhase::getByOffsetLoadElimination): + (JSC::DFG::CSEPhase::putByOffsetStoreElimination): + (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::checkArrayElimination): + (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::getMyScopeLoadElimination): + (JSC::DFG::CSEPhase::getLocalLoadElimination): + (JSC::DFG::CSEPhase::setLocalStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::fixupSetLocalsInBlock): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2013-03-06 Csaba Osztrogonác <ossy@webkit.org> + + Fix unused parameter warnings in ARM assembler + https://bugs.webkit.org/show_bug.cgi?id=111433 + + Reviewed by Kentaro Hara. + + * assembler/ARMAssembler.h: Remove unreachable revertJump() after r143346. + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::moveIntsToDouble): Remove unused scratch parameter instead of UNUSED_PARAM. + (JSC::MacroAssemblerARM::branchConvertDoubleToInt32): Remove unused fpTemp parameter. + (JSC::MacroAssemblerARM::revertJumpReplacementToPatchableBranchPtrWithPatch): Remove unused parameters. + +2013-03-06 Andreas Kling <akling@apple.com> + + Unused Structure property tables waste 14MB on Membuster. + <http://webkit.org/b/110854> + <rdar://problem/13292104> + + Reviewed by Geoffrey Garen. + + Turn PropertyTable into a GC object and have Structure drop unpinned tables when marking. + 14 MB progression on Membuster3. + + This time it should stick; I've been through all the tests with COLLECT_ON_EVERY_ALLOCATION. + The issue with the last version was that Structure::m_offset could be used uninitialized + when re-materializing a previously GC'd property table, causing some sanity checks to fail. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + + Added PropertyTable.cpp. + + * runtime/PropertyTable.cpp: Added. + (JSC::PropertyTable::create): + (JSC::PropertyTable::clone): + (JSC::PropertyTable::PropertyTable): + (JSC::PropertyTable::destroy): + (JSC::PropertyTable::~PropertyTable): + (JSC::PropertyTable::visitChildren): + + Moved marking of property table values here from Structure::visitChildren(). + + * runtime/WriteBarrier.h: + (JSC::WriteBarrierBase::get): + + Move m_cell to a local before using it multiple times. This avoids a multiple-access race when + Structure::checkOffsetConsistency() is used in assertions on the main thread while a marking thread + zaps the property table. + + * runtime/Structure.h: + (JSC::Structure::materializePropertyMapIfNecessary): + (JSC::Structure::materializePropertyMapIfNecessaryForPinning): + * runtime/StructureInlines.h: + (JSC::Structure::propertyTable): + + Added a getter for the Structure's PropertyTable that ASSERTs GC currently isn't active. + Because GC can zap an unpinned property table at any time, it's not entirely safe to access it. + Renamed the variable itself to m_propertyTableUnsafe to force call sites into explaining themselves. + + (JSC::Structure::putWillGrowOutOfLineStorage): + (JSC::Structure::checkOffsetConsistency): + + Moved these out of Structure.h to break header dependency cycle between Structure/PropertyTable. + + * runtime/Structure.cpp: + (JSC::Structure::visitChildren): + + Null out m_propertyTable if the table is unpinned. This'll cause the table to get GC'd. + + (JSC::Structure::takePropertyTableOrCloneIfPinned): + + Added for setting up the property table in a new transition, this code is now shared between + addPropertyTransition() and nonPropertyTransition(). + + * runtime/JSGlobalData.h: + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + + Add a global propertyTableStructure. + + * runtime/PropertyMapHashTable.h: + (PropertyTable): + (JSC::PropertyTable::createStructure): + (JSC::PropertyTable::copy): + + Make PropertyTable a GC object. + + * runtime/Structure.cpp: + (JSC::Structure::dumpStatistics): + (JSC::Structure::materializePropertyMap): + (JSC::Structure::despecifyDictionaryFunction): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::changePrototypeTransition): + (JSC::Structure::despecifyFunctionTransition): + (JSC::Structure::attributeChangeTransition): + (JSC::Structure::toDictionaryTransition): + (JSC::Structure::sealTransition): + (JSC::Structure::freezeTransition): + (JSC::Structure::preventExtensionsTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::isSealed): + (JSC::Structure::isFrozen): + (JSC::Structure::flattenDictionaryStructure): + (JSC::Structure::pin): + (JSC::Structure::copyPropertyTable): + (JSC::Structure::copyPropertyTableForPinning): + (JSC::Structure::get): + (JSC::Structure::despecifyFunction): + (JSC::Structure::despecifyAllFunctions): + (JSC::Structure::putSpecificValue): + (JSC::Structure::remove): + (JSC::Structure::createPropertyMap): + (JSC::Structure::getPropertyNamesFromStructure): + (JSC::Structure::checkConsistency): + +2013-03-05 Filip Pizlo <fpizlo@apple.com> + + Get rid of the invert argument to SpeculativeJIT::jumpSlowForUnwantedArrayMode + https://bugs.webkit.org/show_bug.cgi?id=105624 + + Reviewed by Oliver Hunt. + + All callers pass invert = false, which is the default value of the argument. So, get + rid of the argument and fold away all code that checks it. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + +2013-03-05 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, fix an incorrect comment. The comment was a holdover from a work-in-progress version of this code. + + * dfg/DFGDCEPhase.cpp: + (JSC::DFG::DCEPhase::run): + +2013-03-04 Filip Pizlo <fpizlo@apple.com> + + DFG DCE might eliminate checks unsoundly + https://bugs.webkit.org/show_bug.cgi?id=109389 + + Reviewed by Oliver Hunt. + + This gets rid of all eager reference counting, and does all dead code elimination + in one phase - the DCEPhase. This phase also sets up the node reference counts, + which are then used not just for DCE but also register allocation and stack slot + allocation. + + Doing this required a number of surgical changes in places that previously relied + on always having liveness information. For example, the structure check hoisting + phase must now consult whether a VariableAccessData is profitable for unboxing to + make sure that it doesn't try to do hoisting on set SetLocals. The arguments + simplification phase employs its own light-weight liveness analysis. Both phases + previously just used reference counts. + + The largest change is that now, dead nodes get turned into Phantoms. Those + Phantoms will retain those child edges that are not proven. This ensures that any + type checks performed by a dead node remain even after the node is killed. On the + other hand, this Phantom conversion means that we need special handling for + SetLocal. I decided to make the four forms of SetLocal explicit: + + MovHint(@a, rK): Just indicates that node @a contains the value that would have + now been placed into virtual register rK. Does not actually cause @a to be + stored into rK. This would have previously been a dead SetLocal with @a + being live. MovHints are always dead. + + ZombieHint(rK): Indicates that at this point, register rK will contain a dead + value and OSR should put Undefined into it. This would have previously been + a dead SetLocal with @a being dead also. ZombieHints are always dead. + + MovHintAndCheck(@a, rK): Identical to MovHint except @a is also type checked, + according to whatever UseKind the edge to @a has. The type check is always a + forward exit. MovHintAndChecks are always live, since they are + NodeMustGenerate. Previously this would have been a dead SetLocal with a + live @a, and the check would have disappeared. This is one of the bugs that + this patch solves. + + SetLocal(@a, rK): This still does exactly what it does now, if the SetLocal is + live. + + Basically this patch makes it so that dead SetLocals eventually decay to MovHint, + ZombieHint, or MovHintAndCheck depending on the situation. If the child @a is + also dead, then you get a ZombieHint. If the child @a is live but the SetLocal + has a type check and @a's type hasn't been proven to have that type then you get + a MovHintAndCheck. Otherwise you get a MovHint. + + This is performance neutral. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::executeEffects): + (JSC::DFG::AbstractState::mergeStateAtTail): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (ArgumentsSimplificationPhase): + (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): + * dfg/DFGBasicBlock.h: + (BasicBlock): + * dfg/DFGBasicBlockInlines.h: + (DFG): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::addToGraph): + (JSC::DFG::ByteCodeParser::insertPhiNode): + (JSC::DFG::ByteCodeParser::emitFunctionChecks): + * dfg/DFGCFAPhase.cpp: + (JSC::DFG::CFAPhase::run): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::keepOperandAlive): + * dfg/DFGCPSRethreadingPhase.cpp: + (JSC::DFG::CPSRethreadingPhase::run): + (JSC::DFG::CPSRethreadingPhase::addPhiSilently): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren): + (JSC::DFG::CSEPhase::setReplacement): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCommon.cpp: + (WTF::printInternal): + (WTF): + * dfg/DFGCommon.h: + (WTF): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck): + (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode): + * dfg/DFGDCEPhase.cpp: Added. + (DFG): + (DCEPhase): + (JSC::DFG::DCEPhase::DCEPhase): + (JSC::DFG::DCEPhase::run): + (JSC::DFG::DCEPhase::findTypeCheckRoot): + (JSC::DFG::DCEPhase::countEdge): + (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren): + (JSC::DFG::performDCE): + * dfg/DFGDCEPhase.h: Added. + (DFG): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::checkArray): + (JSC::DFG::FixupPhase::blessArrayOperation): + (JSC::DFG::FixupPhase::fixIntEdge): + (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): + (JSC::DFG::FixupPhase::truncateConstantToInt32): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::Graph): + (JSC::DFG::Graph::dump): + (DFG): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::changeChild): + (JSC::DFG::Graph::changeEdge): + (JSC::DFG::Graph::compareAndSwap): + (JSC::DFG::Graph::clearAndDerefChild): + (JSC::DFG::Graph::performSubstitution): + (JSC::DFG::Graph::performSubstitutionForEdge): + (Graph): + (JSC::DFG::Graph::substitute): + * dfg/DFGInsertionSet.h: + (InsertionSet): + * dfg/DFGNode.h: + (JSC::DFG::Node::Node): + (JSC::DFG::Node::convertToConstant): + (JSC::DFG::Node::convertToGetLocalUnlinked): + (JSC::DFG::Node::containsMovHint): + (Node): + (JSC::DFG::Node::hasVariableAccessData): + (JSC::DFG::Node::willHaveCodeGenOrOSR): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + (JSC::DFG::SpeculativeJIT::compileMovHint): + (JSC::DFG::SpeculativeJIT::compileMovHintAndCheck): + (DFG): + (JSC::DFG::SpeculativeJIT::compileInlineStart): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + (JSC::DFG::StructureCheckHoistingPhase::shouldConsiderForHoisting): + (StructureCheckHoistingPhase): + * dfg/DFGValidate.cpp: + (JSC::DFG::Validate::validate): + +2013-03-05 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: JSValue should implement init and return nil in exceptional cases + https://bugs.webkit.org/show_bug.cgi?id=111487 + + Reviewed by Darin Adler. + + * API/JSValue.mm: + (-[JSValue init]): We return nil here because there is no way to get the instance into a coherent state + without a JSContext. + (-[JSValue initWithValue:inContext:]): Similarly, we should also return nil here if either of the arguments is 0. + +2013-03-05 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r144708. + http://trac.webkit.org/changeset/144708 + https://bugs.webkit.org/show_bug.cgi?id=111447 + + random assertion crashes in inspector tests on qt+mac bots + (Requested by kling on #webkit). + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/PropertyMapHashTable.h: + (PropertyTable): + (JSC::PropertyTable::PropertyTable): + (JSC): + (JSC::PropertyTable::~PropertyTable): + (JSC::PropertyTable::copy): + * runtime/PropertyTable.cpp: Removed. + * runtime/Structure.cpp: + (JSC::Structure::dumpStatistics): + (JSC::Structure::materializePropertyMap): + (JSC::Structure::despecifyDictionaryFunction): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::changePrototypeTransition): + (JSC::Structure::despecifyFunctionTransition): + (JSC::Structure::attributeChangeTransition): + (JSC::Structure::toDictionaryTransition): + (JSC::Structure::sealTransition): + (JSC::Structure::freezeTransition): + (JSC::Structure::preventExtensionsTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::isSealed): + (JSC::Structure::isFrozen): + (JSC::Structure::flattenDictionaryStructure): + (JSC::Structure::pin): + (JSC::Structure::copyPropertyTable): + (JSC::Structure::copyPropertyTableForPinning): + (JSC::Structure::get): + (JSC::Structure::despecifyFunction): + (JSC::Structure::despecifyAllFunctions): + (JSC::Structure::putSpecificValue): + (JSC::Structure::remove): + (JSC::Structure::createPropertyMap): + (JSC::Structure::getPropertyNamesFromStructure): + (JSC::Structure::visitChildren): + (JSC::Structure::checkConsistency): + * runtime/Structure.h: + (JSC): + (JSC::Structure::putWillGrowOutOfLineStorage): + (JSC::Structure::materializePropertyMapIfNecessary): + (JSC::Structure::materializePropertyMapIfNecessaryForPinning): + (JSC::Structure::checkOffsetConsistency): + (Structure): + * runtime/StructureInlines.h: + (JSC::Structure::get): + * runtime/WriteBarrier.h: + (JSC::WriteBarrierBase::get): + +2013-03-05 David Kilzer <ddkilzer@apple.com> + + BUILD FIX (r144698): Only enable SPEECH_SYNTHESIS for Mac + <http://webkit.org/b/106742> + + Fixes the following build failures: + + Undefined symbols for architecture i386: + "__ZTVN7WebCore25PlatformSpeechSynthesizerE", referenced from: + __ZN7WebCore25PlatformSpeechSynthesizerC2EPNS_31PlatformSpeechSynthesizerClientE in PlatformSpeechSynthesizer.o + NOTE: a missing vtable usually means the first non-inline virtual member function has no definition. + "__ZN7WebCore25PlatformSpeechSynthesizer19initializeVoiceListEv", referenced from: + __ZN7WebCore25PlatformSpeechSynthesizerC2EPNS_31PlatformSpeechSynthesizerClientE in PlatformSpeechSynthesizer.o + ld: symbol(s) not found for architecture i386 + + * Configurations/FeatureDefines.xcconfig: + - Fix definition of ENABLE_ENCRYPTED_MEDIA_V2_macosx to match + other FeatureDefines.xcconfig files. + - Only set ENABLE_SPEECH_SYNTHESIS for the macosx platform. + +2013-03-04 Andreas Kling <akling@apple.com> + + Unused Structure property tables waste 14MB on Membuster. + <http://webkit.org/b/110854> + <rdar://problem/13292104> + + Reviewed by Geoffrey Garen. + + Turn PropertyTable into a GC object and have Structure drop unpinned tables when marking. + 14 MB progression on Membuster3. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + + Added PropertyTable.cpp. + + * runtime/PropertyTable.cpp: Added. + (JSC::PropertyTable::create): + (JSC::PropertyTable::clone): + (JSC::PropertyTable::PropertyTable): + (JSC::PropertyTable::destroy): + (JSC::PropertyTable::~PropertyTable): + (JSC::PropertyTable::visitChildren): + + Moved marking of property table values here from Structure::visitChildren(). + + * runtime/WriteBarrier.h: + (JSC::WriteBarrierBase::get): + + Move m_cell to a local before using it multiple times. This avoids a multiple-access race when + Structure::checkOffsetConsistency() is used in assertions on the main thread while a marking thread + zaps the property table. + + * runtime/Structure.h: + (JSC::Structure::materializePropertyMapIfNecessary): + (JSC::Structure::materializePropertyMapIfNecessaryForPinning): + * runtime/StructureInlines.h: + (JSC::Structure::propertyTable): + + Added a getter for the Structure's PropertyTable that ASSERTs GC currently isn't active. + Because GC can zap an unpinned property table at any time, it's not entirely safe to access it. + Renamed the variable itself to m_propertyTableUnsafe to force call sites into explaining themselves. + + (JSC::Structure::putWillGrowOutOfLineStorage): + (JSC::Structure::checkOffsetConsistency): + + Moved these out of Structure.h to break header dependency cycle between Structure/PropertyTable. + + * runtime/Structure.cpp: + (JSC::Structure::visitChildren): + + Null out m_propertyTable if the table is unpinned. This'll cause the table to get GC'd. + + * runtime/JSGlobalData.h: + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + + Add a global propertyTableStructure. + + * runtime/PropertyMapHashTable.h: + (PropertyTable): + (JSC::PropertyTable::createStructure): + (JSC::PropertyTable::copy): + + Make PropertyTable a GC object. + + * runtime/Structure.cpp: + (JSC::Structure::dumpStatistics): + (JSC::Structure::materializePropertyMap): + (JSC::Structure::despecifyDictionaryFunction): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::changePrototypeTransition): + (JSC::Structure::despecifyFunctionTransition): + (JSC::Structure::attributeChangeTransition): + (JSC::Structure::toDictionaryTransition): + (JSC::Structure::sealTransition): + (JSC::Structure::freezeTransition): + (JSC::Structure::preventExtensionsTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::isSealed): + (JSC::Structure::isFrozen): + (JSC::Structure::flattenDictionaryStructure): + (JSC::Structure::pin): + (JSC::Structure::copyPropertyTable): + (JSC::Structure::copyPropertyTableForPinning): + (JSC::Structure::get): + (JSC::Structure::despecifyFunction): + (JSC::Structure::despecifyAllFunctions): + (JSC::Structure::putSpecificValue): + (JSC::Structure::remove): + (JSC::Structure::createPropertyMap): + (JSC::Structure::getPropertyNamesFromStructure): + (JSC::Structure::checkConsistency): + +2013-03-04 Chris Fleizach <cfleizach@apple.com> + + Support WebSpeech - Speech Synthesis + https://bugs.webkit.org/show_bug.cgi?id=106742 + + Reviewed by Simon Fraser. + + Enable speech synthesis for the Mac. + + * Configurations/FeatureDefines.xcconfig: + +2013-03-04 Mark Hahnenberg <mhahnenberg@apple.com> + + Remove contextInternalContext from JSContextInternal.h + https://bugs.webkit.org/show_bug.cgi?id=111356 + + Reviewed by Geoffrey Garen. + + We don't need it any more since we have globalContextRef in JSContext. + + * API/JSContext.mm: + * API/JSContextInternal.h: + * API/JSValue.mm: + (+[JSValue valueWithBool:inContext:]): + (+[JSValue valueWithDouble:inContext:]): + (+[JSValue valueWithInt32:inContext:]): + (+[JSValue valueWithUInt32:inContext:]): + (+[JSValue valueWithNewObjectInContext:]): + (+[JSValue valueWithNewArrayInContext:]): + (+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]): + (+[JSValue valueWithNewErrorFromMessage:inContext:]): + (+[JSValue valueWithNullInContext:]): + (+[JSValue valueWithUndefinedInContext:]): + (-[JSValue toBool]): + (-[JSValue toDouble]): + (-[JSValue toNumber]): + (-[JSValue toString]): + (-[JSValue toDate]): + (-[JSValue toArray]): + (-[JSValue toDictionary]): + (-[JSValue valueForProperty:]): + (-[JSValue setValue:forProperty:]): + (-[JSValue deleteProperty:]): + (-[JSValue hasProperty:]): + (-[JSValue valueAtIndex:]): + (-[JSValue setValue:atIndex:]): + (-[JSValue isUndefined]): + (-[JSValue isNull]): + (-[JSValue isBoolean]): + (-[JSValue isNumber]): + (-[JSValue isString]): + (-[JSValue isObject]): + (-[JSValue isEqualToObject:]): + (-[JSValue isEqualWithTypeCoercionToObject:]): + (-[JSValue isInstanceOf:]): + (-[JSValue callWithArguments:]): + (-[JSValue constructWithArguments:]): + (-[JSValue invokeMethod:withArguments:]): + (valueToObject): + (objectToValueWithoutCopy): + (objectToValue): + (-[JSValue initWithValue:inContext:]): + (-[JSValue dealloc]): + (-[JSValue description]): + * API/JSWrapperMap.mm: + (createObjectWithCustomBrand): + (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): + (-[JSObjCClassInfo wrapperForObject:]): + (-[JSWrapperMap jsWrapperForObject:]): + * API/ObjCCallbackFunction.mm: + (ObjCCallbackFunction::call): + (objCCallbackFunctionForInvocation): + +2013-03-04 Andreas Kling <akling@apple.com> + + Add simple vector traits for JSC::Identifier. + <http://webkit.org/b/111323> + + Reviewed by Geoffrey Garen. + + Identifiers are really just Strings, giving them simple vector traits makes + Vector move them with memcpy() instead of churning the refcounts. + + * runtime/Identifier.h: + (WTF): + +2013-03-04 Kunihiko Sakamoto <ksakamoto@chromium.org> + + Add build flag for FontLoader + https://bugs.webkit.org/show_bug.cgi?id=111289 + + Reviewed by Benjamin Poulain. + + Add ENABLE_FONT_LOAD_EVENTS build flag (disabled by default). + + * Configurations/FeatureDefines.xcconfig: + +2013-03-03 Andreas Kling <akling@apple.com> + + Shrink JSC::HashTable entries. + <http://webkit.org/b/111275> + <rdar://problem/13333511> + + Reviewed by Anders Carlsson. + + Move the Intrinsic value out of the function-specific part of the union, + and store it next to m_attributes. Reduces the size of HashEntry by 8 bytes. + + 990 kB progression on Membuster3. (PTUS: 797 kB) + + * runtime/Lookup.h: + (JSC::HashEntry::initialize): + (JSC::HashEntry::intrinsic): + (HashEntry): + +2013-03-01 David Kilzer <ddkilzer@apple.com> + + BUILD FIX: testapi should link to Foundation, not CoreFoundation + + * JavaScriptCore.xcodeproj/project.pbxproj: Change testapi to + link to Foundation.framework instead of CoreFoundation.framework + since it uses NS types. + +2013-03-01 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Passing JS functions to Objective-C callbacks causes JSValue to leak + https://bugs.webkit.org/show_bug.cgi?id=107836 + + Reviewed by Oliver Hunt. + + We've decided to remove support for this feature from the API because there's no way to automatically manage + the memory for clients in a satisfactory manner. Clients can still pass JS functions to Objective-C methods, + but the methods must accept plain JSValues instead of Objective-C blocks. + + We now ignore functions that are part of a protocol that inherits from JSExport that accept blocks as arguments. + + * API/JSBlockAdaptor.h: Removed. + * API/JSBlockAdaptor.mm: Removed. + * API/ObjCCallbackFunction.mm: + (ArgumentTypeDelegate::typeBlock): Return nil to signal that we want to ignore this function when copying it + to the object from the protocol. + * API/tests/testapi.mm: Added a test to make sure that we ignore methods declared as part of a JSExport-ed protocol + that have block arguments. + (-[TestObject bogusCallback:]): + * JavaScriptCore.gypi: Updated build files. + * JavaScriptCore.xcodeproj/project.pbxproj: + +2013-03-01 Filip Pizlo <fpizlo@apple.com> + + DFG Branch(LogicalNot) peephole should not try to optimize and work-around the case where LogicalNot may be otherwise live + https://bugs.webkit.org/show_bug.cgi?id=111209 + + Reviewed by Oliver Hunt. + + Even if it is then everything will work just fine. It's not necessary to check the ref count here. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + +2013-03-01 Filip Pizlo <fpizlo@apple.com> + + DFG CSE phase shouldn't rely on ref count of nodes, since it doesn't have to + https://bugs.webkit.org/show_bug.cgi?id=111205 + + Reviewed by Oliver Hunt. + + I don't understand the intuition behind setLocalStoreElimination() validating that the SetLocal's ref count + is 1. I believe this is a hold-over from when setLocalStoreElimination() would match one SetLocal to another, + and then try to eliminate the first SetLocal. But that's not how it works now. Now, setLocalStoreElimination() + is actually Flush elimination: it eliminates any Flush that anchors a SetLocal if it proves that every path + from the SetLocal to the Flush is devoid of operations that may observe the local. It doesn't actually kill + the SetLocal itself: if the SetLocal is live because of other things (other Flushes or GetLocals in other + basic blocks), then the SetLocal will naturally still be alive because th Flush was only keeping the SetLocal + alive by one count rather than being solely responsible for its liveness. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::setLocalStoreElimination): + (JSC::DFG::CSEPhase::eliminate): + (JSC::DFG::CSEPhase::performNodeCSE): + +2013-03-01 Filip Pizlo <fpizlo@apple.com> + + Rename MovHint to MovHintEvent so I can create a NodeType called MovHint + + Rubber stamped by Mark Hahnenberg. + + This is similar to the SetLocal/SetLocalEvent naming scheme, where SetLocal is the + NodeType and SetLocalEvent is the VariableEventKind. + + * dfg/DFGVariableEvent.cpp: + (JSC::DFG::VariableEvent::dump): + * dfg/DFGVariableEvent.h: + (JSC::DFG::VariableEvent::movHint): + (JSC::DFG::VariableEvent::id): + (JSC::DFG::VariableEvent::operand): + (VariableEvent): + * dfg/DFGVariableEventStream.cpp: + (JSC::DFG::VariableEventStream::reconstruct): + +2013-03-01 Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> + + [JSC] Fix sign comparison warning/error after r144340. + https://bugs.webkit.org/show_bug.cgi?id=111164 + + Reviewed by Mark Hahnenberg. + + gcc (both 4.2.1 and 4.7.2) complain about comparing signed and + unsigned terms (clang accepts it just fine). + + Work around that by casting the 1 to an uintptr_t as well. + + * dfg/DFGEdge.h: + (JSC::DFG::Edge::makeWord): + +2013-02-28 Filip Pizlo <fpizlo@apple.com> + + DFG CFA should not do liveness pruning + https://bugs.webkit.org/show_bug.cgi?id=111119 + + Reviewed by Mark Hahnenberg. + + It adds complexity and probably buys nothing. Moreover, I'm transitioning to having + liveness only available at the bitter end of compilation, so this will stop working + after https://bugs.webkit.org/show_bug.cgi?id=109389 anyway. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + (JSC::DFG::AbstractState::mergeStateAtTail): + +2013-02-28 Filip Pizlo <fpizlo@apple.com> + + Don't try to emit profiling if you don't have the DFG JIT. + + Rubber stamped by Mark Hahnenberg. + + * jit/JIT.h: + (JSC::JIT::shouldEmitProfiling): + +2013-02-28 Filip Pizlo <fpizlo@apple.com> + + DFG Phantom node should be honest about the fact that it can exit + https://bugs.webkit.org/show_bug.cgi?id=111115 + + Reviewed by Mark Hahnenberg. + + The chances of this having cause serious issues are low, since most clients of the + NodeDoesNotExit flag run after CFA and CFA updates this properly. But one possible + case of badness is if the ByteCodeParser inserted a Phantom with a type check in + between a LogicalNot and a Branch; then that peephole optimization in Fixup might + go slightly wrong. + + * dfg/DFGNodeType.h: + (DFG): + +2013-02-28 Mark Hahnenberg <mhahnenberg@apple.com> + + Add casts in DFGGPRInfo.h to suppress warnings + https://bugs.webkit.org/show_bug.cgi?id=111104 + + Reviewed by Filip Pizlo. + + With certain flags on, we get compiler warnings on ARM. We should do the proper casts to make these warnings go away. + + * dfg/DFGGPRInfo.h: + (JSC::DFG::GPRInfo::toIndex): + (JSC::DFG::GPRInfo::debugName): + +2013-02-28 Filip Pizlo <fpizlo@apple.com> + + It should be easy to determine if a DFG node exits forward or backward when doing type checks + https://bugs.webkit.org/show_bug.cgi?id=111102 + + Reviewed by Mark Hahnenberg. + + This adds a NodeExitsForward flag, which tells you the exit directionality of + type checks performed by the node. Even if you convert the node to a Phantom + and use the Edge UseKind for type checks, you'll still get the same exit + directionality that the original node would have wanted. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGArrayifySlowPathGenerator.h: + (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + * dfg/DFGCPSRethreadingPhase.cpp: + (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::setReplacement): + (JSC::DFG::CSEPhase::eliminate): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::checkArray): + * dfg/DFGNode.h: + (Node): + (JSC::DFG::Node::setOpAndDefaultNonExitFlags): + (JSC::DFG::Node::convertToPhantom): + * dfg/DFGNodeFlags.cpp: + (JSC::DFG::nodeFlagsAsString): + * dfg/DFGNodeFlags.h: + (DFG): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::backwardSpeculationCheck): + (DFG): + (JSC::DFG::SpeculativeJIT::speculationCheck): + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + (JSC::DFG::SpeculativeJIT::backwardTypeCheck): + (JSC::DFG::SpeculativeJIT::typeCheck): + (JSC::DFG::SpeculativeJIT::forwardTypeCheck): + (JSC::DFG::SpeculativeJIT::fillStorage): + (JSC::DFG::SpeculativeJIT::compile): + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculateIntegerOperand::SpeculateIntegerOperand): + (JSC::DFG::SpeculateIntegerOperand::gpr): + (SpeculateIntegerOperand): + (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand): + (JSC::DFG::SpeculateDoubleOperand::fpr): + (SpeculateDoubleOperand): + (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand): + (JSC::DFG::SpeculateCellOperand::gpr): + (SpeculateCellOperand): + (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand): + (JSC::DFG::SpeculateBooleanOperand::gpr): + (SpeculateBooleanOperand): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateInt): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateInt): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + +2013-02-28 Filip Pizlo <fpizlo@apple.com> + + CodeBlock::valueProfile() has a bogus assertion + https://bugs.webkit.org/show_bug.cgi?id=111106 + <rdar://problem/13131427> + + Reviewed by Mark Hahnenberg. + + This was just a bad assertion: m_bytecodeOffset == -1 means that the value profile is constructed but not initialized. + ValueProfile constructs itself in a safe way; you can call any method you want on a constructed but not initialized + ValueProfile. CodeBlock first constructs all ValueProfiles (by growing the ValueProfile vector) and then initializes + their m_bytecodeOffset later. This is necessary because the initialization is linking bytecode instructions to their + ValueProfiles, so at that point we don't want the ValueProfile vector to resize, which implies that we want all of + them to already be constructed. A GC can happen during this phase, and the GC may want to walk all ValueProfiles. + This is safe, but one of the ValueProfile getters (CodeBlock::valueProfile()) was asserting that any value profile + you get has had its m_bytecodeOffset initialized. This need not be the case and nothing will go wrong if it isn't. + + The solution is to remove the assertion, which I believe was put there to ensure that my m_valueProfiles refactoring + a long time ago was sound: it used to be that a ValueProfile with m_bytecodeOffset == -1 was an argument profile; now + all argument profiles are in m_argumentValueProfiles instead. I think it's safe to say that this refactoring was done + soundly since it was a long time ago. So we should kill the assertion - I don't see an easy way to make the assertion + sound with respect to the GC-during-CodeBlock-construction issue, and I don't believe that the assertion is buying us + anything at this point. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::valueProfile): + +2013-02-27 Filip Pizlo <fpizlo@apple.com> + + DFG CFA should leave behind information in Edge that says if the Edge's type check is proven to succeed + https://bugs.webkit.org/show_bug.cgi?id=110840 + + Reviewed by Mark Hahnenberg. + + This doesn't add any observable functionality to the compiler, yet. But it does give + every phase that runs after CFA the ability to know, in O(1) time, whether an edge + will need to execute a type check. + + * dfg/DFGAbstractState.h: + (JSC::DFG::AbstractState::filterEdgeByUse): + (JSC::DFG::AbstractState::filterByType): + * dfg/DFGCommon.cpp: + (WTF): + (WTF::printInternal): + * dfg/DFGCommon.h: + (JSC::DFG::isProved): + (DFG): + (JSC::DFG::proofStatusForIsProved): + (WTF): + * dfg/DFGEdge.cpp: + (JSC::DFG::Edge::dump): + * dfg/DFGEdge.h: + (JSC::DFG::Edge::Edge): + (JSC::DFG::Edge::setNode): + (JSC::DFG::Edge::useKindUnchecked): + (JSC::DFG::Edge::setUseKind): + (Edge): + (JSC::DFG::Edge::proofStatusUnchecked): + (JSC::DFG::Edge::proofStatus): + (JSC::DFG::Edge::setProofStatus): + (JSC::DFG::Edge::isProved): + (JSC::DFG::Edge::needsCheck): + (JSC::DFG::Edge::shift): + (JSC::DFG::Edge::makeWord): + +2013-02-28 Simon Hausmann <simon.hausmann@digia.com> + + [Qt][Mac] Fix massive parallel builds + + Reviewed by Tor Arne Vestbø. + + There exists a race condition that LLIntDesiredOffsets.h is written to + by two parllel instances of the ruby script. This patch ensures that similar to the output file, + the generated file is also prefixed according to the build configuration. + + * LLIntOffsetsExtractor.pro: + +2013-02-27 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r144168. + http://trac.webkit.org/changeset/144168 + https://bugs.webkit.org/show_bug.cgi?id=111019 + + It broke the build and tronical is unavailable (Requested by + Ossy_night on #webkit). + + * LLIntOffsetsExtractor.pro: + +2013-02-26 Filip Pizlo <fpizlo@apple.com> + + Disable some unsound DFG DCE + https://bugs.webkit.org/show_bug.cgi?id=110948 + + Reviewed by Michael Saboff. + + DCE of bitops is not sound since the bitops might call some variant of valueOf. + + This used to work right because ValueToInt32 was MustGenerate. From the DFG IR + standpoint it feels weird to make ValueToInt32 be MustGenerate since that node is + implemented entirely as a pure conversion. If we ever gave the DFG the ability to + do effectful bitops, we would most likely implement them as special nodes not + related to the ValueToInt32 and bitop nodes we have now. + + This change is performance neutral. + + * dfg/DFGNodeType.h: + (DFG): + +2013-02-27 Glenn Adams <glenn@skynav.com> + + Add ENABLE_CSS3_TEXT_LINE_BREAK flag. + https://bugs.webkit.org/show_bug.cgi?id=110944 + + Reviewed by Dean Jackson. + + * Configurations/FeatureDefines.xcconfig: + +2013-02-27 Julien Brianceau <jbrianceau@nds.com> + + Fix build when DFG_JIT is not enabled + https://bugs.webkit.org/show_bug.cgi?id=110991 + + Reviewed by Csaba Osztrogonác. + + * jit/JIT.h: + (JSC::JIT::canBeOptimizedOrInlined): + +2013-02-27 Simon Hausmann <simon.hausmann@digia.com> + + [Qt][Mac] Fix massive parallel builds + + Reviewed by Tor Arne Vestbø. + + There exists a race condition that LLIntDesiredOffsets.h is written to + by two parllel instances of the ruby script. This patch ensures that similar to the output file, + the generated file is also prefixed according to the build configuration. + + * LLIntOffsetsExtractor.pro: + +2013-02-26 Filip Pizlo <fpizlo@apple.com> + + DFG OSR exit doesn't know which virtual register to use for the last result register for post_inc and post_dec + https://bugs.webkit.org/show_bug.cgi?id=109036 + <rdar://problem/13292139> + + Reviewed by Gavin Barraclough. + + This was a two-fold problem: + + 1) post_inc/dec has two results - the new value of the variable, and the old value of the variable. DFG OSR exit + assumed that the "last result" used for the Baseline JIT's register allocation would be the new value. It was + wrong in this assumption. + + 2) The Baseline JIT knew to disable its last result optimization in cases where it might confuse the DFG. But it + was doing this only for code blocks that could be totally optimized, but not code blocks that could only be + optimized when inlined. + + This patch introduces a more rigorous notion of when the Baseline JIT emits profiling, when it does extra work + to account for the possibility of OSR exit, and when it does extra work to account for the possibility of OSR + entry. These notions are called shouldEmitProfiling(), canBeOptimizedOrInlined(), and canBeOptimized(), + respectively. + + This is performance-neutral and fixes the reported bug. It probably fixes other bugs as well, since previously + we for example weren't doing the more conservative implementation of op_mov in the Baseline JIT for code blocks + that could be inlined but not optimized. So, if such a code block OSR exited at just the right point, you'd get + symptoms similar to this bug. + + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * dfg/DFGCommon.h: + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + * jit/JIT.h: + (JSC::JIT::compilePatchGetArrayLength): + (JSC::JIT::canBeOptimizedOrInlined): + (JIT): + * jit/JITArithmetic.cpp: + (JSC::JIT::emit_op_post_inc): + (JSC::JIT::emit_op_post_dec): + * jit/JITArithmetic32_64.cpp: + (JSC::JIT::emit_op_post_inc): + (JSC::JIT::emit_op_post_dec): + * jit/JITCall.cpp: + (JSC::JIT::emit_op_call_put_result): + (JSC::JIT::compileOpCall): + * jit/JITCall32_64.cpp: + (JSC::JIT::compileOpCall): + * jit/JITInlines.h: + (JSC::JIT::emitArrayProfilingSite): + (JSC::JIT::map): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_mov): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::privateCompilePutByIdTransition): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::privateCompilePutByIdTransition): + +2013-02-26 Roger Fong <roger_fong@apple.com> + + Unreviewed. AppleWin VS2010 build fix. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-02-25 Filip Pizlo <fpizlo@apple.com> + + The DFG backend's and OSR's decision to unbox a variable should be based on whether it's used in a typed context + https://bugs.webkit.org/show_bug.cgi?id=110433 + + Reviewed by Oliver Hunt and Mark Hahnenberg. + + This introduces the equivalent of a liveness analysis, except for type checking. + A variable is said to be "profitable for unboxing" (i.e. live at a type check) + if there exists a type check on a GetLocal of that variable, and the type check + is consistent with the variable's prediction. Variables that are not profitable + for unboxing aren't unboxed. Previously they would have been. + + This is a slight speed-up on some things but mostly neutral. + + * dfg/DFGArgumentPosition.h: + (JSC::DFG::ArgumentPosition::ArgumentPosition): + (JSC::DFG::ArgumentPosition::mergeShouldNeverUnbox): + (JSC::DFG::ArgumentPosition::mergeArgumentPredictionAwareness): + (JSC::DFG::ArgumentPosition::mergeArgumentUnboxingAwareness): + (ArgumentPosition): + (JSC::DFG::ArgumentPosition::isProfitableToUnbox): + (JSC::DFG::ArgumentPosition::shouldUseDoubleFormat): + * dfg/DFGCommon.h: + (JSC::DFG::checkAndSet): + (DFG): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::run): + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::fixupSetLocalsInBlock): + (FixupPhase): + (JSC::DFG::FixupPhase::alwaysUnboxSimplePrimitives): + (JSC::DFG::FixupPhase::setUseKindAndUnboxIfProfitable): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + * dfg/DFGVariableAccessData.h: + (JSC::DFG::VariableAccessData::VariableAccessData): + (JSC::DFG::VariableAccessData::mergeIsCaptured): + (JSC::DFG::VariableAccessData::mergeIsProfitableToUnbox): + (VariableAccessData): + (JSC::DFG::VariableAccessData::isProfitableToUnbox): + (JSC::DFG::VariableAccessData::shouldUnboxIfPossible): + (JSC::DFG::VariableAccessData::mergeStructureCheckHoistingFailed): + (JSC::DFG::VariableAccessData::mergeIsArgumentsAlias): + (JSC::DFG::VariableAccessData::shouldUseDoubleFormat): + (JSC::DFG::VariableAccessData::mergeFlags): + +2013-02-26 Oliver Hunt <oliver@apple.com> + + Fix windows build. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + +2013-02-26 Oliver Hunt <oliver@apple.com> + + Web Inspector: REGRESSION: [JSC] SourceProvider reuses IDs + https://bugs.webkit.org/show_bug.cgi?id=99674 + + Reviewed by Gavin Barraclough. + + Simple incrementing counter for SourceProvider IDs. Uses a + lock to incrementing the counter so we don't increment reuse + counter values or reassign the ID for a given SourceProvider. + + * parser/SourceProvider.cpp: + (JSC::SourceProvider::SourceProvider): + (JSC): + (JSC::SourceProvider::getID): + * parser/SourceProvider.h: + (JSC::SourceProvider::asID): + (SourceProvider): + +2013-02-26 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r144074. + http://trac.webkit.org/changeset/144074 + https://bugs.webkit.org/show_bug.cgi?id=110897 + + Causing 20+ crashes on Mac (Requested by bradee-oh on + #webkit). + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/PropertyMapHashTable.h: + (PropertyTable): + (JSC::PropertyTable::PropertyTable): + (JSC): + (JSC::PropertyTable::~PropertyTable): + (JSC::PropertyTable::copy): + * runtime/PropertyTable.cpp: Removed. + * runtime/Structure.cpp: + (JSC::Structure::materializePropertyMap): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::changePrototypeTransition): + (JSC::Structure::despecifyFunctionTransition): + (JSC::Structure::attributeChangeTransition): + (JSC::Structure::toDictionaryTransition): + (JSC::Structure::preventExtensionsTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::copyPropertyTable): + (JSC::Structure::copyPropertyTableForPinning): + (JSC::Structure::putSpecificValue): + (JSC::Structure::createPropertyMap): + (JSC::Structure::visitChildren): + * runtime/Structure.h: + (JSC): + (JSC::Structure::putWillGrowOutOfLineStorage): + (JSC::Structure::checkOffsetConsistency): + (Structure): + * runtime/StructureInlines.h: + +2013-02-26 Roger Fong <roger_fong@apple.com> + + Unreviewed. AppleWin VS2010 build fix. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: + +2013-02-26 Jer Noble <jer.noble@apple.com> + + Unreviewed build fix; use correct macro for platform name in FeatureDefines.xcconfig. + + * Configurations/FeatureDefines.xcconfig: + +2013-02-26 Michael Saboff <msaboff@apple.com> + + Potential crash in YARR JIT generated code when building 64 bit + https://bugs.webkit.org/show_bug.cgi?id=110893 + + Reviewed by Gavin Barraclough. + + The ABI doesn't define the behavior for the upper bits of a value that takes less than 64 bits. + Therefore, we zero extend both the count and length registers to assure that these unsigned values + don't have garbage upper bits. + + * yarr/YarrJIT.cpp: + (JSC::Yarr::YarrGenerator::generateEnter): + +2013-02-26 Andreas Kling <akling@apple.com> + + Unused Structure property tables waste 14MB on Membuster. + <http://webkit.org/b/110854> + <rdar://problem/13292104> + + Reviewed by Filip Pizlo. + + Turn PropertyTable into a GC object and have Structure drop unpinned tables when marking. + 14 MB progression on Membuster3. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + + Added PropertyTable.cpp. + + * runtime/PropertyTable.cpp: Added. + (JSC::PropertyTable::create): + (JSC::PropertyTable::clone): + (JSC::PropertyTable::PropertyTable): + (JSC::PropertyTable::destroy): + (JSC::PropertyTable::~PropertyTable): + (JSC::PropertyTable::visitChildren): + + Moved marking of property table values here from Structure::visitChildren(). + + * runtime/StructureInlines.h: + (JSC::Structure::putWillGrowOutOfLineStorage): + (JSC::Structure::checkOffsetConsistency): + + Moved these to StructureInlines.h to break header dependency cycle between Structure/PropertyTable. + + * runtime/Structure.cpp: + (JSC::Structure::visitChildren): + + Null out m_propertyTable if the table is unpinned. This'll cause the table to get GC'd. + + (JSC::Structure::materializePropertyMap): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::changePrototypeTransition): + (JSC::Structure::despecifyFunctionTransition): + (JSC::Structure::attributeChangeTransition): + (JSC::Structure::toDictionaryTransition): + (JSC::Structure::preventExtensionsTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::copyPropertyTable): + (JSC::Structure::copyPropertyTableForPinning): + (JSC::Structure::putSpecificValue): + (JSC::Structure::createPropertyMap): + * runtime/Structure.h: + (Structure): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/PropertyMapHashTable.h: + (PropertyTable): + (JSC::PropertyTable::createStructure): + (JSC::PropertyTable::copy): + +2013-02-26 Andreas Kling <akling@apple.com> + + Unreviewed, rolling out r144054. + http://trac.webkit.org/changeset/144054 + https://bugs.webkit.org/show_bug.cgi?id=110854 + + broke builds + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/PropertyMapHashTable.h: + (PropertyTable): + (JSC::PropertyTable::PropertyTable): + (JSC): + (JSC::PropertyTable::~PropertyTable): + (JSC::PropertyTable::copy): + * runtime/PropertyTable.cpp: Removed. + * runtime/Structure.cpp: + (JSC::Structure::materializePropertyMap): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::changePrototypeTransition): + (JSC::Structure::despecifyFunctionTransition): + (JSC::Structure::attributeChangeTransition): + (JSC::Structure::toDictionaryTransition): + (JSC::Structure::preventExtensionsTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::copyPropertyTable): + (JSC::Structure::copyPropertyTableForPinning): + (JSC::Structure::putSpecificValue): + (JSC::Structure::createPropertyMap): + (JSC::Structure::visitChildren): + * runtime/Structure.h: + (JSC): + (JSC::Structure::putWillGrowOutOfLineStorage): + (JSC::Structure::checkOffsetConsistency): + (Structure): + * runtime/StructureInlines.h: + +2013-02-26 Andreas Kling <akling@apple.com> + + Unused Structure property tables waste 14MB on Membuster. + <http://webkit.org/b/110854> + <rdar://problem/13292104> + + Reviewed by Filip Pizlo. + + Turn PropertyTable into a GC object and have Structure drop unpinned tables when marking. + 14 MB progression on Membuster3. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.gypi: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + + Added PropertyTable.cpp. + + * runtime/PropertyTable.cpp: Added. + (JSC::PropertyTable::create): + (JSC::PropertyTable::clone): + (JSC::PropertyTable::PropertyTable): + (JSC::PropertyTable::destroy): + (JSC::PropertyTable::~PropertyTable): + (JSC::PropertyTable::visitChildren): + + Moved marking of property table values here from Structure::visitChildren(). + + * runtime/StructureInlines.h: + (JSC::Structure::putWillGrowOutOfLineStorage): + (JSC::Structure::checkOffsetConsistency): + + Moved these to StructureInlines.h to break header dependency cycle between Structure/PropertyTable. + + * runtime/Structure.cpp: + (JSC::Structure::visitChildren): + + Null out m_propertyTable if the table is unpinned. This'll cause the table to get GC'd. + + (JSC::Structure::materializePropertyMap): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::changePrototypeTransition): + (JSC::Structure::despecifyFunctionTransition): + (JSC::Structure::attributeChangeTransition): + (JSC::Structure::toDictionaryTransition): + (JSC::Structure::preventExtensionsTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::copyPropertyTable): + (JSC::Structure::copyPropertyTableForPinning): + (JSC::Structure::putSpecificValue): + (JSC::Structure::createPropertyMap): + * runtime/Structure.h: + (Structure): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/PropertyMapHashTable.h: + (PropertyTable): + (JSC::PropertyTable::createStructure): + (JSC::PropertyTable::copy): + +2013-02-26 Jocelyn Turcotte <jocelyn.turcotte@digia.com> + + Implement JIT on Windows 64 bits + https://bugs.webkit.org/show_bug.cgi?id=107965 + + Reviewed by Simon Hausmann. + + 1. MSVC doesn't support inline assembly for 64 bits, implements the trampoline in a separate ASM file. + + 2. Windows 64 bits has a different calling convention than other OSes following the AMD64 ABI. + Differences that we have to handle here: + - Registers passed parameters are RCX, RDX, R8 and R9 instead of RDI, RSI, RDX, RCX, R8 and R9 + - RDI and RSI must be preserved by callee + - Only return values <= 8 bytes can be returned by register (RDX can't be used to return a second word) + - There is no red-zone after RIP on the stack, but instead 4 reserved words before it + + * Target.pri: + * jit/JITStubs.cpp: + * jit/JITStubs.h: + (JSC): + (JITStackFrame): + (JSC::JITStackFrame::returnAddressSlot): + * jit/JITStubsMSVC64.asm: Added. + * jit/JSInterfaceJIT.h: + (JSInterfaceJIT): + * jit/ThunkGenerators.cpp: + (JSC::nativeForGenerator): + * yarr/YarrJIT.cpp: + (YarrGenerator): + (JSC::Yarr::YarrGenerator::generateEnter): + (JSC::Yarr::YarrGenerator::generateReturn): + +2013-02-26 Oliver Hunt <oliver@apple.com> + + Kill another analyzer warning in javascriptcore + https://bugs.webkit.org/show_bug.cgi?id=110802 + + Reviewed by Benjamin Poulain. + + Add null checks. + + * profiler/LegacyProfiler.cpp: + (JSC::LegacyProfiler::startProfiling): + (JSC::LegacyProfiler::stopProfiling): + +2013-02-26 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r144004. + http://trac.webkit.org/changeset/144004 + https://bugs.webkit.org/show_bug.cgi?id=110858 + + This iOS change is outdated (Requested by notbenjamin on + #webkit). + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + * bytecompiler/BytecodeGenerator.h: + (JSC::BytecodeGenerator::emitNode): + (JSC::BytecodeGenerator::emitNodeInConditionContext): + (BytecodeGenerator): + * parser/Parser.cpp: + (JSC::::Parser): + * parser/Parser.h: + (JSC::Parser::canRecurse): + (Parser): + +2013-02-25 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r143654): some jquery test asserts on 32 bit debug build + https://bugs.webkit.org/show_bug.cgi?id=110756 + + Reviewed by Geoffrey Garen. + + TypeOf does speculations manually, so it should mark its JSValueOperand as doing ManualOperandSpeculation. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-02-25 Benjamin Poulain <bpoulain@apple.com> + + [JSC] Upstream iOS Stack bound checking + https://bugs.webkit.org/show_bug.cgi?id=110813 + + Reviewed by Filip Pizlo. + + On iOS, the StackBounds cannot be cached because the stack + can be in one of two threads (the web thread or the UI thread). + + We simply always consider the current stack bound when testing + stack boundaries. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + * bytecompiler/BytecodeGenerator.h: + (JSC::BytecodeGenerator::emitNode): + (JSC::BytecodeGenerator::emitNodeInConditionContext): + (BytecodeGenerator): + * parser/Parser.cpp: + (JSC::::Parser): + * parser/Parser.h: + (JSC::Parser::canRecurse): + (Parser): + +2013-02-25 Michael Saboff <msaboff@apple.com> + + For JSVALUE32_64, maxOffsetRelativeToPatchedStorage() doesn't compute the maximum negative offset + https://bugs.webkit.org/show_bug.cgi?id=110828 + + Reviewed by Oliver Hunt. + + * runtime/JSObject.h: + (JSC::maxOffsetRelativeToPatchedStorage): Only add the OBJECT_OFFSETOF(tag) for positive offsets. + That way this function will return the offset farthest from 0 needed to access either the payload + or tag. + +2013-02-25 Jeffrey Pfau <jpfau@apple.com> + + Optionally partition cache to prevent using cache for tracking + https://bugs.webkit.org/show_bug.cgi?id=110269 + + Reviewed by Maciej Stachowiak. + + * Configurations/FeatureDefines.xcconfig: Add defines for cache partitioning and public suffix list usage + +2013-02-25 Roger Fong <roger_fong@apple.com> + + Unreviewed. VS2010 solution build fix. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: + +2013-02-24 Filip Pizlo <fpizlo@apple.com> + + DFG::Edge should have more bits for UseKind, and DFG::Allocator should be simpler + https://bugs.webkit.org/show_bug.cgi?id=110722 + + Reviewed by Oliver Hunt. + + This rolls out the DFG::Allocator part of http://trac.webkit.org/changeset/143654, + and changes Edge to have more room for UseKinds and possibly other things. + + This is performance-neutral on both 32-bit and 64-bit. It reduces the size of + DFG::Node on 64-bit (by virtue of getting rid of the 16-byte alignment of Node) + and increases it slightly on 32-bit (by 4 bytes total - 16-byte alignment led to + 80 bytes, but the base size of Node plus the 12 bytes of new m_encodedWords in + Edge gets 84 bytes). But, it will mean that we don't have to increase Node by + another 16 bytes if we ever want to add more UseKinds or other things to Edge. + + * dfg/DFGAllocator.h: + (DFG): + (Allocator): + (JSC::DFG::Allocator::Region::headerSize): + (JSC::DFG::Allocator::Region::numberOfThingsPerRegion): + (JSC::DFG::Allocator::Region::data): + (JSC::DFG::Allocator::Region::isInThisRegion): + (JSC::DFG::::Allocator): + (JSC::DFG::::~Allocator): + (JSC::DFG::::allocate): + (JSC::DFG::::free): + (JSC::DFG::::freeAll): + (JSC::DFG::::reset): + (JSC::DFG::::indexOf): + (JSC::DFG::::allocatorOf): + (JSC::DFG::::bumpAllocate): + (JSC::DFG::::freeListAllocate): + (JSC::DFG::::allocateSlow): + (JSC::DFG::::freeRegionsStartingAt): + (JSC::DFG::::startBumpingIn): + * dfg/DFGEdge.h: + (JSC::DFG::Edge::Edge): + (Edge): + (JSC::DFG::Edge::node): + (JSC::DFG::Edge::setNode): + (JSC::DFG::Edge::useKindUnchecked): + (JSC::DFG::Edge::setUseKind): + (JSC::DFG::Edge::operator==): + (JSC::DFG::Edge::operator!=): + (JSC::DFG::Edge::makeWord): + * dfg/DFGNodeAllocator.h: + (DFG): + +2013-02-22 Filip Pizlo <fpizlo@apple.com> + + The DFG special case checks for isCreatedThisArgument are fragile + https://bugs.webkit.org/show_bug.cgi?id=110535 + + Reviewed by Oliver Hunt. + + There may be many situations in which we want to force a variable to never be + unboxed. Capturing is one such case, and the created this argument is another. + Previously all code that dealt with this issue had to query both scenarios. + + Now DFG::VariableAccessData knows these things. You just have to ask + VariableAccessData for whether a variable should be unboxed. Anyone wishing to + force a variable to never be unboxed just tells VariableAccessData. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + (DFG): + * dfg/DFGCFGSimplificationPhase.cpp: + (CFGSimplificationPhase): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGGraph.h: + (Graph): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGUnificationPhase.cpp: + (JSC::DFG::UnificationPhase::run): + * dfg/DFGVariableAccessData.h: + (JSC::DFG::VariableAccessData::VariableAccessData): + (JSC::DFG::VariableAccessData::mergeIsCaptured): + (JSC::DFG::VariableAccessData::mergeShouldNeverUnbox): + (VariableAccessData): + (JSC::DFG::VariableAccessData::shouldNeverUnbox): + (JSC::DFG::VariableAccessData::shouldUnboxIfPossible): + (JSC::DFG::VariableAccessData::shouldUseDoubleFormat): + (JSC::DFG::VariableAccessData::tallyVotesForShouldUseDoubleFormat): + +2013-02-25 Geoffrey Garen <ggaren@apple.com> + + Do one lookup per code cache insertion instead of two + https://bugs.webkit.org/show_bug.cgi?id=110674 + + Reviewed by Sam Weinig. + + Deployed the idiomatic "add null value" trick to avoid a second hash + lookup when inserting an item. + + * runtime/CodeCache.cpp: + (JSC::CodeCacheMap::pruneSlowCase): Factored this into a helper function + to improve clarity and get some code off the hot path. + + (JSC::CodeCache::getCodeBlock): + (JSC::CodeCache::getFunctionExecutableFromGlobalCode): Use the add() API + to avoid two hash lookups. Be sure to remove items if parsing fails, + otherwise we'll leave nulls in the table. (I'm guessing that caching parse + errors is not a win.) + + * runtime/CodeCache.h: + (JSC::SourceCodeValue::SourceCodeValue): + (CodeCacheMap): + (JSC::CodeCacheMap::add): Combined find() and set() into add(). + + (JSC::CodeCacheMap::remove): + (JSC::CodeCacheMap::age): + (JSC::CodeCacheMap::prune): Refactored to support above changes. + +2013-02-25 Carlos Garcia Campos <cgarcia@igalia.com> + + [BlackBerry][ARM] Fix cast-align warnings in JavaScriptCore + https://bugs.webkit.org/show_bug.cgi?id=110738 + + Reviewed by Rob Buis. + + Use reinterpret_cast_ptr instead of reinterpret_cast for + pointers. + + * dfg/DFGOperations.cpp: + * heap/CopiedBlock.h: + (JSC::CopiedBlock::zeroFillWilderness): + * heap/WeakBlock.h: + (JSC::WeakBlock::asWeakImpl): + (JSC::WeakBlock::asFreeCell): + (JSC::WeakBlock::weakImpls): + * heap/WeakImpl.h: + (JSC::WeakImpl::asWeakImpl): + * interpreter/JSStack.cpp: + (JSC::JSStack::disableErrorStackReserve): + * interpreter/JSStack.h: + (JSC::JSStack::reservationEnd): + * runtime/ArrayStorage.h: + (JSC::ArrayStorage::from): + * runtime/Butterfly.h: + (JSC::Butterfly::indexingPayload): + * runtime/IndexingHeader.h: + (JSC::IndexingHeader::propertyStorage): + * runtime/JSActivation.h: + (JSC::JSActivation::tearOff): + (JSC::JSActivation::isTornOff): + (JSC::JSActivation::storage): + +2013-02-22 Filip Pizlo <fpizlo@apple.com> + + DFG::SpeculativeJIT::speculateNumber() should just use SpeculateDoubleOperand instead of doing its own thing + https://bugs.webkit.org/show_bug.cgi?id=110659 + + Reviewed by Oliver Hunt and Mark Hahnenberg. + + This simplifies the code, and also has the effect that if speculateNumber() is called + prior to someone actually using the number in a double context, then the number will + already be up-converted to double and ready to go. + + Previously if this ever came up, the subsequent use would have to again branch to see + if the value is tagged as int or tagged as double. + + On the other hand, if you ever did speculateNumber() and then used the value as a + JSValue, this will be a slow down now. + + I suspect that the former (speculateNumber() and then use as number) is more likely + than the latter (speculateNumber() and then use as JSValue). + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::speculateNumber): + +2013-02-22 Filip Pizlo <fpizlo@apple.com> + + DFG FixupPhase should have one common hook for knowing if a node is ever being speculated a certain way + https://bugs.webkit.org/show_bug.cgi?id=110650 + + Reviewed by Mark Hahnenberg. + + Changes almost all calls to edge.setUseKind(kind) to be + setUseKindAndUnboxIfProfitable<kind>(edge). This will allow us to use the latter + as a hook for deciding which locals to unbox (webkit.org/b/110433). + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (FixupPhase): + (JSC::DFG::FixupPhase::setUseKindAndUnboxIfProfitable): + (JSC::DFG::FixupPhase::fixIntEdge): + (JSC::DFG::FixupPhase::fixDoubleEdge): + (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd): + +2013-02-22 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r143654): some fast/js test crashes on 32 bit build + https://bugs.webkit.org/show_bug.cgi?id=110590 + + Reviewed by Mark Hahnenberg. + + In compileValueToInt32, the refactoring in r143654 undid one of the fixes from + r143314 due to a merge goof. + + In speculateNumber, we were simply forgetting to indicate that we need a + ManualOperandSpeculation on a JSValueOperand. ManualOperandSpeculation should + be passed whenever you will be performing the type checks yourself rather than + using the operand class to do it for you. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + (JSC::DFG::SpeculativeJIT::speculateNumber): + +2013-02-22 Geoffrey Garen <ggaren@apple.com> + + Not reviewed. + + Fix the 32-bit build by using the right data type in more places. + + * runtime/CodeCache.h: + (CodeCacheMap): + +2013-02-22 Geoffrey Garen <ggaren@apple.com> + + Not reviewed. + + Fix the 32-bit build by using the right data type. + + * runtime/CodeCache.h: + (JSC::CodeCacheMap::find): + +2013-02-21 Geoffrey Garen <ggaren@apple.com> + + Code cache size should adapt to workload + https://bugs.webkit.org/show_bug.cgi?id=110560 + + Reviewed by Antti Koivisto. + + (*) 5% PLT arithmetic mean speedup + (*) 10% PLT geometric mean speedup + (*) 3.4X microbenchmark speedup + (*) Reduces initial cache capacity by 16X + + * runtime/CodeCache.cpp: + (JSC::CodeCache::CodeCache): Updated for interface change. + + * runtime/CodeCache.h: + (JSC::SourceCodeValue::SourceCodeValue): + (SourceCodeValue): Turned the cache value into a struct so it can track its age. + + (CodeCacheMap): + (JSC::CodeCacheMap::CodeCacheMap): + (JSC::CodeCacheMap::find): + (JSC::CodeCacheMap::set): + (JSC::CodeCacheMap::clear): + (JSC::CodeCacheMap::pruneIfNeeded): + (CodeCache): Grow and shrink in response to usage. + +2013-02-21 Jessie Berlin <jberlin@apple.com> + + Fix a typo that broke the 32 bit build. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-02-21 Michael Saboff <msaboff@apple.com> + + 25-30% regression in V8 RayTrace test in 32 bit builds with JIT disabled + https://bugs.webkit.org/show_bug.cgi?id=110539 + + Reviewed by Filip Pizlo. + + Change the scale used to lookup pointers in JSGlobalObject::m_specialPointers to be 4 bytes for + the 32 bit version of the interpreter. + + * llint/LowLevelInterpreter32_64.asm: + +2013-02-21 Roger Fong <roger_fong@apple.com> + + Unreviewed. Add executable property to cmd file. + Required for executable files to maintain their executable permissions over svn. + + * JavaScriptCore.vcxproj/copy-files.cmd: Added property svn:executable. + +2013-02-21 Filip Pizlo <fpizlo@apple.com> + + Object allocation profiling will refuse to create objects with more than JSFinalObject::maxInlineCapacity() inline slots, but JSFunction::allocationProfile() asserts that the number of inline slots is always what it asked for + https://bugs.webkit.org/show_bug.cgi?id=110519 + <rdar://problem/13218566> + + Reviewed by Geoffrey Garen. + + * runtime/JSFunction.h: + (JSC::JSFunction::allocationProfile): + +2013-02-21 Roger Fong <roger_fong@apple.com> + + Unreviewed. Build fix for VS2010 WebKit solution. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-02-20 Filip Pizlo <fpizlo@apple.com> + + DFG should not change its mind about what type speculations a node does, by encoding the checks in the NodeType, UseKind, and ArrayMode + https://bugs.webkit.org/show_bug.cgi?id=109371 + + Reviewed by Oliver Hunt. + + FixupPhase now locks in the speculations that each node will do. The DFG then + remembers those speculations, and doesn't change its mind about them even if the + graph is transformed - for example if a node's child is repointed to a different + node as part of CSE, CFG simplification, or folding. Each node ensures that it + executes the speculations promised by its edges. This is true even for Phantom + nodes. + + This still leaves some craziness on the table for future work, like the + elimination of speculating SetLocal's due to CFG simplification + (webkit.org/b/109388) and elimination of nodes via DCE (webkit.org/b/109389). + + In all, this allows for a huge simplification of the DFG. Instead of having to + execute the right speculation heuristic each time you want to decide what a node + does (for example Node::shouldSpeculateInteger(child1, child2) && + node->canSpeculateInteger()), you just ask for the use kinds of its children + (typically node->binaryUseKind() == Int32Use). Because the use kinds are + discrete, you can often just switch over them. This makes many parts of the code + more clear than they were before. + + Having UseKinds describe the speculations being performed also makes it far + easier to perform analyses that need to know what speculations are done. This is + so far only used to simplify large parts of the CFA. + + To have a larger vocabulary of UseKinds, this also changes the node allocator to + be able to round up Node sizes to the nearest multiple of 16. + + This appears to be neutral on benchmarks, except for some goofy speed-ups, like + 8% on Octane/box2d. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::startExecuting): + (DFG): + (JSC::DFG::AbstractState::executeEdges): + (JSC::DFG::AbstractState::verifyEdge): + (JSC::DFG::AbstractState::verifyEdges): + (JSC::DFG::AbstractState::executeEffects): + (JSC::DFG::AbstractState::execute): + * dfg/DFGAbstractState.h: + (AbstractState): + (JSC::DFG::AbstractState::filterEdgeByUse): + (JSC::DFG::AbstractState::filterByType): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::filter): + * dfg/DFGAdjacencyList.h: + (JSC::DFG::AdjacencyList::AdjacencyList): + (JSC::DFG::AdjacencyList::child): + (JSC::DFG::AdjacencyList::setChild): + (JSC::DFG::AdjacencyList::reset): + (JSC::DFG::AdjacencyList::firstChild): + (JSC::DFG::AdjacencyList::setFirstChild): + (JSC::DFG::AdjacencyList::numChildren): + (JSC::DFG::AdjacencyList::setNumChildren): + (AdjacencyList): + * dfg/DFGAllocator.h: + (DFG): + (Allocator): + (JSC::DFG::Allocator::cellSize): + (JSC::DFG::Allocator::Region::headerSize): + (JSC::DFG::Allocator::Region::numberOfThingsPerRegion): + (JSC::DFG::Allocator::Region::payloadSize): + (JSC::DFG::Allocator::Region::payloadBegin): + (JSC::DFG::Allocator::Region::payloadEnd): + (JSC::DFG::Allocator::Region::isInThisRegion): + (JSC::DFG::::Allocator): + (JSC::DFG::::~Allocator): + (JSC::DFG::::allocate): + (JSC::DFG::::free): + (JSC::DFG::::freeAll): + (JSC::DFG::::reset): + (JSC::DFG::::indexOf): + (JSC::DFG::::allocatorOf): + (JSC::DFG::::bumpAllocate): + (JSC::DFG::::freeListAllocate): + (JSC::DFG::::allocateSlow): + (JSC::DFG::::freeRegionsStartingAt): + (JSC::DFG::::startBumpingIn): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::addToGraph): + (JSC::DFG::ByteCodeParser::handleMinMax): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::setLocalStoreElimination): + (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren): + (JSC::DFG::CSEPhase::setReplacement): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCommon.h: + (DFG): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGEdge.cpp: + (JSC::DFG::Edge::dump): + * dfg/DFGEdge.h: + (JSC::DFG::Edge::useKindUnchecked): + (JSC::DFG::Edge::useKind): + (JSC::DFG::Edge::shift): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::run): + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::checkArray): + (JSC::DFG::FixupPhase::blessArrayOperation): + (JSC::DFG::FixupPhase::fixIntEdge): + (JSC::DFG::FixupPhase::fixDoubleEdge): + (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): + (FixupPhase): + (JSC::DFG::FixupPhase::truncateConstantToInt32): + (JSC::DFG::FixupPhase::truncateConstantsIfNecessary): + (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd): + * dfg/DFGGraph.cpp: + (DFG): + (JSC::DFG::Graph::refChildren): + (JSC::DFG::Graph::derefChildren): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::ref): + (JSC::DFG::Graph::deref): + (JSC::DFG::Graph::performSubstitution): + (JSC::DFG::Graph::isPredictedNumerical): + (JSC::DFG::Graph::addImmediateShouldSpeculateInteger): + (DFG): + * dfg/DFGNode.h: + (JSC::DFG::Node::Node): + (JSC::DFG::Node::convertToGetByOffset): + (JSC::DFG::Node::convertToPutByOffset): + (JSC::DFG::Node::willHaveCodeGenOrOSR): + (JSC::DFG::Node::child1): + (JSC::DFG::Node::child2): + (JSC::DFG::Node::child3): + (JSC::DFG::Node::binaryUseKind): + (Node): + (JSC::DFG::Node::isBinaryUseKind): + * dfg/DFGNodeAllocator.h: + (DFG): + * dfg/DFGNodeFlags.cpp: + (JSC::DFG::nodeFlagsAsString): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::speculationCheck): + (DFG): + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): + (JSC::DFG::SpeculativeJIT::typeCheck): + (JSC::DFG::SpeculativeJIT::forwardTypeCheck): + (JSC::DFG::SpeculativeJIT::fillStorage): + (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): + (JSC::DFG::SpeculativeJIT::compile): + (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): + (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): + (JSC::DFG::SpeculativeJIT::compileInstanceOf): + (JSC::DFG::SpeculativeJIT::compileAdd): + (JSC::DFG::SpeculativeJIT::compileArithSub): + (JSC::DFG::SpeculativeJIT::compileArithNegate): + (JSC::DFG::SpeculativeJIT::compileArithMul): + (JSC::DFG::SpeculativeJIT::compileArithMod): + (JSC::DFG::SpeculativeJIT::compare): + (JSC::DFG::SpeculativeJIT::compileStrictEq): + (JSC::DFG::SpeculativeJIT::speculateInt32): + (JSC::DFG::SpeculativeJIT::speculateNumber): + (JSC::DFG::SpeculativeJIT::speculateRealNumber): + (JSC::DFG::SpeculativeJIT::speculateBoolean): + (JSC::DFG::SpeculativeJIT::speculateCell): + (JSC::DFG::SpeculativeJIT::speculateObject): + (JSC::DFG::SpeculativeJIT::speculateObjectOrOther): + (JSC::DFG::SpeculativeJIT::speculateString): + (JSC::DFG::SpeculativeJIT::speculateNotCell): + (JSC::DFG::SpeculativeJIT::speculateOther): + (JSC::DFG::SpeculativeJIT::speculate): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::valueOfNumberConstant): + (JSC::DFG::SpeculativeJIT::needsTypeCheck): + (JSC::DFG::IntegerOperand::IntegerOperand): + (JSC::DFG::IntegerOperand::edge): + (IntegerOperand): + (JSC::DFG::IntegerOperand::node): + (JSC::DFG::IntegerOperand::gpr): + (JSC::DFG::IntegerOperand::use): + (JSC::DFG::JSValueOperand::JSValueOperand): + (JSValueOperand): + (JSC::DFG::JSValueOperand::edge): + (JSC::DFG::JSValueOperand::node): + (JSC::DFG::JSValueOperand::gpr): + (JSC::DFG::JSValueOperand::fill): + (JSC::DFG::JSValueOperand::use): + (JSC::DFG::StorageOperand::StorageOperand): + (JSC::DFG::StorageOperand::edge): + (StorageOperand): + (JSC::DFG::StorageOperand::node): + (JSC::DFG::StorageOperand::gpr): + (JSC::DFG::StorageOperand::use): + (JSC::DFG::SpeculateIntegerOperand::SpeculateIntegerOperand): + (SpeculateIntegerOperand): + (JSC::DFG::SpeculateIntegerOperand::edge): + (JSC::DFG::SpeculateIntegerOperand::node): + (JSC::DFG::SpeculateIntegerOperand::gpr): + (JSC::DFG::SpeculateIntegerOperand::use): + (JSC::DFG::SpeculateStrictInt32Operand::SpeculateStrictInt32Operand): + (SpeculateStrictInt32Operand): + (JSC::DFG::SpeculateStrictInt32Operand::edge): + (JSC::DFG::SpeculateStrictInt32Operand::node): + (JSC::DFG::SpeculateStrictInt32Operand::gpr): + (JSC::DFG::SpeculateStrictInt32Operand::use): + (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand): + (SpeculateDoubleOperand): + (JSC::DFG::SpeculateDoubleOperand::edge): + (JSC::DFG::SpeculateDoubleOperand::node): + (JSC::DFG::SpeculateDoubleOperand::fpr): + (JSC::DFG::SpeculateDoubleOperand::use): + (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand): + (SpeculateCellOperand): + (JSC::DFG::SpeculateCellOperand::edge): + (JSC::DFG::SpeculateCellOperand::node): + (JSC::DFG::SpeculateCellOperand::gpr): + (JSC::DFG::SpeculateCellOperand::use): + (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand): + (JSC::DFG::SpeculateBooleanOperand::edge): + (SpeculateBooleanOperand): + (JSC::DFG::SpeculateBooleanOperand::node): + (JSC::DFG::SpeculateBooleanOperand::gpr): + (JSC::DFG::SpeculateBooleanOperand::use): + (DFG): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::fillJSValue): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateInt): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): + (JSC::DFG::SpeculativeJIT::emitBranch): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::fillJSValue): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateInt): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): + (JSC::DFG::SpeculativeJIT::emitBranch): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * dfg/DFGUseKind.cpp: Added. + (WTF): + (WTF::printInternal): + * dfg/DFGUseKind.h: Added. + (DFG): + (JSC::DFG::typeFilterFor): + (JSC::DFG::isNumerical): + (WTF): + * dfg/DFGValidate.cpp: + (JSC::DFG::Validate::reportValidationContext): + +2013-02-20 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Need a way to use the Objective-C JavaScript API with WebKit + https://bugs.webkit.org/show_bug.cgi?id=106059 + + Reviewed by Geoffrey Garen. + + * API/JSBase.h: Renamed enable flag for API. + * API/JSBlockAdaptor.h: Using new flag. + * API/JSBlockAdaptor.mm: Ditto. + * API/JSContext.h: Add convenience C API conversion function for JSGlobalContextRef. + * API/JSContext.mm: + (-[JSContext JSGlobalContextRef]): Implementation of C API convenience function. + (-[JSContext initWithVirtualMachine:]): We don't use the m_apiData field any more. + (-[JSContext initWithGlobalContextRef:]): init method for allocating new JSContexts given a JSGlobalContextRef. + (-[JSContext dealloc]): No more m_apiData. + (-[JSContext wrapperForObjCObject:]): Renamed wrapperForObject. + (-[JSContext wrapperForJSObject:]): Fetches or allocates the JSValue for the specified JSValueRef in this JSContext. + (+[JSContext contextWithGlobalContextRef:]): Helper function to grab the lightweight JSContext wrapper for a given + JSGlobalContextRef from the global wrapper cache or allocate a new one if there isn't already one. + * API/JSContextInternal.h: New flag, new method declaration for initWithGlobalContextRef. + * API/JSExport.h: New flag. + * API/JSValue.h: New flag and new C API convenience method. + * API/JSValue.mm: + (-[JSValue JSValueRef]): Implementation of the C API convenience method. + (objectToValueWithoutCopy): + (+[JSValue valueWithValue:inContext:]): We now ask the JSContext for an Objective-C JSValue wrapper, which it can cache + in its internal JSWrapperMap. + * API/JSValueInternal.h: + * API/JSVirtualMachine.h: + * API/JSVirtualMachine.mm: Added global cache that maps JSContextGroupRef -> JSVirtualMachine lightweight wrappers. + (wrapperCacheLock): + (initWrapperCache): + (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]): + (+[JSVMWrapperCache wrapperForJSContextGroupRef:]): + (-[JSVirtualMachine init]): + (-[JSVirtualMachine initWithContextGroupRef:]): + (-[JSVirtualMachine dealloc]): + (+[JSVirtualMachine virtualMachineWithContextGroupRef:]): + (-[JSVirtualMachine contextForGlobalContextRef:]): + (-[JSVirtualMachine addContext:forGlobalContextRef:]): + * API/JSVirtualMachineInternal.h: + * API/JSWrapperMap.h: + * API/JSWrapperMap.mm: + (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We use the JSObjectSetPrototype C API call because + setting the __proto__ property causes all sorts of bad things to happen behind the scenes, which can cause crashes based on + when it gets called. + (-[JSWrapperMap initWithContext:]): + (-[JSWrapperMap jsWrapperForObject:]): + (-[JSWrapperMap objcWrapperForJSValueRef:]): + * API/JavaScriptCore.h: + * API/ObjCCallbackFunction.h: + * API/ObjCCallbackFunction.mm: + (ObjCCallbackFunction::ObjCCallbackFunction): We never actually should have retained the target in the case that we had a + block as a callback. Blocks are initially allocated on the stack and are only moved to the heap if we call their copy method. + Retaining the block on the stack was a bad idea because if that stack frame ever went away and we called the block later, + we'd crash and burn. + (ObjCCallbackFunction::setContext): We need a new setter for when the weak reference to a JSContext inside an ObjCCallbackFunction + disappears, we can allocate a new one in its place. + (ObjCCallbackFunction): + (objCCallbackFunctionCallAsFunction): Reset the callback's context if it's ever destroyed. + (objCCallbackFunctionForInvocation): Again, don't set the __proto__ property because it uses black magic that can cause us to crash + depending on when this is called. + (objCCallbackFunctionForBlock): Here is where we copy the block to the heap when we're first creating the callback object for it. + * API/tests/testapi.c: + (main): + * API/tests/testapi.mm: We're going to get rid of the automatic block conversion, since that is causing leaks. I changed it + here in this test just so that it wouldn't mask any other potential leaks. Also modified some of the tests since JSContexts are + just lightweight wrappers now, we're not guaranteed to get the same pointer back from the call to [JSValue context] as the one + that the value was created in. + (-[TestObject callback:]): + * JavaScriptCore.xcodeproj/project.pbxproj: + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): No more m_apiData. + * runtime/JSGlobalData.h: Ditto. + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): Ditto. + * runtime/JSGlobalObject.h: + +2013-02-19 Filip Pizlo <fpizlo@apple.com> + + DFG::SpeculativeJIT::compileInt32ToDouble() has an unnecessary case for constant operands + https://bugs.webkit.org/show_bug.cgi?id=110309 + + Reviewed by Sam Weinig. + + It used to be necessary, back when we didn't have constant folding. Now we have + constant folding. So we don't need it. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): + +2013-02-20 Filip Pizlo <fpizlo@apple.com> + + DFG inlines Resolves that it doesn't know how to handle correctly + https://bugs.webkit.org/show_bug.cgi?id=110405 + + Reviewed by Geoffrey Garen. + + Don't try to be clever: if there's a failing resolve, we can't inline it, period. + + * dfg/DFGCapabilities.h: + (JSC::DFG::canInlineResolveOperations): + (JSC::DFG::canInlineOpcode): + +2013-02-20 Roger Fong <roger_fong@apple.com> + + Get VS2010 Solution B&I ready. + <rdar://problem/1322988> + + Rubberstamped by Timothy Horton. + + Add Production configuration. + Add a JavaScriptCore submit solution with a DebugSuffix configuration. + Modify JavaScriptCore.make as necessary. + + * JavaScriptCore.vcxproj/JavaScriptCore.make: Added. + * JavaScriptCore.vcxproj/JavaScriptCore.sln: Removed. + * JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: Copied from Source/JavaScriptCore/JavaScriptCore.vcxproj/JavaScriptCore.sln. + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPreBuild.cmd: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorProduction.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props: + * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj.filters: + * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedProduction.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props: + * JavaScriptCore.vcxproj/JavaScriptCoreProduction.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreRelease.props: + * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: + * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: + * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: + * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: + * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: + * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props: Added. + * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: + * JavaScriptCore.vcxproj/jsc/jscCommon.props: + * JavaScriptCore.vcxproj/jsc/jscProduction.props: Added. + * JavaScriptCore.vcxproj/jsc/jscRelease.props: + * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: + * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: + * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props: Added. + * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: + * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: + * JavaScriptCore.vcxproj/testapi/testapiCommon.props: + * JavaScriptCore.vcxproj/testapi/testapiProduction.props: Added. + * JavaScriptCore.vcxproj/testapi/testapiRelease.props: + +2013-02-19 Jer Noble <jer.noble@apple.com> + + EME: Enable both ENCRYPTED_MEDIA and ENCRYPTED_MEDIA_V2 until clients transition to the new API. + https://bugs.webkit.org/show_bug.cgi?id=110284 + + Reviewed by Eric Carlson. + + Re-enable the ENCRYPTED_MEDIA flag. + + * Configurations/FeatureDefines.xcconfig: + +2013-02-20 Dirk Schulze <krit@webkit.org> + + Enable CANVAS_PATH flag + https://bugs.webkit.org/show_bug.cgi?id=108508 + + Reviewed by Simon Fraser. + + Enable CANVAS_PATH flag on trunk. + + Existing tests cover the feature. + + * Configurations/FeatureDefines.xcconfig: + +2013-02-19 Mark Rowe <mrowe@apple.com> + + Unreviewed, uninteresting change to test a theory about bad dependency handling. + + * API/JSStringRefCF.cpp: + (JSStringCreateWithCFString): Remove an unnecessary else clause. + +2013-02-19 Oliver Hunt <oliver@apple.com> + + Silence some analyzer warnings + https://bugs.webkit.org/show_bug.cgi?id=110281 + + Reviewed by Mark Hahnenberg. + + The static analyzer believes that callerCodeBlock can be null, + based on other code performing null tests. This should not + ever be the case, but we'll add RELEASE_ASSERTs to make it + obvious if we're ever wrong. + + * interpreter/Interpreter.cpp: + (JSC::getCallerInfo): + +2013-02-19 Oliver Hunt <oliver@apple.com> + + Don't force everything to be blinded in debug builds + https://bugs.webkit.org/show_bug.cgi?id=110279 + + Reviewed by Mark Hahnenberg. + + Switch to an explicit flag for indicating that we want + every constant to be blinded. + + * assembler/MacroAssembler.h: + (JSC::MacroAssembler::shouldBlind): + +2013-02-19 Filip Pizlo <fpizlo@apple.com> + + Fix indentation of Opcode.h + + Rubber stamped by Mark Hahnenberg. + + * bytecode/Opcode.h: + +2013-02-19 Filip Pizlo <fpizlo@apple.com> + + Moved PolymorphicAccessStructureList into its own file. + + Rubber stamped by Mark Hahnenberg. + + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/Instruction.h: + (JSC): + * bytecode/PolymorphicAccessStructureList.h: Added. + (JSC): + (PolymorphicAccessStructureList): + (PolymorphicStubInfo): + (JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::PolymorphicStubInfo): + (JSC::PolymorphicAccessStructureList::PolymorphicStubInfo::set): + (JSC::PolymorphicAccessStructureList::PolymorphicAccessStructureList): + (JSC::PolymorphicAccessStructureList::visitWeak): + * bytecode/StructureStubInfo.h: + +2013-02-19 Filip Pizlo <fpizlo@apple.com> + + Fix indentation of Instruction.h + + Rubber stamped by Mark Hahnenberg. + + * bytecode/Instruction.h: + +2013-02-18 Geoffrey Garen <ggaren@apple.com> + + Unreviewed, rolling in r143348. + http://trac.webkit.org/changeset/143348 + https://bugs.webkit.org/show_bug.cgi?id=110242 + + The bug was that isEmptyValue() was returning true for the deleted value. + Fixed this and simplified things further by delegating to m_sourceCode + for both isNull() and isHashTableDeletedValue(), so they can't be out of + sync. + + * runtime/CodeCache.cpp: + (JSC::CodeCache::getFunctionExecutableFromGlobalCode): + * runtime/CodeCache.h: + (JSC::SourceCodeKey::SourceCodeKey): + (JSC::SourceCodeKey::isHashTableDeletedValue): + (JSC::SourceCodeKey::hash): + (JSC::SourceCodeKey::length): + (JSC::SourceCodeKey::isNull): + (JSC::SourceCodeKey::operator==): + (SourceCodeKey): + +2013-02-15 Martin Robinson <mrobinson@igalia.com> + + [GTK] Improve gyp build JavaScriptCore code generation + https://bugs.webkit.org/show_bug.cgi?id=109969 + + Reviewed by Dirk Pranke. + + Switch away from using DerivedSources.make when building JavaScriptCore generated + sources. This bring a couple advantages, such as building the sources in parallel, + but requires us to list the generated sources more than once. + + * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Add rules for generating JavaScriptCore sources. + * JavaScriptCore.gyp/generate-derived-sources.sh: Added. + * JavaScriptCore.gyp/redirect-stdout.sh: Added. + +2013-02-19 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r143348. + http://trac.webkit.org/changeset/143348 + https://bugs.webkit.org/show_bug.cgi?id=110242 + + "Caused a deleted value sentinel crash on the layout tests" + (Requested by ggaren on #webkit). + + * runtime/CodeCache.cpp: + (JSC::CodeCache::getFunctionExecutableFromGlobalCode): + * runtime/CodeCache.h: + (JSC::SourceCodeKey::SourceCodeKey): + (JSC::SourceCodeKey::isHashTableDeletedValue): + (JSC::SourceCodeKey::hash): + (JSC::SourceCodeKey::length): + (JSC::SourceCodeKey::isNull): + (JSC::SourceCodeKey::operator==): + (SourceCodeKey): + +2013-02-19 Mark Hahnenberg <mhahnenberg@apple.com> + + HeapBlock::destroy should issue warning if result is unused + https://bugs.webkit.org/show_bug.cgi?id=110233 + + Reviewed by Oliver Hunt. + + To enforce the fact that we need to return blocks to the BlockAllocator after calling destroy, + we should add WARN_UNUSED_RETURN to HeapBlock::destroy and any other destroy functions in its subclasses. + + * heap/HeapBlock.h: + +2013-02-19 Mark Hahnenberg <mhahnenberg@apple.com> + + WeakSet::removeAllocator leaks WeakBlocks + https://bugs.webkit.org/show_bug.cgi?id=110228 + + Reviewed by Geoffrey Garen. + + We need to return the WeakBlock to the BlockAllocator after the call to WeakBlock::destroy. + + * heap/WeakSet.cpp: + (JSC::WeakSet::removeAllocator): + +2013-02-18 Geoffrey Garen <ggaren@apple.com> + + Save space on keys in the CodeCache + https://bugs.webkit.org/show_bug.cgi?id=110179 + + Reviewed by Oliver Hunt. + + Share the SourceProvider's string instead of making our own copy. This + chops off 16MB - 32MB from the CodeCache's memory footprint when full. + (It's 16MB when the strings are LChar, and 32MB when they're UChar.) + + * runtime/CodeCache.cpp: + (JSC::CodeCache::getFunctionExecutableFromGlobalCode): + * runtime/CodeCache.h: Removed a defunct enum value. + + (JSC::SourceCodeKey::SourceCodeKey): + (JSC::SourceCodeKey::isHashTableDeletedValue): + (SourceCodeKey): + (JSC::SourceCodeKey::hash): + (JSC::SourceCodeKey::length): + (JSC::SourceCodeKey::isNull): + (JSC::SourceCodeKey::string): + (JSC::SourceCodeKey::operator==): Store a SourceCode instead of a String + so we can share our string with our SourceProvider. Cache our hash so + we don't have to re-decode our string just to re-hash the table. + +2013-02-19 Zoltan Herczeg <zherczeg@webkit.org> + + revertBranchPtrWithPatch is incorrect on ARM traditional + https://bugs.webkit.org/show_bug.cgi?id=110201 + + Reviewed by Oliver Hunt. + + Revert two instructions back to their original value. + + * assembler/ARMAssembler.h: + (JSC::ARMAssembler::revertBranchPtrWithPatch): + (ARMAssembler): + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::branchPtrWithPatch): + (JSC::MacroAssemblerARM::revertJumpReplacementToBranchPtrWithPatch): + +2013-02-19 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(r143241): It made 27 layout tests crash on 32 bit platforms + https://bugs.webkit.org/show_bug.cgi?id=110184 + + Reviewed by Zoltan Herczeg. + + 32-bit backend was making all sorts of crazy assumptions, which happened to mostly + not break things prior to http://trac.webkit.org/changeset/143241. This brings the + 32-bit backend's type speculation fully into compliance with what the 64-bit + backend does. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + +2013-02-18 Ilya Tikhonovsky <loislo@chromium.org> + + Unreviewed build fix for Apple Windows. Second stage. + Add missed export statement. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + +2013-02-18 Roger Fong <roger_fong@apple.com> + + Unreviewed Windows build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-02-18 Darin Adler <darin@apple.com> + + Remove unneeded explicit function template arguments. + https://bugs.webkit.org/show_bug.cgi?id=110043 + + Reviewed by Ryosuke Niwa. + + * runtime/Identifier.cpp: + (JSC::IdentifierASCIIStringTranslator::hash): Let the compiler deduce the type + when calling computeHashAndMaskTop8Bits. + (JSC::IdentifierLCharFromUCharTranslator::hash): Ditto. + * runtime/Identifier.h: + (JSC::IdentifierCharBufferTranslator::hash): Ditto. +2013-02-18 Geoffrey Garen <ggaren@apple.com> + + Shrank the SourceProvider cache + https://bugs.webkit.org/show_bug.cgi?id=110158 + + Reviewed by Oliver Hunt. + + CodeCache is now our primary source cache, so a long-lived SourceProvider + cache is a waste. I measured this as a 10MB Membuster win; with more + precise instrumentation, Andreas estimated it as up to 30MB. + + I didn't eliminate the SourceProvider cache because it's still useful + in speeding up uncached parsing of scripts with large nested functions + (i.e., all scripts). + + * heap/Heap.cpp: + (JSC::Heap::collect): Discard all source provider caches after GC. This + is a convenient place to do so because it's reasonably soon after initial + parsing without being immediate. + + * parser/Parser.cpp: + (JSC::::Parser): Updated for interface change: The heap now owns the + source provider cache, since most SourceProviders are not expected to + have one by default, and the heap is responsible for throwing them away. + + (JSC::::parseInner): No need to update statistics on cache size, since + we're going to throw it away no matter what. + + (JSC::::parseFunctionInfo): Reduced the minimum function size to 16. This + is a 27% win on a new parsing micro-benchmark I've added. Now that the + cache is temporary, we don't have to worry so much about its memory + footprint. + + * parser/Parser.h: + (Parser): Updated for interface changes. + + * parser/SourceProvider.cpp: + (JSC::SourceProvider::SourceProvider): + (JSC::SourceProvider::~SourceProvider): + * parser/SourceProvider.h: + (JSC): + (SourceProvider): SourceProvider doesn't own its cache anymore because + the cache is temporary. + + * parser/SourceProviderCache.cpp: + (JSC::SourceProviderCache::clear): + (JSC::SourceProviderCache::add): + * parser/SourceProviderCache.h: + (JSC::SourceProviderCache::SourceProviderCache): + (SourceProviderCache): + * parser/SourceProviderCacheItem.h: + (SourceProviderCacheItem): No need to update statistics on cache size, + since we're going to throw it away no matter what. + + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::addSourceProviderCache): + (JSC): + (JSC::JSGlobalData::clearSourceProviderCaches): + * runtime/JSGlobalData.h: + (JSC): + (JSGlobalData): Moved the cache here so it's easier to throw away. + +2013-02-18 Filip Pizlo <fpizlo@apple.com> + + DFG backend Branch handling has duplicate code and dead code + https://bugs.webkit.org/show_bug.cgi?id=110162 + + Reviewed by Mark Hahnenberg. + + Streamline the code, and make the 64 backend's optimizations make more sense + (i.e. not be dead code). + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::emitBranch): + (JSC::DFG::SpeculativeJIT::compile): + +2013-02-18 Brent Fulgham <bfulgham@webkit.org> + + [Windows] Unreviewed VS2010 build correction after r143273. + + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add missing source + file SourceProvider.cpp. + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: Add missing exports. + +2013-02-18 Filip Pizlo <fpizlo@apple.com> + + Structure::flattenDictionaryStructure should compute max offset in a manner that soundly handles the case where the property list becomes empty + https://bugs.webkit.org/show_bug.cgi?id=110155 + <rdar://problem/13233773> + + Reviewed by Mark Rowe. + + This was a rookie mistake. It was doing: + + for (blah) { + m_offset = foo // foo's monotonically increase in the loop + } + + as a way of computing max offset for all of the properties. Except what if the loop doesn't + execute because there are no properties? Well, then, you're going to have a bogus m_offset. + + The solution is to initialize m_offset at the top of the loop. + + * runtime/Structure.cpp: + (JSC::Structure::flattenDictionaryStructure): + +2013-02-18 Balazs Kilvady <kilvadyb@homejinni.com> + + MIPS DFG implementation. + https://bugs.webkit.org/show_bug.cgi?id=101328 + + Reviewed by Oliver Hunt. + + DFG implementation for MIPS. + + * assembler/MIPSAssembler.h: + (JSC::MIPSAssembler::MIPSAssembler): + (JSC::MIPSAssembler::sllv): + (JSC::MIPSAssembler::movd): + (MIPSAssembler): + (JSC::MIPSAssembler::negd): + (JSC::MIPSAssembler::labelForWatchpoint): + (JSC::MIPSAssembler::label): + (JSC::MIPSAssembler::vmov): + (JSC::MIPSAssembler::linkDirectJump): + (JSC::MIPSAssembler::maxJumpReplacementSize): + (JSC::MIPSAssembler::revertJumpToMove): + (JSC::MIPSAssembler::replaceWithJump): + * assembler/MacroAssembler.h: + (MacroAssembler): + (JSC::MacroAssembler::poke): + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::add32): + (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::and32): + (JSC::MacroAssemblerMIPS::lshift32): + (JSC::MacroAssemblerMIPS::mul32): + (JSC::MacroAssemblerMIPS::or32): + (JSC::MacroAssemblerMIPS::rshift32): + (JSC::MacroAssemblerMIPS::urshift32): + (JSC::MacroAssemblerMIPS::sub32): + (JSC::MacroAssemblerMIPS::xor32): + (JSC::MacroAssemblerMIPS::store32): + (JSC::MacroAssemblerMIPS::jump): + (JSC::MacroAssemblerMIPS::branchAdd32): + (JSC::MacroAssemblerMIPS::branchMul32): + (JSC::MacroAssemblerMIPS::branchSub32): + (JSC::MacroAssemblerMIPS::branchNeg32): + (JSC::MacroAssemblerMIPS::call): + (JSC::MacroAssemblerMIPS::loadDouble): + (JSC::MacroAssemblerMIPS::moveDouble): + (JSC::MacroAssemblerMIPS::swapDouble): + (JSC::MacroAssemblerMIPS::subDouble): + (JSC::MacroAssemblerMIPS::mulDouble): + (JSC::MacroAssemblerMIPS::divDouble): + (JSC::MacroAssemblerMIPS::negateDouble): + (JSC::MacroAssemblerMIPS::branchEqual): + (JSC::MacroAssemblerMIPS::branchNotEqual): + (JSC::MacroAssemblerMIPS::branchTruncateDoubleToInt32): + (JSC::MacroAssemblerMIPS::branchTruncateDoubleToUint32): + (JSC::MacroAssemblerMIPS::truncateDoubleToInt32): + (JSC::MacroAssemblerMIPS::truncateDoubleToUint32): + (JSC::MacroAssemblerMIPS::branchDoubleNonZero): + (JSC::MacroAssemblerMIPS::branchDoubleZeroOrNaN): + (JSC::MacroAssemblerMIPS::invert): + (JSC::MacroAssemblerMIPS::replaceWithJump): + (JSC::MacroAssemblerMIPS::maxJumpReplacementSize): + * dfg/DFGAssemblyHelpers.h: + (AssemblyHelpers): + (JSC::DFG::AssemblyHelpers::preserveReturnAddressAfterCall): + (JSC::DFG::AssemblyHelpers::restoreReturnAddressBeforeReturn): + (JSC::DFG::AssemblyHelpers::debugCall): + * dfg/DFGCCallHelpers.h: + (CCallHelpers): + (JSC::DFG::CCallHelpers::setupArguments): + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + * dfg/DFGFPRInfo.h: + (DFG): + (FPRInfo): + (JSC::DFG::FPRInfo::toRegister): + (JSC::DFG::FPRInfo::toIndex): + (JSC::DFG::FPRInfo::debugName): + * dfg/DFGGPRInfo.h: + (DFG): + (GPRInfo): + (JSC::DFG::GPRInfo::toRegister): + (JSC::DFG::GPRInfo::toIndex): + (JSC::DFG::GPRInfo::debugName): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * jit/JSInterfaceJIT.h: + (JSInterfaceJIT): + * runtime/JSGlobalData.h: + (JSC::ScratchBuffer::allocationSize): + (ScratchBuffer): + +2013-02-18 Filip Pizlo <fpizlo@apple.com> + + DFG::SpeculativeJIT::isKnownXYZ methods should use CFA rather than other things + https://bugs.webkit.org/show_bug.cgi?id=110092 + + Reviewed by Geoffrey Garen. + + These methods were previously using GenerationInfo and other things to try to + gain information that the CFA could give away for free, if you asked kindly + enough. + + Also fixed CallLinkStatus's dump() method since it was making an invalid + assertion: we most certainly can have a status where the structure is non-null + and the executable is null, like if we're dealing with an InternalFunction. + + Also removed calls to isKnownNotXYZ from fillSpeculateABC methods in 32_64. I + don't know why that was there. But it was causing asserts if the value was + empty - i.e. we had already exited unconditionally but we didn't know it. I + could have fixed this by introducing another form of isKnownNotXYZ which was + tolerant of empty values, but I didn't feel like fixing code that I knew to be + unnecessary. (More deeply, isKnownNotCell, for example, really asks: "do you + know that this value can never be a cell?" while some of the previous uses + wanted to ask: "do you know that this is a value that is not a cell?". The + former is "true" if the value is a contradiction [i.e. BOTTOM], while the + latter is "false" for contradictions, since contradictions are not values.) + + * bytecode/CallLinkStatus.cpp: + (JSC::CallLinkStatus::dump): + * bytecode/CallLinkStatus.h: + (JSC::CallLinkStatus::CallLinkStatus): + * dfg/DFGSpeculativeJIT.cpp: + (DFG): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::isKnownInteger): + (JSC::DFG::SpeculativeJIT::isKnownCell): + (JSC::DFG::SpeculativeJIT::isKnownNotInteger): + (JSC::DFG::SpeculativeJIT::isKnownNotNumber): + (JSC::DFG::SpeculativeJIT::isKnownNotCell): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + * dfg/DFGStructureAbstractValue.h: + (JSC::DFG::StructureAbstractValue::dump): + +2013-02-17 Filip Pizlo <fpizlo@apple.com> + + Get rid of DFG::DoubleOperand and simplify ValueToInt32 + https://bugs.webkit.org/show_bug.cgi?id=110072 + + Reviewed by Geoffrey Garen. + + ValueToInt32 had a side-effecting path, which was not OSR-friendly: an OSR after + the side-effect would lead to the side-effect re-executing. I got rid of that path + and replaced it with an optimization for the case where the input is speculated + number-or-other. This makes idioms like null|0 and true|0 work as expected, and + get optimized appropriately. + + Also got rid of DoubleOperand. Replaced all remaining uses of it with + SpeculateDoubleOperand. Because the latter asserts that the Edge is a DoubleUse + edge and the remaining uses of DoubleOperand are all for untyped uses, I worked + around the assertion by setting the UseKind to DoubleUse by force. This is sound, + since all existing assertions for DoubleUse are actually asserting that we're not + converting a value to double unexpectedly. But all of these calls to + SpeculateDoubleOperand are when the operand is already known to be represented as + double, so there is no conversion. + + This is neutral on benchmarks, except stanford-crypto-ccm, which speeds up a + little. Mostly, this is intended to delete a bunch of code. DoubleOperand was + equivalent to the replace-edge-with-DoubleUse trick that I'm using now, except it + involved a _lot_ more code. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGSpeculativeJIT.cpp: + (DFG): + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (DFG): + (FPRTemporary): + * dfg/DFGSpeculativeJIT32_64.cpp: + (DFG): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (DFG): + +2013-02-18 Ádám Kallai <kadam@inf.u-szeged.hu> + + [Qt] Mountain Lion buildfix after r143147. + + Reviewed by Csaba Osztrogonác. + + * runtime/DateConstructor.cpp: + +2013-02-18 Zan Dobersek <zdobersek@igalia.com> + + Stop placing std::isfinite and std::signbit inside the global scope + https://bugs.webkit.org/show_bug.cgi?id=109817 + + Reviewed by Darin Adler. + + Prefix calls to the isfinite and signbit methods with std:: as the two + methods are no longer being imported into the global scope. + + * assembler/MacroAssembler.h: + (JSC::MacroAssembler::shouldBlindDouble): + * offlineasm/cloop.rb: + * runtime/BigInteger.h: + (JSC::BigInteger::BigInteger): + * runtime/DateConstructor.cpp: + (JSC::constructDate): + * runtime/DatePrototype.cpp: + (JSC::fillStructuresUsingTimeArgs): + (JSC::fillStructuresUsingDateArgs): + (JSC::dateProtoFuncToISOString): + (JSC::dateProtoFuncSetYear): + * runtime/JSCJSValueInlines.h: + (JSC::JSValue::JSValue): + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::globalFuncIsFinite): + * runtime/JSONObject.cpp: + (JSC::Stringifier::appendStringifiedValue): + * runtime/MathObject.cpp: + (JSC::mathProtoFuncMax): Also include an opportunistic style fix. + (JSC::mathProtoFuncMin): Ditto. + * runtime/NumberPrototype.cpp: + (JSC::toStringWithRadix): + (JSC::numberProtoFuncToExponential): + (JSC::numberProtoFuncToFixed): + (JSC::numberProtoFuncToPrecision): + (JSC::numberProtoFuncToString): + * runtime/Uint16WithFraction.h: + (JSC::Uint16WithFraction::Uint16WithFraction): + +2013-02-18 Ádám Kallai <kadam@inf.u-szeged.hu> + + [Qt] Mountain Lion buildfix after r143147. + + Reviewed by Csaba Osztrogonác. + + * runtime/DateInstance.cpp: + +2013-02-18 Ilya Tikhonovsky <loislo@chromium.org> + + Unreviewed speculative build fix for Apple Win bots. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + +2013-02-18 Filip Pizlo <fpizlo@apple.com> + + Fix indentation of StructureStubInfo.h + + Rubber stamped by Mark Hahnenberg. + + * bytecode/StructureStubInfo.h: + +2013-02-18 Filip Pizlo <fpizlo@apple.com> + + Fix indentation of JSGlobalObject.h and JSGlobalObjectFunctions.h + + Rubber stamped by Mark Hahnenberg. + + * runtime/JSGlobalObject.h: + * runtime/JSGlobalObjectFunctions.h: + +2013-02-18 Filip Pizlo <fpizlo@apple.com> + + Fix indention of Operations.h + + Rubber stamped by Mark Hahnenberg. + + * runtime/Operations.h: + +2013-02-18 Filip Pizlo <fpizlo@apple.com> + + Remove DFG::SpeculativeJIT::isKnownNumeric(), since it's not called from anywhere. + + Rubber stamped by Andy Estes. + + * dfg/DFGSpeculativeJIT.cpp: + (DFG): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + +2013-02-18 Filip Pizlo <fpizlo@apple.com> + + Remove DFG::SpeculativeJIT::isStrictInt32(), since it's not called from anywhere. + + Rubber stampted by Andy Estes. + + * dfg/DFGSpeculativeJIT.cpp: + (DFG): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + +2013-02-18 Filip Pizlo <fpizlo@apple.com> + + Remove dead code for ValueToNumber from the DFG. + + Rubber stamped by Andy Estes. + + We killed ValueToNumber at some point, but forgot to kill all of the backend support + for it. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleMinMax): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + * dfg/DFGSpeculativeJIT64.cpp: + +2013-02-17 Csaba Osztrogonác <ossy@webkit.org> + + Unreviewed buildfix for JSVALUE32_64 builds after r143147. + + * jit/JIT.h: + +2013-02-17 Filip Pizlo <fpizlo@apple.com> + + Move all Structure out-of-line inline methods to StructureInlines.h + https://bugs.webkit.org/show_bug.cgi?id=110024 + + Rubber stamped by Mark Hahnenberg and Sam Weinig. + + This was supposed to be easy. + + But, initially, there was a Structure inline method in CodeBlock.h, and moving that + into StructureInlines.h meant that Operations.h included CodeBlock.h. This would + cause WebCore build failures, because CodeBlock.h transitively included the JSC + parser (via many, many paths), and the JSC parser defines tokens using enumeration + elements that CSSGrammar.cpp (generated by bison) would #define. For example, + bison would give CSSGrammar.cpp a #define FUNCTION 123, and would do so before + including anything interesting. The JSC parser would have an enum that included + FUNCTION as an element. Hence the JSC parser included into CSSGrammar.cpp would have + a token element called FUNCTION declared in an enumeration, but FUNCTION was + #define'd to 123, leading to a parser error. + + Wow. + + So I removed all transitive include paths from CodeBlock.h to the JSC Parser. I + believe I was able to do so without out-of-lining anything interesting or performance + critical. This is probably a purely good thing to have done: it will be nice to be + able to make changes to the parser without having to compile the universe. + + Of course, doing this caused a bunch of other things to not compile, since a bunch of + headers relied on things being implicitly included for them when they transitively + included the parser. I fixed a lot of that. + + Finally, I ended up removing the method that depended on CodeBlock.h from + StructureInlines.h, and putting it in Structure.cpp. That might seem like all of this + was a waste of time, except that I suspect it was a worthwhile forcing function for + cleaning up a bunch of cruft. + + * API/JSCallbackFunction.cpp: + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.h: + (JSC): + * bytecode/EvalCodeCache.h: + * bytecode/SamplingTool.h: + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::UnlinkedFunctionExecutable::parameterCount): + (JSC): + * bytecode/UnlinkedCodeBlock.h: + (UnlinkedFunctionExecutable): + * bytecompiler/BytecodeGenerator.h: + * bytecompiler/Label.h: + (JSC): + * dfg/DFGByteCodeParser.cpp: + * dfg/DFGByteCodeParser.h: + * dfg/DFGFPRInfo.h: + * dfg/DFGRegisterBank.h: + * heap/HandleStack.cpp: + * jit/JITWriteBarrier.h: + * parser/Nodes.h: + (JSC): + * parser/Parser.h: + * parser/ParserError.h: Added. + (JSC): + (JSC::ParserError::ParserError): + (ParserError): + (JSC::ParserError::toErrorObject): + * parser/ParserModes.h: + * parser/SourceProvider.cpp: Added. + (JSC): + (JSC::SourceProvider::SourceProvider): + (JSC::SourceProvider::~SourceProvider): + * parser/SourceProvider.h: + (JSC): + (SourceProvider): + * runtime/ArrayPrototype.cpp: + * runtime/DatePrototype.cpp: + * runtime/Executable.h: + * runtime/JSGlobalObject.cpp: + * runtime/JSGlobalObject.h: + (JSC): + * runtime/Operations.h: + * runtime/Structure.cpp: + (JSC::Structure::prototypeForLookup): + (JSC): + * runtime/Structure.h: + (JSC): + * runtime/StructureInlines.h: Added. + (JSC): + (JSC::Structure::create): + (JSC::Structure::createStructure): + (JSC::Structure::get): + (JSC::Structure::masqueradesAsUndefined): + (JSC::SlotVisitor::internalAppend): + (JSC::Structure::transitivelyTransitionedFrom): + (JSC::Structure::setEnumerationCache): + (JSC::Structure::enumerationCache): + (JSC::Structure::prototypeForLookup): + (JSC::Structure::prototypeChain): + (JSC::Structure::isValid): + * runtime/StructureRareData.cpp: + +2013-02-17 Roger Fong <roger_fong@apple.com> + + Unreviewed. Windows build fix. + + * runtime/CodeCache.h: + (CodeCacheMap): + +2013-02-16 Geoffrey Garen <ggaren@apple.com> + + Code cache should be explicit about what it caches + https://bugs.webkit.org/show_bug.cgi?id=110039 + + Reviewed by Oliver Hunt. + + This patch makes the code cache more explicit in two ways: + + (1) The cache caches top-level scripts. Any sub-functions executed as a + part of a script are cached with it and evicted with it. + + This simplifies things by eliminating out-of-band sub-function tracking, + and fixes pathological cases where functions for live scripts would be + evicted in favor of functions for dead scripts, and/or high probability + functions executed early in script lifetime would be evicted in favor of + low probability functions executed late in script lifetime, due to LRU. + + Statistical data from general browsing and PLT confirms that caching + functions independently of scripts is not profitable. + + (2) The cache tracks script size, not script count. + + This reduces the worst-case cache size by a factor of infinity. + + Script size is a reasonable first-order estimate of in-memory footprint + for a cached script because there are no syntactic constructs that have + super-linear memory footprint. + + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::generateFunctionCodeBlock): Moved this function out of the cache + because it does not consult the cache, and is not managed by it. + + (JSC::UnlinkedFunctionExecutable::visitChildren): Visit our code blocks + because they are strong references now, rather than weak, a la (1). + + (JSC::UnlinkedFunctionExecutable::codeBlockFor): Updated for interface changes. + + * bytecode/UnlinkedCodeBlock.h: + (UnlinkedFunctionExecutable): + (UnlinkedFunctionCodeBlock): Strong now, not weak, a la (1). + + * runtime/CodeCache.cpp: + (JSC::CodeCache::CodeCache): + * runtime/CodeCache.h: + (JSC::SourceCodeKey::length): + (SourceCodeKey): + (CodeCacheMap): + (JSC::CodeCacheMap::CodeCacheMap): + (JSC::CodeCacheMap::find): + (JSC::CodeCacheMap::set): + (JSC::CodeCacheMap::clear): + (CodeCache): + (JSC::CodeCache::clear): Removed individual function tracking, due to (1). + Added explicit character counting, for (2). + + You might think 16000000 characters is a lot. It is. But this patch + didn't establish that limit -- it just took the existing limit and + made it more visible. I intend to reduce the size of the cache in a + future patch. + +2013-02-16 Filip Pizlo <fpizlo@apple.com> + + Remove support for bytecode comments, since it doesn't build, and hasn't been used in a while. + https://bugs.webkit.org/show_bug.cgi?id=110035 + + Rubber stamped by Andreas Kling. + + There are other ways of achieving the same effect, like adding print statements to the bytecode generator. + The fact that this feature doesn't build and nobody noticed implies that it's probably not a popular + feature. As well, the amount of wiring that was required for it was quite big considering its relatively + modest utility. + + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/CodeBlock.cpp: + (JSC): + (JSC::CodeBlock::dumpBytecode): + (JSC::CodeBlock::CodeBlock): + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecode/Comment.h: Removed. + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::emitOpcode): + (JSC): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + (JSC::BytecodeGenerator::symbolTable): + +2013-02-16 Brent Fulgham <bfulgham@webkit.org> + + [Windows] Unreviewed Visual Studio 2010 build fix after r143117 + + * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Reference new path to property sheets. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + Build correction after new operator == added. + +2013-02-16 Filip Pizlo <fpizlo@apple.com> + + Fix indentation of Structure.h + + Rubber stamped by Mark Hahnenberg. + + * runtime/Structure.h: + +2013-02-16 Christophe Dumez <ch.dumez@sisa.samsung.com> + + Unreviewed build fix. + + Export symbol for new CString operator== operator to fix Windows build. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + +2013-02-15 Filip Pizlo <fpizlo@apple.com> + + Structure should be more methodical about the relationship between m_offset and m_propertyTable + https://bugs.webkit.org/show_bug.cgi?id=109978 + + Reviewed by Mark Hahnenberg. + + Allegedly, the previous relationship was that either m_propertyTable or m_offset + would be set, and if m_propertyTable was not set you could rebuild it. In reality, + we would sometimes "reset" both: some transitions wouldn't set m_offset, and other + transitions would clear the previous structure's m_propertyTable. So, in a + structure transition chain of A->B->C you could have: + + A transitions to B: B doesn't copy m_offset but does copy m_propertyTable, because + that seemed like a good idea at the time (this was a common idiom in the code). + B transitions to C: C steals B's m_propertyTable, leaving B with neither a + m_propertyTable nor a m_offset. + + Then we would ask for the size of the property storage of B and get the answer + "none". That's not good. + + Now, there is a new relationship, which, hopefully, should fix things: m_offset is + always set and always refers to the maximum offset ever used by the property table. + From this, you can infer both the inline and out-of-line property size, and + capacity. This is accomplished by having PropertyTable::add() take a + PropertyOffset reference, which must be Structure::m_offset. It will update this + offset. As well, all transitions now copy m_offset. And we frequently assert + (using RELEASE_ASSERT) that the m_offset matches what m_propertyTable would tell + you. Hence if you ever modify the m_propertyTable, you'll also update the offset. + If you ever copy the property table, you'll also copy the offset. Life should be + good, I think. + + * runtime/PropertyMapHashTable.h: + (JSC::PropertyTable::add): + * runtime/Structure.cpp: + (JSC::Structure::materializePropertyMap): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::removePropertyTransition): + (JSC::Structure::changePrototypeTransition): + (JSC::Structure::despecifyFunctionTransition): + (JSC::Structure::attributeChangeTransition): + (JSC::Structure::toDictionaryTransition): + (JSC::Structure::sealTransition): + (JSC::Structure::freezeTransition): + (JSC::Structure::preventExtensionsTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::flattenDictionaryStructure): + (JSC::Structure::checkConsistency): + (JSC::Structure::putSpecificValue): + (JSC::Structure::createPropertyMap): + (JSC::PropertyTable::checkConsistency): + * runtime/Structure.h: + (JSC): + (JSC::Structure::putWillGrowOutOfLineStorage): + (JSC::Structure::outOfLineCapacity): + (JSC::Structure::outOfLineSize): + (JSC::Structure::isEmpty): + (JSC::Structure::materializePropertyMapIfNecessary): + (JSC::Structure::materializePropertyMapIfNecessaryForPinning): + (Structure): + (JSC::Structure::checkOffsetConsistency): + +2013-02-15 Martin Robinson <mrobinson@igalia.com> + + [GTK] Spread the gyp build files throughout the tree + https://bugs.webkit.org/show_bug.cgi?id=109960 + + Reviewed by Dirk Pranke. + + * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Renamed from Source/WebKit/gtk/gyp/JavaScriptCore.gyp. + * JavaScriptCore.gyp/generate-derived-sources.sh: Renamed from Source/WebKit/gtk/gyp/generate-derived-sources.sh. + +2013-02-15 Filip Pizlo <fpizlo@apple.com> + + DFG SpeculativeJIT64 should be more precise about when it's dealing with a cell (even though it probably doesn't matter) + https://bugs.webkit.org/show_bug.cgi?id=109625 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compile): + +2013-02-15 Geoffrey Garen <ggaren@apple.com> + + Merged the global function cache into the source code cache + https://bugs.webkit.org/show_bug.cgi?id=108660 + + Reviewed by Sam Weinig. + + Responding to review comments by Darin Adler. + + * runtime/CodeCache.h: + (JSC::SourceCodeKey::SourceCodeKey): Don't initialize m_name and m_flags + in the hash table deleted value because they're meaningless. + +2013-02-14 Filip Pizlo <fpizlo@apple.com> + + DFG AbstractState should filter operands to NewArray more precisely + https://bugs.webkit.org/show_bug.cgi?id=109900 + + Reviewed by Mark Hahnenberg. + + NewArray for primitive indexing types speculates that the inputs are the appropriate + primitives. Now, the CFA filters the abstract state accordingly, as well. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + +2013-02-15 Andreas Kling <akling@apple.com> + + Yarr: Use OwnPtr to make pattern/disjunction/character-class ownership clearer. + <http://webkit.org/b/109218> + + Reviewed by Benjamin Poulain. + + - Let classes that manage lifetime of other objects hold on to them with OwnPtr instead of raw pointers. + - Placed some strategic Vector::shrinkToFit(), ::reserveInitialCapacity() and ::swap(). + + 668 kB progression on Membuster3. + + * yarr/YarrInterpreter.cpp: + (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd): + (JSC::Yarr::ByteCompiler::emitDisjunction): + (ByteCompiler): + * yarr/YarrInterpreter.h: + (JSC::Yarr::BytecodePattern::BytecodePattern): + (BytecodePattern): + * yarr/YarrJIT.cpp: + (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern): + (JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion): + (JSC::Yarr::YarrGenerator::opCompileBody): + * yarr/YarrPattern.cpp: + (JSC::Yarr::CharacterClassConstructor::charClass): + (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor): + (JSC::Yarr::YarrPatternConstructor::reset): + (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter): + (JSC::Yarr::YarrPatternConstructor::atomCharacterClassEnd): + (JSC::Yarr::YarrPatternConstructor::copyDisjunction): + (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets): + (JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses): + (JSC::Yarr::YarrPatternConstructor::optimizeBOL): + (JSC::Yarr::YarrPatternConstructor::containsCapturingTerms): + (JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions): + * yarr/YarrPattern.h: + (JSC::Yarr::PatternDisjunction::addNewAlternative): + (PatternDisjunction): + (YarrPattern): + (JSC::Yarr::YarrPattern::reset): + (JSC::Yarr::YarrPattern::newlineCharacterClass): + (JSC::Yarr::YarrPattern::digitsCharacterClass): + (JSC::Yarr::YarrPattern::spacesCharacterClass): + (JSC::Yarr::YarrPattern::wordcharCharacterClass): + (JSC::Yarr::YarrPattern::nondigitsCharacterClass): + (JSC::Yarr::YarrPattern::nonspacesCharacterClass): + (JSC::Yarr::YarrPattern::nonwordcharCharacterClass): + +2013-02-14 Geoffrey Garen <ggaren@apple.com> + + Merged the global function cache into the source code cache + https://bugs.webkit.org/show_bug.cgi?id=108660 + + Reviewed by Sam Weinig. + + This has a few benefits: + + (*) Saves a few kB by removing a second cache data structure. + + (*) Reduces the worst case memory usage of the cache by 1.75X. (Heavy + use of 'new Function' and other techniques could cause us to fill + both root caches, and they didn't trade off against each other.) + + (*) Paves the way for future improvements based on a non-trivial + cache key (for example, shrinkable pointer to the key string, and + more precise cache size accounting). + + Also cleaned up the cache implementation and simplified it a bit. + + * heap/Handle.h: + (HandleBase): + * heap/Strong.h: + (Strong): Build! + + * runtime/CodeCache.cpp: + (JSC): + (JSC::CodeCache::getCodeBlock): + (JSC::CodeCache::generateFunctionCodeBlock): + (JSC::CodeCache::getFunctionExecutableFromGlobalCode): + (JSC::CodeCache::usedFunctionCode): Updated for three interface changes: + + (*) SourceCodeKey is a class, not a pair. + + (*) Table values are abstract pointers, since they can be executables + or code blocks. (In a future patch, I'd like to change this so we + always store only code blocks. But that's too much for one patch.) + + (*) The cache function is named "set" because it always overwrites + unconditionally. + + * runtime/CodeCache.h: + (CacheMap): + (JSC::CacheMap::find): + (JSC::CacheMap::set): + (JSC::CacheMap::clear): Added support for specifying hash traits, so we + can use a SourceCodeKey. + + Removed side table and random number generator to save space and reduce + complexity. Hash tables are already random, so we don't need another source + of randomness. + + (SourceCodeKey): + (JSC::SourceCodeKey::SourceCodeKey): + (JSC::SourceCodeKey::isHashTableDeletedValue): + (JSC::SourceCodeKey::hash): + (JSC::SourceCodeKey::isNull): + (JSC::SourceCodeKey::operator==): + (JSC::SourceCodeKeyHash::hash): + (JSC::SourceCodeKeyHash::equal): + (SourceCodeKeyHash): + (SourceCodeKeyHashTraits): + (JSC::SourceCodeKeyHashTraits::isEmptyValue): A SourceCodeKey is just a + fancy triplet: source code string; function name (or null, for non-functions); + and flags. Flags and function name distinguish between functions and programs + with identical code, so they can live in the same cache. + + I chose to use the source code string as the primary hashing reference + because it's likely to be unique. We can use profiling to choose another + technique in future, if collisions between functions and programs prove + to be hot. I suspect they won't. + + (JSC::CodeCache::clear): + (CodeCache): Removed the second cache. + + * heap/Handle.h: + (HandleBase): + * heap/Strong.h: + (Strong): + * runtime/CodeCache.cpp: + (JSC): + (JSC::CodeCache::getCodeBlock): + (JSC::CodeCache::generateFunctionCodeBlock): + (JSC::CodeCache::getFunctionExecutableFromGlobalCode): + (JSC::CodeCache::usedFunctionCode): + * runtime/CodeCache.h: + (JSC): + (CacheMap): + (JSC::CacheMap::find): + (JSC::CacheMap::set): + (JSC::CacheMap::clear): + (SourceCodeKey): + (JSC::SourceCodeKey::SourceCodeKey): + (JSC::SourceCodeKey::isHashTableDeletedValue): + (JSC::SourceCodeKey::hash): + (JSC::SourceCodeKey::isNull): + (JSC::SourceCodeKey::operator==): + (JSC::SourceCodeKeyHash::hash): + (JSC::SourceCodeKeyHash::equal): + (SourceCodeKeyHash): + (SourceCodeKeyHashTraits): + (JSC::SourceCodeKeyHashTraits::isEmptyValue): + (JSC::CodeCache::clear): + (CodeCache): + +2013-02-14 Tony Chang <tony@chromium.org> + + Unreviewed, set svn:eol-style native for .sln, .vcproj, and .vsprops files. + https://bugs.webkit.org/show_bug.cgi?id=96934 + + * JavaScriptCore.vcproj/JavaScriptCore.sln: Modified property svn:eol-style. + * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Modified property svn:eol-style. + * JavaScriptCore.vcproj/testRegExp/testRegExpCommon.vsprops: Added property svn:eol-style. + * JavaScriptCore.vcproj/testRegExp/testRegExpDebug.vsprops: Added property svn:eol-style. + * JavaScriptCore.vcproj/testRegExp/testRegExpDebugAll.vsprops: Added property svn:eol-style. + * JavaScriptCore.vcproj/testRegExp/testRegExpDebugCairoCFLite.vsprops: Added property svn:eol-style. + * JavaScriptCore.vcproj/testRegExp/testRegExpProduction.vsprops: Added property svn:eol-style. + * JavaScriptCore.vcproj/testRegExp/testRegExpRelease.vsprops: Added property svn:eol-style. + * JavaScriptCore.vcproj/testRegExp/testRegExpReleaseCairoCFLite.vsprops: Added property svn:eol-style. + * JavaScriptCore.vcproj/testRegExp/testRegExpReleasePGO.vsprops: Added property svn:eol-style. + +2013-02-14 Tony Chang <tony@chromium.org> + + Unreviewed, set svn:eol-style CRLF for .sln files. + + * JavaScriptCore.vcproj/JavaScriptCore.sln: Modified property svn:eol-style. + * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Modified property svn:eol-style. + +2013-02-14 David Kilzer <ddkilzer@apple.com> + + [Mac] Clean up WARNING_CFLAGS + <http://webkit.org/b/109747> + <rdar://problem/13208373> + + Reviewed by Mark Rowe. + + * Configurations/Base.xcconfig: Use + GCC_WARN_64_TO_32_BIT_CONVERSION to enable and disable + -Wshorten-64-to-32 rather than WARNING_CFLAGS. + + * JavaScriptCore.vcproj/JavaScriptCore.sln: Modified property svn:eol-style. + * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Modified property svn:eol-style. + +2013-02-13 Anders Carlsson <andersca@apple.com> + + Better build fix. + + * API/tests/testapi.c: + (assertEqualsAsNumber): + (main): + +2013-02-13 Roger Fong <roger_fong@apple.com> + + Unreviewed. Build fix. + + * API/tests/testapi.c: + (assertEqualsAsNumber): + (main): + +2013-02-13 Oliver Hunt <oliver@apple.com> + + Yet another build fix + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + +2013-02-13 Zan Dobersek <zdobersek@igalia.com> + + The 'global isinf/isnan' compiler quirk required when using clang with libstdc++ + https://bugs.webkit.org/show_bug.cgi?id=109325 + + Reviewed by Anders Carlsson. + + Prefix calls to the isinf and isnan methods with std::, declaring we want to use the + two methods as they're provided by the C++ standard library being used. + + * API/JSValueRef.cpp: + (JSValueMakeNumber): + * JSCTypedArrayStubs.h: + (JSC): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitLoad): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::constantNaN): + * offlineasm/cloop.rb: + * runtime/DateConstructor.cpp: + (JSC::dateUTC): Also include an opportunistic style fix. + * runtime/DateInstance.cpp: + (JSC::DateInstance::calculateGregorianDateTime): + (JSC::DateInstance::calculateGregorianDateTimeUTC): + * runtime/DatePrototype.cpp: + (JSC::dateProtoFuncGetMilliSeconds): + (JSC::dateProtoFuncGetUTCMilliseconds): + (JSC::setNewValueFromTimeArgs): + (JSC::setNewValueFromDateArgs): + (JSC::dateProtoFuncSetYear): + * runtime/JSCJSValue.cpp: + (JSC::JSValue::toInteger): + * runtime/JSDateMath.cpp: + (JSC::getUTCOffset): + (JSC::parseDateFromNullTerminatedCharacters): + (JSC::parseDate): + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::globalFuncIsNaN): + * runtime/MathObject.cpp: + (JSC::mathProtoFuncMax): + (JSC::mathProtoFuncMin): + (JSC::mathProtoFuncPow): + * runtime/PropertyDescriptor.cpp: + (JSC::sameValue): + +2013-02-13 Filip Pizlo <fpizlo@apple.com> + + Change another use of (SpecCell & ~SpecString) to SpecObject. + + Reviewed by Mark Hahnenberg. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + +2013-02-13 Filip Pizlo <fpizlo@apple.com> + + ForwardInt32ToDouble is not in DFG::MinifiedNode's list of relevant node types + https://bugs.webkit.org/show_bug.cgi?id=109726 + + Reviewed by Mark Hahnenberg. + + If you add it to the list of relevant node types, you also need to make sure + it's listed as either hasChild or one of the other kinds. Otherwise you get + an assertion. This is causing test failures in run-javascriptcore-tests. + + * dfg/DFGMinifiedNode.h: + (JSC::DFG::MinifiedNode::hasChild): + +2013-02-13 Oliver Hunt <oliver@apple.com> + + Build fix. + + Rearranged the code somewhat to reduce the number of + DFG related ifdefs. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + +2013-02-13 Filip Pizlo <fpizlo@apple.com> + + ForwardInt32ToDouble is not in DFG::MinifiedNode's list of relevant node types + https://bugs.webkit.org/show_bug.cgi?id=109726 + + Reviewed by Gavin Barraclough. + + This is asymptomatic because ForwardInt32ToDouble is only used in SetLocals, in + which case the value is already stored to the stack. Still, we should fix this. + + * dfg/DFGMinifiedNode.h: + (JSC::DFG::belongsInMinifiedGraph): + +2013-02-12 Filip Pizlo <fpizlo@apple.com> + + DFG LogicalNot/Branch peephole removal and inversion ignores the possibility of things exiting + https://bugs.webkit.org/show_bug.cgi?id=109489 + + Reviewed by Mark Hahnenberg. + + If things can exit between the LogicalNot and the Branch then don't peephole. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + +2013-02-13 Oliver Hunt <oliver@apple.com> + + Remove unnecessary indirection to non-local variable access operations + https://bugs.webkit.org/show_bug.cgi?id=109724 + + Reviewed by Filip Pizlo. + + Linked bytecode now stores a direct pointer to the resolve operation + vectors, so the interpreter no longer needs a bunch of indirection to + to perform non-local lookup. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecode/Instruction.h: + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::parseResolveOperations): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCapabilities.h: + (JSC::DFG::canInlineOpcode): + * dfg/DFGGraph.h: + (ResolveGlobalData): + (ResolveOperationData): + (PutToBaseOperationData): + * dfg/DFGSpeculativeJIT.h: + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_put_to_base): + (JSC::JIT::emit_op_resolve): + (JSC::JIT::emitSlow_op_resolve): + (JSC::JIT::emit_op_resolve_base): + (JSC::JIT::emitSlow_op_resolve_base): + (JSC::JIT::emit_op_resolve_with_base): + (JSC::JIT::emitSlow_op_resolve_with_base): + (JSC::JIT::emit_op_resolve_with_this): + (JSC::JIT::emitSlow_op_resolve_with_this): + (JSC::JIT::emitSlow_op_put_to_base): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_put_to_base): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter.asm: + +2013-02-13 Zoltan Herczeg <zherczeg@webkit.org> + + replaceWithJump should not decrease the offset by 1 on ARM traditional. + https://bugs.webkit.org/show_bug.cgi?id=109689 + + Reviewed by Oliver Hunt. + + * assembler/ARMAssembler.h: + (JSC::ARMAssembler::replaceWithJump): + +2013-02-12 Joseph Pecoraro <pecoraro@apple.com> + + [iOS] Enable PAGE_VISIBILITY_API + https://bugs.webkit.org/show_bug.cgi?id=109399 + + Reviewed by David Kilzer. + + * Configurations/FeatureDefines.xcconfig: + +2013-02-12 Filip Pizlo <fpizlo@apple.com> + + Renamed SpecObjectMask to SpecObject. + + Rubber stamped by Mark Hahnenberg. + + "SpecObjectMask" is a weird name considering that a bunch of the other speculated + types are also masks, but don't have "Mask" in the name. + + * bytecode/SpeculatedType.h: + (JSC): + (JSC::isObjectSpeculation): + (JSC::isObjectOrOtherSpeculation): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + +2013-02-12 Filip Pizlo <fpizlo@apple.com> + + DFG CFA doesn't filter precisely enough for CompareStrictEq + https://bugs.webkit.org/show_bug.cgi?id=109618 + + Reviewed by Mark Hahnenberg. + + The backend speculates object for this case, but the CFA was filtering on + (SpecCell & ~SpecString) | SpecOther. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + +2013-02-12 Martin Robinson <mrobinson@igalia.com> + + Fix the gyp build of JavaScriptCore. + + * JavaScriptCore.gypi: Added some missing DFG files to the source list. + +2013-02-12 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r142387. + http://trac.webkit.org/changeset/142387 + https://bugs.webkit.org/show_bug.cgi?id=109601 + + caused all layout and jscore tests on windows to fail + (Requested by kling on #webkit). + + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): + * bytecode/UnlinkedCodeBlock.h: + (UnlinkedCodeBlock): + +2013-02-11 Filip Pizlo <fpizlo@apple.com> + + DFG CompareEq optimization should be retuned + https://bugs.webkit.org/show_bug.cgi?id=109545 + + Reviewed by Mark Hahnenberg. + + - Made the object-to-object equality case work again by hoisting the if statement + for it. Previously, object-to-object equality would be compiled as + object-to-object-or-other. + + - Added AbstractState guards for most of the type checks that the object equality + code uses. + + Looks like a hint of a speed-up on all of the things. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): + (JSC::DFG::SpeculativeJIT::compare): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + +2013-02-12 Gabor Rapcsanyi <rgabor@webkit.org> + + JSC asserting with long parameter list functions in debug mode on ARM traditional + https://bugs.webkit.org/show_bug.cgi?id=109565 + + Reviewed by Zoltan Herczeg. + + Increase the value of sequenceGetByIdSlowCaseInstructionSpace to 80. + + * jit/JIT.h: + +2013-02-11 Oliver Hunt <oliver@apple.com> + + Make JSC API more NULL tolerant + https://bugs.webkit.org/show_bug.cgi?id=109515 + + Reviewed by Mark Hahnenberg. + + We do so much marshalling for the C API these days anyway that a single null + check isn't a performance issue. Yet the existing "null is unsafe" behaviour + leads to crashes in embedding applications whenever there's an untested code + path, so it seems having defined behaviour is superior. + + * API/APICast.h: + (toJS): + (toJSForGC): + * API/JSObjectRef.cpp: + (JSObjectIsFunction): + (JSObjectCallAsFunction): + (JSObjectIsConstructor): + (JSObjectCallAsConstructor): + * API/tests/testapi.c: + (main): + +2013-02-11 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, adding a FIXME to remind ourselves of a bug. + https://bugs.webkit.org/show_bug.cgi?id=109487 + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileStrictEqForConstant): + +2013-02-11 Filip Pizlo <fpizlo@apple.com> + + Strange bug in DFG OSR in JSC + https://bugs.webkit.org/show_bug.cgi?id=109491 + + Reviewed by Mark Hahnenberg. + + Int32ToDouble was being injected after a side-effecting operation and before a SetLocal. Anytime we + inject something just before a SetLocal we should be aware that the previous operation may have been + a side-effect associated with the current code origin. Hence, we should use a forward exit. + Int32ToDouble does not do forward exits by default. + + This patch adds a forward-exiting form of Int32ToDouble, for use in SetLocal Int32ToDouble injections. + Changed the CSE and other things to treat these nodes identically, but for the exit strategy to be + distinct (Int32ToDouble -> backward, ForwardInt32ToDouble -> forward). The use of the NodeType for + signaling exit direction is not "great" but it's what we use in other places already (like + ForwardCheckStructure). + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::int32ToDoubleCSE): + (CSEPhase): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCommon.h: + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::fixDoubleEdge): + (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): + * dfg/DFGNode.h: + (JSC::DFG::Node::willHaveCodeGenOrOSR): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): + * dfg/DFGSpeculativeJIT.h: + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGVariableEventStream.cpp: + (JSC::DFG::VariableEventStream::reconstruct): + +2013-02-11 Filip Pizlo <fpizlo@apple.com> + + NonStringCell and Object are practically the same thing for the purpose of speculation + https://bugs.webkit.org/show_bug.cgi?id=109492 + + Reviewed by Mark Hahnenberg. + + Removed isNonStringCellSpeculation, and made all callers use isObjectSpeculation. + + Changed isNonStringCellOrOtherSpeculation to be isObjectOrOtherSpeculation. + + I believe this is correct because even weird object types like JSNotAnObject end up + being "objects" from the standpoint of our typesystem. Anyway, the assumption that + "is cell but not a string" equates to "object" is an assumption that is already made + in other places in the system so there's little value in being paranoid about it. + + * bytecode/SpeculatedType.h: + (JSC::isObjectSpeculation): + (JSC::isObjectOrOtherSpeculation): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGNode.h: + (Node): + (JSC::DFG::Node::shouldSpeculateObjectOrOther): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): + (JSC::DFG::SpeculativeJIT::compare): + (JSC::DFG::SpeculativeJIT::compileStrictEq): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): + (JSC::DFG::SpeculativeJIT::emitBranch): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): + (JSC::DFG::SpeculativeJIT::emitBranch): + (JSC::DFG::SpeculativeJIT::compile): + +2013-02-10 Filip Pizlo <fpizlo@apple.com> + + DFG CompareEq(a, null) and CompareStrictEq(a, const) are unsound with respect to constant folding + https://bugs.webkit.org/show_bug.cgi?id=109387 + + Reviewed by Oliver Hunt and Mark Hahnenberg. + + Lock in the decision to use a non-speculative constant comparison as early as possible + and don't let the CFA change it by folding constants. This might be a performance + penalty on some really weird code (FWIW, I haven't seen this on benchmarks), but on + the other hand it completely side-steps the unsoundness that the bug speaks of. + + Rolling back in after adding 32-bit path. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::isConstantForCompareStrictEq): + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileStrictEq): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-02-10 Filip Pizlo <fpizlo@apple.com> + + DFG TypeOf implementation should have its backend code aligned to what the CFA does + https://bugs.webkit.org/show_bug.cgi?id=109385 + + Reviewed by Sam Weinig. + + The problem was that if we ended up trying to constant fold, but didn't succeed + because of prediction mismatches, then we would also fail to do filtration. + + Rearranged the control flow in the CFA to fix that. + + As far as I know, this is asymptomatic - it's sort of OK for the CFA to prove less + things, which is what the bug was. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + +2013-02-11 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r142491. + http://trac.webkit.org/changeset/142491 + https://bugs.webkit.org/show_bug.cgi?id=109470 + + broke the 32 bit build (Requested by jessieberlin on #webkit). + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileStrictEq): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-02-10 Filip Pizlo <fpizlo@apple.com> + + DFG CompareEq(a, null) and CompareStrictEq(a, const) are unsound with respect to constant folding + https://bugs.webkit.org/show_bug.cgi?id=109387 + + Reviewed by Oliver Hunt. + + Lock in the decision to use a non-speculative constant comparison as early as possible + and don't let the CFA change it by folding constants. This might be a performance + penalty on some really weird code (FWIW, I haven't seen this on benchmarks), but on + the other hand it completely side-steps the unsoundness that the bug speaks of. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::isConstantForCompareStrictEq): + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileStrictEq): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-02-11 Csaba Osztrogonác <ossy@webkit.org> + + Unreviewed fix after r13954 for !ENABLE(JIT) builds. + + * llint/LowLevelInterpreter.cpp: + +2013-02-11 Gabor Rapcsanyi <rgabor@webkit.org> + + JSC build failing with verbose debug mode + https://bugs.webkit.org/show_bug.cgi?id=109441 + + Reviewed by Darin Adler. + + Fixing some verbose messages which caused build errors. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::mergeToSuccessors): + * dfg/DFGCFAPhase.cpp: + (JSC::DFG::CFAPhase::performBlockCFA): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::setReplacement): + (JSC::DFG::CSEPhase::eliminate): + * dfg/DFGPredictionInjectionPhase.cpp: + (JSC::DFG::PredictionInjectionPhase::run): + +2013-02-10 Martin Robinson <mrobinson@igalia.com> + + Fix the GTK+ gyp build + + * JavaScriptCore.gypi: Update the source list to accurately + reflect what's in the repository and remove the offsets extractor + from the list of JavaScriptCore files. It's only used to build + the extractor binary. + +2013-02-09 Andreas Kling <akling@apple.com> + + Shrink-wrap UnlinkedCodeBlock members. + <http://webkit.org/b/109368> + + Reviewed by Oliver Hunt. + + Rearrange the members of UnlinkedCodeBlock to avoid unnecessary padding on 64-bit. + Knocks ~600 KB off of the Membuster3 peak. + + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): + * bytecode/UnlinkedCodeBlock.h: + (UnlinkedCodeBlock): + +2013-02-08 Filip Pizlo <fpizlo@apple.com> + + DFG should allow phases to break Phi's and then have one phase to rebuild them + https://bugs.webkit.org/show_bug.cgi?id=108414 + + Reviewed by Mark Hahnenberg. + + Introduces two new DFG forms: LoadStore and ThreadedCPS. These are described in + detail in DFGCommon.h. + + Consequently, DFG phases no longer have to worry about preserving data flow + links between basic blocks. It is generally always safe to request that the + graph be dethreaded (Graph::dethread), which brings it into LoadStore form, where + the data flow is implicit. In this form, only liveness-at-head needs to be + preserved. + + All of the machinery for "threading" the graph to introduce data flow between + blocks is now moved out of the bytecode parser and into the CPSRethreadingPhase. + All phases that previously did this maintenance themselves now just rely on + being able to dethread the graph. The one exception is the structure check + hoising phase, which operates over a threaded graph and preserves it, for the + sake of performance. + + Also moved two other things into their own phases: unification (previously found + in the parser) and prediction injection (previously found in various places). + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/Operands.h: + (Operands): + (JSC::Operands::sizeFor): + (JSC::Operands::atFor): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::mergeStateAtTail): + * dfg/DFGAllocator.h: + (JSC::DFG::::allocateSlow): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGBasicBlockInlines.h: + (DFG): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getLocal): + (JSC::DFG::ByteCodeParser::getArgument): + (JSC::DFG::ByteCodeParser::flushDirect): + (JSC::DFG::ByteCodeParser::parseBlock): + (DFG): + (JSC::DFG::ByteCodeParser::parse): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::killUnreachable): + (JSC::DFG::CFGSimplificationPhase::keepOperandAlive): + (CFGSimplificationPhase): + (JSC::DFG::CFGSimplificationPhase::fixJettisonedPredecessors): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + * dfg/DFGCPSRethreadingPhase.cpp: Added. + (DFG): + (CPSRethreadingPhase): + (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase): + (JSC::DFG::CPSRethreadingPhase::run): + (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes): + (JSC::DFG::CPSRethreadingPhase::clearVariablesAtHeadAndTail): + (JSC::DFG::CPSRethreadingPhase::addPhiSilently): + (JSC::DFG::CPSRethreadingPhase::addPhi): + (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): + (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocal): + (JSC::DFG::CPSRethreadingPhase::canonicalizeSetLocal): + (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor): + (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocal): + (JSC::DFG::CPSRethreadingPhase::canonicalizeSetArgument): + (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock): + (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlocks): + (JSC::DFG::CPSRethreadingPhase::propagatePhis): + (JSC::DFG::CPSRethreadingPhase::PhiStackEntry::PhiStackEntry): + (PhiStackEntry): + (JSC::DFG::CPSRethreadingPhase::phiStackFor): + (JSC::DFG::performCPSRethreading): + * dfg/DFGCPSRethreadingPhase.h: Added. + (DFG): + * dfg/DFGCSEPhase.cpp: + (CSEPhase): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCommon.cpp: + (WTF): + (WTF::printInternal): + * dfg/DFGCommon.h: + (JSC::DFG::logCompilationChanges): + (DFG): + (WTF): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::Graph): + (JSC::DFG::Graph::dump): + (JSC::DFG::Graph::dethread): + (JSC::DFG::Graph::collectGarbage): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::performSubstitution): + (Graph): + (JSC::DFG::Graph::performSubstitutionForEdge): + (JSC::DFG::Graph::convertToConstant): + * dfg/DFGNode.h: + (JSC::DFG::Node::convertToPhantomLocal): + (Node): + (JSC::DFG::Node::convertToGetLocal): + (JSC::DFG::Node::hasVariableAccessData): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPhase.cpp: + (JSC::DFG::Phase::beginPhase): + * dfg/DFGPhase.h: + (JSC::DFG::runAndLog): + * dfg/DFGPredictionInjectionPhase.cpp: Added. + (DFG): + (PredictionInjectionPhase): + (JSC::DFG::PredictionInjectionPhase::PredictionInjectionPhase): + (JSC::DFG::PredictionInjectionPhase::run): + (JSC::DFG::performPredictionInjection): + * dfg/DFGPredictionInjectionPhase.h: Added. + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::run): + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * dfg/DFGUnificationPhase.cpp: Added. + (DFG): + (UnificationPhase): + (JSC::DFG::UnificationPhase::UnificationPhase): + (JSC::DFG::UnificationPhase::run): + (JSC::DFG::performUnification): + * dfg/DFGUnificationPhase.h: Added. + (DFG): + * dfg/DFGValidate.cpp: + (JSC::DFG::Validate::validate): + (JSC::DFG::Validate::dumpGraphIfAppropriate): + * dfg/DFGVirtualRegisterAllocationPhase.cpp: + (JSC::DFG::VirtualRegisterAllocationPhase::run): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::setUpCall): + * runtime/JSCJSValue.cpp: + (JSC::JSValue::dump): + * runtime/JSString.h: + (JSString): + * runtime/Options.h: + (JSC): + +2013-02-08 Jer Noble <jer.noble@apple.com> + + Bring WebKit up to speed with latest Encrypted Media spec. + https://bugs.webkit.org/show_bug.cgi?id=97037 + + Reviewed by Eric Carlson. + + Define the ENABLE_ENCRYPTED_MEDIA_V2 setting. + + * Configurations/FeatureDefines.xcconfig: + +2013-02-08 Gavin Barraclough <barraclough@apple.com> + + Objective-C API for JavaScriptCore + https://bugs.webkit.org/show_bug.cgi?id=105889 + + Reviewed by Joseph Pecoraro + + Following up on review comments, mostly typos. + + * API/JSBlockAdaptor.h: + * API/JSBlockAdaptor.mm: + (-[JSBlockAdaptor blockFromValue:inContext:withException:]): + * API/JSContext.h: + * API/JSExport.h: + * API/JSValue.h: + * API/JSValue.mm: + * API/JSWrapperMap.mm: + (selectorToPropertyName): + (-[JSWrapperMap classInfoForClass:]): + (-[JSWrapperMap wrapperForObject:]): + +2013-02-08 Martin Robinson <mrobinson@igalia.com> + + [GTK] Add an experimental gyp build + https://bugs.webkit.org/show_bug.cgi?id=109003 + + Reviewed by Gustavo Noronha Silva. + + * JavaScriptCore.gypi: Update the list of source files to include those + necessary for the GTK+ build. + +2013-02-08 Andreas Kling <akling@apple.com> + + JSC: Lower minimum PropertyTable size. + <http://webkit.org/b/109247> + + Reviewed by Darin Adler. + + Lower the minimum table size for PropertyTable from 16 to 8. + 3.32 MB progression on Membuster3 (a ~13% reduction in memory used by PropertyTables.) + + * runtime/PropertyMapHashTable.h: + (PropertyTable): + (JSC::PropertyTable::sizeForCapacity): + +2013-02-07 Roger Fong <roger_fong@apple.com> + + Unreviewed. More VS2010 WebKit solution touchups. + Make JavaScriptCoreExports.def.in be treated as a custom build file so that changes to it cause the exports to be rebuilt. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: + +2013-02-07 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: testapi.mm should use ARC + https://bugs.webkit.org/show_bug.cgi?id=107838 + + Reviewed by Mark Rowe. + + Removing the changes to the Xcode project file and moving the equivalent flags into + the ToolExecutable xcconfig file. + + * Configurations/ToolExecutable.xcconfig: + * JavaScriptCore.xcodeproj/project.pbxproj: + +2013-02-07 Brent Fulgham <bfulgham@webkit.org> + + [Windows] Unreviewed Visual Studio 2010 build fixes after r142179. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: Correct changed symbols + * JavaScriptCore.vcxproj/JavaScriptCoreExports.def: Removed autogenerated file. + +2013-02-05 Filip Pizlo <fpizlo@apple.com> + + DFG::ByteCodeParser should do surgical constant folding to reduce load on the optimization fixpoint + https://bugs.webkit.org/show_bug.cgi?id=109000 + + Reviewed by Oliver Hunt. + + Previously our source parser's ASTBuilder did some surgical constant folding, but it + didn't cover some cases. It was particularly incapable of doing constant folding for + cases where we do some minimal loop peeling in the bytecode generator - since it + didn't "see" those constants prior to the peeling. Example: + + for (var i = 0; i < 4; ++i) + things; + + This will get peeled just a bit by the bytecode generator, so that the "i < 4" is + duplicated both at the top of the loop and the bottom. This means that we have a + constant comparison: "0 < 4", which the bytecode generator emits without any further + thought. + + The DFG optimization fixpoint of course folds this and simplifies the CFG + accordingly, but this incurs a compile-time cost. The purpose of this change is to + do some surgical constant folding in the DFG's bytecode parser, so that such + constructs reduce load on the CFG simplifier and the optimization fixpoint. The goal + is not to cover all cases, since the DFG CFA and CFG simplifier have a powerful + sparse conditional constant propagation that we can always fall back on. Instead the + goal is to cover enough cases that for common small functions we don't have to + perform such transformations, thereby reducing compile times. + + This also refactors m_inlineStackEntry->m_inlineCallFrame to be a handy method call + and also adds the notion of a TriState-based JSValue::pureToBoolean(). Both of these + things are used by the folder. + + As well, care has been taken to make sure that the bytecode parser only does folding + that is statically provable, and that doesn't arise out of speculation. This means + we cannot fold on data flow that crosses inlining boundaries. On the other hand, the + folding that the bytecode parser uses doesn't require phantoming anything. Such is + the trade-off: for anything that we do need phantoming, we defer it to the + optimization fixpoint. + + Slight SunSpider speed-up. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::get): + (JSC::DFG::ByteCodeParser::getLocal): + (JSC::DFG::ByteCodeParser::setLocal): + (JSC::DFG::ByteCodeParser::flushDirect): + (JSC::DFG::ByteCodeParser::flushArgumentsAndCapturedVariables): + (JSC::DFG::ByteCodeParser::toInt32): + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::inlineCallFrame): + (JSC::DFG::ByteCodeParser::currentCodeOrigin): + (JSC::DFG::ByteCodeParser::canFold): + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::getScope): + (JSC::DFG::ByteCodeParser::parseResolveOperations): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::parseCodeBlock): + * dfg/DFGNode.h: + (JSC::DFG::Node::isStronglyProvedConstantIn): + (Node): + * runtime/JSCJSValue.h: + * runtime/JSCJSValueInlines.h: + (JSC::JSValue::pureToBoolean): + (JSC): + +2013-02-07 Zoltan Herczeg <zherczeg@webkit.org> + + Invalid code is generated for storing constants with baseindex addressing modes on ARM traditional. + https://bugs.webkit.org/show_bug.cgi?id=109050 + + Reviewed by Oliver Hunt. + + The S! scratch register is reused, but it should contain the constant value. + + * assembler/ARMAssembler.cpp: + (JSC::ARMAssembler::baseIndexTransfer32): + (JSC::ARMAssembler::baseIndexTransfer16): + +2013-02-07 Andras Becsi <andras.becsi@digia.com> + + [Qt] Use GNU ar's thin archive format for intermediate static libs + https://bugs.webkit.org/show_bug.cgi?id=109052 + + Reviewed by Jocelyn Turcotte. + + Adjust project files that used activeBuildConfig() + to use targetSubDir(). + + * JavaScriptCore.pri: + * LLIntOffsetsExtractor.pro: + * Target.pri: + +2013-02-06 Roger Fong <roger_fong@apple.com> + + Unreviewed. Touchups to VS2010 WebKit solution. + Fix an export generator script, modify some property sheets, add resouce file. + + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorDebug.props: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props: + * JavaScriptCore.vcxproj/resource.h: Added. + +2013-02-06 Ilya Tikhonovsky <loislo@chromium.org> + + Web Inspector: Native Memory Instrumentation: assign class name to the heap graph node automatically + https://bugs.webkit.org/show_bug.cgi?id=107262 + + Reviewed by Yury Semikhatsky. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + +2013-02-06 Mike West <mkwst@chromium.org> + + Add an ENABLE_NOSNIFF feature flag. + https://bugs.webkit.org/show_bug.cgi?id=109029 + + Reviewed by Jochen Eisinger. + + This new flag will control the behavior of 'X-Content-Type-Options: nosniff' + when processing script and other resource types. + + * Configurations/FeatureDefines.xcconfig: + +2013-02-05 Mark Hahnenberg <mhahnenberg@apple.com> + + put_to_base should emit a Phantom for "value" across the ForceOSRExit + https://bugs.webkit.org/show_bug.cgi?id=108998 + + Reviewed by Oliver Hunt. + + Otherwise, the OSR exit compiler could clobber it, which would lead to badness. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::tallyFrequentExitSites): Build fixes for when DFG debug logging is enabled. + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): Added extra Phantoms for the "value" field where needed. + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): Ditto. + +2013-02-05 Michael Saboff <msaboff@apple.com> + + Crash at JSC::call when loading www.gap.com with JSVALUE32_64 Enabled + https://bugs.webkit.org/show_bug.cgi?id=108991 + + Reviewed by Oliver Hunt. + + Changed the restoration from calleeGPR to nonArgGPR0 because the restoration of the return location + may step on calleeGPR is it happen to be nonArgGPR2. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::dfgLinkClosureCall): + +2013-02-05 Roger Fong <roger_fong@apple.com> + + Add a JavaScriptCore Export Generator project. + https://bugs.webkit.org/show_bug.cgi?id=108971. + + Reviewed by Brent Fulgham. + + * JavaScriptCore.vcxproj/JavaScriptCore.sln: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.filters: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj.user: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorBuildCmd.cmd: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorCommon.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorDebug.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPostBuild.cmd: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorPreBuild.cmd: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGeneratorRelease.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in: Added. + +2013-02-04 Filip Pizlo <fpizlo@apple.com> + + DFG should have a precise view of jump targets + https://bugs.webkit.org/show_bug.cgi?id=108868 + + Reviewed by Oliver Hunt. + + Previously, the DFG relied entirely on the CodeBlock's jump targets list for + determining when to break basic blocks. This worked great, except sometimes it + would be too conservative since the CodeBlock just says where the bytecode + generator inserted labels. + + This change keeps the old jump target list in CodeBlock since it is still + valuable to the baseline JIT, but switches the DFG to use its own jump target + calculator. This ought to reduce pressure on the DFG simplifier, which would + previously do a lot of work to try to merge redundantly created basic blocks. + It appears to be a 1% progression on SunSpider. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/PreciseJumpTargets.cpp: Added. + (JSC): + (JSC::addSimpleSwitchTargets): + (JSC::computePreciseJumpTargets): + * bytecode/PreciseJumpTargets.h: Added. + (JSC): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseCodeBlock): + +2013-02-01 Roger Fong <roger_fong@apple.com> + + Make ConfigurationBuildDir include directories precede WebKitLibraries in JSC. + https://bugs.webkit.org/show_bug.cgi?id=108693. + + Rubberstamped by Timothy Horton. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: + +2013-02-04 Mark Hahnenberg <mhahnenberg@apple.com> + + Structure::m_outOfLineCapacity is unnecessary + https://bugs.webkit.org/show_bug.cgi?id=108206 + + Reviewed by Darin Adler. + + Simplifying the utility functions that we use since we don't need a + bunch of fancy templates for this one specific call site. + + * runtime/Structure.h: + (JSC::Structure::outOfLineCapacity): + +2013-02-05 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: testapi.mm should use ARC + https://bugs.webkit.org/show_bug.cgi?id=107838 + + Reviewed by Oliver Hunt. + + In ToT testapi.mm uses the Obj-C garbage collector, which hides a lot of our object lifetime bugs. + We should enable ARC, since that is what most of our clients will be using. We use Xcode project + settings to make sure we don't try to compile ARC on 32-bit. + + * API/tests/testapi.mm: + (+[TestObject testObject]): + (testObjectiveCAPI): + * JavaScriptCore.xcodeproj/project.pbxproj: + +2013-02-05 Brent Fulgham <bfulgham@webkit.org> + + [Windows] Unreviewed VS2010 Build Correction after r141651 + + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add missing + StructureRareData.h and StructureRareData.cpp files. + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto. + +2013-02-05 Michael Saboff <msaboff@apple.com> + + r141788 won't build due to not having all changes needed by Node* change + https://bugs.webkit.org/show_bug.cgi?id=108944 + + Reviewed by David Kilzer. + + Fixed three instances of integerResult(..., m_compileIndex) to be integerResult(..., node). + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileSoftModulo): + (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForARMv7s): + +2013-02-04 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r141809. + http://trac.webkit.org/changeset/141809 + https://bugs.webkit.org/show_bug.cgi?id=108860 + + ARC isn't supported on 32-bit. (Requested by mhahnenberg on + #webkit). + + * API/tests/testapi.mm: + (+[TestObject testObject]): + (testObjectiveCAPI): + * JavaScriptCore.xcodeproj/project.pbxproj: + +2013-02-04 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: testapi.mm should use ARC + https://bugs.webkit.org/show_bug.cgi?id=107838 + + Reviewed by Oliver Hunt. + + In ToT testapi.mm uses the Obj-C garbage collector, which hides a lot of our object lifetime bugs. + We should enable ARC, since that is what most of our clients will be using. + + * API/tests/testapi.mm: + (-[TestObject init]): + (-[TestObject dealloc]): + (+[TestObject testObject]): + (testObjectiveCAPI): + * JavaScriptCore.xcodeproj/project.pbxproj: + +2013-02-04 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: ObjCCallbackFunction should retain the target of its NSInvocation + https://bugs.webkit.org/show_bug.cgi?id=108843 + + Reviewed by Darin Adler. + + Currently, ObjCCallbackFunction doesn't retain the target of its NSInvocation. It needs to do + this to prevent crashes when trying to invoke a callback later on. + + * API/ObjCCallbackFunction.mm: + (ObjCCallbackFunction::ObjCCallbackFunction): + (ObjCCallbackFunction::~ObjCCallbackFunction): + +2013-02-04 Martin Robinson <mrobinson@igalia.com> + + Fix GTK+ 'make dist' in preparation for the 1.11.5 release. + + * GNUmakefile.list.am: Update the source lists. + +2013-02-04 Michael Saboff <msaboff@apple.com> + + For ARMv7s use integer divide instruction for divide and modulo when possible + https://bugs.webkit.org/show_bug.cgi?id=108840 + + Reviewed in person by Filip Pizlo. + + Added ARMv7s integer divide path for ArithDiv and ArithMod where operands and results are integer. + This is patterned after the similar code for X86. Also added modulo power of 2 optimization + that uses logical and. Added sdiv and udiv to the ARMv7 disassembler. Put all the changes + behind #if CPU(APPLE_ARMV7S). + + * assembler/ARMv7Assembler.h: + (ARMv7Assembler): + (JSC::ARMv7Assembler::sdiv): + (JSC::ARMv7Assembler::udiv): + * dfg/DFGCommon.h: + (JSC::DFG::isARMv7s): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileSoftModulo): + (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForARMv7s): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-02-04 David Kilzer <ddkilzer@apple.com> + + Check PrivateHeaders/JSBasePrivate.h for inappropriate macros + <http://webkit.org/b/108749> + + Reviewed by Joseph Pecoraro. + + * JavaScriptCore.xcodeproj/project.pbxproj: Add + PrivateHeaders/JSBasePrivate.h to list of headers to check in + "Check for Inappropriate Macros in External Headers" build phase + script. + +2013-02-04 David Kilzer <ddkilzer@apple.com> + + Remove duplicate entries from JavaScriptCore Xcode project + + $ uniq Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj | diff -u - Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj | patch -p0 -R + patching file Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj + + * JavaScriptCore.xcodeproj/project.pbxproj: Remove duplicates. + +2013-02-04 David Kilzer <ddkilzer@apple.com> + + Sort JavaScriptCore Xcode project file + + * JavaScriptCore.xcodeproj/project.pbxproj: + +2013-02-03 David Kilzer <ddkilzer@apple.com> + + Upstream ENABLE_PDFKIT_PLUGIN settting + <http://webkit.org/b/108792> + + Reviewed by Tim Horton. + + * Configurations/FeatureDefines.xcconfig: Disable PDFKIT_PLUGIN + on iOS since PDFKit is a Mac-only framework. + +2013-02-02 Andreas Kling <akling@apple.com> + + Vector should consult allocator about ideal size when choosing capacity. + <http://webkit.org/b/108410> + <rdar://problem/13124002> + + Reviewed by Benjamin Poulain. + + Remove assertion about Vector capacity that won't hold anymore since capacity() + may not be what you passed to reserveCapacity(). + Also export WTF::fastMallocGoodSize() for Windows builds. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + +2013-02-02 Patrick Gansterer <paroga@webkit.org> + + [CMake] Adopt the WinCE port to new CMake + https://bugs.webkit.org/show_bug.cgi?id=108754 + + Reviewed by Laszlo Gombos. + + * os-win32/WinMain.cpp: Removed. + * shell/PlatformWinCE.cmake: Removed. + +2013-02-02 Mark Rowe <mrowe@apple.com> + + <http://webkit.org/b/108745> WTF shouldn't use a script build phase to detect the presence of headers when the compiler can do it for us + + Reviewed by Sam Weinig. + + * DerivedSources.make: Remove an obsolete Makefile rule. This should have been removed when the use + of the generated file moved to WTF. + +2013-02-02 David Kilzer <ddkilzer@apple.com> + + Upstream iOS FeatureDefines + <http://webkit.org/b/108753> + + Reviewed by Anders Carlsson. + + * Configurations/FeatureDefines.xcconfig: + - ENABLE_DEVICE_ORIENTATION: Add iOS configurations. + - ENABLE_PLUGIN_PROXY_FOR_VIDEO: Ditto. + - FEATURE_DEFINES: Add ENABLE_PLUGIN_PROXY_FOR_VIDEO. Add + PLATFORM_NAME variant to reduce future merge conflicts. + +2013-02-01 Mark Hahnenberg <mhahnenberg@apple.com> + + Structure::m_enumerationCache should be moved to StructureRareData + https://bugs.webkit.org/show_bug.cgi?id=108723 + + Reviewed by Oliver Hunt. + + m_enumerationCache is only used by objects whose properties are iterated over, so not every Structure needs this + field and it can therefore be moved safely to StructureRareData to help with memory savings. + + * runtime/JSPropertyNameIterator.h: + (JSPropertyNameIterator): + (JSC::Register::propertyNameIterator): + (JSC::StructureRareData::enumerationCache): Add to JSPropertyNameIterator.h so that it can see the correct type. + (JSC::StructureRareData::setEnumerationCache): Ditto. + * runtime/Structure.cpp: + (JSC::Structure::addPropertyWithoutTransition): Use the enumerationCache() getter rather than accessing the field. + (JSC::Structure::removePropertyWithoutTransition): Ditto. + (JSC::Structure::visitChildren): We no longer have to worry about marking the m_enumerationCache field. + * runtime/Structure.h: + (JSC::Structure::setEnumerationCache): Move the old accessors back since we don't have to have any knowledge of + the JSPropertyNameIterator type. + (JSC::Structure::enumerationCache): Ditto. + * runtime/StructureRareData.cpp: + (JSC::StructureRareData::visitChildren): Mark the new m_enumerationCache field. + * runtime/StructureRareData.h: Add new functions/fields. + (StructureRareData): + +2013-02-01 Roger Fong <roger_fong@apple.com> + + Unreviewed. JavaScriptCore VS2010 project cleanup. + + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: + * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: + +2013-02-01 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r141662. + http://trac.webkit.org/changeset/141662 + https://bugs.webkit.org/show_bug.cgi?id=108738 + + it's an incorrect change since processPhiStack will + dereference dangling BasicBlock pointers (Requested by pizlo + on #webkit). + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parse): + +2013-02-01 Filip Pizlo <fpizlo@apple.com> + + Eliminate dead blocks sooner in the DFG::ByteCodeParser to make clear that you don't need to hold onto them during Phi construction + https://bugs.webkit.org/show_bug.cgi?id=108717 + + Reviewed by Mark Hahnenberg. + + I think this makes the code clearer. It doesn't change behavior. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parse): + +2013-02-01 Mark Hahnenberg <mhahnenberg@apple.com> + + Structure should have a StructureRareData field to save space + https://bugs.webkit.org/show_bug.cgi?id=108659 + + Reviewed by Oliver Hunt. + + Many of the fields in Structure are used in a subset of all total Structures; however, all Structures must + pay the memory cost of those fields, regardless of whether they use them or not. Since we can have potentially + many Structures on a single page (e.g. bing.com creates ~1500 Structures), it would be profitable to + refactor Structure so that not every Structure has to pay the memory costs for these infrequently used fields. + + To accomplish this, we can create a new StructureRareData class to house these seldom used fields which we + can allocate on demand whenever a Structure requires it. This StructureRareData can itself be a JSCell, and + can do all the marking of the fields for the Structure. The StructureRareData field will be part of a union + with m_previous to minimize overhead. We'll add a new field to JSTypeInfo to indicate that the Structure has + a StructureRareData field. During transitions, a Structure will clone its previous Structure's StructureRareData + if it has one. There could be some potential for optimizing this process, but the initial implementation will + be dumb since we'd be paying these overhead costs for each Structure anyways. + + Initially we'll only put two fields in the StructureRareData to avoid a memory regression. Over time we'll + continue to move fields from Structure to StructureRareData. Optimistically, this could potentially reduce our + Structure memory footprint by up to around 75%. It could also clear the way for removing destructors from + Structures (and into StructureRareData). + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGRepatch.cpp: Includes for linking purposes. + * jit/JITStubs.cpp: + * jsc.cpp: + * llint/LLIntSlowPaths.cpp: + * runtime/JSCellInlines.h: Added ifdef guards. + * runtime/JSGlobalData.cpp: New Structure for StructureRareData class. + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSGlobalObject.h: + * runtime/JSTypeInfo.h: New flag to indicate whether or not a Structure has a StructureRareData field. + (JSC::TypeInfo::flags): + (JSC::TypeInfo::structureHasRareData): + * runtime/ObjectPrototype.cpp: + * runtime/Structure.cpp: We use a combined WriteBarrier<JSCell> field m_previousOrRareData to avoid compiler issues. + (JSC::Structure::dumpStatistics): + (JSC::Structure::Structure): + (JSC::Structure::materializePropertyMap): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::pin): + (JSC::Structure::allocateRareData): Handles allocating a brand new StructureRareData field. + (JSC::Structure::cloneRareDataFrom): Handles cloning a StructureRareData field from another. Used during Structure + transitions. + (JSC::Structure::visitChildren): We no longer have to worry about marking m_objectToStringValue. + * runtime/Structure.h: + (JSC::Structure::previousID): Checks the structureHasRareData flag to see where it should get the previous Structure. + (JSC::Structure::objectToStringValue): Reads the value from the StructureRareData. If it doesn't exist, returns 0. + (JSC::Structure::setObjectToStringValue): Ensures that we have a StructureRareData field, then forwards the function + call to it. + (JSC::Structure::materializePropertyMapIfNecessary): + (JSC::Structure::setPreviousID): Checks for StructureRareData and forwards if necessary. + (Structure): + (JSC::Structure::clearPreviousID): Ditto. + (JSC::Structure::create): + * runtime/StructureRareData.cpp: Added. All of the basic functionality of a JSCell with the fields that we've moved + from Structure and the functions required to access/modify those fields as Structure would have done. + (JSC): + (JSC::StructureRareData::createStructure): + (JSC::StructureRareData::create): + (JSC::StructureRareData::clone): + (JSC::StructureRareData::StructureRareData): + (JSC::StructureRareData::visitChildren): + * runtime/StructureRareData.h: Added. + (JSC): + (StructureRareData): + * runtime/StructureRareDataInlines.h: Added. + (JSC): + (JSC::StructureRareData::previousID): + (JSC::StructureRareData::setPreviousID): + (JSC::StructureRareData::clearPreviousID): + (JSC::Structure::previous): Handles the ugly casting to get the value of the right type of m_previousOrRareData. + (JSC::Structure::rareData): Ditto. + (JSC::StructureRareData::objectToStringValue): + (JSC::StructureRareData::setObjectToStringValue): + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGRepatch.cpp: + * jit/JITStubs.cpp: + * jsc.cpp: + * llint/LLIntSlowPaths.cpp: + * runtime/JSCellInlines.h: + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/JSGlobalObject.h: + * runtime/JSTypeInfo.h: + (JSC): + (JSC::TypeInfo::flags): + (JSC::TypeInfo::structureHasRareData): + * runtime/ObjectPrototype.cpp: + * runtime/Structure.cpp: + (JSC::Structure::dumpStatistics): + (JSC::Structure::Structure): + (JSC::Structure::materializePropertyMap): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::pin): + (JSC::Structure::allocateRareData): + (JSC): + (JSC::Structure::cloneRareDataFrom): + (JSC::Structure::visitChildren): + * runtime/Structure.h: + (JSC::Structure::previousID): + (JSC::Structure::objectToStringValue): + (JSC::Structure::setObjectToStringValue): + (JSC::Structure::materializePropertyMapIfNecessary): + (JSC::Structure::setPreviousID): + (Structure): + (JSC::Structure::clearPreviousID): + (JSC::Structure::previous): + (JSC::Structure::rareData): + (JSC::Structure::create): + * runtime/StructureRareData.cpp: Added. + (JSC): + (JSC::StructureRareData::createStructure): + (JSC::StructureRareData::create): + (JSC::StructureRareData::clone): + (JSC::StructureRareData::StructureRareData): + (JSC::StructureRareData::visitChildren): + * runtime/StructureRareData.h: Added. + (JSC): + (StructureRareData): + * runtime/StructureRareDataInlines.h: Added. + (JSC): + (JSC::StructureRareData::previousID): + (JSC::StructureRareData::setPreviousID): + (JSC::StructureRareData::clearPreviousID): + (JSC::StructureRareData::objectToStringValue): + (JSC::StructureRareData::setObjectToStringValue): + +2013-02-01 Balazs Kilvady <kilvadyb@homejinni.com> + + offlineasm BaseIndex handling is broken on ARM due to MIPS changes + https://bugs.webkit.org/show_bug.cgi?id=108261 + + Reviewed by Filip Pizlo. + + offlineasm BaseIndex handling fix on MIPS. + + * offlineasm/mips.rb: + * offlineasm/risc.rb: + +2013-02-01 Geoffrey Garen <ggaren@apple.com> + + Removed an unused function: JSGlobalObject::createFunctionExecutableFromGlobalCode + https://bugs.webkit.org/show_bug.cgi?id=108657 + + Reviewed by Anders Carlsson. + + * runtime/JSGlobalObject.cpp: + (JSC): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + +2013-02-01 Geoffrey Garen <ggaren@apple.com> + + Added TriState to WTF and started using it in one place + https://bugs.webkit.org/show_bug.cgi?id=108628 + + Reviewed by Beth Dakin. + + * runtime/PrototypeMap.h: + (JSC::PrototypeMap::isPrototype): Use TriState instead of boolean. In + response to review feedback, this is an attempt to clarify that our + 'true' condition is actually just a 'maybe'. + + * runtime/PrototypeMap.h: + (PrototypeMap): + (JSC::PrototypeMap::isPrototype): + +2013-02-01 Alexis Menard <alexis@webkit.org> + + Enable unprefixed CSS transitions by default. + https://bugs.webkit.org/show_bug.cgi?id=108216 + + Reviewed by Dean Jackson. + + Rename the flag CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED + to CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED which will be used later to + guard the unprefixing work for CSS Transforms and animations. + + * Configurations/FeatureDefines.xcconfig: + +2013-01-31 Filip Pizlo <fpizlo@apple.com> + + DFG::CFGSimplificationPhase::keepOperandAlive() conflates liveness and availability + https://bugs.webkit.org/show_bug.cgi?id=108580 + + Reviewed by Oliver Hunt. + + This is a harmless bug in that it only results in us keeping a bit too many things + for OSR. But it's worth fixing so that the code is consistent. + + keepOperandAlive() is called when block A has a branch to blocks B and C, but the + A->B edge is proven to never be taken and we want to optimize the code to have A + unconditionally jump to C. In that case, for the purposes of OSR, we need to + preserve the knowledge that the state that B expected to be live incoming from A + ought still to be live up to the point of where the A->B,C branch used to be. The + way we keep things alive is by using the variablesAtTail of A (i.e., we use the + knowledge of in what manner A made state available to B and C). The way we choose + which state should be kept alive ought to be chosen by the variablesAtHead of B + (i.e. the things B says it needs from its predecessors, including A), except that + keepOperandAlive() was previously just using variablesAtTail of A for this + purpose. + + The fix is to have keepOperandAlive() use both liveness and availability in its + logic. It should use liveness (i.e. B->variablesAtHead) to decide what to keep + alive, and it should use availability (i.e. A->variablesAtTail) to decide how to + keep it alive. + + This might be a microscopic win on some programs, but it's mainly intended to be + a code clean-up so that I don't end up scratching my head in confusion the next + time I look at this code. + + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::keepOperandAlive): + (JSC::DFG::CFGSimplificationPhase::jettisonBlock): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + +2013-01-31 Geoffrey Garen <ggaren@apple.com> + + REGRESSION (r141192): Crash beneath cti_op_get_by_id_generic @ discussions.apple.com + https://bugs.webkit.org/show_bug.cgi?id=108576 + + Reviewed by Filip Pizlo. + + This was a long-standing bug. The DFG would destructively reuse a register + in op_convert_this, but: + + * The bug only presented during speculation failure for type Other + + * The bug presented by removing the low bits of a pointer, which + used to be harmless, since all objects were so aligned anyway. + + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): Don't reuse our this register as + our scratch register. The whole point of our scratch register is to + avoid destructively modifying our this register. I'm pretty sure this + was a copy-paste error. + +2013-01-31 Roger Fong <roger_fong@apple.com> + + Unreviewed. Windows build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + +2013-01-31 Jessie Berlin <jberlin@apple.com> + + Rolling out r141407 because it is causing crashes under + WTF::TCMalloc_Central_FreeList::FetchFromSpans() in Release builds. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + +2013-01-31 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: JSContext exception property causes reference cycle + https://bugs.webkit.org/show_bug.cgi?id=107778 + + Reviewed by Darin Adler. + + JSContext has a (retain) JSValue * exception property which, when non-null, creates a + reference cycle (since the JSValue * holds a strong reference back to the JSContext *). + + * API/JSContext.mm: Instead of JSValue *, we now use a plain JSValueRef, which eliminates the reference cycle. + (-[JSContext initWithVirtualMachine:]): + (-[JSContext setException:]): + (-[JSContext exception]): + +2013-01-31 Roger Fong <roger_fong@apple.com> + + Unreviewed build fix. Win7 port. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + +2013-01-31 Joseph Pecoraro <pecoraro@apple.com> + + Disable ENABLE_FULLSCREEN_API on iOS + https://bugs.webkit.org/show_bug.cgi?id=108250 + + Reviewed by Benjamin Poulain. + + * Configurations/FeatureDefines.xcconfig: + +2013-01-31 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Fix insertion of values greater than the max index allowed by the spec + https://bugs.webkit.org/show_bug.cgi?id=108264 + + Reviewed by Oliver Hunt. + + Fixed a bug, added a test to the API tests, cleaned up some code. + + * API/JSValue.h: Changed some of the documentation on setValue:atIndex: to indicate that + setting values at indices greater than UINT_MAX - 1 wont' affect the length of JS arrays. + * API/JSValue.mm: + (-[JSValue valueAtIndex:]): We weren't returning when we should have been. + (-[JSValue setValue:atIndex:]): Added a comment about why we do the early check for being larger than UINT_MAX. + (objectToValueWithoutCopy): Removed two redundant cases that were already checked previously. + * API/tests/testapi.mm: + +2013-01-30 Andreas Kling <akling@apple.com> + + Vector should consult allocator about ideal size when choosing capacity. + <http://webkit.org/b/108410> + <rdar://problem/13124002> + + Reviewed by Benjamin Poulain. + + Remove assertion about Vector capacity that won't hold anymore since capacity() + may not be what you passed to reserveCapacity(). + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + +2013-01-30 Filip Pizlo <fpizlo@apple.com> + + DFG bytecode parser should have more assertions about the status of local accesses + https://bugs.webkit.org/show_bug.cgi?id=108417 + + Reviewed by Mark Hahnenberg. + + Assert some things that we already know to be true, just to reassure ourselves that they are true. + This is meant as a prerequisite for https://bugs.webkit.org/show_bug.cgi?id=108414, which will + make these rules even stricter. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getLocal): + (JSC::DFG::ByteCodeParser::getArgument): + +2013-01-30 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: JSContext's dealloc causes ASSERT due to ordering of releases + https://bugs.webkit.org/show_bug.cgi?id=107978 + + Reviewed by Filip Pizlo. + + We need to add the Identifier table save/restore in JSContextGroupRelease so that we + have the correct table if we end up destroying the JSGlobalData/Heap. + + * API/JSContextRef.cpp: + (JSContextGroupRelease): + +2013-01-30 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: exceptionHandler needs to be released in JSContext dealloc + https://bugs.webkit.org/show_bug.cgi?id=108378 + + Reviewed by Filip Pizlo. + + JSContext has a (copy) exceptionHandler property that it doesn't release in dealloc. + That sounds like the potential for a leak. It should be released. + + * API/JSContext.mm: + (-[JSContext dealloc]): + +2013-01-30 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(140504): pure CSE no longer matches things, 10% regression on Kraken + https://bugs.webkit.org/show_bug.cgi?id=108366 + + Reviewed by Geoffrey Garen and Mark Hahnenberg. + + This was a longstanding bug that was revealed by http://trac.webkit.org/changeset/140504. + Pure CSE requires that the Node::flags() that may affect the behavior of a node match, + when comparing a possibly redundant node to its possible replacement. It was doing this + by comparing Node::arithNodeFlags(), which as the name might appear to suggest, returns + just those flag bits that correspond to actual node behavior and not auxiliary things. + Unfortunately, Node::arithNodeFlags() wasn't actually masking off the irrelevant bits. + This worked prior to r140504 because CSE itself didn't mutate the flags, so there was a + very high probability that matching nodes would also have completely identical flag bits + (even the ones that aren't relevant to arithmetic behavior, like NodeDoesNotExit). But + r140504 moved one of CSE's side-tables (m_relevantToOSR) into a flag bit for quicker + access. These bits would be mutated as the CSE ran over a basic block, in such a way that + there was a very high probability that the possible replacement would already have the + bit set, while the redundant node did not have the bit set. Since Node::arithNodeFlags() + returned all of the bits, this would cause CSEPhase::pureCSE() to reject the match + almost every time. + + The solution is to make Node::arithNodeFlags() do as its name suggests: only return those + flags that are relevant to arithmetic behavior. This patch introduces a new mask that + represents those bits, and includes NodeBehaviorMask and NodeBackPropMask, which are both + used for queries on Node::arithNodeFlags(), and both affect arithmetic code gen. None of + the other flags are relevant to Node::arithNodeFlags() since they either correspond to + information already conveyed by the opcode (like NodeResultMask, NodeMustGenerate, + NodeHasVarArgs, NodeClobbersWorld, NodeMightClobber) or information that doesn't affect + the result that the node will produce or any of the queries performed on the result of + Node::arithNodeFlags (NodeDoesNotExit and of course NodeRelevantToOSR). + + This is a 10% speed-up on Kraken, undoing the regression from r140504. + + * dfg/DFGNode.h: + (JSC::DFG::Node::arithNodeFlags): + * dfg/DFGNodeFlags.h: + (DFG): + +2013-01-29 Mark Hahnenberg <mhahnenberg@apple.com> + + Structure::m_outOfLineCapacity is unnecessary + https://bugs.webkit.org/show_bug.cgi?id=108206 + + Reviewed by Geoffrey Garen. + + We can calculate our out of line capacity by using the outOfLineSize and our knowledge about our resize policy. + According to GDB, this knocks Structures down from 136 bytes to 128 bytes (I'm guessing the extra bytes are from + better alignment of object fields), which puts Structures in a smaller size class. Woohoo! Looks neutral on our + benchmarks. + + * runtime/Structure.cpp: + (JSC::Structure::Structure): + (JSC): + (JSC::Structure::suggestedNewOutOfLineStorageCapacity): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::addPropertyWithoutTransition): + * runtime/Structure.h: + (Structure): + (JSC::Structure::outOfLineCapacity): + (JSC::Structure::totalStorageCapacity): + +2013-01-29 Geoffrey Garen <ggaren@apple.com> + + Be a little more conservative about emitting table-based switches + https://bugs.webkit.org/show_bug.cgi?id=108292 + + Reviewed by Filip Pizlo. + + Profiling shows we're using op_switch in cases where it's a regression. + + * bytecompiler/NodesCodegen.cpp: + (JSC): + (JSC::length): + (JSC::CaseBlockNode::tryTableSwitch): + (JSC::CaseBlockNode::emitBytecodeForBlock): + * parser/Nodes.h: + (CaseBlockNode): + +2013-01-29 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r140983. + http://trac.webkit.org/changeset/140983 + https://bugs.webkit.org/show_bug.cgi?id=108277 + + Unfortunately, this API has one last client (Requested by + abarth on #webkit). + + * Configurations/FeatureDefines.xcconfig: + +2013-01-29 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: JSObjCClassInfo creates reference cycle with JSContext + https://bugs.webkit.org/show_bug.cgi?id=107839 + + Reviewed by Geoffrey Garen. + + Fixing several ASSERTs that were incorrect along with some of the reallocation of m_prototype and + m_constructor that they were based on. + + * API/JSWrapperMap.mm: + (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We now only allocate those + fields that are null (i.e. have been collected or have never been allocated to begin with). + (-[JSObjCClassInfo reallocateConstructorAndOrPrototype]): Renamed to better indicate that we're + reallocating one or both of the prototype/constructor combo. + (-[JSObjCClassInfo wrapperForObject:]): Call new reallocate function. + (-[JSObjCClassInfo constructor]): Ditto. + +2013-01-29 Geoffrey Garen <ggaren@apple.com> + + Make precise size classes more precise + https://bugs.webkit.org/show_bug.cgi?id=108270 + + Reviewed by Mark Hahnenberg. + + Size inference makes this profitable. + + I chose 8 byte increments because JSString is 24 bytes. Otherwise, 16 + byte increments might be better. + + * heap/Heap.h: + (Heap): Removed firstAllocatorWithoutDestructors because it's unused now. + + * heap/MarkedBlock.h: + (MarkedBlock): Updated constants. + + * heap/MarkedSpace.h: + (MarkedSpace): + (JSC): Also reduced the maximum precise size class because my testing + has shown that the smaller size classes are much more common. This + offsets some of the size class explosion caused by reducing the precise + increment. + + * llint/LLIntData.cpp: + (JSC::LLInt::Data::performAssertions): No need for this ASSERT anymore + because we don't rely on firstAllocatorWithoutDestructors anymore, since + we pick size classes dynamically now. + +2013-01-29 Oliver Hunt <oliver@apple.com> + + Add some hardening to methodTable() + https://bugs.webkit.org/show_bug.cgi?id=108253 + + Reviewed by Mark Hahnenberg. + + When accessing methodTable() we now always make sure that our + structure _could_ be valid. Added a separate method to get a + classes methodTable during destruction as it's not possible to + validate the structure at that point. This separation might + also make it possible to improve the performance of methodTable + access more generally in future. + + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::callDestructor): + * runtime/JSCell.h: + (JSCell): + * runtime/JSCellInlines.h: + (JSC::JSCell::methodTableForDestruction): + (JSC): + (JSC::JSCell::methodTable): + +2013-01-29 Filip Pizlo <fpizlo@apple.com> + + offlineasm BaseIndex handling is broken on ARM due to MIPS changes + https://bugs.webkit.org/show_bug.cgi?id=108261 + + Reviewed by Oliver Hunt. + + Backends shouldn't override each other's methods. That's not cool. + + * offlineasm/mips.rb: + +2013-01-29 Filip Pizlo <fpizlo@apple.com> + + cloop.rb shouldn't use a method called 'dump' for code generation + https://bugs.webkit.org/show_bug.cgi?id=108251 + + Reviewed by Mark Hahnenberg. + + Revert http://trac.webkit.org/changeset/141178 and rename 'dump' to 'clDump'. + + Also made trivial build fixes for !ENABLE(JIT). + + * offlineasm/cloop.rb: + * runtime/Executable.h: + (ExecutableBase): + (JSC::ExecutableBase::intrinsicFor): + * runtime/JSGlobalData.h: + +2013-01-29 Geoffrey Garen <ggaren@apple.com> + + Removed GGC because it has been disabled for a long time + https://bugs.webkit.org/show_bug.cgi?id=108245 + + Reviewed by Filip Pizlo. + + * GNUmakefile.list.am: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGRepatch.cpp: + (JSC::DFG::emitPutReplaceStub): + (JSC::DFG::emitPutTransitionStub): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::writeBarrier): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * heap/CardSet.h: Removed. + * heap/Heap.cpp: + (JSC::Heap::markRoots): + (JSC::Heap::collect): + * heap/Heap.h: + (Heap): + (JSC::Heap::shouldCollect): + (JSC::Heap::isWriteBarrierEnabled): + (JSC): + (JSC::Heap::writeBarrier): + * heap/MarkedBlock.h: + (MarkedBlock): + (JSC): + * heap/MarkedSpace.cpp: + (JSC): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emitWriteBarrier): + +2013-01-29 Filip Pizlo <fpizlo@apple.com> + + Remove redundant AST dump method from cloop.rb, since they are already defined in ast.rb + https://bugs.webkit.org/show_bug.cgi?id=108247 + + Reviewed by Oliver Hunt. + + Makes offlineasm dumping easier to read and less likely to cause assertion failures. + Also fixes the strange situation where cloop.rb and ast.rb both defined dump methods, + but cloop.rb was winning. + + * offlineasm/cloop.rb: + +2013-01-29 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: JSObjCClassInfo creates reference cycle with JSContext + https://bugs.webkit.org/show_bug.cgi?id=107839 + + Reviewed by Oliver Hunt. + + JSContext has a JSWrapperMap, which has an NSMutableDictionary m_classMap, which has values that + are JSObjCClassInfo objects, which have strong references to two JSValue *'s, m_prototype and + m_constructor, which in turn have strong references to the JSContext, creating a reference cycle. + We should make m_prototype and m_constructor Weak<JSObject>. This gets rid of the strong reference + to the JSContext and also prevents clients from accidentally creating reference cycles by assigning + to the prototype of the constructor. If Weak<JSObject> fields are ever garbage collected, we will + reallocate them. + + * API/JSContext.mm: + (-[JSContext wrapperMap]): + * API/JSContextInternal.h: + * API/JSWrapperMap.mm: + (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): + (-[JSObjCClassInfo dealloc]): + (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): + (-[JSObjCClassInfo allocateConstructorAndPrototype]): + (-[JSObjCClassInfo wrapperForObject:]): + (-[JSObjCClassInfo constructor]): + +2013-01-29 Oliver Hunt <oliver@apple.com> + + REGRESSION (r140594): RELEASE_ASSERT_NOT_REACHED in JSC::Interpreter::execute + https://bugs.webkit.org/show_bug.cgi?id=108097 + + Reviewed by Geoffrey Garen. + + LiteralParser was accepting a bogus 'var a.b = c' statement + + * runtime/LiteralParser.cpp: + (JSC::::tryJSONPParse): + +2013-01-29 Oliver Hunt <oliver@apple.com> + + Force debug builds to do bounds checks on contiguous property storage + https://bugs.webkit.org/show_bug.cgi?id=108212 + + Reviewed by Mark Hahnenberg. + + Add a ContiguousData type that we use to represent contiguous property + storage. In release builds it is simply a pointer to the correct type, + but in debug builds it also carries the data length and performs bounds + checks. This means we don't have to add as many manual bounds assertions + when performing operations over contiguous data. + + * dfg/DFGOperations.cpp: + * runtime/ArrayStorage.h: + (ArrayStorage): + (JSC::ArrayStorage::vector): + * runtime/Butterfly.h: + (JSC::ContiguousData::ContiguousData): + (ContiguousData): + (JSC::ContiguousData::operator[]): + (JSC::ContiguousData::data): + (JSC::ContiguousData::length): + (JSC): + (JSC::Butterfly::contiguousInt32): + (Butterfly): + (JSC::Butterfly::contiguousDouble): + (JSC::Butterfly::contiguous): + * runtime/JSArray.cpp: + (JSC::JSArray::sortNumericVector): + (ContiguousTypeAccessor): + (JSC::ContiguousTypeAccessor::getAsValue): + (JSC::ContiguousTypeAccessor::setWithValue): + (JSC::ContiguousTypeAccessor::replaceDataReference): + (JSC): + (JSC::JSArray::sortCompactedVector): + (JSC::JSArray::sort): + (JSC::JSArray::fillArgList): + (JSC::JSArray::copyToArguments): + * runtime/JSArray.h: + (JSArray): + * runtime/JSObject.cpp: + (JSC::JSObject::copyButterfly): + (JSC::JSObject::visitButterfly): + (JSC::JSObject::createInitialInt32): + (JSC::JSObject::createInitialDouble): + (JSC::JSObject::createInitialContiguous): + (JSC::JSObject::convertUndecidedToInt32): + (JSC::JSObject::convertUndecidedToDouble): + (JSC::JSObject::convertUndecidedToContiguous): + (JSC::JSObject::convertInt32ToDouble): + (JSC::JSObject::convertInt32ToContiguous): + (JSC::JSObject::genericConvertDoubleToContiguous): + (JSC::JSObject::convertDoubleToContiguous): + (JSC::JSObject::rageConvertDoubleToContiguous): + (JSC::JSObject::ensureInt32Slow): + (JSC::JSObject::ensureDoubleSlow): + (JSC::JSObject::ensureContiguousSlow): + (JSC::JSObject::rageEnsureContiguousSlow): + (JSC::JSObject::ensureLengthSlow): + * runtime/JSObject.h: + (JSC::JSObject::ensureInt32): + (JSC::JSObject::ensureDouble): + (JSC::JSObject::ensureContiguous): + (JSC::JSObject::rageEnsureContiguous): + (JSObject): + (JSC::JSObject::indexingData): + (JSC::JSObject::currentIndexingData): + +2013-01-29 Brent Fulgham <bfulgham@webkit.org> + + [Windows, WinCairo] Unreviewed build fix after r141050 + + * JavaScriptCore.vcxproj/JavaScriptCoreExports.def: Update symbols + to match JavaScriptCore.vcproj version. + +2013-01-29 Allan Sandfeld Jensen <allan.jensen@digia.com> + + [Qt] Implement GCActivityCallback + https://bugs.webkit.org/show_bug.cgi?id=103998 + + Reviewed by Simon Hausmann. + + Implements the activity triggered garbage collector. + + * runtime/GCActivityCallback.cpp: + (JSC::DefaultGCActivityCallback::DefaultGCActivityCallback): + (JSC::DefaultGCActivityCallback::scheduleTimer): + (JSC::DefaultGCActivityCallback::cancelTimer): + * runtime/GCActivityCallback.h: + (GCActivityCallback): + (DefaultGCActivityCallback): + +2013-01-29 Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com> + + Compilation warning in JSC + https://bugs.webkit.org/show_bug.cgi?id=108178 + + Reviewed by Kentaro Hara. + + Fixed 'comparison between signed and unsigned integer' warning in JSC::Structure constructor. + + * runtime/Structure.cpp: + (JSC::Structure::Structure): + +2013-01-29 Jocelyn Turcotte <jocelyn.turcotte@digia.com> + + [Qt] Fix the JSC build on Mac + + Unreviewed, build fix. + + * heap/HeapTimer.h: + Qt on Mac has USE(CF) true, and should use the CF HeapTimer in that case. + +2013-01-29 Allan Sandfeld Jensen <allan.jensen@digia.com> + + [Qt] Implement IncrementalSweeper and HeapTimer + https://bugs.webkit.org/show_bug.cgi?id=103996 + + Reviewed by Simon Hausmann. + + Implements the incremental sweeping garbage collection for the Qt platform. + + * heap/HeapTimer.cpp: + (JSC::HeapTimer::HeapTimer): + (JSC::HeapTimer::~HeapTimer): + (JSC::HeapTimer::timerEvent): + (JSC::HeapTimer::synchronize): + (JSC::HeapTimer::invalidate): + (JSC::HeapTimer::didStartVMShutdown): + * heap/HeapTimer.h: + (HeapTimer): + * heap/IncrementalSweeper.cpp: + (JSC::IncrementalSweeper::IncrementalSweeper): + (JSC::IncrementalSweeper::scheduleTimer): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + +2013-01-28 Filip Pizlo <fpizlo@apple.com> + + DFG should not use a graph that is a vector, Nodes shouldn't move after allocation, and we should always refer to nodes by Node* + https://bugs.webkit.org/show_bug.cgi?id=106868 + + Reviewed by Oliver Hunt. + + This adds a pool allocator for Nodes, and uses that instead of a Vector. Changes all + uses of Node& and NodeIndex to be simply Node*. Nodes no longer have an index except + for debugging (Node::index(), which is not guaranteed to be O(1)). + + 1% speed-up on SunSpider, presumably because this improves compile times. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/DataFormat.h: + (JSC::dataFormatToString): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + (JSC::DFG::AbstractState::booleanResult): + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::mergeStateAtTail): + (JSC::DFG::AbstractState::mergeToSuccessors): + (JSC::DFG::AbstractState::mergeVariableBetweenBlocks): + (JSC::DFG::AbstractState::dump): + * dfg/DFGAbstractState.h: + (DFG): + (JSC::DFG::AbstractState::forNode): + (AbstractState): + (JSC::DFG::AbstractState::speculateInt32Unary): + (JSC::DFG::AbstractState::speculateNumberUnary): + (JSC::DFG::AbstractState::speculateBooleanUnary): + (JSC::DFG::AbstractState::speculateInt32Binary): + (JSC::DFG::AbstractState::speculateNumberBinary): + (JSC::DFG::AbstractState::trySetConstant): + * dfg/DFGAbstractValue.h: + (AbstractValue): + * dfg/DFGAdjacencyList.h: + (JSC::DFG::AdjacencyList::AdjacencyList): + (JSC::DFG::AdjacencyList::initialize): + * dfg/DFGAllocator.h: Added. + (DFG): + (Allocator): + (JSC::DFG::Allocator::Region::size): + (JSC::DFG::Allocator::Region::headerSize): + (JSC::DFG::Allocator::Region::numberOfThingsPerRegion): + (JSC::DFG::Allocator::Region::data): + (JSC::DFG::Allocator::Region::isInThisRegion): + (JSC::DFG::Allocator::Region::regionFor): + (Region): + (JSC::DFG::::Allocator): + (JSC::DFG::::~Allocator): + (JSC::DFG::::allocate): + (JSC::DFG::::free): + (JSC::DFG::::freeAll): + (JSC::DFG::::reset): + (JSC::DFG::::indexOf): + (JSC::DFG::::allocatorOf): + (JSC::DFG::::bumpAllocate): + (JSC::DFG::::freeListAllocate): + (JSC::DFG::::allocateSlow): + (JSC::DFG::::freeRegionsStartingAt): + (JSC::DFG::::startBumpingIn): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUses): + (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): + (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::originalArrayStructure): + (JSC::DFG::ArrayMode::alreadyChecked): + * dfg/DFGArrayMode.h: + (ArrayMode): + * dfg/DFGArrayifySlowPathGenerator.h: + (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator): + * dfg/DFGBasicBlock.h: + (JSC::DFG::BasicBlock::node): + (JSC::DFG::BasicBlock::isInPhis): + (JSC::DFG::BasicBlock::isInBlock): + (BasicBlock): + * dfg/DFGBasicBlockInlines.h: + (DFG): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::getDirect): + (JSC::DFG::ByteCodeParser::get): + (JSC::DFG::ByteCodeParser::setDirect): + (JSC::DFG::ByteCodeParser::set): + (JSC::DFG::ByteCodeParser::setPair): + (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): + (JSC::DFG::ByteCodeParser::getLocal): + (JSC::DFG::ByteCodeParser::setLocal): + (JSC::DFG::ByteCodeParser::getArgument): + (JSC::DFG::ByteCodeParser::setArgument): + (JSC::DFG::ByteCodeParser::flushDirect): + (JSC::DFG::ByteCodeParser::getToInt32): + (JSC::DFG::ByteCodeParser::toInt32): + (JSC::DFG::ByteCodeParser::getJSConstantForValue): + (JSC::DFG::ByteCodeParser::getJSConstant): + (JSC::DFG::ByteCodeParser::getCallee): + (JSC::DFG::ByteCodeParser::getThis): + (JSC::DFG::ByteCodeParser::setThis): + (JSC::DFG::ByteCodeParser::isJSConstant): + (JSC::DFG::ByteCodeParser::isInt32Constant): + (JSC::DFG::ByteCodeParser::valueOfJSConstant): + (JSC::DFG::ByteCodeParser::valueOfInt32Constant): + (JSC::DFG::ByteCodeParser::constantUndefined): + (JSC::DFG::ByteCodeParser::constantNull): + (JSC::DFG::ByteCodeParser::one): + (JSC::DFG::ByteCodeParser::constantNaN): + (JSC::DFG::ByteCodeParser::cellConstant): + (JSC::DFG::ByteCodeParser::addToGraph): + (JSC::DFG::ByteCodeParser::insertPhiNode): + (JSC::DFG::ByteCodeParser::addVarArgChild): + (JSC::DFG::ByteCodeParser::addCall): + (JSC::DFG::ByteCodeParser::addStructureTransitionCheck): + (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): + (JSC::DFG::ByteCodeParser::getPrediction): + (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): + (JSC::DFG::ByteCodeParser::makeSafe): + (JSC::DFG::ByteCodeParser::makeDivSafe): + (JSC::DFG::ByteCodeParser::ConstantRecord::ConstantRecord): + (ConstantRecord): + (JSC::DFG::ByteCodeParser::PhiStackEntry::PhiStackEntry): + (PhiStackEntry): + (JSC::DFG::ByteCodeParser::handleCall): + (JSC::DFG::ByteCodeParser::emitFunctionChecks): + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::setIntrinsicResult): + (JSC::DFG::ByteCodeParser::handleMinMax): + (JSC::DFG::ByteCodeParser::handleIntrinsic): + (JSC::DFG::ByteCodeParser::handleGetByOffset): + (JSC::DFG::ByteCodeParser::handleGetById): + (JSC::DFG::ByteCodeParser::getScope): + (JSC::DFG::ByteCodeParser::parseResolveOperations): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::processPhiStack): + (JSC::DFG::ByteCodeParser::linkBlock): + (JSC::DFG::ByteCodeParser::parseCodeBlock): + (JSC::DFG::ByteCodeParser::parse): + * dfg/DFGCFAPhase.cpp: + (JSC::DFG::CFAPhase::performBlockCFA): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::keepOperandAlive): + (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): + (JSC::DFG::CFGSimplificationPhase::fixPhis): + (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference): + (JSC::DFG::CFGSimplificationPhase::OperandSubstitution::OperandSubstitution): + (JSC::DFG::CFGSimplificationPhase::OperandSubstitution::dump): + (OperandSubstitution): + (JSC::DFG::CFGSimplificationPhase::skipGetLocal): + (JSC::DFG::CFGSimplificationPhase::recordNewTarget): + (JSC::DFG::CFGSimplificationPhase::fixTailOperand): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::canonicalize): + (JSC::DFG::CSEPhase::endIndexForPureCSE): + (JSC::DFG::CSEPhase::pureCSE): + (JSC::DFG::CSEPhase::constantCSE): + (JSC::DFG::CSEPhase::weakConstantCSE): + (JSC::DFG::CSEPhase::getCalleeLoadElimination): + (JSC::DFG::CSEPhase::getArrayLengthElimination): + (JSC::DFG::CSEPhase::globalVarLoadElimination): + (JSC::DFG::CSEPhase::scopedVarLoadElimination): + (JSC::DFG::CSEPhase::globalVarWatchpointElimination): + (JSC::DFG::CSEPhase::globalVarStoreElimination): + (JSC::DFG::CSEPhase::scopedVarStoreElimination): + (JSC::DFG::CSEPhase::getByValLoadElimination): + (JSC::DFG::CSEPhase::checkFunctionElimination): + (JSC::DFG::CSEPhase::checkExecutableElimination): + (JSC::DFG::CSEPhase::checkStructureElimination): + (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): + (JSC::DFG::CSEPhase::putStructureStoreElimination): + (JSC::DFG::CSEPhase::getByOffsetLoadElimination): + (JSC::DFG::CSEPhase::putByOffsetStoreElimination): + (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::checkArrayElimination): + (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::getMyScopeLoadElimination): + (JSC::DFG::CSEPhase::getLocalLoadElimination): + (JSC::DFG::CSEPhase::setLocalStoreElimination): + (JSC::DFG::CSEPhase::performSubstitution): + (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren): + (JSC::DFG::CSEPhase::setReplacement): + (JSC::DFG::CSEPhase::eliminate): + (JSC::DFG::CSEPhase::performNodeCSE): + (JSC::DFG::CSEPhase::performBlockCSE): + (CSEPhase): + * dfg/DFGCommon.cpp: Added. + (DFG): + (JSC::DFG::NodePointerTraits::dump): + * dfg/DFGCommon.h: + (DFG): + (JSC::DFG::NodePointerTraits::defaultValue): + (NodePointerTraits): + (JSC::DFG::verboseCompilationEnabled): + (JSC::DFG::shouldDumpGraphAtEachPhase): + (JSC::DFG::validationEnabled): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + (JSC::DFG::ConstantFoldingPhase::isCapturedAtOrAfter): + (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck): + (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode): + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::Disassembler): + (JSC::DFG::Disassembler::createDumpList): + (JSC::DFG::Disassembler::dumpDisassembly): + * dfg/DFGDisassembler.h: + (JSC::DFG::Disassembler::setForNode): + (Disassembler): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGEdge.cpp: Added. + (DFG): + (JSC::DFG::Edge::dump): + * dfg/DFGEdge.h: + (JSC::DFG::Edge::Edge): + (JSC::DFG::Edge::node): + (JSC::DFG::Edge::operator*): + (JSC::DFG::Edge::operator->): + (Edge): + (JSC::DFG::Edge::setNode): + (JSC::DFG::Edge::useKind): + (JSC::DFG::Edge::setUseKind): + (JSC::DFG::Edge::isSet): + (JSC::DFG::Edge::shift): + (JSC::DFG::Edge::makeWord): + (JSC::DFG::operator==): + (JSC::DFG::operator!=): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupBlock): + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::checkArray): + (JSC::DFG::FixupPhase::blessArrayOperation): + (JSC::DFG::FixupPhase::fixIntEdge): + (JSC::DFG::FixupPhase::fixDoubleEdge): + (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): + (FixupPhase): + * dfg/DFGGenerationInfo.h: + (JSC::DFG::GenerationInfo::GenerationInfo): + (JSC::DFG::GenerationInfo::initConstant): + (JSC::DFG::GenerationInfo::initInteger): + (JSC::DFG::GenerationInfo::initJSValue): + (JSC::DFG::GenerationInfo::initCell): + (JSC::DFG::GenerationInfo::initBoolean): + (JSC::DFG::GenerationInfo::initDouble): + (JSC::DFG::GenerationInfo::initStorage): + (GenerationInfo): + (JSC::DFG::GenerationInfo::node): + (JSC::DFG::GenerationInfo::noticeOSRBirth): + (JSC::DFG::GenerationInfo::use): + (JSC::DFG::GenerationInfo::appendFill): + (JSC::DFG::GenerationInfo::appendSpill): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::Graph): + (JSC::DFG::Graph::~Graph): + (DFG): + (JSC::DFG::Graph::dumpCodeOrigin): + (JSC::DFG::Graph::amountOfNodeWhiteSpace): + (JSC::DFG::Graph::printNodeWhiteSpace): + (JSC::DFG::Graph::dump): + (JSC::DFG::Graph::dumpBlockHeader): + (JSC::DFG::Graph::refChildren): + (JSC::DFG::Graph::derefChildren): + (JSC::DFG::Graph::predictArgumentTypes): + (JSC::DFG::Graph::collectGarbage): + (JSC::DFG::Graph::determineReachability): + (JSC::DFG::Graph::resetExitStates): + * dfg/DFGGraph.h: + (Graph): + (JSC::DFG::Graph::ref): + (JSC::DFG::Graph::deref): + (JSC::DFG::Graph::changeChild): + (JSC::DFG::Graph::compareAndSwap): + (JSC::DFG::Graph::clearAndDerefChild): + (JSC::DFG::Graph::clearAndDerefChild1): + (JSC::DFG::Graph::clearAndDerefChild2): + (JSC::DFG::Graph::clearAndDerefChild3): + (JSC::DFG::Graph::convertToConstant): + (JSC::DFG::Graph::getJSConstantSpeculation): + (JSC::DFG::Graph::addSpeculationMode): + (JSC::DFG::Graph::valueAddSpeculationMode): + (JSC::DFG::Graph::arithAddSpeculationMode): + (JSC::DFG::Graph::addShouldSpeculateInteger): + (JSC::DFG::Graph::mulShouldSpeculateInteger): + (JSC::DFG::Graph::negateShouldSpeculateInteger): + (JSC::DFG::Graph::isConstant): + (JSC::DFG::Graph::isJSConstant): + (JSC::DFG::Graph::isInt32Constant): + (JSC::DFG::Graph::isDoubleConstant): + (JSC::DFG::Graph::isNumberConstant): + (JSC::DFG::Graph::isBooleanConstant): + (JSC::DFG::Graph::isCellConstant): + (JSC::DFG::Graph::isFunctionConstant): + (JSC::DFG::Graph::isInternalFunctionConstant): + (JSC::DFG::Graph::valueOfJSConstant): + (JSC::DFG::Graph::valueOfInt32Constant): + (JSC::DFG::Graph::valueOfNumberConstant): + (JSC::DFG::Graph::valueOfBooleanConstant): + (JSC::DFG::Graph::valueOfFunctionConstant): + (JSC::DFG::Graph::valueProfileFor): + (JSC::DFG::Graph::methodOfGettingAValueProfileFor): + (JSC::DFG::Graph::numSuccessors): + (JSC::DFG::Graph::successor): + (JSC::DFG::Graph::successorForCondition): + (JSC::DFG::Graph::isPredictedNumerical): + (JSC::DFG::Graph::byValIsPure): + (JSC::DFG::Graph::clobbersWorld): + (JSC::DFG::Graph::varArgNumChildren): + (JSC::DFG::Graph::numChildren): + (JSC::DFG::Graph::varArgChild): + (JSC::DFG::Graph::child): + (JSC::DFG::Graph::voteNode): + (JSC::DFG::Graph::voteChildren): + (JSC::DFG::Graph::substitute): + (JSC::DFG::Graph::substituteGetLocal): + (JSC::DFG::Graph::addImmediateShouldSpeculateInteger): + (JSC::DFG::Graph::mulImmediateShouldSpeculateInteger): + * dfg/DFGInsertionSet.h: + (JSC::DFG::Insertion::Insertion): + (JSC::DFG::Insertion::element): + (Insertion): + (JSC::DFG::InsertionSet::insert): + (InsertionSet): + * dfg/DFGJITCompiler.cpp: + * dfg/DFGJITCompiler.h: + (JSC::DFG::JITCompiler::setForNode): + (JSC::DFG::JITCompiler::addressOfDoubleConstant): + (JSC::DFG::JITCompiler::noticeOSREntry): + * dfg/DFGLongLivedState.cpp: Added. + (DFG): + (JSC::DFG::LongLivedState::LongLivedState): + (JSC::DFG::LongLivedState::~LongLivedState): + (JSC::DFG::LongLivedState::shrinkToFit): + * dfg/DFGLongLivedState.h: Added. + (DFG): + (LongLivedState): + * dfg/DFGMinifiedID.h: + (JSC::DFG::MinifiedID::MinifiedID): + (JSC::DFG::MinifiedID::node): + * dfg/DFGMinifiedNode.cpp: + (JSC::DFG::MinifiedNode::fromNode): + * dfg/DFGMinifiedNode.h: + (MinifiedNode): + * dfg/DFGNode.cpp: Added. + (DFG): + (JSC::DFG::Node::index): + (WTF): + (WTF::printInternal): + * dfg/DFGNode.h: + (DFG): + (JSC::DFG::Node::Node): + (Node): + (JSC::DFG::Node::convertToGetByOffset): + (JSC::DFG::Node::convertToPutByOffset): + (JSC::DFG::Node::ref): + (JSC::DFG::Node::shouldSpeculateInteger): + (JSC::DFG::Node::shouldSpeculateIntegerForArithmetic): + (JSC::DFG::Node::shouldSpeculateIntegerExpectingDefined): + (JSC::DFG::Node::shouldSpeculateDoubleForArithmetic): + (JSC::DFG::Node::shouldSpeculateNumber): + (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined): + (JSC::DFG::Node::shouldSpeculateFinalObject): + (JSC::DFG::Node::shouldSpeculateArray): + (JSC::DFG::Node::dumpChildren): + (WTF): + * dfg/DFGNodeAllocator.h: Added. + (DFG): + (operator new ): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + (SpeculationFailureDebugInfo): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + * dfg/DFGPhase.cpp: + (DFG): + (JSC::DFG::Phase::beginPhase): + (JSC::DFG::Phase::endPhase): + * dfg/DFGPhase.h: + (Phase): + (JSC::DFG::runAndLog): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::setPrediction): + (JSC::DFG::PredictionPropagationPhase::mergePrediction): + (JSC::DFG::PredictionPropagationPhase::isNotNegZero): + (JSC::DFG::PredictionPropagationPhase::isNotZero): + (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoForConstant): + (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoNonRecursive): + (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwo): + (JSC::DFG::PredictionPropagationPhase::propagate): + (JSC::DFG::PredictionPropagationPhase::mergeDefaultFlags): + (JSC::DFG::PredictionPropagationPhase::propagateForward): + (JSC::DFG::PredictionPropagationPhase::propagateBackward): + (JSC::DFG::PredictionPropagationPhase::doDoubleVoting): + (PredictionPropagationPhase): + (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): + * dfg/DFGScoreBoard.h: + (JSC::DFG::ScoreBoard::ScoreBoard): + (JSC::DFG::ScoreBoard::use): + (JSC::DFG::ScoreBoard::useIfHasResult): + (ScoreBoard): + * dfg/DFGSilentRegisterSavePlan.h: + (JSC::DFG::SilentRegisterSavePlan::SilentRegisterSavePlan): + (JSC::DFG::SilentRegisterSavePlan::node): + (SilentRegisterSavePlan): + * dfg/DFGSlowPathGenerator.h: + (JSC::DFG::SlowPathGenerator::SlowPathGenerator): + (JSC::DFG::SlowPathGenerator::generate): + (SlowPathGenerator): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::speculationCheck): + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): + (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR): + (JSC::DFG::SpeculativeJIT::silentSavePlanForFPR): + (JSC::DFG::SpeculativeJIT::silentSpill): + (JSC::DFG::SpeculativeJIT::silentFill): + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::arrayify): + (JSC::DFG::SpeculativeJIT::fillStorage): + (JSC::DFG::SpeculativeJIT::useChildren): + (JSC::DFG::SpeculativeJIT::isStrictInt32): + (JSC::DFG::SpeculativeJIT::isKnownInteger): + (JSC::DFG::SpeculativeJIT::isKnownNumeric): + (JSC::DFG::SpeculativeJIT::isKnownCell): + (JSC::DFG::SpeculativeJIT::isKnownNotCell): + (JSC::DFG::SpeculativeJIT::isKnownNotInteger): + (JSC::DFG::SpeculativeJIT::isKnownNotNumber): + (JSC::DFG::SpeculativeJIT::writeBarrier): + (JSC::DFG::SpeculativeJIT::nonSpeculativeCompare): + (JSC::DFG::SpeculativeJIT::nonSpeculativeStrictEq): + (JSC::DFG::GPRTemporary::GPRTemporary): + (JSC::DFG::FPRTemporary::FPRTemporary): + (JSC::DFG::SpeculativeJIT::compilePeepHoleDoubleBranch): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleIntegerBranch): + (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch): + (JSC::DFG::SpeculativeJIT::noticeOSRBirth): + (JSC::DFG::SpeculativeJIT::compileMovHint): + (JSC::DFG::SpeculativeJIT::compile): + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): + (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): + (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt): + (JSC::DFG::SpeculativeJIT::compileGetByValOnString): + (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): + (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): + (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): + (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): + (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): + (JSC::DFG::SpeculativeJIT::compileInstanceOf): + (JSC::DFG::SpeculativeJIT::compileSoftModulo): + (JSC::DFG::SpeculativeJIT::compileAdd): + (JSC::DFG::SpeculativeJIT::compileArithSub): + (JSC::DFG::SpeculativeJIT::compileArithNegate): + (JSC::DFG::SpeculativeJIT::compileArithMul): + (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForX86): + (JSC::DFG::SpeculativeJIT::compileArithMod): + (JSC::DFG::SpeculativeJIT::compare): + (JSC::DFG::SpeculativeJIT::compileStrictEqForConstant): + (JSC::DFG::SpeculativeJIT::compileStrictEq): + (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): + (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): + (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): + (JSC::DFG::SpeculativeJIT::compileGetArrayLength): + (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck): + (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression): + (JSC::DFG::SpeculativeJIT::compileRegExpExec): + (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): + (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::canReuse): + (JSC::DFG::SpeculativeJIT::isFilled): + (JSC::DFG::SpeculativeJIT::isFilledDouble): + (JSC::DFG::SpeculativeJIT::use): + (JSC::DFG::SpeculativeJIT::isConstant): + (JSC::DFG::SpeculativeJIT::isJSConstant): + (JSC::DFG::SpeculativeJIT::isInt32Constant): + (JSC::DFG::SpeculativeJIT::isDoubleConstant): + (JSC::DFG::SpeculativeJIT::isNumberConstant): + (JSC::DFG::SpeculativeJIT::isBooleanConstant): + (JSC::DFG::SpeculativeJIT::isFunctionConstant): + (JSC::DFG::SpeculativeJIT::valueOfInt32Constant): + (JSC::DFG::SpeculativeJIT::valueOfNumberConstant): + (JSC::DFG::SpeculativeJIT::valueOfNumberConstantAsInt32): + (JSC::DFG::SpeculativeJIT::addressOfDoubleConstant): + (JSC::DFG::SpeculativeJIT::valueOfJSConstant): + (JSC::DFG::SpeculativeJIT::valueOfBooleanConstant): + (JSC::DFG::SpeculativeJIT::valueOfFunctionConstant): + (JSC::DFG::SpeculativeJIT::isNullConstant): + (JSC::DFG::SpeculativeJIT::valueOfJSConstantAsImm64): + (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch): + (JSC::DFG::SpeculativeJIT::integerResult): + (JSC::DFG::SpeculativeJIT::noResult): + (JSC::DFG::SpeculativeJIT::cellResult): + (JSC::DFG::SpeculativeJIT::booleanResult): + (JSC::DFG::SpeculativeJIT::jsValueResult): + (JSC::DFG::SpeculativeJIT::storageResult): + (JSC::DFG::SpeculativeJIT::doubleResult): + (JSC::DFG::SpeculativeJIT::initConstantInfo): + (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck): + (JSC::DFG::SpeculativeJIT::isInteger): + (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): + (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage): + (JSC::DFG::SpeculativeJIT::setNodeForOperand): + (JSC::DFG::IntegerOperand::IntegerOperand): + (JSC::DFG::IntegerOperand::node): + (JSC::DFG::IntegerOperand::gpr): + (JSC::DFG::IntegerOperand::use): + (IntegerOperand): + (JSC::DFG::DoubleOperand::DoubleOperand): + (JSC::DFG::DoubleOperand::node): + (JSC::DFG::DoubleOperand::fpr): + (JSC::DFG::DoubleOperand::use): + (DoubleOperand): + (JSC::DFG::JSValueOperand::JSValueOperand): + (JSC::DFG::JSValueOperand::node): + (JSC::DFG::JSValueOperand::gpr): + (JSC::DFG::JSValueOperand::fill): + (JSC::DFG::JSValueOperand::use): + (JSValueOperand): + (JSC::DFG::StorageOperand::StorageOperand): + (JSC::DFG::StorageOperand::node): + (JSC::DFG::StorageOperand::gpr): + (JSC::DFG::StorageOperand::use): + (StorageOperand): + (JSC::DFG::SpeculateIntegerOperand::SpeculateIntegerOperand): + (JSC::DFG::SpeculateIntegerOperand::node): + (JSC::DFG::SpeculateIntegerOperand::gpr): + (JSC::DFG::SpeculateIntegerOperand::use): + (SpeculateIntegerOperand): + (JSC::DFG::SpeculateStrictInt32Operand::SpeculateStrictInt32Operand): + (JSC::DFG::SpeculateStrictInt32Operand::node): + (JSC::DFG::SpeculateStrictInt32Operand::gpr): + (JSC::DFG::SpeculateStrictInt32Operand::use): + (SpeculateStrictInt32Operand): + (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand): + (JSC::DFG::SpeculateDoubleOperand::node): + (JSC::DFG::SpeculateDoubleOperand::fpr): + (JSC::DFG::SpeculateDoubleOperand::use): + (SpeculateDoubleOperand): + (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand): + (JSC::DFG::SpeculateCellOperand::node): + (JSC::DFG::SpeculateCellOperand::gpr): + (JSC::DFG::SpeculateCellOperand::use): + (SpeculateCellOperand): + (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand): + (JSC::DFG::SpeculateBooleanOperand::node): + (JSC::DFG::SpeculateBooleanOperand::gpr): + (JSC::DFG::SpeculateBooleanOperand::use): + (SpeculateBooleanOperand): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::fillDouble): + (JSC::DFG::SpeculativeJIT::fillJSValue): + (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToNumber): + (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToInt32): + (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber): + (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): + (JSC::DFG::SpeculativeJIT::emitCall): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateInt): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileIntegerCompare): + (JSC::DFG::SpeculativeJIT::compileDoubleCompare): + (JSC::DFG::SpeculativeJIT::compileValueAdd): + (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch): + (JSC::DFG::SpeculativeJIT::emitBranch): + (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::fillDouble): + (JSC::DFG::SpeculativeJIT::fillJSValue): + (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToNumber): + (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToInt32): + (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber): + (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): + (JSC::DFG::SpeculativeJIT::emitCall): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateInt): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileIntegerCompare): + (JSC::DFG::SpeculativeJIT::compileDoubleCompare): + (JSC::DFG::SpeculativeJIT::compileValueAdd): + (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch): + (JSC::DFG::SpeculativeJIT::emitBranch): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureAbstractValue.h: + (StructureAbstractValue): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * dfg/DFGValidate.cpp: + (DFG): + (Validate): + (JSC::DFG::Validate::validate): + (JSC::DFG::Validate::reportValidationContext): + * dfg/DFGValidate.h: + * dfg/DFGValueSource.cpp: + (JSC::DFG::ValueSource::dump): + * dfg/DFGValueSource.h: + (JSC::DFG::ValueSource::ValueSource): + * dfg/DFGVirtualRegisterAllocationPhase.cpp: + (JSC::DFG::VirtualRegisterAllocationPhase::run): + * runtime/FunctionExecutableDump.cpp: Added. + (JSC): + (JSC::FunctionExecutableDump::dump): + * runtime/FunctionExecutableDump.h: Added. + (JSC): + (FunctionExecutableDump): + (JSC::FunctionExecutableDump::FunctionExecutableDump): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSC): + (DFG): + (JSGlobalData): + * runtime/Options.h: + (JSC): + +2013-01-28 Laszlo Gombos <l.gombos@samsung.com> + + Collapse testing for a list of PLATFORM() into OS() and USE() tests + https://bugs.webkit.org/show_bug.cgi?id=108018 + + Reviewed by Eric Seidel. + + No functional change as "OS(DARWIN) && USE(CF)" equals to the + following platforms: MAC, WX, QT and CHROMIUM. CHROMIUM + is not using JavaScriptCore. + + * runtime/DatePrototype.cpp: + (JSC): + +2013-01-28 Geoffrey Garen <ggaren@apple.com> + + Static size inference for JavaScript objects + https://bugs.webkit.org/show_bug.cgi?id=108093 + + Reviewed by Phil Pizlo. + + * API/JSObjectRef.cpp: + * JavaScriptCore.order: + * JavaScriptCore.xcodeproj/project.pbxproj: Pay the tax man. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecode): op_new_object and op_create_this now + have an extra inferredInlineCapacity argument. This is the statically + inferred inline capacity, just from analyzing source text. op_new_object + also gets a pointer to an allocation profile. (For op_create_this, the + profile is in the construtor function.) + + (JSC::CodeBlock::CodeBlock): Link op_new_object. + + (JSC::CodeBlock::stronglyVisitStrongReferences): Mark our profiles. + + * bytecode/CodeBlock.h: + (CodeBlock): Removed some dead code. Added object allocation profiles. + + * bytecode/Instruction.h: + (JSC): New union type, since an instruction operand may point to an + object allocation profile now. + + * bytecode/ObjectAllocationProfile.h: Added. + (JSC): + (ObjectAllocationProfile): + (JSC::ObjectAllocationProfile::offsetOfAllocator): + (JSC::ObjectAllocationProfile::offsetOfStructure): + (JSC::ObjectAllocationProfile::ObjectAllocationProfile): + (JSC::ObjectAllocationProfile::isNull): + (JSC::ObjectAllocationProfile::initialize): + (JSC::ObjectAllocationProfile::structure): + (JSC::ObjectAllocationProfile::inlineCapacity): + (JSC::ObjectAllocationProfile::clear): + (JSC::ObjectAllocationProfile::visitAggregate): + (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): New class + for tracking a prediction about object allocation: structure, inline + capacity, allocator to use. + + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): Updated instruction sizes. + + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): + * bytecode/UnlinkedCodeBlock.h: + (JSC): + (JSC::UnlinkedCodeBlock::addObjectAllocationProfile): + (JSC::UnlinkedCodeBlock::numberOfObjectAllocationProfiles): + (UnlinkedCodeBlock): Unlinked support for allocation profiles. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::generate): Kill all remaining analyses at the + end of codegen, since this is our last opportunity. + + (JSC::BytecodeGenerator::BytecodeGenerator): Added a static property + analyzer to bytecode generation. It tracks initializing assignments and + makes a guess about how many will happen. + + (JSC::BytecodeGenerator::newObjectAllocationProfile): + (JSC): + (JSC::BytecodeGenerator::emitProfiledOpcode): + (JSC::BytecodeGenerator::emitMove): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveBase): + (JSC::BytecodeGenerator::emitResolveBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetById): + (JSC::BytecodeGenerator::emitPutById): + (JSC::BytecodeGenerator::emitDirectPutById): + (JSC::BytecodeGenerator::emitPutGetterSetter): + (JSC::BytecodeGenerator::emitGetArgumentByVal): + (JSC::BytecodeGenerator::emitGetByVal): Added hooks to the static property + analyzer, so it can observe allocations and stores. + + (JSC::BytecodeGenerator::emitCreateThis): Factored this into a helper + function because it was a significant amount of logic, and I wanted to + add to it. + + (JSC::BytecodeGenerator::emitNewObject): + (JSC::BytecodeGenerator::emitExpectedFunctionSnippet): + (JSC::BytecodeGenerator::emitCall): + (JSC::BytecodeGenerator::emitCallVarargs): + (JSC::BytecodeGenerator::emitConstruct): Added a hook to profiled opcodes + to track their stores, in case a store kills a profiled allocation. Since + profiled opcodes are basically the only interesting stores we do, this + is a convenient place to notice any store that might kill an allocation. + + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): As above. + + * bytecompiler/StaticPropertyAnalysis.h: Added. + (JSC): + (StaticPropertyAnalysis): + (JSC::StaticPropertyAnalysis::create): + (JSC::StaticPropertyAnalysis::addPropertyIndex): + (JSC::StaticPropertyAnalysis::record): + (JSC::StaticPropertyAnalysis::propertyIndexCount): + (JSC::StaticPropertyAnalysis::StaticPropertyAnalysis): Simple helper + class for tracking allocations and stores. + + * bytecompiler/StaticPropertyAnalyzer.h: Added. + (StaticPropertyAnalyzer): + (JSC::StaticPropertyAnalyzer::StaticPropertyAnalyzer): + (JSC::StaticPropertyAnalyzer::createThis): + (JSC::StaticPropertyAnalyzer::newObject): + (JSC::StaticPropertyAnalyzer::putById): + (JSC::StaticPropertyAnalyzer::mov): + (JSC::StaticPropertyAnalyzer::kill): Helper class for observing allocations + and stores and making an inline capacity guess. The heuristics here are + intentionally minimal because we don't want this one class to try to + re-create something like a DFG or a runtime analysis. If we discover that + we need those kinds of analyses, we should just replace this class with + something else. + + This class tracks multiple registers that alias the same object -- that + happens a lot, when moving locals into temporary registers -- but it + doesn't track control flow or multiple objects that alias the same register. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): Updated for rename. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): Updated for inline capacity and + allocation profile. + + * dfg/DFGNode.h: + (JSC::DFG::Node::hasInlineCapacity): + (Node): + (JSC::DFG::Node::inlineCapacity): + (JSC::DFG::Node::hasFunction): Give the graph a good way to represent + inline capacity for an allocation. + + * dfg/DFGNodeType.h: + (DFG): Updated for rename. + + * dfg/DFGOperations.cpp: Updated for interface change. + + * dfg/DFGOperations.h: We pass the inline capacity to the slow case as + an argument. This is the simplest way, since it's stored as a bytecode operand. + + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): Updated for rename. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): Fixed a horrible off-by-one-half bug that only + appears when doing an inline cached load for property number 64 on a 32-bit + system. In JSVALUE32_64 land, "offsetRelativeToPatchedStorage" is the + offset of the 64bit JSValue -- but we'll actually issue two loads, one for + the payload at that offset, and one for the tag at that offset + 4. We need + to ensure that both loads have a compact representation, or we'll corrupt + the instruction stream. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::emitAllocateJSObject): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): Lots of refactoring to support + passing an allocator to our allocation function, and/or passing a Structure + as a register instead of an immediate. + + * heap/MarkedAllocator.h: + (DFG): + (MarkedAllocator): + (JSC::MarkedAllocator::offsetOfFreeListHead): Added an accessor to simplify + JIT code generation of allocation from an arbitrary allocator. + + * jit/JIT.h: + (JSC): + * jit/JITInlines.h: + (JSC): + (JSC::JIT::emitAllocateJSObject): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_new_object): + (JSC::JIT::emitSlow_op_new_object): + (JSC::JIT::emit_op_create_this): + (JSC::JIT::emitSlow_op_create_this): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_new_object): + (JSC::JIT::emitSlow_op_new_object): + (JSC::JIT::emit_op_create_this): + (JSC::JIT::emitSlow_op_create_this): Same refactoring as done for the DFG. + + * jit/JITStubs.cpp: + (JSC::tryCacheGetByID): Fixed the same bug mentioned above. + + (JSC::DEFINE_STUB_FUNCTION): Updated for interface changes. + + * llint/LLIntData.cpp: + (JSC::LLInt::Data::performAssertions): Updated for interface changes. + + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: Same refactoring as for the JITs. + + * profiler/ProfilerBytecode.cpp: + * profiler/ProfilerBytecodes.cpp: + * profiler/ProfilerCompilation.cpp: + * profiler/ProfilerCompiledBytecode.cpp: + * profiler/ProfilerDatabase.cpp: + * profiler/ProfilerOSRExit.cpp: + * profiler/ProfilerOrigin.cpp: + * profiler/ProfilerProfiledBytecodes.cpp: Include ObjectConstructor.h + because that's where createEmptyObject() lives now. + + * runtime/Executable.h: + (JSC::JSFunction::JSFunction): Updated for rename. + + * runtime/JSCellInlines.h: + (JSC::allocateCell): Updated to match the allocator selection code in + the JIT, so it's clearer that both are correct. + + * runtime/JSFunction.cpp: + (JSC::JSFunction::JSFunction): + (JSC::JSFunction::createAllocationProfile): + (JSC::JSFunction::visitChildren): + (JSC::JSFunction::getOwnPropertySlot): + (JSC::JSFunction::put): + (JSC::JSFunction::defineOwnProperty): + (JSC::JSFunction::getConstructData): + * runtime/JSFunction.h: + (JSC::JSFunction::offsetOfScopeChain): + (JSC::JSFunction::offsetOfExecutable): + (JSC::JSFunction::offsetOfAllocationProfile): + (JSC::JSFunction::allocationProfile): + (JSFunction): + (JSC::JSFunction::tryGetAllocationProfile): + (JSC::JSFunction::addAllocationProfileWatchpoint): Changed inheritorID + data member to be an ObjectAllocationProfile, which includes a pointer + to the desired allocator. This simplifies JIT code, since we don't have + to compute the allocator on the fly. I verified by code inspection that + JSFunction is still only 64 bytes. + + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + (JSC::JSGlobalObject::visitChildren): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::dateStructure): No direct pointer to the empty + object structure anymore, because now clients need to specify how much + inline capacity they want. + + * runtime/JSONObject.cpp: + * runtime/JSObject.h: + (JSC): + (JSFinalObject): + (JSC::JSFinalObject::defaultInlineCapacity): + (JSC::JSFinalObject::maxInlineCapacity): + (JSC::JSFinalObject::createStructure): A little refactoring to try to + clarify where some of these constants derive from. + + (JSC::maxOffsetRelativeToPatchedStorage): Used for bug fix, above. + + * runtime/JSProxy.cpp: + (JSC::JSProxy::setTarget): Ugly, but effective. + + * runtime/LiteralParser.cpp: + * runtime/ObjectConstructor.cpp: + (JSC::constructObject): + (JSC::constructWithObjectConstructor): + (JSC::callObjectConstructor): + (JSC::objectConstructorCreate): Updated for interface changes. + + * runtime/ObjectConstructor.h: + (JSC::constructEmptyObject): Clarified your options for how to allocate + an empty object, to emphasize what things can actually vary. + + * runtime/PropertyOffset.h: These constants have moved because they're + really higher level concepts to do with the layout of objects and the + collector. PropertyOffset is just an abstract number line, independent + of those things. + + * runtime/PrototypeMap.cpp: + (JSC::PrototypeMap::emptyObjectStructureForPrototype): + (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): + * runtime/PrototypeMap.h: + (PrototypeMap): The map key is now a pair of prototype and inline capacity, + since Structure encodes inline capacity. + + * runtime/Structure.cpp: + (JSC::Structure::Structure): + (JSC::Structure::materializePropertyMap): + (JSC::Structure::addPropertyTransition): + (JSC::Structure::nonPropertyTransition): + (JSC::Structure::copyPropertyTableForPinning): + * runtime/Structure.h: + (Structure): + (JSC::Structure::totalStorageSize): + (JSC::Structure::transitionCount): + (JSC::Structure::create): Fixed a nasty refactoring bug that only shows + up after enabling variable-sized inline capacities: we were passing our + type info where our inline capacity was expected. The compiler didn't + notice because both have type int :(. + +2013-01-28 Oliver Hunt <oliver@apple.com> + + Add more assertions to the property storage use in arrays + https://bugs.webkit.org/show_bug.cgi?id=107728 + + Reviewed by Filip Pizlo. + + Add a bunch of assertions to array and object butterfly + usage. This should make debugging somewhat easier. + + I also converted a couple of assertions to release asserts + as they were so low cost it seemed a sensible thing to do. + + * runtime/JSArray.cpp: + (JSC::JSArray::sortVector): + (JSC::JSArray::compactForSorting): + * runtime/JSObject.h: + (JSC::JSObject::getHolyIndexQuickly): + +2013-01-28 Adam Barth <abarth@webkit.org> + + Remove webkitNotifications.createHTMLNotification + https://bugs.webkit.org/show_bug.cgi?id=107598 + + Reviewed by Benjamin Poulain. + + * Configurations/FeatureDefines.xcconfig: + +2013-01-28 Michael Saboff <msaboff@apple.com> + + Cleanup ARM version of debugName() in DFGFPRInfo.h + https://bugs.webkit.org/show_bug.cgi?id=108090 + + Reviewed by David Kilzer. + + Fixed debugName() so it will compile by adding static_cast<int> and missing commas. + + * dfg/DFGFPRInfo.h: + (JSC::DFG::FPRInfo::debugName): + +2013-01-27 Andreas Kling <akling@apple.com> + + JSC: FunctionParameters are memory hungry. + <http://webkit.org/b/108033> + <rdar://problem/13094803> + + Reviewed by Sam Weinig. + + Instead of inheriting from Vector<Identifier>, make FunctionParameters a simple fixed-size array + with a custom-allocating create() function. Removes one step of indirection and cuts memory usage + roughly in half. + + 2.73 MB progression on Membuster3. + + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::UnlinkedFunctionExecutable::paramString): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + * parser/Nodes.cpp: + (JSC::FunctionParameters::create): + (JSC::FunctionParameters::FunctionParameters): + (JSC::FunctionParameters::~FunctionParameters): + * parser/Nodes.h: + (FunctionParameters): + (JSC::FunctionParameters::size): + (JSC::FunctionParameters::at): + (JSC::FunctionParameters::identifiers): + +2013-01-27 Andreas Kling <akling@apple.com> + + JSC: SourceProviderCache is memory hungry. + <http://webkit.org/b/108029> + <rdar://problem/13094806> + + Reviewed by Sam Weinig. + + Use fixed-size arrays for SourceProviderCacheItem's lists of captured variables. + Since the lists never change after the object is created, there's no need to keep them in Vectors + and we can instead create the whole cache item in a single allocation. + + 13.37 MB progression on Membuster3. + + * parser/Parser.cpp: + (JSC::::parseFunctionInfo): + * parser/Parser.h: + (JSC::Scope::copyCapturedVariablesToVector): + (JSC::Scope::fillParametersForSourceProviderCache): + (JSC::Scope::restoreFromSourceProviderCache): + * parser/SourceProviderCacheItem.h: + (SourceProviderCacheItemCreationParameters): + (SourceProviderCacheItem): + (JSC::SourceProviderCacheItem::approximateByteSize): + (JSC::SourceProviderCacheItem::usedVariables): + (JSC::SourceProviderCacheItem::writtenVariables): + (JSC::SourceProviderCacheItem::~SourceProviderCacheItem): + (JSC::SourceProviderCacheItem::create): + (JSC::SourceProviderCacheItem::SourceProviderCacheItem): + +2013-01-27 Zoltan Arvai <zarvai@inf.u-szeged.hu> + + Fixing atomicIncrement implementation for Windows by dropping support before XP SP2. + https://bugs.webkit.org/show_bug.cgi?id=106740 + + Reviewed by Benjamin Poulain. + + * config.h: + +2013-01-25 Filip Pizlo <fpizlo@apple.com> + + DFG variable event stream shouldn't use NodeIndex + https://bugs.webkit.org/show_bug.cgi?id=107996 + + Reviewed by Oliver Hunt. + + Introduce the notion of a DFG::MinifiedID, which is just a unique ID of a DFG Node. + Internally it currently uses a NodeIndex, but we could change this without having + to recode all of the users of MinifiedID. This effectively decouples the OSR exit + compiler's way of identifying nodes from the speculative JIT's way of identifying + nodes, and should make it easier to make changes to the speculative JIT's internals + in the future. + + Also changed variable event stream logging to exclude information about births and + deaths of constants, since the OSR exit compiler never cares about which register + holds a constant; if a value is constant then the OSR exit compiler can reify it. + + Also changed the variable event stream's value recovery computation to use a + HashMap keyed by MinifiedID rather than a Vector indexed by NodeIndex. + + This appears to be performance-neutral. It's primarily meant as a small step + towards https://bugs.webkit.org/show_bug.cgi?id=106868. + + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGGenerationInfo.h: + (JSC::DFG::GenerationInfo::GenerationInfo): + (JSC::DFG::GenerationInfo::initConstant): + (JSC::DFG::GenerationInfo::initInteger): + (JSC::DFG::GenerationInfo::initJSValue): + (JSC::DFG::GenerationInfo::initCell): + (JSC::DFG::GenerationInfo::initBoolean): + (JSC::DFG::GenerationInfo::initDouble): + (JSC::DFG::GenerationInfo::initStorage): + (JSC::DFG::GenerationInfo::noticeOSRBirth): + (JSC::DFG::GenerationInfo::use): + (JSC::DFG::GenerationInfo::appendFill): + (JSC::DFG::GenerationInfo::appendSpill): + (GenerationInfo): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + * dfg/DFGMinifiedGraph.h: + (JSC::DFG::MinifiedGraph::at): + (MinifiedGraph): + * dfg/DFGMinifiedID.h: Added. + (DFG): + (MinifiedID): + (JSC::DFG::MinifiedID::MinifiedID): + (JSC::DFG::MinifiedID::operator!): + (JSC::DFG::MinifiedID::nodeIndex): + (JSC::DFG::MinifiedID::operator==): + (JSC::DFG::MinifiedID::operator!=): + (JSC::DFG::MinifiedID::operator<): + (JSC::DFG::MinifiedID::operator>): + (JSC::DFG::MinifiedID::operator<=): + (JSC::DFG::MinifiedID::operator>=): + (JSC::DFG::MinifiedID::hash): + (JSC::DFG::MinifiedID::dump): + (JSC::DFG::MinifiedID::isHashTableDeletedValue): + (JSC::DFG::MinifiedID::invalidID): + (JSC::DFG::MinifiedID::otherInvalidID): + (JSC::DFG::MinifiedID::fromBits): + (JSC::DFG::MinifiedIDHash::hash): + (JSC::DFG::MinifiedIDHash::equal): + (MinifiedIDHash): + (WTF): + * dfg/DFGMinifiedNode.cpp: + (JSC::DFG::MinifiedNode::fromNode): + * dfg/DFGMinifiedNode.h: + (JSC::DFG::MinifiedNode::id): + (JSC::DFG::MinifiedNode::child1): + (JSC::DFG::MinifiedNode::getID): + (JSC::DFG::MinifiedNode::compareByNodeIndex): + (MinifiedNode): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileMovHint): + (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::setNodeIndexForOperand): + * dfg/DFGValueSource.cpp: + (JSC::DFG::ValueSource::dump): + * dfg/DFGValueSource.h: + (JSC::DFG::ValueSource::ValueSource): + (JSC::DFG::ValueSource::isSet): + (JSC::DFG::ValueSource::kind): + (JSC::DFG::ValueSource::id): + (ValueSource): + (JSC::DFG::ValueSource::idFromKind): + (JSC::DFG::ValueSource::kindFromID): + * dfg/DFGVariableEvent.cpp: + (JSC::DFG::VariableEvent::dump): + (JSC::DFG::VariableEvent::dumpFillInfo): + (JSC::DFG::VariableEvent::dumpSpillInfo): + * dfg/DFGVariableEvent.h: + (JSC::DFG::VariableEvent::fillGPR): + (JSC::DFG::VariableEvent::fillPair): + (JSC::DFG::VariableEvent::fillFPR): + (JSC::DFG::VariableEvent::spill): + (JSC::DFG::VariableEvent::death): + (JSC::DFG::VariableEvent::movHint): + (JSC::DFG::VariableEvent::id): + (VariableEvent): + * dfg/DFGVariableEventStream.cpp: + (DFG): + (JSC::DFG::VariableEventStream::tryToSetConstantRecovery): + (JSC::DFG::VariableEventStream::reconstruct): + * dfg/DFGVariableEventStream.h: + (VariableEventStream): + +2013-01-25 Roger Fong <roger_fong@apple.com> + + Unreviewed. Rename LLInt projects folder and make appropriate changes to solutions. + + * JavaScriptCore.vcxproj/JavaScriptCore.sln: + * JavaScriptCore.vcxproj/LLInt: Copied from JavaScriptCore.vcxproj/LLInt.vcproj. + * JavaScriptCore.vcxproj/LLInt.vcproj: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.make: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.vcxproj: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.vcxproj.user: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj.user: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj.user: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Removed. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: Removed. + +2013-01-24 Roger Fong <roger_fong@apple.com> + + VS2010 JavascriptCore: Clean up property sheets, add a JSC solution, add testRegExp and testAPI projects. + https://bugs.webkit.org/show_bug.cgi?id=106987 + + Reviewed by Brent Fulgham. + + * JavaScriptCore.vcxproj/JavaScriptCore.sln: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreCF.props: + * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: + * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd: + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: + * JavaScriptCore.vcxproj/jsc/jscCommon.props: + * JavaScriptCore.vcxproj/jsc/jscDebug.props: + * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: + * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: + * JavaScriptCore.vcxproj/testRegExp: Added. + * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Added. + * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: Added. + * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.user: Added. + * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: Added. + * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props: Added. + * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: Added. + * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd: Added. + * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: Added. + * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: Added. + * JavaScriptCore.vcxproj/testapi: Added. + * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Added. + * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters: Added. + * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.user: Added. + * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Added. + * JavaScriptCore.vcxproj/testapi/testapiDebug.props: Added. + * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd: Added. + * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd: Added. + * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: Added. + * JavaScriptCore.vcxproj/testapi/testapiRelease.props: Added. + +2013-01-24 Roger Fong <roger_fong@apple.com> + + Unreviewed. Windows build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + +2013-01-24 Filip Pizlo <fpizlo@apple.com> + + DFG::JITCompiler::getSpeculation() methods are badly named and superfluous + https://bugs.webkit.org/show_bug.cgi?id=107860 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGJITCompiler.h: + (JITCompiler): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + (JSC::DFG::SpeculativeJIT::emitBranch): + +2013-01-24 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Rename JSValue.h/APIJSValue.h to JSCJSValue.h/JSValue.h + https://bugs.webkit.org/show_bug.cgi?id=107327 + + Reviewed by Filip Pizlo. + + We're renaming these two files, so we have to replace the names everywhere. + + * API/APICast.h: + * API/APIJSValue.h: Removed. + * API/JSBlockAdaptor.mm: + * API/JSStringRefCF.cpp: + * API/JSValue.h: Copied from Source/JavaScriptCore/API/APIJSValue.h. + * API/JSValue.mm: + * API/JSValueInternal.h: + * API/JSValueRef.cpp: + * API/JSWeakObjectMapRefPrivate.cpp: + * API/JavaScriptCore.h: + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CallLinkStatus.h: + * bytecode/CodeBlock.cpp: + * bytecode/MethodOfGettingAValueProfile.h: + * bytecode/ResolveGlobalStatus.cpp: + * bytecode/ResolveGlobalStatus.h: + * bytecode/SpeculatedType.h: + * bytecode/ValueRecovery.h: + * dfg/DFGByteCodeParser.cpp: + * dfg/DFGJITCompiler.cpp: + * dfg/DFGNode.h: + * dfg/DFGSpeculativeJIT.cpp: + * dfg/DFGSpeculativeJIT64.cpp: + * heap/CopiedBlock.h: + * heap/HandleStack.cpp: + * heap/HandleTypes.h: + * heap/WeakImpl.h: + * interpreter/Interpreter.h: + * interpreter/Register.h: + * interpreter/VMInspector.h: + * jit/HostCallReturnValue.cpp: + * jit/HostCallReturnValue.h: + * jit/JITCode.h: + * jit/JITExceptions.cpp: + * jit/JITExceptions.h: + * jit/JSInterfaceJIT.h: + * llint/LLIntCLoop.h: + * llint/LLIntData.h: + * llint/LLIntSlowPaths.cpp: + * profiler/ProfilerBytecode.h: + * profiler/ProfilerBytecodeSequence.h: + * profiler/ProfilerBytecodes.h: + * profiler/ProfilerCompilation.h: + * profiler/ProfilerCompiledBytecode.h: + * profiler/ProfilerDatabase.h: + * profiler/ProfilerOSRExit.h: + * profiler/ProfilerOSRExitSite.h: + * profiler/ProfilerOrigin.h: + * profiler/ProfilerOriginStack.h: + * runtime/ArgList.cpp: + * runtime/CachedTranscendentalFunction.h: + * runtime/CallData.h: + * runtime/Completion.h: + * runtime/ConstructData.h: + * runtime/DateConstructor.cpp: + * runtime/DateInstance.cpp: + * runtime/DatePrototype.cpp: + * runtime/JSAPIValueWrapper.h: + * runtime/JSCJSValue.cpp: Copied from Source/JavaScriptCore/runtime/JSValue.cpp. + * runtime/JSCJSValue.h: Copied from Source/JavaScriptCore/runtime/JSValue.h. + (JSValue): + * runtime/JSCJSValueInlines.h: Copied from Source/JavaScriptCore/runtime/JSValueInlines.h. + * runtime/JSGlobalData.h: + * runtime/JSGlobalObject.cpp: + * runtime/JSGlobalObjectFunctions.h: + * runtime/JSStringJoiner.h: + * runtime/JSValue.cpp: Removed. + * runtime/JSValue.h: Removed. + * runtime/JSValueInlines.h: Removed. + * runtime/LiteralParser.h: + * runtime/Operations.h: + * runtime/PropertyDescriptor.h: + * runtime/PropertySlot.h: + * runtime/Protect.h: + * runtime/RegExpPrototype.cpp: + * runtime/Structure.h: + +2013-01-23 Oliver Hunt <oliver@apple.com> + + Harden JSC a bit with RELEASE_ASSERT + https://bugs.webkit.org/show_bug.cgi?id=107766 + + Reviewed by Mark Hahnenberg. + + Went through and replaced a pile of ASSERTs that were covering + significantly important details (bounds checks, etc) where + having the checks did not impact release performance in any + measurable way. + + * API/JSContextRef.cpp: + (JSContextCreateBacktrace): + * assembler/MacroAssembler.h: + (JSC::MacroAssembler::branchAdd32): + (JSC::MacroAssembler::branchMul32): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecode): + (JSC::CodeBlock::handlerForBytecodeOffset): + (JSC::CodeBlock::lineNumberForBytecodeOffset): + (JSC::CodeBlock::bytecodeOffset): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::bytecodeOffsetForCallAtIndex): + (JSC::CodeBlock::bytecodeOffset): + (JSC::CodeBlock::exceptionHandler): + (JSC::CodeBlock::codeOrigin): + (JSC::CodeBlock::immediateSwitchJumpTable): + (JSC::CodeBlock::characterSwitchJumpTable): + (JSC::CodeBlock::stringSwitchJumpTable): + (JSC::CodeBlock::setIdentifiers): + (JSC::baselineCodeBlockForInlineCallFrame): + (JSC::ExecState::uncheckedR): + * bytecode/CodeOrigin.cpp: + (JSC::CodeOrigin::inlineStack): + * bytecode/CodeOrigin.h: + (JSC::CodeOrigin::CodeOrigin): + * dfg/DFGCSEPhase.cpp: + * dfg/DFGOSRExit.cpp: + * dfg/DFGScratchRegisterAllocator.h: + (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer): + (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::allocate): + (JSC::DFG::SpeculativeJIT::spill): + (JSC::DFG::SpeculativeJIT::integerResult): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::fillDouble): + (JSC::DFG::SpeculativeJIT::fillJSValue): + (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull): + (JSC::DFG::SpeculativeJIT::emitCall): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGValueSource.h: + (JSC::DFG::dataFormatToValueSourceKind): + (JSC::DFG::ValueSource::ValueSource): + * dfg/DFGVirtualRegisterAllocationPhase.cpp: + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::BlockAllocator): + (JSC::BlockAllocator::releaseFreeRegions): + (JSC::BlockAllocator::blockFreeingThreadMain): + * heap/Heap.cpp: + (JSC::Heap::lastChanceToFinalize): + (JSC::Heap::collect): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::throwException): + (JSC::Interpreter::execute): + * jit/GCAwareJITStubRoutine.cpp: + (JSC::GCAwareJITStubRoutine::observeZeroRefCount): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JITExceptions.cpp: + (JSC::genericThrow): + * jit/JITInlines.h: + (JSC::JIT::emitLoad): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_end): + (JSC::JIT::emit_resolve_operations): + * jit/JITStubRoutine.cpp: + (JSC::JITStubRoutine::observeZeroRefCount): + * jit/JITStubs.cpp: + (JSC::returnToThrowTrampoline): + * runtime/Arguments.cpp: + (JSC::Arguments::getOwnPropertySlot): + (JSC::Arguments::getOwnPropertyDescriptor): + (JSC::Arguments::deleteProperty): + (JSC::Arguments::defineOwnProperty): + (JSC::Arguments::didTearOffActivation): + * runtime/ArrayPrototype.cpp: + (JSC::shift): + (JSC::unshift): + (JSC::arrayProtoFuncLastIndexOf): + * runtime/ButterflyInlines.h: + (JSC::Butterfly::growPropertyStorage): + * runtime/CodeCache.cpp: + (JSC::CodeCache::getFunctionExecutableFromGlobalCode): + * runtime/CodeCache.h: + (JSC::CacheMap::add): + * runtime/Completion.cpp: + (JSC::checkSyntax): + (JSC::evaluate): + * runtime/Executable.cpp: + (JSC::FunctionExecutable::FunctionExecutable): + (JSC::EvalExecutable::unlinkCalls): + (JSC::ProgramExecutable::compileOptimized): + (JSC::ProgramExecutable::unlinkCalls): + (JSC::ProgramExecutable::initializeGlobalProperties): + (JSC::FunctionExecutable::baselineCodeBlockFor): + (JSC::FunctionExecutable::compileOptimizedForCall): + (JSC::FunctionExecutable::compileOptimizedForConstruct): + (JSC::FunctionExecutable::compileForCallInternal): + (JSC::FunctionExecutable::compileForConstructInternal): + (JSC::FunctionExecutable::unlinkCalls): + (JSC::NativeExecutable::hashFor): + * runtime/Executable.h: + (JSC::EvalExecutable::compile): + (JSC::ProgramExecutable::compile): + (JSC::FunctionExecutable::compileForCall): + (JSC::FunctionExecutable::compileForConstruct): + * runtime/IndexingHeader.h: + (JSC::IndexingHeader::setVectorLength): + * runtime/JSArray.cpp: + (JSC::JSArray::pop): + (JSC::JSArray::shiftCountWithArrayStorage): + (JSC::JSArray::shiftCountWithAnyIndexingType): + (JSC::JSArray::unshiftCountWithArrayStorage): + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::jsStrDecimalLiteral): + * runtime/JSObject.cpp: + (JSC::JSObject::copyButterfly): + (JSC::JSObject::defineOwnIndexedProperty): + (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): + * runtime/JSString.cpp: + (JSC::JSRopeString::getIndexSlowCase): + * yarr/YarrInterpreter.cpp: + (JSC::Yarr::Interpreter::popParenthesesDisjunctionContext): + +2013-01-23 Filip Pizlo <fpizlo@apple.com> + + Constant folding an access to an uncaptured variable that is captured later in the same basic block shouldn't lead to assertion failures + https://bugs.webkit.org/show_bug.cgi?id=107750 + <rdar://problem/12387265> + + Reviewed by Mark Hahnenberg. + + The point of this assertion was that if there is no variable capturing going on, then there should only be one GetLocal + for the variable anywhere in the basic block. But if there is some capturing, then we'll have an unbounded number of + GetLocals. The assertion was too imprecise for the latter case. I want to keep this assertion, so I introduced a + checker that verifies this precisely: if there are any captured accesses to the variable anywhere at or after the + GetLocal we are eliminating, then we allow redundant GetLocals. + + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + (ConstantFoldingPhase): + (JSC::DFG::ConstantFoldingPhase::isCapturedAtOrAfter): + +2013-01-23 Oliver Hunt <oliver@apple.com> + + Replace ASSERT_NOT_REACHED with RELEASE_ASSERT_NOT_REACHED in JSC + https://bugs.webkit.org/show_bug.cgi?id=107736 + + Reviewed by Mark Hahnenberg. + + Mechanical change with no performance impact. + + * API/JSBlockAdaptor.mm: + (BlockArgumentTypeDelegate::typeVoid): + * API/JSCallbackObjectFunctions.h: + (JSC::::construct): + (JSC::::call): + * API/JSScriptRef.cpp: + * API/ObjCCallbackFunction.mm: + (ArgumentTypeDelegate::typeVoid): + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::link): + (JSC::ARMv7Assembler::replaceWithLoad): + (JSC::ARMv7Assembler::replaceWithAddressComputation): + * assembler/MacroAssembler.h: + (JSC::MacroAssembler::invert): + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::countLeadingZeros32): + (JSC::MacroAssemblerARM::divDouble): + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::absDouble): + (JSC::MacroAssemblerMIPS::replaceWithJump): + (JSC::MacroAssemblerMIPS::maxJumpReplacementSize): + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::absDouble): + (JSC::MacroAssemblerSH4::replaceWithJump): + (JSC::MacroAssemblerSH4::maxJumpReplacementSize): + * assembler/SH4Assembler.h: + (JSC::SH4Assembler::shllImm8r): + (JSC::SH4Assembler::shlrImm8r): + (JSC::SH4Assembler::cmplRegReg): + (JSC::SH4Assembler::branch): + * assembler/X86Assembler.h: + (JSC::X86Assembler::replaceWithLoad): + (JSC::X86Assembler::replaceWithAddressComputation): + * bytecode/CallLinkInfo.cpp: + (JSC::CallLinkInfo::unlink): + * bytecode/CodeBlock.cpp: + (JSC::debugHookName): + (JSC::CodeBlock::printGetByIdOp): + (JSC::CodeBlock::printGetByIdCacheStatus): + (JSC::CodeBlock::visitAggregate): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::usesOpcode): + * bytecode/DataFormat.h: + (JSC::needDataFormatConversion): + * bytecode/ExitKind.cpp: + (JSC::exitKindToString): + (JSC::exitKindIsCountable): + * bytecode/MethodOfGettingAValueProfile.cpp: + (JSC::MethodOfGettingAValueProfile::getSpecFailBucket): + * bytecode/Opcode.h: + (JSC::opcodeLength): + * bytecode/PolymorphicPutByIdList.cpp: + (JSC::PutByIdAccess::fromStructureStubInfo): + (JSC::PutByIdAccess::visitWeak): + * bytecode/StructureStubInfo.cpp: + (JSC::StructureStubInfo::deref): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::ResolveResult::checkValidity): + (JSC::BytecodeGenerator::emitGetLocalVar): + (JSC::BytecodeGenerator::beginSwitch): + * bytecompiler/NodesCodegen.cpp: + (JSC::BinaryOpNode::emitBytecode): + (JSC::emitReadModifyAssignment): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::mergeStateAtTail): + (JSC::DFG::AbstractState::mergeToSuccessors): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::makeSafe): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): + (JSC::DFG::CFGSimplificationPhase::fixTailOperand): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::setLocalStoreElimination): + * dfg/DFGCapabilities.cpp: + (JSC::DFG::canHandleOpcodes): + * dfg/DFGCommon.h: + (JSC::DFG::useKindToString): + * dfg/DFGDoubleFormatState.h: + (JSC::DFG::mergeDoubleFormatStates): + (JSC::DFG::doubleFormatStateToString): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::blessArrayOperation): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::clobbersWorld): + * dfg/DFGNode.h: + (JSC::DFG::Node::valueOfJSConstant): + (JSC::DFG::Node::successor): + * dfg/DFGNodeFlags.cpp: + (JSC::DFG::nodeFlagsAsString): + * dfg/DFGNodeType.h: + (JSC::DFG::defaultFlags): + * dfg/DFGRepatch.h: + (JSC::DFG::dfgResetGetByID): + (JSC::DFG::dfgResetPutByID): + * dfg/DFGSlowPathGenerator.h: + (JSC::DFG::SlowPathGenerator::call): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR): + (JSC::DFG::SpeculativeJIT::silentSpill): + (JSC::DFG::SpeculativeJIT::silentFill): + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::bitOp): + (JSC::DFG::SpeculativeJIT::shiftOp): + (JSC::DFG::SpeculativeJIT::integerResult): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::fillDouble): + (JSC::DFG::SpeculativeJIT::fillJSValue): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::fillDouble): + (JSC::DFG::SpeculativeJIT::fillJSValue): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * dfg/DFGValueSource.h: + (JSC::DFG::ValueSource::valueRecovery): + * dfg/DFGVariableEvent.cpp: + (JSC::DFG::VariableEvent::dump): + * dfg/DFGVariableEventStream.cpp: + (JSC::DFG::VariableEventStream::reconstruct): + * heap/BlockAllocator.h: + (JSC::BlockAllocator::regionSetFor): + * heap/GCThread.cpp: + (JSC::GCThread::gcThreadMain): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::sweepHelper): + * heap/MarkedBlock.h: + (JSC::MarkedBlock::isLive): + * interpreter/CallFrame.h: + (JSC::ExecState::inlineCallFrame): + * interpreter/Interpreter.cpp: + (JSC::getCallerInfo): + (JSC::getStackFrameCodeType): + (JSC::Interpreter::execute): + * jit/ExecutableAllocatorFixedVMPool.cpp: + (JSC::FixedVMPoolExecutableAllocator::notifyPageIsFree): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + (JSC::JIT::privateCompile): + * jit/JITArithmetic.cpp: + (JSC::JIT::emitSlow_op_mod): + * jit/JITArithmetic32_64.cpp: + (JSC::JIT::emitBinaryDoubleOp): + (JSC::JIT::emitSlow_op_mod): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::isDirectPutById): + * jit/JITStubs.cpp: + (JSC::getPolymorphicAccessStructureListSlot): + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::jitCompileAndSetHeuristics): + * parser/Lexer.cpp: + (JSC::::lex): + * parser/Nodes.h: + (JSC::ExpressionNode::emitBytecodeInConditionContext): + * parser/Parser.h: + (JSC::Parser::getTokenName): + (JSC::Parser::updateErrorMessageSpecialCase): + * parser/SyntaxChecker.h: + (JSC::SyntaxChecker::operatorStackPop): + * runtime/Arguments.cpp: + (JSC::Arguments::tearOffForInlineCallFrame): + * runtime/DatePrototype.cpp: + (JSC::formatLocaleDate): + * runtime/Executable.cpp: + (JSC::samplingDescription): + * runtime/Executable.h: + (JSC::ScriptExecutable::unlinkCalls): + * runtime/Identifier.cpp: + (JSC): + * runtime/InternalFunction.cpp: + (JSC::InternalFunction::getCallData): + * runtime/JSArray.cpp: + (JSC::JSArray::push): + (JSC::JSArray::sort): + * runtime/JSCell.cpp: + (JSC::JSCell::defaultValue): + (JSC::JSCell::getOwnPropertyNames): + (JSC::JSCell::getOwnNonIndexPropertyNames): + (JSC::JSCell::className): + (JSC::JSCell::getPropertyNames): + (JSC::JSCell::customHasInstance): + (JSC::JSCell::putDirectVirtual): + (JSC::JSCell::defineOwnProperty): + (JSC::JSCell::getOwnPropertyDescriptor): + * runtime/JSCell.h: + (JSCell): + * runtime/JSNameScope.cpp: + (JSC::JSNameScope::put): + * runtime/JSObject.cpp: + (JSC::JSObject::getOwnPropertySlotByIndex): + (JSC::JSObject::putByIndex): + (JSC::JSObject::ensureArrayStorageSlow): + (JSC::JSObject::deletePropertyByIndex): + (JSC::JSObject::getOwnPropertyNames): + (JSC::JSObject::putByIndexBeyondVectorLength): + (JSC::JSObject::putDirectIndexBeyondVectorLength): + (JSC::JSObject::getOwnPropertyDescriptor): + * runtime/JSObject.h: + (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): + * runtime/JSScope.cpp: + (JSC::JSScope::isDynamicScope): + * runtime/JSSymbolTableObject.cpp: + (JSC::JSSymbolTableObject::putDirectVirtual): + * runtime/JSSymbolTableObject.h: + (JSSymbolTableObject): + * runtime/LiteralParser.cpp: + (JSC::::parse): + * runtime/RegExp.cpp: + (JSC::RegExp::compile): + (JSC::RegExp::compileMatchOnly): + * runtime/StructureTransitionTable.h: + (JSC::newIndexingType): + * tools/CodeProfile.cpp: + (JSC::CodeProfile::sample): + * yarr/YarrCanonicalizeUCS2.h: + (JSC::Yarr::getCanonicalPair): + (JSC::Yarr::areCanonicallyEquivalent): + * yarr/YarrInterpreter.cpp: + (JSC::Yarr::Interpreter::matchCharacterClass): + (JSC::Yarr::Interpreter::matchBackReference): + (JSC::Yarr::Interpreter::backtrackParenthesesTerminalEnd): + (JSC::Yarr::Interpreter::matchParentheses): + (JSC::Yarr::Interpreter::backtrackParentheses): + (JSC::Yarr::Interpreter::matchDisjunction): + * yarr/YarrJIT.cpp: + (JSC::Yarr::YarrGenerator::generateTerm): + (JSC::Yarr::YarrGenerator::backtrackTerm): + * yarr/YarrParser.h: + (JSC::Yarr::Parser::CharacterClassParserDelegate::assertionWordBoundary): + (JSC::Yarr::Parser::CharacterClassParserDelegate::atomBackReference): + * yarr/YarrPattern.cpp: + (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn): + +2013-01-23 Tony Chang <tony@chromium.org> + + Unreviewed, set svn:eol-style to CRLF on Windows .sln files. + + * JavaScriptCore.vcproj/JavaScriptCore.sln: Modified property svn:eol-style. + * JavaScriptCore.vcproj/JavaScriptCoreSubmit.sln: Modified property svn:eol-style. + +2013-01-23 Oliver Hunt <oliver@apple.com> + + Replace numerous manual CRASH's in JSC with RELEASE_ASSERT + https://bugs.webkit.org/show_bug.cgi?id=107726 + + Reviewed by Filip Pizlo. + + Fairly manual change from if (foo) CRASH(); to RELEASE_ASSERT(!foo); + + * assembler/MacroAssembler.h: + (JSC::MacroAssembler::branchAdd32): + (JSC::MacroAssembler::branchMul32): + * bytecode/CodeBlockHash.cpp: + (JSC::CodeBlockHash::CodeBlockHash): + * heap/BlockAllocator.h: + (JSC::Region::create): + (JSC::Region::createCustomSize): + * heap/GCAssertions.h: + * heap/HandleSet.cpp: + (JSC::HandleSet::visitStrongHandles): + (JSC::HandleSet::writeBarrier): + * heap/HandleSet.h: + (JSC::HandleSet::allocate): + * heap/Heap.cpp: + (JSC::Heap::collect): + * heap/SlotVisitor.cpp: + (JSC::SlotVisitor::validate): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::execute): + * jit/ExecutableAllocator.cpp: + (JSC::DemandExecutableAllocator::allocateNewSpace): + (JSC::ExecutableAllocator::allocate): + * jit/ExecutableAllocator.h: + (JSC::roundUpAllocationSize): + * jit/ExecutableAllocatorFixedVMPool.cpp: + (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): + (JSC::ExecutableAllocator::allocate): + * runtime/ButterflyInlines.h: + (JSC::Butterfly::createUninitialized): + * runtime/Completion.cpp: + (JSC::evaluate): + * runtime/JSArray.h: + (JSC::constructArray): + * runtime/JSGlobalObject.cpp: + (JSC::slowValidateCell): + * runtime/JSObject.cpp: + (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): + (JSC::JSObject::createArrayStorage): + * tools/TieredMMapArray.h: + (JSC::TieredMMapArray::append): + * yarr/YarrInterpreter.cpp: + (JSC::Yarr::Interpreter::allocDisjunctionContext): + (JSC::Yarr::Interpreter::allocParenthesesDisjunctionContext): + (JSC::Yarr::Interpreter::InputStream::readChecked): + (JSC::Yarr::Interpreter::InputStream::uncheckInput): + (JSC::Yarr::Interpreter::InputStream::atEnd): + (JSC::Yarr::Interpreter::interpret): + +2013-01-22 Filip Pizlo <fpizlo@apple.com> + + Convert CSE phase to not rely too much on NodeIndex + https://bugs.webkit.org/show_bug.cgi?id=107616 + + Reviewed by Geoffrey Garen. + + - Instead of looping over the graph (which assumes that you can simply loop over all + nodes without considering blocks first) to reset node.replacement, do that in the + loop that sets up relevantToOSR, just before running CSE on the block. + + - Instead of having a relevantToOSR bitvector indexed by NodeIndex, made + NodeRelevantToOSR be a NodeFlag. We had exactly one bit left in NodeFlags, so I did + some reshuffling to fit it in. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::CSEPhase): + (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren): + (JSC::DFG::CSEPhase::performNodeCSE): + (JSC::DFG::CSEPhase::performBlockCSE): + (CSEPhase): + * dfg/DFGNodeFlags.h: + (DFG): + * dfg/DFGNodeType.h: + (DFG): + +2013-01-21 Kentaro Hara <haraken@chromium.org> + + Implement UIEvent constructor + https://bugs.webkit.org/show_bug.cgi?id=107430 + + Reviewed by Adam Barth. + + Editor's draft: https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm + + UIEvent constructor is implemented under a DOM4_EVENTS_CONSTRUCTOR flag, + which is enabled on Safari and Chromium for now. + + * Configurations/FeatureDefines.xcconfig: + +2013-01-22 Roger Fong <roger_fong@apple.com> + + Unreviewed VS2010 build fix following r140259. + + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: + +2013-01-22 Roger Fong <roger_fong@apple.com> + + JavaScriptCore property sheets, project files and modified build scripts. + https://bugs.webkit.org/show_bug.cgi?id=106987 + + Reviewed by Brent Fulgham. + + * JavaScriptCore.vcxproj: Added. + * JavaScriptCore.vcxproj/JavaScriptCore.resources: Added. + * JavaScriptCore.vcxproj/JavaScriptCore.resources/Info.plist: Added. + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Added. + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Added. + * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.user: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreCF.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreDebug.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreExports.def: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj.filters: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj.user: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedCommon.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedDebug.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreGeneratedRelease.props: Added. + * JavaScriptCore.vcxproj/JavaScriptCorePostBuild.cmd: Added. + * JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd: Added. + * JavaScriptCore.vcxproj/JavaScriptCorePreLink.cmd: Added. + * JavaScriptCore.vcxproj/JavaScriptCoreRelease.props: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.make: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.vcxproj: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/LLIntAssembly.vcxproj.user: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj.user: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj.user: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Added. + * JavaScriptCore.vcxproj/LLInt.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: Added. + * JavaScriptCore.vcxproj/build-generated-files.sh: Added. + * JavaScriptCore.vcxproj/copy-files.cmd: Added. + * JavaScriptCore.vcxproj/jsc: Added. + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Added. + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Added. + * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.user: Added. + * JavaScriptCore.vcxproj/jsc/jscCommon.props: Added. + * JavaScriptCore.vcxproj/jsc/jscDebug.props: Added. + * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: Added. + * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd: Added. + * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: Added. + * JavaScriptCore.vcxproj/jsc/jscRelease.props: Added. + * config.h: + +2013-01-22 Joseph Pecoraro <pecoraro@apple.com> + + [Mac] Enable Page Visibility (PAGE_VISIBILITY_API) + https://bugs.webkit.org/show_bug.cgi?id=107230 + + Reviewed by David Kilzer. + + * Configurations/FeatureDefines.xcconfig: + +2013-01-22 Tobias Netzel <tobias.netzel@googlemail.com> + + Yarr JIT isn't big endian compatible + https://bugs.webkit.org/show_bug.cgi?id=102897 + + Reviewed by Oliver Hunt. + + This patch was tested in the current mozilla codebase only and has passed the regexp tests there. + + * yarr/YarrJIT.cpp: + (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce): + +2013-01-22 David Kilzer <ddkilzer@apple.com> + + Fix DateMath.cpp to compile with -Wshorten-64-to-32 + <http://webkit.org/b/107503> + + Reviewed by Darin Adler. + + * runtime/JSDateMath.cpp: + (JSC::parseDateFromNullTerminatedCharacters): Remove unneeded + static_cast<int>(). + +2013-01-22 Tim Horton <timothy_horton@apple.com> + + PDFPlugin: Build PDFPlugin everywhere, enable at runtime + https://bugs.webkit.org/show_bug.cgi?id=107117 + + Reviewed by Alexey Proskuryakov. + + Since PDFLayerController SPI is all forward-declared, the plugin should build + on all Mac platforms, and can be enabled at runtime. + + * Configurations/FeatureDefines.xcconfig: + +2013-01-21 Justin Schuh <jschuh@chromium.org> + + [CHROMIUM] Suppress c4267 build warnings for Win64 targets + https://bugs.webkit.org/show_bug.cgi?id=107499 + + Reviewed by Abhishek Arya. + + * JavaScriptCore.gyp/JavaScriptCore.gyp: + +2013-01-21 Dirk Schulze <dschulze@adobe.com> + + Add build flag for Canvas's Path object (disabled by default) + https://bugs.webkit.org/show_bug.cgi?id=107473 + + Reviewed by Dean Jackson. + + Add CANVAS_PATH build flag to build systems. + + * Configurations/FeatureDefines.xcconfig: + +2013-01-20 Geoffrey Garen <ggaren@apple.com> + + Weak GC maps should be easier to use + https://bugs.webkit.org/show_bug.cgi?id=107312 + + Reviewed by Sam Weinig. + + Follow-up fix. + + * runtime/PrototypeMap.cpp: + (JSC::PrototypeMap::emptyObjectStructureForPrototype): Restored this + ASSERT, which was disabled because of a bug in WeakGCMap. + + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::add): We can't pass our passed-in value to add() because + a PassWeak() clears itself when passed to another function. So, we pass + nullptr instead, and fix things up afterwards. + +2013-01-20 Geoffrey Garen <ggaren@apple.com> + + Unreviewed. + + Temporarily disabling this ASSERT to get the bots green + while I investigate a fix. + + * runtime/PrototypeMap.cpp: + (JSC::PrototypeMap::emptyObjectStructureForPrototype): + +2013-01-20 Filip Pizlo <fpizlo@apple.com> + + Inserting a node into the DFG graph should not require five lines of code + https://bugs.webkit.org/show_bug.cgi?id=107381 + + Reviewed by Sam Weinig. + + This adds fairly comprehensive support for inserting a node into a DFG graph in one + method call. A common example of this is: + + m_insertionSet.insertNode(indexInBlock, DontRefChildren, DontRefNode, SpecNone, ForceOSRExit, codeOrigin); + + The arguments to insert() specify what reference counting you need to have happen + (RefChildren => recursively refs all children, RefNode => non-recursively refs the node + that was created), the prediction to set (SpecNone is a common default), followed by + the arguments to the Node() constructor. InsertionSet::insertNode() and similar methods + (Graph::addNode() and BasicBlock::appendNode()) all use a common variadic template + function macro from DFGVariadicFunction.h. Also, all of these methods will automatically + non-recursively ref() the node being created if the flags say NodeMustGenerate. + + In all, this new mechanism retains the flexibility of the old approach (you get to + manage ref counts yourself, albeit in less code) while ensuring that most code that adds + nodes to the graph now needs less code to do it. + + In the future, we should revisit the reference counting methodology in the DFG: we could + do like most compilers and get rid of it entirely, or we could make it automatic. This + patch doesn't attempt to make any such major changes, and only seeks to simplify the + technique we were already using (manual ref counting). + + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/Operands.h: + (JSC::dumpOperands): + * dfg/DFGAdjacencyList.h: + (AdjacencyList): + (JSC::DFG::AdjacencyList::kind): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGBasicBlock.h: + (DFG): + (BasicBlock): + * dfg/DFGBasicBlockInlines.h: Added. + (DFG): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::keepOperandAlive): + * dfg/DFGCommon.h: + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::ConstantFoldingPhase): + (JSC::DFG::ConstantFoldingPhase::foldConstants): + (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck): + (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode): + (ConstantFoldingPhase): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::FixupPhase): + (JSC::DFG::FixupPhase::fixupBlock): + (JSC::DFG::FixupPhase::fixupNode): + (FixupPhase): + (JSC::DFG::FixupPhase::checkArray): + (JSC::DFG::FixupPhase::blessArrayOperation): + (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::ref): + (Graph): + * dfg/DFGInsertionSet.h: + (DFG): + (JSC::DFG::Insertion::Insertion): + (JSC::DFG::Insertion::element): + (Insertion): + (JSC::DFG::InsertionSet::InsertionSet): + (JSC::DFG::InsertionSet::insert): + (InsertionSet): + (JSC::DFG::InsertionSet::execute): + * dfg/DFGNode.h: + (JSC::DFG::Node::Node): + (Node): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * dfg/DFGVariadicFunction.h: Added. + +2013-01-19 Geoffrey Garen <ggaren@apple.com> + + Track inheritance structures in a side table, instead of using a private + name in each prototype + https://bugs.webkit.org/show_bug.cgi?id=107378 + + Reviewed by Sam Weinig and Phil Pizlo. + + This is a step toward object size inference. + + Using a side table frees us to use a more complex key (a pair of + prototype and expected inline capacity). + + It also avoids ruining inline caches for prototypes. (Adding a new private + name for a new inline capacity would change the prototype's structure, + possibly firing watchpoints, making inline caches go polymorphic, and + generally causing us to have a bad time.) + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: Buildage. + + * runtime/ArrayPrototype.cpp: + (JSC::ArrayPrototype::finishCreation): Updated to use new side table API. + + * runtime/JSFunction.cpp: + (JSC::JSFunction::cacheInheritorID): Updated to use new side table API. + + (JSC::JSFunction::visitChildren): Fixed a long-standing bug where JSFunction + forgot to visit one of its data members (m_cachedInheritorID). This + wasn't a user-visible problem before because JSFunction would always + visit its .prototype property, which visited its m_cachedInheritorID. + But now, function.prototype only weakly owns function.m_cachedInheritorID. + + * runtime/JSGlobalData.h: + (JSGlobalData): Added the map, taking care to make sure that its + destructor would run after the heap destructor. + + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): Updated to use new side table API. + + * runtime/JSObject.cpp: + (JSC::JSObject::notifyPresenceOfIndexedAccessors): + (JSC::JSObject::setPrototype): + * runtime/JSObject.h: + (JSObject): Updated to use new side table API, and removed lots of code + that used to manage the per-object private name. + + * runtime/JSProxy.cpp: + (JSC::JSProxy::setTarget): + * runtime/ObjectConstructor.cpp: + (JSC::objectConstructorCreate): + * runtime/ObjectPrototype.cpp: + (JSC::ObjectPrototype::finishCreation): Updated to use new side table API. + + * runtime/PrototypeMap.cpp: Added. + (JSC): + (JSC::PrototypeMap::addPrototype): + (JSC::PrototypeMap::emptyObjectStructureForPrototype): + * runtime/PrototypeMap.h: Added. + (PrototypeMap): + (JSC::PrototypeMap::isPrototype): + (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): New side table. + This is a simple weak map, mapping an object to the structure you should + use when inheriting from that object. (In future, inline capacity will + be a part of the mapping.) + + I used two maps to preserve existing behavior that allowed us to speculate + about an object becoming a prototype, even if it wasn't one at the moment. + However, I suspect that behavior can be removed without harm. + + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::contains): + (WeakGCMap): I would rate myself a 6 / 10 in C++. + +2013-01-18 Dan Bernstein <mitz@apple.com> + + Removed duplicate references to two headers in the project files. + + Rubber-stamped by Mark Rowe. + + * JavaScriptCore.xcodeproj/project.pbxproj: + +2013-01-18 Michael Saboff <msaboff@apple.com> + + Unreviewed build fix for building JSC with DFG_ENABLE_DEBUG_PROPAGATION_VERBOSE enabled in DFGCommon.h. + Fixes the case where the argument node in fixupNode is freed due to the Vector storage being reallocated. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + +2013-01-18 Michael Saboff <msaboff@apple.com> + + Unreviewed build fix for release builds when DFG_ENABLE_DEBUG_PROPAGATION_VERBOSE is set to 1 in DFGCommon.h. + + * dfg/DFGCFAPhase.cpp: Added #include "Operations.h" + +2013-01-18 Michael Saboff <msaboff@apple.com> + + Change set r140201 broke editing/selection/move-by-word-visually-multi-line.html + https://bugs.webkit.org/show_bug.cgi?id=107340 + + Reviewed by Filip Pizlo. + + Due to the change landed in r140201, more nodes might end up + generating Int32ToDouble nodes. Therefore, changed the JSVALUE64 + constant path of compileInt32ToDouble() to use the more + restrictive isInt32Constant() check on the input. This check was + the same as the existing ASSERT() so the ASSERT was eliminated. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): + +2013-01-18 Viatcheslav Ostapenko <sl.ostapenko@samsung.com> + + Weak GC maps should be easier to use + https://bugs.webkit.org/show_bug.cgi?id=107312 + + Reviewed by Ryosuke Niwa. + + Build fix for linux platforms after r140194. + + * runtime/WeakGCMap.h: + (WeakGCMap): + +2013-01-18 Michael Saboff <msaboff@apple.com> + + Harden ArithDiv of integers fix-up by inserting Int32ToDouble node directly + https://bugs.webkit.org/show_bug.cgi?id=107321 + + Reviewed by Filip Pizlo. + + Split out the Int32ToDouble node insertion from fixDoubleEdge() and used it directly when we're fixing up + an ArithDiv node with integer inputs and output for platforms that don't have integer division. + Since we are checking that our inputs should be ints, we can just insert the Int32ToDouble node + without any further checks. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::fixDoubleEdge): + (FixupPhase): + (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): + +2013-01-18 Michael Saboff <msaboff@apple.com> + + Fix up of ArithDiv nodes for non-x86 CPUs is broken + https://bugs.webkit.org/show_bug.cgi?id=107309 + + Reviewed by Filip Pizlo. + + Changed the logic so that we insert an Int32ToDouble node when the existing edge is not SpecDouble. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixDoubleEdge): + +2013-01-18 Dan Bernstein <mitz@apple.com> + + Tried to fix the build after r140194. + + * API/JSWrapperMap.mm: + (-[JSWrapperMap wrapperForObject:]): + +2013-01-18 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Update documentation for JSValue and JSContext + https://bugs.webkit.org/show_bug.cgi?id=107313 + + Reviewed by Geoffrey Garen. + + After changing the semantics of object lifetime we need to update the API documentation to reflect the new semantics. + + * API/APIJSValue.h: + * API/JSContext.h: + +2013-01-18 Balazs Kilvady <kilvadyb@homejinni.com> + + r134080 causes heap problem on linux systems where PAGESIZE != 4096 + https://bugs.webkit.org/show_bug.cgi?id=102828 + + Reviewed by Mark Hahnenberg. + + Make MarkStackSegment::blockSize as the capacity of segments of a MarkStackArray. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: + * heap/MarkStack.cpp: + (JSC): + (JSC::MarkStackArray::MarkStackArray): + (JSC::MarkStackArray::expand): + (JSC::MarkStackArray::donateSomeCellsTo): + (JSC::MarkStackArray::stealSomeCellsFrom): + * heap/MarkStack.h: + (JSC::MarkStackSegment::data): + (CapacityFromSize): + (MarkStackArray): + * heap/MarkStackInlines.h: + (JSC::MarkStackArray::setTopForFullSegment): + (JSC::MarkStackArray::append): + (JSC::MarkStackArray::isEmpty): + (JSC::MarkStackArray::size): + * runtime/Options.h: + (JSC): + +2013-01-18 Geoffrey Garen <ggaren@apple.com> + + Weak GC maps should be easier to use + https://bugs.webkit.org/show_bug.cgi?id=107312 + + Reviewed by Sam Weinig. + + This patch changes WeakGCMap to not use a WeakImpl finalizer to remove + items from the map, and to instead have the map automatically remove + stale items itself upon insertion. This has a few advantages: + + (1) WeakGCMap is now compatible with all the specializations you would + use for HashMap. + + (2) There's no need for clients to write special finalization munging + functions. + + (3) Clients can specify custom value finalizers if they like. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Def! + + * API/JSWeakObjectMapRefPrivate.cpp: Setter no longer requires a global + data, since we've reduced interdependency. + + * heap/Handle.h: No more need to forward declare, since we've reduced + interdependency. + + * heap/Weak.h: + (Weak): Use explicit so we can assign directly to a weak map iterator + without ambiguity between Weak<T> and PassWeak<T>. + + * runtime/Structure.cpp: + (JSC::StructureTransitionTable::add): See above. + + * runtime/Structure.h: + (JSC): + * runtime/StructureTransitionTable.h: + (StructureTransitionTable): Bad code goes away, programmer happy. + + * runtime/WeakGCMap.h: + (JSC): + (WeakGCMap): + (JSC::WeakGCMap::WeakGCMap): + (JSC::WeakGCMap::set): + (JSC::WeakGCMap::add): + (JSC::WeakGCMap::find): + (JSC::WeakGCMap::contains): + (JSC::WeakGCMap::gcMap): + (JSC::WeakGCMap::gcMapIfNeeded): Inherit from HashMap and override any + function that might observe a Weak<T> that has died, just enough to + make such items appear as if they are not in the table. + +2013-01-18 Michael Saboff <msaboff@apple.com> + + Refactor isPowerOf2() and add getLSBSet() + https://bugs.webkit.org/show_bug.cgi?id=107306 + + Reviewed by Filip Pizlo. + + Moved implementation of isPowerOf2() to new hasOneBitSet() in wtf/MathExtras.h. + + * runtime/PropertyMapHashTable.h: + (JSC::isPowerOf2): + +2013-01-17 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Clean up JSValue.mm + https://bugs.webkit.org/show_bug.cgi?id=107163 + + Reviewed by Darin Adler. + + m_context is no longer weak, so there is now a lot of dead code in in JSValue.mm, and a wasted message send + on every API call. In the head of just about every method in JSValue.mm we're doing: + + JSContext *context = [self context]; + if (!context) + return nil; + + This is getting a retained copy of the context, which is no longer necessary now m_context is no longer weak. + We can just delete all these lines from all functions doing this, and where they were referring to the local + variable 'context', instead we can just access m_context directly. + + Since we're already going to be modifying most of JSValue.mm, we'll also do the following: + + 1) context @property is no longer weak – the context property is declared as: + + @property(readonly, weak) JSContext *context; + + This is really only informative (since we're not presently synthesizing the ivar), but it is now misleading. + We should change it to: + + @property(readonly, retain) JSContext *context; + + 2) the JSContext ivar and accessor can be automatically generated. Since we're no longer doing anything + special with m_context, we can just let the compiler handle the ivar for us. We'll delete: + + JSContext *m_context; + + and: + + - (JSContext *)context + { + return m_context; + + } + + and find&replace "m_context" to "_context" in JSValue.mm. + + * API/APIJSValue.h: + * API/JSValue.mm: + (-[JSValue toObject]): + (-[JSValue toBool]): + (-[JSValue toDouble]): + (-[JSValue toNumber]): + (-[JSValue toString]): + (-[JSValue toDate]): + (-[JSValue toArray]): + (-[JSValue toDictionary]): + (-[JSValue valueForProperty:]): + (-[JSValue setValue:forProperty:]): + (-[JSValue deleteProperty:]): + (-[JSValue hasProperty:]): + (-[JSValue defineProperty:descriptor:]): + (-[JSValue valueAtIndex:]): + (-[JSValue setValue:atIndex:]): + (-[JSValue isUndefined]): + (-[JSValue isNull]): + (-[JSValue isBoolean]): + (-[JSValue isNumber]): + (-[JSValue isString]): + (-[JSValue isObject]): + (-[JSValue isEqualToObject:]): + (-[JSValue isEqualWithTypeCoercionToObject:]): + (-[JSValue isInstanceOf:]): + (-[JSValue callWithArguments:]): + (-[JSValue constructWithArguments:]): + (-[JSValue invokeMethod:withArguments:]): + (-[JSValue objectForKeyedSubscript:]): + (-[JSValue setObject:forKeyedSubscript:]): + (-[JSValue initWithValue:inContext:]): + (-[JSValue dealloc]): + (-[JSValue description]): + +2013-01-17 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C API: Clean up JSValue + https://bugs.webkit.org/show_bug.cgi?id=107156 + + Reviewed by Oliver Hunt. + + JSContext m_protectCounts, protect, unprotect are all now unnecessary overhead, and should all be removed. + These exist to handle the context going away before the value does; the context needs to be able to unprotect + values early. Since the value is now keeping the context alive there is no longer any danger of this happening; + instead we should just protect/unprotect the value in JSValue's init/dealloc methods. + + * API/JSContext.mm: + (-[JSContext dealloc]): + * API/JSContextInternal.h: + * API/JSValue.mm: + (-[JSValue initWithValue:inContext:]): + (-[JSValue dealloc]): + +2013-01-17 Filip Pizlo <fpizlo@apple.com> + + DFG Node::ref() and Node::deref() should not return bool, and should have postfixRef variants + https://bugs.webkit.org/show_bug.cgi?id=107147 + + Reviewed by Mark Hahnenberg. + + This small refactoring will enable a world where ref() returns Node*, which is useful for + https://bugs.webkit.org/show_bug.cgi?id=106868. Also, while this refactoring does lead to + slightly less terse code, it's also slightly more self-explanatory. I could never quite + remember what the meaning of the bool return from ref() and deref() was. + + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::collectGarbage): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::ref): + (JSC::DFG::Graph::deref): + * dfg/DFGNode.h: + (JSC::DFG::Node::ref): + (Node): + (JSC::DFG::Node::postfixRef): + (JSC::DFG::Node::deref): + (JSC::DFG::Node::postfixDeref): + +2013-01-17 Alexey Proskuryakov <ap@apple.com> + + Added svn:ignore=*.pyc, so that ud_opcode.pyc and ud_optable.pyc don't show up + in svn stat. + + * disassembler/udis86: Added property svn:ignore. + +2013-01-16 Filip Pizlo <fpizlo@apple.com> + + DFG 32_64 backend doesn't check for hasArrayStorage() in NewArrayWithSize + https://bugs.webkit.org/show_bug.cgi?id=107081 + + Reviewed by Michael Saboff. + + This bug led to the 32_64 backend emitting contiguous allocation code to allocate + ArrayStorage arrays. This then led to all manner of heap corruption, since + subsequent array accesses would be accessing the contiguous array "as if" it was + an arraystorage array. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-01-16 Jonathan Liu <net147@gmail.com> + + Add missing sys/mman.h include on Mac + https://bugs.webkit.org/show_bug.cgi?id=98089 + + Reviewed by Darin Adler. + + The madvise function and MADV_FREE constant require sys/mman.h. + + * jit/ExecutableAllocatorFixedVMPool.cpp: + +2013-01-15 Michael Saboff <msaboff@apple.com> + + DFG X86: division in the used-as-int case doesn't correctly check for -2^31/-1 + https://bugs.webkit.org/show_bug.cgi?id=106978 + + Reviewed by Filip Pizlo. + + Changed the numerator equal to -2^31 check to just return if we expect an integer + result, since the check is after we have determined that the denominator is -1. + The int result of -2^31 / -1 is -2^31, so just return the numerator as the result. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileIntegerArithDivForX86): + +2013-01-15 Levi Weintraub <leviw@chromium.org> + + Unreviewed, rolling out r139792. + http://trac.webkit.org/changeset/139792 + https://bugs.webkit.org/show_bug.cgi?id=106970 + + Broke the windows build. + + * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo. + +2013-01-15 Pratik Solanki <psolanki@apple.com> + + Use MADV_FREE_REUSABLE to return JIT memory to OS + https://bugs.webkit.org/show_bug.cgi?id=106830 + <rdar://problem/11437701> + + Reviewed by Geoffrey Garen. + + Use MADV_FREE_REUSABLE to return JIT memory on OSes that have the underlying madvise bug + fixed. + + * jit/ExecutableAllocatorFixedVMPool.cpp: + (JSC::FixedVMPoolExecutableAllocator::notifyPageIsFree): + +2013-01-15 Levi Weintraub <leviw@chromium.org> + + Unreviewed, rolling out r139790. + http://trac.webkit.org/changeset/139790 + https://bugs.webkit.org/show_bug.cgi?id=106948 + + The patch is failing its own test. + + * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo. + +2013-01-15 Zan Dobersek <zandobersek@gmail.com> + + [Autotools] Unify JavaScriptCore sources list, regardless of target OS + https://bugs.webkit.org/show_bug.cgi?id=106007 + + Reviewed by Gustavo Noronha Silva. + + Include the Source/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp target + in the general sources list as it is guarded by the ENABLE_EXECUTABLE_ALLOCATOR_FIXED + feature define. This define is only used on 64-bit architecture and indirectly depends + on enabling either JIT or YARR JIT feature. Both of these defines are disabled on + Windows OS when using 64-bit architecture so there's no need to add this target to + sources only when the target OS is Windows. + + * GNUmakefile.list.am: + +2013-01-11 Filip Pizlo <fpizlo@apple.com> + + DFG should not forget that it had proved something to be a constant during a merge just because it's merging against the empty value + https://bugs.webkit.org/show_bug.cgi?id=106727 + + Reviewed by Oliver Hunt. + + The problem was this statement: + + if (m_value != other.m_value) + m_value = JSValue(); + + This is well-intentioned, in the sense that if we want our abstract value (i.e. this) to become the superset of the other + abstract value, and the two abstract values have proven different constants, then our abstract value should rescind its + claim that it has been proven to be constant. But this misses the special case that if the other abstract value is + completely clear (meaning that it wishes to contribute zero information and so the superset operation shouldn't change + this), it will have a clear m_value. So, the code prior to this patch would rescind the constant proof even though it + didn't have to. + + This comes up rarely and I don't believe it will be a performance win, but it is good to have the CFA been consistently + precise as often as possible. + + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::merge): + +2013-01-11 Filip Pizlo <fpizlo@apple.com> + + Python implementation reports "MemoryError" instead of doing things + https://bugs.webkit.org/show_bug.cgi?id=106690 + + Reviewed by Oliver Hunt. + + The bug was that the CFA was assuming that a variable is dead at the end of a basic block and hence doesn't need to + be merged to the next block if the last mention of the variable was dead. This is almost correct, except that it + doesn't work if the last mention is a GetLocal - the GetLocal itself may be dead, but that doesn't mean that the + variable is dead - it may still be live. The appropriate thing to do is to look at the GetLocal's Phi. If the + variable is used in the next block then the next block will have a reference to the last mention in our block unless + that last mention is a GetLocal, in which case it will link to the Phi. Doing it this way captures everything that + the CFA wants: if the last use is a live GetLocal then the CFA needs to consider the GetLocal itself for possible + refinements to the proof of the value in the variable, but if the GetLocal is dead, then this must mean that the + variable is not mentioned in the block but may still be "passed through" it, which is what the Phi will tell us. + Note that it is not possible for the GetLocal to refer to anything other than a Phi, and it is also not possible + for the last mention of a variable to be a dead GetLocal while there are other mentions that aren't dead - if + there had been SetLocals or GetLocals prior to the dead one then the dead one wouldn't have been emitted by the + parser. + + This also fixes a similar bug in the handling of captured variables. If a variable is captured, then it doesn't + matter if the last mention is dead, or not. Either way, we already know that a captured variable will be live in + the next block, so we must merge it no matter what. + + Finally, this change makes the output of Operands dumping a bit more verbose: it now prints the variable name next + to each variable's dump. I've often found the lack of this information confusing particularly for operand dumps + that involve a lot of variables. + + * bytecode/Operands.h: + (JSC::dumpOperands): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::mergeStateAtTail): + +2013-01-14 Roger Fong <roger_fong@apple.com> + + Unreviewed. Fix vcproj file. Missing file tag after http://trac.webkit.org/changeset/139541. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + +2013-01-13 Filip Pizlo <fpizlo@apple.com> + + DFG phases that store per-node information should store it in Node itself rather than using a secondary vector + https://bugs.webkit.org/show_bug.cgi?id=106753 + + Reviewed by Geoffrey Garen. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::AbstractState): + (JSC::DFG::AbstractState::beginBasicBlock): + (JSC::DFG::AbstractState::dump): + * dfg/DFGAbstractState.h: + (JSC::DFG::AbstractState::forNode): + (AbstractState): + * dfg/DFGCFGSimplificationPhase.cpp: + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::CSEPhase): + (JSC::DFG::CSEPhase::performSubstitution): + (JSC::DFG::CSEPhase::setReplacement): + (CSEPhase): + * dfg/DFGNode.h: + (Node): + +2013-01-12 Tim Horton <timothy_horton@apple.com> + + Unreviewed build fix. + + * API/JSBlockAdaptor.mm: + * API/JSContext.mm: + * API/JSValue.mm: + +2013-01-12 Csaba Osztrogonác <ossy@webkit.org> + + Unreviewed 64 bit buildfix after r139496. + + * dfg/DFGOperations.cpp: + +2013-01-11 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, speculative build fix. + + * API/JSWrapperMap.mm: + +2013-01-10 Filip Pizlo <fpizlo@apple.com> + + JITThunks should not compile only because of luck + https://bugs.webkit.org/show_bug.cgi?id=105696 + + Rubber stamped by Sam Weinig and Geoffrey Garen. + + This patch was supposed to just move JITThunks into its own file. But then I + realized that there is a horrible circular dependency chain between JSCell, + JSGlobalData, CallFrame, and Weak, which only works because of magical include + order in JITStubs.h, and the fact that JSGlobalData.h includes JITStubs.h + before it includes JSCell or JSValue. + + I first tried to just get JITThunks.h to just magically do the same pointless + includes that JITStubs.h had, but then I decided to actually fix the underflying + problem, which was that JSCell needed CallFrame, CallFrame needed JSGlobalData, + JSGlobalData needed JITThunks, JITThunks needed Weak, and Weak needed JSCell. + Now, all of JSCell's outgoing dependencies are placed in JSCellInlines.h. This + also gave me an opportunity to move JSValue inline methods from JSCell.h into + JSValueInlines.h. But to make this really work, I needed to remove includes of + *Inlines.h from other headers (CodeBlock.h for example included JSValueInlines.h, + which defeats the whole entire purpose of having an Inlines.h file), and I needed + to add includes of *Inlines.h into a bunch of .cpp files. I did this mostly by + having .cpp files include Operations.h. In future, if you're adding a .cpp file + to JSC, you'll almost certainly have to include Operations.h unless you enjoy + link errors. + + * API/JSBase.cpp: + * API/JSCallbackConstructor.cpp: + * API/JSCallbackFunction.cpp: + * API/JSCallbackObject.cpp: + * API/JSClassRef.cpp: + * API/JSContextRef.cpp: + * API/JSObjectRef.cpp: + * API/JSScriptRef.cpp: + * API/JSWeakObjectMapRefPrivate.cpp: + * JSCTypedArrayStubs.h: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/ArrayAllocationProfile.cpp: + * bytecode/CodeBlock.cpp: + * bytecode/GetByIdStatus.cpp: + * bytecode/LazyOperandValueProfile.cpp: + * bytecode/ResolveGlobalStatus.cpp: + * bytecode/SpeculatedType.cpp: + * bytecode/UnlinkedCodeBlock.cpp: + * bytecompiler/BytecodeGenerator.cpp: + * debugger/Debugger.cpp: + * debugger/DebuggerActivation.cpp: + * debugger/DebuggerCallFrame.cpp: + * dfg/DFGArgumentsSimplificationPhase.cpp: + * dfg/DFGArrayMode.cpp: + * dfg/DFGByteCodeParser.cpp: + * dfg/DFGConstantFoldingPhase.cpp: + * dfg/DFGDriver.cpp: + * dfg/DFGFixupPhase.cpp: + * dfg/DFGGraph.cpp: + * dfg/DFGJITCompiler.cpp: + * dfg/DFGOSREntry.cpp: + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + * dfg/DFGOSRExitCompiler64.cpp: + * dfg/DFGPredictionPropagationPhase.cpp: + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR): + (DFG): + (JSC::DFG::SpeculativeJIT::silentSavePlanForFPR): + (JSC::DFG::SpeculativeJIT::silentSpill): + (JSC::DFG::SpeculativeJIT::silentFill): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + * dfg/DFGSpeculativeJIT64.cpp: + * dfg/DFGStructureCheckHoistingPhase.cpp: + * dfg/DFGVariableEventStream.cpp: + * heap/CopiedBlock.h: + * heap/CopiedSpace.cpp: + * heap/HandleSet.cpp: + * heap/Heap.cpp: + * heap/HeapStatistics.cpp: + * heap/SlotVisitor.cpp: + * heap/WeakBlock.cpp: + * interpreter/CallFrame.cpp: + * interpreter/CallFrame.h: + * jit/ClosureCallStubRoutine.cpp: + * jit/GCAwareJITStubRoutine.cpp: + * jit/JIT.cpp: + * jit/JITArithmetic.cpp: + * jit/JITArithmetic32_64.cpp: + * jit/JITCall.cpp: + * jit/JITCall32_64.cpp: + * jit/JITCode.h: + * jit/JITExceptions.cpp: + * jit/JITStubs.h: + * jit/JITThunks.h: + * jsc.cpp: + * llint/LLIntExceptions.cpp: + * profiler/LegacyProfiler.cpp: + * profiler/ProfileGenerator.cpp: + * profiler/ProfilerBytecode.cpp: + * profiler/ProfilerBytecodeSequence.cpp: + * profiler/ProfilerBytecodes.cpp: + * profiler/ProfilerCompilation.cpp: + * profiler/ProfilerCompiledBytecode.cpp: + * profiler/ProfilerDatabase.cpp: + * profiler/ProfilerOSRExit.cpp: + * profiler/ProfilerOSRExitSite.cpp: + * profiler/ProfilerOrigin.cpp: + * profiler/ProfilerOriginStack.cpp: + * profiler/ProfilerProfiledBytecodes.cpp: + * runtime/ArgList.cpp: + * runtime/Arguments.cpp: + * runtime/ArrayConstructor.cpp: + * runtime/BooleanConstructor.cpp: + * runtime/BooleanObject.cpp: + * runtime/BooleanPrototype.cpp: + * runtime/CallData.cpp: + * runtime/CodeCache.cpp: + * runtime/Completion.cpp: + * runtime/ConstructData.cpp: + * runtime/DateConstructor.cpp: + * runtime/DateInstance.cpp: + * runtime/DatePrototype.cpp: + * runtime/Error.cpp: + * runtime/ErrorConstructor.cpp: + * runtime/ErrorInstance.cpp: + * runtime/ErrorPrototype.cpp: + * runtime/ExceptionHelpers.cpp: + * runtime/Executable.cpp: + * runtime/FunctionConstructor.cpp: + * runtime/FunctionPrototype.cpp: + * runtime/GetterSetter.cpp: + * runtime/Identifier.cpp: + * runtime/InternalFunction.cpp: + * runtime/JSActivation.cpp: + * runtime/JSBoundFunction.cpp: + * runtime/JSCell.cpp: + * runtime/JSCell.h: + (JSC): + * runtime/JSCellInlines.h: Added. + (JSC): + (JSC::JSCell::JSCell): + (JSC::JSCell::finishCreation): + (JSC::JSCell::structure): + (JSC::JSCell::visitChildren): + (JSC::allocateCell): + (JSC::isZapped): + (JSC::JSCell::isObject): + (JSC::JSCell::isString): + (JSC::JSCell::isGetterSetter): + (JSC::JSCell::isProxy): + (JSC::JSCell::isAPIValueWrapper): + (JSC::JSCell::setStructure): + (JSC::JSCell::methodTable): + (JSC::JSCell::inherits): + (JSC::JSCell::fastGetOwnPropertySlot): + (JSC::JSCell::fastGetOwnProperty): + (JSC::JSCell::toBoolean): + * runtime/JSDateMath.cpp: + * runtime/JSFunction.cpp: + * runtime/JSFunction.h: + (JSC): + * runtime/JSGlobalData.h: + (JSC): + (JSGlobalData): + * runtime/JSGlobalObject.cpp: + * runtime/JSGlobalObjectFunctions.cpp: + * runtime/JSLock.cpp: + * runtime/JSNameScope.cpp: + * runtime/JSNotAnObject.cpp: + * runtime/JSONObject.cpp: + * runtime/JSObject.h: + (JSC): + * runtime/JSProxy.cpp: + * runtime/JSScope.cpp: + * runtime/JSSegmentedVariableObject.cpp: + * runtime/JSString.h: + (JSC): + * runtime/JSStringJoiner.cpp: + * runtime/JSSymbolTableObject.cpp: + * runtime/JSValue.cpp: + * runtime/JSValueInlines.h: + (JSC::JSValue::toInt32): + (JSC::JSValue::toUInt32): + (JSC): + (JSC::JSValue::isUInt32): + (JSC::JSValue::asUInt32): + (JSC::JSValue::asNumber): + (JSC::jsNaN): + (JSC::JSValue::JSValue): + (JSC::JSValue::encode): + (JSC::JSValue::decode): + (JSC::JSValue::operator bool): + (JSC::JSValue::operator==): + (JSC::JSValue::operator!=): + (JSC::JSValue::isEmpty): + (JSC::JSValue::isUndefined): + (JSC::JSValue::isNull): + (JSC::JSValue::isUndefinedOrNull): + (JSC::JSValue::isCell): + (JSC::JSValue::isInt32): + (JSC::JSValue::isDouble): + (JSC::JSValue::isTrue): + (JSC::JSValue::isFalse): + (JSC::JSValue::tag): + (JSC::JSValue::payload): + (JSC::JSValue::asInt32): + (JSC::JSValue::asDouble): + (JSC::JSValue::asCell): + (JSC::JSValue::isNumber): + (JSC::JSValue::isBoolean): + (JSC::JSValue::asBoolean): + (JSC::reinterpretDoubleToInt64): + (JSC::reinterpretInt64ToDouble): + (JSC::JSValue::isString): + (JSC::JSValue::isPrimitive): + (JSC::JSValue::isGetterSetter): + (JSC::JSValue::isObject): + (JSC::JSValue::getString): + (JSC::::getString): + (JSC::JSValue::getObject): + (JSC::JSValue::getUInt32): + (JSC::JSValue::toPrimitive): + (JSC::JSValue::getPrimitiveNumber): + (JSC::JSValue::toNumber): + (JSC::JSValue::toObject): + (JSC::JSValue::isFunction): + (JSC::JSValue::inherits): + (JSC::JSValue::toThisObject): + (JSC::JSValue::get): + (JSC::JSValue::put): + (JSC::JSValue::putByIndex): + (JSC::JSValue::structureOrUndefined): + (JSC::JSValue::equal): + (JSC::JSValue::equalSlowCaseInline): + (JSC::JSValue::strictEqualSlowCaseInline): + (JSC::JSValue::strictEqual): + * runtime/JSVariableObject.cpp: + * runtime/JSWithScope.cpp: + * runtime/JSWrapperObject.cpp: + * runtime/LiteralParser.cpp: + * runtime/Lookup.cpp: + * runtime/NameConstructor.cpp: + * runtime/NameInstance.cpp: + * runtime/NamePrototype.cpp: + * runtime/NativeErrorConstructor.cpp: + * runtime/NativeErrorPrototype.cpp: + * runtime/NumberConstructor.cpp: + * runtime/NumberObject.cpp: + * runtime/ObjectConstructor.cpp: + * runtime/ObjectPrototype.cpp: + * runtime/Operations.h: + (JSC): + * runtime/PropertySlot.cpp: + * runtime/RegExp.cpp: + * runtime/RegExpCache.cpp: + * runtime/RegExpCachedResult.cpp: + * runtime/RegExpConstructor.cpp: + * runtime/RegExpMatchesArray.cpp: + * runtime/RegExpObject.cpp: + * runtime/RegExpPrototype.cpp: + * runtime/SmallStrings.cpp: + * runtime/SparseArrayValueMap.cpp: + * runtime/StrictEvalActivation.cpp: + * runtime/StringConstructor.cpp: + * runtime/StringObject.cpp: + * runtime/StringRecursionChecker.cpp: + * runtime/Structure.h: + (JSC): + * runtime/StructureChain.cpp: + * runtime/TimeoutChecker.cpp: + * testRegExp.cpp: + +2013-01-11 Filip Pizlo <fpizlo@apple.com> + + If you use Phantom to force something to be live across an OSR exit, you should put it after the OSR exit + https://bugs.webkit.org/show_bug.cgi?id=106724 + + Reviewed by Oliver Hunt. + + In cases where we were getting it wrong, I think it was benign because we would either already have an + OSR exit prior to there, or the operand would be a constant. But still, it's good to get this right. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + +2013-01-11 Filip Pizlo <fpizlo@apple.com> + + Phantom(GetLocal) should be treated as relevant to OSR + https://bugs.webkit.org/show_bug.cgi?id=106715 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::performBlockCSE): + +2013-01-11 Pratik Solanki <psolanki@apple.com> + + Fix function name typo ProgramExecutable::initalizeGlobalProperties() + https://bugs.webkit.org/show_bug.cgi?id=106701 + + Reviewed by Geoffrey Garen. + + * interpreter/Interpreter.cpp: + (JSC::Interpreter::execute): + * runtime/Executable.cpp: + (JSC::ProgramExecutable::initializeGlobalProperties): + * runtime/Executable.h: + +2013-01-11 Mark Hahnenberg <mhahnenberg@apple.com> + + testapi is failing with a block-related error in the Objc API + https://bugs.webkit.org/show_bug.cgi?id=106055 + + Reviewed by Filip Pizlo. + + Same bug as in testapi.mm. We need to actually call the static block, rather than casting the block to a bool. + + * API/ObjCCallbackFunction.mm: + (blockSignatureContainsClass): + +2013-01-11 Filip Pizlo <fpizlo@apple.com> + + Add a run-time option to print bytecode at DFG compile time + https://bugs.webkit.org/show_bug.cgi?id=106704 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseCodeBlock): + * runtime/Options.h: + (JSC): + +2013-01-11 Filip Pizlo <fpizlo@apple.com> + + It should be possible to enable verbose printing of each OSR exit at run-time (rather than compile-time) and it should print register state + https://bugs.webkit.org/show_bug.cgi?id=106700 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGAssemblyHelpers.h: + (DFG): + (JSC::DFG::AssemblyHelpers::debugCall): + * dfg/DFGCommon.h: + * dfg/DFGOSRExit.h: + (DFG): + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * runtime/Options.h: + (JSC): + +2013-01-11 Geoffrey Garen <ggaren@apple.com> + + Removed getDirectLocation and offsetForLocation and all their uses + https://bugs.webkit.org/show_bug.cgi?id=106692 + + Reviewed by Filip Pizlo. + + getDirectLocation() and its associated offsetForLocation() relied on + detailed knowledge of the rules of PropertyOffset, JSObject, and + Structure, which is a hard thing to reverse-engineer reliably. Luckily, + it wasn't needed, and all clients either wanted a true value or a + PropertyOffset. So, I refactored accordingly. + + * dfg/DFGOperations.cpp: Renamed putDirectOffset to putDirect, to clarify + that we are not putting an offset. + + * runtime/JSActivation.cpp: + (JSC::JSActivation::getOwnPropertySlot): Get a value instead of a value + pointer, since we never wanted a pointer to begin with. + + * runtime/JSFunction.cpp: + (JSC::JSFunction::getOwnPropertySlot): Use a PropertyOffset instead of a pointer, + so we don't have to reverse-engineer the offset from the pointer. + + * runtime/JSObject.cpp: + (JSC::JSObject::put): + (JSC::JSObject::resetInheritorID): + (JSC::JSObject::inheritorID): + (JSC::JSObject::removeDirect): + (JSC::JSObject::fillGetterPropertySlot): + (JSC::JSObject::getOwnPropertyDescriptor): Renamed getDirectOffset and + putDirectOffset, as explaind above. We want to use the name "getDirectOffset" + for when the thing you're getting is the offset. + + * runtime/JSObject.h: + (JSC::JSObject::getDirect): + (JSC::JSObject::getDirectOffset): Changed getDirectLocation to getDirectOffset, + since clients really wants PropertyOffsets and not locations. + + (JSObject::offsetForLocation): Removed this function because it was hard + to get right. + + (JSC::JSObject::putDirect): + (JSC::JSObject::putDirectUndefined): + (JSC::JSObject::inlineGetOwnPropertySlot): + (JSC::JSObject::putDirectInternal): + (JSC::JSObject::putDirectWithoutTransition): + * runtime/JSScope.cpp: + (JSC::executeResolveOperations): + (JSC::JSScope::resolvePut): + * runtime/JSValue.cpp: + (JSC::JSValue::putToPrimitive): Updated for renames. + + * runtime/Lookup.cpp: + (JSC::setUpStaticFunctionSlot): Use a PropertyOffset instead of a pointer, + so we don't have to reverse-engineer the offset from the pointer. + + * runtime/Structure.cpp: + (JSC::Structure::flattenDictionaryStructure): Updated for renames. + +2013-01-11 Geoffrey Garen <ggaren@apple.com> + + Removed an unused version of getDirectLocation + https://bugs.webkit.org/show_bug.cgi?id=106691 + + Reviewed by Gavin Barraclough. + + getDirectLocation is a weird operation. Removing the unused version is + the easy part. + + * runtime/JSObject.h: + (JSObject): + +2013-01-11 Mark Hahnenberg <mhahnenberg@apple.com> + + Objective-C objects that are passed to JavaScript leak (until the JSContext is destroyed) + https://bugs.webkit.org/show_bug.cgi?id=106056 + + Reviewed by Darin Adler. + + * API/APIJSValue.h: + * API/JSValue.mm: Make the reference to the JSContext strong. + (-[JSValue context]): + (-[JSValue initWithValue:inContext:]): + (-[JSValue dealloc]): + * API/JSWrapperMap.mm: Make the reference back from wrappers to Obj-C objects weak instead of strong. + Also add an explicit WeakGCMap in the JSWrapperMap rather than using Obj-C associated object API which + was causing memory leaks. + (wrapperClass): + (-[JSObjCClassInfo wrapperForObject:]): + (-[JSWrapperMap initWithContext:]): + (-[JSWrapperMap dealloc]): + (-[JSWrapperMap wrapperForObject:]): + +2013-01-11 Geoffrey Garen <ggaren@apple.com> + + Fixed some bogus PropertyOffset ASSERTs + https://bugs.webkit.org/show_bug.cgi?id=106686 + + Reviewed by Gavin Barraclough. + + The ASSERTs were passing a JSType instead of an inlineCapacity, due to + an incomplete refactoring. + + The compiler didn't catch this because both types are int underneath. + + * runtime/JSObject.h: + (JSC::JSObject::getDirect): + (JSC::JSObject::getDirectLocation): + (JSC::JSObject::offsetForLocation): + * runtime/Structure.cpp: + (JSC::Structure::addPropertyTransitionToExistingStructure): Validate against + our inline capacity, as we intended. + +2013-01-11 Geoffrey Garen <ggaren@apple.com> + + Rename propertyOffsetFor => offsetForPropertyNumber + https://bugs.webkit.org/show_bug.cgi?id=106685 + + Reviewed by Gavin Barraclough. + + Since the argument is just a typedef and not an object, I wanted to clarify the meaning. + + * runtime/PropertyMapHashTable.h: + (JSC::PropertyTable::nextOffset): Updated for rename. + + * runtime/PropertyOffset.h: + (JSC::offsetForPropertyNumber): Renamed. Also changed some PropertyOffset variables + to plain ints, because they're not actually on the PropertyOffsets number line. + + * runtime/Structure.cpp: + (JSC::Structure::flattenDictionaryStructure): + * runtime/Structure.h: + (JSC::Structure::lastValidOffset): Updated for rename. + +2013-01-10 Zan Dobersek <zandobersek@gmail.com> + + Remove the ENABLE_ANIMATION_API feature define occurences + https://bugs.webkit.org/show_bug.cgi?id=106544 + + Reviewed by Simon Fraser. + + The Animation API code was removed in r137243. The ENABLE_ANIMATION_API + feature define handling still lingers in various build systems and configurations + but is of no use, so it should be removed. + + * Configurations/FeatureDefines.xcconfig: + +2013-01-09 Roger Fong <roger_fong@apple.com> + + Unreviewed. Just move the JavaScriptCore exports file around in the vcproj to make things clearer. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + +2013-01-09 Filip Pizlo <fpizlo@apple.com> + + Dont use a node reference after appending to the graph. + https://bugs.webkit.org/show_bug.cgi?id=103305 + <rdar://problem/12753096> + + Reviewed by Mark Hahnenberg. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + +2013-01-09 Roger Fong <roger_fong@apple.com> + + Rename export files to make them more easily findable. + https://bugs.webkit.org/show_bug.cgi?id=98695. + + Reviewed by Timothy Horton. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Removed. + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreCommon.vsprops: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Copied from Source/JavaScriptCore/JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def. + +2013-01-09 Carlos Garcia Campos <cgarcia@igalia.com> + + Unreviewed. Fix make distcheck. + + * GNUmakefile.list.am: Add mips.rb to offlineasm_nosources. + +2013-01-08 Oliver Hunt <oliver@apple.com> + + Support op_typeof in the DFG + https://bugs.webkit.org/show_bug.cgi?id=98898 + + Reviewed by Filip Pizlo. + + Adds a TypeOf node to the DFG to support op_typeof. + + To avoid adding too much GC horror, this also makes the + common strings portion of the SmallString cache strongly + referenced. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + We try to determine the result early here, and substitute in a constant. + Otherwise we leave the node intact, and set the result type to SpecString. + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + Parse op_typeof + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::performNodeCSE): + TypeOf nodes can be subjected to pure CSE + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + We can handle typeof. + * dfg/DFGNodeType.h: + (DFG): + Define the node. + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + Add operationTypeOf to support the non-trivial cases. + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + Actual codegen + * runtime/Operations.cpp: + (JSC::jsTypeStringForValue): + (JSC): + * runtime/Operations.h: + (JSC): + Some refactoring to allow us to get the type string for an + object without needing a callframe. + + +2013-01-08 Filip Pizlo <fpizlo@apple.com> + + DFG shouldn't treat the 'this' argument as being captured if a code block uses arguments + https://bugs.webkit.org/show_bug.cgi?id=106398 + <rdar://problem/12439776> + + Reviewed by Mark Hahnenberg. + + This is a possible optimization for inlined calls, and fixes crashes for inlined constructors, in the case + that the inlined code used arguments. The problem was that assuming that 'this' was captured implies the + assumption that it was initialized by the caller, which is wrong for constructors and this. + + Also added a pretty essential DFG IR validation rule: we shouldn't have any live locals at the top of the + root block. This helps to catch this bug: our assumption that 'this' was captured in an inlined constructor + that used arguments led to liveness for the temporary that would have held 'this' in the caller being + propagated all the way up to the entrypoint of the function. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::isCaptured): + * dfg/DFGValidate.cpp: + (JSC::DFG::Validate::validate): + (JSC::DFG::Validate::reportValidationContext): + (Validate): + (JSC::DFG::Validate::dumpGraphIfAppropriate): + +2013-01-08 Filip Pizlo <fpizlo@apple.com> + + REGRESSION (r138921): Crash in JSC::Arguments::create + https://bugs.webkit.org/show_bug.cgi?id=106329 + <rdar://problem/12974196> + + Reviewed by Mark Hahnenberg. + + Arguments::finishCreation() that takes an InlineCallFrame* needs to understand that the callee can + be unset, indicating that the callee needs to be loaded from the true call frame. This adds a + method to InlineCallFrame to do just that. + + * bytecode/CodeOrigin.cpp: + (JSC::InlineCallFrame::calleeForCallFrame): + * bytecode/CodeOrigin.h: + (InlineCallFrame): + * runtime/Arguments.h: + (JSC::Arguments::finishCreation): + +2013-01-08 Filip Pizlo <fpizlo@apple.com> + + DFG initrinsic handling should ensure that we backwards propagate the fact that all operands may escape + https://bugs.webkit.org/show_bug.cgi?id=106365 + + Reviewed by Mark Hahnenberg. + + Use the fact that Phantom means that things escaped, and just insert Phantoms for all + of the operands. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleCall): + +2013-01-08 Filip Pizlo <fpizlo@apple.com> + + If array allocation profiling causes a new_array to allocate double arrays, then the holes should end up being correctly initialized + https://bugs.webkit.org/show_bug.cgi?id=106363 + + Reviewed by Mark Hahnenberg. + + * runtime/JSArray.h: + (JSC::JSArray::tryCreateUninitialized): + +2013-01-07 Filip Pizlo <fpizlo@apple.com> + + DFG should backwards-propagate NodeUsedAsValue for Phantom + https://bugs.webkit.org/show_bug.cgi?id=106299 + + Reviewed by Mark Hahnenberg. + + This is currently benign because Phantom is only inserted by the bytecode parser for + things that already happen to be used in contexts that backwards propagate + NodeUsedAsValue. But that doesn't change the fact that the semantics of Phantom are + that the value can be arbitrarily used by the baseline JIT. + + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + +2013-01-07 Filip Pizlo <fpizlo@apple.com> + + Rationalize closure call heuristics and profiling + https://bugs.webkit.org/show_bug.cgi?id=106270 + + Reviewed by Oliver Hunt. + + Did a number of things: + + - CallLinkInfo now remembers if it was ever a closure call, and CallLinkStatus uses + this. Reduces the likelihood that we will inline a closure call as if it was a + normal call. + + - Made InlineCallFrame print inferred function names, and refactored + CodeBlock::inferredName() to better use FunctionExecutable's API. + + - Made bytecode dumping print frequent exit sites that led to recompilation. + + - Made bytecode dumping for op_call and op_construct print what the CallLinkStatus + saw. + + * bytecode/CallLinkInfo.h: + (JSC::CallLinkInfo::CallLinkInfo): + (CallLinkInfo): + * bytecode/CallLinkStatus.cpp: + (JSC::CallLinkStatus::computeFor): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::inferredName): + (JSC::CodeBlock::dumpBytecodeCommentAndNewLine): + (JSC::CodeBlock::printCallOp): + * bytecode/CodeOrigin.cpp: + (JSC::CodeOrigin::dump): + (JSC::InlineCallFrame::inferredName): + (JSC): + (JSC::InlineCallFrame::dumpBriefFunctionInformation): + (JSC::InlineCallFrame::dump): + * bytecode/CodeOrigin.h: + (InlineCallFrame): + * bytecode/DFGExitProfile.cpp: + (JSC::DFG::ExitProfile::exitSitesFor): + (DFG): + * bytecode/DFGExitProfile.h: + (ExitProfile): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + +2013-01-07 Ryosuke Niwa <rniwa@webkit.org> + + Sorted the xcodeproj file. + + * JavaScriptCore.xcodeproj/project.pbxproj: + +2013-01-07 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, it should be possible to build JSC on ARM. + + * API/JSBase.h: + * jit/JITStubs.cpp: + (JSC::performPlatformSpecificJITAssertions): + (JSC): + * jit/JITStubs.h: + (JSC): + * jit/JITThunks.cpp: + (JSC::JITThunks::JITThunks): + * jit/JITThunks.h: + (JITThunks): + * offlineasm/armv7.rb: + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + +2013-01-07 Balazs Kilvady <kilvadyb@homejinni.com> + + MIPS LLInt implementation. + https://bugs.webkit.org/show_bug.cgi?id=99706 + + Reviewed by Filip Pizlo. + + LLInt implementation for MIPS. + + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::jump): + * dfg/DFGOperations.cpp: + (JSC): + * jit/JITStubs.cpp: + (JSC): + * jit/JITStubs.h: + (JITStackFrame): + * llint/LLIntOfflineAsmConfig.h: + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * offlineasm/backends.rb: + * offlineasm/instructions.rb: + * offlineasm/mips.rb: Added. + +2013-01-07 Mark Hahnenberg <mhahnenberg@apple.com> + + testapi is failing with a block-related error in the Objc API + https://bugs.webkit.org/show_bug.cgi?id=106055 + + Reviewed by Geoffrey Garen. + + Casting a block to a bool will always return true, which isn't the behavior that is intended here. + Instead we need to call the block, but C semantics don't allow this, so we need to change + testapi.m to be Objective-C++ and therefore testapi.mm. + + * API/tests/testapi.m: Removed. + * API/tests/testapi.mm: Copied from Source/JavaScriptCore/API/tests/testapi.m. + (blockSignatureContainsClass): + * JavaScriptCore.xcodeproj/project.pbxproj: + +2013-01-06 Filip Pizlo <fpizlo@apple.com> + + Simplify slow case profiling + https://bugs.webkit.org/show_bug.cgi?id=106208 + + Reviewed by Mark Rowe. + + Removing the minimum execution ratio portion of slow case profiling, which allows + the removal of a field from CodeBlock. This appears to be performance neutral, + implying that the complexity incurred by the previous heuristic was purely + harmful: it made the code more complicated, and it made CodeBlock larger, without + resulting in any measurable benefits. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::likelyToTakeSlowCase): + (JSC::CodeBlock::couldTakeSlowCase): + (JSC::CodeBlock::likelyToTakeSpecialFastCase): + (JSC::CodeBlock::couldTakeSpecialFastCase): + (JSC::CodeBlock::likelyToTakeDeepestSlowCase): + (JSC::CodeBlock::likelyToTakeAnySlowCase): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + * runtime/Options.h: + +2013-01-05 Filip Pizlo <fpizlo@apple.com> + + DFG should inline closure calls + https://bugs.webkit.org/show_bug.cgi?id=106067 + + Reviewed by Gavin Barraclough. + + This adds initial support for inlining closure calls to the DFG. A call is considered + to be a closure call when the JSFunction* varies, but always has the same executable. + We already have closure call inline caching in both JITs, which works by checking that + the callee has an expected structure (as a cheap way of detecting that it is in fact + a JSFunction) and an expected executable. Closure call inlining uses profiling data + aggregated by CallLinkStatus to decide when to specialize the call to the particular + structure/executable, and inline the call rather than emitting a call sequence. When + we choose to do a closure inline rather than an ordinary inline, a number of things + change about how inlining is performed: + + - The inline is guarded by a CheckStructure/CheckExecutable rather than a + CheckFunction. + + - Instead of propagating a constant value for the scope, we emit GetMyScope every time + that the scope is needed, which loads the scope from a local variable. We do similar + things for the callee. + + - The prologue of the inlined code includes SetMyScope and SetCallee nodes to eagerly + plant the scope and callee into the "true call frame", i.e. the place on the stack + where the call frame would have been if the call had been actually performed. This + allows GetMyScope/GetCallee to work as they would if the code wasn't inlined. It + also allows for trivial handling of scope and callee for call frame reconstruction + upon stack introspection and during OSR. + + - A new node called GetScope is introduced, which just gets the scope of a function. + This node has the expected CSE support. This allows for the + SetMyScope(GetScope(@function)) sequence to set up the scope in the true call frame. + + - GetMyScope/GetCallee CSE can match against SetMyScope/SetCallee, which means that + the GetMyScope/GetCallee nodes emitted during parsing are often removed during CSE, + if we can prove that it is safe to do so. + + - Inlining heuristics are adjusted to grok the cost of inlining a closure. We are + less likely to inline a closure call than we are to inline a normal call, since we + end up emitting more code for closures due to CheckStructure, CheckExecutable, + GetScope, SetMyScope, and SetCallee. + + Additionally, I've fixed the VariableEventStream to ensure that we don't attempt to + plant Undefined into the true call frames. This was previously a harmless oversight, + but it becomes quite bad if OSR is relying on the scope/callee already having been + set and not subsequently clobbered by the OSR itself. + + This is a ~60% speed-up on programs that frequently make calls to closures. It's + neutral on V8v7 and other major benchmark suites. + + The lack of a definite speed-up is likely due the fact that closure inlining currently + does not do any cardinality [1] optimizations. We don't observe when a closure was + constructed within its caller, and so used the scope from its caller; and furthermore + we have no facility to detect when the scope is single. All scoped variable accesses + are assumed to be multiple instead. A subsequent step will be to ensure that closure + call inlining will be single and loving it. + + [1] Single and loving it: Must-alias analysis for higher-order languages. Suresh + Jagannathan, Peter Thiemann, Stephen Weeks, and Andrew Wright. In POPL '98. + + * bytecode/CallLinkStatus.cpp: + (JSC::CallLinkStatus::dump): + * bytecode/CallLinkStatus.h: + (JSC::CallLinkStatus::isClosureCall): + (CallLinkStatus): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::globalObjectFor): + (JSC): + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecode/CodeOrigin.cpp: + (JSC::InlineCallFrame::dump): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::handleCall): + (JSC::DFG::ByteCodeParser::emitFunctionChecks): + (JSC::DFG::ByteCodeParser::handleInlining): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::pureCSE): + (CSEPhase): + (JSC::DFG::CSEPhase::getCalleeLoadElimination): + (JSC::DFG::CSEPhase::checkExecutableElimination): + (JSC::DFG::CSEPhase::getMyScopeLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCapabilities.cpp: + (JSC::DFG::mightInlineFunctionForClosureCall): + * dfg/DFGCapabilities.h: + (DFG): + (JSC::DFG::mightInlineFunctionForClosureCall): + (JSC::DFG::canInlineFunctionForClosureCall): + (JSC::DFG::canInlineFunctionFor): + * dfg/DFGNode.h: + (Node): + (JSC::DFG::Node::hasExecutable): + (JSC::DFG::Node::executable): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGVariableEventStream.cpp: + (JSC::DFG::VariableEventStream::reconstruct): + * runtime/Options.h: + (JSC): + +2013-01-05 Filip Pizlo <fpizlo@apple.com> + + Data flow paths that carry non-numbers, non-undefined, non-null values should not cause subtractions and arithmetic additions (i.e. ++) to speculate double + https://bugs.webkit.org/show_bug.cgi?id=106190 + + Reviewed by Sam Weinig. + + The problem is that the DFG logic for deciding when to speculate integer was + confusing the special case of ValueAdd (where non-numeric values should cause us + to not speculate integer, because we want to fall off into the generic case) with + the more normal case of ArithAdd and ArithSub (where we want to speculate integer + unless we have evidence that the operands are doubles, since the DFG doesn't have + generic handling of non-numeric arithmetic). Prior to this change doing a - b where + either a or b were possibly non-numeric would always force the subtraction to be + done using doubles. + + * dfg/DFGGraph.h: + (JSC::DFG::Graph::addSpeculationMode): + (Graph): + (JSC::DFG::Graph::valueAddSpeculationMode): + (JSC::DFG::Graph::arithAddSpeculationMode): + (JSC::DFG::Graph::addImmediateShouldSpeculateInteger): + +2013-01-04 Filip Pizlo <fpizlo@apple.com> + + DFG should trust array profiling over value profiling + https://bugs.webkit.org/show_bug.cgi?id=106155 + + Reviewed by Gavin Barraclough. + + The real problem is that prediction propagation is not flow-sensitive. We had code + like: + + var a = (some load from memory); // returns either an array or false + if (a) + a[i] = v; + + Because 'a' could be 'false', we were emitting a fully generic unoptimized PutByVal. + This patch changes ArrayMode to ignore the type of the base of an array access, if + array profiling tells us that the array access can be optimized. + + In the future, we could probably make this work even better with some flow + sensitivity in the prediction propagator, but I also tend to think that this is a + more robust overall solution. If we ever did want to support array accesses on + array-or-false then we should change the array profiler to be able to tell us that + this is what is going on. + + 3.7% speed-up on V8/earley. + + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::refine): + +2013-01-04 Filip Pizlo <fpizlo@apple.com> + + Rationalize exit site profiling for calls + https://bugs.webkit.org/show_bug.cgi?id=106150 + + Reviewed by Sam Weinig. + + This adds two new exit kinds for calls: BadFunction and BadExecutable. The latter is not used + yet, but is already integrated with profiling. CheckFunction uses a BadFunction speculation + instead of BadCache, now. This allows CallLinkStatus to turn itself into a closure call status + if we had a BadFunction exit site but the CallLinkInfo told us to use a non-closure call. This + might happen if we had call unlinking that led to information loss along the way. + + No performance impact. This is meant as another step towards inlining closure calls. + + * bytecode/CallLinkStatus.cpp: + * bytecode/CallLinkStatus.h: + (JSC::CallLinkStatus::setIsProved): + (JSC::CallLinkStatus::setHasBadFunctionExitSite): + (CallLinkStatus): + (JSC::CallLinkStatus::setHasBadCacheExitSite): + (JSC::CallLinkStatus::setHasBadExecutableExitSite): + * bytecode/ExitKind.cpp: + (JSC::exitKindToString): + * bytecode/ExitKind.h: + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleCall): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2013-01-03 Filip Pizlo <fpizlo@apple.com> + + DFG should not elide CheckStructure if it's needed to perform a cell check + https://bugs.webkit.org/show_bug.cgi?id=106074 + + Reviewed by Ryosuke Niwa. + + The problem here was that the constant folding phase was misinterpreting the meaning of the sets + in DFG::AbstractValue. AbstractValue describes a constraint on the values that a variable (i.e. + a DFG Node, or a virtual register, i.e. local or argument) may have. It does so by containing + four sets: the set of JSValues (either empty, the singleton set containing one JSValue, or the + set of all JSValues); the set of "current known" structures, i.e. the set of structures that you + already know that this value may have right now (also either empty, the singleton set, or the set + of all structures); the set of "future possible" structures, i.e. the set of structures that this + value could have in the future if none of the structure transition watchpoints for those + structures had fired (also empty, singleton, or all); and the set of types, which is a + SpeculatedType bitmask. The correct way to interpret the sets is to think of the AbstractValue as + the intersection of these three sets of values: + + - The set of JSValues that have a type that belongs to the m_type set. + - If m_value is not the empty value then: the set of all JSValues that are == m_value; + else: the set of all JSValues. + where '==' is as defined by JSValue::operator==. + - Union of { the set of all cells that have a structure that belongs to m_currentKnownStructure } + and { the set of all JSValues that are not cells }. + + You can then further intersect this set with the following set, if you guard the code with + watchpoints on all structures in the m_futurePossibleStructure: + + - Union of { the set of all cells that have a structure that belongs to m_futurePossibleStructure } + and { the set of all JSValues that are not cells }. + + One way to think of this is that m_currentKnownStructure is filtered by m_futurePossibleStructure + (i.e. is set to the intersection of m_currentKnownStructure and m_futurePossibleStructure), if the + code for which you're doing this is always preceded by watchpoints on all structures in + m_futurePossibleStructure, and is always before any side-effects that could change the structures + of objects. + + The incorrect optimization related to CheckStructure. CheckStructure checks that the value is a + cell, and that it has a particular structure. It was incorrectly assuming that you could eliminate + the CheckStructure, if m_currentKnownStructure contained the structure that CheckStructure was + checking. But this is not the case, since m_currentKnownStructure does not prove that the value is + a cell with a particular structure; it only proves that if the value was a cell then it would have + a particular structure. Hence, to eliminate CheckStructure, it is also necessary to check that + AbstractValue::m_type contains only cells (i.e. isCellSpeculation(m_type) == true). + + It wasn't doing that, and this changes makes sure that it does do that. + + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + +2013-01-04 Adam Klein <adamk@chromium.org> + + Remove ENABLE_MUTATION_OBSERVERS #define + https://bugs.webkit.org/show_bug.cgi?id=105459 + + Reviewed by Ryosuke Niwa. + + * Configurations/FeatureDefines.xcconfig: + +2013-01-03 Filip Pizlo <fpizlo@apple.com> + + DFG::ByteCodeCache serves little or no purpose ever since we decided to keep bytecode around permanently + https://bugs.webkit.org/show_bug.cgi?id=106058 + + Reviewed by Michael Saboff. + + All baseline code blocks now always have bytecode, so the bytecode cache's ability to minimize the + number of times that the DFG produces bytecode sequences for code blocks is superfluous. + + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGByteCodeCache.h: Removed. + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::handleInlining): + * runtime/Executable.cpp: + (JSC): + * runtime/Executable.h: + (FunctionExecutable): + +2013-01-03 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, fix build for DFG JIT disabled. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpValueProfiling): + (JSC::CodeBlock::dumpArrayProfiling): + * runtime/Executable.cpp: + (JSC): + (JSC::ExecutableBase::intrinsic): + +2013-01-03 Filip Pizlo <fpizlo@apple.com> + + CallLinkStatus should be aware of closure calls, and the DFG bytecode parser should use that as its sole internal notion of how to optimize calls + https://bugs.webkit.org/show_bug.cgi?id=106027 + + Reviewed by Mark Hahnenberg. + + Previously, the DFG bytecode parser had its own internal notion of exactly what CallLinkStatus was + meant to do, in the form of a CallType, expectedFunction, intrinsic, etc. This change makes CallLinkStatus + smart enough to do all of that, and also gives it the ability to understand closure calls. + + * bytecode/CallLinkStatus.cpp: + (JSC::CallLinkStatus::CallLinkStatus): + (JSC): + (JSC::CallLinkStatus::function): + (JSC::CallLinkStatus::internalFunction): + (JSC::CallLinkStatus::intrinsicFor): + (JSC::CallLinkStatus::setIsProved): + (JSC::CallLinkStatus::computeFromLLInt): + (JSC::CallLinkStatus::computeFor): + (JSC::CallLinkStatus::dump): + * bytecode/CallLinkStatus.h: + (JSC): + (JSC::CallLinkStatus::CallLinkStatus): + (CallLinkStatus): + (JSC::CallLinkStatus::takesSlowPath): + (JSC::CallLinkStatus::isSet): + (JSC::CallLinkStatus::isClosureCall): + (JSC::CallLinkStatus::callTarget): + (JSC::CallLinkStatus::executable): + (JSC::CallLinkStatus::structure): + (JSC::CallLinkStatus::isProved): + (JSC::CallLinkStatus::canOptimize): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleCall): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::valueOfFunctionConstant): + +2013-01-02 Simon Hausmann <simon.hausmann@digia.com> + + [MinGW-w64] Centralize workaround for pow() implementation + https://bugs.webkit.org/show_bug.cgi?id=105925 + + Reviewed by Sam Weinig. + + As suggested by Sam, move the MinGW-w64 workaround into MathExtras.h + away from the JSC usage. + + * runtime/MathObject.cpp: + (JSC::mathPow): + +2013-01-02 Gavin Barraclough <barraclough@apple.com> + + Objective-C API for JavaScriptCore + https://bugs.webkit.org/show_bug.cgi?id=105889 + + Reviewed by Geoff Garen. + + Fixes for more issues raised by Darin. + + * API/JSBlockAdaptor.mm: + (BlockArgument): + (BlockArgumentStruct::BlockArgumentStruct): + (BlockArgumentTypeDelegate::typeStruct): + (BlockResult): + (BlockResultStruct::BlockResultStruct): + (buildBlockSignature): + (-[JSBlockAdaptor initWithBlockSignatureFromProtocol:]): + (-[JSBlockAdaptor blockFromValue:inContext:withException:]): + - fix * position for Objective-C types + * API/JSContext.h: + - fix * position for Objective-C types + * API/JSContext.mm: + (-[JSContext initWithVirtualMachine:]): + (-[JSContext virtualMachine]): + (contextInternalContext): + - fix * position for Objective-C types + (-[JSContext dealloc]): + (-[JSContext protect:]): + (-[JSContext unprotect:]): + - HashMap<JSValueRef, size_t> -> HashCountedSet<JSValueRef> + * API/JSContextInternal.h: + (WeakContextRef): + - fix * position for Objective-C types + * API/JSValue.mm: + (valueToString): + - fix * position for Objective-C types + (isNSBoolean): + - Added helper to check for booleans. + (objectToValueWithoutCopy): + - Added contextRef + - fix * position for Objective-C types + - Remove @YES, @NO literal usage, use isNSBoolean instead + (objectToValue): + - Added contextRef + (+[JSValue valueWithValue:inContext:]): + (-[JSValue initWithValue:inContext:]): + - fix * position for Objective-C types + (createStructHandlerMap): + (handerForStructTag): + - getStructTagHandler -> handerForStructTag + - Split out createStructHandlerMap + - strncmp -> memcmp + - String(type).impl() -> StringImpl::create(type) + (+[JSValue selectorForStructToValue:]): + (+[JSValue selectorForValueToStruct:]): + - getStructTagHandler -> handerForStructTag + (typeToValueInvocationFor): + (valueToTypeInvocationFor): + - fix * position for Objective-C types + * API/JSValueInternal.h: + - fix * position for Objective-C types + * API/JSVirtualMachineInternal.h: + - fix * position for Objective-C types + * API/JSWrapperMap.h: + - fix * position for Objective-C types + * API/JSWrapperMap.mm: + (selectorToPropertyName): + (createObjectWithCustomBrand): + (createRenameMap): + (putNonEnumerable): + (copyMethodsToObject): + (copyPrototypeProperties): + (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): + (-[JSWrapperMap initWithContext:]): + (-[JSWrapperMap wrapperForObject:]): + (getJSExportProtocol): + - fix * position for Objective-C types + * API/ObjCCallbackFunction.h: + - fix * position for Objective-C types + * API/ObjCCallbackFunction.mm: + (CallbackArgument): + (CallbackArgumentStruct::CallbackArgumentStruct): + - fix * position for Objective-C types + (CallbackArgumentBlockCallback::createAdoptingJSBlockAdaptor): + - Added to make adopt explicit + (CallbackArgumentBlockCallback): + (CallbackArgumentBlockCallback::CallbackArgumentBlockCallback): + (ArgumentTypeDelegate::typeBlock): + - Call createAdoptingJSBlockAdaptor + (ArgumentTypeDelegate::typeStruct): + (CallbackResult): + (CallbackResultStruct::CallbackResultStruct): + (ResultTypeDelegate::typeStruct): + (ObjCCallbackFunction::ObjCCallbackFunction): + (ObjCCallbackFunction::context): + (objCCallbackFunctionForInvocation): + (objCCallbackFunctionForMethod): + (objCCallbackFunctionForBlock): + - fix * position for Objective-C types + * API/ObjcRuntimeExtras.h: + (protocolImplementsProtocol): + (forEachProtocolImplementingProtocol): + (forEachMethodInProtocol): + (forEachPropertyInProtocol): + - fix * position for Objective-C types + * API/tests/testapi.m: + (-[TestObject testArgumentTypesWithInt:double:boolean:string:number:array:dictionary:]): + (testObjectiveCAPI): + - fix * position for Objective-C types + +2013-01-02 Geoffrey Garen <ggaren@apple.com> + + Some renaming in the CodeCache + https://bugs.webkit.org/show_bug.cgi?id=105966 + + Reviewed by Gavin Barraclough. + + CodeBlockKey => SourceCodeKey because the key is not a CodeBlock. + + m_recentlyUsedFunctionCode => m_recentlyUsedFunctions to match other names. + + GlobalFunctionKey => FunctionKey because the key is not unique to globalness. + + m_cachedGlobalFunctions => m_globalFunctions because "cached" is redundant + for data members in an object called "CodeCache". + + kMaxRootCodeBlockEntries => kMaxRootEntries because there are no non-CodeBlock + entries in a CodeBlock cache. + + kMaxFunctionCodeBlocks => kMaxChildFunctionEntries to clarify that this + number models a parent-child relationship. + + Also removed the initial "k" from enum constants. That's an interesting + style for calling out constants, but it's not the WebKit style. + + Finally, a behavior change: Use MaxRootEntries for the limit on global + functions, and not MaxChildFunctionEntries. Previously, there was an + unused constant that seemed to have been intended for this purpose. + + * runtime/CodeCache.cpp: + (JSC::CodeCache::makeSourceCodeKey): + (JSC::CodeCache::getCodeBlock): + (JSC::CodeCache::generateFunctionCodeBlock): + (JSC::CodeCache::makeFunctionKey): + (JSC::CodeCache::getFunctionExecutableFromGlobalCode): + (JSC::CodeCache::usedFunctionCode): + * runtime/CodeCache.h: + (JSC::CodeCache::clear): + +2013-01-02 Filip Pizlo <fpizlo@apple.com> + + DFG inlining machinery should be robust against the inline callee varying while the executable stays the same + https://bugs.webkit.org/show_bug.cgi?id=105953 + + Reviewed by Mark Hahnenberg. + + This institutes the policy that if InlineCallFrame::callee is null, then the callee and scope have already + been stored into the true call frame (i.e. the place where the call frame of the inlined call would have + been) and so any attempt to access the callee or scope should do a load instead of assuming that the value + is constant. This wires the changes through the bytecode parser, the stack scanning logic, and the compiler + optimization phases and backends. + + * bytecode/CodeOrigin.cpp: + (JSC::InlineCallFrame::dump): + * bytecode/CodeOrigin.h: + (CodeOrigin): + (InlineCallFrame): + (JSC::InlineCallFrame::isClosureCall): + (JSC::CodeOrigin::stackOffset): + (JSC): + * dfg/DFGAssemblyHelpers.h: + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::get): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::getScope): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCSEPhase.cpp: + (CSEPhase): + (JSC::DFG::CSEPhase::genericPureCSE): + (JSC::DFG::CSEPhase::pureCSE): + (JSC::DFG::CSEPhase::pureCSERequiringSameInlineCallFrame): + (JSC::DFG::CSEPhase::getMyScopeLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * interpreter/CallFrame.cpp: + (JSC::CallFrame::trueCallFrame): + +2013-01-02 Gavin Barraclough <barraclough@apple.com> + + Objective-C API for JavaScriptCore + https://bugs.webkit.org/show_bug.cgi?id=105889 + + Reviewed by Geoff Garen. + + Fixes for a number of issues raised by Darin. + + * API/APIJSValue.h: + - Fix typos in comment + - Add newline before NS_CLASS_AVAILABLE(10_9, NA) + - cls -> expectedClass + - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> * + * API/JSBase.h: + - JS_OBJC_API_ENABLED no longer implies __OBJC__ + * API/JSBlockAdaptor.mm: + (BlockArgumentStruct::BlockArgumentStruct): + (BlockArgumentStruct): + - mark virtual functions as virtual, override, and private + - refactor out buffer allocation for struct types + (BlockArgumentTypeDelegate::typeVoid): + (BlockArgumentTypeDelegate::typeBlock): + (BlockArgumentTypeDelegate::typeStruct): + - return nil -> return 0 + (BlockResultStruct::BlockResultStruct): + (BlockResultStruct): + - mark virtual functions as virtual, override, and private + - refactor out buffer allocation for struct types + (buildBlockSignature): + - %lu is not an appropriate format specifier for NSInteger + (-[JSBlockAdaptor initWithBlockSignatureFromProtocol:]): + - nil check [super init] + (-[JSBlockAdaptor blockMatchesSignature:]): + (-[JSBlockAdaptor blockFromValue:inContext:withException:]): + - ctx -> contextRef + * API/JSContext.h: + - Fix typos in comment + - Add newline before NS_CLASS_AVAILABLE(10_9, NA) + - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> * + * API/JSContext.mm: + (-[JSContext initWithVirtualMachine:]): + - nil check [super init] + (+[JSContext currentArguments]): + - args -> argumentArray + (-[JSContext setObject:forKeyedSubscript:]): + - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> * + (-[JSContext dealloc]): + (-[JSContext protect:]): + (-[JSContext unprotect:]): + - m_protected -> m_protectCounts + * API/JSValue.mm: + (-[JSValue toObjectOfClass:]): + - cls -> expectedClass + (-[JSValue toBool]): + (-[JSValue deleteProperty:]): + (-[JSValue hasProperty:]): + (-[JSValue isUndefined]): + (-[JSValue isNull]): + (-[JSValue isBoolean]): + (-[JSValue isNumber]): + (-[JSValue isString]): + (-[JSValue isObject]): + (-[JSValue isEqualToObject:]): + (-[JSValue isEqualWithTypeCoercionToObject:]): + (-[JSValue isInstanceOf:]): + - removed ? YES : NO + (-[JSValue callWithArguments:]): + (-[JSValue constructWithArguments:]): + (-[JSValue invokeMethod:withArguments:]): + - args -> argumentArray + (+[JSValue valueWithPoint:inContext:]): + (+[JSValue valueWithRange:inContext:]): + (+[JSValue valueWithRect:inContext:]): + (+[JSValue valueWithSize:inContext:]): + - [NSNumber numberWithFloat:] -> @() + (-[JSValue objectForKeyedSubscript:]): + (-[JSValue setObject:forKeyedSubscript:]): + - key type for -setObject:forKeyedSubscript: is now NSObject <NSCopying> * + (JSContainerConvertor): + (JSContainerConvertor::isWorkListEmpty): + (JSContainerConvertor::convert): + (ObjcContainerConvertor): + (ObjcContainerConvertor::isWorkListEmpty): + - remove WTF:: + - isWorkListEmpty is const + (objectToValue): + - use fast enumeration + (-[JSValue initWithValue:inContext:]): + - nil check [super init] + (getStructTagHandler): + - m_structHandlers -> structHandlers + * API/JSVirtualMachine.h: + - Add newline before NS_CLASS_AVAILABLE(10_9, NA) + * API/JSVirtualMachine.mm: + (-[JSVirtualMachine init]): + - nil check [super init] + * API/JSWrapperMap.mm: + (selectorToPropertyName): + (copyPrototypeProperties): + - remove WTF:: + - use static_cast + (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): + (-[JSWrapperMap initWithContext:]): + - nil check [super init] + (-[JSWrapperMap wrapperForObject:]): + (tryUnwrapObjcObject): + - enable ASSERT + (getJSExportProtocol): + (getNSBlockClass): + - remove if check on initializing static + * API/JavaScriptCore.h: + - JS_OBJC_API_ENABLED no longer implies __OBJC__ + * API/ObjCCallbackFunction.mm: + (CallbackArgumentOfClass): + (CallbackArgumentOfClass::~CallbackArgumentOfClass): + (CallbackArgumentStruct::CallbackArgumentStruct): + (CallbackArgumentStruct): + (CallbackArgumentBlockCallback): + - mark virtual functions as virtual, override, and private + - refactor out buffer allocation for struct types + (ArgumentTypeDelegate::typeVoid): + (ArgumentTypeDelegate::typeOfClass): + (ArgumentTypeDelegate::typeStruct): + - return nil -> return 0 + (CallbackResultStruct::CallbackResultStruct): + (CallbackResultStruct): + - mark virtual functions as virtual, override, and private + - refactor out buffer allocation for struct types + (ResultTypeDelegate::typeStruct): + - return nil -> return 0 + (ObjCCallbackFunction): + - remove WTF:: + (objCCallbackFunctionFinalize): + - use static_cast + (objCCallbackFunctionCallAsFunction): + - Fix typos in comment + (createObjCCallbackFunctionClass): + (objCCallbackFunctionClass): + - Split out createObjCCallbackFunctionClass from objCCallbackFunctionClass + (ObjCCallbackFunction::call): + - ctx -> contextRef + (blockSignatureContainsClass): + - Remove tri-state enum. + (skipNumber): + - isdigit -> isASCIIDigit + (objCCallbackFunctionForInvocation): + - clean up & comment blockSignatureContainsClass() usage + (tryUnwrapBlock): + - use static_cast + * API/ObjcRuntimeExtras.h: + (forEachProtocolImplementingProtocol): + (forEachMethodInClass): + (forEachMethodInProtocol): + (forEachPropertyInProtocol): + - Remove WTF:: + - Remove if (count) checks + (skipPair): + - NSUInteger -> size_t + (StringRange): + (StringRange::operator const char*): + (StringRange::get): + (StructBuffer): + (StructBuffer::StructBuffer): + (StructBuffer::~StructBuffer): + (StructBuffer::operator void*): + - Added helper for creating an aligned buffer, used by struct conversion invocations. + (parseObjCType): + - *(position++) -> *position++ + * API/tests/testapi.c: + - PLATFORM(MAC) -> JS_OBJC_API_ENABLED + * API/tests/testapi.m: + (blockSignatureContainsClass): + - Remove tri-state enum. + (testObjectiveCAPI): + - Added more result type checks. + +2013-01-02 Filip Pizlo <fpizlo@apple.com> + + DFG should not use the InlineCallFrame's callee when it could have used the executable istead + https://bugs.webkit.org/show_bug.cgi?id=105947 + + Reviewed by Mark Hahnenberg. + + We shouldn't use the callee to get the executable when we have the executable already. Not only + does this make the logic more clear, but it also allows for a world where the executable is known + but the callee isn't. + + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::strictModeFor): + +2013-01-02 Filip Pizlo <fpizlo@apple.com> + + DFG inliner should not use the callee's bytecode variable for resolving references to the callee in inlined code + https://bugs.webkit.org/show_bug.cgi?id=105938 + + Reviewed by Mark Hahnenberg. + + This simplifies a bunch of code for referring to the callee. It also ought to simplify how we do + closure call inlining: for inlined closure call frames we will simply require that the callee is + already stashed on the stack in the Callee slot in the inline call frame header. + + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::getDirect): + (JSC::DFG::ByteCodeParser::get): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand): + (JSC::DFG::ByteCodeParser::handleCall): + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + (JSC::DFG::ByteCodeParser::parse): + +2013-01-02 Ryosuke Niwa <rniwa@webkit.org> + + Another Windows port build fix attempt. Try not exporting this symbol from JSC + since it's also compiled in WebCore. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2013-01-02 Csaba Osztrogonác <ossy@webkit.org> + + One more unreviewed buildfix after r138609. + + * jit/JITCall.cpp: Add a missing include. + +2013-01-02 Csaba Osztrogonác <ossy@webkit.org> + + Unreviewed buildfix after r138609. + + * jit/JITCall32_64.cpp: Add a missing include. + +2013-01-01 Filip Pizlo <fpizlo@apple.com> + + Baseline JIT should have closure call caching + https://bugs.webkit.org/show_bug.cgi?id=105900 + + Reviewed by Gavin Barraclough. + + This is not a speed-up by itself, but is meant to allow the DFG inliner to + accurately discern between closure calls and non-closure calls, so that it can + do closure call inlining in the future. + + * bytecode/CallLinkStatus.cpp: + (JSC::CallLinkStatus::computeFromLLInt): + (JSC::CallLinkStatus::computeFor): + * bytecode/CallLinkStatus.h: + (JSC::CallLinkStatus::CallLinkStatus): + (JSC::CallLinkStatus::isClosureCall): + (CallLinkStatus): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleCall): + * jit/JIT.cpp: + (JSC::JIT::linkFor): + (JSC::JIT::linkSlowCall): + * jit/JIT.h: + (JSC::JIT::compileClosureCall): + * jit/JITCall.cpp: + (JSC::JIT::privateCompileClosureCall): + * jit/JITCall32_64.cpp: + (JSC::JIT::privateCompileClosureCall): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * jit/JITStubs.h: + * jit/ThunkGenerators.cpp: + (JSC::linkClosureCallGenerator): + * jit/ThunkGenerators.h: + +2013-01-01 Dan Bernstein <mitz@apple.com> + + <rdar://problem/12942239> Update copyright strings + + Reviewed by Sam Weinig. + + * Info.plist: + +2012-12-31 Gavin Barraclough <barraclough@apple.com> + + Objective-C API for JavaScriptCore + https://bugs.webkit.org/show_bug.cgi?id=105889 + + Reviewed by Filip Pizlo. + + For a detailed description of the API implemented here, see: + JSContext.h + APIJSValue.h + JSVirtualMachine.h + JSExport.h + Still to do - + (1) Shoud rename APIJSValue.h -> JSValue.h (but we'll have to rename JSValue.h first). + (2) Numerous FIXMEs, all with separate bugs filed. + + * API/APIJSValue.h: Added. + - this Objective-C class is used to reference a JavaScript object. + * API/JSBase.h: + - added JS_OBJC_API_ENABLED macro to control ObjC API support. + * API/JSBlockAdaptor.h: Added. + - this Objective-C class is used in creating a special NSBlock proxying a JavaScript function. + * API/JSBlockAdaptor.mm: Added. + (BlockArgument): + (BlockArgument::~BlockArgument): + (BlockArgumentBoolean): + (BlockArgumentBoolean::get): + (BlockArgumentNumeric): + (BlockArgumentNumeric::get): + (BlockArgumentId): + (BlockArgumentId::get): + (BlockArgumentStruct): + (BlockArgumentStruct::BlockArgumentStruct): + (BlockArgumentStruct::~BlockArgumentStruct): + (BlockArgumentStruct::get): + - decoded arguent type information of a JSBlockAdaptor. + (BlockArgumentTypeDelegate): + (BlockArgumentTypeDelegate::typeInteger): + (BlockArgumentTypeDelegate::typeDouble): + (BlockArgumentTypeDelegate::typeBool): + (BlockArgumentTypeDelegate::typeVoid): + (BlockArgumentTypeDelegate::typeId): + (BlockArgumentTypeDelegate::typeOfClass): + (BlockArgumentTypeDelegate::typeBlock): + (BlockArgumentTypeDelegate::typeStruct): + - delegate for use in conjunction with parseObjCType. + (BlockResult): + (BlockResult::~BlockResult): + (BlockResultVoid): + (BlockResultVoid::set): + (BlockResultInteger): + (BlockResultInteger::set): + (BlockResultDouble): + (BlockResultDouble::set): + (BlockResultBoolean): + (BlockResultBoolean::set): + (BlockResultStruct): + (BlockResultStruct::BlockResultStruct): + (BlockResultStruct::~BlockResultStruct): + (BlockResultStruct::set): + - decoded result type information of a JSBlockAdaptor. + (buildBlockSignature): + - partial step in constructing a signature with stack offset information from one without. + (-[JSBlockAdaptor initWithBlockSignatureFromProtocol:]): + - constructor. + (-[JSBlockAdaptor blockMatchesSignature:]): + - check whether signature strings match, where only one contains stack frame offsets. + (-[JSBlockAdaptor blockFromValue:inContext:withException:]): + - use the adaptor to create a special forwarding block. + * API/JSCallbackObjectFunctions.h: + (JSC::::inherits): + - add missing braces to multiline for statement. + * API/JSContext.h: Added. + - this Objective-C class is used to reference a JavaScript context. + * API/JSContext.mm: Added. + (-[JSContext init]): + - constructor. + (-[JSContext initWithVirtualMachine:]): + - construct in a given VM (JSGlobalData). + (-[JSContext evaluateScript:]): + (-[JSContext globalObject]): + - evaluate a script, global object accessor. + (+[JSContext currentContext]): + (+[JSContext currentThis]): + (+[JSContext currentArguments]): + - These methods obtain context, this, arguments from within a callback. + (-[JSContext virtualMachine]): + - implementation for .virtualMachine property. + (-[JSContext objectForKeyedSubscript:]): + (-[JSContext setObject:forKeyedSubscript:]): + - support for subscript property access. + (contextInternalContext): + - internal accessor to m_context. + (-[JSContext dealloc]): + - desctructor. + (-[JSContext notifyException:]): + (-[JSContext valueFromNotifyException:]): + (-[JSContext boolFromNotifyException:]): + - internal method to record an exception was thrown. + (-[JSContext beginCallbackWithData:thisValue:argumentCount:arguments:]): + (-[JSContext endCallbackWithData:]): + - internal methods to push/pop a callback record. + (-[JSContext protect:]): + (-[JSContext unprotect:]): + - internal methods to add a value to a protect set (used to protect the internal property of JSValue). + (-[JSContext wrapperForObject:]): + - internal method to create a wrapper object. + (WeakContextRef::WeakContextRef): + (WeakContextRef::~WeakContextRef): + (WeakContextRef::get): + (WeakContextRef::set): + - Helper class to implement a weak reference to a JSContext. + * API/JSContextInternal.h: Added. + (CallbackData): + (WeakContextRef): + - see API/JSContext.mm for description of internal methods. + * API/JSExport.h: Added. + - Provides JSExport protocol & JSExportAs macro. + * API/JSValue.mm: Added. + (+[JSValue valueWithObject:inContext:]): + (+[JSValue valueWithBool:inContext:]): + (+[JSValue valueWithDouble:inContext:]): + (+[JSValue valueWithInt32:inContext:]): + (+[JSValue valueWithUInt32:inContext:]): + (+[JSValue valueWithNewObjectInContext:]): + (+[JSValue valueWithNewArrayInContext:]): + (+[JSValue valueWithNewRegularExpressionFromPattern:flags:inContext:]): + (+[JSValue valueWithNewErrorFromMessage:inContext:]): + (+[JSValue valueWithNullInContext:]): + (+[JSValue valueWithUndefinedInContext:]): + - Constructors. + (-[JSValue toObject]): + (-[JSValue toObjectOfClass:]): + (-[JSValue toBool]): + (-[JSValue toDouble]): + (-[JSValue toInt32]): + (-[JSValue toUInt32]): + (-[JSValue toNumber]): + (-[JSValue toString]): + (-[JSValue toDate]): + (-[JSValue toArray]): + (-[JSValue toDictionary]): + - Conversion to Objective-C types. + (-[JSValue valueForProperty:]): + (-[JSValue setValue:forProperty:]): + (-[JSValue deleteProperty:]): + (-[JSValue hasProperty:]): + (-[JSValue defineProperty:descriptor:]): + - Property access by property name. + (-[JSValue valueAtIndex:]): + (-[JSValue setValue:atIndex:]): + - Property access by index. + (-[JSValue isUndefined]): + (-[JSValue isNull]): + (-[JSValue isBoolean]): + (-[JSValue isNumber]): + (-[JSValue isString]): + (-[JSValue isObject]): + - Test JavaScript type. + (-[JSValue isEqualToObject:]): + (-[JSValue isEqualWithTypeCoercionToObject:]): + (-[JSValue isInstanceOf:]): + - ===, ==, instanceof operators. + (-[JSValue callWithArguments:]): + (-[JSValue constructWithArguments:]): + (-[JSValue invokeMethod:withArguments:]): + - Call & construct. + (-[JSValue context]): + - implementation for .context property. + (-[JSValue toPoint]): + (-[JSValue toRange]): + (-[JSValue toRect]): + (-[JSValue toSize]): + (+[JSValue valueWithPoint:inContext:]): + (+[JSValue valueWithRange:inContext:]): + (+[JSValue valueWithRect:inContext:]): + (+[JSValue valueWithSize:inContext:]): + - Support for NS struct types. + (-[JSValue objectForKeyedSubscript:]): + (-[JSValue objectAtIndexedSubscript:]): + (-[JSValue setObject:forKeyedSubscript:]): + (-[JSValue setObject:atIndexedSubscript:]): + - support for subscript property access. + (isDate): + (isArray): + - internal helper functions to check for instances of JS Date, Array types. + (JSContainerConvertor): + (Task): + (JSContainerConvertor::JSContainerConvertor): + (JSContainerConvertor::isWorkListEmpty): + (JSContainerConvertor::convert): + (JSContainerConvertor::add): + (JSContainerConvertor::take): + - helper class for tracking state while converting to Array/Dictionary objects. + (valueToObjectWithoutCopy): + (containerValueToObject): + (valueToObject): + (valueToNumber): + (valueToString): + (valueToDate): + (valueToArray): + (valueToDictionary): + - function for converting JavaScript values to Objective-C objects. + (ObjcContainerConvertor): + (ObjcContainerConvertor::ObjcContainerConvertor): + (ObjcContainerConvertor::isWorkListEmpty): + (ObjcContainerConvertor::convert): + (ObjcContainerConvertor::add): + (ObjcContainerConvertor::take): + - helper class for tracking state while converting to Array/Dictionary values. + (objectToValueWithoutCopy): + (objectToValue): + (valueInternalValue): + - function for converting Objective-C objects to JavaScript values. + (+[JSValue valueWithValue:inContext:]): + (-[JSValue initWithValue:inContext:]): + - internal constructors. + (StructTagHandler): + (getStructTagHandler): + (+[JSValue selectorForStructToValue:]): + (+[JSValue selectorForValueToStruct:]): + - methods to tracking struct types that support conversion to/from JSValue. + (-[JSValue dealloc]): + - destructor. + (-[JSValue description]): + - Objective-C to-NSString conversion. + (typeToValueInvocationFor): + (valueToTypeInvocationFor): + - create invocation objects for conversion to/from JSValue. + * API/JSValueInternal.h: Added. + - see API/JSValue.mm for description of internal methods. + * API/JSVirtualMachine.h: Added. + - this Objective-C class is used to reference a JavaScript virtual machine (JSGlobalData). + * API/JSVirtualMachine.mm: Added. + (-[JSVirtualMachine init]): + (-[JSVirtualMachine dealloc]): + - constructor & destructor. + (getGroupFromVirtualMachine): + - internal accessor for m_group property. + * API/JSVirtualMachineInternal.h: Added. + - see API/JSVirtualMachine.mm for description of internal methods. + * API/JSWrapperMap.h: Added. + * API/JSWrapperMap.mm: Added. + (wrapperClass): + - singleton root for detction (& unwrapping) of wrapper objects. + (selectorToPropertyName): + - default selector to property name conversion. + (createObjectWithCustomBrand): + - creates a JSObject with a custom NativeBrand (class name). + (createRenameMap): + - parse @optional properties of a JSExport protocol. + (putNonEnumerable): + - property put with enumerable=false. + (copyMethodsToObject): + - iterate methods in a protocol; add functions to a JSObject. + (parsePropertyAttributes): + - examine protocol property metadata. + (makeSetterName): + - "foo" -> "setFoo" + (copyPrototypeProperties): + - create properties on a Protocol object reflecting the instance methods & properties of a protocol. + (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): + (-[JSObjCClassInfo dealloc]): + (-[JSObjCClassInfo wrapperForObject:]): + (-[JSObjCClassInfo constructor]): + - cache the Protocol/Constructor objects for an Objective-C type. + (-[JSWrapperMap initWithContext:]): + (-[JSWrapperMap dealloc]): + - constructor & desctructor. + (-[JSWrapperMap classInfoForClass:]): + - maps Class -> JSObjCClassInfo. + (-[JSWrapperMap wrapperForObject:]): + - cretae or retrieve a cached wrapper value for an object. + (tryUnwrapObjcObject): + - check whether a value is a wrapper object; unwrap if so. + * API/JavaScriptCore.h: + - Added includes for new API headers. + * API/ObjCCallbackFunction.h: Added. + - this class is used to wrap Objective-C instance methods, class methods & blocks as JSFunction objects. + * API/ObjCCallbackFunction.mm: Added. + (CallbackArgument): + (CallbackArgument::~CallbackArgument): + (CallbackArgumentBoolean): + (CallbackArgumentBoolean::set): + (CallbackArgumentInteger): + (CallbackArgumentInteger::set): + (CallbackArgumentDouble): + (CallbackArgumentDouble::set): + (CallbackArgumentJSValue): + (CallbackArgumentJSValue::set): + (CallbackArgumentId): + (CallbackArgumentId::set): + (CallbackArgumentOfClass): + (CallbackArgumentOfClass::CallbackArgumentOfClass): + (CallbackArgumentOfClass::~CallbackArgumentOfClass): + (CallbackArgumentOfClass::set): + (CallbackArgumentNSNumber): + (CallbackArgumentNSNumber::set): + (CallbackArgumentNSString): + (CallbackArgumentNSString::set): + (CallbackArgumentNSDate): + (CallbackArgumentNSDate::set): + (CallbackArgumentNSArray): + (CallbackArgumentNSArray::set): + (CallbackArgumentNSDictionary): + (CallbackArgumentNSDictionary::set): + (CallbackArgumentStruct): + (CallbackArgumentStruct::CallbackArgumentStruct): + (CallbackArgumentStruct::~CallbackArgumentStruct): + (CallbackArgumentStruct::set): + (CallbackArgumentBlockCallback): + (CallbackArgumentBlockCallback::CallbackArgumentBlockCallback): + (CallbackArgumentBlockCallback::~CallbackArgumentBlockCallback): + (CallbackArgumentBlockCallback::set): + - decoded arguent type information of a ObjCCallbackFunction. + (ArgumentTypeDelegate): + (ArgumentTypeDelegate::typeInteger): + (ArgumentTypeDelegate::typeDouble): + (ArgumentTypeDelegate::typeBool): + (ArgumentTypeDelegate::typeVoid): + (ArgumentTypeDelegate::typeId): + (ArgumentTypeDelegate::typeOfClass): + (ArgumentTypeDelegate::typeBlock): + (ArgumentTypeDelegate::typeStruct): + - delegate for use in conjunction with parseObjCType. + (CallbackResult): + (CallbackResult::~CallbackResult): + (CallbackResultVoid): + (CallbackResultVoid::get): + (CallbackResultId): + (CallbackResultId::get): + (CallbackResultNumeric): + (CallbackResultNumeric::get): + (CallbackResultBoolean): + (CallbackResultBoolean::get): + (CallbackResultStruct): + (CallbackResultStruct::CallbackResultStruct): + (CallbackResultStruct::~CallbackResultStruct): + (CallbackResultStruct::get): + - decoded result type information of a ObjCCallbackFunction. + (ResultTypeDelegate): + (ResultTypeDelegate::typeInteger): + (ResultTypeDelegate::typeDouble): + (ResultTypeDelegate::typeBool): + (ResultTypeDelegate::typeVoid): + (ResultTypeDelegate::typeId): + (ResultTypeDelegate::typeOfClass): + (ResultTypeDelegate::typeBlock): + (ResultTypeDelegate::typeStruct): + - delegate for use in conjunction with parseObjCType. + (ObjCCallbackFunction): + (ObjCCallbackFunction::ObjCCallbackFunction): + (ObjCCallbackFunction::~ObjCCallbackFunction): + - constructor & destructor. + (ObjCCallbackFunction::context): + - accessor. + (ObjCCallbackFunction::wrappedBlock): + - attemmpt to unwrap a block object. + (objCCallbackFunctionFinalize): + (objCCallbackFunctionCallAsFunction): + (objCCallbackFunctionClass): + - JSClassRef used to represent ObjCCallbackFunction objects. + (ObjCCallbackFunction::call): + (blockSignatureContainsClass): + - helper function to determine if we're running on a recent Clang. + (skipNumber): + - helper used in parsing signature strings. + (objCCallbackFunctionForInvocation): + (objCCallbackFunctionForMethod): + (objCCallbackFunctionForBlock): + - functions to try to create ObjCCallbackFunction instances for methods/blocks. + (tryUnwrapBlock): + - attemmpt to unwrap a block object. + * API/ObjcRuntimeExtras.h: Added. + (protocolImplementsProtocol): + (forEachProtocolImplementingProtocol): + (forEachMethodInClass): + (forEachMethodInProtocol): + (forEachPropertyInProtocol): + - functions used in reflecting on Objective-C types. + (skipPair): + - parsing helper used by parseObjCType, scans for matching parentheses. + (StringRange): + (StringRange::StringRange): + (StringRange::~StringRange): + (StringRange::operator const char*): + (StringRange::get): + - Helper class - create a c string copy of a range of an existing string. + (parseObjCType): + - function to parse Objective-C type strings, makes callbacks to a deleagte. + * API/tests/testapi.c: + (main): + - added call to testObjectiveCAPI (in testapi.m). + * API/tests/testapi.m: Added. + (+[ParentObject parentTest]): + (+[TestObject testObject]): + (+[TestObject classTest]): + (-[TestObject getString]): + (-[TestObject testArgumentTypesWithInt:double:boolean:string:number:array:dictionary:]): + (-[TestObject callback:]): + (-[TextXYZ test:]): + - test object, used in various test vases. + (checkResult): + - helper function. + (blockSignatureContainsClass): + - helper function to determine if we're running on a recent Clang. + (testObjectiveCAPI): + - new test cases. + * JavaScriptCore.xcodeproj/project.pbxproj: + - added new files. + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + - added m_apiData - provide convenient storage for use by the API. + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::JSGlobalObject): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + - added m_apiData - provide convenient storage for use by the API. + +2012-12-27 Csaba Osztrogonác <ossy@webkit.org> + + One more unreviwed holiday MIPS and SH4 buildfixes after r138516. + + * jit/ThunkGenerators.cpp: + +2012-12-27 Csaba Osztrogonác <ossy@webkit.org> + + Unreviwed holiday ARM and SH4 buildfixes after r138516. + + * jit/ThunkGenerators.cpp: + (JSC::nativeForGenerator): + +2012-12-26 Filip Pizlo <fpizlo@apple.com> + + All JIT stubs should go through the getCTIStub API + https://bugs.webkit.org/show_bug.cgi?id=105750 + + Reviewed by Sam Weinig. + + Previously JITThunks had two sets of thunks: one static set stored in a struct, + which was filled by JIT::privateCompileCTITrampolines, and another set stored in + a HashMap. Moreover, the code to generate the code for the CTI trampoline struct + had loads of copy-paste between JSVALUE32_64 and JSVALUE64, and was total + unmodular with respect to calls versus constructors, among other things. + + This changeset removes this struct and rationalizes the code that generates those + thunks. All of thunks are now generated through the getCTIStub HashMap API. All + thunks for the baseline JIT now use the JSInterfaceJIT and have their codegen + located in ThunkGenerators.cpp. All thunks now share as much code as possible - + it turns out that they are almost 100% identical between 32_64 and 64, so that + works out great. A bunch of call vs. construct duplication was eliminated. And, + most of the call link versus virtual call duplication was also eliminated. + + This does not change behavior but it does make it easier to add more thunks in + the future. + + * bytecode/CallLinkInfo.cpp: + (JSC::CallLinkInfo::unlink): + * jit/JIT.cpp: + (JSC::JIT::linkFor): + * jit/JIT.h: + (JIT): + * jit/JITCall.cpp: + (JSC::JIT::compileCallEvalSlowCase): + (JSC::JIT::compileOpCallSlowCase): + * jit/JITCall32_64.cpp: + (JSC::JIT::compileCallEvalSlowCase): + (JSC::JIT::compileOpCallSlowCase): + * jit/JITInlines.h: + (JSC): + * jit/JITOpcodes.cpp: + (JSC): + (JSC::JIT::privateCompileCTINativeCall): + * jit/JITOpcodes32_64.cpp: + (JSC): + * jit/JITStubs.cpp: + (JSC::tryCacheGetByID): + * jit/JITThunks.cpp: + (JSC::JITThunks::JITThunks): + (JSC::JITThunks::ctiNativeCall): + (JSC::JITThunks::ctiNativeConstruct): + (JSC): + (JSC::JITThunks::hostFunctionStub): + * jit/JITThunks.h: + (JSC): + (JITThunks): + * jit/JSInterfaceJIT.h: + (JSInterfaceJIT): + (JSC::JSInterfaceJIT::emitJumpIfNotJSCell): + (JSC): + (JSC::JSInterfaceJIT::emitFastArithIntToImmNoCheck): + (JSC::JSInterfaceJIT::emitJumpIfNotType): + (JSC::JSInterfaceJIT::emitGetFromCallFrameHeaderPtr): + (JSC::JSInterfaceJIT::emitPutToCallFrameHeader): + (JSC::JSInterfaceJIT::emitPutImmediateToCallFrameHeader): + (JSC::JSInterfaceJIT::emitPutCellToCallFrameHeader): + (JSC::JSInterfaceJIT::preserveReturnAddressAfterCall): + (JSC::JSInterfaceJIT::restoreReturnAddressBeforeReturn): + (JSC::JSInterfaceJIT::restoreArgumentReference): + * jit/ThunkGenerators.cpp: + (JSC::generateSlowCaseFor): + (JSC): + (JSC::linkForGenerator): + (JSC::linkCallGenerator): + (JSC::linkConstructGenerator): + (JSC::virtualForGenerator): + (JSC::virtualCallGenerator): + (JSC::virtualConstructGenerator): + (JSC::stringLengthTrampolineGenerator): + (JSC::nativeForGenerator): + (JSC::nativeCallGenerator): + (JSC::nativeConstructGenerator): + (JSC::charCodeAtThunkGenerator): + (JSC::charAtThunkGenerator): + (JSC::fromCharCodeThunkGenerator): + (JSC::sqrtThunkGenerator): + (JSC::floorThunkGenerator): + (JSC::ceilThunkGenerator): + (JSC::roundThunkGenerator): + (JSC::expThunkGenerator): + (JSC::logThunkGenerator): + (JSC::absThunkGenerator): + (JSC::powThunkGenerator): + * jit/ThunkGenerators.h: + (JSC): + * runtime/Executable.h: + (NativeExecutable): + (JSC::NativeExecutable::nativeFunctionFor): + (JSC::NativeExecutable::offsetOfNativeFunctionFor): + +2012-12-25 Gyuyoung Kim <gyuyoung.kim@samsung.com> + + [CMAKE] Remove header files in JavaScriptCore/CMakeLists.txt + https://bugs.webkit.org/show_bug.cgi?id=105753 + + Reviewed by Laszlo Gombos. + + * CMakeLists.txt: Remove header files in source list. + +2012-12-25 Filip Pizlo <fpizlo@apple.com> + + JITThunks should be in its own file + https://bugs.webkit.org/show_bug.cgi?id=105744 + + Rubber stamped by Sam Weinig. + + Moved JITThunks into its own file and removed some static methods from it + that were not related to what JITThunks currently does. Performed various + pagan rituals to get it to build - apparently there is a circular dependency + between JSCell, Weak, and JITThunks, which magically resolves itself if you + make sure to first include Register.h. Making it so that fewer pagan rituals + need to be performed if this code changes in the future is covered by + https://bugs.webkit.org/show_bug.cgi?id=105696. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * jit/JITStubs.cpp: + (JSC::tryCachePutByID): + (JSC::tryCacheGetByID): + * jit/JITStubs.h: + (JSC::JITStackFrame::returnAddressSlot): + (JSC::returnAddressIsInCtiTrampoline): + * jit/JITThunks.cpp: Added. + (JSC::JITThunks::JITThunks): + (JSC::JITThunks::~JITThunks): + (JSC::JITThunks::ctiStub): + (JSC::JITThunks::hostFunctionStub): + (JSC::JITThunks::clearHostFunctionStubs): + * jit/JITThunks.h: Added. + (JSC::JITThunks::ctiStringLengthTrampoline): + (JSC::JITThunks::ctiVirtualCallLink): + (JSC::JITThunks::ctiVirtualConstructLink): + (JSC::JITThunks::ctiVirtualCall): + (JSC::JITThunks::ctiVirtualConstruct): + (JSC::JITThunks::ctiNativeCall): + (JSC::JITThunks::ctiNativeConstruct): + * jit/ThunkGenerator.h: Added. + * jit/ThunkGenerators.cpp: + * jit/ThunkGenerators.h: + * runtime/JSGlobalData.h: + +2012-12-25 Ilya Tikhonovsky <loislo@chromium.org> + + Unreviewed follow-up for r138455. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-12-24 Ilya Tikhonovsky <loislo@chromium.org> + + Unreviewed compilation fix for r138452. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-12-24 Laszlo Gombos <l.gombos@samsung.com> + + Remove wtf/Platform.h includes from {c|cpp} files + https://bugs.webkit.org/show_bug.cgi?id=105678 + + Reviewed by Kentaro Hara. + + Remove wtf/Platform.h from the include list as it is already + included in config.h. + + * disassembler/udis86/udis86.c: + * disassembler/udis86/udis86_decode.c: + * disassembler/udis86/udis86_input.c: + * disassembler/udis86/udis86_itab_holder.c: + * disassembler/udis86/udis86_syn-att.c: + * disassembler/udis86/udis86_syn-intel.c: + * disassembler/udis86/udis86_syn.c: + * heap/VTableSpectrum.cpp: + +2012-12-21 Filip Pizlo <fpizlo@apple.com> + + DFG Arrayify slow path should be out-of-line + https://bugs.webkit.org/show_bug.cgi?id=105400 + + Reviewed by Gavin Barraclough. + + The interesting bit of this change is allowing out-of-line slow path generators + to emit speculation checks. This is accomplished by having a version of + speculationCheck() that returns a jump placeholder instead of taking a jump (or + jump list) as an argument. You can then fill in that jump placeholder at a + later time, so long as you do it before OSR exit linking. Slow path generators + run before linking, so that just naturally ends up working. + + This isn't really a big win, but we know that out-of-lining slow paths is + generally a good thing to do, so it's fair to assume that this is a move in the + right direction. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * dfg/DFGArrayifySlowPathGenerator.h: Added. + (DFG): + (ArrayifySlowPathGenerator): + (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator): + (JSC::DFG::ArrayifySlowPathGenerator::generateInternal): + * dfg/DFGOSRExitJumpPlaceholder.cpp: Added. + (DFG): + (JSC::DFG::OSRExitJumpPlaceholder::fill): + * dfg/DFGOSRExitJumpPlaceholder.h: Added. + (DFG): + (OSRExitJumpPlaceholder): + (JSC::DFG::OSRExitJumpPlaceholder::OSRExitJumpPlaceholder): + (JSC::DFG::OSRExitJumpPlaceholder::operator!): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::speculationCheck): + (DFG): + (JSC::DFG::SpeculativeJIT::arrayify): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + +2012-12-20 Oliver Hunt <oliver@apple.com> + + Finally found the problem. Using the wrong JSContextGroup. + + * API/tests/testapi.c: + (main): + +2012-12-20 Oliver Hunt <oliver@apple.com> + + Try to convince bots to be happy with testapi. + + * API/JSScriptRefPrivate.h: + +2012-12-20 Michael Saboff <msaboff@apple.com> + + JIT: Change uninitialized pointer value -1 to constant + https://bugs.webkit.org/show_bug.cgi?id=105576 + + Rubber stamped by Gavin Barraclough. + + Changed the use of -1 as a pointer value in the JITs to be the constant unusedPointer defined in the + new file jit/UnusedPointer.h. Made it's value 0xd1e7beef, which is a bad pointer on most architectures + because it is odd, and to distinguish it from other common values. + + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGRepatch.cpp: + (JSC::DFG::dfgResetGetByID): + (JSC::DFG::dfgResetPutByID): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::cachedGetById): + (JSC::DFG::SpeculativeJIT::cachedPutById): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::cachedGetById): + (JSC::DFG::SpeculativeJIT::cachedPutById): + * jit/JIT.h: + * jit/JITPropertyAccess.cpp: + (JSC::JIT::resetPatchGetById): + (JSC::JIT::resetPatchPutById): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::resetPatchGetById): + (JSC::JIT::resetPatchPutById): + * jit/JITWriteBarrier.h: + (JSC::JITWriteBarrierBase::clearToUnusedPointer): + (JSC::JITWriteBarrierBase::get): + * jit/UnusedPointer.h: Added. + +2012-12-20 Filip Pizlo <fpizlo@apple.com> + + DFG shouldn't emit CheckStructure on array accesses if exit profiling tells it not to + https://bugs.webkit.org/show_bug.cgi?id=105577 + + Reviewed by Mark Hahnenberg. + + I don't know why this wasn't there from the beginning. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): + +2012-12-19 Filip Pizlo <fpizlo@apple.com> + + DFG speculation checks that take JumpList should consolidate OSRExits + https://bugs.webkit.org/show_bug.cgi?id=105401 + + Reviewed by Oliver Hunt. + + Change OSRExitCompilationInfo to always contain a JumpList, and change JumpList + to be more compact. This way, a speculationCheck that takes a JumpList only has + to emit one OSRExit structure, and one OSRExit landing pad. + + The downside is that we get less precise information about *where* we exited + from. So, this also includes changes to the profiler to be more relaxed about + what an ExitSite is. + + * assembler/AbstractMacroAssembler.h: + (JumpList): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::linkOSRExits): + (JSC::DFG::JITCompiler::link): + * dfg/DFGJITCompiler.h: + (DFG): + (JSC::DFG::JITCompiler::appendExitInfo): + (JITCompiler): + * dfg/DFGOSRExitCompilationInfo.h: + (OSRExitCompilationInfo): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::speculationCheck): + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + * profiler/ProfilerCompilation.cpp: + (JSC::Profiler::Compilation::addOSRExitSite): + * profiler/ProfilerCompilation.h: + (Compilation): + * profiler/ProfilerOSRExitSite.cpp: + (JSC::Profiler::OSRExitSite::toJS): + * profiler/ProfilerOSRExitSite.h: + (JSC::Profiler::OSRExitSite::OSRExitSite): + (JSC::Profiler::OSRExitSite::codeAddress): + (OSRExitSite): + +2012-12-19 Oliver Hunt <oliver@apple.com> + + Fix some incorrect tests in testapi.c + + Reviewed by Simon Fraser. + + * API/tests/testapi.c: + (main): + +2012-12-19 Filip Pizlo <fpizlo@apple.com> + + JSObject::ensure<IndexingType> should gracefully handle InterceptsGetOwn..., and should never be called when the 'this' is not an object + https://bugs.webkit.org/show_bug.cgi?id=105468 + + Reviewed by Mark Hahnenberg, Oliver Hunt, and Gavin Barraclough. + + Changed JSObject::ensure<IndexingType> methods to gracefully handle + InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero. Most of them handle it by returning + null as a result of indexingShouldBeSparse() returning true, while ensureArrayStorage handles it + by entering dictionary indexing mode, which forces the object to behave correctly even if there + is proxying or weird prototype stuff going on. + + Changed DFGOperations entrypoints to reject non-objects, so that JSObject doesn't have to deal + with pretending to be JSString. In particular, this would go wrong in the ArrayStorage case + since we'd try to resize a butterfly on a JSString, but JSString has something other than + m_butterfly at that offset. + + Finally, removed all InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero from JIT code + since those are now redundant. + + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::arrayify): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * runtime/JSObject.cpp: + (JSC::JSObject::enterDictionaryIndexingMode): + (JSC::JSObject::ensureInt32Slow): + (JSC::JSObject::ensureDoubleSlow): + (JSC::JSObject::ensureContiguousSlow): + (JSC::JSObject::ensureArrayStorageSlow): + (JSC): + (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): + * runtime/JSObject.h: + (JSObject): + +2012-12-19 Oliver Hunt <oliver@apple.com> + + Tidy up JSScriptRef API + https://bugs.webkit.org/show_bug.cgi?id=105470 + + Reviewed by Anders Carlsson. + + People found the API's use of a context confusing, so we'll switch to a JSContextGroup based + API, and drop a number of the unnecessary uses of contexts. + + * API/JSScriptRef.cpp: + (OpaqueJSScript::globalData): + (parseScript): + * API/JSScriptRefPrivate.h: + * API/tests/testapi.c: + (main): + +2012-12-19 Alexis Menard <alexis@webkit.org> + + Implement CSS parsing for CSS transitions unprefixed. + https://bugs.webkit.org/show_bug.cgi?id=104804 + + Reviewed by Dean Jackson. + + Add a new flag ENABLE_CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED + to cover the work of unprefixing Transforms, Animations and + Transitions. It will let the possibility of each ports to turn it off + in their release branches until we're confident that these CSS + properties are ready to be unprefixed. + + * Configurations/FeatureDefines.xcconfig: + +2012-12-18 Filip Pizlo <fpizlo@apple.com> + + Proxies should set InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero + https://bugs.webkit.org/show_bug.cgi?id=105379 + + Reviewed by Gavin Barraclough. + + Forgetting to set this flag led to the DFG trying to ensure array storage on a proxy. I've + now hardened the code with a release assertion as well as fixing the bug. A release assertion + is appropriate here since this is slow-path code. + + * runtime/JSObject.cpp: + (JSC::JSObject::enterDictionaryIndexingMode): + (JSC::JSObject::ensureInt32Slow): + (JSC::JSObject::ensureDoubleSlow): + (JSC::JSObject::ensureContiguousSlow): + (JSC::JSObject::ensureArrayStorageSlowNoCheck): + (JSC::JSObject::ensureArrayStorageSlow): + (JSC): + (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): + * runtime/JSObject.h: + (JSObject): + * runtime/JSProxy.h: + (JSProxy): + +2012-12-18 Oliver Hunt <oliver@apple.com> + + Add a JSScriptRef API to JSC so that we can allow API users to avoid the full cost of reparsing everytime the execute a script. + https://bugs.webkit.org/show_bug.cgi?id=105340 + + Reviewed by Gavin Barraclough. + + This patch adds a (currently private) API to allow users of the JSC API to create a JSScript object + that references a reusable version of the script that they wish to evaluate. This can help us avoid + numeorus copies that are otherwise induced by our existing API and gives us an opaque object that we + can hang various caches off. Currently this is simply a simple SourceProvider, but in future we may + be able to add more caching without requiring new/replacement APIs. + + * API/JSScriptRef.cpp: Added. + * API/JSScriptRefPrivate.h: Added. + * API/tests/testapi.c: + Add tests for new APIs. + * JavaScriptCore.xcodeproj/project.pbxproj: + +2012-12-18 Filip Pizlo <fpizlo@apple.com> + + DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode incorrectly checks for non-array array storage when it should be checking for array array storage + https://bugs.webkit.org/show_bug.cgi?id=105365 + + Reviewed by Mark Hahnenberg. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): + +2012-12-18 Filip Pizlo <fpizlo@apple.com> + + SunSpider/date-format-tofte shouldn't compile each of the tiny worthless eval's only to OSR exit in the prologue every time + https://bugs.webkit.org/show_bug.cgi?id=105335 + + Reviewed by Geoffrey Garen. + + The first thing I did was restructure the logic of canInlineResolveOperations(), + because I didn't understand it. This was relevant because the OSR exits are + caused by a resolve that the DFG cannot handle. + + I was then going to make it so that we didn't compile the resolve at all, but + realized that this would not be the best fix: it didn't seem sensible to me to + be optimizing these evals after only 60 invocations. Evals should have a higher + threshold, since they often contain code for which the baseline JIT does a + pretty good job already (if all you've got is a single heap access or a single + hard-to-inline call, then the baseline JIT has got you covered), and typically + if we see one eval code block we expect to see more (from the same eval site): + so our typical low threshold could lead to a *lot* of compilation. As such, the + main effect of this patch is to introduce an evalThresholdMultiplier, which is + now set to 10. + + This is a ~5% speed-up on data-format-tofte. No regressions anywhere as far as + I can see. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::codeTypeThresholdMultiplier): + (JSC): + (JSC::CodeBlock::optimizationThresholdScalingFactor): + (JSC::CodeBlock::exitCountThresholdForReoptimization): + (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): + * bytecode/CodeBlock.h: + (CodeBlock): + * dfg/DFGCapabilities.h: + (JSC::DFG::canInlineResolveOperations): + * dfg/DFGOSRExitCompiler.cpp: + * runtime/Options.h: + (JSC): + +2012-12-18 Filip Pizlo <fpizlo@apple.com> + + Convert indexingTypeToString to IndexingTypeDump + https://bugs.webkit.org/show_bug.cgi?id=105351 + + Reviewed by Mark Hahnenberg. + + This gets rid of another case of static char buffer[thingy]. + + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * runtime/IndexingType.cpp: + (JSC::dumpIndexingType): + * runtime/IndexingType.h: + (JSC): + * runtime/JSValue.cpp: + (JSC::JSValue::dump): + +2012-12-18 Beth Dakin <bdakin@apple.com> + + https://bugs.webkit.org/show_bug.cgi?id=102579 + [mac] Enable scaled cursors + + Reviewed by Dean Jackson. + + * Configurations/FeatureDefines.xcconfig: + +2012-12-18 Mark Hahnenberg <mhahnenberg@apple.com> + + Restrictions on oversize CopiedBlock allocations should be relaxed + https://bugs.webkit.org/show_bug.cgi?id=105339 + + Reviewed by Filip Pizlo. + + Currently the DFG has a single branch in the inline allocation path for property/array storage where + it checks to see if the number of bytes requested will fit in the current block. This does not match + what the C++ allocation path does; it checks if the requested number of bytes is oversize, and then + if it's not, it tries to fit it in the current block. The garbage collector assumes that ALL allocations + that are greater than 16KB are in oversize blocks. Therefore, this mismatch can lead to crashes when + the collector tries to perform some operation on a CopiedBlock. + + To avoid adding an extra branch to the inline allocation path in the JIT, we should make it so that + oversize blocks are allocated on the same alignment boundaries so that there is a single mask to find + the block header of any CopiedBlock (rather than two, one for normal and one for oversize blocks), and + we should figure out if a block is oversize by some other method than just whatever the JSObject says + it is. One way we could record this info Region of the block, since we allocate a one-off Region for + oversize blocks. + + * heap/BlockAllocator.h: + (JSC::Region::isCustomSize): + (Region): + (JSC::Region::createCustomSize): + (JSC::Region::Region): + (JSC::BlockAllocator::deallocateCustomSize): + * heap/CopiedBlock.h: + (CopiedBlock): + (JSC::CopiedBlock::isOversize): + (JSC): + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::tryAllocateOversize): + (JSC::CopiedSpace::tryReallocate): + (JSC::CopiedSpace::tryReallocateOversize): + * heap/CopiedSpace.h: + (CopiedSpace): + * heap/CopiedSpaceInlines.h: + (JSC::CopiedSpace::contains): + (JSC::CopiedSpace::tryAllocate): + (JSC): + * heap/CopyVisitor.h: + (CopyVisitor): + * heap/CopyVisitorInlines.h: + (JSC::CopyVisitor::checkIfShouldCopy): + (JSC::CopyVisitor::didCopy): + * heap/SlotVisitorInlines.h: + (JSC::SlotVisitor::copyLater): + * runtime/JSObject.cpp: + (JSC::JSObject::copyButterfly): + +2012-12-18 Joseph Pecoraro <pecoraro@apple.com> + + [Mac] Add Build Phase to Check Headers for Inappropriate Macros (Platform.h macros) + https://bugs.webkit.org/show_bug.cgi?id=104279 + + Reviewed by David Kilzer. + + Add a build phase to check the public JavaScriptCore headers for + inappropriate macros. + + * JavaScriptCore.xcodeproj/project.pbxproj: + +2012-12-18 Michael Saboff <msaboff@apple.com> + + [Qt] Fix the ARMv7 build after r137976 + https://bugs.webkit.org/show_bug.cgi?id=105270 + + Reviewed by Csaba Osztrogonác. + + Add default value for Jump parameter to fix build. + + * assembler/AbstractMacroAssembler.h: + (JSC::AbstractMacroAssembler::Jump::Jump): + +2012-12-17 Geoffrey Garen <ggaren@apple.com> + + Constant fold !{number} in the parser + https://bugs.webkit.org/show_bug.cgi?id=105232 + + Reviewed by Filip Pizlo. + + Typically, we wait for hot execution and constant fold in the DFG. + However, !0 and !1 are common enough in minifiers that it can be good + to get them out of the way early, for faster/smaller parsing and startup. + + * parser/ASTBuilder.h: + (JSC::ASTBuilder::createLogicalNot): !{literal} is super simple, especially + since there's no literal form of NaN or Inf. + +2012-12-17 Filip Pizlo <fpizlo@apple.com> + + DFG is too aggressive eliding overflow checks for additions involving large constants + https://bugs.webkit.org/show_bug.cgi?id=105239 + + Reviewed by Gavin Barraclough. + + If we elide overflow checks on an addition (or subtraction) involving a larger-than-2^32 immediate, + then make sure that the non-constant child of the addition knows that he's got to do an overflow + check, by flowing the UsedAsNumber property at him. + + * dfg/DFGGraph.h: + (JSC::DFG::Graph::addSpeculationMode): + (Graph): + (JSC::DFG::Graph::addShouldSpeculateInteger): + (JSC::DFG::Graph::addImmediateShouldSpeculateInteger): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + +2012-12-17 Michael Saboff <msaboff@apple.com> + + DFG: Refactor DFGCorrectableJumpPoint to reduce size of OSRExit data + https://bugs.webkit.org/show_bug.cgi?id=105237 + + Reviewed by Filip Pizlo. + + Replaced DFGCorrectableJumpPoint with OSRExitCompilationInfo which is used and kept alive only while we are + compiling in the DFG. Moved the patchable branch offset directly into OSRExit. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/AbstractMacroAssembler.h: + * dfg/DFGCorrectableJumpPoint.cpp: Removed. + * dfg/DFGCorrectableJumpPoint.h: Removed. + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::linkOSRExits): + (JSC::DFG::JITCompiler::link): + * dfg/DFGJITCompiler.h: + (JSC::DFG::JITCompiler::appendExitJump): + (JITCompiler): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + (JSC::DFG::OSRExit::setPatchableCodeOffset): + (JSC::DFG::OSRExit::getPatchableCodeOffsetAsJump): + (JSC::DFG::OSRExit::codeLocationForRepatch): + (JSC::DFG::OSRExit::correctJump): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOSRExitCompilationInfo.h: Added. + (OSRExitCompilationInfo): + (JSC::DFG::OSRExitCompilationInfo::OSRExitCompilationInfo): + (JSC::DFG::OSRExitCompilationInfo::failureJump): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::speculationCheck): + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + +2012-12-17 Filip Pizlo <fpizlo@apple.com> + + DFG is too aggressive with eliding overflow checks in loops + https://bugs.webkit.org/show_bug.cgi?id=105226 + + Reviewed by Mark Hahnenberg and Oliver Hunt. + + If we see a variable's live range cross basic block boundaries, conservatively assume that it may + be part of a data-flow back-edge, and as a result, we may have entirely integer operations that + could lead to the creation of an integer that is out of range of 2^52 (the significand of a double + float). This does not seem to regress any of the benchmarks we care about, and it fixes the bug. + + In future we may want to actually look at whether or not there was a data-flow back-edge instead + of being super conservative about it. But we have no evidence, yet, that this would help us on + real code. + + * dfg/DFGNodeFlags.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + +2012-12-17 Mark Hahnenberg <mhahnenberg@apple.com> + + Butterfly::growArrayRight shouldn't be called on null Butterfly objects + https://bugs.webkit.org/show_bug.cgi?id=105221 + + Reviewed by Filip Pizlo. + + Currently we depend upon the fact that Butterfly::growArrayRight works with null Butterfly + objects purely by coincidence. We should add a new static function that null checks the old + Butterfly object and creates a new one if it's null, or calls growArrayRight if it isn't for + use in the couple of places in JSObject that expect such behavior to work. + + * runtime/Butterfly.h: + (Butterfly): + * runtime/ButterflyInlines.h: + (JSC::Butterfly::createOrGrowArrayRight): + (JSC): + * runtime/JSObject.cpp: + (JSC::JSObject::createInitialIndexedStorage): + (JSC::JSObject::createArrayStorage): + +2012-12-17 Filip Pizlo <fpizlo@apple.com> + + javascript integer overflow + https://bugs.webkit.org/show_bug.cgi?id=104967 + + Reviewed by Mark Hahnenberg. + + Fix PutScopedVar backward flow. + + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + +2012-12-16 Filip Pizlo <fpizlo@apple.com> + + Rationalize array profiling for out-of-bounds and hole cases + https://bugs.webkit.org/show_bug.cgi?id=105139 + + Reviewed by Geoffrey Garen. + + This makes ArrayProfile track whether or not we had out-of-bounds, which allows + for more precise decision-making in the DFG. + + Also cleaned up ExitKinds for out-of-bounds and hole cases to make it easier to + look at them in the profiler. + + Slight speed-up (5-8%) on SunSpider/crypto-md5. + + * bytecode/ArrayProfile.cpp: + (JSC::ArrayProfile::computeUpdatedPrediction): + (JSC::ArrayProfile::briefDescription): + * bytecode/ArrayProfile.h: + (JSC::ArrayProfile::ArrayProfile): + (JSC::ArrayProfile::addressOfOutOfBounds): + (JSC::ArrayProfile::expectedStructure): + (JSC::ArrayProfile::structureIsPolymorphic): + (JSC::ArrayProfile::outOfBounds): + (JSC::ArrayProfile::polymorphicStructure): + * bytecode/CodeBlock.cpp: + (JSC::dumpChain): + * bytecode/ExitKind.cpp: + (JSC::exitKindToString): + (JSC::exitKindIsCountable): + * bytecode/ExitKind.h: + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JIT.h: + * jit/JITInlines.h: + (JSC::JIT::emitArrayProfileOutOfBoundsSpecialCase): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emitSlow_op_get_by_val): + (JSC::JIT::emitSlow_op_put_by_val): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emitSlow_op_get_by_val): + (JSC::JIT::emitSlow_op_put_by_val): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-12-17 Balazs Kilvady <kilvadyb@homejinni.com> + + Implement add64 for MIPS assembler after r136601 + https://bugs.webkit.org/show_bug.cgi?id=104106 + + Reviewed by Zoltan Herczeg. + + Added add64 function to MacroAssebler of MIPS. + + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::add32): + (JSC::MacroAssemblerMIPS::add64): + (MacroAssemblerMIPS): + +2012-12-17 Jonathan Liu <net147@gmail.com> + + Fix Math.pow implementation with MinGW-w64 + https://bugs.webkit.org/show_bug.cgi?id=105087 + + Reviewed by Simon Hausmann. + + The MinGW-w64 runtime has different behaviour for pow() + compared to other C runtimes. This results in the following + test262 tests failing with the latest MinGW-w64 runtime: + - S15.8.2.13_A14 + - S15.8.2.13_A16 + - S15.8.2.13_A20 + - S15.8.2.13_A22 + + Handle the special cases that are different with MinGW-w64. + + * runtime/MathObject.cpp: + (JSC::mathPow): + +2012-12-16 Filip Pizlo <fpizlo@apple.com> + + Bytecode dumping should show rare case profiles + https://bugs.webkit.org/show_bug.cgi?id=105133 + + Reviewed by Geoffrey Garen. + + Refactored the dumper to call dumpBytecodeCommandAndNewLine in just one place, + rather than in all of the places. Changed the rare case profile getters to use + tryBinarySearch rather than binarySearch, so that they can be used speculatively + even if you don't know that the bytecode has rare case profiles. This actually + increases our assertion level, since it means that in release builds we will get + null and crash rather than getting some random adjacent profile. And then this + adds some printing of the rare case profiles. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printUnaryOp): + (JSC::CodeBlock::printBinaryOp): + (JSC::CodeBlock::printConditionalJump): + (JSC::CodeBlock::printCallOp): + (JSC::CodeBlock::printPutByIdOp): + (JSC::CodeBlock::beginDumpProfiling): + (JSC): + (JSC::CodeBlock::dumpValueProfiling): + (JSC::CodeBlock::dumpArrayProfiling): + (JSC::CodeBlock::dumpRareCaseProfile): + (JSC::CodeBlock::dumpBytecode): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::rareCaseProfileForBytecodeOffset): + (JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset): + +2012-12-13 Filip Pizlo <fpizlo@apple.com> + + Attempt to rationalize and simplify WTF::binarySearch + https://bugs.webkit.org/show_bug.cgi?id=104890 + + Reviewed by Maciej Stachowiak. + + Switch to using the new binarySearch() API. No change in behavior. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::bytecodeOffset): + (JSC::CodeBlock::codeOriginForReturn): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::getStubInfo): + (JSC::CodeBlock::getByValInfo): + (JSC::CodeBlock::getCallLinkInfo): + (JSC::CodeBlock::dfgOSREntryDataForBytecodeIndex): + (JSC::CodeBlock::valueProfileForBytecodeOffset): + (JSC::CodeBlock::rareCaseProfileForBytecodeOffset): + (JSC::CodeBlock::specialFastCaseProfileForBytecodeOffset): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::blockIndexForBytecodeOffset): + * dfg/DFGMinifiedGraph.h: + (JSC::DFG::MinifiedGraph::at): + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * profiler/ProfilerBytecodeSequence.cpp: + (JSC::Profiler::BytecodeSequence::indexForBytecodeIndex): + +2012-12-13 Filip Pizlo <fpizlo@apple.com> + + Don't assert that flags <= 0x3ff in JSTypeInfo + https://bugs.webkit.org/show_bug.cgi?id=104988 + + Reviewed by Sam Weinig. + + This assertion doesn't accomplish anything other than crashes. + + * runtime/JSTypeInfo.h: + (JSC::TypeInfo::TypeInfo): + +2012-12-13 Filip Pizlo <fpizlo@apple.com> + + Named lookups on HTML documents produce inconsistent results in JavaScriptCore bindings + https://bugs.webkit.org/show_bug.cgi?id=104623 + + Reviewed by Geoffrey Garen. + + Add the notion of objects that HasImpureGetOwnPropertySlot, and use that to inhibit prototype chain caching + in some cases. This appears to be perf-neutral on benchmarks that we track. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDProtoList): + * jit/JITStubs.cpp: + (JSC::JITThunks::tryCacheGetByID): + (JSC::DEFINE_STUB_FUNCTION): + * runtime/JSTypeInfo.h: + (JSC): + (JSC::TypeInfo::hasImpureGetOwnPropertySlot): + * runtime/Operations.h: + (JSC::normalizePrototypeChainForChainAccess): + +2012-12-13 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, roll out http://trac.webkit.org/changeset/137683. + It broke gmail. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::putStructureStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * runtime/Operations.cpp: + (JSC::jsTypeStringForValue): + (JSC): + * runtime/Operations.h: + (JSC): + +2012-13-11 Oliver Hunt <oliver@apple.com> + + Support op_typeof in the DFG + https://bugs.webkit.org/show_bug.cgi?id=98898 + + Reviewed by Filip Pizlo. + + Adds a TypeOf node to the DFG to support op_typeof. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + We try to determine the result early here, and substitute in a constant. + Otherwise we leave the node intact, and set the result type to SpecString. + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + Parse op_typeof + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::performNodeCSE): + TypeOf nodes can be subjected to pure CSE + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + We can handle typeof. + * dfg/DFGNodeType.h: + (DFG): + Define the node. + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + Add operationTypeOf to support the non-trivial cases. + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + Actual codegen + * runtime/Operations.cpp: + (JSC::jsTypeStringForValue): + (JSC): + * runtime/Operations.h: + (JSC): + Some refactoring to allow us to get the type string for an + object without needing a callframe. + +2012-12-12 Filip Pizlo <fpizlo@apple.com> + + OSR exit compiler should emit code for resetting the execution counter that matches the logic of ExecutionCounter.cpp + https://bugs.webkit.org/show_bug.cgi?id=104791 + + Reviewed by Oliver Hunt. + + The OSR exit compiler wants to make it so that every OSR exit does the equivalent + of: + + codeBlock->m_jitExecuteCounter.setNewThreshold( + codeBlock->counterValueForOptimizeAfterLongWarmUp()); + + This logically involves: + + - Resetting the counter to zero. + - Setting m_activeThreshold to counterValueForOptimizeAfterLongWarmUp(). + - Figuring out the scaled threshold, subtracting the count so far (which is zero, + so this part is a no-op), and clipping (ExecuteCounter::clippedThreshold()). + - Setting m_counter to the negated clipped threshold. + - Setting m_totalCount to the previous count so far (which is zero) plus the + clipped threshold. + + Because of the reset, which sets the count-so-far to zero, this amounts to: + + - Setting m_activeThreshold to counterValueForOptimizeAfterLongWarmUp(). + - Figuring out the clipped scaled threshold. + - Setting m_counter to the negated clipped scaled threshold. + - Setting m_totalCount to the (positive) clipped scaled threshold. + + The code was previously not doing this, but now is. This is performance neutral. + The only change in behavior over what the code was previously doing (setting the + m_counter to the negated scaled threshold, without clipping, and then setting + the m_totalCount to the clipped scaled threshold) is that this will respond more + gracefully under memory pressure and will ensure that we get more value profile + LUBing before triggering recompilation. More LUBing is almost always a good + thing. + + * dfg/DFGOSRExitCompiler.cpp: + (JSC::DFG::OSRExitCompiler::handleExitCounts): + +2012-12-12 Ilya Tikhonovsky <loislo@chromium.org> + + Web Inspector: Native Memory Instrumentation: remove fake root MemoryObjectInfo. + https://bugs.webkit.org/show_bug.cgi?id=104796 + + Reviewed by Yury Semikhatsky. + + It was not a good idea to introduce a fake root MemoryObjectInfo. + It makes a problem when we visit an object without its own MemoryObjectType. + + Example: RenderBox has a global pointer to a hash map. + HashMap doesn't have its own object type because it is a generic container. + It will inherit object type from the fake root memory object info. + The same could happen for another container in another class with other MemoryObjectType. + + This fact forces me to create custom process method for root objects + because they need to have their own MemoryObjectInfo with customisable memory object type. + + Drive by fix: InstrumentedPointer* was replaced with Wrapper* because actually it is using + for instrumented and not instrumented object classes. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-12-11 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + Implement add64 for ARM traditional assembler after r136601 + https://bugs.webkit.org/show_bug.cgi?id=104103 + + Reviewed by Zoltan Herczeg. + + Implement add64 function for ARM traditional macroassembler. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::add64): + (MacroAssemblerARM): + +2012-12-11 Filip Pizlo <fpizlo@apple.com> + + Unreviewed. Fix build with DFG_ENABLE(DEBUG_PROPAGATION_VERBOSE). + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::tallyFrequentExitSites): + +2012-12-11 Filip Pizlo <fpizlo@apple.com> + + Profiler should show bytecode dumps as they would have been visible to the JITs, including the profiling data that the JITs would see + https://bugs.webkit.org/show_bug.cgi?id=104647 + + Reviewed by Oliver Hunt. + + Adds more profiling data to bytecode dumps, and adds the ability to do a secondary + bytecode dump for each JIT compilation of a code block. This is relevant because both + the bytecodes, and the profiling data, may change after some number of executions. + + Also fixes some random dumping code to use PrintStream& rather than + static const char[thingy]. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/ArrayProfile.cpp: + (JSC::dumpArrayModes): + (JSC::ArrayProfile::briefDescription): + * bytecode/ArrayProfile.h: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printGetByIdOp): + (JSC::CodeBlock::printGetByIdCacheStatus): + (JSC::CodeBlock::printCallOp): + (JSC::CodeBlock::dumpValueProfiling): + (JSC::CodeBlock::dumpArrayProfiling): + (JSC::CodeBlock::dumpBytecode): + * bytecode/CodeBlock.h: + * bytecode/ValueProfile.h: + (JSC::ValueProfileBase::briefDescription): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::dump): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseCodeBlock): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + * profiler/ProfilerBytecodeSequence.cpp: Added. + (JSC::Profiler::BytecodeSequence::BytecodeSequence): + (JSC::Profiler::BytecodeSequence::~BytecodeSequence): + (JSC::Profiler::BytecodeSequence::indexForBytecodeIndex): + (JSC::Profiler::BytecodeSequence::forBytecodeIndex): + (JSC::Profiler::BytecodeSequence::addSequenceProperties): + * profiler/ProfilerBytecodeSequence.h: Added. + (JSC::Profiler::BytecodeSequence::size): + (JSC::Profiler::BytecodeSequence::at): + * profiler/ProfilerBytecodes.cpp: + (JSC::Profiler::Bytecodes::Bytecodes): + (JSC::Profiler::Bytecodes::toJS): + * profiler/ProfilerBytecodes.h: + (JSC::Profiler::Bytecodes::instructionCount): + * profiler/ProfilerCompilation.cpp: + (JSC::Profiler::Compilation::addProfiledBytecodes): + (JSC::Profiler::Compilation::toJS): + * profiler/ProfilerCompilation.h: + (JSC::Profiler::Compilation::profiledBytecodesSize): + (JSC::Profiler::Compilation::profiledBytecodesAt): + * profiler/ProfilerDatabase.cpp: + (JSC::Profiler::Database::ensureBytecodesFor): + * profiler/ProfilerDatabase.h: + * profiler/ProfilerProfiledBytecodes.cpp: Added. + (JSC::Profiler::ProfiledBytecodes::ProfiledBytecodes): + (JSC::Profiler::ProfiledBytecodes::~ProfiledBytecodes): + (JSC::Profiler::ProfiledBytecodes::toJS): + * profiler/ProfilerProfiledBytecodes.h: Added. + (JSC::Profiler::ProfiledBytecodes::bytecodes): + * runtime/CommonIdentifiers.h: + +2012-12-11 Oswald Buddenhagen <oswald.buddenhagen@digia.com> + + [Qt] delete dead include paths + + Reviewed by Simon Hausmann. + + followup to https://bugs.webkit.org/show_bug.cgi?id=93446 + + * JavaScriptCore.pri: + +2012-12-11 Julien BRIANCEAU <jbrianceau@nds.com> + + Implement add64 for SH4 assembler to fix build after r136601 + https://bugs.webkit.org/show_bug.cgi?id=104377 + + Reviewed by Zoltan Herczeg. + + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::add64): + (MacroAssemblerSH4): + +2012-12-10 Yury Semikhatsky <yurys@chromium.org> + + Memory instrumentation: make sure each edge is reported only once + https://bugs.webkit.org/show_bug.cgi?id=104630 + + Reviewed by Pavel Feldman. + + Changed exported symbols for MemoryInstrumentation. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-12-10 Filip Pizlo <fpizlo@apple.com> + + Don't OSR exit just because a string is a rope + https://bugs.webkit.org/show_bug.cgi?id=104621 + + Reviewed by Michael Saboff. + + Slight SunSpider speed-up at around the 0.7% level. This patch does the obvious + thing of calling a slow path to resolve ropes rather than OSR exiting if the + string is a rope. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.h: + (JSC::DFG::ArrayMode::getIndexedPropertyStorageMayTriggerGC): + (ArrayMode): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::putStructureStoreElimination): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + +2012-12-10 Gustavo Noronha Silva <gns@gnome.org> + + Unreviewed distcheck fix. + + * GNUmakefile.list.am: + +2012-12-10 Filip Pizlo <fpizlo@apple.com> + + JSC profiling and debug dump code should use inferred names when possible + https://bugs.webkit.org/show_bug.cgi?id=104519 + + Reviewed by Oliver Hunt. + + This does as advertised: the profiler now knows the inferred name of all code blocks, + and all uses of CodeBlock::dump() dump it along with the hash. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::inferredName): + (JSC::CodeBlock::dumpAssumingJITType): + * bytecode/CodeBlock.h: + * profiler/ProfilerBytecodes.cpp: + (JSC::Profiler::Bytecodes::Bytecodes): + (JSC::Profiler::Bytecodes::toJS): + * profiler/ProfilerBytecodes.h: + (JSC::Profiler::Bytecodes::inferredName): + * profiler/ProfilerDatabase.cpp: + (JSC::Profiler::Database::addBytecodes): + (JSC::Profiler::Database::ensureBytecodesFor): + * profiler/ProfilerDatabase.h: + * runtime/CommonIdentifiers.h: + +2012-12-09 Filip Pizlo <fpizlo@apple.com> + + Profiler should say things about OSR exits + https://bugs.webkit.org/show_bug.cgi?id=104497 + + Reviewed by Oliver Hunt. + + This adds support for profiling OSR exits. For each exit that is taken, the profiler + records the machine code address that the exit occurred on, the exit kind, the origin + stack, and the number of times that it happened. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/AbstractMacroAssembler.h: + (Jump): + (JSC::AbstractMacroAssembler::Jump::label): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::saveCompilation): + (CodeBlock): + (JSC::CodeBlock::compilation): + (DFGData): + * bytecode/DFGExitProfile.h: + (DFG): + * bytecode/ExitKind.cpp: Added. + (JSC): + (JSC::exitKindToString): + (JSC::exitKindIsCountable): + (WTF): + (WTF::printInternal): + * bytecode/ExitKind.h: Added. + (JSC): + (WTF): + * dfg/DFGGraph.h: + (Graph): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::linkOSRExits): + (JSC::DFG::JITCompiler::link): + (JSC::DFG::JITCompiler::compile): + (JSC::DFG::JITCompiler::compileFunction): + * dfg/DFGJITCompiler.h: + (JITCompiler): + * dfg/DFGOSRExitCompiler.cpp: + * jit/JIT.cpp: + (JSC::JIT::JIT): + (JSC::JIT::privateCompile): + * jit/JIT.h: + (JIT): + * jit/JumpReplacementWatchpoint.h: + (JSC::JumpReplacementWatchpoint::sourceLabel): + (JumpReplacementWatchpoint): + * profiler/ProfilerCompilation.cpp: + (JSC::Profiler::Compilation::addOSRExitSite): + (Profiler): + (JSC::Profiler::Compilation::addOSRExit): + (JSC::Profiler::Compilation::toJS): + * profiler/ProfilerCompilation.h: + (Compilation): + * profiler/ProfilerDatabase.cpp: + (JSC::Profiler::Database::newCompilation): + * profiler/ProfilerDatabase.h: + (Database): + * profiler/ProfilerOSRExit.cpp: Added. + (Profiler): + (JSC::Profiler::OSRExit::OSRExit): + (JSC::Profiler::OSRExit::~OSRExit): + (JSC::Profiler::OSRExit::toJS): + * profiler/ProfilerOSRExit.h: Added. + (Profiler): + (OSRExit): + (JSC::Profiler::OSRExit::id): + (JSC::Profiler::OSRExit::origin): + (JSC::Profiler::OSRExit::exitKind): + (JSC::Profiler::OSRExit::isWatchpoint): + (JSC::Profiler::OSRExit::counterAddress): + (JSC::Profiler::OSRExit::count): + * profiler/ProfilerOSRExitSite.cpp: Added. + (Profiler): + (JSC::Profiler::OSRExitSite::toJS): + * profiler/ProfilerOSRExitSite.h: Added. + (Profiler): + (OSRExitSite): + (JSC::Profiler::OSRExitSite::OSRExitSite): + (JSC::Profiler::OSRExitSite::codeAddress): + * runtime/CommonIdentifiers.h: + +2012-12-10 Alexis Menard <alexis@webkit.org> + + [CSS3 Backgrounds and Borders] Remove CSS3_BACKGROUND feature flag. + https://bugs.webkit.org/show_bug.cgi?id=104539 + + Reviewed by Antonio Gomes. + + As discussed on webkit-dev it is not needed to keep this feature flag + as support for <position> type is a small feature that is already + implemented by three other UAs. It was useful while landing this + feature as partial bits were landed one after one. + + * Configurations/FeatureDefines.xcconfig: + +2012-12-09 Filip Pizlo <fpizlo@apple.com> + + DFG ArrayPush/Pop should not pass their second child as the index for blessArrayOperation() + https://bugs.webkit.org/show_bug.cgi?id=104500 + + Reviewed by Oliver Hunt. + + Slight across-the-board speed-up. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + +2012-12-08 Filip Pizlo <fpizlo@apple.com> + + JSC should scale the optimization threshold for a code block according to the cost of compiling it + https://bugs.webkit.org/show_bug.cgi?id=104406 + + Reviewed by Oliver Hunt. + + We've long known that we want to scale the execution count threshold needed for the DFG + to kick in to scale according to some estimate of the cost of compiling that code block. + This institutes a relationship like this: + + threshold = thresholdSetting * (a * sqrt(instructionCount + b) + abs(c * instructionCount) + d + + Where a, b, c, d are coefficients derived from fitting the above expression to various + data points, which I chose based on looking at one benchmark (3d-cube) and from my + own intuitions. + + Making this work well also required changing the thresholdForOptimizeAfterLongWarmUp + from 5000 to 1000. + + This is a >1% speed-up on SunSpider, a >3% speed-up on V8Spider, ~1% speed-up on V8v7, + neutral on Octane, and neutral on Kraken. + + I also out-of-lined a bunch of methods related to these heuristics, because I couldn't + stand having them defined in the header anymore. I also made improvements to debugging + code because I needed it for tuning this change. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::sourceCodeForTools): + (JSC::CodeBlock::sourceCodeOnOneLine): + (JSC::CodeBlock::dumpBytecode): + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::reoptimizationRetryCounter): + (JSC::CodeBlock::countReoptimization): + (JSC::CodeBlock::optimizationThresholdScalingFactor): + (JSC::clipThreshold): + (JSC::CodeBlock::counterValueForOptimizeAfterWarmUp): + (JSC::CodeBlock::counterValueForOptimizeAfterLongWarmUp): + (JSC::CodeBlock::counterValueForOptimizeSoon): + (JSC::CodeBlock::checkIfOptimizationThresholdReached): + (JSC::CodeBlock::optimizeNextInvocation): + (JSC::CodeBlock::dontOptimizeAnytimeSoon): + (JSC::CodeBlock::optimizeAfterWarmUp): + (JSC::CodeBlock::optimizeAfterLongWarmUp): + (JSC::CodeBlock::optimizeSoon): + (JSC::CodeBlock::adjustedExitCountThreshold): + (JSC::CodeBlock::exitCountThresholdForReoptimization): + (JSC::CodeBlock::exitCountThresholdForReoptimizationFromLoop): + (JSC::CodeBlock::shouldReoptimizeNow): + (JSC::CodeBlock::shouldReoptimizeFromLoopNow): + * bytecode/CodeBlock.h: + * bytecode/ExecutionCounter.cpp: + (JSC::ExecutionCounter::hasCrossedThreshold): + * bytecode/ReduceWhitespace.cpp: Added. + (JSC::reduceWhitespace): + * bytecode/ReduceWhitespace.h: Added. + * dfg/DFGCapabilities.cpp: + (JSC::DFG::mightCompileEval): + (JSC::DFG::mightCompileProgram): + (JSC::DFG::mightCompileFunctionForCall): + (JSC::DFG::mightCompileFunctionForConstruct): + (JSC::DFG::mightInlineFunctionForCall): + (JSC::DFG::mightInlineFunctionForConstruct): + * dfg/DFGCapabilities.h: + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::dumpHeader): + * dfg/DFGOSREntry.cpp: + (JSC::DFG::prepareOSREntry): + * jit/JITDisassembler.cpp: + (JSC::JITDisassembler::dumpHeader): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::entryOSR): + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * profiler/ProfilerDatabase.cpp: + (JSC::Profiler::Database::ensureBytecodesFor): + * runtime/Options.h: + +2012-12-07 Jonathan Liu <net147@gmail.com> + + Add missing forward declaration for JSC::ArrayAllocationProfile + https://bugs.webkit.org/show_bug.cgi?id=104425 + + Reviewed by Kentaro Hara. + + The header for the JSC::ArrayConstructor class is missing a forward + declaration for the JSC::ArrayAllocationProfile class which causes + compilation to fail when compiling with MinGW-w64. + + * runtime/ArrayConstructor.h: + (JSC): + +2012-12-07 Jonathan Liu <net147@gmail.com> + + Add missing const qualifier to JSC::CodeBlock::getJITType() + https://bugs.webkit.org/show_bug.cgi?id=104424 + + Reviewed by Laszlo Gombos. + + JSC::CodeBlock::getJITType() has the const qualifier when JIT is + enabled but is missing the const qualifier when JIT is disabled. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::getJITType): + +2012-12-07 Oliver Hunt <oliver@apple.com> + + Make function code cache proportional to main codeblock cache + https://bugs.webkit.org/show_bug.cgi?id=104420 + + Reviewed by Geoffrey Garen. + + Makes the constants determining the recently used function cache proportional + to the number of root codeblocks in the cache. Also renames the constants to + make them more clear. + + * runtime/CodeCache.h: + +2012-12-06 Filip Pizlo <fpizlo@apple.com> + + Strange results calculating a square root in a loop + https://bugs.webkit.org/show_bug.cgi?id=104247 + <rdar://problem/12826880> + + Reviewed by Oliver Hunt. + + Fixed the CFG simplification phase to ignore dead GetLocals in the first of the blocks + under the merge. This fixes the assertion, and is also cleaner: our general rule is + to not "revive" things that we've already proved to be dead. + + Also fixed some rotted debug code. + + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-12-07 Geoffrey Garen <ggaren@apple.com> + + Crash in JSC::Bindings::RootObject::globalObject() sync'ing notes in Evernote + https://bugs.webkit.org/show_bug.cgi?id=104321 + <rdar://problem/12770497> + + Reviewed by Sam Weinig. + + Work around a JSValueUnprotect(NULL) in Evernote. + + * API/JSValueRef.cpp: + (evernoteHackNeeded): + (JSValueUnprotect): + +2012-12-06 Filip Pizlo <fpizlo@apple.com> + + Incorrect inequality for checking whether a statement is within bounds of a handler + https://bugs.webkit.org/show_bug.cgi?id=104313 + <rdar://problem/12808934> + + Reviewed by Geoffrey Garen. + + The most relevant change is in handlerForBytecodeOffset(), which fixes the inequality + used for checking whether a handler is pertinent to the current instruction. '<' is + correct, but '<=' isn't, since the 'end' is not inclusive. + + Also found, and addressed, a benign goof in how the finally inliner works: sometimes + we will have end > start. This falls out naturally from how the inliner works and how + we pop scopes in the bytecompiler, but it's sufficiently surprising that, to avoid any + future confusion, I added a comment and some code to prune those handlers out. Because + of how the handler resolution works, these handlers would have been skipped anyway. + + Also made various fixes to debugging code, which was necessary for tracking this down. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecode): + (JSC::CodeBlock::handlerForBytecodeOffset): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::generate): + * bytecompiler/Label.h: + (JSC::Label::bind): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::throwException): + * llint/LLIntExceptions.cpp: + (JSC::LLInt::interpreterThrowInCaller): + (JSC::LLInt::returnToThrow): + (JSC::LLInt::callToThrow): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (JSC::LLInt::handleHostCall): + +2012-12-06 Rick Byers <rbyers@chromium.org> + + CSS cursor property should support webkit-image-set + https://bugs.webkit.org/show_bug.cgi?id=99493 + + Reviewed by Beth Dakin. + + Add ENABLE_MOUSE_CURSOR_SCALE (disabled by default) + + * Configurations/FeatureDefines.xcconfig: + +2012-12-06 Laszlo Gombos <l.gombos@samsung.com> + + [CMake] Consolidate list of files to build for JavaScriptCore + https://bugs.webkit.org/show_bug.cgi?id=104287 + + Reviewed by Gyuyoung Kim. + + Add MemoryStatistics.cpp and ExecutableAllocator.cpp to the common + list of files and remove them from the port specific lists. + + * CMakeLists.txt: + * PlatformBlackBerry.cmake: + * PlatformEfl.cmake: + * PlatformWinCE.cmake: + +2012-12-06 Oliver Hunt <oliver@apple.com> + + Tell heap that we've released all the compiled code. + + Reviewed by Geoff Garen. + + When we discard compiled code, inform the heap that we've + released an entire object graph. This informs the heap that + it might want to perform a GC soon. + + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::discardAllCode): + +2012-12-06 Laszlo Gombos <l.gombos@samsung.com> + + [EFL] Remove ENABLE_GLIB_SUPPORT CMake variable + https://bugs.webkit.org/show_bug.cgi?id=104278 + + Reviewed by Brent Fulgham. + + The conditional is not required as it is always set for EFL. + + * PlatformEfl.cmake: + +2012-12-06 Oliver Hunt <oliver@apple.com> + + Build fix, last patch rolled out logic that is now needed on ToT. + + * parser/ASTBuilder.h: + (ASTBuilder): + (JSC::ASTBuilder::setFunctionStart): + * parser/Nodes.h: + (JSC::FunctionBodyNode::setFunctionStart): + (JSC::FunctionBodyNode::functionStart): + (FunctionBodyNode): + * parser/Parser.cpp: + (JSC::::parseFunctionInfo): + * parser/SyntaxChecker.h: + (JSC::SyntaxChecker::setFunctionStart): + +2012-12-05 Oliver Hunt <oliver@apple.com> + + Remove harmful string->function cache + https://bugs.webkit.org/show_bug.cgi?id=104193 + + Reviewed by Alexey Proskuryakov. + + Remove the string->function code cache that turned out to actually + be quite harmful. + + * runtime/CodeCache.cpp: + (JSC::CodeCache::getFunctionCodeBlock): + * runtime/CodeCache.h: + (JSC::CodeCache::clear): + +2012-12-05 Halton Huo <halton.huo@intel.com> + + [CMake] Unify coding style for CMake files + https://bugs.webkit.org/show_bug.cgi?id=103605 + + Reviewed by Laszlo Gombos. + + Update cmake files(.cmake, CMakeLists.txt) with following style rules: + 1. Indentation + 1.1 Use spaces, not tabs. + 1.2 Four spaces as indent. + 2. Spacing + 2.1 Place one space between control statements and their parentheses. + For eg, if (), else (), elseif (), endif (), foreach (), + endforeach (), while (), endwhile (), break (). + 2.2 Do not place spaces between function and macro statements and + their parentheses. For eg, macro(), endmacro(), function(), + endfunction(). + 2.3 Do not place spaces between a command or function or macro and its + parentheses, or between a parenthesis and its content. For eg, + message("testing") not message( "testing") or message ("testing" ) + 2.4 No space at line ending. + 3. Lowercase when call commands macros and functions. For eg, + add_executable() not ADD_EXECUTABLE(), set() not SET(). + + * CMakeLists.txt: + * PlatformBlackBerry.cmake: + * PlatformEfl.cmake: + * PlatformWinCE.cmake: + * shell/CMakeLists.txt: + * shell/PlatformBlackBerry.cmake: + * shell/PlatformEfl.cmake: + * shell/PlatformWinCE.cmake: + +2012-12-05 Oliver Hunt <oliver@apple.com> + + Empty parse cache when receiving a low memory warning + https://bugs.webkit.org/show_bug.cgi?id=104161 + + Reviewed by Filip Pizlo. + + This adds a function to the globaldata to empty all code related data + structures (code in the heap and the code cache). + It also adds a function to allow the CodeCache to actually be cleared + at all. + + * runtime/CodeCache.h: + (CacheMap): + (JSC::CacheMap::clear): + (JSC::CodeCache::clear): + (CodeCache): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::discardAllCode): + (JSC): + * runtime/JSGlobalData.h: + (JSGlobalData): + +2012-12-05 Filip Pizlo <fpizlo@apple.com> + + JSC profiler should not count executions of op_call_put_result because doing so changes DFG codegen + https://bugs.webkit.org/show_bug.cgi?id=104102 + + Reviewed by Oliver Hunt. + + This removes op_call_put_result from profiling, since profiling it has an effect on + codegen. This fix enables all of SunSpider, V8, and Kraken to be profiled with the + new profiler. + + To make this all fit together, the profiler now also reports in its output the exact + bytecode opcode name for each instruction (in addition to the stringified dump of that + bytecode), so that tools that grok the output can take note of op_call_put_result and + work around the fact that it has no counts. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::parseCodeBlock): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + * profiler/ProfilerBytecode.cpp: + (JSC::Profiler::Bytecode::toJS): + * profiler/ProfilerBytecode.h: + (JSC::Profiler::Bytecode::Bytecode): + (JSC::Profiler::Bytecode::opcodeID): + (Bytecode): + * profiler/ProfilerDatabase.cpp: + (JSC::Profiler::Database::ensureBytecodesFor): + * runtime/CommonIdentifiers.h: + +2012-12-04 Filip Pizlo <fpizlo@apple.com> + + display-profiler-output should be able to show source code + https://bugs.webkit.org/show_bug.cgi?id=104073 + + Reviewed by Oliver Hunt. + + Modify the profiler database to store source code. For functions, we store the + function including the function signature. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::unlinkedCodeBlock): + (CodeBlock): + * profiler/ProfilerBytecodes.cpp: + (JSC::Profiler::Bytecodes::Bytecodes): + (JSC::Profiler::Bytecodes::toJS): + * profiler/ProfilerBytecodes.h: + (Bytecodes): + (JSC::Profiler::Bytecodes::sourceCode): + * profiler/ProfilerDatabase.cpp: + (JSC::Profiler::Database::addBytecodes): + (JSC::Profiler::Database::ensureBytecodesFor): + * profiler/ProfilerDatabase.h: + (Database): + * runtime/CommonIdentifiers.h: + * runtime/Executable.h: + (FunctionExecutable): + (JSC::FunctionExecutable::unlinkedExecutable): + +2012-12-02 Filip Pizlo <fpizlo@apple.com> + + JSC should be able to report profiling data associated with the IR dumps and disassembly + https://bugs.webkit.org/show_bug.cgi?id=102999 + + Reviewed by Gavin Barraclough. + + Added a new profiler to JSC. It's simply called "Profiler" in anticipation of it + ultimately replacing the previous profiling infrastructure. This profiler counts the + number of times that a bytecode executes in various engines, and will record both the + counts and all disassembly and bytecode dumps, into a database that can be at any + time turned into either a JS object using any global object or global data of your + choice, or can be turned into a JSON string, or saved to a file. + + Currently the only use of this is the new '-p <file>' flag to the jsc command-line. + + The profiler is always compiled in and normally incurs no execution time cost, but is + only activated when you create a Profiler::Database and install it in + JSGlobalData::m_perBytecodeProfiler. From that point on, all code blocks will be + compiled along with disassembly and bytecode dumps stored into the Profiler::Database, + and all code blocks will have execution counts, which are also stored in the database. + The database will continue to keep information about code blocks alive even after they + are otherwise GC'd. + + This currently still has some glitches, like the fact that it only counts executions + in the JITs. Doing execution counting in the LLInt might require a bit of a rethink + about how the counting is expressed - currently it is implicit in bytecode, so there + is no easy way to "turn it on" in the LLInt. Also, right now there is no information + recorded about OSR exits or out-of-line stubs. But, even so, it's quite cool, and + gives you a peek into what JSC is doing that would otherwise not be possible. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::~CodeBlock): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::baselineVersion): + * bytecode/CodeOrigin.cpp: + (JSC::InlineCallFrame::baselineCodeBlock): + (JSC): + * bytecode/CodeOrigin.h: + (InlineCallFrame): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::dump): + (DFG): + (JSC::DFG::Disassembler::reportToProfiler): + (JSC::DFG::Disassembler::dumpHeader): + (JSC::DFG::Disassembler::append): + (JSC::DFG::Disassembler::createDumpList): + * dfg/DFGDisassembler.h: + (Disassembler): + (JSC::DFG::Disassembler::DumpedOp::DumpedOp): + (DumpedOp): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::Graph): + (JSC::DFG::Graph::dumpCodeOrigin): + (JSC::DFG::Graph::dump): + * dfg/DFGGraph.h: + (Graph): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::JITCompiler): + (JSC::DFG::JITCompiler::compile): + (JSC::DFG::JITCompiler::compileFunction): + * dfg/DFGNode.h: + (Node): + (JSC::DFG::Node::hasExecutionCounter): + (JSC::DFG::Node::executionCounter): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JIT.cpp: + (JSC::JIT::JIT): + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompile): + * jit/JIT.h: + (JIT): + * jit/JITDisassembler.cpp: + (JSC::JITDisassembler::dump): + (JSC::JITDisassembler::reportToProfiler): + (JSC): + (JSC::JITDisassembler::dumpHeader): + (JSC::JITDisassembler::firstSlowLabel): + (JSC::JITDisassembler::dumpVectorForInstructions): + (JSC::JITDisassembler::dumpForInstructions): + (JSC::JITDisassembler::reportInstructions): + * jit/JITDisassembler.h: + (JITDisassembler): + (DumpedOp): + * jsc.cpp: + (CommandLine::CommandLine): + (CommandLine): + (printUsageStatement): + (CommandLine::parseArguments): + (jscmain): + * profiler/ProfilerBytecode.cpp: Added. + (Profiler): + (JSC::Profiler::Bytecode::toJS): + * profiler/ProfilerBytecode.h: Added. + (Profiler): + (Bytecode): + (JSC::Profiler::Bytecode::Bytecode): + (JSC::Profiler::Bytecode::bytecodeIndex): + (JSC::Profiler::Bytecode::description): + (JSC::Profiler::getBytecodeIndexForBytecode): + * profiler/ProfilerBytecodes.cpp: Added. + (Profiler): + (JSC::Profiler::Bytecodes::Bytecodes): + (JSC::Profiler::Bytecodes::~Bytecodes): + (JSC::Profiler::Bytecodes::indexForBytecodeIndex): + (JSC::Profiler::Bytecodes::forBytecodeIndex): + (JSC::Profiler::Bytecodes::dump): + (JSC::Profiler::Bytecodes::toJS): + * profiler/ProfilerBytecodes.h: Added. + (Profiler): + (Bytecodes): + (JSC::Profiler::Bytecodes::append): + (JSC::Profiler::Bytecodes::id): + (JSC::Profiler::Bytecodes::hash): + (JSC::Profiler::Bytecodes::size): + (JSC::Profiler::Bytecodes::at): + * profiler/ProfilerCompilation.cpp: Added. + (Profiler): + (JSC::Profiler::Compilation::Compilation): + (JSC::Profiler::Compilation::~Compilation): + (JSC::Profiler::Compilation::addDescription): + (JSC::Profiler::Compilation::executionCounterFor): + (JSC::Profiler::Compilation::toJS): + * profiler/ProfilerCompilation.h: Added. + (Profiler): + (Compilation): + (JSC::Profiler::Compilation::bytecodes): + (JSC::Profiler::Compilation::kind): + * profiler/ProfilerCompilationKind.cpp: Added. + (WTF): + (WTF::printInternal): + * profiler/ProfilerCompilationKind.h: Added. + (Profiler): + (WTF): + * profiler/ProfilerCompiledBytecode.cpp: Added. + (Profiler): + (JSC::Profiler::CompiledBytecode::CompiledBytecode): + (JSC::Profiler::CompiledBytecode::~CompiledBytecode): + (JSC::Profiler::CompiledBytecode::toJS): + * profiler/ProfilerCompiledBytecode.h: Added. + (Profiler): + (CompiledBytecode): + (JSC::Profiler::CompiledBytecode::originStack): + (JSC::Profiler::CompiledBytecode::description): + * profiler/ProfilerDatabase.cpp: Added. + (Profiler): + (JSC::Profiler::Database::Database): + (JSC::Profiler::Database::~Database): + (JSC::Profiler::Database::addBytecodes): + (JSC::Profiler::Database::ensureBytecodesFor): + (JSC::Profiler::Database::notifyDestruction): + (JSC::Profiler::Database::newCompilation): + (JSC::Profiler::Database::toJS): + (JSC::Profiler::Database::toJSON): + (JSC::Profiler::Database::save): + * profiler/ProfilerDatabase.h: Added. + (Profiler): + (Database): + * profiler/ProfilerExecutionCounter.h: Added. + (Profiler): + (ExecutionCounter): + (JSC::Profiler::ExecutionCounter::ExecutionCounter): + (JSC::Profiler::ExecutionCounter::address): + (JSC::Profiler::ExecutionCounter::count): + * profiler/ProfilerOrigin.cpp: Added. + (Profiler): + (JSC::Profiler::Origin::Origin): + (JSC::Profiler::Origin::dump): + (JSC::Profiler::Origin::toJS): + * profiler/ProfilerOrigin.h: Added. + (JSC): + (Profiler): + (Origin): + (JSC::Profiler::Origin::Origin): + (JSC::Profiler::Origin::operator!): + (JSC::Profiler::Origin::bytecodes): + (JSC::Profiler::Origin::bytecodeIndex): + (JSC::Profiler::Origin::operator!=): + (JSC::Profiler::Origin::operator==): + (JSC::Profiler::Origin::hash): + (JSC::Profiler::Origin::isHashTableDeletedValue): + (JSC::Profiler::OriginHash::hash): + (JSC::Profiler::OriginHash::equal): + (OriginHash): + (WTF): + * profiler/ProfilerOriginStack.cpp: Added. + (Profiler): + (JSC::Profiler::OriginStack::OriginStack): + (JSC::Profiler::OriginStack::~OriginStack): + (JSC::Profiler::OriginStack::append): + (JSC::Profiler::OriginStack::operator==): + (JSC::Profiler::OriginStack::hash): + (JSC::Profiler::OriginStack::dump): + (JSC::Profiler::OriginStack::toJS): + * profiler/ProfilerOriginStack.h: Added. + (JSC): + (Profiler): + (OriginStack): + (JSC::Profiler::OriginStack::OriginStack): + (JSC::Profiler::OriginStack::operator!): + (JSC::Profiler::OriginStack::size): + (JSC::Profiler::OriginStack::fromBottom): + (JSC::Profiler::OriginStack::fromTop): + (JSC::Profiler::OriginStack::isHashTableDeletedValue): + (JSC::Profiler::OriginStackHash::hash): + (JSC::Profiler::OriginStackHash::equal): + (OriginStackHash): + (WTF): + * runtime/CommonIdentifiers.h: + * runtime/ExecutionHarness.h: + (JSC::prepareForExecution): + (JSC::prepareFunctionForExecution): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::~JSGlobalData): + * runtime/JSGlobalData.h: + (JSGlobalData): + * runtime/Options.h: + (JSC): + +2012-12-04 Filip Pizlo <fpizlo@apple.com> + + Rename Profiler to LegacyProfiler + https://bugs.webkit.org/show_bug.cgi?id=104031 + + Rubber stamped by Mark Hahnenberg + + Make room in the namespace for https://bugs.webkit.org/show_bug.cgi?id=102999. + + * API/JSProfilerPrivate.cpp: + (JSStartProfiling): + (JSEndProfiling): + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * interpreter/Interpreter.cpp: + (JSC::Interpreter::throwException): + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + * jit/JIT.h: + * jit/JITCode.h: + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * jit/JITStubs.h: + (JSC): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * profiler/LegacyProfiler.cpp: Added. + (JSC): + (JSC::LegacyProfiler::profiler): + (JSC::LegacyProfiler::startProfiling): + (JSC::LegacyProfiler::stopProfiling): + (JSC::dispatchFunctionToProfiles): + (JSC::LegacyProfiler::willExecute): + (JSC::LegacyProfiler::didExecute): + (JSC::LegacyProfiler::exceptionUnwind): + (JSC::LegacyProfiler::createCallIdentifier): + (JSC::createCallIdentifierFromFunctionImp): + * profiler/LegacyProfiler.h: Added. + (JSC): + (LegacyProfiler): + (JSC::LegacyProfiler::currentProfiles): + * profiler/ProfileGenerator.cpp: + (JSC::ProfileGenerator::addParentForConsoleStart): + * profiler/ProfileNode.cpp: + * profiler/Profiler.cpp: Removed. + * profiler/Profiler.h: Removed. + * runtime/JSGlobalData.h: + (JSC): + (JSC::JSGlobalData::enabledProfiler): + (JSGlobalData): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::~JSGlobalObject): + +2012-12-03 Filip Pizlo <fpizlo@apple.com> + + DFG should inline code blocks that use scoped variable access + https://bugs.webkit.org/show_bug.cgi?id=103974 + + Reviewed by Oliver Hunt. + + This mostly just turns on something we could have done all along, but also adds a few key + necessities to make this right: + + 1) Constant folding of SkipScope, since if we inline with a known JSFunction* then the + scope is constant. + + 2) Interference analysis for GetLocal<->PutScopedVar and SetLocal<->GetScopedVar. + + This is not meant to be a speed-up on major benchmarks since we don't yet inline most + closure calls for entirely unrelated reasons. But on toy programs it can be >2x faster. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getScope): + (JSC::DFG::ByteCodeParser::parseResolveOperations): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::scopedVarLoadElimination): + (JSC::DFG::CSEPhase::scopedVarStoreElimination): + (JSC::DFG::CSEPhase::getLocalLoadElimination): + (JSC::DFG::CSEPhase::setLocalStoreElimination): + * dfg/DFGCapabilities.h: + (JSC::DFG::canInlineResolveOperations): + +2012-12-03 Filip Pizlo <fpizlo@apple.com> + + Replace JSValue::description() with JSValue::dump(PrintStream&) + https://bugs.webkit.org/show_bug.cgi?id=103866 + + Reviewed by Darin Adler. + + JSValue now has a dump() method. Anywhere that you would have wanted to use + description(), you can either do toCString(value).data(), or if the callee + is a print()/dataLog() method then you just pass the value directly. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * bytecode/CodeBlock.cpp: + (JSC::valueToSourceString): + (JSC::CodeBlock::finalizeUnconditionally): + * bytecode/ValueProfile.h: + (JSC::ValueProfileBase::dump): + * bytecode/ValueRecovery.h: + (JSC::ValueRecovery::dump): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::dump): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::dumpRegisters): + * jsc.cpp: + (functionDescribe): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::llint_trace_value): + * runtime/JSValue.cpp: + (JSC::JSValue::dump): + * runtime/JSValue.h: + +2012-12-04 Filip Pizlo <fpizlo@apple.com> + + jsc command line tool's support for typed arrays should be robust against array buffer allocation errors + https://bugs.webkit.org/show_bug.cgi?id=104020 + <rdar://problem/12802478> + + Reviewed by Mark Hahnenberg. + + Check for null buffers, since that's what typed array allocators are supposed to do. WebCore does it, + and that is indeed the contract of ArrayBuffer and TypedArrayBase. + + * JSCTypedArrayStubs.h: + (JSC): + +2012-12-03 Peter Rybin <prybin@chromium.org> + + Web Inspector: make ASSERTION FAILED: foundPropertiesCount == object->size() more useful + https://bugs.webkit.org/show_bug.cgi?id=103254 + + Reviewed by Pavel Feldman. + + Missing symbol WTFReportFatalError is added to the linker list. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-12-03 Alexis Menard <alexis@webkit.org> + + [Mac] Enable CSS3 background-position offset by default. + https://bugs.webkit.org/show_bug.cgi?id=103905 + + Reviewed by Simon Fraser. + + Turn the flag on by default. + + * Configurations/FeatureDefines.xcconfig: + +2012-12-02 Filip Pizlo <fpizlo@apple.com> + + DFG should trigger rage conversion from double to contiguous if it sees a GetByVal on Double being used in an integer context + https://bugs.webkit.org/show_bug.cgi?id=103858 + + Reviewed by Gavin Barraclough. + + A rage conversion from double to contiguous is one where you try to convert each + double to an int32. + + This is probably not the last we'll hear of rage conversion from double to contiguous. + It may be better to do this right during parsing, which will result in fewer cases of + Arrayification. But even so, this looks like a straight win already - 1% speed-up on + Kraken, no major regression anywhere else. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::refine): + (JSC::DFG::arrayConversionToString): + (JSC::DFG::ArrayMode::dump): + (WTF): + (WTF::printInternal): + * dfg/DFGArrayMode.h: + (JSC::DFG::ArrayMode::withConversion): + (ArrayMode): + (JSC::DFG::ArrayMode::doesConversion): + (WTF): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupBlock): + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::checkArray): + (FixupPhase): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGNodeFlags.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::arrayify): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * runtime/JSObject.cpp: + (JSC): + (JSC::JSObject::genericConvertDoubleToContiguous): + (JSC::JSObject::convertDoubleToContiguous): + (JSC::JSObject::rageConvertDoubleToContiguous): + (JSC::JSObject::ensureContiguousSlow): + (JSC::JSObject::rageEnsureContiguousSlow): + * runtime/JSObject.h: + (JSObject): + (JSC::JSObject::rageEnsureContiguous): + +2012-12-02 Filip Pizlo <fpizlo@apple.com> + + DFG CSE should not keep alive things that aren't relevant to OSR + https://bugs.webkit.org/show_bug.cgi?id=103849 + + Reviewed by Oliver Hunt. + + Most Phantom nodes are inserted by CSE, and by default have the same children as the + node that CSE had eliminated. This change makes CSE inspect all Phantom nodes (both + those it creates and those that were created by other phases) to see if they have + children that are redundant - i.e. children that are not interesting to OSR, which + is the only reason why Phantoms exist in the first place. Being relevant to OSR is + defined as one of: (1) you're a Phi, (2) you're a SetLocal, (3) somewhere between + your definition and the Phantom there was a SetLocal that referred to you. + + This is a slight speed-up in a few places. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::CSEPhase): + (JSC::DFG::CSEPhase::run): + (JSC::DFG::CSEPhase::performSubstitution): + (CSEPhase): + (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren): + (JSC::DFG::CSEPhase::setReplacement): + (JSC::DFG::CSEPhase::eliminate): + (JSC::DFG::CSEPhase::performNodeCSE): + (JSC::DFG::CSEPhase::performBlockCSE): + +2012-12-02 Filip Pizlo <fpizlo@apple.com> + + It should be possible to build and run with DFG_ENABLE(PROPAGATION_VERBOSE) + https://bugs.webkit.org/show_bug.cgi?id=103848 + + Reviewed by Sam Weinig. + + Fix random dataLog() and print() statements. + + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseCodeBlock): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dumpBlockHeader): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + +2012-12-01 Filip Pizlo <fpizlo@apple.com> + + CodeBlock should be able to dump bytecode to something other than WTF::dataFile() + https://bugs.webkit.org/show_bug.cgi?id=103832 + + Reviewed by Oliver Hunt. + + Add a PrintStream& argument to all of the CodeBlock bytecode dumping methods. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecodeCommentAndNewLine): + (JSC::CodeBlock::printUnaryOp): + (JSC::CodeBlock::printBinaryOp): + (JSC::CodeBlock::printConditionalJump): + (JSC::CodeBlock::printGetByIdOp): + (JSC::dumpStructure): + (JSC::dumpChain): + (JSC::CodeBlock::printGetByIdCacheStatus): + (JSC::CodeBlock::printCallOp): + (JSC::CodeBlock::printPutByIdOp): + (JSC::CodeBlock::printStructure): + (JSC::CodeBlock::printStructures): + (JSC::CodeBlock::dumpBytecode): + * bytecode/CodeBlock.h: + (CodeBlock): + * jit/JITDisassembler.cpp: + (JSC::JITDisassembler::dumpForInstructions): + +2012-11-30 Pierre Rossi <pierre.rossi@gmail.com> + + [Qt] Unreviewed speculative Mac build fix after r136232 + + Update the include path so that LLIntAssembly.h is picked up. + The bot didn't break until later when a clean build was triggered. + + * JavaScriptCore.pri: + +2012-11-30 Oliver Hunt <oliver@apple.com> + + Optimise more cases of op_typeof + https://bugs.webkit.org/show_bug.cgi?id=103783 + + Reviewed by Mark Hahnenberg. + + Increase our coverage of typeof based typechecks by + making sure that the codegenerators always uses + consistent operand ordering when feeding typeof operations + into equality operations. + + * bytecompiler/NodesCodegen.cpp: + (JSC::BinaryOpNode::emitBytecode): + (JSC::EqualNode::emitBytecode): + (JSC::StrictEqualNode::emitBytecode): + +2012-11-30 Filip Pizlo <fpizlo@apple.com> + + Rationalize and clean up DFG handling of scoped accesses + https://bugs.webkit.org/show_bug.cgi?id=103715 + + Reviewed by Oliver Hunt. + + Previously, we had a GetScope node that specified the depth to which you wanted + to travel to get a JSScope, and the backend implementation of the node would + perform all of the necessary footwork, including potentially skipping the top + scope if necessary, and doing however many loads were needed. But there were + strange things. First, if you had accesses at different scope depths, then the + loads to get to the common depth could not be CSE'd - CSE would match only + GetScope's that had identical depth. Second, GetScope would be emitted even if + we already had the scope, for example in put_to_base. And finally, even though + the ResolveOperations could tell us whether or not we had to skip the top scope, + the backend would recompute this information itself, often pessimistically. + + This eliminates GetScope and replaces it with the following: + + GetMyScope: just get the JSScope from the call frame header. This will forever + mean getting the JSScope associated with the machine call frame; it will not + mean getting the scope of an inlined function. Or at least that's the intent. + + SkipTopScope: check if there is an activation, and if so, skip a scope. This + takes a scope as a child and returns a scope. + + SkipScope: skip one scope level. + + The bytecode parser now emits the right combination of the above, and + potentially emits multiple SkipScope's, based on the ResolveOperations. + + This change also includes some fixups to debug logging. We now always print + the ExecutableBase* in addition to the CodeBlock* in the CodeBlock's dump, + and we are now more verbose when dumping CodeOrigins and InlineCallFrames. + + This is performance-neutral. It's just meant to be a clean-up. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpAssumingJITType): + * bytecode/CodeOrigin.cpp: + (JSC::CodeOrigin::inlineStack): + (JSC::CodeOrigin::dump): + (JSC): + (JSC::InlineCallFrame::dump): + * bytecode/CodeOrigin.h: + (CodeOrigin): + (InlineCallFrame): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::getScope): + (DFG): + (JSC::DFG::ByteCodeParser::parseResolveOperations): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::scopedVarLoadElimination): + (JSC::DFG::CSEPhase::scopedVarStoreElimination): + (JSC::DFG::CSEPhase::getMyScopeLoadElimination): + (JSC::DFG::CSEPhase::setLocalStoreElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::dump): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dumpCodeOrigin): + (JSC::DFG::Graph::dumpBlockHeader): + * dfg/DFGNode.h: + (Node): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITDisassembler.cpp: + (JSC::JITDisassembler::dump): + +2012-11-30 Oliver Hunt <oliver@apple.com> + + Add direct string->function code cache + https://bugs.webkit.org/show_bug.cgi?id=103764 + + Reviewed by Michael Saboff. + + A fairly logically simple patch. We now track the start of the + unique portion of a functions body, and use that as our key for + unlinked function code. This allows us to cache identical code + in different contexts, leading to a small but consistent improvement + on the benchmarks we track. + + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): + * bytecode/UnlinkedCodeBlock.h: + (JSC::UnlinkedFunctionExecutable::functionStartOffset): + (UnlinkedFunctionExecutable): + * parser/ASTBuilder.h: + (ASTBuilder): + (JSC::ASTBuilder::setFunctionStart): + * parser/Nodes.cpp: + * parser/Nodes.h: + (JSC::FunctionBodyNode::setFunctionStart): + (JSC::FunctionBodyNode::functionStart): + (FunctionBodyNode): + * parser/Parser.cpp: + (JSC::::parseFunctionInfo): + * parser/Parser.h: + (JSC::Parser::findCachedFunctionInfo): + * parser/SyntaxChecker.h: + (JSC::SyntaxChecker::setFunctionStart): + * runtime/CodeCache.cpp: + (JSC::CodeCache::generateFunctionCodeBlock): + (JSC::CodeCache::getFunctionCodeBlock): + (JSC::CodeCache::usedFunctionCode): + * runtime/CodeCache.h: + +2012-11-30 Allan Sandfeld Jensen <allan.jensen@digia.com> + + Crash in conversion of empty OpaqueJSString to Identifier + https://bugs.webkit.org/show_bug.cgi?id=101867 + + Reviewed by Michael Saboff. + + The constructor call used for both null and empty OpaqueJSStrings results + in an assertion voilation and crash. This patch instead uses the Identifier + constructors which are specifically for null and empty Identifier. + + * API/OpaqueJSString.cpp: + (OpaqueJSString::identifier): + +2012-11-30 Tor Arne Vestbø <tor.arne.vestbo@digia.com> + + [Qt] Place the LLIntOffsetsExtractor binaries in debug/release subdirs on Mac + + Otherwise we'll end up using the same LLIntAssembly.h for both build + configs of JavaScriptCore -- one of them which will be for the wrong + config. + + Reviewed by Simon Hausmann. + + * LLIntOffsetsExtractor.pro: + +2012-11-30 Julien BRIANCEAU <jbrianceau@nds.com> + + [sh4] Fix compilation warnings in JavaScriptCore JIT for sh4 arch + https://bugs.webkit.org/show_bug.cgi?id=103378 + + Reviewed by Filip Pizlo. + + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::branchTest32): + (JSC::MacroAssemblerSH4::branchAdd32): + (JSC::MacroAssemblerSH4::branchMul32): + (JSC::MacroAssemblerSH4::branchSub32): + (JSC::MacroAssemblerSH4::branchOr32): + +2012-11-29 Rafael Weinstein <rafaelw@chromium.org> + + [HTMLTemplateElement] Add feature flag + https://bugs.webkit.org/show_bug.cgi?id=103694 + + Reviewed by Adam Barth. + + This flag will guard the implementation of the HTMLTemplateElement. + http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html + + * Configurations/FeatureDefines.xcconfig: + +2012-11-29 Filip Pizlo <fpizlo@apple.com> + + It should be easy to find code blocks in debug dumps + https://bugs.webkit.org/show_bug.cgi?id=103623 + + Reviewed by Goeffrey Garen. + + This gives CodeBlock a relatively strong, but also relatively compact, hash. We compute + it lazily so that it only impacts run-time when debug support is enabled. We stringify + it smartly so that it's short and easy to type. We base it on the source code so that + the optimization level is irrelevant. And, we use SHA1 since it's already in our code + base. Now, when a piece of code wants to print some debugging to say that it's operating + on some code block, it can use this CodeBlockHash instead of memory addresses. + + This also takes CodeBlock debugging into the new world of print() and dataLog(). In + particular, CodeBlock::dump() corresponds to the thing you want printed if you do: + + dataLog("I heart ", *myCodeBlock); + + Probably, you want to just print some identifying information at this point rather than + the full bytecode dump. So, the existing CodeBlock::dump() has been renamed to + CodeBlock::dumpBytecode(), and CodeBlock::dump() now prints the CodeBlockHash plus just + a few little tidbits. + + Here's an example of CodeBlock::dump() output: + + EkILzr:[0x103883a00, BaselineFunctionCall] + + EkILzr is the CodeBlockHash. 0x103883a00 is the CodeBlock's address in memory. The other + part is self-explanatory. + + Finally, this new notion of CodeBlockHash is available for other purposes like bisecting + breakage. As such CodeBlockHash has all of the comparison operator overloads. When + bisecting in DFGDriver.cpp, you can now say things like: + + if (codeBlock->hash() < CodeBlockHash("CAAAAA")) + return false; + + And yes, CAAAAA is near the median hash, and the largest one is smaller than E99999. Such + is life when you use base 62 to encode a 32-bit number. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CallLinkInfo.h: + (CallLinkInfo): + (JSC::CallLinkInfo::specializationKind): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::hash): + (JSC): + (JSC::CodeBlock::dumpAssumingJITType): + (JSC::CodeBlock::dump): + (JSC::CodeBlock::dumpBytecode): + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::resetStubInternal): + (JSC::CodeBlock::reoptimize): + (JSC::ProgramCodeBlock::jettison): + (JSC::EvalCodeBlock::jettison): + (JSC::FunctionCodeBlock::jettison): + (JSC::CodeBlock::shouldOptimizeNow): + (JSC::CodeBlock::tallyFrequentExitSites): + (JSC::CodeBlock::dumpValueProfiles): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::specializationKind): + (CodeBlock): + (JSC::CodeBlock::getJITType): + * bytecode/CodeBlockHash.cpp: Added. + (JSC): + (JSC::CodeBlockHash::CodeBlockHash): + (JSC::CodeBlockHash::dump): + * bytecode/CodeBlockHash.h: Added. + (JSC): + (CodeBlockHash): + (JSC::CodeBlockHash::CodeBlockHash): + (JSC::CodeBlockHash::hash): + (JSC::CodeBlockHash::operator==): + (JSC::CodeBlockHash::operator!=): + (JSC::CodeBlockHash::operator<): + (JSC::CodeBlockHash::operator>): + (JSC::CodeBlockHash::operator<=): + (JSC::CodeBlockHash::operator>=): + * bytecode/CodeBlockWithJITType.h: Added. + (JSC): + (CodeBlockWithJITType): + (JSC::CodeBlockWithJITType::CodeBlockWithJITType): + (JSC::CodeBlockWithJITType::dump): + * bytecode/CodeOrigin.cpp: Added. + (JSC): + (JSC::CodeOrigin::inlineDepthForCallFrame): + (JSC::CodeOrigin::inlineDepth): + (JSC::CodeOrigin::inlineStack): + (JSC::InlineCallFrame::hash): + * bytecode/CodeOrigin.h: + (InlineCallFrame): + (JSC::InlineCallFrame::specializationKind): + (JSC): + * bytecode/CodeType.cpp: Added. + (WTF): + (WTF::printInternal): + * bytecode/CodeType.h: + (WTF): + * bytecode/ExecutionCounter.cpp: + (JSC::ExecutionCounter::dump): + * bytecode/ExecutionCounter.h: + (ExecutionCounter): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseCodeBlock): + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::dump): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dumpCodeOrigin): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOperations.cpp: + * dfg/DFGRepatch.cpp: + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::emitPutReplaceStub): + (JSC::DFG::emitPutTransitionStub): + (JSC::DFG::dfgLinkClosureCall): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::dumpCallFrame): + * jit/JITCode.cpp: Added. + (WTF): + (WTF::printInternal): + * jit/JITCode.h: + (JSC::JITCode::jitType): + (WTF): + * jit/JITDisassembler.cpp: + (JSC::JITDisassembler::dump): + (JSC::JITDisassembler::dumpForInstructions): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdSelfList): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + (JSC::JIT::privateCompileGetByVal): + (JSC::JIT::privateCompilePutByVal): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdSelfList): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * runtime/CodeSpecializationKind.cpp: Added. + (WTF): + (WTF::printInternal): + * runtime/CodeSpecializationKind.h: + (JSC::specializationFromIsCall): + (JSC): + (JSC::specializationFromIsConstruct): + (WTF): + * runtime/Executable.cpp: + (JSC::ExecutableBase::hashFor): + (JSC): + (JSC::NativeExecutable::hashFor): + (JSC::ScriptExecutable::hashFor): + * runtime/Executable.h: + (ExecutableBase): + (NativeExecutable): + (ScriptExecutable): + (JSC::ScriptExecutable::source): + +2012-11-29 Michael Saboff <msaboff@apple.com> + + Speculative Windows build fix after r136086. + + Unreviewed build fix. + + Suspect that ?setDumpsGeneratedCode@BytecodeGenerator@JSC@@SAX_N@Z needs to be removed from Windows + export list since the symbol was removed in r136086. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-11-28 Filip Pizlo <fpizlo@apple.com> + + SpeculatedType dumping should not use the static char buffer[thingy] idiom + https://bugs.webkit.org/show_bug.cgi?id=103584 + + Reviewed by Michael Saboff. + + Changed SpeculatedType to be "dumpable" by saying things like: + + dataLog("thingy = ", SpeculationDump(thingy)) + + Removed the old stringification functions, and changed all code that referred to them + to use the new dataLog()/print() style. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/SpeculatedType.cpp: + (JSC::dumpSpeculation): + (JSC::speculationToAbbreviatedString): + (JSC::dumpSpeculationAbbreviated): + * bytecode/SpeculatedType.h: + * bytecode/ValueProfile.h: + (JSC::ValueProfileBase::dump): + * bytecode/VirtualRegister.h: + (WTF::printInternal): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::dump): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): + (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + (JSC::DFG::Graph::predictArgumentTypes): + * dfg/DFGGraph.h: + (Graph): + * dfg/DFGStructureAbstractValue.h: + * dfg/DFGVariableAccessDataDump.cpp: Added. + (JSC::DFG::VariableAccessDataDump::VariableAccessDataDump): + (JSC::DFG::VariableAccessDataDump::dump): + * dfg/DFGVariableAccessDataDump.h: Added. + (VariableAccessDataDump): + +2012-11-28 Michael Saboff <msaboff@apple.com> + + Change Bytecompiler s_dumpsGeneratedCode to an Options value + https://bugs.webkit.org/show_bug.cgi?id=103588 + + Reviewed by Filip Pizlo. + + Moved the control of dumping bytecodes to Options::dumpGeneratedBytecodes. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + * bytecompiler/BytecodeGenerator.cpp: + * bytecompiler/BytecodeGenerator.h: + * jsc.cpp: + (runWithScripts): + * runtime/Options.h: + +2012-11-28 Mark Hahnenberg <mhahnenberg@apple.com> + + Copying phase should use work lists + https://bugs.webkit.org/show_bug.cgi?id=101390 + + Reviewed by Filip Pizlo. + + * JavaScriptCore.xcodeproj/project.pbxproj: + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::BlockAllocator): + * heap/BlockAllocator.h: New RegionSet for CopyWorkListSegments. + (BlockAllocator): + (JSC::CopyWorkListSegment): + * heap/CopiedBlock.h: Added a per-block CopyWorkList to keep track of the JSCells that need to be revisited during the copying + phase to copy their backing stores. + (CopiedBlock): + (JSC::CopiedBlock::CopiedBlock): + (JSC::CopiedBlock::didSurviveGC): + (JSC::CopiedBlock::didEvacuateBytes): There is now a one-to-one relationship between GCThreads and the CopiedBlocks they're + responsible for evacuating, we no longer need any of that fancy compare and swap stuff. + (JSC::CopiedBlock::pin): + (JSC::CopiedBlock::hasWorkList): + (JSC::CopiedBlock::workList): + * heap/CopiedBlockInlines.h: Added. + (JSC::CopiedBlock::reportLiveBytes): Since we now have to grab a SpinLock to perform operations on the CopyWorkList during marking, + we don't need to do any of that fancy compare and swap stuff we were doing for tracking live bytes. + * heap/CopiedSpace.h: + (CopiedSpace): + * heap/CopiedSpaceInlines.h: + (JSC::CopiedSpace::pin): + * heap/CopyVisitor.cpp: + (JSC::CopyVisitor::copyFromShared): We now iterate over a range of CopiedBlocks rather than MarkedBlocks and revisit the cells in those + blocks' CopyWorkLists. + * heap/CopyVisitor.h: + (CopyVisitor): + * heap/CopyVisitorInlines.h: + (JSC::CopyVisitor::visitCell): The function responsible for calling the correct copyBackingStore() function for each JSCell from + a CopiedBlock's CopyWorkList. + (JSC::CopyVisitor::didCopy): We no longer need to check if the block is empty here because we know exactly when we're done + evacuating a CopiedBlock, which is when we've gone through all of the CopiedBlock's CopyWorkList. + * heap/CopyWorkList.h: Added. + (CopyWorkListSegment): Individual chunk of a CopyWorkList that is allocated from the BlockAllocator. + (JSC::CopyWorkListSegment::create): + (JSC::CopyWorkListSegment::size): + (JSC::CopyWorkListSegment::isFull): + (JSC::CopyWorkListSegment::get): + (JSC::CopyWorkListSegment::append): + (JSC::CopyWorkListSegment::CopyWorkListSegment): + (JSC::CopyWorkListSegment::data): + (JSC::CopyWorkListSegment::endOfBlock): + (CopyWorkListIterator): Responsible for giving CopyVisitors a contiguous notion of access across the separate CopyWorkListSegments + that make up each CopyWorkList. + (JSC::CopyWorkListIterator::get): + (JSC::CopyWorkListIterator::operator*): + (JSC::CopyWorkListIterator::operator->): + (JSC::CopyWorkListIterator::operator++): + (JSC::CopyWorkListIterator::operator==): + (JSC::CopyWorkListIterator::operator!=): + (JSC::CopyWorkListIterator::CopyWorkListIterator): + (CopyWorkList): Data structure that keeps track of the JSCells that need copying in a particular CopiedBlock. + (JSC::CopyWorkList::CopyWorkList): + (JSC::CopyWorkList::~CopyWorkList): + (JSC::CopyWorkList::append): + (JSC::CopyWorkList::begin): + (JSC::CopyWorkList::end): + * heap/GCThreadSharedData.cpp: + (JSC::GCThreadSharedData::GCThreadSharedData): We no longer use the m_blockSnapshot from the Heap during the copying phase. + (JSC::GCThreadSharedData::didStartCopying): We now copy the set of all blocks in the CopiedSpace to a separate vector for + iterating over during the copying phase since the set stored in the CopiedSpace will change as blocks are evacuated and + recycled throughout the copying phase. + * heap/GCThreadSharedData.h: + (GCThreadSharedData): + * heap/Heap.h: + (Heap): + * heap/SlotVisitor.h: We now need to know the object who is being marked that has a backing store so that we can store it + in a CopyWorkList to revisit later during the copying phase. + * heap/SlotVisitorInlines.h: + (JSC::SlotVisitor::copyLater): + * runtime/JSObject.cpp: + (JSC::JSObject::visitButterfly): + +2012-11-28 Filip Pizlo <fpizlo@apple.com> + + Disassembly methods should be able to disassemble to any PrintStream& rather than always using WTF::dataFile() + https://bugs.webkit.org/show_bug.cgi?id=103492 + + Reviewed by Mark Hahnenberg. + + Switched disassembly code to use PrintStream&, and to use print() rather than printf(). + + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::dump): + (DFG): + (JSC::DFG::Disassembler::dumpDisassembly): + * dfg/DFGDisassembler.h: + (Disassembler): + * dfg/DFGGraph.cpp: + (JSC::DFG::printWhiteSpace): + (JSC::DFG::Graph::dumpCodeOrigin): + (JSC::DFG::Graph::printNodeWhiteSpace): + (JSC::DFG::Graph::dump): + (DFG): + (JSC::DFG::Graph::dumpBlockHeader): + * dfg/DFGGraph.h: + (Graph): + * jit/JITDisassembler.cpp: + (JSC::JITDisassembler::dump): + (JSC::JITDisassembler::dumpForInstructions): + (JSC::JITDisassembler::dumpDisassembly): + * jit/JITDisassembler.h: + (JITDisassembler): + +2012-11-28 Filip Pizlo <fpizlo@apple.com> + + It should be possible to say dataLog("count = ", count, "\n") instead of dataLogF("count = %d\n", count) + https://bugs.webkit.org/show_bug.cgi?id=103009 + + Reviewed by Michael Saboff. + + Instead of converting all of JSC to use the new dataLog()/print() methods, I just changed + one place: dumping of abstract values. This is mainly just to ensure that the code I + added to WTF is actually doing things. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::dump): + (WTF): + (WTF::printInternal): + * dfg/DFGStructureAbstractValue.h: + (JSC::DFG::StructureAbstractValue::dump): + (WTF): + (WTF::printInternal): + +2012-11-28 Oliver Hunt <oliver@apple.com> + + Make source cache include more information about the function extent. + https://bugs.webkit.org/show_bug.cgi?id=103552 + + Reviewed by Gavin Barraclough. + + Add a bit more information to the source cache. + + * parser/Parser.cpp: + (JSC::::parseFunctionInfo): + Store the function start offset + * parser/SourceProviderCacheItem.h: + (JSC::SourceProviderCacheItem::SourceProviderCacheItem): + (SourceProviderCacheItem): + Add additional field for the start of the real function string, and re-arrange + fields to avoid growing the struct. + +2012-11-27 Filip Pizlo <fpizlo@apple.com> + + Convert some remaining uses of FILE* to PrintStream&. + + Rubber stamped by Mark Hahnenberg. + + * bytecode/ValueProfile.h: + (JSC::ValueProfileBase::dump): + * bytecode/ValueRecovery.h: + (JSC::ValueRecovery::dump): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseCodeBlock): + * dfg/DFGNode.h: + (JSC::DFG::Node::dumpChildren): + +2012-11-27 Filip Pizlo <fpizlo@apple.com> + + Fix indentation in JSValue.h + + Rubber stamped by Mark Hahnenberg. + + * runtime/JSValue.h: + +2012-11-26 Filip Pizlo <fpizlo@apple.com> + + DFG SetLocal should use forwardSpeculationCheck instead of its own half-baked version of same + https://bugs.webkit.org/show_bug.cgi?id=103353 + + Reviewed by Oliver Hunt and Gavin Barraclough. + + Made it possible to use forward speculations for most of the operand classes. Changed the conditional + direction parameter from being 'bool isForward' to an enum (SpeculationDirection). Changed SetLocal + to use forward speculations and got rid of its half-baked version of same. + + Also added the ability to force the DFG's disassembler to dump all nodes, even ones that are dead. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::dump): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::speculationCheck): + (DFG): + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + (JSC::DFG::SpeculativeJIT::speculationWatchpoint): + (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): + (JSC::DFG::SpeculativeJIT::fillStorage): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculateIntegerOperand::SpeculateIntegerOperand): + (JSC::DFG::SpeculateIntegerOperand::gpr): + (SpeculateIntegerOperand): + (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand): + (JSC::DFG::SpeculateDoubleOperand::fpr): + (SpeculateDoubleOperand): + (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand): + (JSC::DFG::SpeculateCellOperand::gpr): + (SpeculateCellOperand): + (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand): + (JSC::DFG::SpeculateBooleanOperand::gpr): + (SpeculateBooleanOperand): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateInt): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateInt): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntStrict): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::compile): + * runtime/Options.h: + (JSC): + +2012-11-26 Daniel Bates <dbates@webkit.org> + + Substitute "allSeparators8Bit" for "allSeperators8Bit" in JSC::jsSpliceSubstringsWithSeparators() + <https://bugs.webkit.org/show_bug.cgi?id=103303> + + Reviewed by Simon Fraser. + + Fix misspelled word, "Seperators" [sic], in a local variable name in JSC::jsSpliceSubstringsWithSeparators(). + + * runtime/StringPrototype.cpp: + (JSC::jsSpliceSubstringsWithSeparators): + +2012-11-26 Daniel Bates <dbates@webkit.org> + + JavaScript fails to handle String.replace() with large replacement string + https://bugs.webkit.org/show_bug.cgi?id=102956 + <rdar://problem/12738012> + + Reviewed by Oliver Hunt. + + Fix an issue where we didn't check for overflow when computing the length + of the result of String.replace() with a large replacement string. + + * runtime/StringPrototype.cpp: + (JSC::jsSpliceSubstringsWithSeparators): + +2012-11-26 Zeno Albisser <zeno@webkit.org> + + [Qt] Fix the LLInt build on Mac + https://bugs.webkit.org/show_bug.cgi?id=97587 + + Reviewed by Simon Hausmann. + + * DerivedSources.pri: + * JavaScriptCore.pro: + +2012-11-26 Oliver Hunt <oliver@apple.com> + + 32-bit build fix. Move the method decalration outside of the X86_64 only section. + + * assembler/MacroAssembler.h: + (MacroAssembler): + (JSC::MacroAssembler::shouldConsiderBlinding): + +2012-11-26 Oliver Hunt <oliver@apple.com> + + Don't blind all the things. + https://bugs.webkit.org/show_bug.cgi?id=102572 + + Reviewed by Gavin Barraclough. + + No longer blind all the constants in the instruction stream. We use a + simple non-deterministic filter to avoid blinding everything. Also modified + the basic integer blinding logic to avoid blinding small negative values. + + * assembler/MacroAssembler.h: + (MacroAssembler): + (JSC::MacroAssembler::shouldConsiderBlinding): + (JSC::MacroAssembler::shouldBlind): + +2012-11-26 Mark Hahnenberg <mhahnenberg@apple.com> + + JSObject::copyButterfly doesn't handle undecided indexing types correctly + https://bugs.webkit.org/show_bug.cgi?id=102573 + + Reviewed by Filip Pizlo. + + We don't do any copying into the newly allocated vector and we don't zero-initialize CopiedBlocks + during the copying phase, so we end up with uninitialized memory in arrays which have undecided indexing + types. We should just do the actual memcpy from the old block to the new one. + + * runtime/JSObject.cpp: + (JSC::JSObject::copyButterfly): Just do the same thing that we do for other contiguous indexing types. + +2012-11-26 Julien BRIANCEAU <jbrianceau@nds.com> + + [sh4] JavaScriptCore JIT build is broken since r135330 + Add missing implementation for sh4 arch. + https://bugs.webkit.org/show_bug.cgi?id=103145 + + Reviewed by Oliver Hunt. + + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::canJumpReplacePatchableBranchPtrWithPatch): + (MacroAssemblerSH4): + (JSC::MacroAssemblerSH4::startOfBranchPtrWithPatchOnRegister): + (JSC::MacroAssemblerSH4::revertJumpReplacementToBranchPtrWithPatch): + (JSC::MacroAssemblerSH4::startOfPatchableBranchPtrWithPatchOnAddress): + (JSC::MacroAssemblerSH4::revertJumpReplacementToPatchableBranchPtrWithPatch): + * assembler/SH4Assembler.h: + (JSC::SH4Assembler::revertJump): + (SH4Assembler): + (JSC::SH4Assembler::printInstr): + +2012-11-26 Yuqiang Xian <yuqiang.xian@intel.com> + + Use load64 instead of loadPtr to load a JSValue on JSVALUE64 platforms + https://bugs.webkit.org/show_bug.cgi?id=100909 + + Reviewed by Brent Fulgham. + + This is a (trivial) fix after r132701. + + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + +2012-11-26 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + [Qt][ARM] REGRESSION(r130826): It made 33 JSC test and 466 layout tests crash + https://bugs.webkit.org/show_bug.cgi?id=98857 + + Reviewed by Zoltan Herczeg. + + Implement a new version of patchableBranch32 to fix crashing JSC + tests. + + * assembler/MacroAssembler.h: + (MacroAssembler): + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::patchableBranch32): + (MacroAssemblerARM): + +2012-11-21 Filip Pizlo <fpizlo@apple.com> + + Any function that can log things should be able to easily log them to a memory buffer as well + https://bugs.webkit.org/show_bug.cgi?id=103000 + + Reviewed by Sam Weinig. + + Change all users of WTF::dataFile() to expect a PrintStream& rather than a FILE*. + + * bytecode/Operands.h: + (JSC::OperandValueTraits::dump): + (JSC::dumpOperands): + (JSC): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::dump): + * dfg/DFGAbstractState.h: + (AbstractState): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::dump): + * dfg/DFGCommon.h: + (JSC::DFG::NodeIndexTraits::dump): + * dfg/DFGStructureAbstractValue.h: + (JSC::DFG::StructureAbstractValue::dump): + * dfg/DFGVariableEvent.cpp: + (JSC::DFG::VariableEvent::dump): + (JSC::DFG::VariableEvent::dumpFillInfo): + (JSC::DFG::VariableEvent::dumpSpillInfo): + * dfg/DFGVariableEvent.h: + (VariableEvent): + * disassembler/Disassembler.h: + (JSC): + (JSC::tryToDisassemble): + * disassembler/UDis86Disassembler.cpp: + (JSC::tryToDisassemble): + +2012-11-23 Alexis Menard <alexis@webkit.org> + + [CSS3 Backgrounds and Borders] Implement new CSS3 background-position parsing. + https://bugs.webkit.org/show_bug.cgi?id=102104 + + Reviewed by Julien Chaffraix. + + Protect the new feature behind a feature flag. + + * Configurations/FeatureDefines.xcconfig: + +2012-11-23 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + Fix the ARM traditional build after r135330 + https://bugs.webkit.org/show_bug.cgi?id=102871 + + Reviewed by Zoltan Herczeg. + + Added missing functionality to traditional ARM architecture. + + * assembler/ARMAssembler.h: + (JSC::ARMAssembler::revertJump): + (ARMAssembler): + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::startOfPatchableBranchPtrWithPatchOnAddress): + (JSC::MacroAssemblerARM::startOfBranchPtrWithPatchOnRegister): + (MacroAssemblerARM): + (JSC::MacroAssemblerARM::revertJumpReplacementToBranchPtrWithPatch): + +2012-11-16 Yury Semikhatsky <yurys@chromium.org> + + Memory instrumentation: extract MemoryObjectInfo declaration into a separate file + https://bugs.webkit.org/show_bug.cgi?id=102510 + + Reviewed by Pavel Feldman. + + Added new symbols for the methods that have moved into .../wtf/MemoryInstrumentation.cpp + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-11-23 Julien BRIANCEAU <jbrianceau@nds.com> + + [sh4] JavaScriptCore JIT build is broken since r130839 + Add missing implementation for sh4 arch. + https://bugs.webkit.org/show_bug.cgi?id=101479 + + Reviewed by Filip Pizlo. + + * assembler/MacroAssemblerSH4.h: + (JSC::MacroAssemblerSH4::load8Signed): + (MacroAssemblerSH4): + (JSC::MacroAssemblerSH4::load16Signed): + (JSC::MacroAssemblerSH4::store8): + (JSC::MacroAssemblerSH4::store16): + (JSC::MacroAssemblerSH4::moveDoubleToInts): + (JSC::MacroAssemblerSH4::moveIntsToDouble): + (JSC::MacroAssemblerSH4::loadFloat): + (JSC::MacroAssemblerSH4::loadDouble): + (JSC::MacroAssemblerSH4::storeFloat): + (JSC::MacroAssemblerSH4::storeDouble): + (JSC::MacroAssemblerSH4::addDouble): + (JSC::MacroAssemblerSH4::convertFloatToDouble): + (JSC::MacroAssemblerSH4::convertDoubleToFloat): + (JSC::MacroAssemblerSH4::urshift32): + * assembler/SH4Assembler.h: + (JSC::SH4Assembler::sublRegReg): + (JSC::SH4Assembler::subvlRegReg): + (JSC::SH4Assembler::floatfpulfrn): + (JSC::SH4Assembler::fldsfpul): + (JSC::SH4Assembler::fstsfpul): + (JSC::SH4Assembler::dcnvsd): + (SH4Assembler): + (JSC::SH4Assembler::movbRegMem): + (JSC::SH4Assembler::sizeOfConstantPool): + (JSC::SH4Assembler::linkJump): + (JSC::SH4Assembler::printInstr): + (JSC::SH4Assembler::printBlockInstr): + +2012-11-22 Balazs Kilvady <kilvadyb@homejinni.com> + + Fix the MIPS build after r135330 + https://bugs.webkit.org/show_bug.cgi?id=102872 + + Reviewed by Gavin Barraclough. + + Revert/replace functions added to MIPS port. + + * assembler/MIPSAssembler.h: + (JSC::MIPSAssembler::revertJumpToMove): + (MIPSAssembler): + (JSC::MIPSAssembler::replaceWithJump): + * assembler/MacroAssemblerMIPS.h: + (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::startOfBranchPtrWithPatchOnRegister): + (JSC::MacroAssemblerMIPS::revertJumpReplacementToBranchPtrWithPatch): + (JSC::MacroAssemblerMIPS::startOfPatchableBranchPtrWithPatchOnAddress): + +2012-11-21 Filip Pizlo <fpizlo@apple.com> + + Rename dataLog() and dataLogV() to dataLogF() and dataLogFV() + https://bugs.webkit.org/show_bug.cgi?id=103001 + + Rubber stamped by Dan Bernstein. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * assembler/LinkBuffer.cpp: + (JSC::LinkBuffer::finalizeCodeWithDisassembly): + (JSC::LinkBuffer::dumpLinkStatistics): + (JSC::LinkBuffer::dumpCode): + * assembler/LinkBuffer.h: + (JSC): + * assembler/SH4Assembler.h: + (JSC::SH4Assembler::vprintfStdoutInstr): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dumpBytecodeCommentAndNewLine): + (JSC::CodeBlock::printUnaryOp): + (JSC::CodeBlock::printBinaryOp): + (JSC::CodeBlock::printConditionalJump): + (JSC::CodeBlock::printGetByIdOp): + (JSC::dumpStructure): + (JSC::dumpChain): + (JSC::CodeBlock::printGetByIdCacheStatus): + (JSC::CodeBlock::printCallOp): + (JSC::CodeBlock::printPutByIdOp): + (JSC::CodeBlock::printStructure): + (JSC::CodeBlock::printStructures): + (JSC::CodeBlock::dump): + (JSC::CodeBlock::dumpStatistics): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::resetStubInternal): + (JSC::CodeBlock::reoptimize): + (JSC::ProgramCodeBlock::jettison): + (JSC::EvalCodeBlock::jettison): + (JSC::FunctionCodeBlock::jettison): + (JSC::CodeBlock::shouldOptimizeNow): + (JSC::CodeBlock::tallyFrequentExitSites): + (JSC::CodeBlock::dumpValueProfiles): + * bytecode/Opcode.cpp: + (JSC::OpcodeStats::~OpcodeStats): + * bytecode/SamplingTool.cpp: + (JSC::SamplingFlags::stop): + (JSC::SamplingRegion::dumpInternal): + (JSC::SamplingTool::dump): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::initialize): + (JSC::DFG::AbstractState::endBasicBlock): + (JSC::DFG::AbstractState::mergeStateAtTail): + (JSC::DFG::AbstractState::mergeToSuccessors): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::dump): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): + (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): + (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): + (JSC::DFG::ByteCodeParser::makeSafe): + (JSC::DFG::ByteCodeParser::makeDivSafe): + (JSC::DFG::ByteCodeParser::handleCall): + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::processPhiStack): + (JSC::DFG::ByteCodeParser::linkBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + (JSC::DFG::ByteCodeParser::parseCodeBlock): + (JSC::DFG::ByteCodeParser::parse): + * dfg/DFGCFAPhase.cpp: + (JSC::DFG::CFAPhase::performBlockCFA): + (JSC::DFG::CFAPhase::performForwardCFA): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::fixPossibleGetLocal): + (JSC::DFG::CFGSimplificationPhase::fixPhis): + (JSC::DFG::CFGSimplificationPhase::fixJettisonedPredecessors): + (JSC::DFG::CFGSimplificationPhase::removePotentiallyDeadPhiReference): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::endIndexForPureCSE): + (JSC::DFG::CSEPhase::setReplacement): + (JSC::DFG::CSEPhase::eliminate): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGCapabilities.cpp: + (JSC::DFG::debugFail): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode): + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::dump): + * dfg/DFGDriver.cpp: + (JSC::DFG::compile): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::fixDoubleEdge): + * dfg/DFGGraph.cpp: + (JSC::DFG::printWhiteSpace): + (JSC::DFG::Graph::dumpCodeOrigin): + (JSC::DFG::Graph::dump): + (JSC::DFG::Graph::dumpBlockHeader): + (JSC::DFG::Graph::predictArgumentTypes): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + * dfg/DFGOSREntry.cpp: + (JSC::DFG::prepareOSREntry): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + * dfg/DFGPhase.cpp: + (JSC::DFG::Phase::beginPhase): + * dfg/DFGPhase.h: + (JSC::DFG::runAndLog): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + (JSC::DFG::PredictionPropagationPhase::propagateForward): + (JSC::DFG::PredictionPropagationPhase::propagateBackward): + (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): + * dfg/DFGRegisterBank.h: + (JSC::DFG::RegisterBank::dump): + * dfg/DFGScoreBoard.h: + (JSC::DFG::ScoreBoard::use): + (JSC::DFG::ScoreBoard::dump): + * dfg/DFGSlowPathGenerator.h: + (JSC::DFG::SlowPathGenerator::generate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): + (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecutionWithConditionalDirection): + (JSC::DFG::SpeculativeJIT::runSlowPathGenerators): + (JSC::DFG::SpeculativeJIT::dump): + (JSC::DFG::SpeculativeJIT::checkConsistency): + (JSC::DFG::SpeculativeJIT::compile): + (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * dfg/DFGValidate.cpp: + (Validate): + (JSC::DFG::Validate::reportValidationContext): + (JSC::DFG::Validate::dumpData): + (JSC::DFG::Validate::dumpGraphIfAppropriate): + * dfg/DFGVariableEventStream.cpp: + (JSC::DFG::VariableEventStream::logEvent): + (JSC::DFG::VariableEventStream::reconstruct): + * dfg/DFGVirtualRegisterAllocationPhase.cpp: + (JSC::DFG::VirtualRegisterAllocationPhase::run): + * heap/Heap.cpp: + * heap/HeapStatistics.cpp: + (JSC::HeapStatistics::logStatistics): + (JSC::HeapStatistics::showObjectStatistics): + * heap/MarkStack.h: + * heap/MarkedBlock.h: + * heap/SlotVisitor.cpp: + (JSC::SlotVisitor::validate): + * interpreter/CallFrame.cpp: + (JSC::CallFrame::dumpCaller): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::dumpRegisters): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + (JSC::JIT::privateCompile): + * jit/JITDisassembler.cpp: + (JSC::JITDisassembler::dump): + (JSC::JITDisassembler::dumpForInstructions): + * jit/JITStubRoutine.h: + (JSC): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * jit/JumpReplacementWatchpoint.cpp: + (JSC::JumpReplacementWatchpoint::fireInternal): + * llint/LLIntExceptions.cpp: + (JSC::LLInt::interpreterThrowInCaller): + (JSC::LLInt::returnToThrow): + (JSC::LLInt::callToThrow): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::llint_trace_operand): + (JSC::LLInt::llint_trace_value): + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (JSC::LLInt::traceFunctionPrologue): + (JSC::LLInt::jitCompileAndSetHeuristics): + (JSC::LLInt::entryOSR): + (JSC::LLInt::handleHostCall): + (JSC::LLInt::setUpCall): + * profiler/Profile.cpp: + (JSC::Profile::debugPrintData): + (JSC::Profile::debugPrintDataSampleStyle): + * profiler/ProfileNode.cpp: + (JSC::ProfileNode::debugPrintData): + (JSC::ProfileNode::debugPrintDataSampleStyle): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::dumpRegExpTrace): + * runtime/RegExp.cpp: + (JSC::RegExp::matchCompareWithInterpreter): + * runtime/SamplingCounter.cpp: + (JSC::AbstractSamplingCounter::dump): + * runtime/Structure.cpp: + (JSC::Structure::dumpStatistics): + (JSC::PropertyMapStatisticsExitLogger::~PropertyMapStatisticsExitLogger): + * tools/CodeProfile.cpp: + (JSC::CodeProfile::report): + * tools/ProfileTreeNode.h: + (JSC::ProfileTreeNode::dumpInternal): + * yarr/YarrInterpreter.cpp: + (JSC::Yarr::ByteCompiler::dumpDisjunction): + +2012-11-21 Filip Pizlo <fpizlo@apple.com> + + It should be possible to say disassemble(stuff) instead of having to say if (!tryToDisassemble(stuff)) dataLog("I failed") + https://bugs.webkit.org/show_bug.cgi?id=103010 + + Reviewed by Anders Carlsson. + + You can still say tryToDisassemble(), which will tell you if it failed; you can then + decide what to do instead. But it's better to say disassemble(), which will just print + the instruction ranges if tryToDisassemble() failed. This is particularly appropriate + since that's what all previous users of tryToDisassemble() would have done in some + form or another. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/LinkBuffer.cpp: + (JSC::LinkBuffer::finalizeCodeWithDisassembly): + * dfg/DFGDisassembler.cpp: + (JSC::DFG::Disassembler::dumpDisassembly): + * disassembler/Disassembler.cpp: Added. + (JSC): + (JSC::disassemble): + * disassembler/Disassembler.h: + (JSC): + * jit/JITDisassembler.cpp: + (JSC::JITDisassembler::dumpDisassembly): + +2012-11-21 Filip Pizlo <fpizlo@apple.com> + + dumpOperands() claims that it needs a non-const Operands& when that is completely false + https://bugs.webkit.org/show_bug.cgi?id=103005 + + Reviewed by Eric Carlson. + + * bytecode/Operands.h: + (JSC::dumpOperands): + (JSC): + +2012-11-20 Filip Pizlo <fpizlo@apple.com> + + Baseline JIT's disassembly should be just as pretty as the DFG's + https://bugs.webkit.org/show_bug.cgi?id=102873 + + Reviewed by Sam Weinig. + + Integrated the CodeBlock's bytecode dumper with the JIT's disassembler. Also fixed + some type goof-ups (instructions are not in a Vector<Instruction> so using a Vector + iterator makes no sense) and stream-lined some things (you don't actually need a + full-fledged ExecState* to dump bytecode). + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printUnaryOp): + (JSC::CodeBlock::printBinaryOp): + (JSC::CodeBlock::printConditionalJump): + (JSC::CodeBlock::printGetByIdOp): + (JSC::CodeBlock::printCallOp): + (JSC::CodeBlock::printPutByIdOp): + (JSC::CodeBlock::dump): + (JSC): + (JSC::CodeBlock::CodeBlock): + * bytecode/CodeBlock.h: + (CodeBlock): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::dumpCallFrame): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + (JSC::JIT::privateCompile): + * jit/JIT.h: + (JIT): + * jit/JITDisassembler.cpp: Added. + (JSC): + (JSC::JITDisassembler::JITDisassembler): + (JSC::JITDisassembler::~JITDisassembler): + (JSC::JITDisassembler::dump): + (JSC::JITDisassembler::dumpForInstructions): + (JSC::JITDisassembler::dumpDisassembly): + * jit/JITDisassembler.h: Added. + (JSC): + (JITDisassembler): + (JSC::JITDisassembler::setStartOfCode): + (JSC::JITDisassembler::setForBytecodeMainPath): + (JSC::JITDisassembler::setForBytecodeSlowPath): + (JSC::JITDisassembler::setEndOfSlowPath): + (JSC::JITDisassembler::setEndOfCode): + +2012-11-21 Daniel Bates <dbates@webkit.org> + + JavaScript fails to concatenate large strings + <https://bugs.webkit.org/show_bug.cgi?id=102963> + + Reviewed by Michael Saboff. + + Fixes an issue where we inadvertently didn't check the length of + a JavaScript string for overflow. + + * runtime/Operations.h: + (JSC::jsString): + (JSC::jsStringFromArguments): + +2012-11-20 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to cache closure calls (part 2/2) + https://bugs.webkit.org/show_bug.cgi?id=102662 + + Reviewed by Gavin Barraclough. + + Added caching of calls where the JSFunction* varies, but the Structure* and ExecutableBase* + stay the same. This is accomplished by replacing the branch that compares against a constant + JSFunction* with a jump to a closure call stub. The closure call stub contains a fast path, + and jumps slow directly to the virtual call thunk. + + Looks like a 1% win on V8v7. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CallLinkInfo.cpp: + (JSC::CallLinkInfo::unlink): + * bytecode/CallLinkInfo.h: + (CallLinkInfo): + (JSC::CallLinkInfo::isLinked): + (JSC::getCallLinkInfoBytecodeIndex): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::finalizeUnconditionally): + (JSC): + (JSC::CodeBlock::findClosureCallForReturnPC): + (JSC::CodeBlock::bytecodeOffset): + (JSC::CodeBlock::codeOriginForReturn): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::getCallLinkInfo): + (CodeBlock): + (JSC::CodeBlock::isIncomingCallAlreadyLinked): + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::link): + * dfg/DFGJITCompiler.h: + (JSC::DFG::JITCompiler::addJSCall): + (JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord): + (JSCallRecord): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGRepatch.cpp: + (JSC::DFG::linkSlowFor): + (DFG): + (JSC::DFG::dfgLinkFor): + (JSC::DFG::dfgLinkSlowFor): + (JSC::DFG::dfgLinkClosureCall): + * dfg/DFGRepatch.h: + (DFG): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::emitCall): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::emitCall): + * dfg/DFGThunks.cpp: + (DFG): + (JSC::DFG::linkClosureCallThunkGenerator): + * dfg/DFGThunks.h: + (DFG): + * heap/Heap.h: + (Heap): + (JSC::Heap::jitStubRoutines): + * heap/JITStubRoutineSet.h: + (JSC::JITStubRoutineSet::size): + (JSC::JITStubRoutineSet::at): + (JITStubRoutineSet): + * jit/ClosureCallStubRoutine.cpp: Added. + (JSC): + (JSC::ClosureCallStubRoutine::ClosureCallStubRoutine): + (JSC::ClosureCallStubRoutine::~ClosureCallStubRoutine): + (JSC::ClosureCallStubRoutine::markRequiredObjectsInternal): + * jit/ClosureCallStubRoutine.h: Added. + (JSC): + (ClosureCallStubRoutine): + (JSC::ClosureCallStubRoutine::structure): + (JSC::ClosureCallStubRoutine::executable): + (JSC::ClosureCallStubRoutine::codeOrigin): + * jit/GCAwareJITStubRoutine.cpp: + (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine): + * jit/GCAwareJITStubRoutine.h: + (GCAwareJITStubRoutine): + (JSC::GCAwareJITStubRoutine::isClosureCall): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + +2012-11-20 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to cache closure calls (part 1/2) + https://bugs.webkit.org/show_bug.cgi?id=102662 + + Reviewed by Gavin Barraclough. + + Add ability to revert a jump replacement back to + branchPtrWithPatch(Condition, RegisterID, TrustedImmPtr). This is meant to be + a mandatory piece of functionality for all assemblers. I also renamed some of + the functions for reverting jump replacements back to + patchableBranchPtrWithPatch(Condition, Address, TrustedImmPtr), so as to avoid + confusion. + + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::BadReg): + (ARMv7Assembler): + (JSC::ARMv7Assembler::revertJumpTo_movT3): + * assembler/LinkBuffer.h: + (JSC): + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::startOfBranchPtrWithPatchOnRegister): + (MacroAssemblerARMv7): + (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch): + (JSC::MacroAssemblerARMv7::startOfPatchableBranchPtrWithPatchOnAddress): + * assembler/MacroAssemblerX86.h: + (JSC::MacroAssemblerX86::startOfBranchPtrWithPatchOnRegister): + (MacroAssemblerX86): + (JSC::MacroAssemblerX86::startOfPatchableBranchPtrWithPatchOnAddress): + (JSC::MacroAssemblerX86::revertJumpReplacementToBranchPtrWithPatch): + * assembler/MacroAssemblerX86_64.h: + (JSC::MacroAssemblerX86_64::startOfBranchPtrWithPatchOnRegister): + (JSC::MacroAssemblerX86_64::startOfPatchableBranchPtrWithPatchOnAddress): + (MacroAssemblerX86_64): + (JSC::MacroAssemblerX86_64::revertJumpReplacementToBranchPtrWithPatch): + * assembler/RepatchBuffer.h: + (JSC::RepatchBuffer::startOfBranchPtrWithPatchOnRegister): + (RepatchBuffer): + (JSC::RepatchBuffer::startOfPatchableBranchPtrWithPatchOnAddress): + (JSC::RepatchBuffer::revertJumpReplacementToBranchPtrWithPatch): + * assembler/X86Assembler.h: + (JSC::X86Assembler::revertJumpTo_cmpl_ir_force32): + (X86Assembler): + * dfg/DFGRepatch.cpp: + (JSC::DFG::replaceWithJump): + (JSC::DFG::dfgResetGetByID): + (JSC::DFG::dfgResetPutByID): + +2012-11-20 Yong Li <yoli@rim.com> + + [ARMv7] Neither linkCall() nor linkPointer() should flush code. + https://bugs.webkit.org/show_bug.cgi?id=99213 + + Reviewed by George Staikos. + + LinkBuffer doesn't need to flush code during linking. It will + eventually flush the whole executable. Fixing this gives >%5 + sunspider boost (on QNX). + + Also make replaceWithLoad() and replaceWithAddressComputation() flush + only when necessary. + + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::linkCall): + (JSC::ARMv7Assembler::linkPointer): + (JSC::ARMv7Assembler::relinkCall): + (JSC::ARMv7Assembler::repatchInt32): + (JSC::ARMv7Assembler::repatchPointer): + (JSC::ARMv7Assembler::replaceWithLoad): Flush only after it did write. + (JSC::ARMv7Assembler::replaceWithAddressComputation): Flush only after it did write. + (JSC::ARMv7Assembler::setInt32): + (JSC::ARMv7Assembler::setPointer): + +2012-11-19 Filip Pizlo <fpizlo@apple.com> + + Remove support for ARMv7 errata from the jump code + https://bugs.webkit.org/show_bug.cgi?id=102759 + + Reviewed by Oliver Hunt. + + The jump replacement code was wrong to begin with since it wasn't doing + a cache flush on the inserted padding. And, to my knowledge, we don't need + this anymore, so this patch removes all errata code from the ARMv7 port. + + * assembler/ARMv7Assembler.h: + (JSC::ARMv7Assembler::computeJumpType): + (JSC::ARMv7Assembler::replaceWithJump): + (JSC::ARMv7Assembler::maxJumpReplacementSize): + (JSC::ARMv7Assembler::canBeJumpT3): + (JSC::ARMv7Assembler::canBeJumpT4): + +2012-11-19 Patrick Gansterer <paroga@webkit.org> + + [CMake] Create JavaScriptCore ForwardingHeaders + https://bugs.webkit.org/show_bug.cgi?id=92665 + + Reviewed by Brent Fulgham. + + When using CMake to build the Windows port, we need + to generate the forwarding headers with it too. + + * CMakeLists.txt: + +2012-11-19 Kihong Kwon <kihong.kwon@samsung.com> + + Add PROXIMITY_EVENTS feature + https://bugs.webkit.org/show_bug.cgi?id=102658 + + Reviewed by Kentaro Hara. + + Add PROXIMITY_EVENTS feature to xcode project for JavaScriptCore. + + * Configurations/FeatureDefines.xcconfig: + +2012-11-18 Dan Bernstein <mitz@apple.com> + + Try to fix the DFG build after r135099. + + * dfg/DFGCommon.h: + (JSC::DFG::shouldShowDisassembly): + +2012-11-18 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, build fix for !ENABLE(DFG_JIT). + + * dfg/DFGCommon.h: + (JSC::DFG::shouldShowDisassembly): + (DFG): + +2012-11-18 Filip Pizlo <fpizlo@apple.com> + + JSC should have more logging in structure-related code + https://bugs.webkit.org/show_bug.cgi?id=102630 + + Reviewed by Simon Fraser. + + - JSValue::description() now tells you if something is a structure, and if so, + what kind of structure it is. + + - Jettisoning logic now tells you why things are being jettisoned. + + - It's now possible to turn off GC-triggered jettisoning entirely. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::reoptimize): + (JSC::ProgramCodeBlock::jettison): + (JSC::EvalCodeBlock::jettison): + (JSC::FunctionCodeBlock::jettison): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan): + * runtime/JSValue.cpp: + (JSC::JSValue::description): + * runtime/Options.h: + (JSC): + +2012-11-18 Filip Pizlo <fpizlo@apple.com> + + DFG constant folding phase should say 'changed = true' whenever it changes the graph + https://bugs.webkit.org/show_bug.cgi?id=102550 + + Rubber stamped by Mark Hahnenberg. + + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + +2012-11-17 Elliott Sprehn <esprehn@chromium.org> + + Expose JSObject removeDirect and PrivateName to WebCore + https://bugs.webkit.org/show_bug.cgi?id=102546 + + Reviewed by Geoffrey Garen. + + Export removeDirect for use in WebCore so JSDependentRetained works. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-11-16 Filip Pizlo <fpizlo@apple.com> + + Given a PutById or GetById with a proven structure, the DFG should be able to emit a PutByOffset or GetByOffset instead + https://bugs.webkit.org/show_bug.cgi?id=102327 + + Reviewed by Mark Hahnenberg. + + If the profiler tells us that a GetById or PutById may be polymorphic but our + control flow analysis proves that it isn't, we should trust the control flow + analysis over the profiler. This arises in cases where GetById or PutById were + inlined: the inlined function may have been called from other places that led + to polymorphism, but in the current inlined context, there is no polymorphism. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * bytecode/GetByIdStatus.cpp: + (JSC::GetByIdStatus::computeFor): + (JSC): + * bytecode/GetByIdStatus.h: + (JSC::GetByIdStatus::GetByIdStatus): + (GetByIdStatus): + * bytecode/PutByIdStatus.cpp: + (JSC::PutByIdStatus::computeFor): + (JSC): + * bytecode/PutByIdStatus.h: + (JSC): + (JSC::PutByIdStatus::PutByIdStatus): + (PutByIdStatus): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::bestProvenStructure): + (AbstractValue): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck): + (ConstantFoldingPhase): + * dfg/DFGNode.h: + (JSC::DFG::Node::convertToGetByOffset): + (Node): + (JSC::DFG::Node::convertToPutByOffset): + (JSC::DFG::Node::hasStorageResult): + * runtime/JSGlobalObject.h: + (JSC::Structure::prototypeChain): + (JSC): + (JSC::Structure::isValid): + * runtime/Operations.h: + (JSC::isPrototypeChainNormalized): + (JSC): + * runtime/Structure.h: + (Structure): + (JSC::Structure::transitionDidInvolveSpecificValue): + +2012-11-16 Tony Chang <tony@chromium.org> + + Remove ENABLE_CSS_HIERARCHIES since it's no longer in use + https://bugs.webkit.org/show_bug.cgi?id=102554 + + Reviewed by Andreas Kling. + + As mentioned in https://bugs.webkit.org/show_bug.cgi?id=79939#c41 , + we're going to revist this feature once additional vendor support is + achieved. + + * Configurations/FeatureDefines.xcconfig: + +2012-11-16 Patrick Gansterer <paroga@webkit.org> + + Build fix for WinCE after r133688. + + Use numeric_limits<uint32_t>::max() instead of UINT32_MAX. + + * runtime/CodeCache.h: + (JSC::CacheMap::CacheMap): + +2012-11-15 Filip Pizlo <fpizlo@apple.com> + + ClassInfo.h should have correct indentation. + + Rubber stamped by Mark Hahnenberg. + + ClassInfo.h had some true creativity in its use of whitespace. Some things within + the namespace were indented four spaces and others where not. One #define had its + contents indented four spaces, while another didn't. I applied the following rule: + + - Non-macro things in the namespace should not be indented (that's our current + accepted practice). + + - Macros should never be indented but if they are multi-line then their subsequent + bodies should be indented four spaces. I believe that is consistent with what we + do elsewhere. + + * runtime/ClassInfo.h: + (JSC): + (MethodTable): + (ClassInfo): + (JSC::ClassInfo::propHashTable): + (JSC::ClassInfo::isSubClassOf): + (JSC::ClassInfo::hasStaticProperties): + +2012-11-15 Filip Pizlo <fpizlo@apple.com> + + DFG should copy propagate trivially no-op ConvertThis + https://bugs.webkit.org/show_bug.cgi?id=102445 + + Reviewed by Oliver Hunt. + + Copy propagation is always a good thing, since it reveals must-alias relationships + to the CFA and CSE. This accomplishes copy propagation for ConvertThis by first + converting it to an Identity node (which is done by the constant folder since it + has access to CFA results) and then performing substitution of references to + Identity with references to Identity's child in the CSE. + + I'm not aiming for a big speed-up here; I just think that this will be useful for + the work on https://bugs.webkit.org/show_bug.cgi?id=102327. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-11-15 Filip Pizlo <fpizlo@apple.com> + + CallData.h should have correct indentation. + + Rubber stamped by Mark Hahneberg. + + * runtime/CallData.h: + (JSC): + +2012-11-15 Filip Pizlo <fpizlo@apple.com> + + Remove methodCallDummy since it is not used anymore. + + Rubber stamped by Mark Hahnenberg. + + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + (JSC): + (JSC::JSGlobalObject::visitChildren): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + +2012-11-14 Filip Pizlo <fpizlo@apple.com> + + Structure should be able to easily tell if the prototype chain might intercept a store + https://bugs.webkit.org/show_bug.cgi?id=102326 + + Reviewed by Geoffrey Garen. + + This improves our ability to reason about the correctness of the more optimized + prototype chain walk in JSObject::put(), while also making it straight forward to + check if the prototype chain will do strange things to a property store by just + looking at the structure. + + * runtime/JSObject.cpp: + (JSC::JSObject::put): + * runtime/Structure.cpp: + (JSC::Structure::prototypeChainMayInterceptStoreTo): + (JSC): + * runtime/Structure.h: + (Structure): + +2012-11-15 Thiago Marcos P. Santos <thiago.santos@intel.com> + + [CMake] Do not regenerate LLIntAssembly.h on every incremental build + https://bugs.webkit.org/show_bug.cgi?id=102248 + + Reviewed by Kenneth Rohde Christiansen. + + Update LLIntAssembly.h's mtime after running asm.rb to make the build + system dependency tracking consistent. + + * CMakeLists.txt: + +2012-11-15 Thiago Marcos P. Santos <thiago.santos@intel.com> + + Fix compiler warnings about signed/unsigned comparison on i386 + https://bugs.webkit.org/show_bug.cgi?id=102249 + + Reviewed by Kenneth Rohde Christiansen. + + Add casting to unsigned to shut up gcc warnings. Build was broken on + JSVALUE32_64 ports compiling with -Werror. + + * llint/LLIntData.cpp: + (JSC::LLInt::Data::performAssertions): + +2012-11-14 Brent Fulgham <bfulgham@webkit.org> + + [Windows, WinCairo] Unreviewed build fix. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + Missed one of the exports that was part of the WebKit2.def. + +2012-11-14 Brent Fulgham <bfulgham@webkit.org> + + [Windows, WinCairo] Correct build failure. + https://bugs.webkit.org/show_bug.cgi?id=102302 + + WebCore symbols were mistakenly added to the JavaScriptCore + library definition file. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: Remove + WebCore symbols that were incorrectly added to the export file. + +2012-11-14 Mark Lam <mark.lam@apple.com> + + Change JSEventListener::m_jsFunction to be a weak ref. + https://bugs.webkit.org/show_bug.cgi?id=101989. + + Reviewed by Geoffrey Garen. + + Added infrastructure for scanning weak ref slots. + + * heap/SlotVisitor.cpp: Added #include "SlotVisitorInlines.h". + * heap/SlotVisitor.h: + (SlotVisitor): Added SlotVisitor::appendUnbarrieredWeak(). + * heap/SlotVisitorInlines.h: Added #include "Weak.h". + (JSC::SlotVisitor::appendUnbarrieredWeak): Added. + * heap/Weak.h: + (JSC::operator==): Added operator==() for Weak. + * runtime/JSCell.h: Removed #include "SlotVisitorInlines.h". + * runtime/JSObject.h: Added #include "SlotVisitorInlines.h". + +2012-11-14 Filip Pizlo <fpizlo@apple.com> + + Read-only properties created with putDirect() should tell the structure that there are read-only properties + https://bugs.webkit.org/show_bug.cgi?id=102292 + + Reviewed by Gavin Barraclough. + + This mostly affects things like function.length. + + * runtime/JSObject.h: + (JSC::JSObject::putDirectInternal): + +2012-11-13 Filip Pizlo <fpizlo@apple.com> + + Don't access Node& after adding nodes to the graph. + https://bugs.webkit.org/show_bug.cgi?id=102005 + + Reviewed by Oliver Hunt. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + +2012-11-14 Valery Ignatyev <valery.ignatyev@ispras.ru> + + Replace (typeof(x) != <"object", "undefined", ...>) with + !(typeof(x) == <"object",..>). Later is_object, is_<...> bytecode operation + will be used. + + https://bugs.webkit.org/show_bug.cgi?id=98893 + + Reviewed by Filip Pizlo. + + This eliminates expensive typeof implementation and + allows to use DFG optimizations, which doesn't support 'typeof'. + + * bytecompiler/NodesCodegen.cpp: + (JSC::BinaryOpNode::emitBytecode): + +2012-11-14 Peter Gal <galpeter@inf.u-szeged.hu> + + [Qt][ARM]REGRESSION(r133985): It broke the build + https://bugs.webkit.org/show_bug.cgi?id=101740 + + Reviewed by Csaba Osztrogonác. + + Changed the emitGenericContiguousPutByVal to accept the additional IndexingType argument. + This information was passed as a template parameter. + + * jit/JIT.h: + (JSC::JIT::emitInt32PutByVal): + (JSC::JIT::emitDoublePutByVal): + (JSC::JIT::emitContiguousPutByVal): + (JIT): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emitGenericContiguousPutByVal): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emitGenericContiguousPutByVal): + +2012-11-14 Peter Gal <galpeter@inf.u-szeged.hu> + + Fix the MIPS build after r134332 + https://bugs.webkit.org/show_bug.cgi?id=102227 + + Reviewed by Csaba Osztrogonác. + + Added missing methods for the MacroAssemblerMIPS, based on the MacroAssemblerARMv7. + + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::canJumpReplacePatchableBranchPtrWithPatch): + (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::startOfPatchableBranchPtrWithPatch): + (JSC::MacroAssemblerMIPS::revertJumpReplacementToPatchableBranchPtrWithPatch): + +2012-11-14 Peter Gal <galpeter@inf.u-szeged.hu> + + Fix the [-Wreturn-type] warning in JavaScriptCore/assembler/MacroAssemblerARM.h + https://bugs.webkit.org/show_bug.cgi?id=102206 + + Reviewed by Csaba Osztrogonác. + + Add a return value for the function to suppress the warning. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::startOfPatchableBranchPtrWithPatch): + +2012-11-14 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r134599. + http://trac.webkit.org/changeset/134599 + https://bugs.webkit.org/show_bug.cgi?id=102225 + + It broke the 32 bit EFL build (Requested by Ossy on #webkit). + + * jit/JITPropertyAccess.cpp: + * jit/JITPropertyAccess32_64.cpp: + (JSC): + (JSC::JIT::emitGenericContiguousPutByVal): + +2012-11-14 Balazs Kilvady <kilvadyb@homejinni.com> + + [Qt][ARM]REGRESSION(r133985): It broke the build + https://bugs.webkit.org/show_bug.cgi?id=101740 + + Reviewed by Csaba Osztrogonác. + + Template function body moved to fix VALUE_PROFILER disabled case. + + * jit/JITPropertyAccess.cpp: + (JSC): + (JSC::JIT::emitGenericContiguousPutByVal): + * jit/JITPropertyAccess32_64.cpp: + +2012-11-13 Filip Pizlo <fpizlo@apple.com> + + DFG CreateThis should be able to statically account for the structure of the object it creates, if profiling indicates that this structure is always the same + https://bugs.webkit.org/show_bug.cgi?id=102017 + + Reviewed by Geoffrey Garen. + + This adds a watchpoint in JSFunction on the cached inheritor ID. It also changes + NewObject to take a structure as an operand (previously it implicitly used the owning + global object's empty object structure). Any GetCallee where the callee is predictable + is turned into a CheckFunction + WeakJSConstant, and any CreateThis on a WeakJSConstant + where the inheritor ID watchpoint is still valid is turned into an InheritorIDWatchpoint + followed by a NewObject. NewObject already accounts for the structure it uses for object + creation in the CFA. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::checkFunctionElimination): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasFunction): + (JSC::DFG::Node::function): + (JSC::DFG::Node::hasStructure): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * runtime/Executable.h: + (JSC::JSFunction::JSFunction): + * runtime/JSBoundFunction.cpp: + (JSC): + * runtime/JSFunction.cpp: + (JSC::JSFunction::JSFunction): + (JSC::JSFunction::put): + (JSC::JSFunction::defineOwnProperty): + * runtime/JSFunction.h: + (JSC::JSFunction::tryGetKnownInheritorID): + (JSFunction): + (JSC::JSFunction::addInheritorIDWatchpoint): + +2012-11-13 Filip Pizlo <fpizlo@apple.com> + + JSFunction and its descendants should be destructible + https://bugs.webkit.org/show_bug.cgi?id=102062 + + Reviewed by Mark Hahnenberg. + + This will make it easy to place an InlineWatchpointSet inside JSFunction. In the + future, we could make JSFunction non-destructible again by making a version of + WatchpointSet that is entirely GC'd, but this seems like overkill for now. + + This is performance-neutral. + + * runtime/JSBoundFunction.cpp: + (JSC::JSBoundFunction::destroy): + (JSC): + * runtime/JSBoundFunction.h: + (JSBoundFunction): + * runtime/JSFunction.cpp: + (JSC): + (JSC::JSFunction::destroy): + * runtime/JSFunction.h: + (JSFunction): + +2012-11-13 Cosmin Truta <ctruta@rim.com> + + Uninitialized fields in class JSLock + https://bugs.webkit.org/show_bug.cgi?id=101695 + + Reviewed by Mark Hahnenberg. + + Initialize JSLock::m_ownerThread and JSLock::m_lockDropDepth. + + * runtime/JSLock.cpp: + (JSC::JSLock::JSLock): + +2012-11-13 Peter Gal <galpeter@inf.u-szeged.hu> + + Fix the ARM traditional build after r134332 + https://bugs.webkit.org/show_bug.cgi?id=102044 + + Reviewed by Zoltan Herczeg. + + Added missing methods for the MacroAssemblerARM, based on the MacroAssemblerARMv7. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::canJumpReplacePatchableBranchPtrWithPatch): + (MacroAssemblerARM): + (JSC::MacroAssemblerARM::startOfPatchableBranchPtrWithPatch): + (JSC::MacroAssemblerARM::revertJumpReplacementToPatchableBranchPtrWithPatch): + +2012-11-12 Filip Pizlo <fpizlo@apple.com> + + op_get_callee should have value profiling + https://bugs.webkit.org/show_bug.cgi?id=102047 + + Reviewed by Sam Weinig. + + This will allow us to detect if the callee is always the same, which is probably + the common case for a lot of constructors. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_get_callee): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_get_callee): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-11-12 Filip Pizlo <fpizlo@apple.com> + + The act of getting the callee during 'this' construction should be explicit in bytecode + https://bugs.webkit.org/show_bug.cgi?id=102016 + + Reviewed by Michael Saboff. + + This is mostly a rollout of http://trac.webkit.org/changeset/116673, but also includes + changes to have create_this use the result of get_callee. + + No performance or behavioral impact. This is just meant to allow us to profile + get_callee in the future. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + * jit/JIT.h: + (JIT): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_get_callee): + (JSC): + (JSC::JIT::emit_op_create_this): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_get_callee): + (JSC): + (JSC::JIT::emit_op_create_this): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + +2012-11-12 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, fix ARMv7 build. + + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::startOfPatchableBranchPtrWithPatch): + (JSC::MacroAssemblerARMv7::revertJumpReplacementToPatchableBranchPtrWithPatch): + +2012-11-12 Filip Pizlo <fpizlo@apple.com> + + Patching of jumps to stubs should use jump replacement rather than branch destination overwrite + https://bugs.webkit.org/show_bug.cgi?id=101909 + + Reviewed by Geoffrey Garen. + + This saves a few instructions in inline cases, on those architectures where it is + easy to figure out where to put the jump replacement. Sub-1% speed-up across the + board. + + * assembler/MacroAssemblerARMv7.h: + (MacroAssemblerARMv7): + (JSC::MacroAssemblerARMv7::canJumpReplacePatchableBranchPtrWithPatch): + (JSC::MacroAssemblerARMv7::startOfPatchableBranchPtrWithPatch): + (JSC::MacroAssemblerARMv7::revertJumpReplacementToPatchableBranchPtrWithPatch): + * assembler/MacroAssemblerX86.h: + (JSC::MacroAssemblerX86::canJumpReplacePatchableBranchPtrWithPatch): + (MacroAssemblerX86): + (JSC::MacroAssemblerX86::startOfPatchableBranchPtrWithPatch): + (JSC::MacroAssemblerX86::revertJumpReplacementToPatchableBranchPtrWithPatch): + * assembler/MacroAssemblerX86_64.h: + (JSC::MacroAssemblerX86_64::canJumpReplacePatchableBranchPtrWithPatch): + (MacroAssemblerX86_64): + (JSC::MacroAssemblerX86_64::startOfPatchableBranchPtrWithPatch): + (JSC::MacroAssemblerX86_64::revertJumpReplacementToPatchableBranchPtrWithPatch): + * assembler/RepatchBuffer.h: + (JSC::RepatchBuffer::startOfPatchableBranchPtrWithPatch): + (RepatchBuffer): + (JSC::RepatchBuffer::replaceWithJump): + (JSC::RepatchBuffer::revertJumpReplacementToPatchableBranchPtrWithPatch): + * assembler/X86Assembler.h: + (X86Assembler): + (JSC::X86Assembler::revertJumpTo_movq_i64r): + (JSC::X86Assembler::revertJumpTo_cmpl_im_force32): + (X86InstructionFormatter): + * bytecode/StructureStubInfo.h: + * dfg/DFGRepatch.cpp: + (JSC::DFG::replaceWithJump): + (DFG): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::tryBuildGetByIDProtoList): + (JSC::DFG::tryCachePutByID): + (JSC::DFG::dfgResetGetByID): + (JSC::DFG::dfgResetPutByID): + +2012-11-11 Filip Pizlo <fpizlo@apple.com> + + DFG ArithMul overflow check elimination is too aggressive + https://bugs.webkit.org/show_bug.cgi?id=101871 + + Reviewed by Oliver Hunt. + + The code was ignoring the fact that ((a * b) | 0) == (((a | 0) * (b | 0)) | 0) + only holds if a * b < 2^53. So, I changed it to only enable the optimization + when a < 2^22 and b is an int32 (and vice versa), using a super trivial peephole + analysis to prove the inequality. I considered writing an epic forward flow + formulation that tracks the ranges of integer values but then I thought better + of it. + + This also rewires the ArithMul integer speculation logic. Previously, we would + assume that an ArithMul was only UsedAsNumber if it escaped, and separately we + would decide whether to speculate integer based on a proof of the <2^22 + inequality. Now, we treat the double rounding behavior of ArithMul as if the + result was UsedAsNumber even if it did not escape. Then we try to prove that + double rounding cannot happen by attemping to prove that a < 2^22. This then + feeds back into the decision of whether or not to speculate integer (if we fail + to prove a < 2^22 then we're UsedAsNumber, and if we're also MayOverflow then + that forces double speculation). + + No performance impact. It just fixes a bug. + + * dfg/DFGGraph.h: + (JSC::DFG::Graph::mulShouldSpeculateInteger): + * dfg/DFGPredictionPropagationPhase.cpp: + (PredictionPropagationPhase): + (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoForConstant): + (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoNonRecursive): + (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwo): + (JSC::DFG::PredictionPropagationPhase::propagate): + +2012-11-11 Filip Pizlo <fpizlo@apple.com> + + DFG should not emit function checks if we've already proved that the operand is that exact function + https://bugs.webkit.org/show_bug.cgi?id=101885 + + Reviewed by Oliver Hunt. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::filterByValue): + (AbstractValue): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + +2012-11-12 Kentaro Hara <haraken@chromium.org> + + [V8][JSC] ScriptProfileNode::callUID needs not to be [Custom] + https://bugs.webkit.org/show_bug.cgi?id=101892 + + Reviewed by Adam Barth. + + Added callUID(), which enables us to kill custom bindings for ScriptProfileNode::callUID. + + * profiler/ProfileNode.h: + (JSC::ProfileNode::callUID): + +2012-11-12 Carlos Garcia Campos <cgarcia@igalia.com> + + Unreviewed. Fix make distcheck. + + * GNUmakefile.list.am: Add missing header. + +2012-11-11 Michael Pruett <michael@68k.org> + + Fix assertion failure in JSObject::tryGetIndexQuickly() + https://bugs.webkit.org/show_bug.cgi?id=101869 + + Reviewed by Filip Pizlo. + + Currently JSObject::tryGetIndexQuickly() triggers an assertion + failure when the object has an undecided indexing type. This + case should be treated the same as a blank indexing type. + + * runtime/JSObject.h: + (JSC::JSObject::tryGetIndexQuickly): + +2012-11-11 Filip Pizlo <fpizlo@apple.com> + + DFG register allocation should be greedy rather than round-robin + https://bugs.webkit.org/show_bug.cgi?id=101870 + + Reviewed by Geoffrey Garen. + + This simplifies the code, reduces some code duplication, and shows some slight + performance improvements in a few places, likely due to the fact that lower-numered + registers also typically have smaller encodings. + + * dfg/DFGRegisterBank.h: + (JSC::DFG::RegisterBank::RegisterBank): + (JSC::DFG::RegisterBank::tryAllocate): + (JSC::DFG::RegisterBank::allocate): + (JSC::DFG::RegisterBank::allocateInternal): + (RegisterBank): + +2012-11-11 Kenichi Ishibashi <bashi@chromium.org> + + WTFString::utf8() should have a mode of conversion to use replacement character + https://bugs.webkit.org/show_bug.cgi?id=101678 + + Reviewed by Alexey Proskuryakov. + + Follow the change on String::utf8() + + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::encode): Pass String::StrictConversion instead of true to String::utf8(). + +2012-11-10 Filip Pizlo <fpizlo@apple.com> + + DFG should optimize out the NaN check on loads from double arrays if the array prototype chain is having a great time + https://bugs.webkit.org/show_bug.cgi?id=101718 + + Reviewed by Geoffrey Garen. + + If we're reading from a JSArray in double mode, where the array's structure is + primordial (all aspects of the structure are unchanged except for indexing type), + and the result of the load is used in arithmetic that is known to not distinguish + between NaN and undefined, then we should not emit a NaN check. Looks like a 5% + win on navier-stokes. + + Also fixed an OpInfo initialization goof for String ops that was revealed by this + change. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::arraySpeculationToString): + * dfg/DFGArrayMode.h: + (JSC::DFG::ArrayMode::isSaneChain): + (ArrayMode): + (JSC::DFG::ArrayMode::isInBounds): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleIntrinsic): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGNodeFlags.cpp: + (JSC::DFG::nodeFlagsAsString): + * dfg/DFGNodeFlags.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::arrayPrototypeChainIsSane): + (JSC): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + +2012-11-10 Filip Pizlo <fpizlo@apple.com> + + DFG constant folding and CFG simplification should be smart enough to know that if a logical op's operand is proven to have a non-masquerading structure then it always evaluates to true + https://bugs.webkit.org/show_bug.cgi?id=101511 + + Reviewed by Geoffrey Garen. + + This is the second attempt at this patch, which fixes the !"" case. + + To make life easier, this moves BranchDirection into BasicBlock so that after + running the CFA, we always know, for each block, what direction the CFA + proved. CFG simplification now both uses and preserves cfaBranchDirection in + its transformations. + + Also made both LogicalNot and Branch check whether the operand is a known cell + with a known structure, and if so, made them do the appropriate folding. + + 5% speed-up on V8/raytrace because it makes raytrace's own null checks + evaporate (i.e. idioms like 'if (!x) throw "unhappiness"') thanks to the fact + that we were already doing structure check hoisting. + + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::endBasicBlock): + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::mergeToSuccessors): + * dfg/DFGAbstractState.h: + (AbstractState): + * dfg/DFGBasicBlock.h: + (JSC::DFG::BasicBlock::BasicBlock): + (BasicBlock): + * dfg/DFGBranchDirection.h: Added. + (DFG): + (JSC::DFG::branchDirectionToString): + (JSC::DFG::isKnownDirection): + (JSC::DFG::branchCondition): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + +2012-11-10 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r133971. + http://trac.webkit.org/changeset/133971 + https://bugs.webkit.org/show_bug.cgi?id=101839 + + Causes WebProcess to hang at 100% on www.apple.com (Requested + by kling on #webkit). + + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::endBasicBlock): + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::mergeToSuccessors): + * dfg/DFGAbstractState.h: + (JSC::DFG::AbstractState::branchDirectionToString): + (AbstractState): + * dfg/DFGBasicBlock.h: + (JSC::DFG::BasicBlock::BasicBlock): + (BasicBlock): + * dfg/DFGBranchDirection.h: Removed. + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + +2012-11-09 Filip Pizlo <fpizlo@apple.com> + + If the DFG ArrayMode says that an access is on an OriginalArray, then the checks should always enforce this + https://bugs.webkit.org/show_bug.cgi?id=101720 + + Reviewed by Mark Hahnenberg. + + Previously, "original" arrays was just a hint that we could find the structure + of the array if we needed to even if the array profile didn't have it due to + polymorphism. Now, "original" arrays are a property that is actually checked: + if an array access has ArrayMode::arrayClass() == Array::OriginalArray, then we + can be sure that the code performing the access is dealing with not just a + JSArray, but a JSArray that has no named properties, no indexed accessors, and + the ArrayPrototype as its prototype. This will be useful for optimizations that + are being done as part of https://bugs.webkit.org/show_bug.cgi?id=101720. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::originalArrayStructure): + (DFG): + (JSC::DFG::ArrayMode::alreadyChecked): + * dfg/DFGArrayMode.h: + (JSC): + (DFG): + (JSC::DFG::ArrayMode::withProfile): + (ArrayMode): + (JSC::DFG::ArrayMode::benefitsFromOriginalArray): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::checkArray): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::compileGetByValOnString): + (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): + (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): + (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): + +2012-11-09 Filip Pizlo <fpizlo@apple.com> + + Fix indentation of BooleanPrototype.h + + Rubber stamped by Mark Hahnenberg. + + * runtime/BooleanPrototype.h: + +2012-11-09 Filip Pizlo <fpizlo@apple.com> + + Fix indentation of BooleanObject.h + + Rubber stamped by Mark Hahnenberg. + + * runtime/BooleanObject.h: + +2012-11-09 Filip Pizlo <fpizlo@apple.com> + + Fix indentation of BooleanConstructor.h + + Rubber stamped by Mark Hahnenberg. + + * runtime/BooleanConstructor.h: + +2012-11-09 Filip Pizlo <fpizlo@apple.com> + + Fix indentation of BatchedTransitionOptimizer.h + + Rubber stamped by Mark Hahnenberg. + + * runtime/BatchedTransitionOptimizer.h: + +2012-11-09 Oliver Hunt <oliver@apple.com> + + So Thingy probably isn't the best name for a class, so + renamed to CacheMap. + + RS=Geoff + + * runtime/CodeCache.h: + (JSC::CacheMap::CacheMap): + +2012-11-09 Filip Pizlo <fpizlo@apple.com> + + ArrayPrototype should start out with a blank indexing type + https://bugs.webkit.org/show_bug.cgi?id=101719 + + Reviewed by Mark Hahnenberg. + + This allows us to track if the array prototype ever ends up with indexed + properties. + + * runtime/ArrayPrototype.cpp: + (JSC::ArrayPrototype::create): + (JSC::ArrayPrototype::ArrayPrototype): + * runtime/ArrayPrototype.h: + (ArrayPrototype): + (JSC::ArrayPrototype::createStructure): + +2012-11-08 Mark Hahnenberg <mhahnenberg@apple.com> + + MarkStackArray should use the BlockAllocator instead of the MarkStackSegmentAllocator + https://bugs.webkit.org/show_bug.cgi?id=101642 + + Reviewed by Filip Pizlo. + + MarkStackSegmentAllocator is like a miniature version of the BlockAllocator. Now that the BlockAllocator has support + for a variety of block sizes, we should get rid of the MarkStackSegmentAllocator in favor of the BlockAllocator. + + * heap/BlockAllocator.h: Add new specializations of regionSetFor for the new MarkStackSegments. + (JSC): + (JSC::MarkStackSegment): + * heap/GCThreadSharedData.cpp: + (JSC::GCThreadSharedData::GCThreadSharedData): + (JSC::GCThreadSharedData::reset): + * heap/GCThreadSharedData.h: + (GCThreadSharedData): + * heap/MarkStack.cpp: + (JSC::MarkStackArray::MarkStackArray): We now have a doubly linked list of MarkStackSegments, so we need to refactor + all the places that used the old custom tail/previous logic. + (JSC::MarkStackArray::~MarkStackArray): + (JSC::MarkStackArray::expand): + (JSC::MarkStackArray::refill): + (JSC::MarkStackArray::donateSomeCellsTo): Refactor to use the new linked list. + (JSC::MarkStackArray::stealSomeCellsFrom): Ditto. + * heap/MarkStack.h: + (JSC): + (MarkStackSegment): + (JSC::MarkStackSegment::MarkStackSegment): + (JSC::MarkStackSegment::sizeFromCapacity): + (MarkStackArray): + * heap/MarkStackInlines.h: + (JSC::MarkStackSegment::create): + (JSC): + (JSC::MarkStackArray::postIncTop): + (JSC::MarkStackArray::preDecTop): + (JSC::MarkStackArray::setTopForFullSegment): + (JSC::MarkStackArray::setTopForEmptySegment): + (JSC::MarkStackArray::top): + (JSC::MarkStackArray::validatePrevious): + (JSC::MarkStackArray::append): + (JSC::MarkStackArray::removeLast): + (JSC::MarkStackArray::isEmpty): + (JSC::MarkStackArray::size): + * heap/SlotVisitor.cpp: + (JSC::SlotVisitor::SlotVisitor): + +2012-11-09 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + [Qt] r133953 broke the ARM_TRADITIONAL build + https://bugs.webkit.org/show_bug.cgi?id=101706 + + Reviewed by Csaba Osztrogonác. + + Fix for both hardfp and softfp. + + * dfg/DFGCCallHelpers.h: + (CCallHelpers): + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + +2012-11-09 Sheriff Bot <webkit.review.bot@gmail.com> + + Unreviewed, rolling out r134051. + http://trac.webkit.org/changeset/134051 + https://bugs.webkit.org/show_bug.cgi?id=101757 + + It didn't fix the build (Requested by Ossy on #webkit). + + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + +2012-11-09 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + [Qt] r133953 broke the ARM_TRADITIONAL build + https://bugs.webkit.org/show_bug.cgi?id=101706 + + Reviewed by Csaba Osztrogonác. + + Fix the ARM_TRADITIONAL build after r133953 + + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + (CCallHelpers): + +2012-11-09 Csaba Osztrogonác <ossy@webkit.org> + + [Qt] Fix the LLINT build from ARMv7 platform + https://bugs.webkit.org/show_bug.cgi?id=101712 + + Reviewed by Simon Hausmann. + + Enable generating of LLIntAssembly.h on ARM platforms. + + * DerivedSources.pri: + * JavaScriptCore.pro: + +2012-11-08 Filip Pizlo <fpizlo@apple.com> + + ArrayPrototype.h should have correct indentation + + Rubber stamped by Sam Weinig. + + * runtime/ArrayPrototype.h: + +2012-11-08 Mark Lam <mark.lam@apple.com> + + Renamed ...InlineMethods.h files to ...Inlines.h. + https://bugs.webkit.org/show_bug.cgi?id=101145. + + Reviewed by Geoffrey Garen. + + This is only a refactoring effort to rename the files. There are no + functionality changes. + + * API/JSObjectRef.cpp: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/CodeBlock.cpp: + * dfg/DFGOperations.cpp: + * heap/ConservativeRoots.cpp: + * heap/CopiedBlock.h: + * heap/CopiedSpace.cpp: + * heap/CopiedSpaceInlineMethods.h: Removed. + * heap/CopiedSpaceInlines.h: Copied from Source/JavaScriptCore/heap/CopiedSpaceInlineMethods.h. + * heap/CopyVisitor.cpp: + * heap/CopyVisitorInlineMethods.h: Removed. + * heap/CopyVisitorInlines.h: Copied from Source/JavaScriptCore/heap/CopyVisitorInlineMethods.h. + * heap/GCThread.cpp: + * heap/GCThreadSharedData.cpp: + * heap/HandleStack.cpp: + * heap/Heap.cpp: + * heap/HeapRootVisitor.h: + * heap/MarkStack.cpp: + * heap/MarkStackInlineMethods.h: Removed. + * heap/MarkStackInlines.h: Copied from Source/JavaScriptCore/heap/MarkStackInlineMethods.h. + * heap/SlotVisitor.cpp: + * heap/SlotVisitor.h: + * heap/SlotVisitorInlineMethods.h: Removed. + * heap/SlotVisitorInlines.h: Copied from Source/JavaScriptCore/heap/SlotVisitorInlineMethods.h. + * jit/HostCallReturnValue.cpp: + * jit/JIT.cpp: + * jit/JITArithmetic.cpp: + * jit/JITArithmetic32_64.cpp: + * jit/JITCall.cpp: + * jit/JITCall32_64.cpp: + * jit/JITInlineMethods.h: Removed. + * jit/JITInlines.h: Copied from Source/JavaScriptCore/jit/JITInlineMethods.h. + * jit/JITOpcodes.cpp: + * jit/JITOpcodes32_64.cpp: + * jit/JITPropertyAccess.cpp: + * jit/JITPropertyAccess32_64.cpp: + * jsc.cpp: + * runtime/ArrayConstructor.cpp: + * runtime/ArrayPrototype.cpp: + * runtime/ButterflyInlineMethods.h: Removed. + * runtime/ButterflyInlines.h: Copied from Source/JavaScriptCore/runtime/ButterflyInlineMethods.h. + * runtime/IndexingHeaderInlineMethods.h: Removed. + * runtime/IndexingHeaderInlines.h: Copied from Source/JavaScriptCore/runtime/IndexingHeaderInlineMethods.h. + * runtime/JSActivation.h: + * runtime/JSArray.cpp: + * runtime/JSArray.h: + * runtime/JSCell.h: + * runtime/JSObject.cpp: + * runtime/JSValueInlineMethods.h: Removed. + * runtime/JSValueInlines.h: Copied from Source/JavaScriptCore/runtime/JSValueInlineMethods.h. + * runtime/LiteralParser.cpp: + * runtime/ObjectConstructor.cpp: + * runtime/Operations.h: + * runtime/RegExpMatchesArray.cpp: + * runtime/RegExpObject.cpp: + * runtime/StringPrototype.cpp: + +2012-11-08 Filip Pizlo <fpizlo@apple.com> + + ArrayConstructor.h should have correct indentation + + Rubber stamped by Sam Weinig. + + * runtime/ArrayConstructor.h: + +2012-11-08 Filip Pizlo <fpizlo@apple.com> + + DFG should know that int == null is always false + https://bugs.webkit.org/show_bug.cgi?id=101665 + + Reviewed by Oliver Hunt. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + +2012-11-08 Filip Pizlo <fpizlo@apple.com> + + Arguments.h should have correct indentation + + Rubber stamped by Sam Weinig. + + * runtime/Arguments.h: + +2012-11-08 Filip Pizlo <fpizlo@apple.com> + + It should be possible to JIT compile get_by_vals and put_by_vals even if the DFG is disabled. + + Reviewed by Oliver Hunt. + + * jit/JITInlineMethods.h: + (JSC::JIT::chooseArrayMode): + +2012-11-08 Filip Pizlo <fpizlo@apple.com> + + op_call should have LLInt call link info even if the DFG is disabled + https://bugs.webkit.org/show_bug.cgi?id=101672 + + Reviewed by Oliver Hunt. + + Get rid of the evil uses of fall-through. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + +2012-11-08 Oliver Hunt <oliver@apple.com> + + Improve effectiveness of function-level caching + https://bugs.webkit.org/show_bug.cgi?id=101667 + + Reviewed by Filip Pizlo. + + Added a random-eviction based cache for unlinked functions, and switch + UnlinkedFunctionExecutable's code references to Weak<>, thereby letting + us remove the explicit UnlinkedFunctionExecutable::clearCode() calls that + were being triggered by GC. + + Refactored the random eviction part of the CodeCache into a separate data + structure so that I didn't have to duplicate the code again, and then used + that for the new function cache. + + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::UnlinkedFunctionExecutable::visitChildren): + (JSC::UnlinkedFunctionExecutable::codeBlockFor): + * bytecode/UnlinkedCodeBlock.h: + (JSC::UnlinkedFunctionExecutable::clearCodeForRecompilation): + (UnlinkedFunctionExecutable): + * debugger/Debugger.cpp: + * runtime/CodeCache.cpp: + (JSC::CodeCache::getCodeBlock): + (JSC::CodeCache::generateFunctionCodeBlock): + (JSC::CodeCache::getFunctionExecutableFromGlobalCode): + (JSC::CodeCache::usedFunctionCode): + (JSC): + * runtime/Executable.cpp: + (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilationIfNotCompiling): + (JSC::FunctionExecutable::clearCode): + * runtime/Executable.h: + (FunctionExecutable): + +2012-11-07 Filip Pizlo <fpizlo@apple.com> + + DFG constant folding and CFG simplification should be smart enough to know that if a logical op's operand is proven to have a non-masquerading structure then it always evaluates to true + https://bugs.webkit.org/show_bug.cgi?id=101511 + + Reviewed by Oliver Hunt. + + To make life easier, this moves BranchDirection into BasicBlock so that after + running the CFA, we always know, for each block, what direction the CFA + proved. CFG simplification now both uses and preserves cfaBranchDirection in + its transformations. + + Also made both LogicalNot and Branch check whether the operand is a known cell + with a known structure, and if so, made them do the appropriate folding. + + 5% speed-up on V8/raytrace because it makes raytrace's own null checks + evaporate (i.e. idioms like 'if (!x) throw "unhappiness"') thanks to the fact + that we were already doing structure check hoisting. + + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::endBasicBlock): + (JSC::DFG::AbstractState::execute): + (JSC::DFG::AbstractState::mergeToSuccessors): + * dfg/DFGAbstractState.h: + (AbstractState): + * dfg/DFGBasicBlock.h: + (JSC::DFG::BasicBlock::BasicBlock): + (BasicBlock): + * dfg/DFGBranchDirection.h: Added. + (DFG): + (JSC::DFG::branchDirectionToString): + (JSC::DFG::isKnownDirection): + (JSC::DFG::branchCondition): + * dfg/DFGCFGSimplificationPhase.cpp: + (JSC::DFG::CFGSimplificationPhase::run): + (JSC::DFG::CFGSimplificationPhase::mergeBlocks): + +2012-11-08 Christophe Dumez <christophe.dumez@intel.com> + + [JSC] HTML extensions to String.prototype should escape " as " in argument values + https://bugs.webkit.org/show_bug.cgi?id=90667 + + Reviewed by Benjamin Poulain. + + Escape quotation mark as " in argument values to: + - String.prototype.anchor(name) + - String.prototype.fontcolor(color) + - String.prototype.fontsize(size) + - String.prototype.link(href) + + This behavior matches Chromium/V8 and Firefox/Spidermonkey + implementations and is requited by: + http://mathias.html5.org/specs/javascript/#escapeattributevalue + + This also fixes a potential security risk (XSS vector). + + * runtime/StringPrototype.cpp: + (JSC::stringProtoFuncFontcolor): + (JSC::stringProtoFuncFontsize): + (JSC::stringProtoFuncAnchor): + (JSC::stringProtoFuncLink): + +2012-11-08 Anders Carlsson <andersca@apple.com> + + HeapStatistics::s_pauseTimeStarts and s_pauseTimeEnds should be Vectors + https://bugs.webkit.org/show_bug.cgi?id=101651 + + Reviewed by Andreas Kling. + + HeapStatistics uses Deques when Vectors would work just as good. + + * heap/HeapStatistics.cpp: + * heap/HeapStatistics.h: + (HeapStatistics): + +2012-11-07 Filip Pizlo <fpizlo@apple.com> + + DFG should not assume that something is a double just because it might be undefined + https://bugs.webkit.org/show_bug.cgi?id=101438 + + Reviewed by Oliver Hunt. + + This changes all non-bitop arithmetic to (a) statically expect that variables are + defined prior to use in arithmetic and (b) not fall off into double paths just + because a value may not be a number. This is accomplished with two new notions of + speculation: + + shouldSpeculateIntegerExpectingDefined: Should we speculate that the value is an + integer if we ignore undefined (i.e. SpecOther) predictions? + + shouldSpeculateIntegerForArithmetic: Should we speculate that the value is an + integer if we ignore non-numeric predictions? + + This is a ~2x speed-up on programs that seem to our prediction propagator to have + paths in which otherwise numeric variables are undefined. + + * bytecode/SpeculatedType.h: + (JSC::isInt32SpeculationForArithmetic): + (JSC): + (JSC::isInt32SpeculationExpectingDefined): + (JSC::isDoubleSpeculationForArithmetic): + (JSC::isNumberSpeculationExpectingDefined): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::addShouldSpeculateInteger): + (JSC::DFG::Graph::mulShouldSpeculateInteger): + (JSC::DFG::Graph::negateShouldSpeculateInteger): + (JSC::DFG::Graph::addImmediateShouldSpeculateInteger): + (JSC::DFG::Graph::mulImmediateShouldSpeculateInteger): + * dfg/DFGNode.h: + (JSC::DFG::Node::shouldSpeculateIntegerForArithmetic): + (Node): + (JSC::DFG::Node::shouldSpeculateIntegerExpectingDefined): + (JSC::DFG::Node::shouldSpeculateDoubleForArithmetic): + (JSC::DFG::Node::shouldSpeculateNumberExpectingDefined): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileAdd): + (JSC::DFG::SpeculativeJIT::compileArithMod): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITArithmetic.cpp: + (JSC::JIT::emit_op_div): + +2012-11-06 Filip Pizlo <fpizlo@apple.com> + + JSC should infer when indexed storage contains only integers or doubles + https://bugs.webkit.org/show_bug.cgi?id=98606 + + Reviewed by Oliver Hunt. + + This adds two new indexing types: int32 and double. It also adds array allocation profiling, + which allows array allocations to converge to allocating arrays using those types to which + those arrays would have been converted. + + 20% speed-up on navier-stokes. 40% speed-up on various Kraken DSP tests. Some slow-downs too, + but a performance win overall on all benchmarks we track. + + * API/JSObjectRef.cpp: + (JSObjectMakeArray): + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/AbstractMacroAssembler.h: + (JumpList): + (JSC::AbstractMacroAssembler::JumpList::JumpList): + * assembler/MacroAssemblerX86Common.h: + (JSC::MacroAssemblerX86Common::branchDouble): + * assembler/X86Assembler.h: + (JSC::X86Assembler::jnp): + (X86Assembler): + (JSC::X86Assembler::X86InstructionFormatter::emitRex): + * bytecode/ArrayAllocationProfile.cpp: Added. + (JSC): + (JSC::ArrayAllocationProfile::updateIndexingType): + * bytecode/ArrayAllocationProfile.h: Added. + (JSC): + (ArrayAllocationProfile): + (JSC::ArrayAllocationProfile::ArrayAllocationProfile): + (JSC::ArrayAllocationProfile::selectIndexingType): + (JSC::ArrayAllocationProfile::updateLastAllocation): + (JSC::ArrayAllocationProfile::selectIndexingTypeFor): + (JSC::ArrayAllocationProfile::updateLastAllocationFor): + * bytecode/ArrayProfile.cpp: + (JSC::ArrayProfile::updatedObservedArrayModes): + (JSC): + * bytecode/ArrayProfile.h: + (JSC): + (JSC::arrayModesInclude): + (JSC::shouldUseSlowPutArrayStorage): + (JSC::shouldUseFastArrayStorage): + (JSC::shouldUseContiguous): + (JSC::shouldUseDouble): + (JSC::shouldUseInt32): + (ArrayProfile): + * bytecode/ByValInfo.h: + (JSC::isOptimizableIndexingType): + (JSC::jitArrayModeForIndexingType): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): + (JSC): + (JSC::CodeBlock::updateAllValueProfilePredictions): + (JSC::CodeBlock::updateAllArrayPredictions): + (JSC::CodeBlock::updateAllPredictions): + (JSC::CodeBlock::shouldOptimizeNow): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::numberOfArrayAllocationProfiles): + (JSC::CodeBlock::addArrayAllocationProfile): + (JSC::CodeBlock::updateAllValueProfilePredictions): + (JSC::CodeBlock::updateAllArrayPredictions): + * bytecode/DFGExitProfile.h: + (JSC::DFG::exitKindToString): + * bytecode/Instruction.h: + (JSC): + (JSC::Instruction::Instruction): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/SpeculatedType.h: + (JSC): + (JSC::isRealNumberSpeculation): + * bytecode/UnlinkedCodeBlock.cpp: + (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): + * bytecode/UnlinkedCodeBlock.h: + (JSC): + (JSC::UnlinkedCodeBlock::addArrayAllocationProfile): + (JSC::UnlinkedCodeBlock::numberOfArrayAllocationProfiles): + (UnlinkedCodeBlock): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::newArrayAllocationProfile): + (JSC): + (JSC::BytecodeGenerator::emitNewArray): + (JSC::BytecodeGenerator::emitExpectedFunctionSnippet): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::fromObserved): + (JSC::DFG::ArrayMode::refine): + (DFG): + (JSC::DFG::ArrayMode::alreadyChecked): + (JSC::DFG::arrayTypeToString): + * dfg/DFGArrayMode.h: + (JSC::DFG::ArrayMode::withType): + (ArrayMode): + (JSC::DFG::ArrayMode::withTypeAndConversion): + (JSC::DFG::ArrayMode::usesButterfly): + (JSC::DFG::ArrayMode::isSpecific): + (JSC::DFG::ArrayMode::supportsLength): + (JSC::DFG::ArrayMode::arrayModesThatPassFiltering): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getArrayMode): + (ByteCodeParser): + (JSC::DFG::ByteCodeParser::handleIntrinsic): + (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + (CCallHelpers): + * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: + (JSC::DFG::CallArrayAllocatorSlowPathGenerator::generateInternal): + (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::generateInternal): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::checkArray): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::byValIsPure): + * dfg/DFGNode.h: + (NewArrayBufferData): + (JSC::DFG::Node::hasIndexingType): + (Node): + (JSC::DFG::Node::indexingType): + (JSC::DFG::Node::setIndexingType): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): + (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): + (DFG): + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::arrayify): + (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): + (JSC::DFG::SpeculativeJIT::compileGetArrayLength): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + (SpeculateIntegerOperand): + (JSC::DFG::SpeculateIntegerOperand::use): + (SpeculateDoubleOperand): + (JSC::DFG::SpeculateDoubleOperand::use): + * dfg/DFGSpeculativeJIT32_64.cpp: + (DFG): + (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JIT.h: + (JSC::JIT::emitInt32GetByVal): + (JIT): + (JSC::JIT::emitInt32PutByVal): + (JSC::JIT::emitDoublePutByVal): + (JSC::JIT::emitContiguousPutByVal): + * jit/JITExceptions.cpp: + (JSC::genericThrow): + * jit/JITInlineMethods.h: + (JSC::arrayProfileSaw): + (JSC::JIT::chooseArrayMode): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_new_array): + (JSC::JIT::emit_op_new_array_with_size): + (JSC::JIT::emit_op_new_array_buffer): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emitDoubleGetByVal): + (JSC): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::emitGenericContiguousPutByVal): + (JSC::JIT::emitSlow_op_put_by_val): + (JSC::JIT::privateCompileGetByVal): + (JSC::JIT::privateCompilePutByVal): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emitDoubleGetByVal): + (JSC): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::emitGenericContiguousPutByVal): + (JSC::JIT::emitSlow_op_put_by_val): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * jit/JITStubs.h: + (JSC): + * jsc.cpp: + (GlobalObject::finishCreation): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::jitCompileAndSetHeuristics): + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * offlineasm/x86.rb: + * runtime/ArrayConstructor.cpp: + (JSC::constructArrayWithSizeQuirk): + * runtime/ArrayConstructor.h: + (JSC): + * runtime/ArrayPrototype.cpp: + (JSC::arrayProtoFuncConcat): + (JSC::arrayProtoFuncSlice): + (JSC::arrayProtoFuncSplice): + (JSC::arrayProtoFuncFilter): + (JSC::arrayProtoFuncMap): + * runtime/Butterfly.h: + (JSC::Butterfly::contiguousInt32): + (JSC::Butterfly::contiguousDouble): + (JSC::Butterfly::fromContiguous): + * runtime/ButterflyInlineMethods.h: + (JSC::Butterfly::createUninitializedDuringCollection): + * runtime/FunctionPrototype.cpp: + (JSC::functionProtoFuncBind): + * runtime/IndexingHeaderInlineMethods.h: + (JSC::IndexingHeader::indexingPayloadSizeInBytes): + * runtime/IndexingType.cpp: + (JSC::leastUpperBoundOfIndexingTypes): + (JSC): + (JSC::leastUpperBoundOfIndexingTypeAndType): + (JSC::leastUpperBoundOfIndexingTypeAndValue): + (JSC::indexingTypeToString): + * runtime/IndexingType.h: + (JSC): + (JSC::hasUndecided): + (JSC::hasInt32): + (JSC::hasDouble): + * runtime/JSArray.cpp: + (JSC::JSArray::setLength): + (JSC::JSArray::pop): + (JSC::JSArray::push): + (JSC::JSArray::shiftCountWithAnyIndexingType): + (JSC::JSArray::unshiftCountWithAnyIndexingType): + (JSC::compareNumbersForQSortWithInt32): + (JSC): + (JSC::compareNumbersForQSortWithDouble): + (JSC::JSArray::sortNumericVector): + (JSC::JSArray::sortNumeric): + (JSC::JSArray::sortCompactedVector): + (JSC::JSArray::sort): + (JSC::JSArray::sortVector): + (JSC::JSArray::fillArgList): + (JSC::JSArray::copyToArguments): + (JSC::JSArray::compactForSorting): + * runtime/JSArray.h: + (JSArray): + (JSC::createContiguousArrayButterfly): + (JSC::JSArray::create): + (JSC::JSArray::tryCreateUninitialized): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + (JSC): + (JSC::JSGlobalObject::haveABadTime): + (JSC::JSGlobalObject::visitChildren): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::originalArrayStructureForIndexingType): + (JSC::JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation): + (JSC::JSGlobalObject::arrayStructureForProfileDuringAllocation): + (JSC::JSGlobalObject::isOriginalArrayStructure): + (JSC::constructEmptyArray): + (JSC::constructArray): + * runtime/JSObject.cpp: + (JSC::JSObject::copyButterfly): + (JSC::JSObject::getOwnPropertySlotByIndex): + (JSC::JSObject::putByIndex): + (JSC::JSObject::enterDictionaryIndexingMode): + (JSC::JSObject::createInitialIndexedStorage): + (JSC): + (JSC::JSObject::createInitialUndecided): + (JSC::JSObject::createInitialInt32): + (JSC::JSObject::createInitialDouble): + (JSC::JSObject::createInitialContiguous): + (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::convertUndecidedForValue): + (JSC::JSObject::convertInt32ForValue): + (JSC::JSObject::setIndexQuicklyToUndecided): + (JSC::JSObject::convertInt32ToDoubleOrContiguousWhilePerformingSetIndex): + (JSC::JSObject::convertDoubleToContiguousWhilePerformingSetIndex): + (JSC::JSObject::ensureInt32Slow): + (JSC::JSObject::ensureDoubleSlow): + (JSC::JSObject::ensureContiguousSlow): + (JSC::JSObject::ensureArrayStorageSlow): + (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): + (JSC::JSObject::switchToSlowPutArrayStorage): + (JSC::JSObject::deletePropertyByIndex): + (JSC::JSObject::getOwnPropertyNames): + (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): + (JSC::JSObject::putByIndexBeyondVectorLength): + (JSC::JSObject::putDirectIndexBeyondVectorLength): + (JSC::JSObject::getNewVectorLength): + (JSC::JSObject::countElements): + (JSC::JSObject::ensureLengthSlow): + (JSC::JSObject::getOwnPropertyDescriptor): + * 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): + (JSObject): + (JSC::JSObject::ensureInt32): + (JSC::JSObject::ensureDouble): + (JSC::JSObject::ensureLength): + (JSC::JSObject::indexingData): + (JSC::JSObject::currentIndexingData): + (JSC::JSObject::getHolyIndexQuickly): + (JSC::JSObject::relevantLength): + (JSC::JSObject::currentRelevantLength): + * runtime/JSValue.cpp: + (JSC::JSValue::description): + * runtime/LiteralParser.cpp: + (JSC::::parse): + * runtime/ObjectConstructor.cpp: + (JSC::objectConstructorGetOwnPropertyNames): + (JSC::objectConstructorKeys): + * runtime/StringPrototype.cpp: + (JSC::stringProtoFuncMatch): + (JSC::stringProtoFuncSplit): + * runtime/Structure.cpp: + (JSC::Structure::nonPropertyTransition): + * runtime/StructureTransitionTable.h: + (JSC::newIndexingType): + +2012-11-08 Balazs Kilvady <kilvadyb@homejinni.com> + + ASSERT problem on MIPS + https://bugs.webkit.org/show_bug.cgi?id=100589 + + Reviewed by Oliver Hunt. + + ASSERT fix for MIPS arch. + + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_resolve_operations): + +2012-11-08 Michael Saboff <msaboff@apple.com> + + OpaqueJSClassContextData() should use StringImpl::isolatedCopy() to make string copies + https://bugs.webkit.org/show_bug.cgi?id=101507 + + Reviewed by Andreas Kling. + + Changed to use isolatedCopy() for key Strings. + + * API/JSClassRef.cpp: + (OpaqueJSClassContextData::OpaqueJSClassContextData): + +2012-11-07 Mark Hahnenberg <mhahnenberg@apple.com> + + WeakBlocks should be HeapBlocks + https://bugs.webkit.org/show_bug.cgi?id=101411 + + Reviewed by Oliver Hunt. + + Currently WeakBlocks use fastMalloc memory. They are very similar to the other HeapBlocks, however, + so we should change them to being allocated with the BlockAllocator. + + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::BlockAllocator): + * heap/BlockAllocator.h: Added a new RegionSet for WeakBlocks. + (JSC): + (BlockAllocator): + (JSC::WeakBlock): + * heap/Heap.h: Friended WeakSet to allow access to the BlockAllocator. + (Heap): + * heap/WeakBlock.cpp: + (JSC::WeakBlock::create): Refactored to use HeapBlocks rather than fastMalloc. + (JSC::WeakBlock::WeakBlock): + * heap/WeakBlock.h: Changed the WeakBlock size to 4 KB so that it divides evenly into the Region size. + (JSC): + (WeakBlock): + * heap/WeakSet.cpp: + (JSC::WeakSet::~WeakSet): + (JSC::WeakSet::addAllocator): + +2012-11-07 Filip Pizlo <fpizlo@apple.com> + + Indentation of ArgList.h is wrong + https://bugs.webkit.org/show_bug.cgi?id=101441 + + Reviewed by Andreas Kling. + + Just unindented by 4 spaces. + + * runtime/ArgList.h: + +2012-11-07 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + [Qt][ARM] REGRESSION(r133688): It made all JSC and layout tests crash on ARM traditional platform + https://bugs.webkit.org/show_bug.cgi?id=101465 + + Reviewed by Oliver Hunt. + + Fix failing javascriptcore tests on ARM after r133688 + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + +2012-11-06 Oliver Hunt <oliver@apple.com> + + Reduce parser overhead in JSC + https://bugs.webkit.org/show_bug.cgi?id=101127 + + Reviewed by Filip Pizlo. + + An exciting journey into the world of architecture in which our hero + adds yet another layer to JSC codegeneration. + + This patch adds a marginally more compact form of bytecode that is + free from any data specific to a given execution context, and that + does store any data structures necessary for execution. To actually + execute this UnlinkedBytecode we still need to instantiate a real + CodeBlock, but this is a much faster linear time operation than any + of the earlier parsing or code generation passes. + + As the unlinked code is context free we can then simply use a cache + from source to unlinked code mapping to completely avoid all of the + old parser overhead. The cache is currently very simple and memory + heavy, using the complete source text as a key (rather than SourceCode + or equivalent), and a random eviction policy. + + This seems to produce a substantial win when loading identical content + in different contexts. + + * API/tests/testapi.c: + (main): + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/CodeBlock.cpp: + * bytecode/CodeBlock.h: + Moved a number of fields, and a bunch of logic to UnlinkedCodeBlock.h/cpp + * bytecode/Opcode.h: + Added a global const init no op instruction needed to get correct + behaviour without any associated semantics. + * bytecode/UnlinkedCodeBlock.cpp: Added. + * bytecode/UnlinkedCodeBlock.h: Added. + A fairly shallow, GC allocated version of the old CodeBlock + classes with a 32bit instruction size, and just metadata + size tracking. + * bytecompiler/BytecodeGenerator.cpp: + * bytecompiler/BytecodeGenerator.h: + Replace direct access to m_symbolTable with access through + symbolTable(). ProgramCode no longer has a symbol table at + all so some previously unconditional (and pointless) uses + of symbolTable get null checks. + A few other changes to deal with type changes due to us generating + unlinked code (eg. pointer free, so profile indices rather than + pointers). + * dfg/DFGByteCodeParser.cpp: + * dfg/DFGCapabilities.h: + Support global_init_nop + * interpreter/Interpreter.cpp: + Now get the ProgramExecutable to initialise new global properties + before starting execution. + * jit/JIT.cpp: + * jit/JITDriver.h: + * jit/JITStubs.cpp: + * llint/LLIntData.cpp: + * llint/LLIntSlowPaths.cpp: + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + Adding init_global_const_nop everywhere else + * parser/Parser.h: + * parser/ParserModes.h: Added. + * parser/ParserTokens.h: + Parser no longer needs a global object or callframe to function + * runtime/CodeCache.cpp: Added. + * runtime/CodeCache.h: Added. + A simple, random eviction, Source->UnlinkedCode cache + * runtime/Executable.cpp: + * runtime/Executable.h: + Executables now reference their unlinked counterparts, and + request code specifically for the target global object. + * runtime/JSGlobalData.cpp: + * runtime/JSGlobalData.h: + GlobalData now owns a CodeCache and a set of new structures + for the unlinked code types. + * runtime/JSGlobalObject.cpp: + * runtime/JSGlobalObject.h: + Utility functions used by executables to perform compilation + + * runtime/JSType.h: + Add new JSTypes for unlinked code + +2012-11-06 Michael Saboff <msaboff@apple.com> + + JSStringCreateWithCFString() Should create an 8 bit String if possible + https://bugs.webkit.org/show_bug.cgi?id=101104 + + Reviewed by Darin Adler. + + Try converting the CFString to an 8 bit string using CFStringGetBytes(..., + kCFStringEncodingISOLatin1, ...) and return the 8 bit string if successful. + If not proceed with 16 bit conversion. + + * API/JSStringRefCF.cpp: + (JSStringCreateWithCFString): + +2012-11-06 Oliver Hunt <oliver@apple.com> + + Reduce direct m_symbolTable usage in CodeBlock + https://bugs.webkit.org/show_bug.cgi?id=101391 + + Reviewed by Sam Weinig. + + Simple refactoring. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::CodeBlock::dumpStatistics): + (JSC::CodeBlock::nameForRegister): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::isCaptured): + +2012-11-06 Michael Saboff <msaboff@apple.com> + + Lexer::scanRegExp, create 8 bit pattern and flag Identifiers from 16 bit source when possible + https://bugs.webkit.org/show_bug.cgi?id=101013 + + Reviewed by Darin Adler. + + Changed scanRegExp so that it will create 8 bit identifiers from 8 bit sources and from 16 bit sources + whan all the characters are 8 bit. Using two templated helpers, the "is all 8 bit" check is only performed + on 16 bit sources. The first helper is orCharacter() that will accumulate the or value of all characters + only for 16 bit sources. Replaced the helper Lexer::makeIdentifierSameType() with Lexer::makeRightSizedIdentifier(). + + * parser/Lexer.cpp: + (JSC::orCharacter<LChar>): Explicit template that serves as a placeholder. + (JSC::orCharacter<UChar>): Explicit template that actually or accumulates characters. + (JSC::Lexer::scanRegExp): + * parser/Lexer.h: + (Lexer): + (JSC::Lexer::makeRightSizedIdentifier<LChar>): New template that always creates an 8 bit Identifier. + (JSC::Lexer::makeRightSizedIdentifier<UChar>): New template that creates an 8 bit Identifier for 8 bit + data in a 16 bit source. + +2012-11-06 Filip Pizlo <fpizlo@apple.com> + + Indentation of JSCell.h is wrong + https://bugs.webkit.org/show_bug.cgi?id=101379 + + Rubber stamped by Alexey Proskuryakov. + + Just removed four spaces on a bunch of lines. + + * runtime/JSCell.h: + +2012-11-05 Filip Pizlo <fpizlo@apple.com> + + Indentation of JSObject.h is wrong + https://bugs.webkit.org/show_bug.cgi?id=101313 + + Rubber stamped by Alexey Proskuryakov. + + Just unindented code, since namespace bodies shouldn't be indented. + + * runtime/JSObject.h: + +2012-11-05 Filip Pizlo <fpizlo@apple.com> + + Indentation of JSArray.h is wrong + https://bugs.webkit.org/show_bug.cgi?id=101314 + + Rubber stamped by Alexey Proskuryakov. + + Just removing the indentation inside the namespace body. + + * runtime/JSArray.h: + +2012-11-05 Filip Pizlo <fpizlo@apple.com> + + DFG should not fall down to patchable GetById just because a prototype had things added to it + https://bugs.webkit.org/show_bug.cgi?id=101299 + + Reviewed by Geoffrey Garen. + + This looks like a slight win on V8v7 and SunSpider. + + * bytecode/DFGExitProfile.h: + (JSC::DFG::exitKindToString): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-11-05 Filip Pizlo <fpizlo@apple.com> + + Get rid of method_check + https://bugs.webkit.org/show_bug.cgi?id=101147 + + Reviewed by Geoffrey Garen. + + op_method_check no longer buys us anything, since get_by_id proto caching + gives just as much profiling information and the DFG inlines monomorphic + proto accesses anyway. + + This also has the potential for a speed-up since it makes parsing of + profiling data easier. No longer do we have to deal with the confusion of + the get_by_id portion of a method_check appearing monomorphic even though + we're really dealing with a bimorphic access (method_check specializes for + one case and get_by_id for another). + + This looks like a 1% speed-up on both SunSpider and V8v7. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printGetByIdCacheStatus): + (JSC::CodeBlock::dump): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::shrinkToFit): + (JSC::CodeBlock::unlinkCalls): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::getCallLinkInfo): + (JSC::CodeBlock::callLinkInfo): + (CodeBlock): + * bytecode/GetByIdStatus.cpp: + (JSC::GetByIdStatus::computeFromLLInt): + * bytecode/MethodCallLinkInfo.cpp: Removed. + * bytecode/MethodCallLinkInfo.h: Removed. + * bytecode/MethodCallLinkStatus.cpp: Removed. + * bytecode/MethodCallLinkStatus.h: Removed. + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecompiler/BytecodeGenerator.cpp: + (JSC): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::FunctionCallDotNode::emitBytecode): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + (JSC::PropertyStubCompilationInfo::copyToStubInfo): + (JSC::JIT::privateCompile): + * jit/JIT.h: + (JSC::PropertyStubCompilationInfo::slowCaseInfo): + (PropertyStubCompilationInfo): + (JSC): + (JIT): + * jit/JITPropertyAccess.cpp: + (JSC): + (JSC::JIT::emitSlow_op_get_by_id): + (JSC::JIT::compileGetByIdSlowCase): + * jit/JITPropertyAccess32_64.cpp: + (JSC): + (JSC::JIT::compileGetByIdSlowCase): + * jit/JITStubs.cpp: + (JSC): + * jit/JITStubs.h: + * llint/LowLevelInterpreter.asm: + +2012-11-05 Yuqiang Xian <yuqiang.xian@intel.com> + + Refactor LLInt64 to distinguish the pointer operations from the 64-bit integer operations + https://bugs.webkit.org/show_bug.cgi?id=100321 + + Reviewed by Filip Pizlo. + + We have refactored the MacroAssembler and JIT compilers to distinguish + the pointer operations from the 64-bit integer operations (see bug #99154). + Now we want to do the similar work for LLInt, and the goal is same as + the one mentioned in 99154. + + This is the second part of the modification: in the low level interpreter, + changing the operations on 64-bit integers to use the "<foo>q" instructions. + This also removes some unused/meaningless "<foo>p" instructions. + + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter.cpp: + (JSC::CLoop::execute): + * llint/LowLevelInterpreter64.asm: + * offlineasm/armv7.rb: + * offlineasm/cloop.rb: + * offlineasm/instructions.rb: + * offlineasm/x86.rb: + +2012-11-05 Filip Pizlo <fpizlo@apple.com> + + Prototype chain caching should check that the path from the base object to the slot base involves prototype hops only + https://bugs.webkit.org/show_bug.cgi?id=101276 + + Reviewed by Gavin Barraclough. + + Changed normalizePrototypeChain() to report an invalid prototype chain if any object is a proxy. + This catches cases where our prototype chain checks would have been insufficient to guard against + newly introduced properties, despecialized properties, or deleted properties in the chain of + objects involved in the access. + + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDProtoList): + (JSC::DFG::tryCachePutByID): + (JSC::DFG::tryBuildPutByIdList): + * jit/JITStubs.cpp: + (JSC::JITThunks::tryCachePutByID): + (JSC::JITThunks::tryCacheGetByID): + (JSC::DEFINE_STUB_FUNCTION): + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * runtime/Operations.h: + (JSC): + (JSC::normalizePrototypeChain): + +2012-11-05 Dima Gorbik <dgorbik@apple.com> + + Back out controversial changes from Bug 98665. + https://bugs.webkit.org/show_bug.cgi?id=101244 + + Reviewed by David Kilzer. + + Backing out changes from Bug 98665 until further discussions take place on rules for including Platform.h in Assertions.h. + + * API/tests/minidom.c: + * API/tests/testapi.c: + +2012-11-04 Filip Pizlo <fpizlo@apple.com> + + Reduce the verbosity of referring to QNaN in JavaScriptCore + https://bugs.webkit.org/show_bug.cgi?id=101174 + + Reviewed by Geoffrey Garen. + + Introduces a #define QNaN in JSValue.h, and replaces all previous uses of + std::numeric_limits<double>::quiet_NaN() with QNaN. + + * API/JSValueRef.cpp: + (JSValueMakeNumber): + (JSValueToNumber): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emitFloatTypedArrayGetByVal): + * runtime/CachedTranscendentalFunction.h: + (JSC::CachedTranscendentalFunction::initialize): + * runtime/DateConstructor.cpp: + (JSC::constructDate): + * runtime/DateInstanceCache.h: + (JSC::DateInstanceData::DateInstanceData): + (JSC::DateInstanceCache::reset): + * runtime/ExceptionHelpers.cpp: + (JSC::InterruptedExecutionError::defaultValue): + (JSC::TerminatedExecutionError::defaultValue): + * runtime/JSCell.h: + (JSC::JSValue::getPrimitiveNumber): + * runtime/JSDateMath.cpp: + (JSC::parseDateFromNullTerminatedCharacters): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::resetDateCache): + * runtime/JSGlobalObjectFunctions.cpp: + (JSC::parseInt): + (JSC::jsStrDecimalLiteral): + (JSC::toDouble): + (JSC::jsToNumber): + (JSC::parseFloat): + * runtime/JSValue.cpp: + (JSC::JSValue::toNumberSlowCase): + * runtime/JSValue.h: + (JSC): + * runtime/JSValueInlineMethods.h: + (JSC::jsNaN): + * runtime/MathObject.cpp: + (JSC::mathProtoFuncMax): + (JSC::mathProtoFuncMin): + +2012-11-03 Filip Pizlo <fpizlo@apple.com> + + Baseline JIT should use structure watchpoints whenever possible + https://bugs.webkit.org/show_bug.cgi?id=101146 + + Reviewed by Sam Weinig. + + No speed-up yet except on toy programs. I think that it will start to show + speed-ups with https://bugs.webkit.org/show_bug.cgi?id=101147, which this is + a step towards. + + * jit/JIT.h: + (JIT): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + (JSC::JIT::addStructureTransitionCheck): + (JSC): + (JSC::JIT::testPrototype): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::privateCompilePutByIdTransition): + (JSC::JIT::privateCompileGetByIdProto): + (JSC::JIT::privateCompileGetByIdProtoList): + (JSC::JIT::privateCompileGetByIdChainList): + (JSC::JIT::privateCompileGetByIdChain): + +2012-11-04 Csaba Osztrogonác <ossy@webkit.org> + + [Qt] udis86_itab.c is always regenerated + https://bugs.webkit.org/show_bug.cgi?id=100756 + + Reviewed by Simon Hausmann. + + * DerivedSources.pri: Generate sources to the generated directory. + * disassembler/udis86/differences.txt: + * disassembler/udis86/itab.py: Add --outputDir option. + (UdItabGenerator.__init__): + (genItabH): + (genItabC): + (main): + +2012-11-02 Filip Pizlo <fpizlo@apple.com> + + LLInt 32-bit put_by_val ArrayStorage case should use the right register (t3, not t2) for the index in the publicLength updating path + https://bugs.webkit.org/show_bug.cgi?id=101118 + + Reviewed by Gavin Barraclough. + + * llint/LowLevelInterpreter32_64.asm: + +2012-11-02 Filip Pizlo <fpizlo@apple.com> + + DFG::Node::converToStructureTransitionWatchpoint should take kindly to ArrayifyToStructure + https://bugs.webkit.org/show_bug.cgi?id=101117 + + Reviewed by Gavin Barraclough. + + We have logic to convert ArrayifyToStructure to StructureTransitionWatchpoint, which is awesome, except + that previously convertToStructureTransitionWatchpoint was (a) asserting that it never saw an + ArrayifyToStructure and (b) would incorrectly create a ForwardStructureTransitionWatchpoint if it did. + + * dfg/DFGNode.h: + (JSC::DFG::Node::convertToStructureTransitionWatchpoint): + +2012-11-02 Filip Pizlo <fpizlo@apple.com> + + DFG::SpeculativeJIT::typedArrayDescriptor should use the Float64Array descriptor for Float64Arrays + https://bugs.webkit.org/show_bug.cgi?id=101114 + + Reviewed by Gavin Barraclough. + + As in https://bugs.webkit.org/show_bug.cgi?id=101112, this was only wrong when Float64Array descriptors + hadn't been initialized yet. That happens rarely, but when it does happen, we would crash. + + This would also become much more wrong if we ever put type size info (num bytes, etc) in the descriptor + and used that directly. So it's good to fix it. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::typedArrayDescriptor): + +2012-11-02 Filip Pizlo <fpizlo@apple.com> + + JIT::privateCompileGetByVal should use the uint8ClampedArrayDescriptor for compiling accesses to Uint8ClampedArrays + https://bugs.webkit.org/show_bug.cgi?id=101112 + + Reviewed by Gavin Barraclough. + + The only reason why the code was wrong to use uint8ArrayDescriptor instead is that if we're just using + Uint8ClampedArrays then the descriptor for Uint8Array may not have been initialized. + + * jit/JITPropertyAccess.cpp: + (JSC::JIT::privateCompileGetByVal): + +2012-11-02 Mark Hahnenberg <mhahnenberg@apple.com> + + MarkedBlocks should use something other than the mark bits to indicate liveness for newly allocated objects + https://bugs.webkit.org/show_bug.cgi?id=100877 + + Reviewed by Filip Pizlo. + + Currently when we canonicalize cell liveness data in MarkedBlocks, we set the mark bit for every cell in the + block except for those in the free list. This allows us to consider objects that were allocated since the + previous collection to be considered live until they have a chance to be properly marked by the collector. + + If we want to use the mark bits to signify other types of information, e.g. using sticky mark bits for generational + collection, we will have to keep track of newly allocated objects in a different fashion when we canonicalize cell liveness. + + One method would be to allocate a separate set of bits while canonicalizing liveness data. These bits would + track the newly allocated objects in the block separately from those objects who had already been marked. We would + then check these bits, along with the mark bits, when determining liveness. + + * heap/Heap.h: + (Heap): + (JSC::Heap::isLive): We now check for the presence of the newlyAllocated Bitmap. + (JSC): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::specializedSweep): We clear the newlyAllocated Bitmap if we're creating a free list. This + will happen if we canonicalize liveness data for some other reason than collection (e.g. forEachCell) and + then start allocating again. + (JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor): + (SetNewlyAllocatedFunctor): + (JSC::SetNewlyAllocatedFunctor::operator()): We set the newlyAllocated bits for all the objects + that aren't already marked. We undo the bits for the objects in the free list later in canonicalizeCellLivenessData. + (JSC::MarkedBlock::canonicalizeCellLivenessData): We should never have a FreeListed block with a newlyAllocated Bitmap. + We allocate the new Bitmap, set the bits for all the objects that aren't already marked, and then unset all of the + bits for the items currently in the FreeList. + * heap/MarkedBlock.h: + (JSC::MarkedBlock::clearMarks): We clear the newlyAllocated bitmap if it exists because at this point we don't need it + any more. + (JSC::MarkedBlock::isEmpty): If we have some objects that are newlyAllocated, we are not empty. + (JSC::MarkedBlock::isNewlyAllocated): + (JSC): + (JSC::MarkedBlock::setNewlyAllocated): + (JSC::MarkedBlock::clearNewlyAllocated): + (JSC::MarkedBlock::isLive): We now check the newlyAllocated Bitmap, if it exists, when determining liveness of a cell in + a block that is Marked. + * heap/WeakBlock.cpp: + (JSC::WeakBlock::visit): We need to make sure we don't finalize objects that are in the newlyAllocated Bitmap. + (JSC::WeakBlock::reap): Ditto. + +2012-11-02 Filip Pizlo <fpizlo@apple.com> + + JIT::privateCompileGetByVal should use MacroAssemblerCodePtr::createFromExecutableAddress like JIT::privateCompilePutByVal + https://bugs.webkit.org/show_bug.cgi?id=101109 + + Reviewed by Gavin Barraclough. + + This fixes crashes on ARMv7 resulting from the return address already being tagged with the THUMB2 bit. + + * jit/JITPropertyAccess.cpp: + (JSC::JIT::privateCompileGetByVal): + +2012-11-02 Simon Fraser <simon.fraser@apple.com> + + Enable SUBPIXEL_LAYOUT on Mac + https://bugs.webkit.org/show_bug.cgi?id=101076 + + Reviewed by Dave Hyatt. + + Define ENABLE_SUBPIXEL_LAYOUT and include it in FEATURE_DEFINES. + + * Configurations/FeatureDefines.xcconfig: + +2012-11-02 Michael Saboff <msaboff@apple.com> + + RegExp.prototype.toString Should Produce an 8 bit JSString if possible. + https://bugs.webkit.org/show_bug.cgi?id=101003 + + Reviewed by Geoffrey Garen. + + Took the logic of regExpObjectSource() and created two templated helpers that uses the + source character type when appending to the StringBuilder. + + * runtime/RegExpObject.cpp: + (JSC::appendLineTerminatorEscape): Checks line terminate type to come up with escaped version. + (JSC::regExpObjectSourceInternal): Templated version of original. + (JSC::regExpObjectSource): Wrapper function. + +2012-11-02 Adam Barth <abarth@webkit.org> + + ENABLE(UNDO_MANAGER) is disabled everywhere and is not under active development + https://bugs.webkit.org/show_bug.cgi?id=100711 + + Reviewed by Eric Seidel. + + * Configurations/FeatureDefines.xcconfig: + +2012-11-02 Simon Hausmann <simon.hausmann@digia.com> + + [Qt] Fix build on Windows when Qt is configured with -release + https://bugs.webkit.org/show_bug.cgi?id=101041 + + Reviewed by Jocelyn Turcotte. + + When Qt is configured with -debug or -release, the release/debug build of for example + QtCore is not available by default. For LLIntExtractor we always need to build debug + _and_ release versions, but we do not actually need any Qt libraries nor qtmain(d).lib. + Therefore we can disable all these features but need to keep $$QT.core.includes in the + INCLUDEPATH for some defines from qglobal.h. + + * LLIntOffsetsExtractor.pro: + +2012-11-01 Mark Lam <mark.lam@apple.com> + + A llint workaround for a toolchain issue. + https://bugs.webkit.org/show_bug.cgi?id=101012. + + Reviewed by Michael Saboff. + + * llint/LowLevelInterpreter.asm: + - use a local label to workaround the toolchain issue with undeclared + global labels. + +2012-11-01 Oliver Hunt <oliver@apple.com> + + Remove GlobalObject constant register that is typically unused + https://bugs.webkit.org/show_bug.cgi?id=101005 + + Reviewed by Geoffrey Garen. + + The GlobalObject constant register is frequently allocated even when it + is not used, it is also getting in the way of some other optimisations. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::CodeBlock): + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::BytecodeGenerator): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseResolveOperations): + +2012-10-31 Filip Pizlo <fpizlo@apple.com> + + DFG optimized string access code should be enabled + https://bugs.webkit.org/show_bug.cgi?id=100825 + + Reviewed by Oliver Hunt. + + - Removes prediction checks from the parser. + + - Fixes the handling of array mode refinement for strings. I.e. we don't do + any refinement - we already know it's going to be a string. We could + revisit this in the future, but for now the DFG lacks the ability to + handle any array modes other than Array::String for string intrinsics, so + this is as good as it gets. + + - Removes uses of isBlahSpeculation for checking if a mode is already + checked. isBlahSpeculation implicitly checks if the SpeculatedType is not + BOTTOM ("empty"), which breaks for checking if a mode is already checked + since a mode may already be "checked" in the sense that we've proven that + the code is unreachable. + + ~1% speed-up on V8v7, mostly from a speed-up on crypto, which uses string + intrinsics in one of the hot functions. + + * bytecode/SpeculatedType.h: + (JSC::speculationChecked): + (JSC): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::alreadyChecked): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleIntrinsic): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt): + +2012-10-31 Filip Pizlo <fpizlo@apple.com> + + Sparse array size threshold should be increased to 100000 + https://bugs.webkit.org/show_bug.cgi?id=100827 + + Reviewed by Oliver Hunt. + + This enables the use of contiguous arrays in programs that previously + couldn't use them. And I so far can't see any examples of this being + a downside. To the extent that there is a downside, it ought to be + addressed by GC: https://bugs.webkit.org/show_bug.cgi?id=100828 + + * runtime/ArrayConventions.h: + (JSC): + +2012-10-31 Mark Lam <mark.lam@apple.com> + + C++ llint 64-bit backend needs to zero extend results of int32 operations. + https://bugs.webkit.org/show_bug.cgi?id=100899. + + Reviewed by Filip Pizlo. + + llint asm instructions ending in "i" for a 64-bit machine expects the + high 32-bit of registers to be zero'ed out when a 32-bit instruction + writes into a register. Fixed the C++ llint to honor this. + + Fixed the index register used in BaseIndex addressing to be of size + intptr_t as expected. + + Updated CLoopRegister to handle different endiannesss configurations. + + * llint/LowLevelInterpreter.cpp: + (JSC::CLoopRegister::clearHighWord): + - new method to clear the high 32-bit of a 64-bit register. + It's a no-op for the 32-bit build. + (CLoopRegister): + - CLoopRegister now takes care of packing and byte endianness order. + (JSC::CLoop::execute): - Added an assert. + * offlineasm/cloop.rb: + - Add calls to clearHighWord() wherever needed. + +2012-10-31 Mark Lam <mark.lam@apple.com> + + A JSC printf (support for %J+s and %b). + https://bugs.webkit.org/show_bug.cgi?id=100566. + + Reviewed by Michael Saboff. + + Added VMInspector::printf(), fprintf(), sprintf(), and snprintf(). + - %b prints ints as boolean TRUE (non-zero) or FALSE (zero). + - %Js prints a WTF::String* like a %s prints a char*. + Also works for 16bit WTF::Strings (prints wchar_t* using %S). + - '+' is a modifier meaning 'use verbose mode', and %J+s is an example + of its use. + + * JavaScriptCore.xcodeproj/project.pbxproj: + * interpreter/VMInspector.cpp: + (FormatPrinter): + (JSC::FormatPrinter::~FormatPrinter): + (JSC::FormatPrinter::print): + (JSC::FormatPrinter::printArg): + (JSC::FormatPrinter::printWTFString): + (JSC::FileFormatPrinter::FileFormatPrinter): + (JSC::FileFormatPrinter::printArg): + (JSC::StringFormatPrinter::StringFormatPrinter): + (JSC::StringFormatPrinter::printArg): + (JSC::StringNFormatPrinter::StringNFormatPrinter): + (JSC::StringNFormatPrinter::printArg): + (JSC::VMInspector::fprintf): + (JSC::VMInspector::printf): + (JSC::VMInspector::sprintf): + (JSC::VMInspector::snprintf): + * interpreter/VMInspector.h: + (VMInspector): + +2012-10-31 Mark Lam <mark.lam@apple.com> + + 64-bit llint PC offset can be negative: using an unsigned shift is a bug. + https://bugs.webkit.org/show_bug.cgi?id=100896. + + Reviewed by Filip Pizlo. + + Fixed the PC offset divisions in the 64-bit llint asm to use rshift instead of urshift. + + * llint/LowLevelInterpreter64.asm: + +2012-10-30 Yuqiang Xian <yuqiang.xian@intel.com> + + glsl-function-atan.html WebGL conformance test fails after https://bugs.webkit.org/show_bug.cgi?id=99154 + https://bugs.webkit.org/show_bug.cgi?id=100789 + + Reviewed by Filip Pizlo. + + We accidently missed a bitwise double to int64 conversion. + + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::silentFill): + +2012-10-30 Joseph Pecoraro <pecoraro@apple.com> + + [Mac] Sync up FeatureDefine Configuration Files + https://bugs.webkit.org/show_bug.cgi?id=100171 + + Reviewed by David Kilzer. + + Follow up to better coordinate with iOS feature defines. Make: + + - ENABLE_FILTERS always on + - ENABLE_INPUT_* iphonesimulator values point to the iphoneos values + + * Configurations/FeatureDefines.xcconfig: + +2012-10-30 Joseph Pecoraro <pecoraro@apple.com> + + [Mac] Sync up FeatureDefine Configuration Files + https://bugs.webkit.org/show_bug.cgi?id=100171 + + Reviewed by David Kilzer. + + Ensure an identical FeatureDefine files across all projects. Changes: + + - ENABLE_CSS_BOX_DECORATION_BREAK should be in all + - ENABLE_PDFKIT_PLUGIN should be in all + - ENABLE_RESOLUTION_MEDIA_QUERY should be in all + - ENABLE_ENCRYPTED_MEDIA should be in all + - ENABLE_HIDDEN_PAGE_DOM_TIMER_THROTTLING with corrected value + - Some alphabetical ordering cleanup + + * Configurations/FeatureDefines.xcconfig: + +2012-10-30 Mark Hahnenberg <mhahnenberg@apple.com> + + Arrays can change IndexingType in the middle of sorting + https://bugs.webkit.org/show_bug.cgi?id=100773 + + Reviewed by Filip Pizlo. + + Instead of giving up, we just fetch the appropriate vector based on the current + IndexingType of the array. + + * runtime/JSArray.cpp: + (JSC::JSArray::sortVector): + * runtime/JSObject.h: + (JSObject): + (JSC::JSObject::currentIndexingData): + (JSC::JSObject::currentRelevantLength): + +2012-10-29 Anders Carlsson <andersca@apple.com> + + Build WebKit as C++11 on Mac + https://bugs.webkit.org/show_bug.cgi?id=100720 + + Reviewed by Daniel Bates. + + * Configurations/Base.xcconfig: + Add CLANG_CXX_LANGUAGE_STANDARD=gnu++0x. + + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::generate): + (JSC::BytecodeGenerator::pushFinallyContext): + (JSC::BytecodeGenerator::beginSwitch): + * llint/LLIntOffsetsExtractor.cpp: + * runtime/Identifier.cpp: + (JSC::Identifier::add8): + * runtime/Identifier.h: + (JSC::Identifier::add): + * runtime/JSONObject.cpp: + (JSC::appendStringToStringBuilder): + * runtime/StringPrototype.cpp: + (JSC::replaceUsingStringSearch): + Add static_casts to prevent implicit type conversions in non-constant initializer lists. + +2012-10-28 Mark Rowe <mrowe@apple.com> + + Simplify Xcode configuration settings that used to vary between OS versions. + + Reviewed by Dan Bernstein. + + * Configurations/Base.xcconfig: + * Configurations/DebugRelease.xcconfig: + * Configurations/JavaScriptCore.xcconfig: + +2012-10-28 Mark Rowe <mrowe@apple.com> + + Remove references to unsupported OS and Xcode versions. + + Reviewed by Anders Carlsson. + + * Configurations/Base.xcconfig: + * Configurations/CompilerVersion.xcconfig: Removed. + * Configurations/DebugRelease.xcconfig: + * Configurations/Version.xcconfig: + * JavaScriptCore.xcodeproj/project.pbxproj: + +2012-10-29 Michael Saboff <msaboff@apple.com> + + Non-special escape character sequences cause JSC::Lexer::parseString to create 16 bit strings + https://bugs.webkit.org/show_bug.cgi?id=100576 + + Reviewed by Darin Adler. + + Changed singleEscape() processing to be based on a lookup of a static table. The table + covers ASCII characters SPACE through DEL. If a character can be a single character escape, + then the table provides the non-zero result of that escape. Updated the result of + singleEscape to be an LChar to make the table as small as possible. + Added a new test fast/js/normal-character-escapes-in-string-literals.html to validated + the behavior. + + * parser/Lexer.cpp: + (JSC::singleEscape): + (JSC::Lexer::parseString): + (JSC::Lexer::parseStringSlowCase): + +2012-10-29 Enrica Casucci <enrica@apple.com> + + Add ENABLE_USERSELECT_ALL feature flag. + https://bugs.webkit.org/show_bug.cgi?id=100559 + + Reviewed by Eric Seidel. + + * Configurations/FeatureDefines.xcconfig: + +2012-10-28 Filip Pizlo <fpizlo@apple.com> + + DFG should be able to emit effectful structure checks + https://bugs.webkit.org/show_bug.cgi?id=99260 + + Reviewed by Oliver Hunt. + + This change allows us to find out if an array access that has gone polymorphic + is operating over known structures - i.e. the primordial array structures of the + global object that the code block containing the array access belongs to. We + term this state "OriginalArray" for short. The fact that the access has gone + polymorphic means that the array profile will not be able to report the set of + structures it had seen - but if it can tell us that all of the structures were + primordial then it just so happens that we can deduce what the structure set + would have been by just querying the code block's global object. This allows us + to emit an ArrayifyToStructure instead of an Arrayify if we find that we need to + do conversions. The fast path of an ArrayifyToStructure is exactly like the fast + path of a CheckStructure and is mostly subject to the same optimizations. It + also burns one fewer registers. + + Essentially the notion of OriginalArray is a super cheap way of getting the + array profile to tell us a structure set instead of a singleton structure. + Currently, the array profile can only tell us the structure seen at an array + access if there was exactly one structure. If there were multiple structures, it + won't tell us anything other than the array modes and other auxiliary profiling + data (whether there were stores to holes, for example). With OriginalArray, we + cheaply get a structure set if all of the structures were primordial for the + code block's global object, since in that case the array mode set (ArrayModes) + can directly tell us the structure set. In the future, we might consider adding + complete structure sets to the array profiles, but I suspect that we would hit + diminishing returns if we did so - it would only help if we have array accesses + that are both polymorphic and are cross-global-object accesses (rare) or if the + arrays had named properties or other structure transitions that are unrelated to + indexing type (also rare). + + This also does away with Arrayify (and the new ArrayifyToStructure) returning + the butterfly pointer. This turns out to be faster and easier to CSE. + + And, this also changes constant folding to be able to eliminate CheckStructure, + ForwardCheckStructure, and ArrayifyToStructure in addition to being able to + transform them into structure transition watchpoints. This is great for + ArrayifyToStructure because then CSE and CFA know that there is no side effect. + Converting CheckStructure and ForwardCheckStructure to also behave this way is + just a matter of elegance. + + This has no performance impact right now. It's intended to alleviate some of the + regressions seen in the early implementation of + https://bugs.webkit.org/show_bug.cgi?id=98606. + + * bytecode/ArrayProfile.cpp: + (JSC::ArrayProfile::computeUpdatedPrediction): + * bytecode/ArrayProfile.h: + (JSC): + (JSC::ArrayProfile::ArrayProfile): + (ArrayProfile): + (JSC::ArrayProfile::usesOriginalArrayStructures): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::fromObserved): + (JSC::DFG::ArrayMode::alreadyChecked): + (JSC::DFG::arrayClassToString): + * dfg/DFGArrayMode.h: + (JSC::DFG::ArrayMode::withProfile): + (JSC::DFG::ArrayMode::isJSArray): + (ArrayMode): + (JSC::DFG::ArrayMode::isJSArrayWithOriginalStructure): + (JSC::DFG::ArrayMode::supportsLength): + (JSC::DFG::ArrayMode::arrayModesWithIndexingShape): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getArrayMode): + (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): + (JSC::DFG::ByteCodeParser::handleGetByOffset): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::checkStructureElimination): + (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): + (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::checkArrayElimination): + (JSC::DFG::CSEPhase::getScopeRegistersLoadElimination): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::checkArray): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasStructure): + (JSC::DFG::Node::hasArrayMode): + (JSC::DFG::Node::arrayMode): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): + (JSC::DFG::SpeculativeJIT::arrayify): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * runtime/JSGlobalObject.h: + (JSC::JSGlobalObject::isOriginalArrayStructure): + * runtime/Structure.cpp: + (JSC::Structure::nonPropertyTransition): + +2012-10-28 Filip Pizlo <fpizlo@apple.com> + + There should not be blind spots in array length array profiling + https://bugs.webkit.org/show_bug.cgi?id=100620 + + Reviewed by Oliver Hunt. + + I don't think this has any performance impact. But it's good to not have random + programs occasionally emit a GetById for array length accesses. + + * jit/JITPropertyAccess.cpp: + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::privateCompilePatchGetArrayLength): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::privateCompilePatchGetArrayLength): + +2012-10-28 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, make always-true enum-to-int comparisons use casts. + + * dfg/DFGFPRInfo.h: + (JSC::DFG::FPRInfo::debugName): + * dfg/DFGGPRInfo.h: + (JSC::DFG::JSValueSource::tagGPR): + (JSC::DFG::GPRInfo::toIndex): + (JSC::DFG::GPRInfo::debugName): + * runtime/JSTypeInfo.h: + (JSC::TypeInfo::TypeInfo): + +2012-10-27 Filip Pizlo <fpizlo@apple.com> + + OSR exit compilation should defend against argument recoveries from code blocks that are no longer on the inline stack + https://bugs.webkit.org/show_bug.cgi?id=100601 + + Reviewed by Oliver Hunt. + + This happened to me while I was fixing bugs for https://bugs.webkit.org/show_bug.cgi?id=100599. + I'm not sure how to reproduce this. + + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::baselineCodeBlockFor): + (AssemblyHelpers): + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + +2012-10-27 Filip Pizlo <fpizlo@apple.com> + + DFG::Array::Mode needs to be cleaned up + https://bugs.webkit.org/show_bug.cgi?id=100599 + + Reviewed by Oliver Hunt. + + Turn the previous massive Array::Mode enum into a class that contains four + fields, the type, whether it's a JSArray, the level of speculation, and the + kind of conversion to perform. + + No performance or behavioral change. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::ArrayMode::fromObserved): + (JSC::DFG::ArrayMode::refine): + (JSC::DFG::ArrayMode::alreadyChecked): + (JSC::DFG::arrayTypeToString): + (JSC::DFG::arrayClassToString): + (DFG): + (JSC::DFG::arraySpeculationToString): + (JSC::DFG::arrayConversionToString): + (JSC::DFG::ArrayMode::toString): + * dfg/DFGArrayMode.h: + (DFG): + (ArrayMode): + (JSC::DFG::ArrayMode::ArrayMode): + (JSC::DFG::ArrayMode::type): + (JSC::DFG::ArrayMode::arrayClass): + (JSC::DFG::ArrayMode::speculation): + (JSC::DFG::ArrayMode::conversion): + (JSC::DFG::ArrayMode::asWord): + (JSC::DFG::ArrayMode::fromWord): + (JSC::DFG::ArrayMode::withSpeculation): + (JSC::DFG::ArrayMode::usesButterfly): + (JSC::DFG::ArrayMode::isJSArray): + (JSC::DFG::ArrayMode::isInBounds): + (JSC::DFG::ArrayMode::mayStoreToHole): + (JSC::DFG::ArrayMode::isOutOfBounds): + (JSC::DFG::ArrayMode::isSlowPut): + (JSC::DFG::ArrayMode::canCSEStorage): + (JSC::DFG::ArrayMode::lengthNeedsStorage): + (JSC::DFG::ArrayMode::modeForPut): + (JSC::DFG::ArrayMode::isSpecific): + (JSC::DFG::ArrayMode::supportsLength): + (JSC::DFG::ArrayMode::benefitsFromStructureCheck): + (JSC::DFG::ArrayMode::doesConversion): + (JSC::DFG::ArrayMode::arrayModesThatPassFiltering): + (JSC::DFG::ArrayMode::operator==): + (JSC::DFG::ArrayMode::operator!=): + (JSC::DFG::ArrayMode::arrayModesWithIndexingShape): + (JSC::DFG::canCSEStorage): + (JSC::DFG::lengthNeedsStorage): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getArrayMode): + (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks): + (JSC::DFG::ByteCodeParser::handleIntrinsic): + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getArrayLengthElimination): + (JSC::DFG::CSEPhase::checkArrayElimination): + (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::checkArray): + (JSC::DFG::FixupPhase::blessArrayOperation): + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::byValIsPure): + * dfg/DFGNode.h: + (JSC::DFG::Node::arrayMode): + (JSC::DFG::Node::setArrayMode): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::typedArrayDescriptor): + (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::arrayify): + (JSC::DFG::SpeculativeJIT::compileGetByValOnString): + (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): + (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): + (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): + (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): + (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): + (JSC::DFG::SpeculativeJIT::compileGetArrayLength): + (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister): + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-10-27 Dan Bernstein <mitz@apple.com> + + REAL_PLATFORM_NAME build setting is no longer needed + https://bugs.webkit.org/show_bug.cgi?id=100587 + + Reviewed by Mark Rowe. + + Removed the definition of REAL_PLATFORM_NAME and replaced references to it with references + to PLATFORM_NAME. + + * Configurations/Base.xcconfig: + * Configurations/CompilerVersion.xcconfig: + * Configurations/DebugRelease.xcconfig: + * Configurations/FeatureDefines.xcconfig: + * Configurations/JSC.xcconfig: + * Configurations/JavaScriptCore.xcconfig: + * Configurations/ToolExecutable.xcconfig: + +2012-10-25 Filip Pizlo <fpizlo@apple.com> + + Forward OSR calculation is wrong in the presence of multiple SetLocals, or a mix of SetLocals and Phantoms + https://bugs.webkit.org/show_bug.cgi?id=100461 + + Reviewed by Oliver Hunt and Gavin Barraclough. + + This does a couple of things. First, it removes the part of the change in r131822 that made the forward + OSR exit calculator capable of handling multiple SetLocals. That change was wrong, because it would + blindly assume that all SetLocals had the same ValueRecovery, and would ignore the possibility that if + there is no value recovery then a ForwardCheckStructure on the first SetLocal would not know how to + recover the state associated with the second SetLocal. Then, it introduces the invariant that any bytecode + op that decomposes into multiple SetLocals must first emit dead SetLocals as hints and then emit a second + set of SetLocals to actually do the setting of the locals. This means that if a ForwardCheckStructure (or + any other hoisted forward speculation) is inserted, it will always be inserted on the second set of + SetLocals (since hoisting only touches the live ones), at which point OSR will already know about the + mov hints implied by the first set of (dead) SetLocals. This gives us the behavior we wanted, namely, that + a ForwardCheckStructure applied to a variant set by a resolve_with_base-like operation can correctly do a + forward exit while also ensuring that prior to exiting we set the appropriate locals. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + +2012-10-26 Simon Hausmann <simon.hausmann@digia.com> + + [Qt] Fix the LLInt build on Windows + https://bugs.webkit.org/show_bug.cgi?id=97648 + + Reviewed by Tor Arne Vestbø. + + The main change for the port on Windows is changing the way offsets are extracted + and the LLIntAssembly.h is generated to accomodate release and debug configurations. + + Firstly the LLIntOffsetsExtractor binary is now built as-is (no DESTDIR set) and + placed into debug\LLIntOffsetsExtractor.exe and release\LLIntOffsetsExtractor.exe + on Windows debug_and_release builds. On other patforms it remainds in the regular + out directory. + + Secondly the LLIntAssembly.h files must be different for different build types, + so the LLIntAssembly.h generator in DerivedSources.pri operates no on the extractor + binary files as input. Using a simple exists() check we verify the presence of either + a regular, a debug\LLIntOffsetsExtractor and a release\LLIntOffsetsExtractor binary + and process all of them. The resulting assembly files consequently end up in + generated\debug\LLIntAssembly.h and generated\release\LLIntAssembly.h. + + In Target.pri we have to also make sure that those directories are in the include + path according to the release or debug configuration. + + Lastly a small tweak - swapping WTF.pri and JSC.pri inclusions - in the + LLIntOffsetsExtractor build was needed to make sure that we include + JavaScriptCore/config.h instead of WTF/config.h, required to fix the + build issues originally pasted in bug #97648. + + * DerivedSources.pri: + * JavaScriptCore.pro: + * LLIntOffsetsExtractor.pro: + * Target.pri: + +2012-10-26 Gabor Ballabas <gaborb@inf.u-szeged.hu> + + [Qt] Enable JSC's disassembler on x86, x86_64 Linux + https://bugs.webkit.org/show_bug.cgi?id=100386 + + Reviewed by Simon Hausmann. + + It works fine on Linux x86, x86_64 just needs to be enabled in the + QtWebKit build system. + + * DerivedSources.pri: + * JavaScriptCore.pri: + * Target.pri: + +2012-10-26 Thiago Marcos P. Santos <thiago.santos@intel.com> + + Add feature flags for CSS Device Adaptation + https://bugs.webkit.org/show_bug.cgi?id=95960 + + Reviewed by Kenneth Rohde Christiansen. + + * Configurations/FeatureDefines.xcconfig: + +2012-10-26 Simon Hausmann <simon.hausmann@digia.com> + + [WIN] Make LLInt offsets extractor work on Windows + https://bugs.webkit.org/show_bug.cgi?id=100369 + + Reviewed by Kenneth Rohde Christiansen. + + Open the input file explicitly in binary mode to prevent ruby/Windows from thinking that + it's a text mode file that needs even new line conversions. The binary mode parameter is + ignored on other platforms. + + * offlineasm/offsets.rb: + +2012-10-25 Michael Saboff <msaboff@apple.com> + + SymbolTableIndexHashTraits::needsDestruction should be set to true + https://bugs.webkit.org/show_bug.cgi?id=100437 + + Reviewed by Mark Hahnenberg. + + For correctness, set SymbolTableIndexHashTraits::needsDestruction to true since SymbolTableEntry's do + need to have their destructor called due to the possibility of rare data. + + * runtime/SymbolTable.h: + (SymbolTableIndexHashTraits): + +2012-10-25 Filip Pizlo <fpizlo@apple.com> + + DFG Arrayify elimination should replace it with GetButterfly rather than Phantom + https://bugs.webkit.org/show_bug.cgi?id=100441 + + Reviewed by Oliver Hunt and Gavin Barraclough. + + Made array profiler's to-string helper behave correctly. + + Made Arrayify elimination do the right thing (convert to GetButterfly). + + Made CFA's interference analysis track clobbered array modes correctly, mostly by + simplifying the machinery. + + * bytecode/ArrayProfile.cpp: + (JSC::arrayModesToString): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::clobberArrayModes): + (AbstractValue): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + +2012-10-25 Filip Pizlo <fpizlo@apple.com> + + REGRESSION (r131793-r131826): Crash going to wikifonia.org + https://bugs.webkit.org/show_bug.cgi?id=100281 + + Reviewed by Oliver Hunt. + + Restore something that got lost in the resolve refactoring: the ability to give up on life if + we see a resolve of 'arguments'. + + * runtime/JSScope.cpp: + (JSC::JSScope::resolveContainingScopeInternal): + +2012-10-25 Dominik Röttsches <dominik.rottsches@intel.com> + + Conditionalize XHR timeout support + https://bugs.webkit.org/show_bug.cgi?id=100356 + + Reviewed by Adam Barth. + + Adding XHR_TIMEOUT feature to conditionalize this on ports without network backend support. + + * Configurations/FeatureDefines.xcconfig: + +2012-10-25 Michael Saboff <msaboff@apple.com> + + REGRESSION (r131836): failures in list styles tests on EFL, GTK + https://bugs.webkit.org/show_bug.cgi?id=99824 + + Reviewed by Oliver Hunt. + + Saved start of string since it is modified by call convertUTF8ToUTF16(). + + * API/JSStringRef.cpp: + (JSStringCreateWithUTF8CString): + +2012-10-24 Filip Pizlo <fpizlo@apple.com> + + DFG NewArrayBuffer node should keep its data in a structure on the side to free up one of the opInfos + https://bugs.webkit.org/show_bug.cgi?id=100328 + + Reviewed by Oliver Hunt. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGGraph.h: + (Graph): + * dfg/DFGNode.h: + (NewArrayBufferData): + (DFG): + (JSC::DFG::Node::newArrayBufferData): + (Node): + (JSC::DFG::Node::startConstant): + (JSC::DFG::Node::numConstants): + +2012-10-25 Mark Lam <mark.lam@apple.com> + + Update the C++ llint to work with the latest op_resolve... changes. + https://bugs.webkit.org/show_bug.cgi?id=100345. + + Reviewed by Oliver Hunt. + + * llint/LowLevelInterpreter.cpp: + (JSC::CLoop::execute): + - emit opcode name as label when not using COMPUTED_GOTOs. The new op_resolve + opcodes have jumps to these labels. + - declare all opcode labels as UNUSED_LABEL()s to keep the compiler happy + for opcodes that are not referenced by anyone. + * offlineasm/asm.rb: + - strip llint_ prefix from opcode names used as labels. + +2012-10-24 Yuqiang Xian <yuqiang.xian@intel.com> + + Refactor LLInt64 to distinguish the pointer operations from the 64-bit integer operations + https://bugs.webkit.org/show_bug.cgi?id=100321 + + Reviewed by Filip Pizlo. + + We have refactored the MacroAssembler and JIT compilers to distinguish + the pointer operations from the 64-bit integer operations (see bug #99154). + Now we want to do the similar work for LLInt, and the goal is same as + the one mentioned in 99154. + + This is the first part of the modification: in the offline assembler, + adding the support of the "<foo>q" instructions which will be used for + 64-bit integer operations. + + * llint/LowLevelInterpreter.cpp: + (JSC::CLoop::execute): + * offlineasm/cloop.rb: + * offlineasm/instructions.rb: + * offlineasm/x86.rb: + +2012-10-24 Filip Pizlo <fpizlo@apple.com> + + DFG compileBlahBlahByVal methods for Contiguous and ArrayStorage have only one caller and should be removed + https://bugs.webkit.org/show_bug.cgi?id=100311 + + Reviewed by Mark Hahnenberg. + + Just trying to simplify things before I make them more complicated again. + + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): + * dfg/DFGSpeculativeJIT32_64.cpp: + (DFG): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (DFG): + (JSC::DFG::SpeculativeJIT::compile): + +2012-10-23 Andreas Kling <kling@webkit.org> + + CodeBlock: Give m_putToBaseOperations an inline capacity. + <http://webkit.org/b/100190> + <rdar://problem/12562466> + + Reviewed by Oliver Hunt. + + Since the CodeBlock constructor always inserts a single PutToBaseOperation, but there's no + guarantee that more will follow, give the m_putToBaseOperations vector an inline capacity of 1. + There are 4009 of these Vectors on Membuster3, and only 126 of them have more than a single entry. + + This change yields a 1.90MB reduction in memory usage. + + * bytecode/CodeBlock.h: + (CodeBlock): + +2012-10-23 Christophe Dumez <christophe.dumez@intel.com> + + Regression(r132143): Assertion hit in JSC::Interpreter::StackPolicy::StackPolicy(JSC::Interpreter&, const WTF::StackBounds&) + https://bugs.webkit.org/show_bug.cgi?id=100109 + + Reviewed by Oliver Hunt. + + Fix possible integer overflow in StackPolicy constructor by + using size_t type instead of int for stack sizes. The value + returned by StackBounds::size() is of type size_t but was + assigned to an int, which may overflow. + + * interpreter/Interpreter.cpp: + (JSC): + (JSC::Interpreter::StackPolicy::StackPolicy): + +2012-10-23 Carlos Garcia Campos <cgarcia@igalia.com> + + Unreviewed. Fix make distcheck. + + * GNUmakefile.list.am: Add missing header file. + +2012-10-23 Mark Lam <mark.lam@apple.com> + + Make topCallFrame reliable. + https://bugs.webkit.org/show_bug.cgi?id=98928. + + Reviewed by Geoffrey Garen. + + - VM entry points and the GC now uses topCallFrame. + - The callerFrame value in CallFrames are now always the previous + frame on the stack, except for the first frame which has a + callerFrame of 0 (not counting the HostCallFrameFlag). + Hence, we can now traverse every frame on the stack all the way + back to the first frame. + - GlobalExec's will no longer be used as the callerFrame values in + call frames. + - Added fences and traps for debugging the JSStack in debug builds. + + * bytecode/SamplingTool.h: + (SamplingTool): + (JSC::SamplingTool::CallRecord::CallRecord): + * dfg/DFGOperations.cpp: + - Fixed 2 DFG helper functions to flush topCallFrame as expected. + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::prepareForExternalCall): + * interpreter/CallFrame.h: + (JSC::ExecState::callerFrameNoFlags): + (ExecState): + (JSC::ExecState::argIndexForRegister): + (JSC::ExecState::getArgumentUnsafe): + * interpreter/CallFrameClosure.h: + (CallFrameClosure): + * interpreter/Interpreter.cpp: + (JSC): + (JSC::eval): + (JSC::Interpreter::Interpreter): + (JSC::Interpreter::throwException): + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + (JSC::Interpreter::prepareForRepeatCall): + (JSC::Interpreter::endRepeatCall): + * interpreter/Interpreter.h: + (JSC): + (Interpreter): + * interpreter/JSStack.cpp: + (JSC::JSStack::JSStack): + (JSC::JSStack::gatherConservativeRoots): + (JSC::JSStack::disableErrorStackReserve): + * interpreter/JSStack.h: + (JSC): + (JSStack): + (JSC::JSStack::installFence): + (JSC::JSStack::validateFence): + (JSC::JSStack::installTrapsAfterFrame): + * interpreter/JSStackInlines.h: Added. + (JSC): + (JSC::JSStack::getTopOfFrame): + (JSC::JSStack::getTopOfStack): + (JSC::JSStack::getStartOfFrame): + (JSC::JSStack::pushFrame): + (JSC::JSStack::popFrame): + (JSC::JSStack::generateFenceValue): + (JSC::JSStack::installFence): + (JSC::JSStack::validateFence): + (JSC::JSStack::installTrapsAfterFrame): + * jit/JITStubs.cpp: + (JSC::jitCompileFor): + (JSC::lazyLinkFor): + - Set frame->codeBlock to 0 for both the above because they are called + with partially intitialized frames (cb uninitialized), but may + trigger a GC. + (JSC::DEFINE_STUB_FUNCTION): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + +2012-10-22 Filip Pizlo <fpizlo@apple.com> + + DFG::Array::Undecided should be called DFG::Array::SelectUsingPredictions + https://bugs.webkit.org/show_bug.cgi?id=100052 + + Reviewed by Oliver Hunt. + + No functional change, just renaming. It's a clearer name that more accurately + reflects the meaning, and it eliminates the namespace confusion that will happen + with the Undecided indexing type in https://bugs.webkit.org/show_bug.cgi?id=98606 + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::fromObserved): + (JSC::DFG::refineArrayMode): + (JSC::DFG::modeAlreadyChecked): + (JSC::DFG::modeToString): + * dfg/DFGArrayMode.h: + (JSC::DFG::canCSEStorage): + (JSC::DFG::modeIsSpecific): + (JSC::DFG::modeSupportsLength): + (JSC::DFG::benefitsFromStructureCheck): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::blessArrayOperation): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::arrayify): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-10-22 Mark Lam <mark.lam@apple.com> + + Change stack recursion checks to be based on stack availability. + https://bugs.webkit.org/show_bug.cgi?id=99872. + + Reviewed by Filip Pizlo and Geoffrey Garen. + + - Remove m_reentryDepth, ThreadStackType which are now obsolete. + - Replaced the reentryDepth checks with a StackBounds check. + - Added the Interpreter::StackPolicy class to compute a reasonable + stack capacity requirement given the native stack that the + interpreter is executing on at that time. + - Reserved an amount of JSStack space for the use of error handling + and enable its use (using Interpreter::ErrorHandlingMode) when + we're about to throw or report an exception. + - Interpreter::StackPolicy also allows more native stack space + to be used when in ErrorHandlingMode. This is needed in the case + of native stack overflows. + - Fixed the parser so that it throws a StackOverflowError instead of + a SyntaxError when it encounters a stack overflow. + + * API/JSContextRef.cpp: + (JSContextGroupCreate): + (JSGlobalContextCreateInGroup): + * JavaScriptCore.order: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + * interpreter/Interpreter.cpp: + (JSC::Interpreter::ErrorHandlingMode::ErrorHandlingMode): + (JSC): + (JSC::Interpreter::ErrorHandlingMode::~ErrorHandlingMode): + (JSC::Interpreter::StackPolicy::StackPolicy): + (JSC::Interpreter::Interpreter): + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + (JSC::Interpreter::prepareForRepeatCall): + * interpreter/Interpreter.h: + (JSC): + (Interpreter): + (ErrorHandlingMode): + (StackPolicy): + (JSC::Interpreter::StackPolicy::requiredCapacity): + * interpreter/JSStack.cpp: + (JSC): + (JSC::JSStack::JSStack): + (JSC::JSStack::growSlowCase): + (JSC::JSStack::enableErrorStackReserve): + (JSC::JSStack::disableErrorStackReserve): + * interpreter/JSStack.h: + (JSStack): + (JSC::JSStack::reservationEnd): + (JSC): + * jsc.cpp: + (jscmain): + * parser/Parser.cpp: + (JSC::::Parser): + * parser/Parser.h: + (Parser): + (JSC::::parse): + * runtime/ExceptionHelpers.cpp: + (JSC::throwStackOverflowError): + * runtime/JSGlobalData.cpp: + (JSC::JSGlobalData::JSGlobalData): + (JSC::JSGlobalData::createContextGroup): + (JSC::JSGlobalData::create): + (JSC::JSGlobalData::createLeaked): + (JSC::JSGlobalData::sharedInstance): + * runtime/JSGlobalData.h: + (JSC): + (JSGlobalData): + * runtime/StringRecursionChecker.h: + (JSC::StringRecursionChecker::performCheck): + * testRegExp.cpp: + (realMain): + +2012-10-20 Martin Robinson <mrobinson@igalia.com> + + Fix 'make dist' for the GTK+ port + + * GNUmakefile.list.am: Add missing files to the source list. + +2012-10-21 Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> + + [CMake][JSC] Depend on risc.rb to decide when to run the LLInt scripts. + https://bugs.webkit.org/show_bug.cgi?id=99917 + + Reviewed by Geoffrey Garen. + + Depend on the newly-added risc.rb to make sure we always run the + LLInt scripts when one of them changes. + + * CMakeLists.txt: + +2012-10-20 Filip Pizlo <fpizlo@apple.com> + + LLInt backends of non-ARM RISC platforms should be able to share code with the existing ARMv7 backend + https://bugs.webkit.org/show_bug.cgi?id=99745 + + Reviewed by Geoffrey Garen. + + This moves all of the things in armv7.rb that I thought are generally useful out + into risc.rb. It also separates some phases (branch ops is separated into one + phase that does sensible things, and another that does things that are painfully + ARM-specific), and removes ARM assumptions from others by using a callback to + drive exactly what lowering must happen. The goal here is to minimize the future + maintenance burden of LLInt by ensuring that the various platforms share as much + lowering code as possible. + + * offlineasm/armv7.rb: + * offlineasm/risc.rb: Added. + +2012-10-19 Filip Pizlo <fpizlo@apple.com> + + DFG should have some facility for recognizing redundant CheckArrays and Arrayifies + https://bugs.webkit.org/show_bug.cgi?id=99287 + + Reviewed by Mark Hahnenberg. + + Adds reasoning about indexing type sets (i.e. ArrayModes) to AbstractValue, which + then enables us to fold away CheckArray's and Arrayify's that are redundant. + + * bytecode/ArrayProfile.cpp: + (JSC::arrayModesToString): + (JSC): + * bytecode/ArrayProfile.h: + (JSC): + (JSC::mergeArrayModes): + (JSC::arrayModesAlreadyChecked): + * bytecode/StructureSet.h: + (JSC::StructureSet::arrayModesFromStructures): + (StructureSet): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGAbstractValue.h: + (JSC::DFG::AbstractValue::AbstractValue): + (JSC::DFG::AbstractValue::clear): + (JSC::DFG::AbstractValue::isClear): + (JSC::DFG::AbstractValue::makeTop): + (JSC::DFG::AbstractValue::clobberStructures): + (AbstractValue): + (JSC::DFG::AbstractValue::setMostSpecific): + (JSC::DFG::AbstractValue::set): + (JSC::DFG::AbstractValue::operator==): + (JSC::DFG::AbstractValue::merge): + (JSC::DFG::AbstractValue::filter): + (JSC::DFG::AbstractValue::filterArrayModes): + (JSC::DFG::AbstractValue::validate): + (JSC::DFG::AbstractValue::checkConsistency): + (JSC::DFG::AbstractValue::dump): + (JSC::DFG::AbstractValue::clobberArrayModes): + (JSC::DFG::AbstractValue::clobberArrayModesSlow): + (JSC::DFG::AbstractValue::setFuturePossibleStructure): + (JSC::DFG::AbstractValue::filterFuturePossibleStructure): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::modeAlreadyChecked): + * dfg/DFGArrayMode.h: + (JSC::DFG::arrayModesFor): + (DFG): + * dfg/DFGConstantFoldingPhase.cpp: + (JSC::DFG::ConstantFoldingPhase::foldConstants): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::arrayify): + +2012-10-19 Filip Pizlo <fpizlo@apple.com> + + Baseline JIT should not inline array allocations, to make them easier to instrument + https://bugs.webkit.org/show_bug.cgi?id=99905 + + Reviewed by Mark Hahnenberg. + + This will make it easier to instrument array allocations for the purposes of profiling. + It also allows us to kill off a bunch of code. And, this doesn't appear to hurt + performance at all. That's expected because these days any hot allocation will end up + in the DFG JIT, which does inline these allocations. + + * jit/JIT.cpp: + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + (JIT): + * jit/JITInlineMethods.h: + (JSC): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_new_array): + +2012-10-19 Oliver Hunt <oliver@apple.com> + + Fix some of the regression cause by the non-local variable reworking + https://bugs.webkit.org/show_bug.cgi?id=99896 + + Reviewed by Filip Pizlo. + + The non0local variable reworking led to some of the optimisations performed by + the bytecode generator being dropped. This in turn put more pressure on the DFG + optimisations. This exposed a short coming in our double speculation propogation. + Now we try to distinguish between places where we should SpecDoubleReal vs generic + SpecDouble. + + * dfg/DFGPredictionPropagationPhase.cpp: + (PredictionPropagationPhase): + (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPrediction): + (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPredictions): + (JSC::DFG::PredictionPropagationPhase::propagate): + +2012-10-19 Michael Saboff <msaboff@apple.com> + + Lexer should create 8 bit Identifiers for RegularExpressions and ASCII identifiers + https://bugs.webkit.org/show_bug.cgi?id=99855 + + Reviewed by Filip Pizlo. + + Added makeIdentifier helpers that will always make an 8 bit Identifier or make an + Identifier that is the same size as the template parameter. Used the first in the fast + path when looking for a JS identifier and the second when scanning regular expressions. + + * parser/Lexer.cpp: + (JSC::::scanRegExp): + * parser/Lexer.h: + (Lexer): + (JSC::::makeIdentifierSameType): + (JSC::::makeLCharIdentifier): + (JSC::::lexExpectIdentifier): + +2012-10-19 Mark Lam <mark.lam@apple.com> + + Added WTF::StackStats mechanism. + https://bugs.webkit.org/show_bug.cgi?id=99805. + + Reviewed by Geoffrey Garen. + + Added StackStats checkpoints and probes. + + * bytecompiler/BytecodeGenerator.h: + (JSC::BytecodeGenerator::emitNode): + (JSC::BytecodeGenerator::emitNodeInConditionContext): + * heap/SlotVisitor.cpp: + (JSC::SlotVisitor::append): + (JSC::visitChildren): + (JSC::SlotVisitor::donateKnownParallel): + (JSC::SlotVisitor::drain): + (JSC::SlotVisitor::drainFromShared): + (JSC::SlotVisitor::mergeOpaqueRoots): + (JSC::SlotVisitor::internalAppend): + (JSC::SlotVisitor::harvestWeakReferences): + (JSC::SlotVisitor::finalizeUnconditionalFinalizers): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + (JSC::Interpreter::prepareForRepeatCall): + * parser/Parser.h: + (JSC::Parser::canRecurse): + * runtime/StringRecursionChecker.h: + (StringRecursionChecker): + +2012-10-19 Oliver Hunt <oliver@apple.com> + + REGRESSION(r131822): It made 500+ tests crash on 32 bit platforms + https://bugs.webkit.org/show_bug.cgi?id=99814 + + Reviewed by Filip Pizlo. + + Call the correct macro in 32bit. + + * llint/LowLevelInterpreter.asm: + +2012-10-19 Dongwoo Joshua Im <dw.im@samsung.com> + + Rename ENABLE_CSS3_TEXT_DECORATION to ENABLE_CSS3_TEXT + https://bugs.webkit.org/show_bug.cgi?id=99804 + + Reviewed by Julien Chaffraix. + + CSS3 text related properties will be implemented under this flag, + including text decoration, text-align-last, and text-justify. + + * Configurations/FeatureDefines.xcconfig: + +2012-10-18 Anders Carlsson <andersca@apple.com> + + Clean up RegExpKey + https://bugs.webkit.org/show_bug.cgi?id=99798 + + Reviewed by Darin Adler. + + RegExpHash doesn't need to be a class template specialization when the class template is specialized + for JSC::RegExpKey only. Make it a nested class of RegExp instead. Also, make operator== a friend function + so Hash::equal can see it. + + * runtime/RegExpKey.h: + (JSC::RegExpKey::RegExpKey): + (JSC::RegExpKey::operator==): + (RegExpKey): + (JSC::RegExpKey::Hash::hash): + (JSC::RegExpKey::Hash::equal): + (Hash): + +2012-10-19 Mark Lam <mark.lam@apple.com> + + Bot greening: Follow up to r131877 to fix the Windows build. + https://bugs.webkit.org/show_bug.cgi?id=99739. + + Not reviewed. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-10-19 Mark Lam <mark.lam@apple.com> + + Bot greening: Attempt to fix broken Window build after r131836. + https://bugs.webkit.org/show_bug.cgi?id=99739. + + Not reviewed. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-10-19 Yuqiang Xian <yuqiang.xian@intel.com> + + Unreviewed fix after r131868. + + On JSVALUE64 platforms, JSValue constants can be Imm64 instead of ImmPtr for JIT compilers. + + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + +2012-10-18 Filip Pizlo <fpizlo@apple.com> + + Baseline array profiling should be less accurate, and DFG OSR exit should update array profiles on CheckArray and CheckStructure failure + https://bugs.webkit.org/show_bug.cgi?id=99261 + + Reviewed by Oliver Hunt. + + This makes array profiling stochastic, like value profiling. The point is to avoid + noticing one-off indexing types that we'll never see again, but instead to: + + Notice the big ones: We want the DFG to compile based on the things that happen with + high probability. So, this change makes array profiling do like value profiling and + only notice a random subsampling of indexing types that flowed through an array + access. Prior to this patch array profiles noticed all indexing types and weighted + them identically. + + Bias the recent: Often an array access will see awkward indexing types during the + first handful of executions because of artifacts of program startup. So, we want to + bias towards the indexing types that we saw most recently. With this change, array + profiling does like value profiling and usually tells use a random sampling that + is biased to what happened recently. + + Have a backup plan: The above two things don't work by themselves because our + randomness is not that random (nor do we care enough to make it more random), and + because some procedures will have a <1/10 probability event that we must handle + without bailing because it dominates a hot loop. So, like value profiling, this + patch makes array profiling use OSR exits to tell us why we are bailing out, so + that we don't make the same mistake again in the future. + + This change also makes the way that the 32-bit OSR exit compiler snatches scratch + registers more uniform. We don't need a scratch buffer when we can push and pop. + + * bytecode/DFGExitProfile.h: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::arrayify): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITInlineMethods.h: + (JSC::JIT::emitArrayProfilingSite): + * llint/LowLevelInterpreter.asm: + +2012-10-18 Yuqiang Xian <yuqiang.xian@intel.com> + + [Qt] REGRESSION(r131858): It broke the ARM build + https://bugs.webkit.org/show_bug.cgi?id=99809 + + Reviewed by Csaba Osztrogonác. + + * dfg/DFGCCallHelpers.h: + (CCallHelpers): + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + +2012-10-18 Yuqiang Xian <yuqiang.xian@intel.com> + + Refactor MacroAssembler interfaces to differentiate the pointer operands from the 64-bit integer operands + https://bugs.webkit.org/show_bug.cgi?id=99154 + + Reviewed by Gavin Barraclough. + + In current JavaScriptCore implementation for JSVALUE64 platform (i.e., + the X64 platform), we assume that the JSValue size is same to the + pointer size, and thus EncodedJSValue is simply type defined as a + "void*". In the JIT compiler, we also take this assumption and invoke + the same macro assembler interfaces for both JSValue and pointer + operands. We need to differentiate the operations on pointers from the + operations on JSValues, and let them invoking different macro + assembler interfaces. For example, we now use the interface of + "loadPtr" to load either a pointer or a JSValue, and we need to switch + to using "loadPtr" to load a pointer and some new "load64" interface + to load a JSValue. This would help us supporting other JSVALUE64 + platforms where pointer size is not necessarily 64-bits, for example + x32 (bug #99153). + + The major modification I made is to introduce the "*64" interfaces in + the MacroAssembler for those operations on JSValues, keep the "*Ptr" + interfaces for those operations on real pointers, and go through all + the JIT compiler code to correct the usage. + + This is the second part of the work, i.e, to correct the usage of the + new MacroAssembler interfaces in the JIT compilers, which also means + that now EncodedJSValue is defined as a 64-bit integer, and the "*64" + interfaces are used for it. + + * assembler/MacroAssembler.h: JSValue immediates should be in Imm64 instead of ImmPtr. + (MacroAssembler): + (JSC::MacroAssembler::shouldBlind): + * dfg/DFGAssemblyHelpers.cpp: Correct the JIT compilers usage of the new interfaces. + (JSC::DFG::AssemblyHelpers::jitAssertIsInt32): + (JSC::DFG::AssemblyHelpers::jitAssertIsJSInt32): + (JSC::DFG::AssemblyHelpers::jitAssertIsJSNumber): + (JSC::DFG::AssemblyHelpers::jitAssertIsJSDouble): + (JSC::DFG::AssemblyHelpers::jitAssertIsCell): + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::emitPutToCallFrameHeader): + (JSC::DFG::AssemblyHelpers::branchIfNotCell): + (JSC::DFG::AssemblyHelpers::debugCall): + (JSC::DFG::AssemblyHelpers::boxDouble): + (JSC::DFG::AssemblyHelpers::unboxDouble): + (JSC::DFG::AssemblyHelpers::emitExceptionCheck): + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + (CCallHelpers): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGRepatch.cpp: + (JSC::DFG::generateProtoChainAccessStub): + (JSC::DFG::tryCacheGetByID): + (JSC::DFG::tryBuildGetByIDList): + (JSC::DFG::emitPutReplaceStub): + (JSC::DFG::emitPutTransitionStub): + * dfg/DFGScratchRegisterAllocator.h: + (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer): + (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer): + * dfg/DFGSilentRegisterSavePlan.h: + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + (JSC::DFG::SpeculativeJIT::compileValueToInt32): + (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): + (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): + (JSC::DFG::SpeculativeJIT::compileInstanceOf): + (JSC::DFG::SpeculativeJIT::compileStrictEqForConstant): + (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR): + (JSC::DFG::SpeculativeJIT::silentSpill): + (JSC::DFG::SpeculativeJIT::silentFill): + (JSC::DFG::SpeculativeJIT::spill): + (JSC::DFG::SpeculativeJIT::valueOfJSConstantAsImm64): + (JSC::DFG::SpeculativeJIT::callOperation): + (JSC::DFG::SpeculativeJIT::branch64): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::fillDouble): + (JSC::DFG::SpeculativeJIT::fillJSValue): + (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToNumber): + (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToInt32): + (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber): + (JSC::DFG::SpeculativeJIT::cachedGetById): + (JSC::DFG::SpeculativeJIT::cachedPutById): + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): + (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): + (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): + (JSC::DFG::SpeculativeJIT::emitCall): + (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal): + (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): + (JSC::DFG::SpeculativeJIT::fillSpeculateCell): + (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): + (JSC::DFG::SpeculativeJIT::convertToDouble): + (JSC::DFG::SpeculativeJIT::compileObjectEquality): + (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): + (JSC::DFG::SpeculativeJIT::compileDoubleCompare): + (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot): + (JSC::DFG::SpeculativeJIT::compileLogicalNot): + (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch): + (JSC::DFG::SpeculativeJIT::emitBranch): + (JSC::DFG::SpeculativeJIT::compileContiguousGetByVal): + (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal): + (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): + (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGThunks.cpp: + (JSC::DFG::osrExitGenerationThunkGenerator): + (JSC::DFG::throwExceptionFromCallSlowPathGenerator): + (JSC::DFG::slowPathFor): + (JSC::DFG::virtualForThunkGenerator): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::dumpRegisters): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + * jit/JIT.h: + (JIT): + * jit/JITArithmetic.cpp: + (JSC::JIT::emit_op_negate): + (JSC::JIT::emitSlow_op_negate): + (JSC::JIT::emit_op_rshift): + (JSC::JIT::emitSlow_op_urshift): + (JSC::JIT::emit_compareAndJumpSlow): + (JSC::JIT::emit_op_bitand): + (JSC::JIT::compileBinaryArithOpSlowCase): + (JSC::JIT::emit_op_div): + * jit/JITCall.cpp: + (JSC::JIT::compileLoadVarargs): + (JSC::JIT::compileCallEval): + (JSC::JIT::compileCallEvalSlowCase): + (JSC::JIT::compileOpCall): + * jit/JITInlineMethods.h: Have some clean-up work as well. + (JSC): + (JSC::JIT::emitPutCellToCallFrameHeader): + (JSC::JIT::emitPutIntToCallFrameHeader): + (JSC::JIT::emitPutToCallFrameHeader): + (JSC::JIT::emitGetFromCallFrameHeader32): + (JSC::JIT::emitGetFromCallFrameHeader64): + (JSC::JIT::emitAllocateJSArray): + (JSC::JIT::emitValueProfilingSite): + (JSC::JIT::emitGetJITStubArg): + (JSC::JIT::emitGetVirtualRegister): + (JSC::JIT::emitPutVirtualRegister): + (JSC::JIT::emitInitRegister): + (JSC::JIT::emitJumpIfJSCell): + (JSC::JIT::emitJumpIfBothJSCells): + (JSC::JIT::emitJumpIfNotJSCell): + (JSC::JIT::emitLoadInt32ToDouble): + (JSC::JIT::emitJumpIfImmediateInteger): + (JSC::JIT::emitJumpIfNotImmediateInteger): + (JSC::JIT::emitJumpIfNotImmediateIntegers): + (JSC::JIT::emitFastArithReTagImmediate): + (JSC::JIT::emitFastArithIntToImmNoCheck): + * jit/JITOpcodes.cpp: + (JSC::JIT::privateCompileCTINativeCall): + (JSC::JIT::emit_op_mov): + (JSC::JIT::emit_op_instanceof): + (JSC::JIT::emit_op_is_undefined): + (JSC::JIT::emit_op_is_boolean): + (JSC::JIT::emit_op_is_number): + (JSC::JIT::emit_op_tear_off_activation): + (JSC::JIT::emit_op_not): + (JSC::JIT::emit_op_jfalse): + (JSC::JIT::emit_op_jeq_null): + (JSC::JIT::emit_op_jneq_null): + (JSC::JIT::emit_op_jtrue): + (JSC::JIT::emit_op_bitxor): + (JSC::JIT::emit_op_bitor): + (JSC::JIT::emit_op_get_pnames): + (JSC::JIT::emit_op_next_pname): + (JSC::JIT::compileOpStrictEq): + (JSC::JIT::emit_op_catch): + (JSC::JIT::emit_op_throw_static_error): + (JSC::JIT::emit_op_eq_null): + (JSC::JIT::emit_op_neq_null): + (JSC::JIT::emit_op_create_activation): + (JSC::JIT::emit_op_create_arguments): + (JSC::JIT::emit_op_init_lazy_reg): + (JSC::JIT::emitSlow_op_convert_this): + (JSC::JIT::emitSlow_op_not): + (JSC::JIT::emit_op_get_argument_by_val): + (JSC::JIT::emit_op_put_to_base): + (JSC::JIT::emit_resolve_operations): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emitArrayStorageGetByVal): + (JSC::JIT::emitSlow_op_get_by_val): + (JSC::JIT::compileGetDirectOffset): + (JSC::JIT::emit_op_get_by_pname): + (JSC::JIT::emitContiguousPutByVal): + (JSC::JIT::emitArrayStoragePutByVal): + (JSC::JIT::compileGetByIdHotPath): + (JSC::JIT::emit_op_put_by_id): + (JSC::JIT::compilePutDirectOffset): + (JSC::JIT::emit_op_init_global_const): + (JSC::JIT::emit_op_init_global_const_check): + (JSC::JIT::emitIntTypedArrayGetByVal): + (JSC::JIT::emitFloatTypedArrayGetByVal): + (JSC::JIT::emitFloatTypedArrayPutByVal): + * jit/JITStubCall.h: + (JITStubCall): + (JSC::JITStubCall::JITStubCall): + (JSC::JITStubCall::addArgument): + (JSC::JITStubCall::call): + (JSC::JITStubCall::callWithValueProfiling): + * jit/JSInterfaceJIT.h: + (JSC::JSInterfaceJIT::emitJumpIfImmediateNumber): + (JSC::JSInterfaceJIT::emitJumpIfNotImmediateNumber): + (JSC::JSInterfaceJIT::emitLoadJSCell): + (JSC::JSInterfaceJIT::emitLoadInt32): + (JSC::JSInterfaceJIT::emitLoadDouble): + * jit/SpecializedThunkJIT.h: + (JSC::SpecializedThunkJIT::returnDouble): + (JSC::SpecializedThunkJIT::tagReturnAsInt32): + * runtime/JSValue.cpp: + (JSC::JSValue::description): + * runtime/JSValue.h: Define JSVALUE64 EncodedJSValue as int64_t, which is also unified with JSVALUE32_64. + (JSC): + * runtime/JSValueInlineMethods.h: New implementation of some JSValue methods to make them more conformant + with the new rule that "JSValue is a 64-bit integer rather than a pointer" for JSVALUE64 platforms. + (JSC): + (JSC::JSValue::JSValue): + (JSC::JSValue::operator bool): + (JSC::JSValue::operator==): + (JSC::JSValue::operator!=): + (JSC::reinterpretDoubleToInt64): + (JSC::reinterpretInt64ToDouble): + (JSC::JSValue::asDouble): + +2012-10-18 Michael Saboff <msaboff@apple.com> + + convertUTF8ToUTF16() Should Check for ASCII Input + ihttps://bugs.webkit.org/show_bug.cgi?id=99739 + + Reviewed by Geoffrey Garen. + + Using the updated convertUTF8ToUTF16() , we can determine if is makes more sense to + create a string using the 8 bit source. Added a new OpaqueJSString::create(LChar*, unsigned). + Had to add a cast n JSStringCreateWithCFString to differentiate which create() to call. + + * API/JSStringRef.cpp: + (JSStringCreateWithUTF8CString): + * API/JSStringRefCF.cpp: + (JSStringCreateWithCFString): + * API/OpaqueJSString.h: + (OpaqueJSString::create): + (OpaqueJSString): + (OpaqueJSString::OpaqueJSString): + +2012-10-18 Oliver Hunt <oliver@apple.com> + + Unbreak jsc tests. Last minute "clever"-ness is clearly just not + a good plan. + + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + +2012-10-18 Oliver Hunt <oliver@apple.com> + + Bytecode should not have responsibility for determining how to perform non-local resolves + https://bugs.webkit.org/show_bug.cgi?id=99349 + + Reviewed by Gavin Barraclough. + + This patch removes lexical analysis from the bytecode generation. This allows + us to delay lookup of a non-local variables until the lookup is actually necessary, + and simplifies a lot of the resolve logic in BytecodeGenerator. + + Once a lookup is performed we cache the lookup information in a set of out-of-line + buffers in CodeBlock. This allows subsequent lookups to avoid unnecessary hashing, + etc, and allows the respective JITs to recreated optimal lookup code. + + This is currently still a performance regression in LLInt, but most of the remaining + regression is caused by a lot of indirection that I'll remove in future work, as well + as some work necessary to allow LLInt to perform in line instruction repatching. + We will also want to improve the behaviour of the baseline JIT for some of the lookup + operations, however this patch was getting quite large already so I'm landing it now + that we've reached the bar of "performance-neutral". + + Basic browsing seems to work. + + * GNUmakefile.list.am: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printStructures): + (JSC::CodeBlock::dump): + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::visitStructures): + (JSC): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::shrinkToFit): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::addResolve): + (JSC::CodeBlock::addPutToBase): + (CodeBlock): + (JSC::CodeBlock::resolveOperations): + (JSC::CodeBlock::putToBaseOperation): + (JSC::CodeBlock::numberOfResolveOperations): + (JSC::CodeBlock::numberOfPutToBaseOperations): + (JSC::CodeBlock::addPropertyAccessInstruction): + (JSC::CodeBlock::globalObjectConstant): + (JSC::CodeBlock::setGlobalObjectConstant): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/ResolveGlobalStatus.cpp: + (JSC::computeForStructure): + (JSC::ResolveGlobalStatus::computeFor): + * bytecode/ResolveGlobalStatus.h: + (JSC): + (ResolveGlobalStatus): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::ResolveResult::checkValidity): + (JSC): + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::resolveConstDecl): + (JSC::BytecodeGenerator::shouldAvoidResolveGlobal): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveBase): + (JSC::BytecodeGenerator::emitResolveBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetLocalVar): + (JSC::BytecodeGenerator::emitInitGlobalConst): + (JSC::BytecodeGenerator::emitPutToBase): + * bytecompiler/BytecodeGenerator.h: + (JSC::ResolveResult::registerResolve): + (JSC::ResolveResult::dynamicResolve): + (ResolveResult): + (JSC::ResolveResult::ResolveResult): + (JSC): + (NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::~NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::resolved): + (JSC::NonlocalResolveInfo::put): + (BytecodeGenerator): + (JSC::BytecodeGenerator::getResolveOperations): + (JSC::BytecodeGenerator::getResolveWithThisOperations): + (JSC::BytecodeGenerator::getResolveBaseOperations): + (JSC::BytecodeGenerator::getResolveBaseForPutOperations): + (JSC::BytecodeGenerator::getResolveWithBaseForPutOperations): + (JSC::BytecodeGenerator::getPutToBaseOperation): + * bytecompiler/NodesCodegen.cpp: + (JSC::ResolveNode::isPure): + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::PostfixNode::emitResolve): + (JSC::PrefixNode::emitResolve): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): + (JSC::ConstDeclNode::emitCodeSingle): + (JSC::ForInNode::emitBytecode): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::handleGetByOffset): + (DFG): + (JSC::DFG::ByteCodeParser::parseResolveOperations): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCapabilities.h: + (JSC::DFG::canInlineResolveOperations): + (DFG): + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canInlineOpcode): + * dfg/DFGGraph.h: + (ResolveGlobalData): + (ResolveOperationData): + (DFG): + (PutToBaseOperationData): + (Graph): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasIdentifier): + (JSC::DFG::Node::resolveOperationsDataIndex): + (Node): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::resolveOperations): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::putToBaseOperation): + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + (JIT): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_put_to_base): + (JSC): + (JSC::JIT::emit_resolve_operations): + (JSC::JIT::emitSlow_link_resolve_operations): + (JSC::JIT::emit_op_resolve): + (JSC::JIT::emitSlow_op_resolve): + (JSC::JIT::emit_op_resolve_base): + (JSC::JIT::emitSlow_op_resolve_base): + (JSC::JIT::emit_op_resolve_with_base): + (JSC::JIT::emitSlow_op_resolve_with_base): + (JSC::JIT::emit_op_resolve_with_this): + (JSC::JIT::emitSlow_op_resolve_with_this): + (JSC::JIT::emitSlow_op_put_to_base): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_put_to_base): + (JSC): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_init_global_const): + (JSC::JIT::emit_op_init_global_const_check): + (JSC::JIT::emitSlow_op_init_global_const_check): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_init_global_const): + (JSC::JIT::emit_op_init_global_const_check): + (JSC::JIT::emitSlow_op_init_global_const_check): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + (JSC): + * jit/JITStubs.h: + * llint/LLIntSlowPaths.cpp: + (LLInt): + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSScope.cpp: + (JSC::LookupResult::base): + (JSC::LookupResult::value): + (JSC::LookupResult::setBase): + (JSC::LookupResult::setValue): + (LookupResult): + (JSC): + (JSC::setPutPropertyAccessOffset): + (JSC::executeResolveOperations): + (JSC::JSScope::resolveContainingScopeInternal): + (JSC::JSScope::resolveContainingScope): + (JSC::JSScope::resolve): + (JSC::JSScope::resolveBase): + (JSC::JSScope::resolveWithBase): + (JSC::JSScope::resolveWithThis): + (JSC::JSScope::resolvePut): + (JSC::JSScope::resolveGlobal): + * runtime/JSScope.h: + (JSScope): + * runtime/JSVariableObject.cpp: + (JSC): + * runtime/JSVariableObject.h: + (JSVariableObject): + * runtime/Structure.h: + (JSC::Structure::propertyAccessesAreCacheable): + (Structure): + +2012-10-18 Mark Hahnenberg <mhahnenberg@apple.com> + + Live oversize copied blocks should count toward overall heap fragmentation + https://bugs.webkit.org/show_bug.cgi?id=99548 + + Reviewed by Filip Pizlo. + + The CopiedSpace uses overall heap fragmentation to determine whether or not it should do any copying. + Currently it doesn't include live oversize CopiedBlocks in the calculation, but it should. We should + treat them as 100% utilized, since running a copying phase won't be able to free/compact any of their + memory. We can also free any dead oversize CopiedBlocks while we're iterating over them, rather than + iterating over them again at the end of the copying phase. + + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::doneFillingBlock): + (JSC::CopiedSpace::startedCopying): + (JSC::CopiedSpace::doneCopying): Also removed a branch when iterating over from-space at the end of + copying. Since we eagerly recycle blocks as soon as they're fully evacuated, we should see no + unpinned blocks in from-space at the end of copying. + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::recycleBorrowedBlock): + * heap/CopyVisitorInlineMethods.h: + (JSC::CopyVisitor::checkIfShouldCopy): + +2012-10-18 Roger Fong <roger_fong@apple.com> + + Unreviewed. Build fix after r131701 and r131777. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-10-18 Mark Hahnenberg <mhahnenberg@apple.com> + + Race condition between GCThread and main thread during copying phase + https://bugs.webkit.org/show_bug.cgi?id=99641 + + Reviewed by Filip Pizlo. + + When a GCThread returns from copyFromShared(), it then calls doneCopying(), which returns + its borrowed CopiedBlock to the CopiedSpace. This final block allows the CopiedSpace to + continue and finish the cleanup of the copying phase. However, the GCThread can loop back + around, see that m_currentPhase is still "Copy", and try to go through the copying phase again. + This can cause all sorts of issues. To fix this, we should add a cyclic barrier to GCThread::waitForNextPhase(). + + * heap/GCThread.cpp: + (JSC::GCThread::waitForNextPhase): All GCThreads will wait when they finish one iteration until the main thread + notifies them to move down to the second while loop, where they wait for the next GCPhase to start. They also + decrement the m_numberOfActiveGCThreads counter as they begin to wait for the next phase and increment it as + they enter the next phase. This allows the main thread to wait in endCurrentPhase() until all the threads have + finished the current phase and are waiting on the next phase to begin. Without the counter, there would be + no way to ensure that every thread was available for each GCPhase. + (JSC::GCThread::gcThreadMain): We now use the m_phaseLock to synchronize with the main thread when we're being created. + * heap/GCThreadSharedData.cpp: + (JSC::GCThreadSharedData::GCThreadSharedData): As we create each GCThread, we increment the m_numberOfActiveGCThreads + counter. When we are done creating the threads, we wait until they're all waiting for the next GCPhase. This prevents + us from leaving some GCThreads behind during the first GCPhase, which could hurt us on our very short-running + benchmarks (e.g. SunSpider). + (JSC::GCThreadSharedData::~GCThreadSharedData): + (JSC::GCThreadSharedData::startNextPhase): We atomically swap the two flags, m_gcThreadsShouldWait and m_currentPhase, + so that if the threads finish very quickly, they will wait until the main thread is ready to end the current phase. + (JSC::GCThreadSharedData::endCurrentPhase): Here atomically we swap the two flags again to allow the threads to + advance to waiting on the next GCPhase. We wait until all of the GCThreads have settled into the second wait loop + before allowing the main thread to continue. This prevents us from leaving one of the GCThreads stuck in the first + wait loop if we were to call startNextPhase() before it had time to wake up and move on to the second wait loop. + (JSC): + (JSC::GCThreadSharedData::didStartMarking): We now use startNextPhase() to properly swap the flags. + (JSC::GCThreadSharedData::didFinishMarking): Ditto for endCurrentPhase(). + (JSC::GCThreadSharedData::didStartCopying): Ditto. + (JSC::GCThreadSharedData::didFinishCopying): Ditto. + * heap/GCThreadSharedData.h: + (GCThreadSharedData): + * heap/Heap.cpp: + (JSC::Heap::copyBackingStores): No reason to use the extra reference. + +2012-10-18 Pablo Flouret <pablof@motorola.com> + + Implement css3-conditional's @supports rule + https://bugs.webkit.org/show_bug.cgi?id=86146 + + Reviewed by Antti Koivisto. + + * Configurations/FeatureDefines.xcconfig: + Add an ENABLE_CSS3_CONDITIONAL_RULES flag. + +2012-10-18 Michael Saboff <msaboff@apple.com> + + Make conversion between JSStringRef and WKStringRef work without character size conversions + https://bugs.webkit.org/show_bug.cgi?id=99727 + + Reviewed by Anders Carlsson. + + Export the string() method for use in WebKit. + + * API/OpaqueJSString.h: + (OpaqueJSString::string): + +2012-10-18 Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> + + [CMake] Avoid unnecessarily running the LLInt generation commands. + https://bugs.webkit.org/show_bug.cgi?id=99708 + + Reviewed by Rob Buis. + + As described in the comments in the change itself, in some cases + the Ruby generation scripts used when LLInt is on would each be + run twice in every build even if nothing had changed. + + Fix that by not setting the OBJECT_DEPENDS property of some source + files to depend on the generated headers; instead, they are now + just part of the final binaries/libraries which use them. + + * CMakeLists.txt: + +2012-10-17 Zoltan Horvath <zoltan@webkit.org> + + Remove the JSHeap memory measurement of the PageLoad performacetests since it creates bogus JSGlobalDatas + https://bugs.webkit.org/show_bug.cgi?id=99609 + + Reviewed by Ryosuke Niwa. + + Remove the implementation since it creates bogus JSGlobalDatas in the layout tests. + + * heap/HeapStatistics.cpp: + (JSC): + * heap/HeapStatistics.h: + (HeapStatistics): + +2012-10-17 Sam Weinig <sam@webkit.org> + + Attempt to fix the build. + + * bytecode/GlobalResolveInfo.h: Copied from bytecode/GlobalResolveInfo.h. + +2012-10-17 Filip Pizlo <fpizlo@apple.com> + + REGRESSION (r130826 or r130828): Twitter top bar is dysfunctional + https://bugs.webkit.org/show_bug.cgi?id=99577 + <rdar://problem/12518883> + + Reviewed by Mark Hahnenberg. + + It turns out that it's a good idea to maintain the invariants of your object model, such as that + elements past publicLength should have the hole value. + + * dfg/DFGGraph.cpp: + (JSC::DFG::Graph::dump): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-10-17 Anders Carlsson <andersca@apple.com> + + Clean up Vector.h + https://bugs.webkit.org/show_bug.cgi?id=99622 + + Reviewed by Benjamin Poulain. + + Fix fallout from removing std::max and std::min using declarations. + + * runtime/StringPrototype.cpp: + (JSC::jsSpliceSubstrings): + (JSC::jsSpliceSubstringsWithSeparators): + (JSC::stringProtoFuncIndexOf): + * yarr/YarrPattern.cpp: + (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets): + +2012-10-17 Oliver Hunt <oliver@apple.com> + + Committing new files is so overrated. + + * bytecode/ResolveOperation.h: Added. + (JSC): + (JSC::ResolveOperation::getAndReturnScopedVar): + (JSC::ResolveOperation::checkForDynamicEntriesBeforeGlobalScope): + (ResolveOperation): + (JSC::ResolveOperation::getAndReturnGlobalVar): + (JSC::ResolveOperation::getAndReturnGlobalProperty): + (JSC::ResolveOperation::resolveFail): + (JSC::ResolveOperation::skipTopScopeNode): + (JSC::ResolveOperation::skipScopes): + (JSC::ResolveOperation::returnGlobalObjectAsBase): + (JSC::ResolveOperation::setBaseToGlobal): + (JSC::ResolveOperation::setBaseToUndefined): + (JSC::ResolveOperation::setBaseToScope): + (JSC::ResolveOperation::returnScopeAsBase): + (JSC::PutToBaseOperation::PutToBaseOperation): + +2012-10-17 Michael Saboff <msaboff@apple.com> + + StringPrototype::jsSpliceSubstringsWithSeparators() doesn't optimally handle 8 bit strings + https://bugs.webkit.org/show_bug.cgi?id=99230 + + Reviewed by Geoffrey Garen. + + Added code to select characters8() or characters16() on the not all 8 bit path for both the + processing of the source and the separators. + + * runtime/StringPrototype.cpp: + (JSC::jsSpliceSubstringsWithSeparators): + +2012-10-17 Filip Pizlo <fpizlo@apple.com> + + Array and object allocations via 'new Object' or 'new Array' should be inlined in bytecode to allow allocation site profiling + https://bugs.webkit.org/show_bug.cgi?id=99557 + + Reviewed by Geoffrey Garen. + + Removed an inaccurate and misleading comment as per Geoff's review. (I forgot + to make this change as part of http://trac.webkit.org/changeset/131644). + + * bytecompiler/NodesCodegen.cpp: + (JSC::FunctionCallResolveNode::emitBytecode): + +2012-10-17 Oliver Hunt <oliver@apple.com> + + Bytecode should not have responsibility for determining how to perform non-local resolves + https://bugs.webkit.org/show_bug.cgi?id=99349 + + Reviewed by Gavin Barraclough. + + This patch removes lexical analysis from the bytecode generation. This allows + us to delay lookup of a non-local variables until the lookup is actually necessary, + and simplifies a lot of the resolve logic in BytecodeGenerator. + + Once a lookup is performed we cache the lookup information in a set of out-of-line + buffers in CodeBlock. This allows subsequent lookups to avoid unnecessary hashing, + etc, and allows the respective JITs to recreated optimal lookup code. + + This is currently still a performance regression in LLInt, but most of the remaining + regression is caused by a lot of indirection that I'll remove in future work, as well + as some work necessary to allow LLInt to perform in line instruction repatching. + We will also want to improve the behaviour of the baseline JIT for some of the lookup + operations, however this patch was getting quite large already so I'm landing it now + that we've reached the bar of "performance-neutral". + + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printStructures): + (JSC::CodeBlock::dump): + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::visitStructures): + (JSC): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::shrinkToFit): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::addResolve): + (JSC::CodeBlock::addPutToBase): + (CodeBlock): + (JSC::CodeBlock::resolveOperations): + (JSC::CodeBlock::putToBaseOperation): + (JSC::CodeBlock::numberOfResolveOperations): + (JSC::CodeBlock::numberOfPutToBaseOperations): + (JSC::CodeBlock::addPropertyAccessInstruction): + (JSC::CodeBlock::globalObjectConstant): + (JSC::CodeBlock::setGlobalObjectConstant): + * bytecode/GlobalResolveInfo.h: Removed. + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/ResolveGlobalStatus.cpp: + (JSC::computeForStructure): + (JSC::ResolveGlobalStatus::computeFor): + * bytecode/ResolveGlobalStatus.h: + (JSC): + (ResolveGlobalStatus): + * bytecode/ResolveOperation.h: Added. + The new types and logic we use to perform the cached lookups. + (JSC): + (ResolveOperation): + (JSC::ResolveOperation::getAndReturnScopedVar): + (JSC::ResolveOperation::checkForDynamicEntriesBeforeGlobalScope): + (JSC::ResolveOperation::getAndReturnGlobalVar): + (JSC::ResolveOperation::getAndReturnGlobalProperty): + (JSC::ResolveOperation::resolveFail): + (JSC::ResolveOperation::skipTopScopeNode): + (JSC::ResolveOperation::skipScopes): + (JSC::ResolveOperation::returnGlobalObjectAsBase): + (JSC::ResolveOperation::setBaseToGlobal): + (JSC::ResolveOperation::setBaseToUndefined): + (JSC::ResolveOperation::setBaseToScope): + (JSC::ResolveOperation::returnScopeAsBase): + (JSC::PutToBaseOperation::PutToBaseOperation): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::ResolveResult::checkValidity): + (JSC): + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::resolveConstDecl): + (JSC::BytecodeGenerator::shouldAvoidResolveGlobal): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveBase): + (JSC::BytecodeGenerator::emitResolveBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetLocalVar): + (JSC::BytecodeGenerator::emitInitGlobalConst): + (JSC::BytecodeGenerator::emitPutToBase): + * bytecompiler/BytecodeGenerator.h: + (JSC::ResolveResult::registerResolve): + (JSC::ResolveResult::dynamicResolve): + (ResolveResult): + (JSC::ResolveResult::ResolveResult): + (JSC): + (NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::~NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::resolved): + (JSC::NonlocalResolveInfo::put): + (BytecodeGenerator): + (JSC::BytecodeGenerator::getResolveOperations): + (JSC::BytecodeGenerator::getResolveWithThisOperations): + (JSC::BytecodeGenerator::getResolveBaseOperations): + (JSC::BytecodeGenerator::getResolveBaseForPutOperations): + (JSC::BytecodeGenerator::getResolveWithBaseForPutOperations): + (JSC::BytecodeGenerator::getPutToBaseOperation): + * bytecompiler/NodesCodegen.cpp: + (JSC::ResolveNode::isPure): + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::PostfixNode::emitResolve): + (JSC::PrefixNode::emitResolve): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): + (JSC::ConstDeclNode::emitCodeSingle): + (JSC::ForInNode::emitBytecode): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::handleGetByOffset): + (DFG): + (JSC::DFG::ByteCodeParser::parseResolveOperations): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileResolveOperations): + (DFG): + (JSC::DFG::canCompilePutToBaseOperation): + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canInlineOpcode): + * dfg/DFGGraph.h: + (ResolveGlobalData): + (ResolveOperationData): + (DFG): + (PutToBaseOperationData): + (Graph): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasIdentifier): + (JSC::DFG::Node::resolveOperationsDataIndex): + (Node): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::resolveOperations): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::putToBaseOperation): + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + (JIT): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_put_to_base): + (JSC): + (JSC::JIT::emit_resolve_operations): + (JSC::JIT::emitSlow_link_resolve_operations): + (JSC::JIT::emit_op_resolve): + (JSC::JIT::emitSlow_op_resolve): + (JSC::JIT::emit_op_resolve_base): + (JSC::JIT::emitSlow_op_resolve_base): + (JSC::JIT::emit_op_resolve_with_base): + (JSC::JIT::emitSlow_op_resolve_with_base): + (JSC::JIT::emit_op_resolve_with_this): + (JSC::JIT::emitSlow_op_resolve_with_this): + (JSC::JIT::emitSlow_op_put_to_base): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_put_to_base): + (JSC): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_init_global_const): + (JSC::JIT::emit_op_init_global_const_check): + (JSC::JIT::emitSlow_op_init_global_const_check): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_init_global_const): + (JSC::JIT::emit_op_init_global_const_check): + (JSC::JIT::emitSlow_op_init_global_const_check): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + (JSC): + * jit/JITStubs.h: + * llint/LLIntSlowPaths.cpp: + (LLInt): + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSScope.cpp: + (JSC::LookupResult::base): + (JSC::LookupResult::value): + (JSC::LookupResult::setBase): + (JSC::LookupResult::setValue): + (LookupResult): + (JSC): + (JSC::setPutPropertyAccessOffset): + (JSC::executeResolveOperations): + (JSC::JSScope::resolveContainingScopeInternal): + (JSC::JSScope::resolveContainingScope): + (JSC::JSScope::resolve): + (JSC::JSScope::resolveBase): + (JSC::JSScope::resolveWithBase): + (JSC::JSScope::resolveWithThis): + (JSC::JSScope::resolvePut): + (JSC::JSScope::resolveGlobal): + * runtime/JSScope.h: + (JSScope): + * runtime/JSVariableObject.cpp: + (JSC): + * runtime/JSVariableObject.h: + (JSVariableObject): + * runtime/Structure.h: + (JSC::Structure::propertyAccessesAreCacheable): + (Structure): + +2012-10-17 Filip Pizlo <fpizlo@apple.com> + + Array and object allocations via 'new Object' or 'new Array' should be inlined in bytecode to allow allocation site profiling + https://bugs.webkit.org/show_bug.cgi?id=99557 + + Reviewed by Geoffrey Garen. + + This uses the old jneq_ptr trick to allow for the bytecode to "see" that the + operation in question is what we almost certainly know it to be. + + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/SpecialPointer.h: + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::emitCall): + (JSC::BytecodeGenerator::emitCallEval): + (JSC::BytecodeGenerator::expectedFunctionForIdentifier): + (JSC): + (JSC::BytecodeGenerator::emitExpectedFunctionSnippet): + (JSC::BytecodeGenerator::emitConstruct): + * bytecompiler/BytecodeGenerator.h: + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::NewExprNode::emitBytecode): + (JSC::FunctionCallValueNode::emitBytecode): + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::FunctionCallBracketNode::emitBytecode): + (JSC::FunctionCallDotNode::emitBytecode): + (JSC::CallFunctionCallDotNode::emitBytecode): + (JSC::ApplyFunctionCallDotNode::emitBytecode): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::parseBlock): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + * jit/JIT.h: + (JIT): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_new_array_with_size): + (JSC): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + (JSC): + * jit/JITStubs.h: + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (LLInt): + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter.asm: + * runtime/ArrayConstructor.cpp: + (JSC::constructArrayWithSizeQuirk): + (JSC): + * runtime/ArrayConstructor.h: + (JSC): + * runtime/CommonIdentifiers.h: + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + (JSC): + +2012-10-17 Filip Pizlo <fpizlo@apple.com> + + JIT op_get_by_pname should call cti_get_by_val_generic and not cti_get_by_val + https://bugs.webkit.org/show_bug.cgi?id=99631 + <rdar://problem/12483221> + + Reviewed by Mark Hahnenberg. + + cti_get_by_val assumes that the return address has patching metadata associated with it, which won't + be true for op_get_by_pname. cti_get_by_val_generic makes no such assumptions. + + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emitSlow_op_get_by_pname): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emitSlow_op_get_by_pname): + +2012-10-17 Mark Hahnenberg <mhahnenberg@apple.com> + + Block freeing thread should sleep indefinitely when there's no work to do + https://bugs.webkit.org/show_bug.cgi?id=98084 + + Reviewed by Geoffrey Garen. + + r130212 didn't fully fix the problem. + + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::blockFreeingThreadMain): We would just continue to the next iteration if + we found that we had zero blocks to copy. We should move the indefinite wait up to where that + check is done so that we properly detect the "no more blocks to copy, wait for more" condition. + +2012-10-16 Csaba Osztrogonác <ossy@webkit.org> + + Unreviewed, rolling out r131516 and r131550. + http://trac.webkit.org/changeset/131516 + http://trac.webkit.org/changeset/131550 + https://bugs.webkit.org/show_bug.cgi?id=99349 + + It caused zillion different problem on different platforms + + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/CodeBlock.cpp: + (JSC): + (JSC::isGlobalResolve): + (JSC::instructionOffsetForNth): + (JSC::printGlobalResolveInfo): + (JSC::CodeBlock::printStructures): + (JSC::CodeBlock::dump): + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::visitStructures): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::hasGlobalResolveInfoAtBytecodeOffset): + (JSC::CodeBlock::globalResolveInfoForBytecodeOffset): + (JSC::CodeBlock::shrinkToFit): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::addGlobalResolveInstruction): + (JSC::CodeBlock::addGlobalResolveInfo): + (JSC::CodeBlock::globalResolveInfo): + (JSC::CodeBlock::numberOfGlobalResolveInfos): + (JSC::CodeBlock::globalResolveInfoCount): + * bytecode/GlobalResolveInfo.h: Copied from Source/JavaScriptCore/bytecode/ResolveGlobalStatus.cpp. + (JSC): + (JSC::GlobalResolveInfo::GlobalResolveInfo): + (GlobalResolveInfo): + (JSC::getGlobalResolveInfoBytecodeOffset): + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/ResolveGlobalStatus.cpp: + (JSC): + (JSC::computeForStructure): + (JSC::computeForLLInt): + (JSC::ResolveGlobalStatus::computeFor): + * bytecode/ResolveGlobalStatus.h: + (JSC): + (ResolveGlobalStatus): + * bytecode/ResolveOperation.h: Removed. + * bytecompiler/BytecodeGenerator.cpp: + (JSC::ResolveResult::checkValidity): + (JSC::ResolveResult::registerPointer): + (JSC): + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::resolveConstDecl): + (JSC::BytecodeGenerator::shouldAvoidResolveGlobal): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveBase): + (JSC::BytecodeGenerator::emitResolveBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithBase): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetStaticVar): + (JSC::BytecodeGenerator::emitInitGlobalConst): + (JSC::BytecodeGenerator::emitPutStaticVar): + * bytecompiler/BytecodeGenerator.h: + (JSC::ResolveResult::registerResolve): + (JSC::ResolveResult::dynamicResolve): + (JSC::ResolveResult::lexicalResolve): + (JSC::ResolveResult::indexedGlobalResolve): + (JSC::ResolveResult::dynamicIndexedGlobalResolve): + (JSC::ResolveResult::globalResolve): + (JSC::ResolveResult::dynamicGlobalResolve): + (JSC::ResolveResult::type): + (JSC::ResolveResult::index): + (JSC::ResolveResult::depth): + (JSC::ResolveResult::globalObject): + (ResolveResult): + (JSC::ResolveResult::isStatic): + (JSC::ResolveResult::isIndexed): + (JSC::ResolveResult::isScoped): + (JSC::ResolveResult::isGlobal): + (JSC::ResolveResult::ResolveResult): + (BytecodeGenerator): + * bytecompiler/NodesCodegen.cpp: + (JSC::ResolveNode::isPure): + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::PostfixNode::emitResolve): + (JSC::PrefixNode::emitResolve): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): + (JSC::ConstDeclNode::emitCodeSingle): + (JSC::ForInNode::emitBytecode): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::handleGetByOffset): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canInlineOpcode): + * dfg/DFGGraph.h: + (ResolveGlobalData): + (DFG): + (Graph): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasIdentifier): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + (JSC): + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + (JIT): + (JSC::JIT::emit_op_get_global_var_watchable): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_resolve): + (JSC): + (JSC::JIT::emit_op_resolve_base): + (JSC::JIT::emit_op_resolve_skip): + (JSC::JIT::emit_op_resolve_global): + (JSC::JIT::emitSlow_op_resolve_global): + (JSC::JIT::emit_op_resolve_with_base): + (JSC::JIT::emit_op_resolve_with_this): + (JSC::JIT::emit_op_resolve_global_dynamic): + (JSC::JIT::emitSlow_op_resolve_global_dynamic): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_resolve): + (JSC): + (JSC::JIT::emit_op_resolve_base): + (JSC::JIT::emit_op_resolve_skip): + (JSC::JIT::emit_op_resolve_global): + (JSC::JIT::emitSlow_op_resolve_global): + (JSC::JIT::emit_op_resolve_with_base): + (JSC::JIT::emit_op_resolve_with_this): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_scoped_var): + (JSC): + (JSC::JIT::emit_op_put_scoped_var): + (JSC::JIT::emit_op_get_global_var): + (JSC::JIT::emit_op_put_global_var): + (JSC::JIT::emit_op_put_global_var_check): + (JSC::JIT::emitSlow_op_put_global_var_check): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_scoped_var): + (JSC): + (JSC::JIT::emit_op_put_scoped_var): + (JSC::JIT::emit_op_get_global_var): + (JSC::JIT::emit_op_put_global_var): + (JSC::JIT::emit_op_put_global_var_check): + (JSC::JIT::emitSlow_op_put_global_var_check): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + (JSC): + * jit/JITStubs.h: + * llint/LLIntSlowPaths.cpp: + (LLInt): + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSScope.cpp: + (JSC::JSScope::resolve): + (JSC::JSScope::resolveSkip): + (JSC::JSScope::resolveGlobal): + (JSC::JSScope::resolveGlobalDynamic): + (JSC::JSScope::resolveBase): + (JSC::JSScope::resolveWithBase): + (JSC::JSScope::resolveWithThis): + * runtime/JSScope.h: + (JSScope): + * runtime/JSVariableObject.cpp: + * runtime/JSVariableObject.h: + * runtime/Structure.h: + +2012-10-16 Dongwoo Joshua Im <dw.im@samsung.com> + + [GTK] Fix build break - ResolveOperations.h is not in WebKit. + https://bugs.webkit.org/show_bug.cgi?id=99538 + + Unreviewed build fix. + + There are some files including ResolveOperations.h which is not exist at all. + + * GNUmakefile.list.am: s/ResolveOperations.h/ResolveOperation.h/ + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: s/ResolveOperations.h/ResolveOperation.h/ + +2012-10-16 Jian Li <jianli@chromium.org> + + Rename feature define ENABLE_WIDGET_REGION to ENABLE_DRAGGBALE_REGION + https://bugs.webkit.org/show_bug.cgi?id=98975 + + Reviewed by Adam Barth. + + Renaming is needed to better match with the draggable region code. + + * Configurations/FeatureDefines.xcconfig: + +2012-10-15 Oliver Hunt <oliver@apple.com> + + Bytecode should not have responsibility for determining how to perform non-local resolves + https://bugs.webkit.org/show_bug.cgi?id=99349 + + Reviewed by Gavin Barraclough. + + This patch removes lexical analysis from the bytecode generation. This allows + us to delay lookup of a non-local variables until the lookup is actually necessary, + and simplifies a lot of the resolve logic in BytecodeGenerator. + + Once a lookup is performed we cache the lookup information in a set of out-of-line + buffers in CodeBlock. This allows subsequent lookups to avoid unnecessary hashing, + etc, and allows the respective JITs to recreated optimal lookup code. + + This is currently still a performance regression in LLInt, but most of the remaining + regression is caused by a lot of indirection that I'll remove in future work, as well + as some work necessary to allow LLInt to perform in line instruction repatching. + We will also want to improve the behaviour of the baseline JIT for some of the lookup + operations, however this patch was getting quite large already so I'm landing it now + that we've reached the bar of "performance-neutral". + + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::printStructures): + (JSC::CodeBlock::dump): + (JSC::CodeBlock::CodeBlock): + (JSC::CodeBlock::visitStructures): + (JSC): + (JSC::CodeBlock::finalizeUnconditionally): + (JSC::CodeBlock::shrinkToFit): + * bytecode/CodeBlock.h: + (JSC::CodeBlock::addResolve): + (JSC::CodeBlock::addPutToBase): + (CodeBlock): + (JSC::CodeBlock::resolveOperations): + (JSC::CodeBlock::putToBaseOperation): + (JSC::CodeBlock::numberOfResolveOperations): + (JSC::CodeBlock::numberOfPutToBaseOperations): + (JSC::CodeBlock::addPropertyAccessInstruction): + (JSC::CodeBlock::globalObjectConstant): + (JSC::CodeBlock::setGlobalObjectConstant): + * bytecode/GlobalResolveInfo.h: Removed. + * bytecode/Opcode.h: + (JSC): + (JSC::padOpcodeName): + * bytecode/ResolveGlobalStatus.cpp: + (JSC::computeForStructure): + (JSC::ResolveGlobalStatus::computeFor): + * bytecode/ResolveGlobalStatus.h: + (JSC): + (ResolveGlobalStatus): + * bytecode/ResolveOperation.h: Added. + The new types and logic we use to perform the cached lookups. + (JSC): + (ResolveOperation): + (JSC::ResolveOperation::getAndReturnScopedVar): + (JSC::ResolveOperation::checkForDynamicEntriesBeforeGlobalScope): + (JSC::ResolveOperation::getAndReturnGlobalVar): + (JSC::ResolveOperation::getAndReturnGlobalProperty): + (JSC::ResolveOperation::resolveFail): + (JSC::ResolveOperation::skipTopScopeNode): + (JSC::ResolveOperation::skipScopes): + (JSC::ResolveOperation::returnGlobalObjectAsBase): + (JSC::ResolveOperation::setBaseToGlobal): + (JSC::ResolveOperation::setBaseToUndefined): + (JSC::ResolveOperation::setBaseToScope): + (JSC::ResolveOperation::returnScopeAsBase): + (JSC::PutToBaseOperation::PutToBaseOperation): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::ResolveResult::checkValidity): + (JSC): + (JSC::BytecodeGenerator::BytecodeGenerator): + (JSC::BytecodeGenerator::resolve): + (JSC::BytecodeGenerator::resolveConstDecl): + (JSC::BytecodeGenerator::shouldAvoidResolveGlobal): + (JSC::BytecodeGenerator::emitResolve): + (JSC::BytecodeGenerator::emitResolveBase): + (JSC::BytecodeGenerator::emitResolveBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithBaseForPut): + (JSC::BytecodeGenerator::emitResolveWithThis): + (JSC::BytecodeGenerator::emitGetLocalVar): + (JSC::BytecodeGenerator::emitInitGlobalConst): + (JSC::BytecodeGenerator::emitPutToBase): + * bytecompiler/BytecodeGenerator.h: + (JSC::ResolveResult::registerResolve): + (JSC::ResolveResult::dynamicResolve): + (ResolveResult): + (JSC::ResolveResult::ResolveResult): + (JSC): + (NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::~NonlocalResolveInfo): + (JSC::NonlocalResolveInfo::resolved): + (JSC::NonlocalResolveInfo::put): + (BytecodeGenerator): + (JSC::BytecodeGenerator::getResolveOperations): + (JSC::BytecodeGenerator::getResolveWithThisOperations): + (JSC::BytecodeGenerator::getResolveBaseOperations): + (JSC::BytecodeGenerator::getResolveBaseForPutOperations): + (JSC::BytecodeGenerator::getResolveWithBaseForPutOperations): + (JSC::BytecodeGenerator::getPutToBaseOperation): + * bytecompiler/NodesCodegen.cpp: + (JSC::ResolveNode::isPure): + (JSC::FunctionCallResolveNode::emitBytecode): + (JSC::PostfixNode::emitResolve): + (JSC::PrefixNode::emitResolve): + (JSC::ReadModifyResolveNode::emitBytecode): + (JSC::AssignResolveNode::emitBytecode): + (JSC::ConstDeclNode::emitCodeSingle): + (JSC::ForInNode::emitBytecode): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (ByteCodeParser): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::handleGetByOffset): + (DFG): + (JSC::DFG::ByteCodeParser::parseResolveOperations): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCapabilities.h: + (JSC::DFG::canCompileResolveOperations): + (DFG): + (JSC::DFG::canCompilePutToBaseOperation): + (JSC::DFG::canCompileOpcode): + (JSC::DFG::canInlineOpcode): + * dfg/DFGGraph.h: + (ResolveGlobalData): + (ResolveOperationData): + (DFG): + (PutToBaseOperationData): + (Graph): + * dfg/DFGNode.h: + (JSC::DFG::Node::hasIdentifier): + (JSC::DFG::Node::resolveOperationsDataIndex): + (Node): + * dfg/DFGNodeType.h: + (DFG): + * dfg/DFGOSRExit.cpp: + (JSC::DFG::OSRExit::OSRExit): + * dfg/DFGOSRExit.h: + (OSRExit): + * dfg/DFGOSRExitCompiler.cpp: + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGPredictionPropagationPhase.cpp: + (JSC::DFG::PredictionPropagationPhase::propagate): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::resolveOperations): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::putToBaseOperation): + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + * jit/JIT.cpp: + (JSC::JIT::privateCompileMainPass): + (JSC::JIT::privateCompileSlowCases): + * jit/JIT.h: + (JIT): + * jit/JITOpcodes.cpp: + (JSC::JIT::emit_op_put_to_base): + (JSC): + (JSC::JIT::emit_resolve_operations): + (JSC::JIT::emitSlow_link_resolve_operations): + (JSC::JIT::emit_op_resolve): + (JSC::JIT::emitSlow_op_resolve): + (JSC::JIT::emit_op_resolve_base): + (JSC::JIT::emitSlow_op_resolve_base): + (JSC::JIT::emit_op_resolve_with_base): + (JSC::JIT::emitSlow_op_resolve_with_base): + (JSC::JIT::emit_op_resolve_with_this): + (JSC::JIT::emitSlow_op_resolve_with_this): + (JSC::JIT::emitSlow_op_put_to_base): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emit_op_put_to_base): + (JSC): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_init_global_const): + (JSC::JIT::emit_op_init_global_const_check): + (JSC::JIT::emitSlow_op_init_global_const_check): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_init_global_const): + (JSC::JIT::emit_op_init_global_const_check): + (JSC::JIT::emitSlow_op_init_global_const_check): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + (JSC): + * jit/JITStubs.h: + * llint/LLIntSlowPaths.cpp: + (LLInt): + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/JSScope.cpp: + (JSC::LookupResult::base): + (JSC::LookupResult::value): + (JSC::LookupResult::setBase): + (JSC::LookupResult::setValue): + (LookupResult): + (JSC): + (JSC::setPutPropertyAccessOffset): + (JSC::executeResolveOperations): + (JSC::JSScope::resolveContainingScopeInternal): + (JSC::JSScope::resolveContainingScope): + (JSC::JSScope::resolve): + (JSC::JSScope::resolveBase): + (JSC::JSScope::resolveWithBase): + (JSC::JSScope::resolveWithThis): + (JSC::JSScope::resolvePut): + (JSC::JSScope::resolveGlobal): + * runtime/JSScope.h: + (JSScope): + * runtime/JSVariableObject.cpp: + (JSC): + * runtime/JSVariableObject.h: + (JSVariableObject): + * runtime/Structure.h: + (JSC::Structure::propertyAccessesAreCacheable): + (Structure): + +2012-10-16 Filip Pizlo <fpizlo@apple.com> + + Accidental switch fall-through in DFG::FixupPhase + https://bugs.webkit.org/show_bug.cgi?id=96956 + <rdar://problem/12313242> + + Reviewed by Mark Hahnenberg. + + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + +2012-10-16 Filip Pizlo <fpizlo@apple.com> + + GetScopedVar CSE matches dead GetScopedVar's leading to IR corruption + https://bugs.webkit.org/show_bug.cgi?id=99470 + <rdar://problem/12363698> + + Reviewed by Mark Hahnenberg. + + All it takes is to follow the "if (!shouldGenerate) continue" idiom and everything will be OK. + + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::globalVarLoadElimination): + (JSC::DFG::CSEPhase::scopedVarLoadElimination): + (JSC::DFG::CSEPhase::globalVarWatchpointElimination): + (JSC::DFG::CSEPhase::getByValLoadElimination): + (JSC::DFG::CSEPhase::checkStructureElimination): + (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination): + (JSC::DFG::CSEPhase::getByOffsetLoadElimination): + +2012-10-16 Dima Gorbik <dgorbik@apple.com> + + Remove Platform.h include from the header files. + https://bugs.webkit.org/show_bug.cgi?id=98665 + + Reviewed by Eric Seidel. + + We don't want other clients that include WebKit headers to know about Platform.h. + + * API/tests/minidom.c: + * API/tests/testapi.c: + +2012-10-16 Balazs Kilvady <kilvadyb@homejinni.com> + + Add missing MIPS functions to assembler. + https://bugs.webkit.org/show_bug.cgi?id=98856 + + Reviewed by Oliver Hunt. + + Implement missing functions in MacroAssemblerMIPS and MIPSAssembler. + + * assembler/MIPSAssembler.h: + (JSC::MIPSAssembler::lb): + (MIPSAssembler): + (JSC::MIPSAssembler::lh): + (JSC::MIPSAssembler::cvtds): + (JSC::MIPSAssembler::cvtsd): + (JSC::MIPSAssembler::vmov): + * assembler/MacroAssemblerMIPS.h: + (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::load8Signed): + (JSC::MacroAssemblerMIPS::load16Signed): + (JSC::MacroAssemblerMIPS::moveDoubleToInts): + (JSC::MacroAssemblerMIPS::moveIntsToDouble): + (JSC::MacroAssemblerMIPS::loadFloat): + (JSC::MacroAssemblerMIPS::loadDouble): + (JSC::MacroAssemblerMIPS::storeFloat): + (JSC::MacroAssemblerMIPS::storeDouble): + (JSC::MacroAssemblerMIPS::addDouble): + (JSC::MacroAssemblerMIPS::convertFloatToDouble): + (JSC::MacroAssemblerMIPS::convertDoubleToFloat): + +2012-10-16 Balazs Kilvady <kilvadyb@homejinni.com> + + MIPS assembler coding-style fix. + https://bugs.webkit.org/show_bug.cgi?id=99359 + + Reviewed by Oliver Hunt. + + Coding style fix of existing MIPS assembler header files. + + * assembler/MIPSAssembler.h: + (JSC::MIPSAssembler::addiu): + (JSC::MIPSAssembler::addu): + (JSC::MIPSAssembler::subu): + (JSC::MIPSAssembler::mul): + (JSC::MIPSAssembler::andInsn): + (JSC::MIPSAssembler::andi): + (JSC::MIPSAssembler::nor): + (JSC::MIPSAssembler::orInsn): + (JSC::MIPSAssembler::ori): + (JSC::MIPSAssembler::xorInsn): + (JSC::MIPSAssembler::xori): + (JSC::MIPSAssembler::slt): + (JSC::MIPSAssembler::sltu): + (JSC::MIPSAssembler::sltiu): + (JSC::MIPSAssembler::sll): + (JSC::MIPSAssembler::sllv): + (JSC::MIPSAssembler::sra): + (JSC::MIPSAssembler::srav): + (JSC::MIPSAssembler::srl): + (JSC::MIPSAssembler::srlv): + (JSC::MIPSAssembler::lbu): + (JSC::MIPSAssembler::lw): + (JSC::MIPSAssembler::lwl): + (JSC::MIPSAssembler::lwr): + (JSC::MIPSAssembler::lhu): + (JSC::MIPSAssembler::sb): + (JSC::MIPSAssembler::sh): + (JSC::MIPSAssembler::sw): + (JSC::MIPSAssembler::addd): + (JSC::MIPSAssembler::subd): + (JSC::MIPSAssembler::muld): + (JSC::MIPSAssembler::divd): + (JSC::MIPSAssembler::lwc1): + (JSC::MIPSAssembler::ldc1): + (JSC::MIPSAssembler::swc1): + (JSC::MIPSAssembler::sdc1): + (MIPSAssembler): + (JSC::MIPSAssembler::relocateJumps): + (JSC::MIPSAssembler::linkWithOffset): + * assembler/MacroAssemblerMIPS.h: + (JSC::MacroAssemblerMIPS::add32): + (JSC::MacroAssemblerMIPS::and32): + (JSC::MacroAssemblerMIPS::sub32): + (MacroAssemblerMIPS): + (JSC::MacroAssemblerMIPS::load8): + (JSC::MacroAssemblerMIPS::load32): + (JSC::MacroAssemblerMIPS::load32WithUnalignedHalfWords): + (JSC::MacroAssemblerMIPS::load16): + (JSC::MacroAssemblerMIPS::store8): + (JSC::MacroAssemblerMIPS::store16): + (JSC::MacroAssemblerMIPS::store32): + (JSC::MacroAssemblerMIPS::nearCall): + (JSC::MacroAssemblerMIPS::test8): + (JSC::MacroAssemblerMIPS::test32): + +2012-10-16 Yuqiang Xian <yuqiang.xian@intel.com> + + Refactor MacroAssembler interfaces to differentiate the pointer operands from the 64-bit integer operands + https://bugs.webkit.org/show_bug.cgi?id=99154 + + Reviewed by Gavin Barraclough. + + In current JavaScriptCore implementation for JSVALUE64 platform (i.e., + the X64 platform), we assume that the JSValue size is same to the + pointer size, and thus EncodedJSValue is simply type defined as a + "void*". In the JIT compiler, we also take this assumption and invoke + the same macro assembler interfaces for both JSValue and pointer + operands. We need to differentiate the operations on pointers from the + operations on JSValues, and let them invoking different macro + assembler interfaces. For example, we now use the interface of + "loadPtr" to load either a pointer or a JSValue, and we need to switch + to using "loadPtr" to load a pointer and some new "load64" interface + to load a JSValue. This would help us supporting other JSVALUE64 + platforms where pointer size is not necessarily 64-bits, for example + x32 (bug #99153). + + The major modification I made is to introduce the "*64" interfaces in + the MacroAssembler for those operations on JSValues, keep the "*Ptr" + interfaces for those operations on real pointers, and go through all + the JIT compiler code to correct the usage. + + This is the first part of the work, i.e, to add the *64 interfaces to + the MacroAssembler. + + * assembler/AbstractMacroAssembler.h: Add the Imm64 interfaces. + (AbstractMacroAssembler): + (JSC::AbstractMacroAssembler::TrustedImm64::TrustedImm64): + (TrustedImm64): + (JSC::AbstractMacroAssembler::Imm64::Imm64): + (Imm64): + (JSC::AbstractMacroAssembler::Imm64::asTrustedImm64): + * assembler/MacroAssembler.h: map <foo>Ptr methods to <foo>64 for X86_64. + (MacroAssembler): + (JSC::MacroAssembler::peek64): + (JSC::MacroAssembler::poke): + (JSC::MacroAssembler::poke64): + (JSC::MacroAssembler::addPtr): + (JSC::MacroAssembler::andPtr): + (JSC::MacroAssembler::negPtr): + (JSC::MacroAssembler::orPtr): + (JSC::MacroAssembler::rotateRightPtr): + (JSC::MacroAssembler::subPtr): + (JSC::MacroAssembler::xorPtr): + (JSC::MacroAssembler::loadPtr): + (JSC::MacroAssembler::loadPtrWithAddressOffsetPatch): + (JSC::MacroAssembler::loadPtrWithCompactAddressOffsetPatch): + (JSC::MacroAssembler::storePtr): + (JSC::MacroAssembler::storePtrWithAddressOffsetPatch): + (JSC::MacroAssembler::movePtrToDouble): + (JSC::MacroAssembler::moveDoubleToPtr): + (JSC::MacroAssembler::comparePtr): + (JSC::MacroAssembler::testPtr): + (JSC::MacroAssembler::branchPtr): + (JSC::MacroAssembler::branchTestPtr): + (JSC::MacroAssembler::branchAddPtr): + (JSC::MacroAssembler::branchSubPtr): + (JSC::MacroAssembler::shouldBlindDouble): + (JSC::MacroAssembler::shouldBlind): + (JSC::MacroAssembler::RotatedImm64::RotatedImm64): + (RotatedImm64): + (JSC::MacroAssembler::rotationBlindConstant): + (JSC::MacroAssembler::loadRotationBlindedConstant): + (JSC::MacroAssembler::move): + (JSC::MacroAssembler::and64): + (JSC::MacroAssembler::store64): + * assembler/MacroAssemblerX86Common.h: + (JSC::MacroAssemblerX86Common::shouldBlindForSpecificArch): + (MacroAssemblerX86Common): + (JSC::MacroAssemblerX86Common::move): + * assembler/MacroAssemblerX86_64.h: Add the <foo>64 methods for X86_64. + (JSC::MacroAssemblerX86_64::branchAdd32): + (JSC::MacroAssemblerX86_64::add64): + (MacroAssemblerX86_64): + (JSC::MacroAssemblerX86_64::and64): + (JSC::MacroAssemblerX86_64::neg64): + (JSC::MacroAssemblerX86_64::or64): + (JSC::MacroAssemblerX86_64::rotateRight64): + (JSC::MacroAssemblerX86_64::sub64): + (JSC::MacroAssemblerX86_64::xor64): + (JSC::MacroAssemblerX86_64::load64): + (JSC::MacroAssemblerX86_64::load64WithAddressOffsetPatch): + (JSC::MacroAssemblerX86_64::load64WithCompactAddressOffsetPatch): + (JSC::MacroAssemblerX86_64::store64): + (JSC::MacroAssemblerX86_64::store64WithAddressOffsetPatch): + (JSC::MacroAssemblerX86_64::move64ToDouble): + (JSC::MacroAssemblerX86_64::moveDoubleTo64): + (JSC::MacroAssemblerX86_64::compare64): + (JSC::MacroAssemblerX86_64::branch64): + (JSC::MacroAssemblerX86_64::branchTest64): + (JSC::MacroAssemblerX86_64::test64): + (JSC::MacroAssemblerX86_64::branchAdd64): + (JSC::MacroAssemblerX86_64::branchSub64): + (JSC::MacroAssemblerX86_64::branchPtrWithPatch): + (JSC::MacroAssemblerX86_64::storePtrWithPatch): + +2012-10-15 Mark Hahnenberg <mhahnenberg@apple.com> + + Make CopiedSpace and MarkedSpace regions independent + https://bugs.webkit.org/show_bug.cgi?id=99222 + + Reviewed by Filip Pizlo. + + Right now CopiedSpace and MarkedSpace have the same block size and share the same regions, + but there's no reason that they can't have different block sizes while still sharing the + same underlying regions. We should factor the two "used" lists of regions apart so that + MarkedBlocks and CopiedBlocks can be different sizes. Regions will still be a uniform size + so that when they become empty they may be shared between the CopiedSpace and the MarkedSpace, + since benchmarks indicate that sharing is a boon for performance. + + * heap/BlockAllocator.cpp: + (JSC::BlockAllocator::BlockAllocator): + * heap/BlockAllocator.h: + (JSC): + (Region): + (JSC::Region::create): We now have a fixed size for Regions so that empty regions can continue to + be shared between the MarkedSpace and CopiedSpace. Once they are used for a specific type of block, + however, they can only be used for that type of block until they become empty again. + (JSC::Region::createCustomSize): + (JSC::Region::Region): + (JSC::Region::~Region): + (JSC::Region::reset): + (BlockAllocator): + (JSC::BlockAllocator::RegionSet::RegionSet): + (RegionSet): + (JSC::BlockAllocator::tryAllocateFromRegion): We change this function so that it correctly + moves blocks between empty, partial, and full lists. + (JSC::BlockAllocator::allocate): + (JSC::BlockAllocator::allocateCustomSize): + (JSC::BlockAllocator::deallocate): Ditto. + (JSC::CopiedBlock): + (JSC::MarkedBlock): + (JSC::BlockAllocator::regionSetFor): We use this so that we can use the same allocate/deallocate + functions with different RegionSets. We specialize the function for each type of block that we + want to allocate. + * heap/CopiedBlock.h: + (CopiedBlock): + * heap/CopiedSpace.h: + (CopiedSpace): + * heap/HeapBlock.h: + (HeapBlock): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::MarkedBlock): For oversize MarkedBlocks, if the block size gets too big we can + underflow the endAtom, which will cause us to segfault when we try to sweep a block. If we're a + custom size MarkedBlock we need to calculate endAtom so it doesn't underflow. + +2012-10-14 Filip Pizlo <fpizlo@apple.com> + + JIT::JIT fails to initialize all of its fields + https://bugs.webkit.org/show_bug.cgi?id=99283 + + Reviewed by Andreas Kling. + + There were two groups of such fields, all of which are eventually initialized + prior to use inside of privateCompile(). But it's safer to make sure that they + are initialized in the constructor as well, since we may use the JIT to do a + stub compile without calling into privateCompile(). + + Unsigned index fields for dynamic repatching meta-data: this change + initializes them to UINT_MAX, so we should crash if we try to use those + indices without initializing them. + + Boolean flags for value profiling: this change initializes them to false, so + we at worst turn off value profiling. + + * jit/JIT.cpp: + (JSC::JIT::JIT): + +2012-10-15 Mark Hahnenberg <mhahnenberg@apple.com> + + We should avoid weakCompareAndSwap when parallel GC is disabled + https://bugs.webkit.org/show_bug.cgi?id=99331 + + Reviewed by Filip Pizlo. + + CopiedBlock::reportLiveBytes and didEvacuateBytes uses weakCompareAndSwap, which some platforms + don't support. For platforms that don't have parallel GC enabled, we should just use a normal store. + + * heap/CopiedBlock.h: + (JSC::CopiedBlock::reportLiveBytes): + (JSC::CopiedBlock::didEvacuateBytes): + +2012-10-15 Carlos Garcia Campos <cgarcia@igalia.com> + + Unreviewed. Fix make distcheck. + + * GNUmakefile.list.am: Add missing header file. + +2012-10-14 Filip Pizlo <fpizlo@apple.com> + + DFG should handle polymorphic array modes by eagerly transforming arrays into the most general applicable form + https://bugs.webkit.org/show_bug.cgi?id=99269 + + Reviewed by Geoffrey Garen. + + This kills off a bunch of code for "polymorphic" array modes in the DFG. It should + also be a performance win for code that uses a lot of array storage arrays. + + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::fromObserved): + (JSC::DFG::modeAlreadyChecked): + (JSC::DFG::modeToString): + * dfg/DFGArrayMode.h: + (DFG): + (JSC::DFG::modeUsesButterfly): + (JSC::DFG::modeIsJSArray): + (JSC::DFG::mayStoreToTail): + (JSC::DFG::mayStoreToHole): + (JSC::DFG::canCSEStorage): + (JSC::DFG::modeSupportsLength): + (JSC::DFG::benefitsFromStructureCheck): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::checkArray): + (JSC::DFG::FixupPhase::blessArrayOperation): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::byValIsPure): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::arrayify): + (DFG): + (JSC::DFG::SpeculativeJIT::compileGetArrayLength): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister): + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-10-14 Filip Pizlo <fpizlo@apple.com> + + REGRESSION(126886): Fat binary builds don't know how to handle architecture variants to which the LLInt is agnostic + https://bugs.webkit.org/show_bug.cgi?id=99270 + + Reviewed by Geoffrey Garen. + + The fix is to hash cons the offsets based on configuration index, not the offsets + themselves. + + * offlineasm/offsets.rb: + +2012-10-13 Filip Pizlo <fpizlo@apple.com> + + IndexingType should not have a bit for each type + https://bugs.webkit.org/show_bug.cgi?id=98997 + + Reviewed by Oliver Hunt. + + Somewhat incidentally, the introduction of butterflies led to each indexing + type being represented by a unique bit. This is superficially nice since it + allows you to test if a structure corresponds to a particular indexing type + by saying !!(structure->indexingType() & TheType). But the downside is that + given the 8 bits we have for the m_indexingType field, that leaves only a + small number of possible indexing types if we have one per bit. + + This changeset changes the indexing type to be: + + Bit #1: Tells you if you're an array. + + Bits #2 - #5: 16 possible indexing types, including the blank type for + objects that don't have indexed properties. + + Bits #6-8: Auxiliary bits that we could use for other things. Currently we + just use one of those bits, for MayHaveIndexedAccessors. + + This is performance-neutral, and is primarily intended to give us more + breathing room for introducing new inferred array modes. + + * assembler/AbstractMacroAssembler.h: + (JSC::AbstractMacroAssembler::JumpList::jumps): + * assembler/MacroAssembler.h: + (MacroAssembler): + (JSC::MacroAssembler::patchableBranch32): + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::patchableBranch32): + (MacroAssemblerARMv7): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::modeAlreadyChecked): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::speculationCheck): + (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): + (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): + (DFG): + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::arrayify): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateJSArray): + (JSC::JIT::chooseArrayMode): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emitArrayStorageGetByVal): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::emitContiguousPutByVal): + (JSC::JIT::emitArrayStoragePutByVal): + (JSC::JIT::privateCompilePatchGetArrayLength): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emitArrayStorageGetByVal): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::emitContiguousPutByVal): + (JSC::JIT::emitArrayStoragePutByVal): + (JSC::JIT::privateCompilePatchGetArrayLength): + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/IndexingType.h: + (JSC): + (JSC::hasIndexedProperties): + (JSC::hasContiguous): + (JSC::hasFastArrayStorage): + (JSC::hasArrayStorage): + (JSC::shouldUseSlowPut): + * runtime/JSGlobalObject.cpp: + (JSC): + * runtime/StructureTransitionTable.h: + (JSC::newIndexingType): + +2012-10-14 Filip Pizlo <fpizlo@apple.com> + + DFG structure check hoisting should attempt to ignore side effects and make transformations that are sound even in their presence + https://bugs.webkit.org/show_bug.cgi?id=99262 + + Reviewed by Oliver Hunt. + + This hugely simplifies the structure check hoisting phase. It will no longer be necessary + to modify it when the effectfulness of operations changes. This also enables the hoister + to hoist effectful things in the future. + + The downside is that the hoister may end up adding strictly more checks than were present + in the original code, if the code truly has a lot of side-effects. I don't see evidence + of this happening. This patch does have some speed-ups and some slow-downs, but is + neutral in the average, and the slow-downs do not appear to have more structure checks + than ToT. + + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): + (StructureCheckHoistingPhase): + (CheckData): + (JSC::DFG::StructureCheckHoistingPhase::CheckData::CheckData): + +2012-10-14 Filip Pizlo <fpizlo@apple.com> + + Fix the build of universal binary with ARMv7s of JavaScriptCore + + * llint/LLIntOfflineAsmConfig.h: + * llint/LowLevelInterpreter.asm: + +2012-10-13 Filip Pizlo <fpizlo@apple.com> + + Array length array profiling is broken in the baseline JIT + https://bugs.webkit.org/show_bug.cgi?id=99258 + + Reviewed by Oliver Hunt. + + The code generator for array length stubs calls into + emitArrayProfilingSiteForBytecodeIndex(), which emits profiling only if + canBeOptimized() returns true. But m_canBeOptimized is only initialized during + full method compiles, so in a stub compile it may (or may not) be false, meaning + that we may, or may not, get meaningful profiling info. + + This appeared to not affect too many programs since the LLInt has good array + length array profiling. + + * jit/JIT.h: + (JSC::JIT::compilePatchGetArrayLength): + +2012-10-14 Patrick Gansterer <paroga@webkit.org> + + Build fix for WinCE after r131089. + + WinCE does not support getenv(). + + * runtime/Options.cpp: + (JSC::overrideOptionWithHeuristic): + +2012-10-12 Kangil Han <kangil.han@samsung.com> + + Fix build error on DFGSpeculativeJIT32_64.cpp + https://bugs.webkit.org/show_bug.cgi?id=99234 + + Reviewed by Anders Carlsson. + + Seems BUG 98608 causes build error on 32bit machine so fix it. + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-10-12 Filip Pizlo <fpizlo@apple.com> + + Contiguous array allocation should always be inlined + https://bugs.webkit.org/show_bug.cgi?id=98608 + + Reviewed by Oliver Hunt and Mark Hahnenberg. + + This inlines contiguous array allocation in the most obvious way possible. + + * JavaScriptCore.xcodeproj/project.pbxproj: + * assembler/MacroAssembler.h: + (JSC::MacroAssembler::branchSubPtr): + (MacroAssembler): + * assembler/MacroAssemblerX86_64.h: + (JSC::MacroAssemblerX86_64::branchSubPtr): + (MacroAssemblerX86_64): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGCCallHelpers.h: + (JSC::DFG::CCallHelpers::setupArgumentsWithExecState): + (CCallHelpers): + * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: Added. + (DFG): + (CallArrayAllocatorSlowPathGenerator): + (JSC::DFG::CallArrayAllocatorSlowPathGenerator::CallArrayAllocatorSlowPathGenerator): + (JSC::DFG::CallArrayAllocatorSlowPathGenerator::generateInternal): + (CallArrayAllocatorWithVariableSizeSlowPathGenerator): + (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableSizeSlowPathGenerator): + (JSC::DFG::CallArrayAllocatorWithVariableSizeSlowPathGenerator::generateInternal): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): + (DFG): + (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): + (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage): + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): + (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-10-12 Mark Hahnenberg <mhahnenberg@apple.com> + + Race condition during CopyingPhase can lead to deadlock + https://bugs.webkit.org/show_bug.cgi?id=99226 + + Reviewed by Filip Pizlo. + + The main thread calls startCopying() for each of the GCThreads at the beginning of the copy phase. + It then proceeds to start copying. If copying completes before one of the GCThreads wakes up, the + main thread will set m_currentPhase back to NoPhase, the GCThread will wake up, see that there's + nothing to do, and then it will go back to sleep without ever calling CopyVisitor::doneCopying() + to return its borrowed block to the CopiedSpace. CopiedSpace::doneCopying() will then sleep forever + waiting on the block. + + The fix for this is to make sure we call CopiedSpace::doneCopying() on the main thread before we + call GCThreadSharedData::didFinishCopying(), which sets the m_currentPhase flag to NoPhase. This + way we will wait until all threads have woken up and given back their borrowed blocks before + clearing the flag. + + * heap/Heap.cpp: + (JSC::Heap::copyBackingStores): + +2012-10-12 Anders Carlsson <andersca@apple.com> + + Move macros from Parser.h to Parser.cpp + https://bugs.webkit.org/show_bug.cgi?id=99217 + + Reviewed by Andreas Kling. + + There are a bunch of macros in Parser.h that are only used in Parser.cpp. Move them to Parser.cpp + so they won't pollute the global namespace. + * parser/Parser.cpp: + * parser/Parser.h: + (JSC): + +2012-10-12 Mark Hahnenberg <mhahnenberg@apple.com> + + Another build fix after r131213 + + Added some symbol magic to placate the linker on some platforms. + + * JavaScriptCore.order: + +2012-10-12 Mark Hahnenberg <mhahnenberg@apple.com> + + Build fix after r131213 + + Removed an unused variable that was making compilers unhappy. + + * heap/GCThread.cpp: + (JSC::GCThread::GCThread): + * heap/GCThread.h: + (GCThread): + * heap/GCThreadSharedData.cpp: + (JSC::GCThreadSharedData::GCThreadSharedData): + +2012-10-09 Mark Hahnenberg <mhahnenberg@apple.com> + + Copying collection shouldn't require O(live bytes) memory overhead + https://bugs.webkit.org/show_bug.cgi?id=98792 + + Reviewed by Filip Pizlo. + + Currently our copying collection occurs simultaneously with the marking phase. We'd like + to be able to reuse CopiedBlocks as soon as they become fully evacuated, but this is not + currently possible because we don't know the liveness statistics of each old CopiedBlock + until marking/copying has already finished. Instead, we have to allocate additional memory + from the OS to use as our working set of CopiedBlocks while copying. We then return the + fully evacuated old CopiedBlocks back to the block allocator, thus giving our copying phase + an O(live bytes) overhead. + + To fix this, we should instead split the copying phase apart from the marking phase. This + way we have full liveness data for each CopiedBlock during the copying phase so that we + can reuse them the instant they become fully evacuated. With the additional liveness data + that each CopiedBlock accumulates, we can add some additional heuristics to the collector. + For example, we can calculate our global Heap fragmentation and only choose to do a copying + phase if that fragmentation exceeds some limit. As another example, we can skip copying + blocks that are already above a particular fragmentation limit, which allows older objects + to coalesce into blocks that are rarely copied. + + * JavaScriptCore.xcodeproj/project.pbxproj: + * heap/CopiedBlock.h: + (CopiedBlock): + (JSC::CopiedBlock::CopiedBlock): Added support for tracking live bytes in a CopiedBlock in a + thread-safe fashion. + (JSC::CopiedBlock::reportLiveBytes): Adds a number of live bytes to the block in a thread-safe + fashion using compare and swap. + (JSC): + (JSC::CopiedBlock::didSurviveGC): Called when a block survives a single GC without being + evacuated. This could be called for a couple reasons: (a) the block was pinned or (b) we + decided not to do any copying. A block can become pinned for a few reasons: (1) a pointer into + the block was found during the conservative scan. (2) the block was deemed full enough to + not warrant any copying. (3) The block is oversize and was found to be live. + (JSC::CopiedBlock::didEvacuateBytes): Called when some number of bytes are copied from this + block. If the number of live bytes ever hits zero, the block will return itself to the + BlockAllocator to be recycled. + (JSC::CopiedBlock::canBeRecycled): Indicates that a block has no live bytes and can be + immediately recycled. This is used for blocks that are found to have zero live bytes at the + beginning of the copying phase. + (JSC::CopiedBlock::shouldEvacuate): This function returns true if the current fragmentation + of the block is above our fragmentation threshold, and false otherwise. + (JSC::CopiedBlock::isPinned): Added an accessor for the pinned flag + (JSC::CopiedBlock::liveBytes): + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::CopiedSpace): + (JSC::CopiedSpace::doneFillingBlock): Changed so that we can exchange our filled block for a + fresh block. This avoids the situation where a thread returns its borrowed block, it's the last + borrowed block, so CopiedSpace thinks that copying has completed, and it starts doing all of the + copying phase cleanup. In actuality, the thread wanted another block after returning the current + block. So we allow the thread to atomically exchange its block for another block. + (JSC::CopiedSpace::startedCopying): Added the calculation of global Heap fragmentation to + determine if the copying phase should commence. We include the MarkedSpace in our fragmentation + calculation by assuming that the MarkedSpace is 0% fragmented since we can reuse any currently + free memory in it (i.e. we ignore any internal fragmentation in the MarkedSpace). While we're + calculating the fragmentation of CopiedSpace, we also return any free blocks we find along the + way (meaning liveBytes() == 0). + (JSC): + (JSC::CopiedSpace::doneCopying): We still have to iterate over all the blocks, regardless of + whether the copying phase took place or not so that we can reset all of the live bytes counters + and un-pin any pinned blocks. + * heap/CopiedSpace.h: + (CopiedSpace): + (JSC::CopiedSpace::shouldDoCopyPhase): + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::recycleEvacuatedBlock): This function is distinct from recycling a borrowed block + because a borrowed block hasn't been added to the CopiedSpace yet, but an evacuated block is still + currently in CopiedSpace, so we have to make sure we properly remove all traces of the block from + CopiedSpace before returning it to BlockAllocator. + (JSC::CopiedSpace::recycleBorrowedBlock): Renamed to indicate the distinction mentioned above. + * heap/CopyVisitor.cpp: Added. + (JSC): + (JSC::CopyVisitor::CopyVisitor): + (JSC::CopyVisitor::copyFromShared): Main function for any thread participating in the copying phase. + Grabs chunks of MarkedBlocks from the shared list and copies the backing store of anybody who needs + it until there are no more chunks to copy. + * heap/CopyVisitor.h: Added. + (JSC): + (CopyVisitor): + * heap/CopyVisitorInlineMethods.h: Added. + (JSC): + (GCCopyPhaseFunctor): + (JSC::GCCopyPhaseFunctor::GCCopyPhaseFunctor): + (JSC::GCCopyPhaseFunctor::operator()): + (JSC::CopyVisitor::checkIfShouldCopy): We don't have to check shouldEvacuate() because all of those + checks are done during the marking phase. + (JSC::CopyVisitor::allocateNewSpace): + (JSC::CopyVisitor::allocateNewSpaceSlow): + (JSC::CopyVisitor::startCopying): Initialization function for a thread that is about to start copying. + (JSC::CopyVisitor::doneCopying): + (JSC::CopyVisitor::didCopy): This callback is called by an object that has just successfully copied its + backing store. It indicates to the CopiedBlock that somebody has just finished evacuating some number of + bytes from it, and, if the CopiedBlock now has no more live bytes, can be recycled immediately. + * heap/GCThread.cpp: Added. + (JSC): + (JSC::GCThread::GCThread): This is a new class that encapsulates a single thread responsible for participating + in a specific set of GC phases. Currently, that set of phases includes Mark, Copy, and Exit. Each thread + monitors a shared variable in its associated GCThreadSharedData. The main thread updates this m_currentPhase + variable as collection progresses through the various phases. Parallel marking still works exactly like it + has. In other words, the "run loop" for each of the GC threads sits above any individual phase, thus keeping + the separate phases of the collector orthogonal. + (JSC::GCThread::threadID): + (JSC::GCThread::initializeThreadID): + (JSC::GCThread::slotVisitor): + (JSC::GCThread::copyVisitor): + (JSC::GCThread::waitForNextPhase): + (JSC::GCThread::gcThreadMain): + (JSC::GCThread::gcThreadStartFunc): + * heap/GCThread.h: Added. + (JSC): + (GCThread): + * heap/GCThreadSharedData.cpp: The GCThreadSharedData now has a list of GCThread objects rather than raw + ThreadIdentifiers. + (JSC::GCThreadSharedData::resetChildren): + (JSC::GCThreadSharedData::childVisitCount): + (JSC::GCThreadSharedData::GCThreadSharedData): + (JSC::GCThreadSharedData::~GCThreadSharedData): + (JSC::GCThreadSharedData::reset): + (JSC::GCThreadSharedData::didStartMarking): Callback to let the GCThreadSharedData know that marking has + started and updates the m_currentPhase variable and notifies the GCThreads accordingly. + (JSC::GCThreadSharedData::didFinishMarking): Ditto for finishing marking. + (JSC::GCThreadSharedData::didStartCopying): Ditto for starting the copying phase. + (JSC::GCThreadSharedData::didFinishCopying): Ditto for finishing copying. + * heap/GCThreadSharedData.h: + (JSC): + (GCThreadSharedData): + (JSC::GCThreadSharedData::getNextBlocksToCopy): Atomically gets the next chunk of work for a copying thread. + * heap/Heap.cpp: + (JSC::Heap::Heap): + (JSC::Heap::markRoots): + (JSC): + (JSC::Heap::copyBackingStores): Responsible for setting up the copying phase, notifying the copying threads, + and doing any copying work if necessary. + (JSC::Heap::collect): + * heap/Heap.h: + (Heap): + (JSC): + (JSC::CopyFunctor::CopyFunctor): + (CopyFunctor): + (JSC::CopyFunctor::operator()): + * heap/IncrementalSweeper.cpp: Changed the incremental sweeper to have a reference to the list of MarkedBlocks + that need sweeping, since this now resides in the Heap so that it can be easily shared by the GCThreads. + (JSC::IncrementalSweeper::IncrementalSweeper): + (JSC::IncrementalSweeper::startSweeping): + * heap/IncrementalSweeper.h: + (JSC): + (IncrementalSweeper): + * heap/SlotVisitor.cpp: + (JSC::SlotVisitor::setup): + (JSC::SlotVisitor::drainFromShared): We no longer do any copying-related work here. + (JSC): + * heap/SlotVisitor.h: + (SlotVisitor): + * heap/SlotVisitorInlineMethods.h: + (JSC): + (JSC::SlotVisitor::copyLater): Notifies the CopiedBlock that there are some live bytes that may need + to be copied. + * runtime/Butterfly.h: + (JSC): + (Butterfly): + * runtime/ButterflyInlineMethods.h: + (JSC::Butterfly::createUninitializedDuringCollection): Uses the new CopyVisitor. + * runtime/ClassInfo.h: + (MethodTable): Added new "virtual" function copyBackingStore to method table. + (JSC): + * runtime/JSCell.cpp: + (JSC::JSCell::copyBackingStore): Default implementation that does nothing. + (JSC): + * runtime/JSCell.h: + (JSC): + (JSCell): + * runtime/JSObject.cpp: + (JSC::JSObject::copyButterfly): Does the actual copying of the butterfly. + (JSC): + (JSC::JSObject::visitButterfly): Calls copyLater for the butterfly. + (JSC::JSObject::copyBackingStore): + * runtime/JSObject.h: + (JSObject): + (JSC::JSCell::methodTable): + (JSC::JSCell::inherits): + * runtime/Options.h: Added two new constants, minHeapUtilization and minCopiedBlockUtilization, + to govern the amount of fragmentation we allow before doing copying. + (JSC): + +2012-10-12 Filip Pizlo <fpizlo@apple.com> + + DFG array allocation calls should not return an encoded JSValue + https://bugs.webkit.org/show_bug.cgi?id=99196 + + Reviewed by Mark Hahnenberg. + + The array allocation operations now return a pointer instead. This makes it + easier to share code between 32-bit and 64-bit. + + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::callOperation): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + +2012-10-01 Jer Noble <jer.noble@apple.com> + + Enable ENCRYPTED_MEDIA support on Mac. + https://bugs.webkit.org/show_bug.cgi?id=98044 + + Reviewed by Anders Carlsson. + + Enable the ENCRYPTED_MEDIA flag. + + * Configurations/FeatureDefines.xcconfig: + +2012-10-12 Filip Pizlo <fpizlo@apple.com> + + Unreviewed. It should be possible to build JSC on ARMv7. + + * assembler/MacroAssemblerARMv7.h: + (JSC::MacroAssemblerARMv7::patchableBranchPtr): + +2012-10-11 Mark Hahnenberg <mhahnenberg@apple.com> + + BlockAllocator should use regions as its VM allocation abstraction + https://bugs.webkit.org/show_bug.cgi?id=99107 + + Reviewed by Geoffrey Garen. + + Currently the BlockAllocator allocates a single block at a time directly from the OS. Our block + allocations are on the large-ish side (64 KB) to amortize across many allocations the expense of + mapping new virtual memory from the OS. These large blocks are then shared between the MarkedSpace + and the CopiedSpace. This design makes it difficult to vary the size of the blocks in different + parts of the Heap while still allowing us to amortize the VM allocation costs. + + We should redesign the BlockAllocator so that it has a layer of indirection between blocks that are + used by the allocator/collector and our primary unit of VM allocation from the OS. In particular, + the BlockAllocator should allocate Regions of virtual memory from the OS, which are then subdivided + into one or more Blocks to be used in our custom allocators. This design has the following nice properties: + + 1) We can remove the knowledge of PageAllocationAligned from HeapBlocks. Each HeapBlock will now + only know what Region it belongs to. The Region maintains all the metadata for how to allocate + and deallocate virtual memory from the OS. + + 2) We can easily allocate in larger chunks than we need to satisfy a particular request for a Block. + We can then continue to amortize our VM allocation costs while allowing for smaller block sizes, + which should increase locality in the mutator when allocating, lazy sweeping, etc. + + 3) By encapsulating the logic of where our memory comes from inside of the Region class, we can more + easily transition over to allocating VM from a specific range of pre-reserved address space. This + will be a necessary step along the way to 32-bit pointers. + + This particular patch will not change the size of MarkedBlocks or CopiedBlocks, nor will it change how + much VM we allocate per failed Block request. It only sets up the data structures that we need to make + these changes in future patches. + + Most of the changes in this patch relate to the addition of the Region class to be used by the + BlockAllocator and the threading of changes made to BlockAllocator's interface through to the call sites. + + * heap/BlockAllocator.cpp: The BlockAllocator now has three lists that track the three disjoint sets of + Regions that it cares about: empty regions, partially full regions, and completely full regions. + Empty regions have no blocks currently in use and can be freed immediately if the freeing thread + determines they should be. Partial regions have some blocks used, but aren't completely in use yet. + These regions are preferred for recycling before empty regions to mitigate fragmentation within regions. + Completely full regions are no longer able to be used for allocations. Regions move between these + three lists as they are created and their constituent blocks are allocated and deallocated. + (JSC::BlockAllocator::BlockAllocator): + (JSC::BlockAllocator::~BlockAllocator): + (JSC::BlockAllocator::releaseFreeRegions): + (JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock): + (JSC::BlockAllocator::waitForRelativeTime): + (JSC::BlockAllocator::blockFreeingThreadMain): + * heap/BlockAllocator.h: + (JSC): + (DeadBlock): + (JSC::DeadBlock::DeadBlock): + (Region): + (JSC::Region::blockSize): + (JSC::Region::isFull): + (JSC::Region::isEmpty): + (JSC::Region::create): This function is responsible for doing the actual VM allocation. This should be the + only function in the entire JSC object runtime that calls out the OS for virtual memory allocation. + (JSC::Region::Region): + (JSC::Region::~Region): + (JSC::Region::allocate): + (JSC::Region::deallocate): + (BlockAllocator): + (JSC::BlockAllocator::tryAllocateFromRegion): Helper function that encapsulates checking a particular list + of regions for a free block. + (JSC::BlockAllocator::allocate): + (JSC::BlockAllocator::allocateCustomSize): This function is responsible for allocating one-off custom size + regions for use in oversize allocations in both the MarkedSpace and the CopiedSpace. These regions are not + tracked by the BlockAllocator. The only pointer to them is in the HeapBlock that is returned. These regions + contain exactly one block. + (JSC::BlockAllocator::deallocate): + (JSC::BlockAllocator::deallocateCustomSize): This function is responsible for deallocating one-off custom size + regions. The regions are deallocated back to the OS eagerly. + * heap/CopiedBlock.h: Re-worked CopiedBlocks to use Regions instead of PageAllocationAligned. + (CopiedBlock): + (JSC::CopiedBlock::createNoZeroFill): + (JSC::CopiedBlock::create): + (JSC::CopiedBlock::CopiedBlock): + (JSC::CopiedBlock::payloadEnd): + (JSC::CopiedBlock::capacity): + * heap/CopiedSpace.cpp: + (JSC::CopiedSpace::~CopiedSpace): + (JSC::CopiedSpace::tryAllocateOversize): + (JSC::CopiedSpace::tryReallocateOversize): + (JSC::CopiedSpace::doneCopying): + * heap/CopiedSpaceInlineMethods.h: + (JSC::CopiedSpace::allocateBlockForCopyingPhase): + (JSC::CopiedSpace::allocateBlock): + * heap/HeapBlock.h: + (JSC::HeapBlock::destroy): + (JSC::HeapBlock::HeapBlock): + (JSC::HeapBlock::region): + (HeapBlock): + * heap/MarkedAllocator.cpp: + (JSC::MarkedAllocator::allocateBlock): + * heap/MarkedBlock.cpp: + (JSC::MarkedBlock::create): + (JSC::MarkedBlock::MarkedBlock): + * heap/MarkedBlock.h: + (JSC::MarkedBlock::capacity): + * heap/MarkedSpace.cpp: + (JSC::MarkedSpace::freeBlock): + +2012-10-11 Filip Pizlo <fpizlo@apple.com> + + UInt32ToNumber and OSR exit should be aware of copy propagation and correctly recover both versions of a variable that was subject to a UInt32ToNumber cast + https://bugs.webkit.org/show_bug.cgi?id=99100 + <rdar://problem/12480955> + + Reviewed by Michael Saboff and Mark Hahnenberg. + + Fixed by forcing UInt32ToNumber to use a different register. This "undoes" the copy propagation that we + would have been doing, since it has no performance effect in this case and has the benefit of making the + OSR exit compiler a lot simpler. + + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): + +2012-10-11 Geoffrey Garen <ggaren@apple.com> + + Removed some more static assumptions about inline object capacity + https://bugs.webkit.org/show_bug.cgi?id=98603 + + Reviewed by Filip Pizlo. + + * dfg/DFGSpeculativeJIT.h: + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): Use JSObject::allocationSize() + for a little more flexibility. We still pass it a constant inline capacity + because the JIT doesn't have a strategy for selecting a size class based + on non-constant capacity yet. "INLINE_STORAGE_CAPACITY" is a marker for + code that makes static assumptions about object size. + + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + * llint/LLIntData.cpp: + (JSC::LLInt::Data::performAssertions): + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: Ditto for the rest of our many execution engines. + + * runtime/JSObject.h: + (JSC::JSObject::allocationSize): + (JSC::JSFinalObject::finishCreation): + (JSC::JSFinalObject::create): New helper function for computing object + size dynamically, since we plan to have objects of different sizes. + + (JSC::JSFinalObject::JSFinalObject): Note that our m_inlineStorage used + to auto-generate an implicit C++ constructor with default null initialization. + This memory is not observed in its uninitialized state, and our LLInt and + JIT allocators do not initialize it, so I did not add any explicit code + to do so, now that the implicit code is gone. + + (JSC::JSObject::offsetOfInlineStorage): Changed the math here to match + inlineStorageUnsafe(), since we can rely on an explicit data member anymore. + +2012-10-11 Geoffrey Garen <ggaren@apple.com> + + Enable RUNTIME_HEURISTICS all the time, for easier testing + https://bugs.webkit.org/show_bug.cgi?id=99090 + + Reviewed by Filip Pizlo. + + I find myself using this a lot, and there doesn't seem to be an obvious + reason to compile it out, since it only runs once at startup. + + * runtime/Options.cpp: + (JSC::overrideOptionWithHeuristic): + (JSC::Options::initialize): + * runtime/Options.h: Removed the #ifdef. + +2012-10-11 Geoffrey Garen <ggaren@apple.com> + + Removed ASSERT_CLASS_FITS_IN_CELL + https://bugs.webkit.org/show_bug.cgi?id=97634 + + Reviewed by Mark Hahnenberg. + + Our collector now supports arbitrarily sized objects, so the ASSERT is not needed. + + * API/JSCallbackFunction.cpp: + * API/JSCallbackObject.cpp: + * heap/MarkedSpace.h: + * jsc.cpp: + * runtime/Arguments.cpp: + * runtime/ArrayConstructor.cpp: + * runtime/ArrayPrototype.cpp: + * runtime/BooleanConstructor.cpp: + * runtime/BooleanObject.cpp: + * runtime/BooleanPrototype.cpp: + * runtime/DateConstructor.cpp: + * runtime/DatePrototype.cpp: + * runtime/Error.cpp: + * runtime/ErrorConstructor.cpp: + * runtime/ErrorPrototype.cpp: + * runtime/FunctionConstructor.cpp: + * runtime/FunctionPrototype.cpp: + * runtime/InternalFunction.cpp: + * runtime/JSActivation.cpp: + * runtime/JSArray.cpp: + * runtime/JSBoundFunction.cpp: + * runtime/JSFunction.cpp: + * runtime/JSGlobalObject.cpp: + * runtime/JSGlobalThis.cpp: + * runtime/JSNameScope.cpp: + * runtime/JSNotAnObject.cpp: + * runtime/JSONObject.cpp: + * runtime/JSObject.cpp: + * runtime/JSPropertyNameIterator.cpp: + * runtime/JSScope.cpp: + * runtime/JSWithScope.cpp: + * runtime/JSWrapperObject.cpp: + * runtime/MathObject.cpp: + * runtime/NameConstructor.cpp: + * runtime/NamePrototype.cpp: + * runtime/NativeErrorConstructor.cpp: + * runtime/NativeErrorPrototype.cpp: + * runtime/NumberConstructor.cpp: + * runtime/NumberObject.cpp: + * runtime/NumberPrototype.cpp: + * runtime/ObjectConstructor.cpp: + * runtime/ObjectPrototype.cpp: + * runtime/RegExpConstructor.cpp: + * runtime/RegExpMatchesArray.cpp: + * runtime/RegExpObject.cpp: + * runtime/RegExpPrototype.cpp: + * runtime/StringConstructor.cpp: + * runtime/StringObject.cpp: + * runtime/StringPrototype.cpp: + * testRegExp.cpp: Removed the ASSERT. + +2012-10-11 Filip Pizlo <fpizlo@apple.com> + + DFG should inline code blocks that use new_array_buffer + https://bugs.webkit.org/show_bug.cgi?id=98996 + + Reviewed by Geoffrey Garen. + + This adds plumbing to drop in constant buffers from the inlinees to the inliner. + It's smart about not duplicating buffers needlessly but doesn't try to completely + hash-cons them, either. + + * bytecode/CodeBlock.h: + (JSC::CodeBlock::numberOfConstantBuffers): + (JSC::CodeBlock::addConstantBuffer): + (JSC::CodeBlock::constantBufferAsVector): + (JSC::CodeBlock::constantBuffer): + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGByteCodeParser.cpp: + (ConstantBufferKey): + (JSC::DFG::ConstantBufferKey::ConstantBufferKey): + (JSC::DFG::ConstantBufferKey::operator==): + (JSC::DFG::ConstantBufferKey::hash): + (JSC::DFG::ConstantBufferKey::isHashTableDeletedValue): + (JSC::DFG::ConstantBufferKey::codeBlock): + (JSC::DFG::ConstantBufferKey::index): + (DFG): + (JSC::DFG::ConstantBufferKeyHash::hash): + (JSC::DFG::ConstantBufferKeyHash::equal): + (ConstantBufferKeyHash): + (WTF): + (ByteCodeParser): + (InlineStackEntry): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGCapabilities.h: + (JSC::DFG::canInlineOpcode): + * 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): + +2012-10-10 Zoltan Horvath <zoltan@webkit.org> + + Pageload tests should measure memory usage + https://bugs.webkit.org/show_bug.cgi?id=93958 + + Reviewed by Ryosuke Niwa. + + Add JS Heap and Heap memory measurement to PageLoad tests. + + * heap/HeapStatistics.cpp: + (JSC::HeapStatistics::usedJSHeap): Add new private function to expose the used JS Heap size. + (JSC): + * heap/HeapStatistics.h: + (HeapStatistics): Add new private function to expose the used JS Heap size. + +2012-10-10 Balazs Kilvady <kilvadyb@homejinni.com> + + RegisterFile to JSStack rename fix for a struct member. + + Compilation problem in debug build on MIPS + https://bugs.webkit.org/show_bug.cgi?id=98808 + + Reviewed by Alexey Proskuryakov. + + In ASSERT conditions structure field name "registerFile" was replaced + with type name "JSStack" and it should be "stack". + + * jit/JITStubs.cpp: + (JSC::JITThunks::JITThunks): structure member name fix. + +2012-10-10 Michael Saboff <msaboff@apple.com> + + After r130344, OpaqueJSString::string() shouldn't directly return the wrapped String + https://bugs.webkit.org/show_bug.cgi?id=98801 + + Reviewed by Geoffrey Garen. + + Return a copy of the wrapped String so that the wrapped string cannot be turned into + an Identifier. + + * API/OpaqueJSString.cpp: + (OpaqueJSString::string): + * API/OpaqueJSString.h: + (OpaqueJSString): + +2012-10-10 Peter Gal <galpeter@inf.u-szeged.hu> + + Add moveDoubleToInts and moveIntsToDouble to MacroAssemblerARM + https://bugs.webkit.org/show_bug.cgi?id=98855 + + Reviewed by Filip Pizlo. + + Implement the missing moveDoubleToInts and moveIntsToDouble + methods in the MacroAssemblerARM after r130839. + + * assembler/MacroAssemblerARM.h: + (JSC::MacroAssemblerARM::moveDoubleToInts): + (MacroAssemblerARM): + (JSC::MacroAssemblerARM::moveIntsToDouble): + +2012-10-09 Filip Pizlo <fpizlo@apple.com> + + Typed arrays should not be 20x slower in the baseline JIT than in the DFG JIT + https://bugs.webkit.org/show_bug.cgi?id=98605 + + Reviewed by Oliver Hunt and Gavin Barraclough. + + This adds typed array get_by_val/put_by_val patching to the baseline JIT. It's + a big (~40%) win on benchmarks that have trouble staying in the DFG JIT. Even + if we fix those benchmarks, this functionality gives us the insurance that we + typically desire with all speculative optimizations: even if we bail to + baseline, we're still reasonably performant. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/MacroAssembler.cpp: Added. + (JSC): + * assembler/MacroAssembler.h: + (MacroAssembler): + (JSC::MacroAssembler::patchableBranchPtr): + * assembler/MacroAssemblerARMv7.h: + (MacroAssemblerARMv7): + (JSC::MacroAssemblerARMv7::moveDoubleToInts): + (JSC::MacroAssemblerARMv7::moveIntsToDouble): + (JSC::MacroAssemblerARMv7::patchableBranchPtr): + * assembler/MacroAssemblerX86.h: + (MacroAssemblerX86): + (JSC::MacroAssemblerX86::moveDoubleToInts): + (JSC::MacroAssemblerX86::moveIntsToDouble): + * bytecode/ByValInfo.h: + (JSC::hasOptimizableIndexingForClassInfo): + (JSC): + (JSC::hasOptimizableIndexing): + (JSC::jitArrayModeForClassInfo): + (JSC::jitArrayModeForStructure): + (JSC::ByValInfo::ByValInfo): + (ByValInfo): + * dfg/DFGAssemblyHelpers.cpp: + (DFG): + * dfg/DFGAssemblyHelpers.h: + (AssemblyHelpers): + (JSC::DFG::AssemblyHelpers::boxDouble): + (JSC::DFG::AssemblyHelpers::unboxDouble): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): + (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + * jit/JIT.h: + (JIT): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::privateCompileGetByVal): + (JSC::JIT::privateCompilePutByVal): + (JSC::JIT::emitIntTypedArrayGetByVal): + (JSC): + (JSC::JIT::emitFloatTypedArrayGetByVal): + (JSC::JIT::emitIntTypedArrayPutByVal): + (JSC::JIT::emitFloatTypedArrayPutByVal): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + * jit/JITStubs.cpp: + (JSC::DEFINE_STUB_FUNCTION): + * runtime/JSCell.h: + * runtime/JSGlobalData.h: + (JSGlobalData): + (JSC::JSGlobalData::typedArrayDescriptor): + * runtime/TypedArrayDescriptor.h: Added. + (JSC): + (JSC::TypedArrayDescriptor::TypedArrayDescriptor): + (TypedArrayDescriptor): + +2012-10-09 Michael Saboff <msaboff@apple.com> + + Add tests to testapi for null OpaqueJSStrings + https://bugs.webkit.org/show_bug.cgi?id=98805 + + Reviewed by Geoffrey Garen. + + Added tests that check that OpaqueJSString, which is wrapped via JSStringRef, properly returns + null strings and that a null string in a JSStringRef will return a NULL JSChar* and 0 length + via the JSStringGetCharactersPtr() and JSStringGetLength() APIs respectively. Added a check that + JSValueMakeFromJSONString() properly handles a null string as well. + + * API/tests/testapi.c: + (main): + +2012-10-09 Jian Li <jianli@chromium.org> + + Update the CSS property used to support draggable regions. + https://bugs.webkit.org/show_bug.cgi?id=97156 + + Reviewed by Adam Barth. + + The CSS property to support draggable regions, guarded under + WIDGET_REGION is now disabled from Mac WebKit, in order not to cause + confusion with DASHBOARD_SUPPORT feature. + + * Configurations/FeatureDefines.xcconfig: Disable WIDGET_REGION feature. + +2012-10-09 Filip Pizlo <fpizlo@apple.com> + + Unreviewed, adding forgotten files. + + * bytecode/ByValInfo.h: Added. + (JSC): + (JSC::isOptimizableIndexingType): + (JSC::jitArrayModeForIndexingType): + (JSC::ByValInfo::ByValInfo): + (ByValInfo): + (JSC::getByValInfoBytecodeIndex): + * runtime/IndexingType.cpp: Added. + (JSC): + (JSC::indexingTypeToString): + +2012-10-08 Filip Pizlo <fpizlo@apple.com> + + JSC should infer when indexed storage is contiguous, and optimize for it + https://bugs.webkit.org/show_bug.cgi?id=97288 + + Reviewed by Mark Hahnenberg. + + This introduces a new kind of indexed property storage called Contiguous, + which has the following properties: + + - No header bits beyond IndexedHeader. This results in a 16 byte reduction + in memory usage per array versus an ArrayStorage array. It also means + that the total memory usage for an empty array is now just 3 * 8 on both + 32-bit and 64-bit. Of that, only 8 bytes are array-specific; the rest is + our standard object header overhead. + + - No need for hole checks on store. This results in a ~4% speed-up on + Kraken and a ~1% speed-up on V8v7. + + - publicLength <= vectorLength. This means that doing new Array(blah) + immediately allocates room for blah elements. + + - No sparse map or index bias. + + If you ever do things to an array that would require publicLength > + vectorLength, a sparse map, or index bias, then we switch to ArrayStorage + mode. This seems to never happen in any benchmark we track, and is unlikely + to happen very frequently on any website. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * assembler/AbstractMacroAssembler.h: + (JSC::AbstractMacroAssembler::JumpList::append): + * assembler/MacroAssembler.h: + (MacroAssembler): + (JSC::MacroAssembler::patchableBranchTest32): + * bytecode/ByValInfo.h: Added. + (JSC): + (JSC::isOptimizableIndexingType): + (JSC::jitArrayModeForIndexingType): + (JSC::ByValInfo::ByValInfo): + (ByValInfo): + (JSC::getByValInfoBytecodeIndex): + * bytecode/CodeBlock.h: + (CodeBlock): + (JSC::CodeBlock::getByValInfo): + (JSC::CodeBlock::setNumberOfByValInfos): + (JSC::CodeBlock::numberOfByValInfos): + (JSC::CodeBlock::byValInfo): + * bytecode/SamplingTool.h: + * dfg/DFGAbstractState.cpp: + (JSC::DFG::AbstractState::execute): + * dfg/DFGArrayMode.cpp: + (JSC::DFG::fromObserved): + (JSC::DFG::modeAlreadyChecked): + (JSC::DFG::modeToString): + * dfg/DFGArrayMode.h: + (DFG): + (JSC::DFG::modeUsesButterfly): + (JSC::DFG::modeIsJSArray): + (JSC::DFG::isInBoundsAccess): + (JSC::DFG::mayStoreToTail): + (JSC::DFG::mayStoreToHole): + (JSC::DFG::modeIsPolymorphic): + (JSC::DFG::polymorphicIncludesContiguous): + (JSC::DFG::polymorphicIncludesArrayStorage): + (JSC::DFG::canCSEStorage): + (JSC::DFG::modeSupportsLength): + (JSC::DFG::benefitsFromStructureCheck): + (JSC::DFG::isEffectful): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::handleIntrinsic): + * dfg/DFGCSEPhase.cpp: + (JSC::DFG::CSEPhase::getArrayLengthElimination): + (JSC::DFG::CSEPhase::getByValLoadElimination): + (JSC::DFG::CSEPhase::performNodeCSE): + * dfg/DFGFixupPhase.cpp: + (JSC::DFG::FixupPhase::fixupNode): + (JSC::DFG::FixupPhase::checkArray): + (JSC::DFG::FixupPhase::blessArrayOperation): + * dfg/DFGGraph.h: + (JSC::DFG::Graph::byValIsPure): + * dfg/DFGOperations.cpp: + * dfg/DFGOperations.h: + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryCacheGetByID): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::checkArray): + (JSC::DFG::SpeculativeJIT::arrayify): + (JSC::DFG::SpeculativeJIT::compileGetArrayLength): + (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): + (DFG): + * dfg/DFGSpeculativeJIT.h: + (DFG): + (JSC::DFG::SpeculativeJIT::callOperation): + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister): + (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compileContiguousGetByVal): + (DFG): + (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal): + (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): + (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compileContiguousGetByVal): + (DFG): + (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal): + (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): + (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal): + (JSC::DFG::SpeculativeJIT::compile): + * interpreter/Interpreter.cpp: + (SamplingScope): + (JSC::SamplingScope::SamplingScope): + (JSC::SamplingScope::~SamplingScope): + (JSC): + (JSC::Interpreter::execute): + * jit/JIT.cpp: + (JSC::JIT::privateCompileSlowCases): + (JSC::JIT::privateCompile): + * jit/JIT.h: + (JSC::ByValCompilationInfo::ByValCompilationInfo): + (ByValCompilationInfo): + (JSC): + (JIT): + (JSC::JIT::compileGetByVal): + (JSC::JIT::compilePutByVal): + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateJSArray): + (JSC::JIT::emitArrayProfileStoreToHoleSpecialCase): + (JSC): + (JSC::arrayProfileSaw): + (JSC::JIT::chooseArrayMode): + * jit/JITOpcodes.cpp: + (JSC::JIT::emitSlow_op_get_argument_by_val): + (JSC::JIT::emit_op_new_array): + (JSC::JIT::emitSlow_op_new_array): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::emitSlow_op_get_argument_by_val): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emitArrayStorageGetByVal): + (JSC::JIT::emitSlow_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::emitContiguousPutByVal): + (JSC::JIT::emitArrayStoragePutByVal): + (JSC::JIT::emitSlow_op_put_by_val): + (JSC::JIT::privateCompilePatchGetArrayLength): + (JSC::JIT::privateCompileGetByVal): + (JSC::JIT::privateCompilePutByVal): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_by_val): + (JSC): + (JSC::JIT::emitContiguousGetByVal): + (JSC::JIT::emitArrayStorageGetByVal): + (JSC::JIT::emitSlow_op_get_by_val): + (JSC::JIT::emit_op_put_by_val): + (JSC::JIT::emitContiguousPutByVal): + (JSC::JIT::emitArrayStoragePutByVal): + (JSC::JIT::emitSlow_op_put_by_val): + * jit/JITStubs.cpp: + (JSC::getByVal): + (JSC): + (JSC::DEFINE_STUB_FUNCTION): + (JSC::putByVal): + * jit/JITStubs.h: + * llint/LowLevelInterpreter.asm: + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: + * runtime/ArrayConventions.h: + (JSC::isDenseEnoughForVector): + * runtime/ArrayPrototype.cpp: + (JSC): + (JSC::shift): + (JSC::unshift): + (JSC::arrayProtoFuncPush): + (JSC::arrayProtoFuncShift): + (JSC::arrayProtoFuncSplice): + (JSC::arrayProtoFuncUnShift): + * runtime/Butterfly.h: + (Butterfly): + (JSC::Butterfly::fromPointer): + (JSC::Butterfly::pointer): + (JSC::Butterfly::publicLength): + (JSC::Butterfly::vectorLength): + (JSC::Butterfly::setPublicLength): + (JSC::Butterfly::setVectorLength): + (JSC::Butterfly::contiguous): + (JSC::Butterfly::fromContiguous): + * runtime/ButterflyInlineMethods.h: + (JSC::Butterfly::unshift): + (JSC::Butterfly::shift): + * runtime/IndexingHeaderInlineMethods.h: + (JSC::IndexingHeader::indexingPayloadSizeInBytes): + * runtime/IndexingType.cpp: Added. + (JSC): + (JSC::indexingTypeToString): + * runtime/IndexingType.h: + (JSC): + (JSC::hasContiguous): + * runtime/JSArray.cpp: + (JSC::JSArray::setLengthWithArrayStorage): + (JSC::JSArray::setLength): + (JSC): + (JSC::JSArray::pop): + (JSC::JSArray::push): + (JSC::JSArray::shiftCountWithArrayStorage): + (JSC::JSArray::shiftCountWithAnyIndexingType): + (JSC::JSArray::unshiftCountWithArrayStorage): + (JSC::JSArray::unshiftCountWithAnyIndexingType): + (JSC::JSArray::sortNumericVector): + (JSC::JSArray::sortNumeric): + (JSC::JSArray::sortCompactedVector): + (JSC::JSArray::sort): + (JSC::JSArray::sortVector): + (JSC::JSArray::fillArgList): + (JSC::JSArray::copyToArguments): + (JSC::JSArray::compactForSorting): + * runtime/JSArray.h: + (JSC::JSArray::shiftCountForShift): + (JSC::JSArray::shiftCountForSplice): + (JSArray): + (JSC::JSArray::shiftCount): + (JSC::JSArray::unshiftCountForShift): + (JSC::JSArray::unshiftCountForSplice): + (JSC::JSArray::unshiftCount): + (JSC::JSArray::isLengthWritable): + (JSC::createContiguousArrayButterfly): + (JSC): + (JSC::JSArray::create): + (JSC::JSArray::tryCreateUninitialized): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::reset): + (JSC): + (JSC::JSGlobalObject::haveABadTime): + (JSC::JSGlobalObject::visitChildren): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::arrayStructureWithArrayStorage): + (JSC::JSGlobalObject::addressOfArrayStructureWithArrayStorage): + (JSC::constructEmptyArray): + * runtime/JSObject.cpp: + (JSC::JSObject::visitButterfly): + (JSC::JSObject::getOwnPropertySlotByIndex): + (JSC::JSObject::putByIndex): + (JSC::JSObject::enterDictionaryIndexingMode): + (JSC::JSObject::createInitialContiguous): + (JSC): + (JSC::JSObject::createArrayStorage): + (JSC::JSObject::convertContiguousToArrayStorage): + (JSC::JSObject::ensureContiguousSlow): + (JSC::JSObject::ensureArrayStorageSlow): + (JSC::JSObject::ensureIndexedStorageSlow): + (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode): + (JSC::JSObject::switchToSlowPutArrayStorage): + (JSC::JSObject::setPrototype): + (JSC::JSObject::deletePropertyByIndex): + (JSC::JSObject::getOwnPropertyNames): + (JSC::JSObject::defineOwnIndexedProperty): + (JSC::JSObject::putByIndexBeyondVectorLengthContiguousWithoutAttributes): + (JSC::JSObject::putByIndexBeyondVectorLength): + (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage): + (JSC::JSObject::putDirectIndexBeyondVectorLength): + (JSC::JSObject::getNewVectorLength): + (JSC::JSObject::countElementsInContiguous): + (JSC::JSObject::increaseVectorLength): + (JSC::JSObject::ensureContiguousLengthSlow): + (JSC::JSObject::getOwnPropertyDescriptor): + * 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): + (JSObject): + (JSC::JSObject::ensureContiguous): + (JSC::JSObject::ensureIndexedStorage): + (JSC::JSObject::ensureContiguousLength): + (JSC::JSObject::indexingData): + (JSC::JSObject::relevantLength): + * runtime/JSValue.cpp: + (JSC::JSValue::description): + * runtime/Options.cpp: + (JSC::Options::initialize): + * runtime/Structure.cpp: + (JSC::Structure::needsSlowPutIndexing): + (JSC): + (JSC::Structure::suggestedArrayStorageTransition): + * runtime/Structure.h: + (Structure): + * runtime/StructureTransitionTable.h: + (JSC::newIndexingType): + +2012-10-09 Michael Saboff <msaboff@apple.com> + + After r130344, OpaqueJSString::identifier() adds wrapped String to identifier table + https://bugs.webkit.org/show_bug.cgi?id=98693 + REGRESSION (r130344): Install failed in Install Environment + <rdar://problem/12450118> + + Reviewed by Mark Rowe. + + Use Identifier(LChar*, length) or Identifier(UChar*, length) constructors so that we don't + add the String instance in the OpaqueJSString to any identifier tables. + + * API/OpaqueJSString.cpp: + (OpaqueJSString::identifier): + +2012-10-08 Mark Lam <mark.lam@apple.com> + + Renamed RegisterFile to JSStack, and removed prototype of the + previously deleted Interpreter::privateExecute(). + https://bugs.webkit.org/show_bug.cgi?id=98717. + + Reviewed by Filip Pizlo. + + * CMakeLists.txt: + * GNUmakefile.list.am: + * JavaScriptCore.order: + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: + * JavaScriptCore.xcodeproj/project.pbxproj: + * Target.pri: + * bytecode/BytecodeConventions.h: + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::nameForRegister): + * bytecode/CodeBlock.h: + (CodeBlock): + * bytecode/ValueRecovery.h: + (JSC::ValueRecovery::alreadyInJSStack): + (JSC::ValueRecovery::alreadyInJSStackAsUnboxedInt32): + (JSC::ValueRecovery::alreadyInJSStackAsUnboxedCell): + (JSC::ValueRecovery::alreadyInJSStackAsUnboxedBoolean): + (JSC::ValueRecovery::alreadyInJSStackAsUnboxedDouble): + (JSC::ValueRecovery::displacedInJSStack): + (JSC::ValueRecovery::isAlreadyInJSStack): + (JSC::ValueRecovery::virtualRegister): + (JSC::ValueRecovery::dump): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::resolveCallee): + (JSC::BytecodeGenerator::emitCall): + (JSC::BytecodeGenerator::emitConstruct): + * bytecompiler/BytecodeGenerator.h: + (JSC::BytecodeGenerator::registerFor): + * dfg/DFGAbstractState.h: + (AbstractState): + * dfg/DFGAssemblyHelpers.h: + (JSC::DFG::AssemblyHelpers::emitGetFromCallFrameHeaderPtr): + (JSC::DFG::AssemblyHelpers::emitPutToCallFrameHeader): + (JSC::DFG::AssemblyHelpers::emitPutImmediateToCallFrameHeader): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::getDirect): + (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal): + (JSC::DFG::ByteCodeParser::addCall): + (JSC::DFG::ByteCodeParser::InlineStackEntry::remapOperand): + (JSC::DFG::ByteCodeParser::handleInlining): + (JSC::DFG::ByteCodeParser::parseBlock): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGGenerationInfo.h: + (GenerationInfo): + (JSC::DFG::GenerationInfo::needsSpill): + * dfg/DFGGraph.h: + * dfg/DFGJITCompiler.cpp: + (JSC::DFG::JITCompiler::compileEntry): + (JSC::DFG::JITCompiler::compileFunction): + * dfg/DFGJITCompiler.h: + (JSC::DFG::JITCompiler::beginCall): + * dfg/DFGOSREntry.cpp: + (JSC::DFG::prepareOSREntry): + * dfg/DFGOSRExitCompiler32_64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGOSRExitCompiler64.cpp: + (JSC::DFG::OSRExitCompiler::compileExit): + * dfg/DFGRepatch.cpp: + (JSC::DFG::tryBuildGetByIDList): + * dfg/DFGSpeculativeJIT.cpp: + (JSC::DFG::SpeculativeJIT::compile): + (JSC::DFG::SpeculativeJIT::checkArgumentTypes): + (JSC::DFG::SpeculativeJIT::computeValueRecoveryFor): + * dfg/DFGSpeculativeJIT.h: + (SpeculativeJIT): + (JSC::DFG::SpeculativeJIT::spill): + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::emitCall): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::fillInteger): + (JSC::DFG::SpeculativeJIT::emitCall): + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGThunks.cpp: + (JSC::DFG::throwExceptionFromCallSlowPathGenerator): + (JSC::DFG::slowPathFor): + (JSC::DFG::virtualForThunkGenerator): + * dfg/DFGValueSource.cpp: + (JSC::DFG::ValueSource::dump): + * dfg/DFGValueSource.h: + (JSC::DFG::dataFormatToValueSourceKind): + (JSC::DFG::valueSourceKindToDataFormat): + (JSC::DFG::isInJSStack): + (JSC::DFG::ValueSource::forSpeculation): + (JSC::DFG::ValueSource::isInJSStack): + (JSC::DFG::ValueSource::valueRecovery): + * dfg/DFGVariableEventStream.cpp: + (JSC::DFG::VariableEventStream::reconstruct): + * heap/Heap.cpp: + (JSC::Heap::stack): + (JSC::Heap::getConservativeRegisterRoots): + (JSC::Heap::markRoots): + * heap/Heap.h: + (JSC): + (Heap): + * interpreter/CallFrame.cpp: + (JSC::CallFrame::stack): + * interpreter/CallFrame.h: + (JSC::ExecState::calleeAsValue): + (JSC::ExecState::callee): + (JSC::ExecState::codeBlock): + (JSC::ExecState::scope): + (JSC::ExecState::callerFrame): + (JSC::ExecState::returnPC): + (JSC::ExecState::hasReturnPC): + (JSC::ExecState::clearReturnPC): + (JSC::ExecState::bytecodeOffsetForNonDFGCode): + (JSC::ExecState::setBytecodeOffsetForNonDFGCode): + (JSC::ExecState::inlineCallFrame): + (JSC::ExecState::codeOriginIndexForDFG): + (JSC::ExecState::currentVPC): + (JSC::ExecState::setCurrentVPC): + (JSC::ExecState::setCallerFrame): + (JSC::ExecState::setScope): + (JSC::ExecState::init): + (JSC::ExecState::argumentCountIncludingThis): + (JSC::ExecState::offsetFor): + (JSC::ExecState::setArgumentCountIncludingThis): + (JSC::ExecState::setCallee): + (JSC::ExecState::setCodeBlock): + (JSC::ExecState::setReturnPC): + (JSC::ExecState::setInlineCallFrame): + (ExecState): + * interpreter/Interpreter.cpp: + (JSC::Interpreter::slideRegisterWindowForCall): + (JSC::eval): + (JSC::loadVarargs): + (JSC::Interpreter::dumpRegisters): + (JSC::Interpreter::throwException): + (JSC::Interpreter::execute): + (JSC::Interpreter::executeCall): + (JSC::Interpreter::executeConstruct): + (JSC::Interpreter::prepareForRepeatCall): + (JSC::Interpreter::endRepeatCall): + * interpreter/Interpreter.h: + (JSC::Interpreter::stack): + (Interpreter): + (JSC::Interpreter::execute): + (JSC): + * interpreter/JSStack.cpp: Copied from Source/JavaScriptCore/interpreter/RegisterFile.cpp. + (JSC::stackStatisticsMutex): + (JSC::JSStack::~JSStack): + (JSC::JSStack::growSlowCase): + (JSC::JSStack::gatherConservativeRoots): + (JSC::JSStack::releaseExcessCapacity): + (JSC::JSStack::initializeThreading): + (JSC::JSStack::committedByteCount): + (JSC::JSStack::addToCommittedByteCount): + * interpreter/JSStack.h: Copied from Source/JavaScriptCore/interpreter/RegisterFile.h. + (JSStack): + (JSC::JSStack::JSStack): + (JSC::JSStack::shrink): + (JSC::JSStack::grow): + * interpreter/RegisterFile.cpp: Removed. + * interpreter/RegisterFile.h: Removed. + * interpreter/VMInspector.cpp: + (JSC::VMInspector::dumpFrame): + * jit/JIT.cpp: + (JSC::JIT::JIT): + (JSC::JIT::privateCompile): + * jit/JIT.h: + (JSC): + (JIT): + * jit/JITCall.cpp: + (JSC::JIT::compileLoadVarargs): + (JSC::JIT::compileCallEval): + (JSC::JIT::compileCallEvalSlowCase): + (JSC::JIT::compileOpCall): + * jit/JITCall32_64.cpp: + (JSC::JIT::emit_op_ret): + (JSC::JIT::emit_op_ret_object_or_this): + (JSC::JIT::compileLoadVarargs): + (JSC::JIT::compileCallEval): + (JSC::JIT::compileCallEvalSlowCase): + (JSC::JIT::compileOpCall): + * jit/JITCode.h: + (JSC): + (JSC::JITCode::execute): + * jit/JITInlineMethods.h: + (JSC::JIT::emitPutToCallFrameHeader): + (JSC::JIT::emitPutCellToCallFrameHeader): + (JSC::JIT::emitPutIntToCallFrameHeader): + (JSC::JIT::emitPutImmediateToCallFrameHeader): + (JSC::JIT::emitGetFromCallFrameHeaderPtr): + (JSC::JIT::emitGetFromCallFrameHeader32): + (JSC::JIT::updateTopCallFrame): + (JSC::JIT::unmap): + * jit/JITOpcodes.cpp: + (JSC::JIT::privateCompileCTIMachineTrampolines): + (JSC::JIT::privateCompileCTINativeCall): + (JSC::JIT::emit_op_end): + (JSC::JIT::emit_op_ret): + (JSC::JIT::emit_op_ret_object_or_this): + (JSC::JIT::emit_op_create_this): + (JSC::JIT::emit_op_get_arguments_length): + (JSC::JIT::emit_op_get_argument_by_val): + (JSC::JIT::emit_op_resolve_global_dynamic): + * jit/JITOpcodes32_64.cpp: + (JSC::JIT::privateCompileCTIMachineTrampolines): + (JSC::JIT::privateCompileCTINativeCall): + (JSC::JIT::emit_op_end): + (JSC::JIT::emit_op_create_this): + (JSC::JIT::emit_op_get_arguments_length): + (JSC::JIT::emit_op_get_argument_by_val): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::emit_op_get_scoped_var): + (JSC::JIT::emit_op_put_scoped_var): + * jit/JITPropertyAccess32_64.cpp: + (JSC::JIT::emit_op_get_scoped_var): + (JSC::JIT::emit_op_put_scoped_var): + * jit/JITStubs.cpp: + (JSC::ctiTrampoline): + (JSC::JITThunks::JITThunks): + (JSC): + (JSC::DEFINE_STUB_FUNCTION): + * jit/JITStubs.h: + (JSC): + (JITStackFrame): + * jit/JSInterfaceJIT.h: + * jit/SpecializedThunkJIT.h: + (JSC::SpecializedThunkJIT::SpecializedThunkJIT): + (JSC::SpecializedThunkJIT::returnJSValue): + (JSC::SpecializedThunkJIT::returnDouble): + (JSC::SpecializedThunkJIT::returnInt32): + (JSC::SpecializedThunkJIT::returnJSCell): + * llint/LLIntData.cpp: + (JSC::LLInt::Data::performAssertions): + * llint/LLIntOffsetsExtractor.cpp: + * llint/LLIntSlowPaths.cpp: + (JSC::LLInt::LLINT_SLOW_PATH_DECL): + (JSC::LLInt::genericCall): + * llint/LLIntSlowPaths.h: + (LLInt): + * llint/LowLevelInterpreter.asm: + * runtime/Arguments.cpp: + (JSC::Arguments::tearOffForInlineCallFrame): + * runtime/CommonSlowPaths.h: + (JSC::CommonSlowPaths::arityCheckFor): + * runtime/InitializeThreading.cpp: + (JSC::initializeThreadingOnce): + * runtime/JSActivation.cpp: + (JSC::JSActivation::visitChildren): + * runtime/JSGlobalObject.cpp: + (JSC::JSGlobalObject::globalExec): + * runtime/JSGlobalObject.h: + (JSC): + (JSGlobalObject): + * runtime/JSLock.cpp: + (JSC): + * runtime/JSVariableObject.h: + (JSVariableObject): + * runtime/MemoryStatistics.cpp: + (JSC::globalMemoryStatistics): + +2012-10-08 Kiran Muppala <cmuppala@apple.com> + + Throttle DOM timers on hidden pages. + https://bugs.webkit.org/show_bug.cgi?id=98474 + + Reviewed by Maciej Stachowiak. + + Add HIDDEN_PAGE_DOM_TIMER_THROTTLING feature define. + + * Configurations/FeatureDefines.xcconfig: + +2012-10-08 Michael Saboff <msaboff@apple.com> + + After r130344, OpaqueJSString() creates an empty string which should be a null string + https://bugs.webkit.org/show_bug.cgi?id=98417 + + Reviewed by Sam Weinig. + + Changed create() of a null string to return 0. This is the same behavior as before r130344. + + * API/OpaqueJSString.cpp: + (OpaqueJSString::create): + +2012-10-07 Caio Marcelo de Oliveira Filho <caio.oliveira@openbossa.org> + + Rename first/second to key/value in HashMap iterators + https://bugs.webkit.org/show_bug.cgi?id=82784 + + Reviewed by Eric Seidel. + + * API/JSCallbackObject.h: + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::getPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::setPrivateProperty): + (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren): + * API/JSCallbackObjectFunctions.h: + (JSC::::getOwnNonIndexPropertyNames): + * API/JSClassRef.cpp: + (OpaqueJSClass::~OpaqueJSClass): + (OpaqueJSClassContextData::OpaqueJSClassContextData): + (OpaqueJSClass::contextData): + * bytecode/CodeBlock.cpp: + (JSC::CodeBlock::dump): + (JSC::EvalCodeCache::visitAggregate): + (JSC::CodeBlock::nameForRegister): + * bytecode/JumpTable.h: + (JSC::StringJumpTable::offsetForValue): + (JSC::StringJumpTable::ctiForValue): + * bytecode/LazyOperandValueProfile.cpp: + (JSC::LazyOperandValueProfileParser::getIfPresent): + * bytecode/SamplingTool.cpp: + (JSC::SamplingTool::dump): + * bytecompiler/BytecodeGenerator.cpp: + (JSC::BytecodeGenerator::addVar): + (JSC::BytecodeGenerator::addGlobalVar): + (JSC::BytecodeGenerator::addConstant): + (JSC::BytecodeGenerator::addConstantValue): + (JSC::BytecodeGenerator::emitLoad): + (JSC::BytecodeGenerator::addStringConstant): + (JSC::BytecodeGenerator::emitLazyNewFunction): + * bytecompiler/NodesCodegen.cpp: + (JSC::PropertyListNode::emitBytecode): + * debugger/Debugger.cpp: + * dfg/DFGArgumentsSimplificationPhase.cpp: + (JSC::DFG::ArgumentsSimplificationPhase::run): + (JSC::DFG::ArgumentsSimplificationPhase::observeBadArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::observeProperArgumentsUse): + (JSC::DFG::ArgumentsSimplificationPhase::isOKToOptimize): + (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild): + * dfg/DFGAssemblyHelpers.cpp: + (JSC::DFG::AssemblyHelpers::decodedCodeMapFor): + * dfg/DFGByteCodeCache.h: + (JSC::DFG::ByteCodeCache::~ByteCodeCache): + (JSC::DFG::ByteCodeCache::get): + * dfg/DFGByteCodeParser.cpp: + (JSC::DFG::ByteCodeParser::cellConstant): + (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): + * dfg/DFGStructureCheckHoistingPhase.cpp: + (JSC::DFG::StructureCheckHoistingPhase::run): + (JSC::DFG::StructureCheckHoistingPhase::noticeStructureCheck): + (JSC::DFG::StructureCheckHoistingPhase::noticeClobber): + * heap/Heap.cpp: + (JSC::Heap::markProtectedObjects): + * heap/Heap.h: + (JSC::Heap::forEachProtectedCell): + * heap/JITStubRoutineSet.cpp: + (JSC::JITStubRoutineSet::markSlow): + (JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines): + * heap/SlotVisitor.cpp: + (JSC::SlotVisitor::internalAppend): + * heap/Weak.h: + (JSC::weakRemove): + * jit/JIT.cpp: + (JSC::JIT::privateCompile): + * jit/JITStubs.cpp: + (JSC::JITThunks::ctiStub): + * parser/Parser.cpp: + (JSC::::parseStrictObjectLiteral): + * profiler/Profile.cpp: + (JSC::functionNameCountPairComparator): + (JSC::Profile::debugPrintDataSampleStyle): + * runtime/Identifier.cpp: + (JSC::Identifier::add): + * runtime/JSActivation.cpp: + (JSC::JSActivation::getOwnNonIndexPropertyNames): + (JSC::JSActivation::symbolTablePutWithAttributes): + * runtime/JSArray.cpp: + (JSC::JSArray::setLength): + * runtime/JSObject.cpp: + (JSC::JSObject::getOwnPropertySlotByIndex): + (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): + (JSC::JSObject::deletePropertyByIndex): + (JSC::JSObject::getOwnPropertyNames): + (JSC::JSObject::defineOwnIndexedProperty): + (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype): + (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage): + (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage): + (JSC::JSObject::getOwnPropertyDescriptor): + * runtime/JSSymbolTableObject.cpp: + (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames): + * runtime/JSSymbolTableObject.h: + (JSC::symbolTableGet): + (JSC::symbolTablePut): + (JSC::symbolTablePutWithAttributes): + * runtime/RegExpCache.cpp: + (JSC::RegExpCache::invalidateCode): + * runtime/SparseArrayValueMap.cpp: + (JSC::SparseArrayValueMap::putEntry): + (JSC::SparseArrayValueMap::putDirect): + (JSC::SparseArrayValueMap::visitChildren): + * runtime/WeakGCMap.h: + (JSC::WeakGCMap::clear): + (JSC::WeakGCMap::set): + * tools/ProfileTreeNode.h: + (JSC::ProfileTreeNode::sampleChild): + (JSC::ProfileTreeNode::childCount): + (JSC::ProfileTreeNode::dumpInternal): + (JSC::ProfileTreeNode::compareEntries): + +2012-10-05 Mark Hahnenberg <mhahnenberg@apple.com> + + JSC should have a way to gather and log Heap memory use and pause times + https://bugs.webkit.org/show_bug.cgi?id=98431 + + Reviewed by Geoffrey Garen. + + In order to improve our infrastructure for benchmark-driven development, we should + have a centralized method of gathering and logging various statistics about the state + of the JS heap. This would allow us to create and to use other tools to analyze the + output of the VM after running various workloads. + + The first two statistics that might be interesting is memory use by JSC and GC pause + times. We can control whether this recording happens through the use of the Options + class, allowing us to either use environment variables or command line flags. + + * JavaScriptCore.xcodeproj/project.pbxproj: + * heap/Heap.cpp: + (JSC::Heap::collect): If we finish a collection and are still over our set GC heap size, + we end the program immediately and report an error. Also added recording of pause times. + * heap/Heap.h: + (Heap): + (JSC::Heap::shouldCollect): When we set a specific GC heap size through Options, we + ignore all other heuristics on when we should collect and instead only ask if we're + greater than the amount specified in the Option value. This allows us to view time/memory + tradeoffs more clearly. + * heap/HeapStatistics.cpp: Added. + (JSC): + (JSC::HeapStatistics::initialize): + (JSC::HeapStatistics::recordGCPauseTime): + (JSC::HeapStatistics::logStatistics): + (JSC::HeapStatistics::exitWithFailure): + (JSC::HeapStatistics::reportSuccess): + (JSC::HeapStatistics::parseMemoryAmount): + (StorageStatistics): + (JSC::StorageStatistics::StorageStatistics): + (JSC::StorageStatistics::operator()): + (JSC::StorageStatistics::objectWithOutOfLineStorageCount): + (JSC::StorageStatistics::objectCount): + (JSC::StorageStatistics::storageSize): + (JSC::StorageStatistics::storageCapacity): + (JSC::HeapStatistics::showObjectStatistics): Moved the old showHeapStatistics (renamed to showObjectStatistics) + to try to start collecting our various memory statistics gathering/reporting mechanisms scattered throughout the + codebase into one place. + * heap/HeapStatistics.h: Added. + (JSC): + (HeapStatistics): + * jsc.cpp: + (main): + * runtime/InitializeThreading.cpp: + (JSC::initializeThreadingOnce): We need to initialize our data structures for recording + statistics if necessary. + * runtime/Options.cpp: Add new Options for the various types of statistics we'll be gathering. + (JSC::parse): + (JSC): + (JSC::Options::initialize): Initialize the various new options using environment variables. + (JSC::Options::dumpOption): + * runtime/Options.h: + (JSC): + +2012-10-04 Rik Cabanier <cabanier@adobe.com> + + Turn Compositing on by default in WebKit build + https://bugs.webkit.org/show_bug.cgi?id=98315 + + Reviewed by Simon Fraser. + + enable -webkit-blend-mode on trunk. + + * Configurations/FeatureDefines.xcconfig: + +2012-10-04 Michael Saboff <msaboff@apple.com> + + Crash in Safari at com.apple.JavaScriptCore: WTF::StringImpl::is8Bit const + 12 + https://bugs.webkit.org/show_bug.cgi?id=98433 + + Reviewed by Jessie Berlin. + + The problem is due to a String with a null StringImpl (i.e. a null string). + Added a length check before the is8Bit() check since length() checks for a null StringImpl. Changed the + characters16() call to characters() since it can handle a null StringImpl as well. + + * API/JSValueRef.cpp: + (JSValueMakeFromJSONString): + +2012-10-04 Benjamin Poulain <bpoulain@apple.com> + + Use copyLCharsFromUCharSource() for IdentifierLCharFromUCharTranslator translation + https://bugs.webkit.org/show_bug.cgi?id=98335 + + Reviewed by Michael Saboff. + + Michael Saboff added an optimized version of UChar->LChar conversion in r125846. + Use this function in JSC::Identifier. + + * runtime/Identifier.cpp: + (JSC::IdentifierLCharFromUCharTranslator::translate): + +2012-10-04 Michael Saboff <msaboff@apple.com> + + After r130344, OpaqueJSString() creates a empty string which should be a null string + https://bugs.webkit.org/show_bug.cgi?id=98417 + + Reviewed by Alexey Proskuryakov. + + Removed the setting of enclosed string to an empty string from default constructor. + Before changeset r130344, the semantic was the default constructor produced a null + string. + + * API/OpaqueJSString.h: + (OpaqueJSString::OpaqueJSString): + +2012-10-04 Csaba Osztrogonác <ossy@webkit.org> + + [Qt] Add missing LLInt dependencies to the build system + https://bugs.webkit.org/show_bug.cgi?id=98394 + + Reviewed by Geoffrey Garen. + + * DerivedSources.pri: + * LLIntOffsetsExtractor.pro: + +2012-10-03 Geoffrey Garen <ggaren@apple.com> + + Next step toward fixing Windows: add new symbol. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-10-03 Geoffrey Garen <ggaren@apple.com> + + First step toward fixing Windows: remove old symbol. + + * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def: + +2012-10-03 Geoffrey Garen <ggaren@apple.com> + + Removed the assumption that "final" objects have a fixed number of inline slots + https://bugs.webkit.org/show_bug.cgi?id=98332 + + Reviewed by Filip Pizlo. + + This is a step toward object size inference. + + I replaced the inline storage capacity constant with a data member per + structure, set the the maximum supported value for the constant to 100, + then fixed what broke. (Note that even though this patch increases the + theoretical maximum inline capacity, it doesn't change any actual inline + capacity.) + + * dfg/DFGSpeculativeJIT32_64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * dfg/DFGSpeculativeJIT64.cpp: + (JSC::DFG::SpeculativeJIT::compile): + * jit/JITPropertyAccess.cpp: + (JSC::JIT::compileGetDirectOffset): These functions just get a rename: + the constant they need is the first out of line offset along the offset + number line, which is not necessarily the same thing (and is, in this + patch, never the same thing) as the inline capacity of any given object. + + (JSC::JIT::emit_op_get_by_pname): + * jit/JITPropertyAccess32_64.cpp: This function changes functionality, + since it needs to convert from the abstract offset number line to an + actual offset in memory, and it can't assume that inline and out-of-line + offsets are contiguous on the number line. + + (JSC::JIT::compileGetDirectOffset): Updated for rename. + + (JSC::JIT::emit_op_get_by_pname): Same as emit_op_get_by_pname above. + + * llint/LowLevelInterpreter.asm: Updated to mirror changes in PropertyOffset.h, + since we duplicate values from there. + + * llint/LowLevelInterpreter32_64.asm: + * llint/LowLevelInterpreter64.asm: Just like the JIT, most things are just + renames, and get_by_pname changes to do more math. I also standardized + offset calculations to use a hard-coded "-2", to match the JIT. This + isn't really better, but it makes global search and replace easier, + should we choose to refactor this code not to hard-code constants. + + I also renamed loadPropertyAtVariableOffsetKnownNotFinal to + loadPropertyAtVariableOffsetKnownNotInline in order to sever the assumption + that inline capacity is tied to object type, and I changed the 64bit LLInt + to use this -- not using this previously seems to have been an oversight. + + * runtime/JSObject.cpp: + (JSC::JSObject::visitChildren): + (JSC::JSFinalObject::visitChildren): + * runtime/JSObject.h: + (JSC::JSObject::offsetForLocation): + (JSNonFinalObject): + (JSC::JSFinalObject::createStructure): + (JSFinalObject): + (JSC::JSFinalObject::finishCreation): Updated for above changes. + + * runtime/JSPropertyNameIterator.h: + (JSPropertyNameIterator): + (JSC::JSPropertyNameIterator::finishCreation): Store the inline capacity + of our object, since it's not a constant. + + (JSC::JSPropertyNameIterator::getOffset): Removed. This function was + wrong. Luckily, it was also unused, since the C++ interpreter is gone. + + * runtime/PropertyMapHashTable.h: + (PropertyTable): Use a helper function instead of hard-coding assumptions + about object types. + + (JSC::PropertyTable::nextOffset): + * runtime/PropertyOffset.h: + (JSC): + (JSC::checkOffset): + (JSC::validateOffset): + (JSC::isInlineOffset): + (JSC::numberOfSlotsForLastOffset): + (JSC::propertyOffsetFor): Refactored these functions to take inline capacity + as an argument, since it's not fixed at compile time anymore. + + * runtime/Structure.cpp: + (JSC::Structure::Structure): + (JSC::Structure::flattenDictionaryStructure): + (JSC::Structure::putSpecificValue): + * runtime/Structure.h: + (Structure): + (JSC::Structure::outOfLineCapacity): + (JSC::Structure::hasInlineStorage): + (JSC::Structure::inlineCapacity): + (JSC::Structure::inlineSize): + (JSC::Structure::firstValidOffset): + (JSC::Structure::lastValidOffset): + (JSC::Structure::create): Removed some hard-coded assumptions about inline + capacity and object type, and replaced with more liberal use of helper functions. + +2012-10-03 Michael Saboff <msaboff@apple.com> + + OpaqueJSString doesn't optimally handle 8 bit strings + https://bugs.webkit.org/show_bug.cgi?id=98300 + + Reviewed by Geoffrey Garen. + + Change OpaqueJSString to store and manage a String instead of a UChar buffer. + The member string is a copy of any string used during creation. + + * API/OpaqueJSString.cpp: + (OpaqueJSString::create): + (OpaqueJSString::identifier): + * API/OpaqueJSString.h: + (OpaqueJSString::characters): + (OpaqueJSString::length): + (OpaqueJSString::string): + (OpaqueJSString::OpaqueJSString): + (OpaqueJSString): + +2012-10-03 Filip Pizlo <fpizlo@apple.com> + + Array.splice should be fast when it is used to remove elements other than the very first + https://bugs.webkit.org/show_bug.cgi?id=98236 + + Reviewed by Michael Saboff. + + Applied the same technique that was used to optimize the unshift case of splice in + http://trac.webkit.org/changeset/129676. This is a >20x speed-up on programs that + use splice for element removal. + + * runtime/ArrayPrototype.cpp: + (JSC::shift): + * runtime/JSArray.cpp: + (JSC::JSArray::shiftCount): + * runtime/JSArray.h: + (JSArray): + +2012-09-16 Mark Hahnenberg <mhahnenberg@apple.com> + + Delayed structure sweep can leak structures without bound + https://bugs.webkit.org/show_bug.cgi?id=96546 + + Reviewed by Geoffrey Garen. + + This patch gets rid of the separate Structure allocator in the MarkedSpace and adds two new destructor-only + allocators. We now have separate allocators for our three types of objects: those objects with no destructors, + those objects with destructors and with immortal structures, and those objects with destructors that don't have + immortal structures. All of the objects of the third type (destructors without immortal structures) now + inherit from a new class named JSDestructibleObject (which in turn is a subclass of JSNonFinalObject), which stores + the ClassInfo for these classes at a fixed offset for safe retrieval during sweeping/destruction. + + * API/JSCallbackConstructor.cpp: Use JSDestructibleObject for JSCallbackConstructor. + (JSC): + (JSC::JSCallbackConstructor::JSCallbackConstructor): + * API/JSCallbackConstructor.h: + (JSCallbackConstructor): + * API/JSCallbackObject.cpp: Inherit from JSDestructibleObject for normal JSCallbackObjects and use a finalizer for + JSCallbackObject<JSGlobalObject>, since JSGlobalObject also uses a finalizer. + (JSC): + (JSC::::create): We need to move the create function for JSCallbackObject<JSGlobalObject> out of line so we can add + the finalizer for it. We don't want to add the finalizer is something like finishCreation in case somebody decides + to subclass this. We use this same technique for many other subclasses of JSGlobalObject. + (JSC::::createStructure): + * API/JSCallbackObject.h: + (JSCallbackObject): + (JSC): + * API/JSClassRef.cpp: Change all the JSCallbackObject<JSNonFinalObject> to use JSDestructibleObject instead. + (OpaqueJSClass::prototype): + * API/JSObjectRef.cpp: Ditto. + (JSObjectMake): + (JSObjectGetPrivate): + (JSObjectSetPrivate): + (JSObjectGetPrivateProperty): + (JSObjectSetPrivateProperty): + (JSObjectDeletePrivateProperty): + * API/JSValueRef.cpp: Ditto. + (JSValueIsObjectOfClass): + * API/JSWeakObjectMapRefPrivate.cpp: Ditto. + * JSCTypedArrayStubs.h: + (JSC): + * JavaScriptCore.xcodeproj/project.pbxproj: + * dfg/DFGSpeculativeJIT.h: Use the proper allocator type when doing inline allocation in the DFG. + (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): + (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject): + * heap/Heap.cpp: + (JSC): + * heap/Heap.h: Add accessors for the various types of allocators now. Also remove the isSafeToSweepStructures function + since it's always safe to sweep Structures now. + (JSC::Heap::allocatorForObjectWithNormalDestructor): + (JSC::Heap::allocatorForObjectWithImmortalStructureDestructor): + (Heap): + (JSC::Heap::allocateWithNormalDestructor): + (JSC): + (JSC::Heap::allocateWithImmortalStructureDestructor): + * heap/IncrementalSweeper.cpp: Remove all the logic to detect when it's safe to sweep Structures from the + IncrementalSweeper since it's always safe to sweep Structures now. + (JSC::IncrementalSweeper::IncrementalSweeper): + (JSC::IncrementalSweeper::sweepNextBlock): + (JSC::IncrementalSweeper::startSweeping): + (JSC::IncrementalSweeper::willFinishSweeping): + (JSC): + * heap/IncrementalSweeper.h: + (IncrementalSweeper): + * heap/MarkedAllocator.cpp: Remove the logic that was preventing us from sweeping Structures if it wasn't safe. Add + tracking of the specific destructor type of allocator. + (JSC::MarkedAllocator::tryAllocateHelper): + (JSC::MarkedAllocator::allocateBlock): + * heap/MarkedAllocator.h: + (JSC::MarkedAllocator::destructorType): + (MarkedAllocator): + (JSC::MarkedAllocator::MarkedAllocator): + (JSC::MarkedAllocator::init): + * heap/MarkedBlock.cpp: Add all the destructor type stuff to MarkedBlocks so that we do the right thing when sweeping. + We also use the stored destructor type to determine the right thing to do in all JSCell::classInfo() calls. + (JSC::MarkedBlock::create): + (JSC::MarkedBlock::MarkedBlock): + (JSC): + (JSC::MarkedBlock::specializedSweep): + (JSC::MarkedBlock::sweep): + (JSC::MarkedBlock::sweepHelper): + * heap/MarkedBlock.h: + (JSC): + (JSC::MarkedBlock::allocator): + (JSC::MarkedBlock::destructorType): + * heap/MarkedSpace.cpp: Add the new destructor allocators to MarkedSpace. + (JSC::MarkedSpace::MarkedSpace): + (JSC::MarkedSpace::resetAllocators): + (JSC::MarkedSpace::canonicalizeCellLivenessData): + (JSC::MarkedSpace::isPagedOut): + (JSC::MarkedSpace::freeBlock): + * heap/MarkedSpace.h: + (MarkedSpace): + (JSC::MarkedSpace::immortalStructureDestructorAllocatorFor): + (JSC::MarkedSpace::normalDestructorAllocatorFor): + (JSC::MarkedSpace::allocateWithImmortalStructureDestructor): + (JSC::MarkedSpace::allocateWithNormalDestructor): + (JSC::MarkedSpace::forEachBlock): + * heap/SlotVisitor.cpp: Add include because the symbol was needed in an inlined function. + * jit/JIT.h: Make sure we use the correct allocator when doing inline allocations in the baseline JIT. + * jit/JITInlineMethods.h: + (JSC::JIT::emitAllocateBasicJSObject): + (JSC::JIT::emitAllocateJSFinalObject): + (JSC::JIT::emitAllocateJSArray): + * jsc.cpp: + (GlobalObject::create): Add finalizer here since JSGlobalObject needs to use a finalizer instead of inheriting from + JSDestructibleObject. + * runtime/Arguments.cpp: Inherit from JSDestructibleObject. + (JSC): + * runtime/Arguments.h: + (Arguments): + (JSC::Arguments::Arguments): + * runtime/ErrorPrototype.cpp: Added an assert to make sure we have a trivial destructor. + (JSC): + * runtime/Executable.h: Indicate that all of the Executable* classes have immortal Structures. + (JSC): + * runtime/InternalFunction.cpp: Inherit from JSDestructibleObject. + (JSC): + (JSC::InternalFunction::InternalFunction): + * runtime/InternalFunction.h: + (InternalFunction): + * runtime/JSCell.h: Added two static bools, needsDestruction and hasImmortalStructure, that classes can override + to indicate at compile time which part of the heap they should be allocated in. + (JSC::allocateCell): Use the appropriate allocator depending on the destructor type. + * runtime/JSDestructibleObject.h: Added. New class that stores the ClassInfo of any subclass so that it can be + accessed safely when the object is being destroyed. + (JSC): + (JSDestructibleObject): + (JSC::JSDestructibleObject::classInfo): + (JSC::JSDestructibleObject::JSDestructibleObject): + (JSC::JSCell::classInfo): Checks the current MarkedBlock to see where it should get the ClassInfo from so that it's always safe. + * runtime/JSGlobalObject.cpp: JSGlobalObject now uses a finalizer instead of a destructor so that it can avoid forcing all + of its relatives in the inheritance hierarchy (e.g. JSScope) to use destructors as well. + (JSC::JSGlobalObject::reset): + * runtime/JSGlobalObject.h: + (JSGlobalObject): + (JSC::JSGlobalObject::createRareDataIfNeeded): Since we always create a finalizer now, we don't have to worry about adding one + for the m_rareData field when it's created. + (JSC::JSGlobalObject::create): + (JSC): + * runtime/JSGlobalThis.h: Inherit from JSDestructibleObject. + (JSGlobalThis): + (JSC::JSGlobalThis::JSGlobalThis): + * runtime/JSPropertyNameIterator.h: Has an immortal Structure. + (JSC): + * runtime/JSScope.cpp: + (JSC): + * runtime/JSString.h: Has an immortal Structure. + (JSC): + * runtime/JSWrapperObject.h: Inherit from JSDestructibleObject. + (JSWrapperObject): + (JSC::JSWrapperObject::JSWrapperObject): + * runtime/MathObject.cpp: Cleaning up some of the inheritance stuff. + (JSC): + * runtime/NameInstance.h: Inherit from JSDestructibleObject. + (NameInstance): + * runtime/RegExp.h: Has immortal Structure. + (JSC): + * runtime/RegExpObject.cpp: Inheritance cleanup. + (JSC): + * runtime/SparseArrayValueMap.h: Has immortal Structure. + (JSC): + * runtime/Structure.h: Has immortal Structure. + (JSC): + * runtime/StructureChain.h: Ditto. + (JSC): + * runtime/SymbolTable.h: Ditto. + (SharedSymbolTable): + (JSC): + +== Rolled over to ChangeLog-2012-10-02 == |