diff options
Diffstat (limited to 'Source/JavaScriptCore/ChangeLog')
| -rw-r--r-- | Source/JavaScriptCore/ChangeLog | 859 |
1 files changed, 784 insertions, 75 deletions
diff --git a/Source/JavaScriptCore/ChangeLog b/Source/JavaScriptCore/ChangeLog index 3574aa0d8..c6b5ce758 100644 --- a/Source/JavaScriptCore/ChangeLog +++ b/Source/JavaScriptCore/ChangeLog @@ -1,63 +1,631 @@ -2012-10-17 Zoltan Horvath <zoltan@webkit.org> +2012-10-20 Martin Robinson <mrobinson@igalia.com> - Remove the JSHeap memory measurement of the PageLoad performacetests since it creates bogus JSGlobalDatas - https://bugs.webkit.org/show_bug.cgi?id=99609 + Fix 'make dist' for the GTK+ port - Reviewed by Ryosuke Niwa. + * GNUmakefile.list.am: Add missing files to the source list. - Remove the implementation since it creates bogus JSGlobalDatas in the layout tests. +2012-10-21 Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com> - * heap/HeapStatistics.cpp: + [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): - * heap/HeapStatistics.h: - (HeapStatistics): + * 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-17 Sam Weinig <sam@webkit.org> +2012-10-19 Filip Pizlo <fpizlo@apple.com> - Attempt to fix the build. + Baseline JIT should not inline array allocations, to make them easier to instrument + https://bugs.webkit.org/show_bug.cgi?id=99905 - * bytecode/GlobalResolveInfo.h: Copied from bytecode/GlobalResolveInfo.h. + Reviewed by Mark Hahnenberg. -2012-10-17 Oliver Hunt <oliver@apple.com> + 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. - Roll out r131645 as it causes random site crashes. + * 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_reference_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): - (JSC::isGlobalResolve): - (JSC::instructionOffsetForNth): - (JSC::printGlobalResolveInfo): (JSC::CodeBlock::printStructures): (JSC::CodeBlock::dump): (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::visitStructures): + (JSC): (JSC::CodeBlock::finalizeUnconditionally): - (JSC::CodeBlock::hasGlobalResolveInfoAtBytecodeOffset): - (JSC::CodeBlock::globalResolveInfoForBytecodeOffset): (JSC::CodeBlock::shrinkToFit): * bytecode/CodeBlock.h: + (JSC::CodeBlock::addResolve): + (JSC::CodeBlock::addPutToBase): (CodeBlock): - (JSC::CodeBlock::addGlobalResolveInstruction): - (JSC::CodeBlock::addGlobalResolveInfo): - (JSC::CodeBlock::globalResolveInfo): - (JSC::CodeBlock::numberOfGlobalResolveInfos): - (JSC::CodeBlock::globalResolveInfoCount): + (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): (JSC::computeForStructure): - (JSC::computeForLLInt): (JSC::ResolveGlobalStatus::computeFor): * bytecode/ResolveGlobalStatus.h: (JSC): (ResolveGlobalStatus): * bytecompiler/BytecodeGenerator.cpp: (JSC::ResolveResult::checkValidity): - (JSC::ResolveResult::registerPointer): (JSC): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::resolve): @@ -66,30 +634,29 @@ (JSC::BytecodeGenerator::emitResolve): (JSC::BytecodeGenerator::emitResolveBase): (JSC::BytecodeGenerator::emitResolveBaseForPut): - (JSC::BytecodeGenerator::emitResolveWithBase): + (JSC::BytecodeGenerator::emitResolveWithBaseForPut): (JSC::BytecodeGenerator::emitResolveWithThis): - (JSC::BytecodeGenerator::emitGetStaticVar): + (JSC::BytecodeGenerator::emitGetLocalVar): (JSC::BytecodeGenerator::emitInitGlobalConst): - (JSC::BytecodeGenerator::emitPutStaticVar): + (JSC::BytecodeGenerator::emitPutToBase): * 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): + (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): @@ -105,18 +672,25 @@ (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: @@ -130,7 +704,6 @@ (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: - (JSC): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGRepatch.cpp: @@ -138,6 +711,9 @@ * 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): @@ -150,43 +726,31 @@ (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: (JIT): - (JSC::JIT::emit_op_get_global_var_watchable): * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_resolve): + (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::emit_op_resolve_skip): - (JSC::JIT::emit_op_resolve_global): - (JSC::JIT::emitSlow_op_resolve_global): + (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::emit_op_resolve_global_dynamic): - (JSC::JIT::emitSlow_op_resolve_global_dynamic): + (JSC::JIT::emitSlow_op_resolve_with_this): + (JSC::JIT::emitSlow_op_put_to_base): * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_resolve): + (JSC::JIT::emit_op_put_to_base): (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): + (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_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): + (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): @@ -200,18 +764,163 @@ * 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::resolveSkip): - (JSC::JSScope::resolveGlobal): - (JSC::JSScope::resolveGlobalDynamic): (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> |