GitLab

https://bugs.webkit.org/show_bug.cgi?id=116350

Reviewed by Oliver Hunt.

This refactors compilation so that:

- JITStubs knows exactly what the result of compilation was. For example, if
  compilation was deferred, it will now know this.

- The set of things that has to happen to install compiled code is now factored
  out into JSC::installOptimizedCode().

- A bunch of the code in Executable.cpp is now made more common to reduce code
  duplication. For example, the heap heuristics stuff is now in one place.

* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::ProgramCodeBlock::compileOptimized):
(JSC::ProgramCodeBlock::replaceWithDeferredOptimizedCode):
(JSC):
(JSC::EvalCodeBlock::compileOptimized):
(JSC::EvalCodeBlock::replaceWithDeferredOptimizedCode):
(JSC::FunctionCodeBlock::compileOptimized):
(JSC::FunctionCodeBlock::replaceWithDeferredOptimizedCode):
(JSC::ProgramCodeBlock::jitCompileImpl):
(JSC::EvalCodeBlock::jitCompileImpl):
(JSC::FunctionCodeBlock::jitCompileImpl):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::jitCompile):
(ProgramCodeBlock):
(EvalCodeBlock):
(FunctionCodeBlock):
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::numberOfIdentifiers):
(DFG):
(JSC::DFG::DesiredIdentifiers::at):
* dfg/DFGDesiredIdentifiers.h:
(JSC):
(DesiredIdentifiers):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
(JSC::DFG::tryFinalizePlan):
(DFG):
* dfg/DFGDriver.h:
(DFG):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
(JSC::DFG::tryFinalizePlan):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
* dfg/DFGJITFinalizer.cpp:
(JSC::DFG::JITFinalizer::finalizeCommon):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::reallyAdd):
* dfg/DFGPlan.h:
(JSC):
(Plan):
(DFG):
* ftl/FTLJITFinalizer.cpp:
(JSC::FTL::JITFinalizer::finalizeFunction):
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriateImpl):
(JSC::jitCompileFunctionIfAppropriateImpl):
(JSC):
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
* runtime/CompilationResult.cpp: Added.
(WTF):
(WTF::printInternal):
* runtime/CompilationResult.h: Added.
(JSC):
(WTF):
* runtime/Executable.cpp:
(JSC::EvalExecutable::compileOptimized):
(JSC::EvalExecutable::jitCompile):
(JSC::EvalExecutable::compileInternal):
(JSC::EvalExecutable::replaceWithDeferredOptimizedCode):
(JSC):
(JSC::ProgramExecutable::compileOptimized):
(JSC::ProgramExecutable::jitCompile):
(JSC::ProgramExecutable::compileInternal):
(JSC::ProgramExecutable::replaceWithDeferredOptimizedCode):
(JSC::FunctionExecutable::compileOptimizedForCall):
(JSC::FunctionExecutable::compileOptimizedForConstruct):
(JSC::FunctionExecutable::jitCompileForCall):
(JSC::FunctionExecutable::jitCompileForConstruct):
(JSC::FunctionExecutable::compileForCallInternal):
(JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeForCall):
(JSC::FunctionExecutable::compileForConstructInternal):
(JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeForConstruct):
* runtime/Executable.h:
(ScriptExecutable):
(EvalExecutable):
(ProgramExecutable):
(FunctionExecutable):
(JSC::FunctionExecutable::compileOptimizedFor):
(JSC::FunctionExecutable::replaceWithDeferredOptimizedCodeFor):
(JSC::FunctionExecutable::jitCompileFor):
* runtime/ExecutionHarness.h:
(JSC::prepareForExecutionImpl):
(JSC::prepareFunctionForExecutionImpl):
(JSC):
(JSC::installOptimizedCode):
(JSC::prepareForExecution):
(JSC::prepareFunctionForExecution):
(JSC::replaceWithDeferredOptimizedCode):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153165 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=116130

This would just lead to us being overly conservative when deciding
whether we should unbox GetLocals with KnownCellUse UseKinds.

Reviewed by Filip Pizlo.

* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::observeUseKindOnNode):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153164 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=116134

CodeBlock and JITCode should be ThreadSafeRefCounted. We're going to
start using them on more threads very soon (with concurrent
compilation). This patch also fixes the specific place where we were
superfluously creating a RefPtr.

Reviewed by Oliver Hunt.

* bytecode/CodeBlock.h:
(JSC::CodeBlock::getJITType):
* jit/JITCode.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153163 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115705.

Reviewed by Geoffrey Garen.

The probe is in the form of a MacroAssembler pseudo instruction.
It takes 3 arguments: a ProbeFunction, and 2 void* args.

When inserted into the JIT at some code generation site, the probe
pseudo "instruction" will emit a minimal amount of code to save the
stack pointer, 1 (or more) scratch register(s), and the probe
arguments into a ProbeContext record on the stack. The emitted code
will then call a probe trampoline to do the rest of the work, which
consists of:
1. saving the remaining registers into the ProbeContext.
2. calling the ProbeFunction, and passing it the ProbeContext pointer.
3. restoring the registers from the ProbeContext after the ProbeFunction
   returns, and then returning to the JIT generated code.

The ProbeContext is stack allocated and is only valid for the duration
that the ProbeFunction is executing.

If the user supplied ProbeFunction alters the register values in the
ProbeContext, the new values will be installed into the registers upon
returning from the probe. This can be useful for some debugging or
testing purposes.

The probe mechanism is built conditional on USE(MASM_PROBE) which is
defined in config.h. USE(MASM_PROBE) will off by default.

This changeset only implements the probe mechanism for X86 and X86_64.

* 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:
* assembler/MacroAssembler.h:
(MacroAssembler):
(JSC::MacroAssembler::shouldBlind):
(JSC::MacroAssembler::store32):
* assembler/MacroAssemblerX86.h:
(MacroAssemblerX86):
(JSC::MacroAssemblerX86::trustedImm32FromPtr):
(JSC::MacroAssemblerX86::probe):
* assembler/MacroAssemblerX86Common.cpp: Added.
(JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters):
- CPU specific register dumper called by ProbeContext::dump().
(JSC::MacroAssemblerX86Common::ProbeContext::dump):
- Prints the ProbeContext to the DataLog.
* assembler/MacroAssemblerX86Common.h:
(MacroAssemblerX86Common):
(CPUState): Added.
(ProbeContext): Added.
* assembler/MacroAssemblerX86_64.h:
(MacroAssemblerX86_64):
(JSC::MacroAssemblerX86_64::trustedImm64FromPtr):
(JSC::MacroAssemblerX86_64::probe):
* assembler/X86Assembler.h:
* config.h: Added WTF_USE_MASM_PROBE flag.
* jit/JITStubs.cpp:
* jit/JITStubs.h:
* jit/JITStubsX86.h:
* jit/JITStubsX86Common.h: Added.
* jit/JITStubsX86_64.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153162 268f45cc-cd09-0410-ab3c-d52691b4dbfc

fourthTier: DFG should separate link phase into things that must be done concurrently and things that must be done synchronously, and have a way of passing data from one to the other
https://bugs.webkit.org/show_bug.cgi?id=116060

Reviewed by Gavin Barraclough.

This introduces the concept of a DFG::Plan, which corresponds to:

- The data that the concurrent DFG or FTL need to start compiling a CodeBlock.
  This mostly includes basic things like CodeBlock*, but also a list of
  must-handle values for OSR entry.

- The data that the synchronous linker need to link in code compiled by a
  concurrent compilation thread. This is further encapsulated by DFG::Finalizer,
  since the data, and the actions that need to be taken, are different in DFG
  versus FTL. This patch also institutes the policy that the concurrent
  compilation thread shall not use LinkBuffer::performFinalization(), since that
  code assumes that it's running on the same thread that will actually run the
  code.

- The actions that need to be taken to compile code. In other words, most of the
  code that previously lived in DFGDriver.cpp now lives in
  DFG::Plan::compileInThread().

- The actions that need to be taken when synchronously linking the code. This
  includes "really" adding watchpoints and identifiers, checking watchpoint and
  chain validity, and running the DFG::Finalizer.

Currently, DFGDriver just creates a Plan and runs it synchronously. But in the
future, we will be able to malloc some Plans and enqueue them, and have the
concurrent thread dequeue them and call Plan::compileInThread().

For now, this has no behavior or performance change.

* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::performFinalization):
* assembler/LinkBuffer.h:
(LinkBuffer):
(JSC::LinkBuffer::LinkBuffer):
(JSC::LinkBuffer::~LinkBuffer):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::initialize):
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::setFuturePossibleStructure):
(JSC::DFG::AbstractValue::filterFuturePossibleStructure):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addStructureTransitionCheck):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
* dfg/DFGDriver.cpp:
(DFG):
(JSC::DFG::compile):
* dfg/DFGFailedFinalizer.cpp: Added.
(DFG):
(JSC::DFG::FailedFinalizer::FailedFinalizer):
(JSC::DFG::FailedFinalizer::~FailedFinalizer):
(JSC::DFG::FailedFinalizer::finalize):
(JSC::DFG::FailedFinalizer::finalizeFunction):
* dfg/DFGFailedFinalizer.h: Added.
(DFG):
(FailedFinalizer):
* dfg/DFGFinalizer.cpp: Added.
(DFG):
(JSC::DFG::Finalizer::Finalizer):
(JSC::DFG::Finalizer::~Finalizer):
* dfg/DFGFinalizer.h: Added.
(DFG):
(Finalizer):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::dump):
(DFG):
* dfg/DFGGraph.h:
(Graph):
(JSC::DFG::Graph::masqueradesAsUndefinedWatchpointIsStillValid):
(JSC::DFG::Graph::compilation):
(JSC::DFG::Graph::identifiers):
(JSC::DFG::Graph::watchpoints):
(JSC::DFG::Graph::chains):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::linkFunction):
(DFG):
(JSC::DFG::JITCompiler::disassemble):
* dfg/DFGJITCompiler.h:
(JITCompiler):
(JSC::DFG::JITCompiler::addLazily):
* dfg/DFGJITFinalizer.cpp: Added.
(DFG):
(JSC::DFG::JITFinalizer::JITFinalizer):
(JSC::DFG::JITFinalizer::~JITFinalizer):
(JSC::DFG::JITFinalizer::finalize):
(JSC::DFG::JITFinalizer::finalizeFunction):
(JSC::DFG::JITFinalizer::finalizeCommon):
* dfg/DFGJITFinalizer.h: Added.
(DFG):
(JITFinalizer):
* dfg/DFGPlan.cpp: Added.
(DFG):
(JSC::DFG::dumpAndVerifyGraph):
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::~Plan):
(JSC::DFG::Plan::compileInThread):
(JSC::DFG::Plan::isStillValid):
(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::finalize):
* dfg/DFGPlan.h: Added.
(DFG):
(Plan):
(JSC::DFG::Plan::vm):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::identifierUID):
(JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):
* ftl/FTLGeneratedFunction.h: Added.
(FTL):
* ftl/FTLJITFinalizer.cpp: Added.
(FTL):
(JSC::FTL::JITFinalizer::JITFinalizer):
(JSC::FTL::JITFinalizer::~JITFinalizer):
(JSC::FTL::JITFinalizer::finalize):
(JSC::FTL::JITFinalizer::finalizeFunction):
* ftl/FTLJITFinalizer.h: Added.
(FTL):
(JITFinalizer):
(JSC::FTL::JITFinalizer::initializeExitThunksLinkBuffer):
(JSC::FTL::JITFinalizer::initializeEntrypointLinkBuffer):
(JSC::FTL::JITFinalizer::initializeCode):
(JSC::FTL::JITFinalizer::initializeFunction):
(JSC::FTL::JITFinalizer::initializeArityCheck):
(JSC::FTL::JITFinalizer::initializeJITCode):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLLink.h:
(FTL):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* ftl/FTLState.h:
(FTL):
(State):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153161 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=116135.

Reviewed by Michael Saboff.

This mod only moves the CPU specific parts out. There is no code change.
Tested on debug builds of X86, X86_64, ARM and ARMv7. The SH4 and MIPS
ports are untested. Windows port also not tested.

* GNUmakefile.list.am:
* JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JITStubs.cpp:
(JSC::performPlatformSpecificJITAssertions):
* jit/JITStubsARM.h: Added.
(JSC::ctiTrampoline):
(JSC::ctiTrampolineEnd):
(JSC::ctiVMThrowTrampoline):
(JSC::ctiOpThrowNotCaught):
(JSC::performARMJITAssertions):
* jit/JITStubsARMv7.h: Added.
(JSC::ctiTrampoline):
(JSC::ctiVMThrowTrampoline):
(JSC::ctiOpThrowNotCaught):
(JSC::performARMv7JITAssertions):
* jit/JITStubsMIPS.h: Added.
(JSC::performMIPSJITAssertions):
* jit/JITStubsSH4.h: Added.
* jit/JITStubsX86.h: Added.
* jit/JITStubsX86_64.h: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153160 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=116082

It's crashing because CodeBlock::baselineVersion() doesn't know how to handle the case where 'this' is the
baseline version but it hasn't been assigned to the m_blahCodeBlock field in BlahExecutable. The fix is to
check if we're the baseline version in baselineVersion() and return this if so.

Reviewed by Filip Pizlo.

* bytecode/CodeBlock.h:
(JSC::CodeBlock::baselineVersion):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153159 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115938

We're going to add some more types of check hoisting soon, so let's have
the right name here.

Rubber stamped by Filip Pizlo.

* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGStructureCheckHoistingPhase.cpp: Removed.
* dfg/DFGStructureCheckHoistingPhase.h: Removed.
* dfg/DFGTypeCheckHoistingPhase.cpp: Added.
(DFG):
(TypeCheckHoistingPhase):
(JSC::DFG::TypeCheckHoistingPhase::TypeCheckHoistingPhase):
(JSC::DFG::TypeCheckHoistingPhase::run):
(JSC::DFG::TypeCheckHoistingPhase::shouldConsiderForHoisting):
(JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheck):
(CheckData):
(JSC::DFG::TypeCheckHoistingPhase::CheckData::CheckData):
(JSC::DFG::performTypeCheckHoisting):
* dfg/DFGTypeCheckHoistingPhase.h: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153158 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115943

Currently it uses Uncountable, which gives us no information if we end up exiting due to a
mismatched ClassInfo pointer. It should instead use BadType and should pass the correct
JSValueSource and Node instead of passing empty values.

Reviewed by Filip Pizlo.

* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArray):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153157 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115942

Reviewed by Oliver Hunt.

Added two obvious nodes: Jump and ForceOSRExit. We already had everything we needed
to support them.

Adding these increases our coverage a fair bit, and revealed a bug: LLVM's full
instruction selector currently appears to mishandle doubles in constant pools (or
just constant pools in general) with the small code model in the MCJIT. But switching
to FastISel "fixes" it. That's what this patch does, for now. This will probably
actually be permanent; the FastISel does pretty much everything we would ever want,
at least in the foreseeable future.

* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
(FTL):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileBlock):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileJSConstant):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileJump):
(JSC::FTL::LowerDFGToLLVM::compileReturn):
(JSC::FTL::LowerDFGToLLVM::compileForceOSRExit):
* runtime/Options.h:
(JSC):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153156 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115941

Reviewed by Mark Hahnenberg.

Pretty simple, but factors out the craziness of comparing against null or undefined
in a way that is reusable for both == and ===.

* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
(JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153155 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115939

Reviewed by Oliver Hunt and Mark Hahnenberg.

The most interesting part of this patch is the way I make it easier to deal with
the inputs to Phi functions. This adds the notion of ValueFromBlock, which you
can get by doing m_out.anchor(value). You can build up a vector of these, and then
pass them to m_out.phi(type, vector) in one go.

* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/FTLAbbreviatedTypes.h: Added.
(FTL):
* ftl/FTLAbbreviations.h:
(FTL):
(JSC::FTL::addIncoming):
(JSC::FTL::buildPhi):
* ftl/FTLAbstractHeapRepository.h:
(FTL):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lowDouble):
(JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIfIsStillValid):
* ftl/FTLOutput.h:
(JSC::FTL::Output::phi):
(Output):
(JSC::FTL::Output::anchor):
* ftl/FTLValueFromBlock.h: Added.
(FTL):
(ValueFromBlock):
(JSC::FTL::ValueFromBlock::ValueFromBlock):
(JSC::FTL::ValueFromBlock::value):
(JSC::FTL::ValueFromBlock::block):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153154 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115927

Reviewed by Mark Hahnenberg.

Do the sensible thing, and make it so that for common cases, CompareEq is
implemented in terms of CompareStrictEq in the FTL backend. All of the cases
we currently support can be done this way.

* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileCompareEq):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153153 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115926

Reviewed by Mark Hahnenberg.

This node exists mainly to help the DFG see that a node may have both an int
and a double representation. But in the FTL, nodes already have multiple
representations. So this is just a no-op for the FTL.

I considered making it so that the node isn't even inserted if we're doing
FTL compilation, but that would have required a bunch of conditionalizing in
the DFG's optimization phases, which sort of expect this node to be present
and necessary.

* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble):
(LowerDFGToLLVM):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153152 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115924

Reviewed by Mark Hahnenberg.

* ftl/FTLAbbreviations.h:
(JSC::FTL::buildNot):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileLogicalNot):
(LowerDFGToLLVM):
* ftl/FTLOutput.h:
(JSC::FTL::Output::bitNot):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153151 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115923

Reviewed by Mark Hahnenberg.

Also fixed a bug where double CompareLess would assert.

* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::compileCompareLess):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
(JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
(JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153150 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115920

Reviewed by Mark Hahnenberg.

We don't yet support watchpoints, but this does all the wiring right up to the
part where we would have emitted watchpoints. I've also written this in a way that
makes it easy to use the case where you would have anyway speculated non-masquerading
even if the watchpoint was invalidated.

This is inherently racy, of course: but the only race here is that you might first
set the watchpoint, and then the watchpoint is invalidated, and then you compile rest
of the code in a way that doesn't need the watchpoint. That's fine, since the FTL
will remember that it had set the watchpoint and then cancel the compilation.

* ftl/FTLAbbreviations.h:
(JSC::FTL::int8Type):
* ftl/FTLAbstractHeapRepository.h:
(FTL):
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
* ftl/FTLCommonValues.h:
(CommonValues):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::LowerDFGToLLVM::lowNonNullObject):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
(JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIsStillValid):
(JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIfIsStillValid):
* ftl/FTLOutput.h:
(JSC::FTL::Output::constInt8):
(JSC::FTL::Output::load8):
(JSC::FTL::Output::isZero8):
(JSC::FTL::Output::notZero8):
(JSC::FTL::Output::testIsZero8):
(JSC::FTL::Output::testNonZero8):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153149 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115598

Reviewed by Geoffrey Garen.

I believe that we've now fixed this, and this patch just adds the relevant assertion.

* runtime/JSCellInlines.h:
(JSC::JSCell::JSCell):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153148 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115594

Reviewed by Geoffrey Garen.

This makes it possible to have the currently-being-compiled CodeBlock not be
installed in Executable, while also allowing it to point to its intended
alternative(). So long as we were using ownership and not reference counting, it
would have been difficult to have both CodeBlock::m_alternative and
Executable::m_codeBlockForBlah point to the previous CodeBlock.

I also took the opportunity to clean up a bunch of code that appears to have
rotted.

* assembler/MacroAssemblerCodeRef.h:
(MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::operator==):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::releaseAlternative):
(JSC::CodeBlock::setAlternative):
(CodeBlock):
(JSC::GlobalCodeBlock::GlobalCodeBlock):
(JSC::ProgramCodeBlock::ProgramCodeBlock):
(JSC::EvalCodeBlock::EvalCodeBlock):
(JSC::FunctionCodeBlock::FunctionCodeBlock):
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::~DFGCodeBlocks):
(JSC::DFGCodeBlocks::jettison):
(JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
* heap/DFGCodeBlocks.h:
(DFGCodeBlocks):
* heap/Heap.cpp:
(JSC::Heap::jettisonDFGCodeBlock):
* heap/Heap.h:
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* runtime/Executable.cpp:
(JSC::jettisonCodeBlock):
(JSC::EvalExecutable::jitCompile):
(JSC::EvalExecutable::compileInternal):
(JSC::ProgramExecutable::jitCompile):
(JSC::ProgramExecutable::compileInternal):
(JSC::FunctionExecutable::jitCompileForCall):
(JSC::FunctionExecutable::jitCompileForConstruct):
(JSC::FunctionExecutable::produceCodeBlockFor):
(JSC::FunctionExecutable::compileForCallInternal):
(JSC::FunctionExecutable::compileForConstructInternal):
* runtime/Executable.h:
(EvalExecutable):
(FunctionExecutable):
(JSC::FunctionExecutable::codeBlockFor):
* runtime/ExecutionHarness.h:
(JSC::prepareForExecution):
(JSC::prepareFunctionForExecution):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153147 268f45cc-cd09-0410-ab3c-d52691b4dbfc

fourthTier: DFG should have its own notion of StructureChain, and it should be possible to validate it after compilation finishes
https://bugs.webkit.org/show_bug.cgi?id=115841

Reviewed by Oliver Hunt.

This adds IntendedStructureChain, which is like StructureChain, except that it holds a bit
more information and can be validated independantly of its owning Structure and lexical
GlobalObject, since it remembers both of those things. It's also malloc'd and RefCounted
rather than GC'd, so it can be allocated in a concurrent compilation thread.

Gave this class a bunch of methods to allow the following idiom:

- Snapshot a structure chain concurrently. This structure chain may end up being
  wrong in case of races, but in that case we will find out when we try to validate
  it.

- Perform validation on the structure chain itself, without recomputing the chain.
  Previously, many chain validation methods (prototypeChainMayInterceptStoreTo() for
  example) recomputed the chain, and hence, were inherently racy: you could build one
  chain and then validate against a different chain, and hence not realize that the
  chain you did build was actually broken for your purposes, because the chain you
  checked was a different one.

- Validate that the chain is still the right one at any time, allowing the cancellation
  of compilation if there was a race.

Also added DFG::DesiredStructureChains, which tracks those intended structure chains that
the compiler had already chosen to use. If any of those are invalid at link time, throw
out the compilation.

* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeForChain):
(JSC::GetByIdStatus::computeFor):
* bytecode/GetByIdStatus.h:
(JSC::GetByIdStatus::GetByIdStatus):
(JSC::GetByIdStatus::chain):
(GetByIdStatus):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
* bytecode/PutByIdStatus.h:
(JSC::PutByIdStatus::PutByIdStatus):
(JSC::PutByIdStatus::structureChain):
(PutByIdStatus):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDesiredStructureChains.cpp: Added.
(DFG):
(JSC::DFG::DesiredStructureChains::DesiredStructureChains):
(JSC::DFG::DesiredStructureChains::~DesiredStructureChains):
(JSC::DFG::DesiredStructureChains::areStillValid):
* dfg/DFGDesiredStructureChains.h: Added.
(DFG):
(DesiredStructureChains):
(JSC::DFG::DesiredStructureChains::addLazily):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isStillValid):
(DFG):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::linkFunction):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* runtime/IntendedStructureChain.cpp: Added.
(JSC):
(JSC::IntendedStructureChain::IntendedStructureChain):
(JSC::IntendedStructureChain::~IntendedStructureChain):
(JSC::IntendedStructureChain::isStillValid):
(JSC::IntendedStructureChain::matches):
(JSC::IntendedStructureChain::chain):
(JSC::IntendedStructureChain::mayInterceptStoreTo):
(JSC::IntendedStructureChain::isNormalized):
(JSC::IntendedStructureChain::terminalPrototype):
* runtime/IntendedStructureChain.h: Added.
(JSC):
(IntendedStructureChain):
(JSC::IntendedStructureChain::head):
(JSC::IntendedStructureChain::size):
(JSC::IntendedStructureChain::at):
(JSC::IntendedStructureChain::operator[]):
(JSC::IntendedStructureChain::last):
* runtime/Structure.cpp:
(JSC::Structure::prototypeChainMayInterceptStoreTo):
* runtime/Structure.h:
(Structure):
* runtime/StructureInlines.h:
(JSC::Structure::storedPrototypeObject):
(JSC):
(JSC::Structure::storedPrototypeStructure):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153146 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Reviewed by Oliver Hunt.

Source/JavaScriptCore:

    Rationalized 'this' value conversion
    https://bugs.webkit.org/show_bug.cgi?id=115542

    This fixes a bunch of Sputnik tests, and some bad pointer access.

    The new model is that the callee always performs 'this' value conversion.

    My ultimate goal is to break up resolve_with_this into single-result
    opcodes. This step avoids having to add a special form of convert_this
    that distinguishes callers vs callees.

    Only the callee knows whether it uses 'this' and/or whether 'this'
    conversion should use StrictMode, so it's most natural to perform
    convert_this in the callee.

    * API/JSCallbackFunction.cpp:
    (JSC::JSCallbackFunction::call): Perform 'this' value conversion for
    our callee, since it may observe 'this'.

    * API/JSCallbackObjectFunctions.h:
    (JSC::::call): Ditto.

    * API/JSContextRef.cpp:
    (JSGlobalContextCreateInGroup): Use a proxy 'this' object in global scope
    even when we're not in the browser. This eliminates some odd cases where
    API clients used to be able to get a direct reference to an environment
    record. Now, any reference to an environment record unambiguously means
    that the VM resolved that record in the scope chain.

    (JSContextGetGlobalObject): Removed an incorrect comment. Now that JSC
    participates in the proxy 'this' object scheme, the behavior is not
    WebCore-only.

    * API/JSObjectRef.cpp:
    (JSObjectSetPrototype):
    (JSObjectCallAsFunction): Don't perform 'this' value conversion in the
    caller; the callee will do it if needed.

    * JavaScriptCore.order: Order!

    * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
    * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
    What are the chances that this will work?

    * bytecode/CodeBlock.cpp:
    (JSC::CodeBlock::dumpBytecode):
    (JSC::CodeBlock::CodeBlock): Renamed convert_this to to_this, to match our
    other conversion opcodes.

    * bytecode/CodeOrigin.h:
    (CodeOrigin):
    (InlineCallFrame):
    (JSC::CodeOrigin::codeOriginOwner): Use the more precise type for our
    executable, so compilation can discover where we're in strict mode.

    * bytecode/Opcode.h:
    (JSC::padOpcodeName): Updated for rename.

    * bytecompiler/BytecodeGenerator.cpp:
    (JSC::BytecodeGenerator::BytecodeGenerator): Always emit to_this when
    'this' is in use -- strict mode still needs to convert environment
    records to 'undefined'.

    * dfg/DFGAbstractState.cpp:
    (JSC::DFG::AbstractState::executeEffects):
    * dfg/DFGByteCodeParser.cpp:
    (JSC::DFG::ByteCodeParser::parseBlock):
    * dfg/DFGCapabilities.h:
    (JSC::DFG::canCompileOpcode): Updated for renames.

    * dfg/DFGFixupPhase.cpp:
    (JSC::DFG::FixupPhase::fixupNode): Tightened up this code to consider
    strict mode (a new requirement) and to consider the global object (which
    was always a requirement).

    * dfg/DFGGraph.h:
    (JSC::DFG::Graph::globalThisObjectFor):
    (JSC::DFG::Graph::executableFor):
    * dfg/DFGNodeType.h:
    * 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): Ditto.

    * interpreter/Interpreter.cpp:
    (JSC::eval):
    (JSC::Interpreter::execute):
    (JSC::Interpreter::executeCall):
    * interpreter/Interpreter.h: Don't ASSERT about 'this' -- it's our job
    to fix it up if needed.

    * jit/JIT.cpp:
    (JSC::JIT::privateCompileMainPass):
    (JSC::JIT::privateCompileSlowCases):
    * jit/JIT.h:
    (JIT):
    * jit/JITOpcodes.cpp:
    (JSC::JIT::emit_op_to_this):
    (JSC::JIT::emitSlow_op_to_this):
    * jit/JITOpcodes32_64.cpp:
    (JSC::JIT::emit_op_to_this):
    (JSC::JIT::emitSlow_op_to_this):
    * jit/JITStubs.cpp:
    (JSC::DEFINE_STUB_FUNCTION):
    * jit/JITStubs.h: Removed special-case code for various kinds of
    conversions. The baseline fast path is now final objects only. It hurt
    my brain to think through how to keep the other fast paths working, and
    our benchmarks do not object.

    * llint/LLIntData.cpp:
    (JSC::LLInt::Data::performAssertions):
    * llint/LLIntSlowPaths.cpp:
    (JSC::LLInt::LLINT_SLOW_PATH_DECL):
    * llint/LLIntSlowPaths.h:
    (LLInt):
    * llint/LowLevelInterpreter.asm:
    * llint/LowLevelInterpreter32_64.asm:
    * llint/LowLevelInterpreter64.asm: Updated for renames. Removed some
    special case code, as in the JIT above.

    * profiler/ProfileGenerator.cpp:
    (JSC::ProfileGenerator::addParentForConsoleStart):
    * runtime/CallData.cpp:
    (JSC::call):
    * runtime/ClassInfo.h:
    (MethodTable):
    * runtime/Completion.cpp:
    (JSC::evaluate):
    * runtime/DatePrototype.cpp:
    (JSC::dateProtoFuncToJSON): The callee performs 'this' conversion, not
    the caller.

    * runtime/GetterSetter.cpp:
    (JSC::callGetter):
    (JSC::callSetter):
    * runtime/GetterSetter.h: Added helper functions for invoking getters
    and setters from C++ code, since this was duplicated in a bunch of
    places.

    * runtime/JSActivation.cpp:
    (JSC::JSActivation::toThis):
    * runtime/JSActivation.h:
    (JSActivation):
    * runtime/JSCJSValue.cpp:
    (JSC::JSValue::toThisSlowCase):
    (JSC::JSValue::putToPrimitive):
    * runtime/JSCJSValue.h:
    (JSValue):
    * runtime/JSCJSValueInlines.h:
    (JSC::JSValue::toThis):
    * runtime/JSCell.cpp:
    (JSC::JSCell::toThis):
    * runtime/JSCell.h:
    (JSCell):
    * runtime/JSGlobalObject.cpp:
    (JSC::JSGlobalObject::toThis):
    * runtime/JSGlobalObject.h:
    (JSGlobalObject): Filled out runtime support for converting 'this'
    values as needed, according to the appropriate strictness, using
    helper functions where getter/setter code was duplicated.

    * runtime/JSGlobalObjectFunctions.cpp:
    (JSC::globalFuncProtoGetter):
    (JSC::globalFuncProtoSetter): Perform 'this' value conversion, since we
    observe 'this'.

    * runtime/JSNameScope.cpp:
    (JSC::JSNameScope::toThis):
    * runtime/JSNameScope.h:
    (JSNameScope): Same as JSActivation.

    * runtime/JSObject.cpp:
    (JSC::JSObject::put):
    (JSC::JSObject::setPrototypeWithCycleCheck): Bug fix. Don't peform
    'this' value conversion in this helper function. The __proto__
    setter does this for us, since it's the function that logically observes
    'this' -- and we can ASSERT so. Also, the previous code used
    "globalExec()->thisValue()", which is a read past the beginning of a
    buffer! I don't think this ever worked on purpose.

    (JSC::JSObject::toThis):
    (JSC::JSObject::fillGetterPropertySlot):
    * runtime/JSObject.h:
    (JSC::JSObject::inlineGetOwnPropertySlot):
    * runtime/JSScope.cpp:
    (JSC::JSScope::resolveWithThis):
    * runtime/JSString.cpp:
    (JSC::JSString::toThis):
    * runtime/JSString.h:
    (JSString):
    * runtime/PropertySlot.cpp:
    (JSC::PropertySlot::functionGetter):
    * runtime/PropertySlot.h:
    (JSC):
    (JSC::PropertySlot::setGetterSlot):
    (JSC::PropertySlot::setCacheableGetterSlot):
    * runtime/SparseArrayValueMap.cpp:
    (JSC::SparseArrayEntry::get):
    (JSC::SparseArrayEntry::put):
    * runtime/StrictEvalActivation.cpp:
    (JSC::StrictEvalActivation::toThis):
    * runtime/StrictEvalActivation.h:
    (StrictEvalActivation): Ditto.

Source/WebCore:

    Rationalized 'this' value conversion
    https://bugs.webkit.org/show_bug.cgi?id=115542

Source/WebKit/mac:

    Rationalized 'this' value conversion
    https://bugs.webkit.org/show_bug.cgi?id=115542

Source/WebKit2:

    Rationalized 'this' value conversion
    https://bugs.webkit.org/show_bug.cgi?id=115542

LayoutTests:

    Rationalized 'this' value conversion
    https://bugs.webkit.org/show_bug.cgi?id=115542

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153145 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115582

Reviewed by Geoffrey Garen.

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::ByteCodeParser):
(ByteCodeParser):
(JSC::DFG::parse):
* dfg/DFGByteCodeParser.h:
(DFG):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153144 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115445

Reviewed by Geoffrey Garen.

Change the Profiler::Database API for Compilation creation so that we don't add
it to the Database until it's completely constructed. This prevents the Database
from seeing Compilations that are being concurrently constructed.

Change the Profiler::Database itself to do locking for creation of Bytecodes and
for modifying the map. This map may be consulted by both the main thread and the
concurrent thread.

* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::linkFunction):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* profiler/ProfilerBytecodes.h:
* profiler/ProfilerDatabase.cpp:
(JSC::Profiler::Database::ensureBytecodesFor):
(JSC::Profiler::Database::notifyDestruction):
(JSC::Profiler::Database::addCompilation):
* profiler/ProfilerDatabase.h:
(Database):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153143 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115300

Source/JavaScriptCore:

Reviewed by Geoffrey Garen.

Change any code transitively called from DFG compilation to use StringImpl*
directly instead of String, Identifier, or PropertyName. I use the convention
of passing "StringImpl* uid" instead of an Identifier or PropertyName.

Switch over any code transitively called from DFG compilation to use CStrings
whenever possible for all of its debug dumping.

This makes it possible to compile things without hitting the ref/deref
assertion in StringImpl.

* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::inferredName):
(JSC::CodeBlock::sourceCodeForTools):
(JSC::CodeBlock::sourceCodeOnOneLine):
(JSC::constantName):
(JSC::idName):
(JSC::CodeBlock::registerName):
(JSC::regexpToSourceString):
(JSC::regexpName):
(JSC::pointerToSourceString):
(JSC::CodeBlock::printUnaryOp):
(JSC::CodeBlock::printBinaryOp):
(JSC::CodeBlock::printConditionalJump):
(JSC::CodeBlock::printGetByIdOp):
(JSC::dumpStructure):
(JSC::CodeBlock::printCallOp):
(JSC::CodeBlock::printPutByIdOp):
(JSC::CodeBlock::printStructure):
(JSC::CodeBlock::printStructures):
(JSC::CodeBlock::dumpBytecode):
* bytecode/CodeBlock.h:
(CodeBlock):
* bytecode/CodeBlockHash.cpp:
(JSC::CodeBlockHash::CodeBlockHash):
* bytecode/CodeOrigin.cpp:
(JSC::InlineCallFrame::inferredName):
* bytecode/CodeOrigin.h:
(InlineCallFrame):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeForChain):
(JSC::GetByIdStatus::computeFor):
* bytecode/GetByIdStatus.h:
(JSC):
(GetByIdStatus):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
* bytecode/PutByIdStatus.h:
(JSC):
(PutByIdStatus):
* bytecode/ReduceWhitespace.cpp:
(JSC::reduceWhitespace):
* bytecode/ReduceWhitespace.h:
(JSC):
* bytecode/ResolveGlobalStatus.cpp:
(JSC::computeForStructure):
(JSC::ResolveGlobalStatus::computeFor):
* bytecode/ResolveGlobalStatus.h:
(JSC):
(ResolveGlobalStatus):
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(ByteCodeParser):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDesiredIdentifiers.cpp: Added.
(DFG):
(JSC::DFG::DesiredIdentifiers::DesiredIdentifiers):
(JSC::DFG::DesiredIdentifiers::~DesiredIdentifiers):
(JSC::DFG::DesiredIdentifiers::addLazily):
(JSC::DFG::DesiredIdentifiers::reallyAdd):
* dfg/DFGDesiredIdentifiers.h: Added.
(DFG):
(DesiredIdentifiers):
(JSC::DFG::DesiredIdentifiers::numberOfIdentifiers):
(JSC::DFG::DesiredIdentifiers::at):
(JSC::DFG::DesiredIdentifiers::operator[]):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
(JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::Graph):
(JSC::DFG::Graph::dump):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGRepatch.cpp:
(JSC::DFG::tryBuildGetByIDList):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::identifierUID):
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedGetById):
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::compile):
* parser/SourceCode.cpp: Added.
(JSC):
(JSC::SourceCode::toUTF8):
* parser/SourceCode.h:
(SourceCode):
* profiler/ProfilerBytecodes.cpp:
(JSC::Profiler::Bytecodes::toJS):
* profiler/ProfilerBytecodes.h:
(JSC::Profiler::Bytecodes::inferredName):
(JSC::Profiler::Bytecodes::sourceCode):
(Bytecodes):
* runtime/Identifier.h:
(JSC::Identifier::utf8):
(JSC):
* runtime/Structure.cpp:
(JSC::Structure::addPropertyTransitionToExistingStructureImpl):
(JSC::Structure::addPropertyTransitionToExistingStructure):
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
(JSC::Structure::getConcurrently):
(JSC::Structure::prototypeChainMayInterceptStoreTo):
(JSC):
* runtime/Structure.h:
(Structure):
* runtime/StructureInlines.h:
(JSC::Structure::getConcurrently):

Source/WTF:

Reviewed by Geoffrey Garen.

Make it possible to do more things directly to StringImpl*'s, including being
able to directly do utf8 conversion on a substring without creating the
substring first.

Add assertions to StringImpl that it isn't being ref/deref'd from the
compilation thread.

* wtf/PrintStream.cpp:
(WTF::printInternal):
(WTF):
* wtf/PrintStream.h:
(WTF):
(WTF::printInternal):
* wtf/StringPrintStream.h:
(WTF):
(WTF::toCString):
* wtf/text/StringImpl.cpp:
(WTF::StringImpl::utf8ForRange):
(WTF::StringImpl::utf8):
(WTF):
* wtf/text/StringImpl.h:
(StringImpl):
(WTF::StringImpl::hasAtLeastOneRef):
(WTF::StringImpl::ref):
(WTF::StringImpl::deref):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153142 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115525

Reviewed by Geoffrey Garen.

The structure transition table basically maps string to structure. The string is
always also stored, and ref'd, in the structure in Structure::m_nameInPrevious.
m_nameInPrevious is never mutated, and never cleared. The string cannot die unless
the structure dies. If the structure dies, then that entry in the transition map
becomes a zombie anyway and we will detect this separately.

So, we don't need to use RefPtr<StringImpl>. We can just use StringImpl*.

This also fixes a goof where we were getting the StringImpl's hash rather than
using a pointer hash. Not only is the latter faster, but it prevents my change
from leading to crashes: with my change we can have zombie keys, not just zombie
values. They will exist only until the next map mutation, which will clear them.
Lookups will work fine because the lookup routine will reject zombies. But it
does mean that the HashMap will have to deal with dangling StringImpl*'s; all it
takes to make this work is to ensure that the HashMap itself never dereferences
them. Using a pointer hash rather than StringImpl::existingHash() accomplishes
this.

This also ensures that we don't accidentally call ref() or deref() from the
compilation thread, if the compilation thread inspects the transition table.

And no, we wouldn't have been able to use the HashMap<RefPtr<...>, ...>
specialization, because the transition table is actually
HashMap<pair<RefPtr<StringImpl>, unsigned>, ...>: hence that specialization
doesn't kick in. We could have written a new specialization or something, but
that seemed like a lot of work given that we don't need the table to be ref'ing
the strings anyways.

* runtime/Structure.cpp:
(JSC::StructureTransitionTable::add):
* runtime/StructureTransitionTable.h:
(StructureTransitionTable):
(Hash):
(JSC::StructureTransitionTable::Hash::hash):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153141 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115468

Reviewed by Geoffrey Garen.

This makes the main thread modify the transition table while holding a lock. Note
that the GC might modify its weak pointers without locking, but the GC will lock out
the compilation thread anyway. The map will then only reshape in response to add()
and set(), which happen while holding a lock.

This allows the compilation thread to now query transition tables safely, provided it
holds a lock when doing so.

Also changed LLVM asm printer initialization to just initialize the X86 one. It makes
sense for us to just initialize the asm printer(s) that we actually use; you could
imagine us being linked to a system LLVM that has cross-compilation support; there is
no point in the WebKit or JSC process doing work to initialize all of those targets.
That part was rubber stamped by Mark Hahnenberg.

* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreadingOnce):
* runtime/Structure.cpp:
(JSC::Structure::addPropertyTransitionToExistingStructureImpl):
(JSC::Structure::addPropertyTransitionToExistingStructure):
(JSC):
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
(JSC::Structure::addPropertyTransition):
(JSC::Structure::nonPropertyTransition):
* runtime/Structure.h:
(Structure):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153140 268f45cc-cd09-0410-ab3c-d52691b4dbfc

fourthTier: Structure::getConcurrently() may be called from for uncacheable dictionaries, and this is safe
https://bugs.webkit.org/show_bug.cgi?id=115464

Reviewed by Oliver Hunt and Geoffrey Garen.

This can happen for example transitively from JSObject::put(). getCurrently() does
work for uncacheable dictionaries; it just has the obvious race that right after it
returns, the result it returned may no longer be right. This isn't an issue if it was
called on the main thread, and may not be an issue in some other situations.

So, we should just remove the assertion, since the only thing it buys us is crashes.

* runtime/Structure.cpp:
(JSC::Structure::getConcurrently):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153139 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Rubber stamped by Mark Rowe.

* Scripts/copy-webkitlibraries-to-product-directory:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153138 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Rubber stamped by Mark Rowe.

* Configurations/JavaScriptCore.xcconfig:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153137 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Rubber stamped by Mark Hahnenberg.

* LLVMIncludesMountainLion.tar.bz2:
* LLVMLibrariesMountainLion.tar.bz2:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153136 268f45cc-cd09-0410-ab3c-d52691b4dbfc

fourthTier: String::utf8() should also be available as StringImpl::utf8() so that you don't have to ref() a StringImpl just to get its utf8()
https://bugs.webkit.org/show_bug.cgi?id=115393

Reviewed by Geoffrey Garen.

Source/JavaScriptCore:

* runtime/JSGlobalObjectFunctions.cpp:
(JSC::encode):

Source/WebCore:

No new tests because no new behavior.

* Modules/websockets/WebSocket.cpp:
(WebCore::WebSocket::close):
* Modules/websockets/WebSocketChannel.cpp:
(WebCore::WebSocketChannel::send):
* html/MediaFragmentURIParser.cpp:
(WebCore::MediaFragmentURIParser::parseFragments):

Source/WTF:

* WTF.xcodeproj/project.pbxproj:
* wtf/text/ConversionMode.h: Added.
(WTF):
* wtf/text/StringImpl.cpp:
(WTF):
(WTF::putUTF8Triple):
(WTF::StringImpl::utf8):
* wtf/text/StringImpl.h:
(StringImpl):
* wtf/text/WTFString.cpp:
(WTF):
(WTF::String::utf8):
* wtf/text/WTFString.h:
(String):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153135 268f45cc-cd09-0410-ab3c-d52691b4dbfc

fourthTier: ASSERT that commonly used not-thread-safe methods in the runtime are not being called during compilation
https://bugs.webkit.org/show_bug.cgi?id=115297

Source/JavaScriptCore:

Reviewed by Geoffrey Garen.

Put in assertions that we're not doing bad things in compilation threads. Also
factored compilation into compile+link so that even though we don't yet have
concurrent compilation, we can be explicit about which parts of DFG work are
meant to be concurrent, and which aren't.

Also fix a handful of bugs found by these assertions.

* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ResolveGlobalStatus.cpp:
(JSC::computeForStructure):
* bytecode/Watchpoint.cpp:
(JSC::WatchpointSet::add):
(JSC::InlineWatchpointSet::inflateSlow):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::~JITCompiler):
(DFG):
(JSC::DFG::JITCompiler::compileBody):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compileFunction):
(JSC::DFG::JITCompiler::linkFunction):
* dfg/DFGJITCompiler.h:
(JITCompiler):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLCompile.h:
(FTL):
* ftl/FTLLink.cpp: Added.
(FTL):
(JSC::FTL::compileEntry):
(JSC::FTL::link):
* ftl/FTLLink.h: Added.
(FTL):
* ftl/FTLState.cpp:
(JSC::FTL::State::State):
* ftl/FTLState.h:
(FTL):
(State):
* runtime/Structure.cpp:
(JSC::Structure::get):
(JSC::Structure::prototypeChainMayInterceptStoreTo):
* runtime/Structure.h:
(JSC::Structure::materializePropertyMapIfNecessary):
* runtime/StructureInlines.h:
(JSC::Structure::get):

Source/WTF:

Reviewed by Geoffrey Garen.

Taught WTF the notion of compilation threads. This allows all parts of our stack
to assert that we're not being called from a JSC compilation thread. This is in
WTF because it will probably end up being used in StringImpl and WTFString.

* WTF.xcodeproj/project.pbxproj:
* wtf/CompilationThread.cpp: Added.
(WTF):
(WTF::initializeCompilationThreadsOnce):
(WTF::initializeCompilationThreads):
(WTF::isCompilationThread):
(WTF::exchangeIsCompilationThread):
* wtf/CompilationThread.h: Added.
(WTF):
(CompilationScope):
(WTF::CompilationScope::CompilationScope):
(WTF::CompilationScope::~CompilationScope):
(WTF::CompilationScope::leaveEarly):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153134 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=113624

Reviewed by Geoffrey Garen.

Made all of the operations that the FTL already supports, also support doubles.
OSR exit already basically had everything it needed, so no changes there. This
mostly just glues together bits of DFG IR to LLVM IR, in a straight-forward way.

* ftl/FTLAbbreviations.h:
(FTL):
(JSC::FTL::doubleType):
(JSC::FTL::constReal):
(JSC::FTL::buildPhi):
(JSC::FTL::addIncoming):
(JSC::FTL::buildFAdd):
(JSC::FTL::buildFSub):
(JSC::FTL::buildFMul):
(JSC::FTL::buildFNeg):
(JSC::FTL::buildSIToFP):
(JSC::FTL::buildUIToFP):
(JSC::FTL::buildBitCast):
(JSC::FTL::buildFCmp):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::CommonValues):
* ftl/FTLCommonValues.h:
(CommonValues):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lower):
(JSC::FTL::LowerDFGToLLVM::compileGetLocal):
(JSC::FTL::LowerDFGToLLVM::compileSetLocal):
(JSC::FTL::LowerDFGToLLVM::compileAdd):
(JSC::FTL::LowerDFGToLLVM::compileArithSub):
(JSC::FTL::LowerDFGToLLVM::compileArithMul):
(JSC::FTL::LowerDFGToLLVM::compileArithNegate):
(JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
(JSC::FTL::LowerDFGToLLVM::compileGetByVal):
(JSC::FTL::LowerDFGToLLVM::compileCompareEq):
(JSC::FTL::LowerDFGToLLVM::compileCompareLess):
(JSC::FTL::LowerDFGToLLVM::lowDouble):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::lowJSValue):
(JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
(JSC::FTL::LowerDFGToLLVM::unboxDouble):
(JSC::FTL::LowerDFGToLLVM::boxDouble):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::speculateNumber):
(JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
(JSC::FTL::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
* ftl/FTLOutput.h:
(JSC::FTL::Output::constDouble):
(Output):
(JSC::FTL::Output::phi):
(JSC::FTL::Output::doubleAdd):
(JSC::FTL::Output::doubleSub):
(JSC::FTL::Output::doubleMul):
(JSC::FTL::Output::doubleNeg):
(JSC::FTL::Output::intToFP):
(JSC::FTL::Output::intToDouble):
(JSC::FTL::Output::unsignedToFP):
(JSC::FTL::Output::unsignedToDouble):
(JSC::FTL::Output::bitCast):
(JSC::FTL::Output::loadDouble):
(JSC::FTL::Output::storeDouble):
(JSC::FTL::Output::doubleEqual):
(JSC::FTL::Output::doubleNotEqualOrUnordered):
(JSC::FTL::Output::doubleLessThan):
(JSC::FTL::Output::doubleLessThanOrEqual):
(JSC::FTL::Output::doubleGreaterThan):
(JSC::FTL::Output::doubleGreaterThanOrEqual):
(JSC::FTL::Output::doubleEqualOrUnordered):
(JSC::FTL::Output::doubleNotEqual):
(JSC::FTL::Output::doubleLessThanOrUnordered):
(JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
(JSC::FTL::Output::doubleGreaterThanOrUnordered):
(JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
(JSC::FTL::Output::testIsZero64):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153133 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115301

Reviewed by Geoffrey Garen.

Makes SymbolTable thread-safe. Relies on SymbolTableEntry already being immutable,
other than the WatchpointSet; but the WatchpointSet already has a righteous
concurrency protocol. So, this patch just protects the SymbolTable's HashMap.

* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::nameForRegister):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addVar):
* runtime/Executable.cpp:
(JSC::ProgramExecutable::addGlobalVar):
* runtime/JSActivation.cpp:
(JSC::JSActivation::getOwnNonIndexPropertyNames):
(JSC::JSActivation::symbolTablePutWithAttributes):
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
(JSC::symbolTablePut):
(JSC::symbolTablePutWithAttributes):
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::SymbolTable):
(JSC::SymbolTable::~SymbolTable):
* runtime/SymbolTable.h:
(JSC::SymbolTable::find):
(JSC::SymbolTable::get):
(JSC::SymbolTable::inlineGet):
(JSC::SymbolTable::begin):
(JSC::SymbolTable::end):
(JSC::SymbolTable::size):
(JSC::SymbolTable::add):
(JSC::SymbolTable::set):
(JSC::SymbolTable::contains):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153132 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=115299

Reviewed by Anders Carlsson.

The compiler often does things like:

1c) Observe something that would imply that a WatchpointSet ought to be invalid

2c) Check that it is invalid

The main thread often does things like:

1m) Fire the watchpoint set

2m) Do some other thing that would cause the compiler to assume that the WatchpointSet
ought to be invalid

An example is structure transitions, where (1c) is the compiler noticing that a
put_by_id inline cache is in a transition state, with the source structure being S;
(2c) is the compiler asserting that S's watchpoint set is invalid; (1m) is the main
thread firing S's watchpoint set before it does the first transition away from S; and
(2m) is the main thread caching the put_by_id transition away from S.

This is totally fine, except that (1c) and (2c), and (1m) and (2m) could be reordered.
Probably, in most cases, this ought to do enough things that the main thread probably
already has some fencing. But the compiler thread definitely doesn't have fencing. In
any case, we should play it safe and just have additional fencing in all of the
relevant places.

We already have some idioms to put load-load and store-store fences in the right
places. But this change just makes WatchpointSet take care of this for us, thus
reducing the chances of us getting this wrong.

* bytecode/Watchpoint.cpp:
(JSC::WatchpointSet::notifyWriteSlow):
* bytecode/Watchpoint.h:
(WatchpointSet):
(JSC::WatchpointSet::isStillValid):
(JSC::WatchpointSet::hasBeenInvalidated):
(JSC::InlineWatchpointSet::hasBeenInvalidated):
(JSC::InlineWatchpointSet::notifyWrite):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153131 268f45cc-cd09-0410-ab3c-d52691b4dbfc

fourthTier: CFA should defend against results seeming inconsistent due to a watchpoint firing during compilation
https://bugs.webkit.org/show_bug.cgi?id=115083

Reviewed by Geoffrey Garen.

This ruggedizes our racyness with respect to watchpoints. We want to be able to assert,
in some places, that a watchpoint-based optimization has only occurred if the
watchpoint set was still valid. But currently we *can* soundly do watchpoint-based
optimizations even for invalid watchpoints, so long as we recorded in the IR that we
had done so; this will then lead to the code being insta-jettisoned after compilation
completes. Obviously, we don't want this to happen often - but we do want to allow it
precisely in the case of watchpoint races.

This adds the ability to assert that we hadn't over-watchpointed ourselves, with and
exemption for races.

* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::setFuturePossibleStructure):
(JSC::DFG::AbstractValue::filterFuturePossibleStructure):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addStructureTransitionCheck):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
* dfg/DFGDesiredWatchpoints.h:
(GenericDesiredWatchpoints):
(JSC::DFG::GenericDesiredWatchpoints::isStillValid):
(JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState):
(JSC::DFG::GenericDesiredWatchpoints::isValidOrMixed):
(JSC::DFG::DesiredWatchpoints::isStillValid):
(JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState):
(JSC::DFG::DesiredWatchpoints::isValidOrMixed):
(DesiredWatchpoints):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::masqueradesAsUndefinedWatchpointIsStillValid):
(Graph):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addLazily):
(JITCompiler):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
(JSC::DFG::SpeculativeJIT::speculationWatchpointForMasqueradesAsUndefined):
(JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
(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::nonSpeculativeNonPeepholeCompareNull):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
(JSC::DFG::SpeculativeJIT::compileObjectEquality):
(JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLState.h:
(State):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153130 268f45cc-cd09-0410-ab3c-d52691b4dbfc

fourthTier: AbstractValue methods that deal with watchpoints should have access to Graph, so that in debug mode, Graph can track the history of watchpoint states and detect races
https://bugs.webkit.org/show_bug.cgi?id=115084

Reviewed by Geoffrey Garen.

The idea is that as part of https://bugs.webkit.org/show_bug.cgi?id=115083, I'll have
Graph record the initial state of a watchpoint at the time that we decide to take
advantage of it; then I will use this to disable any watchpoint-related assertions
in debug mode. Note that this "watchpoint cache" will only be maintained in debug
mode, so there will be no release performance implications. But to do this, I need to
ensure that all of the places that reason about watchpoints have access to Graph.
For example, I'll want AbstractValue::setFuturePossibleStructure to record the state
of the watchpoint in Graph so that subsequent assertions can check if the watchpoint's
state had changed since that decision was made.

* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::initialize):
(JSC::DFG::AbstractState::executeEffects):
(JSC::DFG::AbstractState::mergeStateAtTail):
* dfg/DFGAbstractState.h:
(JSC::DFG::AbstractState::trySetConstant):
* dfg/DFGAbstractValue.cpp: Added.
(DFG):
(JSC::DFG::AbstractValue::setMostSpecific):
(JSC::DFG::AbstractValue::set):
(JSC::DFG::AbstractValue::filter):
(JSC::DFG::AbstractValue::setFuturePossibleStructure):
(JSC::DFG::AbstractValue::filterFuturePossibleStructure):
(JSC::DFG::AbstractValue::dump):
* dfg/DFGAbstractValue.h:
(DFG):
(AbstractValue):
(JSC::DFG::AbstractValue::setType):
(JSC::DFG::AbstractValue::filterByValue):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153129 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=114987

Reviewed by Geoffrey Garen.

This completes the work started by r148570. That patch made it possible to do
Structure::get() without modifying Structure. This patch takes this further, and
makes this thread-safe (for non-uncacheable-dictionaries) via
Structure::getConcurrently(). This method not only doesn't modify Structure, but
also ensures that any concurrent attempts to add to, remove from, or steal the
table from that structure doesn't mess up the result of the call. The call may
return invalidOffset even if a property is *just* about to be added, but it will
never do the reverse: if it returns a property then you can be sure that the
structure really does have that property and always will have it.

* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFromLLInt):
(JSC::GetByIdStatus::computeForChain):
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
* runtime/PropertyMapHashTable.h:
(PropertyTable):
(JSC::PropertyTable::findConcurrently):
(JSC):
(JSC::PropertyTable::add):
(JSC::PropertyTable::remove):
(JSC::PropertyTable::reinsert):
(JSC::PropertyTable::rehash):
* runtime/PropertyTable.cpp:
(JSC::PropertyTable::PropertyTable):
* runtime/Structure.cpp:
(JSC::Structure::findStructuresAndMapForMaterialization):
(JSC::Structure::getConcurrently):
* runtime/Structure.h:
(Structure):
* runtime/StructureInlines.h:
(JSC::Structure::getConcurrently):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153128 268f45cc-cd09-0410-ab3c-d52691b4dbfc

https://bugs.webkit.org/show_bug.cgi?id=114933

Reviewed by Andy Estes.

This makes it easy to get set up for tandem LLVM builds.

* Scripts/copy-webkitlibraries-to-product-directory:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153127 268f45cc-cd09-0410-ab3c-d52691b4dbfc

fourthTier: WebKit's build system should relink JavaScriptCore if LLVM's libraries changed but its headers didn't
https://bugs.webkit.org/show_bug.cgi?id=114926

Source/JavaScriptCore:

Reviewed by Geoffrey Garen.

Use a phony file that includes a phony header to force JavaScriptCore to be relinked
if necessary. The external LLVM-importing scripts will touch the header if the libraries
are known to have changed.

* JavaScriptCore.xcodeproj/project.pbxproj:
* ftl/WebKitLLVMLibraryAnchor.cpp: Added.

Tools:

Reviewed by Geoffrey Garen.

If the LLVM libraries change, then touch a phony header, which will force relink
of JavaScriptCore.

* Scripts/copy-webkitlibraries-to-product-directory:
(unpackIfNecessary):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153126 268f45cc-cd09-0410-ab3c-d52691b4dbfc