Generate derived files in ANGLE at build time rather than when updating from upstream.
https://bugs.webkit.org/show_bug.cgi?id=118872

Reviewed by Mark Rowe.

* ANGLE.xcodeproj/project.pbxproj: Made Derived Sources target which calls DerivedSources.make,
moved generated files into Derived Sources group.
* DerivedSources.make: Added.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153101 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Use-after-free in ApplyStyleCommand::removeInlineStyle
https://bugs.webkit.org/show_bug.cgi?id=118627

Reviewed by Oliver Hunt.
        
Merge https://chromium.googlesource.com/chromium/blink/+/b6471d077e012b05ccba14d0ce8e6d616106c8e6

Unfortunately, there is no test case for this bug.

* editing/ApplyStyleCommand.cpp:
(WebCore::ApplyStyleCommand::removeInlineStyle):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153102 268f45cc-cd09-0410-ab3c-d52691b4dbfc
It should be possible to hijack IndexingHeader for things other than lengths
https://bugs.webkit.org/show_bug.cgi?id=119065

Reviewed by Mark Hahnenberg.
        
Made the body of IndexingHeader be a union.
        
Modified the offlineasm so that you can say IndexingHeader::u.lengths.publicLength.
Previously those dots would cause parse errors. Now an identifier in offlineasm can
have a dot anywhere except the first character.

* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/parser.rb:
* runtime/IndexingHeader.h:
(JSC::IndexingHeader::offsetOfPublicLength):
(JSC::IndexingHeader::offsetOfVectorLength):
(JSC::IndexingHeader::IndexingHeader):
(JSC::IndexingHeader::vectorLength):
(JSC::IndexingHeader::setVectorLength):
(JSC::IndexingHeader::publicLength):
(JSC::IndexingHeader::setPublicLength):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153104 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r152335): Mac Pro title occluded in MobileSafari; can't scroll page
https://bugs.webkit.org/show_bug.cgi?id=119066
<rdar://problem/14499184>

Reviewed by Daniel Bates.

Following <http://trac.webkit.org/changeset/152335> (bug #118337) we set
the z-index to 0 on every element with CSS "overflow: scroll" and
"-webkit-overflow-scrolling: touch" regardless of whether the element has
non-auto z-index. Instead we should only set the z-index to 0 for such elements
that have an auto z-index.

* css/StyleResolver.cpp:
(WebCore::StyleResolver::adjustRenderStyle):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153105 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2][Soup] Add entry point for network process
https://bugs.webkit.org/show_bug.cgi?id=110136

Reviewed by Gustavo Noronha Silva.

Original patch by Balazs Kelemen <kbalazs@webkit.org>.

Added a common entry point for non-Mac Unix ports.

* NetworkProcess/unix/NetworkProcessMainUnix.cpp: Added.
(WebKit::NetworkProcessMain):
* NetworkProcess/unix/NetworkProcessMainUnix.h: Added.
* unix/NetworkMainUnix.cpp: Added.
(main):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153106 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Crash when calling WKPageGetProcessIdentifier after aborted process launch
https://bugs.webkit.org/show_bug.cgi?id=119069
<rdar://problem/14494064>

Reviewed by Andreas Kling.

Source/WebKit2:

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::processIdentifier):
Check if the page is closed instead of checking whether we have a process - We'll always have a process.

(WebKit::WebPageProxy::isValid):
Make this const.

* UIProcess/WebPageProxy.h:

Tools:

Add a test.

* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WebKit2/mac/GetPIDAfterAbortedProcessLaunch.cpp: Added.
(TestWebKitAPI::didFinishLoadForFrame):
(TestWebKitAPI::TEST):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153107 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rename WebColorChooserProxy
<rdar://problem/14528039> and https://bugs.webkit.org/show_bug.cgi?id=119025

Reviewed by Brady Eidson.

Renamed WebColorChooserProxy to WebColorPicker since the name WebColorChoooserProxy
implies that it represents the same object as WebColorChooser, which is not true.
Also, renamed createColorChooserProxy to createColorPicker in WebPageProxy and
platform-equivalent versions of it.

* CMakeLists.txt:
* GNUmakefile.list.am:
* Target.pri:
* UIProcess/API/gtk/PageClientImpl.cpp:
(WebKit::PageClientImpl::createColorPicker):
* UIProcess/API/gtk/PageClientImpl.h:
* UIProcess/API/mac/PageClientImpl.h:
* UIProcess/API/mac/PageClientImpl.mm:
(WebKit::PageClientImpl::createColorPicker):
* UIProcess/API/qt/raw/qrawwebview.cpp:
(QRawWebViewPrivate::createColorPicker):
* UIProcess/API/qt/raw/qrawwebview_p_p.h:
* UIProcess/CoordinatedGraphics/WebView.cpp:
(WebKit::WebView::createColorPicker):
* UIProcess/CoordinatedGraphics/WebView.h:
* UIProcess/PageClient.h:
* UIProcess/WebColorChooserProxy.cpp: Removed.
* UIProcess/WebColorChooserProxy.h: Removed.
* UIProcess/WebColorPicker.cpp: Copied from Source/WebKit2/UIProcess/WebColorChooserProxy.cpp.
(WebKit::WebColorPicker::WebColorPicker):
(WebKit::WebColorPicker::~WebColorPicker):
(WebKit::WebColorPicker::endChooser):
(WebKit::WebColorPicker::setSelectedColor):
* UIProcess/WebColorPicker.h: Copied from Source/WebKit2/UIProcess/WebColorChooserProxy.h.
(WebKit::WebColorPicker::create):
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::close):
(WebKit::WebPageProxy::showColorChooser):
(WebKit::WebPageProxy::setColorChooserColor):
(WebKit::WebPageProxy::endColorChooser):
(WebKit::WebPageProxy::didEndColorChooser):
(WebKit::WebPageProxy::resetStateAfterProcessExited):
* UIProcess/WebPageProxy.h: Renamed m_colorChooser to m_colorPicker.
* UIProcess/qt/QtPageClient.cpp:
(WebKit::QtPageClient::createColorPicker):
* UIProcess/qt/QtPageClient.h:
* UIProcess/qt/WebColorChooserProxyQt.cpp: Removed.
* UIProcess/qt/WebColorChooserProxyQt.h: Removed.
* UIProcess/qt/WebColorPickerQt.cpp: Added.
(WebKit::ColorChooserContextObject::ColorChooserContextObject):
(WebKit::ColorChooserContextObject::currentColor):
(WebKit::ColorChooserContextObject::elementRect):
(WebKit::ColorChooserContextObject::accept):
(WebKit::ColorChooserContextObject::reject):
(WebKit::WebColorPickerQt::WebColorPickerQt):
(WebKit::WebColorPickerQt::~WebColorPickerQt):
(WebKit::WebColorPickerQt::createItem):
(WebKit::WebColorPickerQt::createContext):
(WebKit::WebColorPickerQt::setSelectedColor):
(WebKit::WebColorPickerQt::notifyColorSelected):
(WebKit::WebColorPickerQt::endChooser):
* UIProcess/qt/WebColorPickerQt.h: Added.
(WebKit::WebColorPickerQt::create):
* WebKit2.xcodeproj/project.pbxproj:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153108 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add DRT test to ensure don't override z-index for overflow: scroll, -webkit-overflow-scrolling: touch
https://bugs.webkit.org/show_bug.cgi?id=119071

Reviewed by Simon Fraser.

Add a DRT test to ensure we don't regress the fix for <https://bugs.webkit.org/show_bug.cgi?id=119066>.

* compositing/overflow/should-not-override-z-index-for-element-with-non-auto-z-index-and-overflow-scroll-and-touch-expected.txt: Added.
* compositing/overflow/should-not-override-z-index-for-element-with-non-auto-z-index-and-overflow-scroll-and-touch.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153111 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] Captions are clipped in documents using pagination
https://bugs.webkit.org/show_bug.cgi?id=119072

Reviewed by Beth Dakin.

MediaControlTextTrackContainerElement::createTextTrackRepresentationImage() is called
to paint captions into a layer used for fullscreen video. It did the painting using
a subtree paint, but starting at the root RenderView's layer. This is problematic,
because the caption painting is subject to clipping for columns, and any enclosing
overflow:hidden container.

Fix this by starting the paint at the MediaControlTextTrackContainerElement's
renderer's layer. By doing this we don't have to worry about an offset, so no
translation is required.

Also make sure we update layer before grabbing the renderer (in case layout
destroys it).

* html/shadow/MediaControlElements.cpp:
(WebCore::MediaControlTextTrackContainerElement::createTextTrackRepresentationImage):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153112 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: JITCode should abstract exactly how the JIT code is structured and where it was allocated
https://bugs.webkit.org/show_bug.cgi?id=113437

Reviewed by Mark Hahnenberg.

JITCode is now a virtual base class, which will allow different JITs to have radically
different memory allocation and management conventions in the future. It will also
make it easier to store JIT-specific meta-data in CodeBlock just by putting it into
an appropriate JITCode subclass.

For now there is one subclass, DirectJITCode, which just behaves like JITCode used to
behave.

* assembler/RepatchBuffer.h:
(JSC::RepatchBuffer::RepatchBuffer):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::resetStubInternal):
(JSC::CodeBlock::bytecodeOffset):
(JSC::CodeBlock::codeOriginForReturn):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::getJITCode):
(JSC::CodeBlock::getJITType):
(CodeBlock):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGDriver.h:
(DFG):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JITCompiler):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::codeLocationForRepatch):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOperations.cpp:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
* jit/JIT.cpp:
(JSC::JIT::privateCompile):
* jit/JIT.h:
(JSC::JIT::compile):
(JIT):
* jit/JITCode.cpp:
(JSC):
(JSC::JITCode::JITCode):
(JSC::JITCode::~JITCode):
(JSC::JITCode::execute):
(JSC::JITCode::hostFunction):
(JSC::DirectJITCode::DirectJITCode):
(JSC::DirectJITCode::~DirectJITCode):
(JSC::DirectJITCode::addressForCall):
(JSC::DirectJITCode::executableAddressAtOffset):
(JSC::DirectJITCode::dataAddressAtOffset):
(JSC::DirectJITCode::offsetOf):
(JSC::DirectJITCode::size):
(JSC::DirectJITCode::contains):
* jit/JITCode.h:
(JSC):
(JITCode):
(JSC::JITCode::bottomTierJIT):
(JSC::JITCode::topTierJIT):
(JSC::JITCode::nextTierJIT):
(JSC::JITCode::isOptimizingJIT):
(JSC::JITCode::isBaselineCode):
(JSC::JITCode::jitType):
(JSC::JITCode::jitTypeFor):
(JSC::JITCode::executableAddress):
(JSC::JITCode::start):
(JSC::JITCode::end):
(DirectJITCode):
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* jit/JITStubs.cpp:
(JSC::lazyLinkFor):
(JSC::DEFINE_STUB_FUNCTION):
* jit/ThunkGenerators.cpp:
(JSC::virtualForGenerator):
* llint/LLIntEntrypoints.cpp:
(JSC::LLInt::getFunctionEntrypoint):
(JSC::LLInt::getEvalEntrypoint):
(JSC::LLInt::getProgramEntrypoint):
* llint/LLIntEntrypoints.h:
(JSC):
(LLInt):
(JSC::LLInt::getEntrypoint):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::jitCompileAndSetHeuristics):
(JSC::LLInt::entryOSR):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/Executable.cpp:
(JSC::EvalExecutable::compileInternal):
(JSC::ProgramExecutable::compileInternal):
(JSC::FunctionExecutable::compileForCallInternal):
(JSC::FunctionExecutable::compileForConstructInternal):
* runtime/Executable.h:
(JSC::ExecutableBase::generatedJITCodeForCall):
(JSC::ExecutableBase::generatedJITCodeForConstruct):
(JSC::ExecutableBase::generatedJITCodeFor):
(ExecutableBase):
(JSC::ExecutableBase::hostCodeEntryFor):
(JSC::ExecutableBase::jsCodeEntryFor):
(JSC::ExecutableBase::jsCodeWithArityCheckEntryFor):
(JSC::NativeExecutable::create):
(JSC::NativeExecutable::finishCreation):
(JSC::EvalExecutable::generatedJITCode):
(JSC::ProgramExecutable::generatedJITCode):
* runtime/ExecutionHarness.h:
(JSC::prepareForExecution):
(JSC::prepareFunctionForExecution):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153113 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: DFG should abstract out how it does forward exits, and that code should be simplified
https://bugs.webkit.org/show_bug.cgi?id=113894

Reviewed by Mark Hahnenberg.

1) We previously had two different ways of convertingToForward, one path for
   where we had a ValueRecovery for the current node and one where we didn't.
   But the paths were doing exactly the same thing except that if you have a
   ValueRecovery, you also find the last applicable mov hint and do some
   extra things. This patch combines the two paths and bases both of them on
   the previous no-ValueRecovery path, which was simpler to begin with.

2) This moves the logic into DFG::OSRExit, which further simplifies the code
   and makes the logic available to the FTL.

* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::convertToForward):
(DFG):
* dfg/DFGOSRExit.h:
(DFG):
(OSRExit):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153114 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: Everyone should know about the FTL
https://bugs.webkit.org/show_bug.cgi?id=113897

Reviewed by Mark Hahnenberg.

In order to get OSR exit to work right, we need the distinction between DFG and
FTL to be clear even after compilation finishes, since they will have subtly
different OSR stories and likely use different data structures.

* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::resetStubInternal):
(JSC::ProgramCodeBlock::compileOptimized):
(JSC::EvalCodeBlock::compileOptimized):
(JSC::FunctionCodeBlock::compileOptimized):
(JSC::CodeBlock::adjustedExitCountThreshold):
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::hasOptimizedReplacement):
(JSC::ExecState::isInlineCallFrame):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::JITCode):
* ftl/FTLState.cpp:
(JSC::FTL::State::dumpState):
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::jettison):
* interpreter/Interpreter.cpp:
(JSC::getLineNumberForCallFrame):
(JSC::getCallerInfo):
* jit/JITCode.cpp:
(WTF::printInternal):
* jit/JITCode.h:
(JSC::JITCode::topTierJIT):
(JSC::JITCode::nextTierJIT):
(JITCode):
(JSC::JITCode::isJIT):
(JSC::JITCode::isLowerTier):
(JSC::JITCode::isHigherTier):
(JSC::JITCode::isLowerOrSameTier):
(JSC::JITCode::isHigherOrSameTier):
(JSC::JITCode::isOptimizingJIT):
* jit/JITDriver.h:
(JSC::jitCompileIfAppropriate):
(JSC::jitCompileFunctionIfAppropriate):
* jit/JITStubs.cpp:
(JSC::DEFINE_STUB_FUNCTION):
* runtime/Executable.cpp:
(JSC::EvalExecutable::compileOptimized):
(JSC::samplingDescription):
(JSC::ProgramExecutable::compileOptimized):
(JSC::FunctionExecutable::compileOptimizedForCall):
(JSC::FunctionExecutable::compileOptimizedForConstruct):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153115 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data into something accessible from both DFG::JITCode and FTL::JITCode
https://bugs.webkit.org/show_bug.cgi?id=113905

Reviewed by Geoffrey Garen.

This removes one pointer from CodeBlock.

It also gives us a framework for having JITType-specific data in CodeBlock, by
putting it into the appropriate JITCode class (either DFG::JITCode or
FTL::JITCode). And it allows us to have DFG and FTL share some common data,
via DFG::CommonData, which is stored in both DFG::JITCode and FTL::JITCode and
always accessible via JITCode::dfgCommon().

* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* bytecode/CodeBlock.cpp:
(JSC):
(JSC::CodeBlock::dumpBytecode):
(JSC::CodeBlock::visitAggregate):
(JSC::CodeBlock::performTracingFixpointIteration):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::stronglyVisitWeakReferences):
(JSC::CodeBlock::shrinkToFit):
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::setJITCode):
(JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
(JSC::DFGCodeBlocks::mark):
* dfg/DFGAssemblyHelpers.h:
* dfg/DFGCommonData.cpp: Added.
(DFG):
(JSC::DFG::CommonData::notifyCompilingStructureTransition):
(JSC::DFG::CommonData::shrinkToFit):
* dfg/DFGCommonData.h: Added.
(JSC):
(DFG):
(JSC::DFG::WeakReferenceTransition::WeakReferenceTransition):
(WeakReferenceTransition):
(CommonData):
(JSC::DFG::CommonData::CommonData):
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGDriver.h:
(DFG):
(JSC::DFG::tryCompile):
(JSC::DFG::tryCompileFunction):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGJITCode.cpp: Added.
(DFG):
(JSC::DFG::JITCode::JITCode):
(JSC::DFG::JITCode::~JITCode):
(JSC::DFG::JITCode::dfgCommon):
(JSC::DFG::JITCode::dfg):
(JSC::DFG::JITCode::shrinkToFit):
* dfg/DFGJITCode.h: Added.
(DFG):
(JITCode):
(JSC::DFG::JITCode::appendOSREntryData):
(JSC::DFG::JITCode::osrEntryDataForBytecodeIndex):
(JSC::DFG::JITCode::appendOSRExit):
(JSC::DFG::JITCode::lastOSRExit):
(JSC::DFG::JITCode::appendSpeculationRecovery):
(JSC::DFG::JITCode::appendWatchpoint):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::JITCompiler):
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGJITCompiler.h:
(JITCompiler):
(JSC::DFG::JITCompiler::addWeakReference):
(JSC::DFG::JITCompiler::noticeOSREntry):
(JSC::DFG::JITCompiler::jitCode):
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOSRExit.h:
(OSRExit):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::backwardSpeculationCheck):
(JSC::DFG::SpeculativeJIT::speculationWatchpoint):
(JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGVariableEventStream.cpp:
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::JITCode):
(JSC::FTL::JITCode::~JITCode):
(FTL):
(JSC::FTL::JITCode::initializeCode):
(JSC::FTL::JITCode::addressForCall):
(JSC::FTL::JITCode::executableAddressAtOffset):
(JSC::FTL::JITCode::dataAddressAtOffset):
(JSC::FTL::JITCode::offsetOf):
(JSC::FTL::JITCode::size):
(JSC::FTL::JITCode::contains):
(JSC::FTL::JITCode::ftl):
(JSC::FTL::JITCode::dfgCommon):
* ftl/FTLJITCode.h:
(JITCode):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint):
(JSC::FTL::LowerDFGToLLVM::compilePutStructure):
(JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):
(JSC::FTL::LowerDFGToLLVM::addWeakReference):
(LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::weakPointer):
* ftl/FTLState.cpp:
(FTL):
(JSC::FTL::State::State):
(JSC::FTL::State::dumpState):
* ftl/FTLState.h:
(State):
* heap/DFGCodeBlocks.cpp:
(JSC::DFGCodeBlocks::~DFGCodeBlocks):
(JSC::DFGCodeBlocks::jettison):
(JSC::DFGCodeBlocks::clearMarks):
(JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
(JSC::DFGCodeBlocks::traceMarkedCodeBlocks):
* jit/JITCode.cpp:
(JSC::JITCode::dfgCommon):
(JSC):
(JSC::JITCode::dfg):
(JSC::JITCode::ftl):
(JSC::DirectJITCode::DirectJITCode):
(JSC::DirectJITCode::initializeCodeRef):
(JSC::DirectJITCode::addressForCall):
(JSC::DirectJITCode::executableAddressAtOffset):
(JSC::DirectJITCode::dataAddressAtOffset):
(JSC::DirectJITCode::offsetOf):
(JSC::DirectJITCode::size):
(JSC::DirectJITCode::contains):
* jit/JITCode.h:
(DFG):
(FTL):
(JSC):
(JITCode):
(DirectJITCode):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153116 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: DFG should better abstract arguments
https://bugs.webkit.org/show_bug.cgi?id=114073

Reviewed by Mark Hahnenberg.

* dfg/DFGGPRInfo.h:
(GPRInfo):
(JSC::DFG::GPRInfo::toArgumentRegister):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153117 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: DFG should better abstract floating point arguments
https://bugs.webkit.org/show_bug.cgi?id=114300

Reviewed by Mark Hahnenberg.

* dfg/DFGFPRInfo.h:
(FPRInfo):
(JSC::DFG::FPRInfo::toArgumentRegister):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153118 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: DFG should provide utilities for common OSR exit tasks
https://bugs.webkit.org/show_bug.cgi?id=114306

Reviewed by Mark Hahnenberg.

Just abstract out some things that the FTL will want to use as well.

* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Target.pri:
* dfg/DFGDriver.cpp:
(JSC::DFG::compile):
* dfg/DFGOSRExitCompiler.cpp:
* dfg/DFGOSRExitCompiler.h:
(OSRExitCompiler):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompilerCommon.cpp: Added.
(DFG):
(JSC::DFG::handleExitCounts):
(JSC::DFG::reifyInlinedCallFrames):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitCompilerCommon.h: Added.
(DFG):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153119 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: DFG should be able to query Structure without modifying it
https://bugs.webkit.org/show_bug.cgi?id=114708

Reviewed by Oliver Hunt.

This is work towards allowing the DFG, and FTL, to run on a separate thread.
The idea is that the most evil thing that the DFG does that has thread-safety
issues is fiddling with Structures by calling Structure::get(). This can lead
to rematerialization of property tables, which is definitely not thread-safe
due to how StringImpl works. So, this patch completely side-steps the problem
by creating a new version of Structure::get, called
Structure::getWithoutMaterializing, which may choose to do an O(n) search if
necessary to avoid materialization. I believe this should be fine - the DFG
does't call into these code path often enough for this to matter, and most of
the time, the Structure that we call this on will already have a property
table because some inline cache would have already called ::get() on that
Structure.

Also cleaned up the materialization logic: we can stop the search as soon as
we find any Structure with a property table rather than searching all the way
for a pinned one.

* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
* runtime/Structure.cpp:
(JSC::Structure::findStructuresAndMapForMaterialization):
(JSC::Structure::materializePropertyMap):
(JSC::Structure::getWithoutMaterializing):
(JSC):
* runtime/Structure.h:
(Structure):
* runtime/StructureInlines.h:
(JSC::Structure::getWithoutMaterializing):
(JSC):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153120 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: Landing the initial FTL logic in a single commit to avoid spurious
broken builds.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153121 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: all inline caches should thread-safe enough to allow a concurrent compilation thread to read them safely
https://bugs.webkit.org/show_bug.cgi?id=114762

Source/JavaScriptCore:

Reviewed by Mark Hahnenberg.

For most inline caches this is easy: the inline cache has a clean temporal
separation between doing the requested action (which may take an unbounded
amount of time, may recurse, and may do arbitrary things) and recording the
relevant information in the cache. So, we just put locks around the
recording bit. That part is always O(1) and does not recurse. The lock we
use is per-CodeBlock to achieve a good balance between locking granularity
and low space overhead. So a concurrent compilation thread will only block
if an inline cache ping-pongs in the code block being compiled (or inlined)
and never when other inline caches do things.

For resolve operations, it's a bit tricky. The global resolve bit works
like any other IC in that it has the clean temporal separation. But the
operations vector itself doesn't have this separation, since we will be
filling it in tandem with actions that may take a long time. This patch
gets around this by having a m_ready bit in the ResolveOperations and
PutToBaseOperation. This is set while holding the CodeBlock's lock. If the
DFG observes the m_ready bit not set (while holding the lock) then it
conservatively assumes that the resolve hasn't happened yet and just
plants a ForceOSRExit.

* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
* bytecode/CodeBlock.h:
(CodeBlock):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecode/ResolveGlobalStatus.cpp:
(JSC::ResolveGlobalStatus::computeFor):
* bytecode/ResolveOperation.h:
(JSC::ResolveOperations::ResolveOperations):
(ResolveOperations):
(JSC::PutToBaseOperation::PutToBaseOperation):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
* jit/JITStubs.cpp:
(JSC::tryCachePutByID):
(JSC::tryCacheGetByID):
(JSC::DEFINE_STUB_FUNCTION):
(JSC::lazyLinkFor):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setUpCall):
* runtime/JSScope.cpp:
(JSC::JSScope::resolveContainingScopeInternal):
(JSC::JSScope::resolveContainingScope):
(JSC::JSScope::resolvePut):

Source/WTF:

Reviewed by Mark Hahnenberg.

Implemented a new spinlock that is optimized for compactness, by using just a byte.
This will be useful as we start using fine-grained locking on a bunch of places.

At some point I'll make these byte-sized spinlocks into adaptive mutexes, but for
now I think it's fine to do the evil thing and use spinning particularly since we
only use them for short critical sections.

* WTF.xcodeproj/project.pbxproj:
* wtf/Atomics.h:
(WTF):
(WTF::weakCompareAndSwap):
* wtf/ByteSpinLock.h: Added.
(WTF):
(ByteSpinLock):
(WTF::ByteSpinLock::ByteSpinLock):
(WTF::ByteSpinLock::lock):
(WTF::ByteSpinLock::unlock):
(WTF::ByteSpinLock::isHeld):
* wtf/ThreadingPrimitives.h:
(WTF::pauseBriefly):
(WTF):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153122 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: value profiles and array profiles should be thread-safe enough to be accessible in a concurrent compilation thread
https://bugs.webkit.org/show_bug.cgi?id=114906

Source/JavaScriptCore:

Reviewed by Oliver Hunt.

This introduces thread safety to value profiles, array profiles, and
array allocation profiles.

We already have three separate operations that happen on profiles:
(1) writing, which the JIT, LLInt, and OSR exit do; (2) updating,
which happens during GC, from OSR entry slow-paths, and in the DFG;
and (3) reading, which happens in the DFG. For example, the JIT/LLInt
and OSR exit write to ValueProfile::m_buckets, which gets synthesized
into ValueProfile::m_prediction (and other fields) during update, and
the latter gets read by the DFG. Note that (2) must also happen in
the DFG since only the DFG knows which code blocks it will inline,
and those blocks' profiles may not have otherwise been updated via
any other mechanism.

I refer to these three operations as writing, updating, and reading.

Consequently, both profile updating and profile reading may happen
asynchronously, if the JIT is asynchronous.

The locking protocol for profiles works as follows:

- Writing does not require locking, but is only allowed on the main
  thread. We require that these fields can be stored atomically by
  the profiling code, even without locks. For value profiles, this
  only works on 64-bit platforms, currently. For array profiles,
  which consist of multiple separate fields, this means that an
  asynchronous update of the profile may see slight inconsistencies
  (like a structure that doesn't quite match the array modes bits),
  but these should be harmless: at worst, the DFG will specialize
  too much and we'll have OSR exits.

- Updating a value profile requires holding a lock, but must assume
  that the fields written by the profiling code in JIT/LLInt may
  be written to without locking.

- Reading a value profile requires holding a lock.

The one major exception to these rules is the ArrayAllocationProfile,
which requires no locking. We do this because it's used so often and
in places where we don't necessarily have access to the owning
CodeBlock, so if we did want it to be locked it would have to have
its own lock. Also, I believe that it is sound to just make this
profile racy and not worry about locking at all. All that was needed
were some changes to ensure that we explicitly read some raced-over
fields only once.

Two additional interesting things in this change:

- To make it easy to see which profile methods require locking, they
  take a const CodeBlockLocker& as an argument. I saw this idiom for
  identifying which methods require which locks to be held being used
  in LLVM, and I quite like it.

- Lazy operand value profiles, which are created lazily and at any
  time, require the CodeBlockLock to be held when they are being
  created. Writes to them are lockless and main-thread-only, but as
  with other profiles, updates and reads require locking.

* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ArrayAllocationProfile.cpp:
(JSC::ArrayAllocationProfile::updateIndexingType):
* bytecode/ArrayAllocationProfile.h:
(JSC::ArrayAllocationProfile::selectIndexingType):
* bytecode/ArrayProfile.cpp:
(JSC::ArrayProfile::computeUpdatedPrediction):
(JSC::ArrayProfile::briefDescription):
* bytecode/ArrayProfile.h:
(ArrayProfile):
(JSC::ArrayProfile::expectedStructure):
(JSC::ArrayProfile::structureIsPolymorphic):
(JSC::ArrayProfile::hasDefiniteStructure):
(JSC::ArrayProfile::observedArrayModes):
(JSC::ArrayProfile::mayInterceptIndexedAccesses):
(JSC::ArrayProfile::mayStoreToHole):
(JSC::ArrayProfile::outOfBounds):
(JSC::ArrayProfile::usesOriginalArrayStructures):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFor):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpValueProfiling):
(JSC::CodeBlock::dumpArrayProfiling):
(JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
(JSC::CodeBlock::updateAllArrayPredictions):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
(JSC::CodeBlock::updateAllPredictionsAndCheckIfShouldOptimizeNow):
(CodeBlock):
* bytecode/CodeBlockLock.h: Added.
(JSC):
* bytecode/GetByIdStatus.cpp:
(JSC::GetByIdStatus::computeFor):
* bytecode/LazyOperandValueProfile.cpp:
(JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
(JSC::CompressedLazyOperandValueProfileHolder::add):
(JSC::LazyOperandValueProfileParser::LazyOperandValueProfileParser):
(JSC::LazyOperandValueProfileParser::~LazyOperandValueProfileParser):
(JSC):
(JSC::LazyOperandValueProfileParser::initialize):
(JSC::LazyOperandValueProfileParser::prediction):
* bytecode/LazyOperandValueProfile.h:
(CompressedLazyOperandValueProfileHolder):
(LazyOperandValueProfileParser):
* bytecode/MethodOfGettingAValueProfile.cpp:
(JSC::MethodOfGettingAValueProfile::getSpecFailBucket):
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFor):
* bytecode/ResolveGlobalStatus.cpp:
(JSC::ResolveGlobalStatus::computeFor):
* bytecode/ValueProfile.h:
(JSC::ValueProfileBase::briefDescription):
(ValueProfileBase):
(JSC::ValueProfileBase::computeUpdatedPrediction):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::fromObserved):
* dfg/DFGArrayMode.h:
(ArrayMode):
(JSC::DFG::ArrayMode::withProfile):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
(JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
(JSC::DFG::ByteCodeParser::getArrayMode):
(JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
(JSC::DFG::ByteCodeParser::parseResolveOperations):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOSRExitPreparation.cpp:
(JSC::DFG::prepareCodeOriginForOSRExit):
* dfg/DFGPredictionInjectionPhase.cpp:
(JSC::DFG::PredictionInjectionPhase::run):
* jit/JITInlines.h:
(JSC::JIT::chooseArrayMode):
* jit/JITStubs.cpp:
(JSC::tryCachePutByID):
(JSC::tryCacheGetByID):
(JSC::DEFINE_STUB_FUNCTION):
(JSC::lazyLinkFor):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setUpCall):
* profiler/ProfilerBytecodeSequence.cpp:
(JSC::Profiler::BytecodeSequence::BytecodeSequence):
* runtime/JSScope.cpp:
(JSC::JSScope::resolveContainingScopeInternal):
(JSC::JSScope::resolvePut):

Source/WTF:

Reviewed by Oliver Hunt.

Add ability to abstract whether or not the CodeBlock requires locking at all,
since some platforms may not support the byte spin-locking and/or may not want
to, if they turn off concurrent JIT.

* WTF.xcodeproj/project.pbxproj:
* wtf/ByteSpinLock.h:
* wtf/NoLock.h: Added.
(WTF):
(NoLock):
(WTF::NoLock::lock):
(WTF::NoLock::unlock):
(WTF::NoLock::isHeld):
* wtf/Platform.h:

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