DFG should have a separate StoreBarrier node
https://bugs.webkit.org/show_bug.cgi?id=125530

Reviewed by Filip Pizlo.

Source/JavaScriptCore: 

This is in preparation for GenGC. We use a separate StoreBarrier node instead of making them implicitly 
part of other nodes so that it's easier to run analyses on them, e.g. for the StoreBarrierElisionPhase. 
They are inserted during the fixup phase. Initially they do not generate any code.

* CMakeLists.txt:
* GNUmakefile.list.am:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
* JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractHeap.h:
* dfg/DFGAbstractInterpreter.h:
(JSC::DFG::AbstractInterpreter::isKnownNotCell):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberizeForAllocation):
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants): Whenever we insert new nodes that require StoreBarriers,
we have to add those new StoreBarriers too. It's important to note that AllocatePropertyStorage and 
ReallocatePropertyStorage nodes require their StoreBarriers to come after them since they allocate first,
which could cause a GC, and then store the resulting buffer into their JSCell, which requires the barrier.
If we ever require that write barriers occur before stores, we'll have to split these nodes into 
AllocatePropertyStorage + StoreBarrier + PutPropertyStorage.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::insertStoreBarrier):
* dfg/DFGNode.h:
(JSC::DFG::Node::isStoreBarrier):
* dfg/DFGNodeType.h:
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
(JSC::DFG::SpeculativeJIT::compileStoreBarrier):
(JSC::DFG::SpeculativeJIT::genericWriteBarrier): The fast path write barrier check. It loads the 
byte that contains the mark bit of the object. 
(JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): If the fast path check fails we try to store the 
cell in the WriteBarrierBuffer so as to avoid frequently flushing all registers in order to make a C call.
(JSC::DFG::SpeculativeJIT::writeBarrier):
(JSC::DFG::SpeculativeJIT::osrWriteBarrier): More barebones version of the write barrier to be executed 
during an OSR exit into baseline code. We must do this so that the baseline JIT object and array profiles 
are properly cleared during GC.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::writeBarrier):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::cachedPutById):
(JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::writeBarrier):
* dfg/DFGStoreBarrierElisionPhase.cpp: Added. New DFG phase that does block-local elision of redundant
StoreBarriers. Every time a StoreBarrier on a particular object is executed, a bit is set indicating that 
that object doesn't need any more StoreBarriers. 
(JSC::DFG::StoreBarrierElisionPhase::StoreBarrierElisionPhase):
(JSC::DFG::StoreBarrierElisionPhase::couldCauseGC): Nodes that could cause a GC reset the bits for all of the 
objects known in the current block. 
(JSC::DFG::StoreBarrierElisionPhase::allocatesFreshObject): A node that creates a new object automatically 
sets the bit for that object since if a GC occurred as the result of that object's allocation then that 
object would not need a barrier since it would be guaranteed to be a young generation object until the 
next GC point.
(JSC::DFG::StoreBarrierElisionPhase::noticeFreshObject):
(JSC::DFG::StoreBarrierElisionPhase::getBaseOfStore):
(JSC::DFG::StoreBarrierElisionPhase::shouldBeElided):
(JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
(JSC::DFG::StoreBarrierElisionPhase::handleNode):
(JSC::DFG::StoreBarrierElisionPhase::handleBlock):
(JSC::DFG::StoreBarrierElisionPhase::run):
(JSC::DFG::performStoreBarrierElision):
* dfg/DFGStoreBarrierElisionPhase.h: Added.
* heap/Heap.cpp:
(JSC::Heap::Heap):
(JSC::Heap::flushWriteBarrierBuffer):
* heap/Heap.h:
(JSC::Heap::writeBarrier):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::offsetOfMarks):
* heap/WriteBarrierBuffer.cpp: Added. The WriteBarrierBuffer buffers a set of JSCells that are awaiting 
a pending WriteBarrier. This buffer is used by the DFG to avoid the overhead of calling out to C repeatedly
to invoke a write barrier on a single JSCell. Instead the DFG has inline code to fill the WriteBarrier buffer
until its full, and then to call out to C to flush it. The WriteBarrierBuffer will also be flushed prior to 
each EdenCollection.
(JSC::WriteBarrierBuffer::WriteBarrierBuffer):
(JSC::WriteBarrierBuffer::~WriteBarrierBuffer):
(JSC::WriteBarrierBuffer::flush):
(JSC::WriteBarrierBuffer::reset):
(JSC::WriteBarrierBuffer::add):
* heap/WriteBarrierBuffer.h: Added.
(JSC::WriteBarrierBuffer::currentIndexOffset):
(JSC::WriteBarrierBuffer::capacityOffset):
(JSC::WriteBarrierBuffer::bufferOffset):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* runtime/VM.h:

Source/WTF: 

* wtf/Platform.h: Added an #define for ENABLE(GGC) which will be used for landing things related to GenGC.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160796 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK][CMake] Remove binary size optimizations we do not use in the autotools build
https://bugs.webkit.org/show_bug.cgi?id=125947

Reviewed by Martin Robinson.

* Source/cmake/OptionsGTK.cmake: remove the relevant flags.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160797 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WinCairo] Preparation for GStreamer on Windows.
https://bugs.webkit.org/show_bug.cgi?id=125946

Patch by Alex Christensen <achristensen@webkit.org> on 2013-12-18
Reviewed by Brent Fulgham.

Source/WebCore:

* WebCore.vcxproj/WebCore.vcxproj:
Use new GStreamer property sheets for WinCairo.
* WebCore.vcxproj/WebCoreCairo.props:
Include GStreamer directory.

Source/WebKit:

* WebKit.vcxproj/WebKit/WebKit.vcxproj:
Use new GStreamer property sheets for WinCairo.
* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
Fixed 64-bit symbols, added GStreamer symbol.

Source/WTF:

* WTF.vcxproj/WTF.vcxproj:
Use new GStreamer property sheets for WinCairo.

Tools:

* WinLauncher/WinLauncher.vcxproj/WinLauncherLib.vcxproj:
Use new GStreamer property sheets for WinCairo.
* win/DLLLauncher/DLLLauncherMain.cpp:
(modifyPath):
(wWinMain):
Prepend GStreamer bin directory to path if it exists.

WebKitLibraries:

* win/tools/vsprops/FeatureDefinesCairo.props:
Added ENABLE_MEDIA_CONTROLS_SCRIPT and ENABLE_VIDEO_TRACK for DerivedSources.make.
* win/tools/vsprops/GStreamer32.props: Added.
* win/tools/vsprops/GStreamer64.props: Added.
* win/tools/vsprops/GStreamerCommon.props: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160798 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK][CMake] Use thin archives if building on Linux, only way to get non-shared-core debug builds
https://bugs.webkit.org/show_bug.cgi?id=125951

Reviewed by Martin Robinson.

* Source/cmake/OptionsGTK.cmake: append T for thin archives to the flags passed to ar,
also use u, which is used in the autotools build (it avoids adding a file twice).

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160799 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add a simple stack abstraction for x86_64
https://bugs.webkit.org/show_bug.cgi?id=125908

Reviewed by Geoffrey Garen.

Source/JavaScriptCore: 

* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::addPtrNoFlags):
Add an explicit abstraction for the "lea" instruction. This is needed
by the experimental JIT to have add and substract without changing the flags.

This is useful for function calls to test the return value, restore the registers,
then branch on the flags from the return value.

Source/WebCore: 

StackAllocator provides an abstraction to make it hard to make mistakes and protects from obvious
issues at runtime.

The key roles of StackAllocators are:
-Provide the necessary stack alignment for function calls (only x86_64 stack for now).
-Provide ways to save registers on the stack, restore or discard them as needed.
-Crash at runtime if an operation would obviously cause a stack inconsistency.

The way simple inconsistencies are detected is through the StackReference object
returned whenever something is added on the stack.
The object keeps a reference to the offset of what has been pushed. When the StackReference
is used to recover the register, if the offset is different, there is a missmatch between
push() and pop() after the object was pushed.

* cssjit/StackAllocator.h: Added.
(WebCore::StackAllocator::StackReference::StackReference):
(WebCore::StackAllocator::StackReference::operator unsigned):
(WebCore::StackAllocator::StackAllocator):
(WebCore::StackAllocator::~StackAllocator):
(WebCore::StackAllocator::push):
(WebCore::StackAllocator::pop):

(WebCore::StackAllocator::alignStackPreFunctionCall):
(WebCore::StackAllocator::unalignStackPostFunctionCall):
Those helpers provide a simple way to have a valid stack prior to a function call.
Since StackAllocator knows the offset and the platform rules, it can adjust the stack
if needed for x86_64.

(WebCore::StackAllocator::discard): Discard a single register or the full stack.

(WebCore::StackAllocator::combine): combining stacks is the way to solve branches
where the stack is used differently in each case.
To do that, the stack is first copied to A and B. Each branch works on its own
StackAllocator copy, then the two copies are linked together to the original stack.

The copies ensure the local consistency in each branch, linking the copies ensure global
consistencies and that both branches end in the same stack state.

(WebCore::StackAllocator::offsetToStackReference): Helper function to access the stack by address
through its StackReference.

(WebCore::StackAllocator::reset):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160800 268f45cc-cd09-0410-ab3c-d52691b4dbfc
PDFPlugin: Never make a NSEventType = 0
https://bugs.webkit.org/show_bug.cgi?id=125955

Reviewed by Dan Bernstein.

* WebProcess/Plugins/PDF/PDFPlugin.mm:
(WebKit::getEventTypeFromWebEvent):
Make getEventTypeFromWebEvent return its NSEventType as an out arg, and
make the return value represent whether or not we set it.

(WebKit::PDFPlugin::nsEventForWebMouseEvent):
(WebKit::PDFPlugin::handleKeyboardEvent):
Make use of getEventTypeFromWebEvent.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160801 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Shapes] Simplify RectangleShape implementation
https://bugs.webkit.org/show_bug.cgi?id=125536

Reviewed by Andreas Kling.

Instead of caching an instance of a private FloatRoundedRect (ish) class for
RectangleShape's shape-margin and shape-padding bounds, we just compute
the FloatRect and radii as needed. This reduces the classes footprint a little
and it simplifies the implementation.

Removed the private RectangleShape::ShapeBounds class and made its
cornerInterceptForWidth() method a static function. Added members for
the RectangleShape constructor args, and private getters for their properties.

There are no new tests because this is just an internal refactoring.

* rendering/shapes/RectangleShape.cpp:
(WebCore::RectangleShape::shapePaddingBounds):
(WebCore::RectangleShape::shapeMarginBounds):
(WebCore::ellipseXIntercept):
(WebCore::ellipseYIntercept):
(WebCore::RectangleShape::getExcludedIntervals):
(WebCore::RectangleShape::getIncludedIntervals):
(WebCore::cornerInterceptForWidth):
(WebCore::RectangleShape::firstIncludedIntervalLogicalTop):
(WebCore::RectangleShape::buildPath):
* rendering/shapes/RectangleShape.h:
(WebCore::RectangleShape::RectangleShape):
(WebCore::RectangleShape::rx):
(WebCore::RectangleShape::ry):
(WebCore::RectangleShape::x):
(WebCore::RectangleShape::y):
(WebCore::RectangleShape::width):
(WebCore::RectangleShape::height):
* rendering/shapes/Shape.cpp:
(WebCore::createCircleShape): Renamed this internal function (it was createShapeCircle) because it was inconsistent.
(WebCore::createEllipseShape): Ditto.
(WebCore::Shape::createShape):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160802 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=125941
Add Obj C API for injected bundle PageGroup class.

Patch by Yongjun Zhang <yongjun_zhang@apple.com> on 2013-12-18
Reviewed by Dan Bernstein.

Add Obj C API (WKWebProcessPlugInPageGroup) for injected bundle PageGroup class. And add APIs to
expose the main frame and page group from WKWebProcessPlugInBrowsingContextController.

* Shared/Cocoa/APIObject.mm:
(API::Object::newObject): Create wrapper object for InjectedPageGroup object.
* WebKit2.xcodeproj/project.pbxproj:
* WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInPageGroup.h: Added.
* WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInPageGroup.mm: Added.
(-[WKWebProcessPlugInPageGroup identifier]):
(-[WKWebProcessPlugInPageGroup dealloc]):
(-[WKWebProcessPlugInPageGroup API::]):
* WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInPageGroupInternal.h: Added.
(WebKit::wrapper):
* WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.h: Add API to expose the main frame and page group
    for WKWebPocessPlugInBrowserContextController.
* WebProcess/InjectedBundle/API/mac/WKWebProcessPlugInBrowserContextController.mm:
(-[WKWebProcessPlugInBrowserContextController mainFrame]):
(-[WKWebProcessPlugInBrowserContextController pageGroup]):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160803 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] [CMake] Add support for building WebKit1
https://bugs.webkit.org/show_bug.cgi?id=116377

Reviewed by Gustavo Noronha Silva.

.:

* Source/cmake/OptionsGTK.cmake: Turn off some features that do not build properly
for WebKit1 and stop using the version script which we haven't implemented yet. Turn
on WebKit1.

Source/WebCore:

* PlatformGTK.cmake: Add a missing source required by WebKit1 to
the WebCore build.

Source/WebKit:

* CMakeLists.txt: Updated WebCore include directory list for WebKitGTK+ and
added BUILDING_WEBKIT to the list of defines.
* PlatformGTK.cmake: Added.

Source/WebKit/gtk:

* GNUmakefile.am: Switch to using the templates for building the GObject enums.
* webkit/webkitenumtypes.cpp.template: Added.
* webkit/webkitenumtypes.h.template: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160804 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] [CMake] Add support for building GtkLauncher
https://bugs.webkit.org/show_bug.cgi?id=125766

Reviewed by Gustavo Noronha Silva.

* CMakeLists.txt: Add the GtkLauncher subdirectory for the GTK port.
* GtkLauncher/CMakeLists.txt: Added.
* GtkLauncher/main.c: Support including the CMake config file.

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