2014-07-25 Lucas Forschler <lforschler@apple.com>

Merge r171578

2014-07-24 Brent Fulgham <bfulgham@apple.com>

[Win] Correct build order in JavaScriptCore.submit.sln

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

<rdar://problem/17805592>

Unreviewed build fix.

* JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: Correct build order

such that LLIntDesiredOffset is built prior to the rest of JSC.

2014-07-24 Lucas Forschler <lforschler@apple.com>

Merge r171564

2014-07-24 Mark Lam <mark.lam@apple.com>

JSWrapperMap's jsWrapperForObject() needs to keep weak prototype and constructors from being GCed.

<https://webkit.org/b/135258>

Reviewed by Mark Hahnenberg.

Where needed, we cache the prototype object pointer in a stack local var.

This allows it to be scanned by the GC, and hence be kept alive until

we use it. The constructor object will in turn be kept alive by the

prototype object.

Also added some comments to warn against future code additions that could

regress this issue.

* API/JSWrapperMap.mm:

(-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]):

(-[JSObjCClassInfo reallocateConstructorAndOrPrototype]):

(-[JSObjCClassInfo wrapperForObject:]):

(-[JSObjCClassInfo constructor]):

2014-07-24 Lucas Forschler <lforschler@apple.com>

Merge r171558

2014-07-24 Joseph Pecoraro <pecoraro@apple.com>

JSLock release should only modify the AtomicStringTable if it modified in acquire

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

Reviewed by Darin Adler.

* runtime/JSLock.cpp:

(JSC::JSLock::JSLock):

Initialize the member variable to nullptr.

(JSC::JSLock::willDestroyVM):

Update style to use nullptr instead of 0.

(JSC::JSLock::willReleaseLock):

We should only reset the thread data's atomic string table if

didAcquireLock changed it. m_entryAtomicStringTable will have

been set by didAcquireLock if it changed, or nullptr if it didn't.

This way we are sure we are balanced, regardless of m_vm changes.

2014-07-24 Lucas Forschler <lforschler@apple.com>

Merge r171543

2014-07-24 Mark Hahnenberg <mhahnenberg@apple.com>

Creating a JSGlobalObject with a custom JSClassRef results in a JSProxy with the wrong prototype

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

Reviewed by Geoffrey Garen.

JSGlobalObject::resetPrototype (which is called from JSGlobalContextCreateInGroup) doesn't change its

JSProxy's prototype as well. This results in a JSProxy where no properties in the original prototype

chain (as created from the JSClassRef hierarchy) are accessible. Changing resetPrototype to also change

the JSProxy's prototype fixes the issue.

* API/JSValueRef.cpp:

(JSValueIsObjectOfClass): Also fixed a bug where a JSProxy for a JSGlobalObject with a custom JSClassRef

would claim it wasn't of the specified class, even if the target was of the specified class.

* API/tests/CustomGlobalObjectClassTest.c: Added.

(jsDoSomething):

(customGlobalObjectClassTest):

* API/tests/CustomGlobalObjectClassTest.h: Added.

* API/tests/testapi.c:

(assertTrue):

(main):

* JavaScriptCore.vcxproj/testapi/testapi.vcxproj:

* JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:

* JavaScriptCore.xcodeproj/project.pbxproj:

* runtime/JSGlobalObject.cpp:

(JSC::JSGlobalObject::resetPrototype):

2014-07-24 Lucas Forschler <lforschler@apple.com>

Merge r171395

2014-07-22 Brent Fulgham <bfulgham@apple.com>

Build fix for non-clang compile.

* jsc.cpp:

(WTF::RuntimeArray::put): Remove incorrect return statement

I added.

2014-07-24 Lucas Forschler <lforschler@apple.com>

Merge r171393

2014-07-22 Brent Fulgham <bfulgham@apple.com>

Build fix for non-clang compile.

* jsc.cpp:

(WTF::RuntimeArray::deleteProperty): Need (fake) return

value when NO_RETURN_DUE_TO_CRASH is not defined.

2014-07-24 Lucas Forschler <lforschler@apple.com>

Merge r171390

2014-07-22 Mark Lam <mark.lam@apple.com>

Array.concat() should work on runtime arrays too.

<https://webkit.org/b/135179>

Reviewed by Geoffrey Garen.

* jsc.cpp:

(WTF::RuntimeArray::create):

(WTF::RuntimeArray::~RuntimeArray):

(WTF::RuntimeArray::destroy):

(WTF::RuntimeArray::getOwnPropertySlot):

(WTF::RuntimeArray::getOwnPropertySlotByIndex):

(WTF::RuntimeArray::put):

(WTF::RuntimeArray::deleteProperty):

(WTF::RuntimeArray::getLength):

(WTF::RuntimeArray::createPrototype):

(WTF::RuntimeArray::createStructure):

(WTF::RuntimeArray::finishCreation):

(WTF::RuntimeArray::RuntimeArray):

(WTF::RuntimeArray::lengthGetter):

(GlobalObject::finishCreation):

(functionCreateRuntimeArray):

- Added support to create a runtime array for testing purpose.

* runtime/ArrayPrototype.cpp:

(JSC::getLength):

- Added fast case for when the array object is a JSArray.

(JSC::arrayProtoFuncJoin):

- Added a needed but missing exception check.

(JSC::arrayProtoFuncConcat):

- Use getLength() to compute the array length instead of assuming that

the array is a JSArray instance.

* tests/stress/regexp-matches-array.js: Added.

(testArrayConcat):

* tests/stress/runtime-array.js: Added.

(testArrayConcat):

2014-07-24 Lucas Forschler <lforschler@apple.com>

Merge r171328

2014-07-21 Mark Lam <mark.lam@apple.com>

Refactor ArrayPrototype to use getLength() and putLength() utility functions.

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

Reviewed by Oliver Hunt.

- Specialize putProperty() to putLength() because it is only used for setting

the length property.

- Added a getLength() utility function to get the value of the length property.

- Use these getLength() and putLength() functions instead of the existing code

to get and put the length property. Less code to read, easier to understand.

* runtime/ArrayPrototype.cpp:

(JSC::getLength):

(JSC::putLength):

(JSC::arrayProtoFuncToString):

(JSC::arrayProtoFuncToLocaleString):

(JSC::arrayProtoFuncJoin):

(JSC::arrayProtoFuncPop):

(JSC::arrayProtoFuncPush):

(JSC::arrayProtoFuncReverse):

(JSC::arrayProtoFuncShift):

(JSC::arrayProtoFuncSlice):

(JSC::arrayProtoFuncSort):

(JSC::arrayProtoFuncSplice):

(JSC::arrayProtoFuncUnShift):

(JSC::arrayProtoFuncReduce):

(JSC::arrayProtoFuncReduceRight):

(JSC::arrayProtoFuncIndexOf):

(JSC::arrayProtoFuncLastIndexOf):

(JSC::putProperty): Deleted.

2014-07-23 Matthew Hanson <matthew_hanson@apple.com>

Merge r171474 (rollout r171367 from trunk)

2014-07-23 Lucas Forschler <lforschler@apple.com>

Merge r171367

2014-07-22 Joseph Pecoraro <pecoraro@apple.com>

JSLock release should only modify the AtomicStringTable if it modified in acquire

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

Reviewed by Pratik Solanki.

* runtime/JSLock.cpp:

(JSC::JSLock::willDestroyVM):

(JSC::JSLock::willReleaseLock):

Only set the AtomicStringTable when there was a VM, to balance JSLock::didAcquireLock.

2014-07-23 Lucas Forschler <lforschler@apple.com>

Merge r171355

2014-07-21 Sam Weinig <sam@webkit.org>

[Cocoa] WKScriptMessageHandlers don't seem to function properly after navigating

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

Reviewed by Geoffrey Garen.

* runtime/CommonIdentifiers.h:

Add a common identifier for the string "webkit".

2014-07-23 Lucas Forschler <lforschler@apple.com>

Merge r171354

2014-07-22 Filip Pizlo <fpizlo@apple.com>

ASSERTION FAILED: info.spillFormat() & DataFormatJS in JSC::DFG::SpeculativeJIT::fillSpeculateCell

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

<rdar://problem/17763909>

Reviewed by Oliver Hunt.

The DFG fillSpeculate code paths all need to be mindful of the fact that they may be stumbling upon a

contradiction, and that this is OK. In this case, we were speculating cell on an int.

* dfg/DFGSpeculativeJIT64.cpp:

(JSC::DFG::SpeculativeJIT::fillSpeculateCell):

* tests/stress/regress-135155.js: Added.

(run.t.length):

(run):

2014-07-22 Dana Burkart <dburkart@apple.com>

Merge r171228.

2014-07-18 Filip Pizlo <fpizlo@apple.com>

Fix cloop build.

* jsc.cpp:

(jscmain):

2014-07-22 Dana Burkart <dburkart@apple.com>

Merge r171213.

2014-07-15 Filip Pizlo <fpizlo@apple.com>

Need ability to fuzz exception throwing

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

<rdar://problem/17722027>

Reviewed by Sam Weinig.

Adds the ability to instrument exception checks, and to force some random

exception check to artificially throw an exception. Also adds new tests that

are suitable for testing this. Note that this is closely tied to the Tools

directory changes that are also part of this changeset.

This also fixes an activation tear-off bug that arises if we ever throw an

exception from operationOptimize, or if due to some other bug it's only due

to the operationOptimize exception check that we realize that there is an

exception to be thrown.

* dfg/DFGJITCompiler.h:

(JSC::DFG::JITCompiler::fastExceptionCheck):

* ftl/FTLIntrinsicRepository.h:

* ftl/FTLLowerDFGToLLVM.cpp:

(JSC::FTL::LowerDFGToLLVM::callCheck):

* interpreter/Interpreter.cpp:

(JSC::unwindCallFrame):

* jit/AssemblyHelpers.cpp:

(JSC::AssemblyHelpers::callExceptionFuzz):

(JSC::AssemblyHelpers::emitExceptionCheck):

* jit/AssemblyHelpers.h:

(JSC::AssemblyHelpers::emitExceptionCheck): Deleted.

* jit/JIT.cpp:

(JSC::JIT::privateCompileMainPass):

* jit/JITOpcodes.cpp:

(JSC::JIT::emit_op_enter):

* jit/JITOperations.cpp:

(JSC::numberOfExceptionFuzzChecks):

* jit/JITOperations.h:

* jsc.cpp:

(jscmain):

* runtime/Options.h:

* runtime/TestRunnerUtils.h:

* tests/exceptionFuzz.yaml: Added.

* tests/exceptionFuzz: Added.

* tests/exceptionFuzz/3d-cube.js: Added.

* tests/exceptionFuzz/date-format-xparb.js: Added.

* tests/exceptionFuzz/earley-boyer.js: Added.

2014-07-22 Dana Burkart <dburkart@apple.com>

Merge r171204.

2014-07-17 Joseph Pecoraro <pecoraro@apple.com>

Follow-up fix to r171195 to prevent ASSERT in fast/profiler/profile-with-no-title.html

Rubber-stamped by Alexey Proskuryakov.

Null / empty titles should be fine. Tests pass in release builds

which allowed empty titles, and it looks like the LegacyProfiler

stopProfiling handles empty titles as expected already.

* profiler/LegacyProfiler.cpp:

(JSC::LegacyProfiler::startProfiling):

2014-07-22 Dana Burkart <dburkart@apple.com>

Merge r171190.

2014-07-16 Filip Pizlo <fpizlo@apple.com>

DFG Flush(SetLocal) store elimination is overzealous for captured variables in the presence of nodes that have no effects but may throw

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

<rdar://problem/17706349>

Reviewed by Oliver Hunt.

Luckily, we also don't need this optimization to be super powerful: the only place

where it really matters is for getting rid of the redundancy between op_enter and

op_init_lazy_reg, and in that case, there is a small set of possible nodes between the

two things. This change updates the store eliminator to know about only that small,

obviously safe, set of nodes over which we can store-eliminate.

This shouldn't have any performance impact in the DFG because this optimization kicks

in relatively rarely already. And once we tier up into the FTL, we get a much better

store elimination over LLVM IR, so this really shouldn't matter at all.

The tricky part of this patch is that there is a close relative of this optimization,

for uncaptured variables that got flushed. This happens for arguments to inlined calls.

I make this work by splitting it into two different store eliminators.

Note that in the process of crafting the tests, I realized that we were incorrectly

DCEing NewArrayWithSize. That's not cool, since that can throw an exception for

negative array sizes. If we ever did want to DCE this node, we'd need to lower the node

to a check node followed by the actual allocation.

* dfg/DFGCSEPhase.cpp:

(JSC::DFG::CSEPhase::uncapturedSetLocalStoreElimination):

(JSC::DFG::CSEPhase::capturedSetLocalStoreElimination):

(JSC::DFG::CSEPhase::setLocalStoreElimination):

(JSC::DFG::CSEPhase::performNodeCSE):

(JSC::DFG::CSEPhase::SetLocalStoreEliminationResult::SetLocalStoreEliminationResult): Deleted.

* dfg/DFGNodeType.h:

* tests/stress/capture-escape-and-throw.js: Added.

(foo.f):

(foo):

* tests/stress/new-array-with-size-throw-exception-and-tear-off-arguments.js: Added.

(foo):

(bar):

2014-07-17 Dean Jackson <dino@apple.com>

<rdar://problem/17675068> Disable some features on this branch.

Reviewed originally by Simon Fraser.

Disable:

- CSS_EXCLUSIONS

- CSS_GRID_LAYOUT

- INPUT_TYPE_COLOR

- INPUT_TYPE_COLOR_POPUP

- CANVAS_PATH

- CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED

- INDIE_UI

- SHARED_WORKERS

- NAVIGATOR_HWCONCURRENCY

- GAMEPAD

- PICTURE_SIZES

- CSS3_CONDITIONAL_RULES

- WILL_REVEAL_EDGE_EVENTS

* Configurations/FeatureDefines.xcconfig:

2014-07-15 Benjamin Poulain <benjamin@webkit.org>

Reduce the overhead of updating the AssemblerBuffer

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

Reviewed by Gavin Barraclough.

In r164548, the linker was changed to allow the LinkBuffer to survive its MacroAssembler.

That feature is useful for JSC to get offsets inside a linked buffer in order to jump directly

there.

On ARM, we use branch compaction and we need to keep the "compaction offset" somewher to be able

to get the real address of a lable. That is done by reusing the memory of AssemblerData.

To share the memory between LinkBuffer and the Assembler, r164548 moved the AssemblerData into

a ref-counted object. Unfortunately, the extra complexity related to the new AssemblerData was enough

to make clang give up a bunch of optimizations.

This patch solve (some of) the problems by making AssemblerBuffer and AssemblerData super low overhead structures.

In particular, the grow() function becomes 8 Thumb instructions, which is easily inlined everywhere it is used.

Instead of sharing ownership between the Assembler and LinkBuffer, LinkBuffer now takes full ownership of

the AssemblerData. I feel this is also safer since LinkBuffer is reusing the AssemblerData is a very

specific way that would make it unusable for the Assembler.

-- Technical details --

From LinkBuffer, we don't want to ever access the Assembler after releasing its buffer (or writting anything

into it really). This was obviously already the case, but that was hard to prove from LinkBuffer::copyCompactAndLinkCode().

To make this easier to work with, I changed all the assembler specific function to be static. This way we know

exactly what code access the Assembler instance. The code that does access the instance is then moved

at the beginning, before we modify anything.

The function recordLinkOffsets() that was on the MacroAssembler and copied in Assembler was moved directly

to LinkBuffer. This make the modification of AssemblerData completely explicit, and that code is specific

to LinkBuffer anyway (see LinkBuffer::executableOffsetFor()).

-- Perf impact --

This does not put us exactly at before r164548 due to the missing inline buffer. Still, it is very close.

On ARMv7, this reduces the time spent in Assembler by half. On the CSS JIT, this reduces the compilation

time by ~20%.

I could not measure any difference on x86_64.

* assembler/ARM64Assembler.h:

(JSC::ARM64Assembler::jumpSizeDelta):

(JSC::ARM64Assembler::canCompact):

(JSC::ARM64Assembler::computeJumpType):

(JSC::ARM64Assembler::link):

(JSC::ARM64Assembler::recordLinkOffsets): Deleted.

* assembler/ARMv7Assembler.h:

(JSC::ARMv7Assembler::ifThenElseConditionBit):

(JSC::ARMv7Assembler::ifThenElse):

(JSC::ARMv7Assembler::jumpSizeDelta):

(JSC::ARMv7Assembler::canCompact):

(JSC::ARMv7Assembler::computeJumpType):

(JSC::ARMv7Assembler::link):

(JSC::ARMv7Assembler::linkJumpT1):

(JSC::ARMv7Assembler::linkJumpT3):

(JSC::ARMv7Assembler::linkConditionalJumpT4):

(JSC::ARMv7Assembler::linkConditionalBX):

(JSC::ARMv7Assembler::recordLinkOffsets): Deleted.

* assembler/AssemblerBuffer.h:

(JSC::AssemblerData::AssemblerData):

(JSC::AssemblerData::operator=):

(JSC::AssemblerData::~AssemblerData):

(JSC::AssemblerData::buffer):

(JSC::AssemblerData::capacity):

(JSC::AssemblerData::grow):

(JSC::AssemblerBuffer::AssemblerBuffer):

(JSC::AssemblerBuffer::isAvailable):

(JSC::AssemblerBuffer::data):

(JSC::AssemblerBuffer::releaseAssemblerData):

(JSC::AssemblerBuffer::putIntegral):

(JSC::AssemblerBuffer::putIntegralUnchecked):

(JSC::AssemblerBuffer::append):

(JSC::AssemblerBuffer::grow):

(JSC::AssemblerBuffer::~AssemblerBuffer): Deleted.

(JSC::AssemblerBuffer::storage): Deleted.

* assembler/LinkBuffer.cpp:

(JSC::recordLinkOffsets):

(JSC::LinkBuffer::copyCompactAndLinkCode):

* assembler/LinkBuffer.h:

(JSC::LinkBuffer::LinkBuffer):

(JSC::LinkBuffer::executableOffsetFor):

* assembler/MacroAssemblerARM64.h:

(JSC::MacroAssemblerARM64::canCompact):

(JSC::MacroAssemblerARM64::computeJumpType):

(JSC::MacroAssemblerARM64::jumpSizeDelta):

(JSC::MacroAssemblerARM64::link):

(JSC::MacroAssemblerARM64::recordLinkOffsets): Deleted.

* assembler/MacroAssemblerARMv7.h:

(JSC::MacroAssemblerARMv7::canCompact):

(JSC::MacroAssemblerARMv7::computeJumpType):

(JSC::MacroAssemblerARMv7::jumpSizeDelta):

(JSC::MacroAssemblerARMv7::link):

(JSC::MacroAssemblerARMv7::recordLinkOffsets): Deleted.

2014-07-15 Mark Hahnenberg <mhahnenberg@apple.com>

Stores to PropertyTable use the Structure as the owner

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

Reviewed by Darin Adler.

Since PropertyTable is the object that does the marking of these references, it should be the owner.

Also removed some unused parameters to other methods that historically used the Structure as the owner.

* runtime/JSPropertyNameIterator.h:

(JSC::StructureRareData::setEnumerationCache):

* runtime/ObjectPrototype.cpp:

(JSC::objectProtoFuncToString):

* runtime/PropertyMapHashTable.h:

(JSC::PropertyTable::copy):

* runtime/PropertyTable.cpp:

(JSC::PropertyTable::clone):

(JSC::PropertyTable::PropertyTable):

* runtime/Structure.cpp:

(JSC::Structure::Structure):

(JSC::Structure::materializePropertyMap):

(JSC::Structure::addPropertyTransition):

(JSC::Structure::changePrototypeTransition):

(JSC::Structure::despecifyFunctionTransition):

(JSC::Structure::attributeChangeTransition):

(JSC::Structure::toDictionaryTransition):

(JSC::Structure::preventExtensionsTransition):

(JSC::Structure::takePropertyTableOrCloneIfPinned):

(JSC::Structure::nonPropertyTransition):

(JSC::Structure::copyPropertyTable):

(JSC::Structure::copyPropertyTableForPinning):

(JSC::Structure::putSpecificValue):

* runtime/Structure.h:

(JSC::Structure::setObjectToStringValue):

(JSC::Structure::setPreviousID):

* runtime/StructureInlines.h:

(JSC::Structure::setEnumerationCache):

* runtime/StructureRareData.h:

* runtime/StructureRareDataInlines.h:

(JSC::StructureRareData::setPreviousID):

(JSC::StructureRareData::setObjectToStringValue):

2014-07-15 Mark Hahnenberg <mhahnenberg@apple.com>

ScriptExecutable::forEachCodeBlock can dereference null CodeBlocks

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

Reviewed by Andreas Kling.

* bytecode/CodeBlock.h:

(JSC::ScriptExecutable::forEachCodeBlock): Check for null CodeBlocks before calling forEachRelatedCodeBlock.

2014-07-15 Eva Balazsfalvi <evab.u-szeged@partner.samsung.com>

Buildfix if LLINT_SLOW_PATH_TRACING is enabled

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

Reviewed by Mark Lam.

* llint/LLIntSlowPaths.cpp:

(JSC::LLInt::LLINT_SLOW_PATH_DECL):

2014-07-14 Filip Pizlo <fpizlo@apple.com>

Allow for Int52Rep to see things other than Int32, and make this testable

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

<rdar://problem/17641915>

Reviewed by Geoffrey Garen and Mark Hahnenberg.

A major premise of our type inference is that prediction propagation can say whatever it

wants and we'll still have valid IR after Fixup. This previously didn't work with Int52s.

We required some kind of agreement between prediction propagation and fixup over which

data flow paths were Int52 and which weren't.

It turns out that we basically had such an agreement, with the exception of code that was

unreachable due to ForceOSRExit. Then, fixup and prediction propagation would disagree. It

might be nice to fix that bug - but it's only in the case of Int52 that such a thing would

be a bug! Normally, we allow sloppiness in prediction propagation.

This patch allows us to be sloppy with Int52 prediction propagation by giving Int52Rep the

ability to see inputs other than Int32. This fixes the particular ForceOSRExit bug (see

int52-force-osr-exit-path.js for the reduced test case). To make sure that the newly

empowered Int52Rep is actually correct - in case we end up using it on paths other than

ForceOSRExit - this patch introduces an internal intrinsic called fiatInt52() that forces

us to attempt Int52 conversion on the input. This patch adds a bunch of tests that stress

this intrinsic. This means that we're now stressing Int52Rep more so than ever before!

Note that it would still be a bug for prediction propagation to ever cause us to create an

Int52Rep node for a non-Int32 input. But, this will now be a performance bug, rather than

a crash bug.

* dfg/DFGAbstractInterpreterInlines.h:

(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

* dfg/DFGAbstractValue.cpp:

(JSC::DFG::AbstractValue::fixTypeForRepresentation):

* dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::handleIntrinsic):

* dfg/DFGClobberize.h:

(JSC::DFG::clobberize):

* dfg/DFGFixupPhase.cpp:

(JSC::DFG::FixupPhase::fixupNode):

(JSC::DFG::FixupPhase::injectTypeConversionsForEdge):

* dfg/DFGGraph.h:

(JSC::DFG::Graph::isMachineIntConstant):

* dfg/DFGNode.h:

(JSC::DFG::Node::isMachineIntConstant):

* dfg/DFGNodeType.h:

* dfg/DFGOperations.cpp:

* dfg/DFGOperations.h:

* dfg/DFGPredictionPropagationPhase.cpp:

(JSC::DFG::PredictionPropagationPhase::propagate):

* dfg/DFGSafeToExecute.h:

(JSC::DFG::SafeToExecuteEdge::operator()):

(JSC::DFG::safeToExecute):

* dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::SpeculativeJIT::speculate):

* dfg/DFGSpeculativeJIT.h:

(JSC::DFG::SpeculativeJIT::callOperation):

* dfg/DFGSpeculativeJIT32_64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

* dfg/DFGSpeculativeJIT64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

(JSC::DFG::SpeculativeJIT::convertMachineInt):

(JSC::DFG::SpeculativeJIT::speculateMachineInt):

(JSC::DFG::SpeculativeJIT::speculateDoubleRepMachineInt):

* dfg/DFGStrengthReductionPhase.cpp:

(JSC::DFG::StrengthReductionPhase::handleNode):

* dfg/DFGUseKind.cpp:

(WTF::printInternal):

* dfg/DFGUseKind.h:

(JSC::DFG::typeFilterFor):

(JSC::DFG::isNumerical):

(JSC::DFG::isDouble):

* dfg/DFGValidate.cpp:

(JSC::DFG::Validate::validate):

* ftl/FTLCapabilities.cpp:

(JSC::FTL::canCompile):

* ftl/FTLIntrinsicRepository.h:

* ftl/FTLLowerDFGToLLVM.cpp:

(JSC::FTL::LowerDFGToLLVM::compileInt52Rep):

(JSC::FTL::LowerDFGToLLVM::doubleToInt32):

(JSC::FTL::LowerDFGToLLVM::jsValueToDouble):

(JSC::FTL::LowerDFGToLLVM::jsValueToStrictInt52):

(JSC::FTL::LowerDFGToLLVM::doubleToStrictInt52):

(JSC::FTL::LowerDFGToLLVM::speculate):

(JSC::FTL::LowerDFGToLLVM::speculateMachineInt):

(JSC::FTL::LowerDFGToLLVM::speculateDoubleRepMachineInt):

* jit/JITOperations.h:

* jsc.cpp:

(GlobalObject::finishCreation):

(functionIdentity):

* runtime/Intrinsic.h:

* runtime/JSCJSValue.h:

* runtime/JSCJSValueInlines.h:

(JSC::tryConvertToInt52):

(JSC::isInt52):

(JSC::JSValue::isMachineInt):

* tests/stress/dead-fiat-double-to-int52-then-exit-not-int52.js: Added.

(foo):

* tests/stress/dead-fiat-double-to-int52.js: Added.

(foo):

* tests/stress/dead-fiat-int32-to-int52.js: Added.

(foo):

* tests/stress/dead-fiat-value-to-int52-double-path.js: Added.

(foo):

(bar):

* tests/stress/dead-fiat-value-to-int52-then-exit-not-double.js: Added.

(foo):

(bar):

* tests/stress/dead-fiat-value-to-int52-then-exit-not-int52.js: Added.

(foo):

(bar):

* tests/stress/dead-fiat-value-to-int52.js: Added.

(foo):

(bar):

* tests/stress/fiat-double-to-int52-then-exit-not-int52.js: Added.

(foo):

* tests/stress/fiat-double-to-int52-then-fail-to-fold.js: Added.

(foo):

* tests/stress/fiat-double-to-int52-then-fold.js: Added.

(foo):

* tests/stress/fiat-double-to-int52.js: Added.

(foo):

* tests/stress/fiat-int32-to-int52.js: Added.

(foo):

* tests/stress/fiat-value-to-int52-double-path.js: Added.

(foo):

(bar):

* tests/stress/fiat-value-to-int52-then-exit-not-double.js: Added.

(foo):

(bar):

* tests/stress/fiat-value-to-int52-then-exit-not-int52.js: Added.

(foo):

(bar):

* tests/stress/fiat-value-to-int52-then-fail-to-fold.js: Added.

(foo):

* tests/stress/fiat-value-to-int52-then-fold.js: Added.

(foo):

* tests/stress/fiat-value-to-int52.js: Added.

(foo):

(bar):

* tests/stress/int52-force-osr-exit-path.js: Added.

(foo):

2014-07-14 Mark Hahnenberg <mhahnenberg@apple.com>

Flattening dictionaries with oversize backing stores can cause crashes

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

Reviewed by Filip Pizlo.

The collector expects any pointers into CopiedSpace passed to copyLater are within 32 KB

of the CopiedBlock header. This was always the case except for when flattening a dictionary

caused the size of the Butterfly to decrease. This was equivalent to moving the base of the

Butterfly to higher addresses. If the object was reduced sufficiently in size, the base

would no longer be within the first 32 KB of the CopiedBlock and the next collection would

choke on the Butterfly pointer.

This patch fixes this issue by detect this situation during flattening and memmove-ing

the Butterfly down to where the old base was.

* runtime/JSObject.cpp:

(JSC::JSObject::shiftButterflyAfterFlattening):

* runtime/JSObject.h:

(JSC::JSObject::butterflyPreCapacity):

(JSC::JSObject::butterflyTotalSize):

* runtime/Structure.cpp:

(JSC::Structure::flattenDictionaryStructure):

* tests/stress/flatten-oversize-dictionary-object.js: Added.

(foo):

2014-07-14 Benjamin Poulain <benjamin@webkit.org>

Remove some dead code from FTLJITFinalizer

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

Reviewed by Geoffrey Garen.

Not sure what that code was for...but it does not do anything :)

* ftl/FTLJITFinalizer.cpp:

(JSC::FTL::JITFinalizer::finalizeFunction):

The pointer of the label is computed but never used.

* ftl/FTLJITFinalizer.h:

* ftl/FTLLink.cpp:

(JSC::FTL::link):

The label is never set to anything.

2014-07-14 Bear Travis <betravis@adobe.com>

[Feature Queries] Enable Feature Queries on Mac

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

Reviewed by Antti Koivisto.

Enable Feature Queries on Mac and resume running the

feature tests.

* Configurations/FeatureDefines.xcconfig: Turn on

ENABLE_CSS3_CONDITIONAL_RULES.

2014-07-11 Joseph Pecoraro <pecoraro@apple.com>

Web Inspector: Debugger Pause button does not work

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

Reviewed by Timothy Hatcher.

* CMakeLists.txt:

* DerivedSources.make:

Minification strips the sourceURL command. Add it back with minification.

2014-07-11 peavo@outlook.com <peavo@outlook.com>

[Win] Enable DFG JIT.

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

Reviewed by Mark Lam.

When the return type of a JIT generated function call is larger than 64-bit (e.g. SlowPathReturnType),

the normal call() implementation cannot be used on 64-bit Windows, because the 64-bit Windows ABI is different in this case.

Also, when generating calls with double arguments, we need to make sure the arguments are put in the correct registers,

since the register allocation differs on 64-bit Windows.

* assembler/MacroAssemblerX86_64.h:

(JSC::MacroAssemblerX86_64::callWithSlowPathReturnType): Added method to handle function calls where the return value type size is larger than 64-bit.

* jit/CCallHelpers.h:

(JSC::CCallHelpers::setupArgumentsWithExecState): Move arguments to correct registers when there are floating point arguments.

(JSC::CCallHelpers::setupArgumentsWithExecStateForCallWithSlowPathReturnType): Added method.

* jit/JIT.h:

(JSC::JIT::appendCallWithSlowPathReturnType): Added method.

* jit/JITInlines.h:

(JSC::JIT::appendCallWithExceptionCheckAndSlowPathReturnType): Added method.

(JSC::JIT::callOperation): Call new method.

2014-07-09 Benjamin Poulain <benjamin@webkit.org>

Use 16bits instructions for push/pop on ARMv7 when possible

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

Reviewed by Geoffrey Garen.

The patch r170839 mixed the code for push/pop pair and single push/pop.

That part was reverted in r170909.

This patch puts the code back but specialized for single push/pop.

* assembler/ARMv7Assembler.h:

(JSC::ARMv7Assembler::pop):

(JSC::ARMv7Assembler::push):

* assembler/MacroAssemblerARMv7.h:

(JSC::MacroAssemblerARMv7::pop):

(JSC::MacroAssemblerARMv7::push):

2014-07-09 Brent Fulgham <bfulgham@apple.com>

[Win] Remove uses of 'bash' in build system

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

<rdar://problem/17615533>

Reviewed by Dean Jackson.

Remove uses of 'bash' by replacing Windows-specific bash scripts

with Perl equivalents.

* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:

* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:

* JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj.filters:

* JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd:

* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:

* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:

* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl: Copied from Source/JavaScriptCore/JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh.

* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh: Removed.

* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:

* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:

* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl: Copied from Source/JavaScriptCore/JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh.

* JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Removed.

* JavaScriptCore.vcxproj/build-generated-files.pl: Copied from Source/JavaScriptCore/JavaScriptCore.vcxproj/build-generated-files.sh.

* JavaScriptCore.vcxproj/build-generated-files.sh: Removed.

* JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd:

* JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd:

* JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd:

2014-07-09 Brent Fulgham <bfulgham@apple.com>

[Win] Remove use of 'grep' in build steps

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

<rdar://problem/17608783>

Reviewed by Tim Horton.

Replace uses of the grep command in Windows builds with the equivalent

Perl program.

* JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd:

* JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd:

* JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd:

* JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd:

2014-07-08 Benjamin Poulain <benjamin@webkit.org>

Restore the assertion changed with 170839

* assembler/ARMv7Assembler.h:

(JSC::ARMv7Assembler::pop):

(JSC::ARMv7Assembler::push):

Revert the Assembler part of 170839. The assertions do not match both encoding.

I'll add specific version of push and pop instead.

2014-07-08 Jon Honeycutt <jhoneycutt@apple.com>

RemoteInspector::shared() should not call WTF::initializeMainThread()

<https://bugs.webkit.org/show_bug.cgi?id=134747>

<rdar://problem/17161482>

Reviewed by Joseph Pecoraro.

* inspector/remote/RemoteInspector.mm:

(Inspector::RemoteInspector::shared):

Don't call WTF::initializeMainThread(). WTF threading is initialized by

JSC::initializeThreading().

2014-07-08 Andreas Kling <akling@apple.com>

VM::lastCachedString should be a Strong, not a Weak.

<https://webkit.org/b/134746>

Using Weak<JSString> for this regressed some of our bindings perf tests

due to Weak having to allocate a new WeakImpl every time the last cached

string changed. Make it a Strong instead should make that problem go away.

Reviewed by Geoffrey Garen.

* runtime/JSString.cpp:

(JSC::jsStringWithCacheSlowCase):

* runtime/VM.h:

2014-07-07 Benjamin Poulain <bpoulain@apple.com>

Fix the build after r170876

* assembler/LinkBuffer.cpp:

(JSC::LinkBuffer::linkCode):

2014-07-07 Benjamin Poulain <benjamin@webkit.org>

LinkBuffer should not keep a reference to the MacroAssembler

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

Reviewed by Geoffrey Garen.

In FTL, the LinkBuffer can outlive the MacroAssembler that was used for code generation.

When that happens, the pointer m_assembler points to released memory. That was not causing

issues because the attribute is not used after linking, but that was not particularily

future proof.

This patch refactors LinkBuffer to avoid any lifetime risk. The MacroAssembler is now passed

as a reference, it is used for linking but no reference is ever stored with the LinkBuffer.

While fixing the call sites to use a reference, I also discovered LinkBuffer.h was included

everywhere. I refactored some #include to avoid that.

* assembler/LinkBuffer.cpp:

(JSC::LinkBuffer::copyCompactAndLinkCode):

(JSC::LinkBuffer::linkCode):

* assembler/LinkBuffer.h:

(JSC::LinkBuffer::LinkBuffer):

* bytecode/Watchpoint.cpp:

* dfg/DFGDisassembler.cpp:

* dfg/DFGDisassembler.h:

* dfg/DFGJITCompiler.cpp:

(JSC::DFG::JITCompiler::link):

(JSC::DFG::JITCompiler::linkFunction):

* dfg/DFGOSRExitCompiler.cpp:

* dfg/DFGPlan.cpp:

* dfg/DFGThunks.cpp:

(JSC::DFG::osrExitGenerationThunkGenerator):

(JSC::DFG::osrEntryThunkGenerator):

* ftl/FTLCompile.cpp:

(JSC::FTL::generateICFastPath):

(JSC::FTL::fixFunctionBasedOnStackMaps):

* ftl/FTLJSCall.cpp:

* ftl/FTLJSCall.h:

* ftl/FTLLink.cpp:

(JSC::FTL::link):

* ftl/FTLLowerDFGToLLVM.cpp:

* ftl/FTLOSRExitCompiler.cpp:

(JSC::FTL::compileStub):

* ftl/FTLThunks.cpp:

(JSC::FTL::osrExitGenerationThunkGenerator):

(JSC::FTL::slowPathCallThunkGenerator):

* jit/ArityCheckFailReturnThunks.cpp:

(JSC::ArityCheckFailReturnThunks::returnPCsFor):

* jit/JIT.cpp:

(JSC::JIT::privateCompile):

* jit/JITCall.cpp:

(JSC::JIT::privateCompileClosureCall):

* jit/JITCall32_64.cpp:

(JSC::JIT::privateCompileClosureCall):

* jit/JITDisassembler.cpp:

* jit/JITDisassembler.h:

* jit/JITOpcodes.cpp:

* jit/JITPropertyAccess.cpp:

(JSC::JIT::stringGetByValStubGenerator):

(JSC::JIT::privateCompileGetByVal):

(JSC::JIT::privateCompilePutByVal):

* jit/JITPropertyAccess32_64.cpp:

(JSC::JIT::stringGetByValStubGenerator):

* jit/RegisterPreservationWrapperGenerator.cpp:

(JSC::generateRegisterPreservationWrapper):

(JSC::registerRestorationThunkGenerator):

* jit/Repatch.cpp:

(JSC::generateByIdStub):

(JSC::tryCacheGetByID):

(JSC::emitPutReplaceStub):

(JSC::emitPutTransitionStub):

(JSC::tryRepatchIn):

(JSC::linkClosureCall):

* jit/SpecializedThunkJIT.h:

(JSC::SpecializedThunkJIT::finalize):

* jit/ThunkGenerators.cpp:

(JSC::throwExceptionFromCallSlowPathGenerator):

(JSC::linkForThunkGenerator):

(JSC::linkClosureCallForThunkGenerator):

(JSC::virtualForThunkGenerator):

(JSC::nativeForGenerator):

(JSC::arityFixup):

* llint/LLIntThunks.cpp:

(JSC::LLInt::generateThunkWithJumpTo):

* yarr/YarrJIT.cpp:

(JSC::Yarr::YarrGenerator::compile):

2014-07-07 Andreas Kling <akling@apple.com>

Fast path for jsStringWithCache() when asked for the same string repeatedly.

<https://webkit.org/b/134635>