Source/JavaScriptCore/ChangeLog

   1 2015-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>
   2
   3         [JSC] Generate put_by_val_direct for indexed identifiers instead of put_by_id with direct postfix
   4         https://bugs.webkit.org/show_bug.cgi?id=145360
   5
   6         Reviewed by Darin Adler.
   7
   8         JSObject::putDirect only accepts non-indexed properties.
   9         So when generating put_by_id (with direct postfix) for indexed property,
  10         we should generate put_by_val_direct instead.
  11
  12         * bytecompiler/BytecodeGenerator.cpp:
  13         (JSC::BytecodeGenerator::emitDirectPutById):
  14         * bytecompiler/NodesCodegen.cpp:
  15         (JSC::PropertyListNode::emitPutConstantProperty):
  16         * tests/stress/put-by-id-direct-should-be-done-for-non-index-property.js: Added.
  17
  18 2015-05-24  Jordan Harband  <ljharb@gmail.com>
  19
  20         Array#findIndex/find should not skip holes
  21         https://bugs.webkit.org/show_bug.cgi?id=145361
  22         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.findindex
  23         and https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.find
  24
  25         Reviewed by Yusuke Suzuki.
  26
  27         * builtins/Array.prototype.js:
  28         (find): Deleted.
  29         (findIndex): Deleted.
  30
  31 2015-05-24  Brian J. Burg  <burg@cs.washington.edu>
  32
  33         Web Inspector: Uncaught exception when using Inspect tool on SVG elements
  34         https://bugs.webkit.org/show_bug.cgi?id=145363
  35
  36         Reviewed by Joseph Pecoraro.
  37
  38         The injected script failed by chaining a call to String.prototype.trim to the result of
  39         SVG*Element.className, which is an SVGAnimatedString and lacks useful methods. So, obtain
  40         the class name using Node.getAttribute, which always returns a DOMString.
  41
  42         * inspector/InjectedScriptSource.js:
  43         (InjectedScriptSource.prototype._getDescription): use getAttribute instead of className.
  44
  45 2015-05-23  Dan Bernstein  <mitz@apple.com>
  46
  47         Remove unused definitions of WEBKIT_VERSION_MIN_REQUIRED
  48         https://bugs.webkit.org/show_bug.cgi?id=145345
  49
  50         Reviewed by Sam Weinig.
  51
  52         * Configurations/Base.xcconfig: Also changed to use $(inherited).
  53
  54 2015-05-23  Yusuke Suzuki  <utatane.tea@gmail.com>
  55
  56         Introduce UniquedStringImpl and SymbolImpl to separate symbolic strings from AtomicStringImpl
  57         https://bugs.webkit.org/show_bug.cgi?id=144848
  58
  59         Reviewed by Darin Adler.
  60
  61         Use UniquedStringImpl, SymbolImpl and AtomicStringImpl.
  62
  63         * API/JSCallbackObject.h:
  64         * builtins/BuiltinNames.h:
  65         (JSC::BuiltinNames::isPrivateName):
  66         * bytecode/BytecodeIntrinsicRegistry.h:
  67         * bytecode/CodeBlock.cpp:
  68         (JSC::CodeBlock::CodeBlock):
  69         * bytecode/ComplexGetStatus.cpp:
  70         (JSC::ComplexGetStatus::computeFor):
  71         * bytecode/ComplexGetStatus.h:
  72         * bytecode/GetByIdStatus.cpp:
  73         (JSC::GetByIdStatus::computeFromLLInt):
  74         (JSC::GetByIdStatus::computeFor):
  75         (JSC::GetByIdStatus::computeForStubInfo):
  76         * bytecode/GetByIdStatus.h:
  77         * bytecode/Instruction.h:
  78         (JSC::Instruction::Instruction):
  79         * bytecode/PutByIdStatus.cpp:
  80         (JSC::PutByIdStatus::computeFromLLInt):
  81         (JSC::PutByIdStatus::computeFor):
  82         (JSC::PutByIdStatus::computeForStubInfo):
  83         * bytecode/PutByIdStatus.h:
  84         * bytecompiler/BytecodeGenerator.cpp:
  85         (JSC::BytecodeGenerator::BytecodeGenerator):
  86         (JSC::BytecodeGenerator::visibleNameForParameter):
  87         (JSC::BytecodeGenerator::hasConstant):
  88         (JSC::BytecodeGenerator::addConstant):
  89         * bytecompiler/BytecodeGenerator.h:
  90         * bytecompiler/NodesCodegen.cpp:
  91         (JSC::PropertyListNode::emitBytecode):
  92         * dfg/DFGByteCodeParser.cpp:
  93         (JSC::DFG::ByteCodeParser::parseBlock):
  94         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
  95         * dfg/DFGDesiredIdentifiers.cpp:
  96         (JSC::DFG::DesiredIdentifiers::addLazily):
  97         (JSC::DFG::DesiredIdentifiers::at):
  98         (JSC::DFG::DesiredIdentifiers::reallyAdd):
  99         * dfg/DFGDesiredIdentifiers.h:
 100         (JSC::DFG::DesiredIdentifiers::operator[]):
 101         * dfg/DFGFixupPhase.cpp:
 102         (JSC::DFG::FixupPhase::fixupNode):
 103         (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
 104         * dfg/DFGSpeculativeJIT.cpp:
 105         (JSC::DFG::SpeculativeJIT::compileIn):
 106         * dfg/DFGSpeculativeJIT.h:
 107         (JSC::DFG::SpeculativeJIT::identifierUID):
 108         (JSC::DFG::SpeculativeJIT::callOperation):
 109         * ftl/FTLCompile.cpp:
 110         (JSC::FTL::mmAllocateDataSection):
 111         * ftl/FTLInlineCacheDescriptor.h:
 112         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
 113         (JSC::FTL::InlineCacheDescriptor::uid):
 114         (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
 115         (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
 116         (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
 117         * ftl/FTLIntrinsicRepository.h:
 118         * ftl/FTLLowerDFGToLLVM.cpp:
 119         (JSC::FTL::LowerDFGToLLVM::compilePutById):
 120         (JSC::FTL::LowerDFGToLLVM::compileIn):
 121         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
 122         (JSC::FTL::LowerDFGToLLVM::getById):
 123         * ftl/FTLOperations.cpp:
 124         (JSC::FTL::operationMaterializeObjectInOSR):
 125         * ftl/FTLSlowPathCall.cpp:
 126         (JSC::FTL::callOperation):
 127         * ftl/FTLSlowPathCall.h:
 128         * jit/JIT.h:
 129         * jit/JITInlines.h:
 130         (JSC::JIT::callOperation):
 131         * jit/JITOperations.cpp:
 132         * jit/JITOperations.h:
 133         * parser/Nodes.cpp:
 134         (JSC::ProgramNode::setClosedVariables):
 135         * parser/Nodes.h:
 136         (JSC::ScopeNode::captures):
 137         (JSC::ScopeNode::setClosedVariables):
 138         (JSC::ProgramNode::closedVariables):
 139         * parser/Parser.cpp:
 140         (JSC::Parser<LexerType>::parseInner):
 141         (JSC::Parser<LexerType>::didFinishParsing):
 142         (JSC::Parser<LexerType>::parseContinueStatement):
 143         * parser/Parser.h:
 144         (JSC::Scope::Scope):
 145         (JSC::Scope::pushLabel):
 146         (JSC::Scope::getLabel):
 147         (JSC::Scope::declareCallee):
 148         (JSC::Scope::declareVariable):
 149         (JSC::Scope::declareParameter):
 150         (JSC::Scope::declareBoundParameter):
 151         (JSC::Scope::useVariable):
 152         (JSC::Scope::copyCapturedVariablesToVector):
 153         (JSC::Parser::closedVariables):
 154         (JSC::ScopeLabelInfo::ScopeLabelInfo): Deleted.
 155         * parser/SourceProviderCacheItem.h:
 156         (JSC::SourceProviderCacheItem::usedVariables):
 157         (JSC::SourceProviderCacheItem::writtenVariables):
 158         (JSC::SourceProviderCacheItem::create):
 159         * runtime/CommonIdentifiers.cpp:
 160         (JSC::CommonIdentifiers::isPrivateName):
 161         * runtime/CommonIdentifiers.h:
 162         * runtime/Identifier.h:
 163         (JSC::Identifier::impl):
 164         (JSC::Identifier::Identifier):
 165         (JSC::parseIndex):
 166         (JSC::IdentifierRepHash::hash):
 167         * runtime/IdentifierInlines.h:
 168         (JSC::Identifier::fromUid):
 169         * runtime/IntendedStructureChain.cpp:
 170         (JSC::IntendedStructureChain::mayInterceptStoreTo):
 171         * runtime/IntendedStructureChain.h:
 172         * runtime/JSGlobalObject.cpp:
 173         (JSC::JSGlobalObject::init):
 174         * runtime/Lookup.h:
 175         (JSC::HashTable::entry):
 176         * runtime/MapData.h:
 177         * runtime/ObjectConstructor.cpp:
 178         (JSC::objectConstructorGetOwnPropertySymbols):
 179         * runtime/PrivateName.h:
 180         (JSC::PrivateName::PrivateName):
 181         (JSC::PrivateName::uid):
 182         * runtime/PropertyMapHashTable.h:
 183         * runtime/PropertyName.h:
 184         (JSC::PropertyName::PropertyName):
 185         (JSC::PropertyName::uid):
 186         (JSC::PropertyName::publicName):
 187         (JSC::parseIndex):
 188         * runtime/PropertyNameArray.h:
 189         (JSC::PropertyNameArray::addKnownUnique):
 190         (JSC::PropertyNameArray::add):
 191         * runtime/Structure.cpp:
 192         (JSC::StructureTransitionTable::contains):
 193         (JSC::StructureTransitionTable::get):
 194         (JSC::StructureTransitionTable::add):
 195         (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
 196         (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
 197         (JSC::Structure::getConcurrently):
 198         (JSC::Structure::add):
 199         (JSC::Structure::remove):
 200         (JSC::Structure::toStructureShape):
 201         * runtime/Structure.h:
 202         (JSC::PropertyMapEntry::PropertyMapEntry):
 203         * runtime/StructureInlines.h:
 204         (JSC::Structure::getConcurrently):
 205         * runtime/StructureTransitionTable.h:
 206         (JSC::StructureTransitionTable::Hash::hash):
 207         * runtime/Symbol.cpp:
 208         (JSC::Symbol::Symbol):
 209         * runtime/Symbol.h:
 210         * runtime/SymbolConstructor.cpp:
 211         (JSC::symbolConstructorFor):
 212         (JSC::symbolConstructorKeyFor):
 213         * runtime/SymbolTable.cpp:
 214         (JSC::SymbolTable::uniqueIDForVariable):
 215         (JSC::SymbolTable::globalTypeSetForVariable):
 216         * runtime/SymbolTable.h:
 217         * runtime/TypeSet.cpp:
 218         (JSC::StructureShape::addProperty):
 219         (JSC::StructureShape::propertyHash):
 220         * runtime/TypeSet.h:
 221
 222 2015-05-21  Filip Pizlo  <fpizlo@apple.com>
 223
 224         Arguments elimination phase mishandles arity check failure in its reduction of LoadVarargs to GetStack/PutStacks
 225         https://bugs.webkit.org/show_bug.cgi?id=145298
 226
 227         Reviewed by Geoffrey Garen.
 228
 229         * dfg/DFGArgumentsEliminationPhase.cpp: Fix the bug. I restructured the loop to make it more obvious that we're initializing everything that we're supposed to initialize.
 230         * dfg/DFGNode.h: Add a comment to clarify something I was confused about while writing this code.
 231         * dfg/DFGPutStackSinkingPhase.cpp: Hacking on PutStacks made me think deep thoughts, and I added some FIXMEs.
 232         * tests/stress/fold-load-varargs-arity-check-fail-barely.js: Added. This test crashes or fails before this patch.
 233         * tests/stress/fold-load-varargs-arity-check-fail.js: Added. This is even more sure to crash or fail.
 234         * tests/stress/simplify-varargs-mandatory-minimum-smaller-than-limit.js: Added. Not sure if we had coverage for this case before.
 235
 236 2015-05-22  Basile Clement  <basile_clement@apple.com>
 237
 238         Allow DFGClobberize to return non-node constants that must be later created
 239         https://bugs.webkit.org/show_bug.cgi?id=145272
 240
 241         Reviewed by Filip Pizlo.
 242
 243         This adds a new LazyNode class in DFG that represents either a Node*,
 244         or a FrozenValue* with a way to convert it to a Node* provided a block
 245         to insert it into. DFGClobberize is converted to use LazyNode instead
 246         of Node* when def()'ing values, which allows to now define the array's
 247         length as well as the value of its various fields in NewArray and
 248         NewArrayBuffer nodes.
 249
 250         We also introduce a Vector<uint32_t> in DFG::Graph to collect all the
 251         values that can be used as index, in order to avoid def()'ing too many
 252         values at once for big NewArrayBuffers.
 253
 254         HeapLocation had to be updated to use a LazyNode as its index to be
 255         able to define array values.
 256
 257         * CMakeLists.txt:
 258         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
 259         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
 260         * JavaScriptCore.xcodeproj/project.pbxproj:
 261         * dfg/DFGCSEPhase.cpp:
 262         * dfg/DFGClobberize.h:
 263         (JSC::DFG::clobberize):
 264         (JSC::DFG::DefMethodClobberize::operator()):
 265         * dfg/DFGGraph.cpp:
 266         (JSC::DFG::Graph::freezeFragile):
 267         * dfg/DFGGraph.h:
 268         * dfg/DFGHeapLocation.h:
 269         (JSC::DFG::HeapLocation::HeapLocation):
 270         (JSC::DFG::HeapLocation::index):
 271         (JSC::DFG::HeapLocation::hash):
 272         * dfg/DFGLazyNode.cpp: Added.
 273         (JSC::DFG::LazyNode::dump):
 274         * dfg/DFGLazyNode.h: Added.
 275         (JSC::DFG::LazyNode::LazyNode):
 276         (JSC::DFG::LazyNode::setNode):
 277         (JSC::DFG::LazyNode::isHashTableDeletedValue):
 278         (JSC::DFG::LazyNode::isNode):
 279         (JSC::DFG::LazyNode::op):
 280         (JSC::DFG::LazyNode::asNode):
 281         (JSC::DFG::LazyNode::asValue):
 282         (JSC::DFG::LazyNode::hash):
 283         (JSC::DFG::LazyNode::operator==):
 284         (JSC::DFG::LazyNode::operator!=):
 285         (JSC::DFG::LazyNode::ensureIsNode):
 286         (JSC::DFG::LazyNode::operator->):
 287         (JSC::DFG::LazyNode::operator*):
 288         (JSC::DFG::LazyNode::operator!):
 289         (JSC::DFG::LazyNode::operator UnspecifiedBoolType*):
 290         (JSC::DFG::LazyNode::setFrozenValue):
 291         * dfg/DFGPreciseLocalClobberize.h:
 292         (JSC::DFG::PreciseLocalClobberizeAdaptor::def):
 293         * dfg/DFGPutStackSinkingPhase.cpp:
 294
 295 2015-05-22  Andreas Kling  <akling@apple.com>
 296
 297         [JSC] Speed up new array construction in Array.prototype.splice().
 298         <https://webkit.org/b/145303>
 299
 300         Reviewed by Benjamin Poulain.
 301
 302         Give splice() a fast path just like slice(), for indexing types where the backing
 303         store can be memcpy'd. I generalized JSArray::fastSlice() a little bit so it works
 304         for this optimization as well.
 305
 306         7% progression on Kraken/stanford-crypto-pbkdf2.
 307
 308         * runtime/JSArray.h:
 309         * runtime/JSArray.cpp:
 310         (JSC::JSArray::fastSlice): Tweak this to return JSArray*, and don't bother throwing
 311         out-of-memory exceptions. Let the caller worry about that.
 312
 313         * runtime/ArrayPrototype.cpp:
 314         (JSC::arrayProtoFuncSlice): Update for fastSlice() changes.
 315         (JSC::arrayProtoFuncSplice): If the object we're splicing out of is a bona fide
 316         JSArray, use fastSlice() to create the returned array instead of doing a generic
 317         get/put loop.
 318
 319 2015-05-21  Filip Pizlo  <fpizlo@apple.com>
 320
 321         CPS rethreading should really get rid of GetLocals
 322         https://bugs.webkit.org/show_bug.cgi?id=145290
 323
 324         Reviewed by Benjamin Poulain.
 325
 326         CPS rethreading is intended to get rid of redundant GetLocals. CSE can also do it, but
 327         the idea is that you should be able to disable CSE and everything would still work. This
 328         fixes a bug in CPS rethreading's GetLocal elimination: we should be calling replaceWith
 329         rather than setReplacement, since setReplacement still leaves the original node.
 330
 331         * dfg/DFGCPSRethreadingPhase.cpp:
 332         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): Fix the bug.
 333         * dfg/DFGFixupPhase.cpp:
 334         (JSC::DFG::FixupPhase::fixupNode): Eliminating GetLocals means that they turn into Check. We should handle Checks that have zero inputs.
 335         * dfg/DFGValidate.cpp:
 336         (JSC::DFG::Validate::validateCPS): Add a validation for what a GetLocal should look like in ThreadedCPS.
 337         * tests/stress/get-local-elimination.js: Added.
 338         (foo):
 339
 340 2015-05-21  Saam Barati  <saambarati1@gmail.com>
 341
 342         Object allocation sinking phase should explicitly create bottom values for CreateActivation sink candidates and CreateActivation should have SymbolTable as a child node
 343         https://bugs.webkit.org/show_bug.cgi?id=145192
 344
 345         Reviewed by Filip Pizlo.
 346
 347         When we sink CreateActivation and generate MaterializeCreateActivation
 348         in the object allocation sinking phase, we now explictly add PutHints for
 349         all variables on the activation setting those variables to their default value
 350         (undefined for Function activations and soon to be JS Empty Value for block scope activations).
 351         This allows us to remove code that fills FTL fast activation allocations with Undefined.
 352
 353         This patch also adds the constant SymbolTable as an OpInfo of CreateActivation and MaterializeCreateActivation
 354         nodes. This is in preparation for ES6 block scoping which will introduce a new
 355         op code that gets lowered to CreateActivation.
 356
 357         * dfg/DFGByteCodeParser.cpp:
 358         (JSC::DFG::ByteCodeParser::parseBlock):
 359         * dfg/DFGClobberize.h:
 360         (JSC::DFG::clobberize):
 361         * dfg/DFGNode.h:
 362         (JSC::DFG::Node::hasCellOperand):
 363         (JSC::DFG::Node::cellOperand):
 364         * dfg/DFGObjectAllocationSinkingPhase.cpp:
 365         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
 366         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
 367         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
 368         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
 369         * dfg/DFGPromotedHeapLocation.cpp:
 370         (WTF::printInternal):
 371         * dfg/DFGPromotedHeapLocation.h:
 372         * dfg/DFGSpeculativeJIT.cpp:
 373         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
 374         * ftl/FTLLowerDFGToLLVM.cpp:
 375         (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
 376         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
 377         * ftl/FTLOperations.cpp:
 378         (JSC::FTL::operationMaterializeObjectInOSR):
 379         * tests/stress/activation-sink-default-value.js: Added.
 380         (bar):
 381         * tests/stress/activation-sink-osrexit-default-value.js: Added.
 382         (foo.set result):
 383
 384 2015-05-21  Per Arne Vollan  <peavo@outlook.com>
 385
 386         MSVC internal compiler error when compiling TemplateRegistryKey class.
 387         https://bugs.webkit.org/show_bug.cgi?id=145259
 388
 389         Reviewed by Alex Christensen.
 390
 391         MSVC is not able to handle the brace initialization of a class member in this case.
 392
 393         * runtime/TemplateRegistryKey.h:
 394
 395 2015-05-21  Csaba Osztrogonác  <ossy@webkit.org>
 396
 397         Fix the !ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) build after r184337
 398         https://bugs.webkit.org/show_bug.cgi?id=145248
 399
 400         Reviewed by Yusuke Suzuki.
 401
 402         * bytecompiler/BytecodeGenerator.cpp:
 403         * bytecompiler/BytecodeGenerator.h:
 404         * parser/Parser.cpp:
 405         (JSC::Parser<LexerType>::parseMemberExpression):
 406
 407 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
 408
 409         Web Inspector: array previews should have a much smaller cap on values
 410         https://bugs.webkit.org/show_bug.cgi?id=145195
 411
 412         Reviewed by Timothy Hatcher.
 413
 414         * inspector/InjectedScriptSource.js:
 415         (InjectedScript.RemoteObject.prototype._generatePreview):
 416         Reduce the indexes threshold for previews.
 417
 418 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
 419
 420         Web Inspector: Use native Arguments detection instead of using toString
 421         https://bugs.webkit.org/show_bug.cgi?id=145235
 422
 423         Reviewed by Timothy Hatcher.
 424
 425         * inspector/InjectedScriptSource.js:
 426         (InjectedScript.prototype._subtype):
 427         Deleted the old string code.
 428
 429         * inspector/JSInjectedScriptHost.cpp:
 430         (Inspector::JSInjectedScriptHost::subtype):
 431         Replaced with a stricter, more accurate check.
 432
 433 2015-05-20  Andreas Kling  <akling@apple.com>
 434
 435         Remove unused MarkedBlock::m_rememberedSet.
 436         <https://webkit.org/b/145224>
 437
 438         Reviewed by Mark Hahnenberg.
 439
 440         The MarkedBlock had a copy of the remembered bit for each of its cells,
 441         and we were maintaining that bitmap despite no one actually ever consulting it.
 442
 443         This patch removes MarkedBlock::m_rememberedSet, freeing up 128 bytes in each
 444         block and making write barriers a little faster.
 445
 446         * heap/Heap.cpp:
 447         (JSC::Heap::clearRememberedSet):
 448         (JSC::Heap::addToRememberedSet):
 449         * heap/HeapInlines.h:
 450         (JSC::Heap::isRemembered):
 451         * heap/MarkedBlock.cpp:
 452         (JSC::MarkedBlock::clearRememberedSet): Deleted.
 453         (JSC::MarkedBlock::clearMarksWithCollectionType):
 454         * heap/MarkedBlock.h:
 455         (JSC::MarkedBlock::setRemembered): Deleted.
 456         (JSC::MarkedBlock::clearRemembered): Deleted.
 457         (JSC::MarkedBlock::atomicClearRemembered): Deleted.
 458         (JSC::MarkedBlock::isRemembered): Deleted.
 459         * heap/MarkedSpace.h:
 460         (JSC::ClearRememberedSet::operator()): Deleted.
 461         (JSC::MarkedSpace::clearRememberedSet): Deleted.
 462
 463 2015-05-20  Andreas Kling  <akling@apple.com>
 464
 465         Eden collections should extend the IncrementalSweeper work list, not replace it.
 466         <https://webkit.org/b/145213>
 467         <rdar://problem/21002666>
 468
 469         Reviewed by Geoffrey Garen.
 470
 471         After an eden collection, the garbage collector was adding all MarkedBlocks containing
 472         new objects to the IncrementalSweeper's work list, to make sure they didn't have to
 473         wait until the next full collection before getting swept.
 474
 475         Or at least, that's what it thought it was doing. It turns out that IncrementalSweeper's
 476         internal work list is really just a reference to Heap::m_blockSnapshot. I didn't realize
 477         this when writing the post-eden sweep code, and instead made eden collections cancel
 478         all pending sweeps and *replace* them with the list of blocks with new objects.
 479
 480         This made it so that rapidly occurring eden collections could prevent large numbers of
 481         heap blocks from ever getting swept. This would manifest as accumulation of MarkedBlocks
 482         when a system under heavy load was also allocating short lived objects at a high rate.
 483         Things would eventually get cleaned up when there was a lull and a full collection was
 484         allowed to run its heap sweep to completion.
 485
 486         Fix this by moving all management of the block snapshot to Heap. snapshotMarkedSpace()
 487         now handles eden collections by merging the list of blocks with new objects into the
 488         existing block snapshot.
 489
 490         * heap/Heap.cpp:
 491         (JSC::Heap::snapshotMarkedSpace):
 492         (JSC::Heap::notifyIncrementalSweeper):
 493         * heap/IncrementalSweeper.cpp:
 494         (JSC::IncrementalSweeper::startSweeping):
 495         (JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Deleted.
 496         * heap/IncrementalSweeper.h:
 497
 498 2015-05-20  Youenn Fablet  <youenn.fablet@crf.canon.fr>
 499
 500         AudioContext resume/close/suspend should reject promises with a DOM exception in lieu of throwing exceptions
 501         https://bugs.webkit.org/show_bug.cgi?id=145064
 502
 503         Reviewed by Darin Adler.
 504
 505         Added default message for TypeError.
 506
 507         * runtime/Error.cpp:
 508         (JSC::throwTypeError):
 509         * runtime/Error.h:
 510
 511 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
 512
 513         No LLInt Test Failure: jsc-layout-tests.yaml/js/script-tests/object-literal-duplicate-properties.js.layout-no-llint
 514         https://bugs.webkit.org/show_bug.cgi?id=145219
 515
 516         Reviewed by Mark Lam.
 517
 518         * jit/JITOperations.cpp:
 519         Throw the error we just got, instead of a stack overflow exception.
 520         This matches other error handling for callers of prepareForExecution.
 521
 522 2015-05-19  Filip Pizlo  <fpizlo@apple.com>
 523
 524         Add some assertions about the CFG in the loop pre-header creation phase
 525         https://bugs.webkit.org/show_bug.cgi?id=145205
 526
 527         Reviewed by Geoffrey Garen.
 528
 529         * dfg/DFGByteCodeParser.cpp:
 530         (JSC::DFG::ByteCodeParser::currentNodeOrigin): Add a FIXME.
 531         * dfg/DFGLICMPhase.cpp:
 532         (JSC::DFG::LICMPhase::run): Add a FIXME.
 533         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
 534         (JSC::DFG::LoopPreHeaderCreationPhase::run): Add the assertions.
 535
 536 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
 537
 538         ES6: Implement Object.setPrototypeOf
 539         https://bugs.webkit.org/show_bug.cgi?id=145202
 540
 541         Reviewed by Darin Adler.
 542
 543         * runtime/JSGlobalObjectFunctions.h:
 544         * runtime/JSGlobalObjectFunctions.cpp:
 545         (JSC::globalFuncProtoSetter):
 546         (JSC::checkProtoSetterAccessAllowed):
 547         Extract a helper to share this code between __proto__ setter and setPrototypeOf.
 548
 549         * runtime/ObjectConstructor.cpp:
 550         (JSC::objectConstructorSetPrototypeOf):
 551         Implementation is very similiar to __proto__ setter.
 552
 553 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
 554
 555         ES6: Should not allow duplicate basic __proto__ properties in Object Literals
 556         https://bugs.webkit.org/show_bug.cgi?id=145138
 557
 558         Reviewed by Darin Adler.
 559
 560         Implement ES6 Annex B.3.1, which disallows duplicate basic __proto__
 561         properties in object literals. This doesn't affect computed properties,
 562         shorthand properties, or getters/setters all of which avoid setting
 563         the actual prototype of the object anyway.
 564
 565         * interpreter/Interpreter.cpp:
 566         (JSC::eval):
 567         Remove out of date comment. Duplicate property names are allowed
 568         now in ES6, they were not in ES5 strict mode.
 569
 570         * parser/ASTBuilder.h:
 571         (JSC::ASTBuilder::getName):
 572         (JSC::ASTBuilder::getType):
 573         * parser/SyntaxChecker.h:
 574         (JSC::SyntaxChecker::getName):
 575         Add back getName to get the property name depending on the tree builder.
 576         Also tighten up the parameter types.
 577
 578         * runtime/LiteralParser.cpp:
 579         (JSC::LiteralParser<CharType>::parse):
 580         In quick JSON literal parsing for eval, we actually need to evaluate
 581         the __proto__ property assignment, instead of just building up a list
 582         of direct properties. Only do this when not doing a strict JSON parse.
 583
 584         * parser/Nodes.h:
 585         Add "Shorthand" to the list of PropertyNode types to allow it to
 586         be distinguished without relying on other information.
 587
 588         * parser/Parser.h:
 589         * parser/Parser.cpp:
 590         (JSC::Parser<LexerType>::parseProperty):
 591         Add the Shorthand type when parsing a shorthand property.
 592
 593         (JSC::Parser<LexerType>::shouldCheckPropertyForUnderscoreProtoDuplicate):
 594         (JSC::Parser<LexerType>::parseObjectLiteral):
 595         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
 596         Check for duplicate __proto__ properties, and throw a SyntaxError
 597         if that was the case.
 598
 599 2015-05-20  Csaba Osztrogonác  <ossy@webkit.org>
 600
 601         [JSC] Add missing copyrights and licenses for some scripts
 602         https://bugs.webkit.org/show_bug.cgi?id=145044
 603
 604         Reviewed by Darin Adler.
 605
 606         * build-symbol-table-index.py:
 607         * create-llvm-ir-from-source-file.py:
 608         * create-symbol-table-index.py:
 609
 610 2015-05-20  Joseph Pecoraro  <pecoraro@apple.com>
 611
 612         Web Inspector: Slightly better node previews in arrays
 613         https://bugs.webkit.org/show_bug.cgi?id=145188
 614
 615         Reviewed by Timothy Hatcher.
 616
 617         * inspector/InjectedScriptSource.js:
 618         (InjectedScript.prototype._nodeDescription):
 619         (InjectedScript.prototype._nodePreview):
 620         Different stringified representations for a basic object description or in a preview.
 621
 622         (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
 623         Use the node preview string representation inside previews.
 624
 625 2015-05-19  Commit Queue  <commit-queue@webkit.org>
 626
 627         Unreviewed, rolling out r184613 and r184614.
 628         https://bugs.webkit.org/show_bug.cgi?id=145206
 629
 630         Broke 10 tests :| (Requested by kling on #webkit).
 631
 632         Reverted changesets:
 633
 634         "[JSC] Speed up URL encode/decode by using bitmaps instead of
 635         strchr()."
 636         https://bugs.webkit.org/show_bug.cgi?id=145115
 637         http://trac.webkit.org/changeset/184613
 638
 639         "[JSC] Speed up URL encode/decode by using bitmaps instead of
 640         strchr()."
 641         https://bugs.webkit.org/show_bug.cgi?id=145115
 642         http://trac.webkit.org/changeset/184614
 643
 644 2015-05-19  Andreas Kling  <akling@apple.com>
 645
 646         Give StringView a utf8() API.
 647         <https://webkit.org/b/145201>
 648
 649         Reviewed by Anders Carlsson.
 650
 651         Use JSString::view() in a few places where we couldn't before due to StringView
 652         lacking a utf8() API. This is a minor speed-up on Kraken's crypto subtests,
 653         which like to call encode() with substring JSStrings.
 654
 655         * jsc.cpp:
 656         (functionPrint):
 657         (functionDebug):
 658         * runtime/JSGlobalObjectFunctions.cpp:
 659         (JSC::encode):
 660
 661 2015-05-19  Andreas Kling  <akling@apple.com>
 662
 663         [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
 664         <https://webkit.org/b/145115>
 665
 666         Incorporate review feedback from Darin, removing some unnecessary zero checks.
 667
 668         * runtime/JSGlobalObjectFunctions.cpp:
 669         (JSC::encode):
 670         (JSC::decode):
 671         (JSC::globalFuncEscape):
 672
 673 2015-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
 674
 675         Move AtomicStringImpl table related operations from AtomicString to AtomicStringImpl
 676         https://bugs.webkit.org/show_bug.cgi?id=145109
 677
 678         Reviewed by Darin Adler.
 679
 680         * bytecode/CodeBlock.cpp:
 681         (JSC::CodeBlock::nameForRegister):
 682         * runtime/Identifier.cpp:
 683         (JSC::Identifier::add):
 684         (JSC::Identifier::add8):
 685         * runtime/Identifier.h:
 686         (JSC::Identifier::add):
 687         * runtime/IdentifierInlines.h:
 688         (JSC::Identifier::Identifier):
 689         (JSC::Identifier::add):
 690         * runtime/JSString.cpp:
 691         (JSC::JSRopeString::resolveRopeToExistingAtomicString):
 692         * runtime/JSString.h:
 693         (JSC::JSString::toExistingAtomicString):
 694         * runtime/SmallStrings.cpp:
 695         (JSC::SmallStringsStorage::SmallStringsStorage):
 696         * runtime/TypeSet.cpp:
 697         (JSC::StructureShape::propertyHash):
 698
 699 2015-05-19  Joseph Pecoraro  <pecoraro@apple.com>
 700
 701         Web Inspector: Improve Preview for NodeList / array like collections
 702         https://bugs.webkit.org/show_bug.cgi?id=145177
 703
 704         Reviewed by Timothy Hatcher.
 705
 706         * inspector/InjectedScriptSource.js:
 707         (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
 708         For "array" like object previews skip over non-index properties.
 709         We are not marking the object as lossless by choice, but we
 710         may return to this decision later.
 711
 712 2015-05-19  Michael Saboff  <msaboff@apple.com>
 713
 714         REGRESSION(183787): JIT is enabled for all builds
 715         https://bugs.webkit.org/show_bug.cgi?id=145179
 716
 717         Reviewed by Geoffrey Garen.
 718
 719         Eliminated the setting of ENABLE_JIT, as wtf/Platform.h has appropriate logic to
 720         set it depending on OS and CPU type.
 721
 722         * Configurations/FeatureDefines.xcconfig:
 723
 724 2015-05-19  Youenn Fablet  <youenn.fablet@crf.canon.fr>
 725
 726         Rename createIterResultObject as createIteratorResultObject
 727         https://bugs.webkit.org/show_bug.cgi?id=145116
 728
 729         Reviewed by Darin Adler.
 730
 731         Renamed createIterResultObject as createIteratorResultObject.
 732         Made this function exportable for future use by streams API.
 733
 734         * runtime/IteratorOperations.cpp:
 735         (JSC::createIteratorResultObject):
 736         * runtime/IteratorOperations.h:
 737         * runtime/MapIteratorPrototype.cpp:
 738         (JSC::MapIteratorPrototypeFuncNext):
 739         * runtime/SetIteratorPrototype.cpp:
 740         (JSC::SetIteratorPrototypeFuncNext):
 741
 742 2015-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
 743
 744         Array.prototype methods must use ToLength
 745         https://bugs.webkit.org/show_bug.cgi?id=144128
 746
 747         Reviewed by Oliver Hunt.
 748
 749         Patch by Jordan Harband  <ljharb@gmail.com> and Yusuke Suzuki <utatane.tea@gmail.com>
 750
 751         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength
 752
 753         This patch introduces ToLength and ToInteger JS implementation to encourage the DFG/FTL's inlining.
 754         These implementations are located in GlobalObject.js.
 755         And set to the JSGlobalObject with the private symbols @ToLength and @ToInteger manually.
 756
 757         * builtins/Array.prototype.js:
 758         (every):
 759         (forEach):
 760         (filter):
 761         (map):
 762         (some):
 763         (fill):
 764         (find):
 765         (findIndex):
 766         (includes):
 767         * builtins/ArrayConstructor.js:
 768         (from):
 769         * builtins/GlobalObject.js: Copied from Source/JavaScriptCore/builtins/StringConstructor.js.
 770         (ToInteger):
 771         (ToLength):
 772         * builtins/StringConstructor.js:
 773         (raw):
 774         * runtime/JSGlobalObject.cpp:
 775         (JSC::JSGlobalObject::init):
 776         * runtime/JSGlobalObjectFunctions.h:
 777
 778 2015-05-19  Mark Lam  <mark.lam@apple.com>
 779
 780         Fix the build of a universal binary with ARMv7k of JavaScriptCore.
 781         https://bugs.webkit.org/show_bug.cgi?id=145143
 782
 783         Reviewed by Geoffrey Garen.
 784
 785         The offlineasm works in 3 phases:
 786
 787         Phase 1:
 788            Parse the llint asm files for config options and desired offsets.
 789            Let's say the offlineasm discovers C unique options and O unique offsets.
 790            The offlineasm will then generate a LLIntDesiredOffsets.h file with
 791            C x C build configurations, each with a set of O offsets.
 792
 793            Each of these build configurations is given a unique configuration index number.
 794
 795         Phase 2:
 796            Compile the LLIntDesiredOffsets.h file into a JSCLLIntOffsetsExtractor binary.
 797
 798            If we're building a fat binary with 2 configurations: armv7, and armv7k,
 799            then the fat binary will contain 2 blobs of offsets, one for each of these
 800            build configurations.
 801
 802         Phase 3:
 803            Parse the llint asm files and emit asm code using the offsets that are
 804            extracted from the JSCLLIntOffsetsExtractor binary for the corresponding
 805            configuration index number.
 806
 807         In the pre-existing code, there are no "if ARMv7k" statements in the llint asm
 808         source.  As a result, OFFLINE_ASM_ARMv7k is not one of the config options in
 809         the set of C unique options.
 810
 811         For armv7k builds, OFFLINE_ASM_ARMv7 is also true.  As a result, for an armv7k
 812         target, we will end up building armv7 source.  In general, this is fine except:
 813
 814         1. armv7k has different alignment requirements from armv7.  Hence, their offset
 815            values (in JSCLLIntOffsetsExtractor) will be different.
 816
 817         2. The offlineasm was never told that it needed to make a different configuration
 818            for armv7k builds.  Hence, the armv7k build of LLIntDesiredOffsets.h will
 819            build the armv7 configuration, and consequently, the armv7k blob of offsets in
 820            JSCLLIntOffsetsExtractor will have the same configuration index number as
 821            the armv7 blob of offsets.
 822
 823         In phase 3, when the offlineasm parses the JSCLLIntOffsetsExtractor fat binary
 824         looking for the armv7 build's configuration index number, it discovers the
 825         armv7k blob which has the same configuration number.  As a result, it
 826         erroneously thinks the armv7k offsets are appropriate for emitting armv7 code.
 827         Needless to say, armv7 code using armv7k offsets will lead to incorrect behavior
 828         and all round badness.
 829
 830         The fix is to add a simple "if ARMv7k" statement to the llint asm files.  While
 831         the if statement has no body, it does make the offlineasm aware of the need for
 832         ARMv7k as a configuration option.  As a result, it will generate an armv7k
 833         variant configuration in the LLIntDesiredOffsets.h file with its own unique
 834         configuration index number.  With that, the JSCLLIntOffsetsExtractor fat binary
 835         will no longer have duplicate configuration index numbers for the armv7 and
 836         armv7k blobs of offsets, and the issue is resolved.
 837
 838         * llint/LLIntOfflineAsmConfig.h:
 839         * llint/LowLevelInterpreter.asm:
 840
 841 2015-05-19  Andreas Kling  <akling@apple.com>
 842
 843         Give JSString a StringView getter and start using it.
 844         <https://webkit.org/b/145131>
 845
 846         Reviewed by Anders Carlsson.
 847
 848         When JSString is a substring internally, calling value(ExecState*) on it
 849         will reify the baseString/start/length tuple into a new StringImpl.
 850
 851         For clients that only want to look at the characters of a JSString, but
 852         don't actually need a reffable StringImpl, adding a light-weight StringView
 853         getter lets them avoid constructing anything.
 854
 855         This patch adds JSString::view(ExecState*) and uses it in a few places.
 856         There are many more opportunities to use this API, but let's do a few things
 857         at a time.
 858
 859         * runtime/FunctionConstructor.cpp:
 860         (JSC::constructFunctionSkippingEvalEnabledCheck):
 861         * runtime/JSGlobalObjectFunctions.cpp:
 862         (JSC::decode):
 863         (JSC::parseInt):
 864         (JSC::jsToNumber):
 865         (JSC::parseFloat):
 866         (JSC::globalFuncParseInt):
 867         (JSC::globalFuncParseFloat):
 868         (JSC::globalFuncEscape):
 869         (JSC::globalFuncUnescape):
 870         * runtime/JSGlobalObjectFunctions.h:
 871         * runtime/JSONObject.cpp:
 872         (JSC::JSONProtoFuncParse):
 873         * runtime/JSString.cpp:
 874         (JSC::JSString::getPrimitiveNumber):
 875         (JSC::JSString::toNumber):
 876         * runtime/JSString.h:
 877         (JSC::JSRopeString::view):
 878         (JSC::JSString::view):
 879
 880 2015-05-18  Filip Pizlo  <fpizlo@apple.com>
 881
 882         Better optimize 'if' with ternaries conditional tests.
 883         https://bugs.webkit.org/show_bug.cgi?id=144136
 884
 885         Reviewed by Benjamin Poulain.
 886
 887         This is the last fix I'll do for this for now. BooleanToNumber(Untyped:) where the input
 888         is proved to be either BoolInt32 or Boolean should be optimized to just masking the
 889         lowest bit.
 890
 891         This is another 37% speed-up on JSRegress/slow-ternaries.
 892
 893         * dfg/DFGSpeculativeJIT32_64.cpp:
 894         (JSC::DFG::SpeculativeJIT::compile):
 895         * dfg/DFGSpeculativeJIT64.cpp:
 896         (JSC::DFG::SpeculativeJIT::compile):
 897         * ftl/FTLLowerDFGToLLVM.cpp:
 898         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
 899
 900 2015-05-18  Benjamin Poulain  <bpoulain@apple.com>
 901
 902         <rdar://problem/21003555> cloberrize() is wrong for ArithRound because it doesn't account for the arith mode
 903         https://bugs.webkit.org/show_bug.cgi?id=145147
 904
 905         Reviewed by Filip Pizlo.
 906
 907         Really stupid bug: ArithRound nodes with different rounding modes
 908         were not distinguished and CSE would happily unify with a node of
 909         a different rounding mode.
 910
 911         DFG::clobberize() already support additional data but I was not using it.
 912
 913         * dfg/DFGClobberize.h:
 914         (JSC::DFG::clobberize):
 915         * tests/stress/math-round-arith-rounding-mode.js: Added.
 916         (firstCareAboutZeroSecondDoesNot):
 917         (firstDoNotCareAboutZeroSecondDoes):
 918         (warmup):
 919         (verifyNegativeZeroIsPreserved):
 920
 921 2015-05-18  Filip Pizlo  <fpizlo@apple.com>
 922
 923         Add SpecBoolInt32 type that means "I'm an int and I'm either 0 or 1"
 924         https://bugs.webkit.org/show_bug.cgi?id=145137
 925
 926         Reviewed by Benjamin Poulain.
 927
 928         It's super useful to know if an integer value could be either zero or one. We have an
 929         immediate need for this because of Int32|Boolean uses, where knowing that the Int32 is
 930         either 0 or 1 means that there is no actual polymorphism if you just look at the low bit
 931         (1 behaves like true, 0 behaves like false, and the low bit of 1|true is 1, and the low
 932         bit of 0|false is 0).
 933
 934         We do this by splitting the SpecInt32 type into SpecBoolInt32 and SpecNonBoolInt32. This
 935         change doesn't have any effect on behavior, yet. But it does give us the ability to
 936         predict and prove when values are SpecBoolInt32; it's just we don't leverage this yet.
 937
 938         This is perf-neutral.
 939
 940         * bytecode/SpeculatedType.cpp:
 941         (JSC::dumpSpeculation):
 942         (JSC::speculationToAbbreviatedString):
 943         (JSC::speculationFromValue):
 944         * bytecode/SpeculatedType.h:
 945         (JSC::isStringOrStringObjectSpeculation):
 946         (JSC::isBoolInt32Speculation):
 947         (JSC::isInt32Speculation):
 948         (JSC::isInt32OrBooleanSpeculation):
 949         * dfg/DFGAbstractInterpreterInlines.h:
 950         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
 951
 952 2015-05-18  Michael Catanzaro  <mcatanzaro@igalia.com>
 953
 954         [CMake] Ignore warnings in system headers
 955         https://bugs.webkit.org/show_bug.cgi?id=144747
 956
 957         Reviewed by Darin Adler.
 958
 959         Separate include directories into WebKit project includes and system includes. Suppress all
 960         warnings from headers in system include directories using the SYSTEM argument to
 961         the include_directories command.
 962
 963         * CMakeLists.txt:
 964         * PlatformGTK.cmake:
 965
 966 2015-05-18  Skachkov Alexandr  <gskachkov@gmail.com>
 967
 968         [ES6] Arrow function syntax. Feature flag for arrow function
 969         https://bugs.webkit.org/show_bug.cgi?id=145108
 970
 971         Reviewed by Ryosuke Niwa.
 972
 973         Added feature flag ENABLE_ES6_ARROWFUNCTION_SYNTAX for arrow function
 974
 975         * Configurations/FeatureDefines.xcconfig:
 976
 977 2015-05-18  Benjamin Poulain  <benjamin@webkit.org>
 978
 979         [JSC] When entering a CheckTierUp without OSREntry, force the CheckTierUp for the outer loops with OSR Entry
 980         https://bugs.webkit.org/show_bug.cgi?id=145092
 981
 982         Reviewed by Filip Pizlo.
 983
 984         When we have a hot loop without OSR Entry inside a slower loop that support OSR Entry,
 985         we get the inside loop driving the tierUpCounter and we have very little chance of
 986         doing a CheckTierUp on the outer loop. In turn, this give almost no opportunity to tier
 987         up in the outer loop and OSR Enter there.
 988
 989         This patches changes CheckTierUp to force its outer loops to do a CheckTierUp themselves.
 990
 991         To do that, CheckTierUp sets a flag "nestedTriggerIsSet" to force the outer loop to
 992         enter their CheckTierUp regardless of the tier-up counter.
 993
 994         * bytecode/ExecutionCounter.cpp:
 995         (JSC::ExecutionCounter<countingVariant>::setThreshold):
 996         This is somewhat unrelated. This assertion is incorrect because it relies on
 997         m_counter, which changes on an other thread.
 998
 999         I have hit it a couple of times with this patch because we are a bit more aggressive
1000         on CheckTierUp. What happens is:
1001         1) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() first checks
1002            hasCrossedThreshold(), and it is false.
1003         2) On the main thread, the hot loops keeps running and the counter becomes large
1004            enough to cross the threshold.
1005         3) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() runs the next
1006            test, setThreshold(), where the assertion is. Since the counter is now large enough,
1007            the assertion fails.
1008
1009         * dfg/DFGAbstractInterpreterInlines.h:
1010         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1011         * dfg/DFGClobberize.h:
1012         (JSC::DFG::clobberize):
1013         * dfg/DFGDoesGC.cpp:
1014         (JSC::DFG::doesGC):
1015         * dfg/DFGFixupPhase.cpp:
1016         (JSC::DFG::FixupPhase::fixupNode):
1017
1018         * dfg/DFGJITCode.h:
1019         I used a uint8_t instead of a boolean to make the code generation clearer
1020         in DFGSpeculativeJIT64.
1021
1022         * dfg/DFGNodeType.h:
1023         * dfg/DFGOperations.cpp:
1024         * dfg/DFGOperations.h:
1025
1026         * dfg/DFGPredictionPropagationPhase.cpp:
1027         (JSC::DFG::PredictionPropagationPhase::propagate):
1028         This is a bit annoying: we have the NaturalLoops analysis that provides us
1029         everything we need to know about loops, but the TierUpCheck are conservative
1030         and set on LoopHint.
1031
1032         To make the two work together, we first find all the CheckTierUp that cannot
1033         OSR enter and we keep a list of all the natural loops containing them.
1034
1035         Then we do a second pass over the LoopHints, get their NaturalLoop, and check
1036         if it contains a loop that cannot OSR enter.
1037
1038         * dfg/DFGSafeToExecute.h:
1039         (JSC::DFG::safeToExecute):
1040         * dfg/DFGSpeculativeJIT32_64.cpp:
1041         (JSC::DFG::SpeculativeJIT::compile):
1042         * dfg/DFGSpeculativeJIT64.cpp:
1043         (JSC::DFG::SpeculativeJIT::compile):
1044         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1045         (JSC::DFG::TierUpCheckInjectionPhase::run):
1046         (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
1047
1048 2015-05-18  Filip Pizlo  <fpizlo@apple.com>
1049
1050         Add a Int-or-Boolean speculation to Branch
1051         https://bugs.webkit.org/show_bug.cgi?id=145134
1052
1053         Reviewed by Benjamin Poulain.
1054
1055         After https://bugs.webkit.org/show_bug.cgi?id=126778 we no longer have a reason not to do the
1056         int-or-boolean optimization that we already do everywhere else.
1057
1058         * dfg/DFGFixupPhase.cpp:
1059         (JSC::DFG::FixupPhase::fixupNode):
1060
1061 2015-05-18  Andreas Kling  <akling@apple.com>
1062
1063         [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
1064         <https://webkit.org/b/145115>
1065
1066         Reviewed by Anders Carlsson.
1067
1068         We were calling strchr() for every character when doing URL encoding/decoding and it stood out
1069         like a sore O(n) thumb in Instruments. Optimize this by using a Bitmap<256> instead.
1070
1071         5.5% progression on Kraken/stanford-crypto-sha256-iterative.
1072
1073         * runtime/JSGlobalObjectFunctions.cpp:
1074         (JSC::makeCharacterBitmap):
1075         (JSC::encode):
1076         (JSC::decode):
1077         (JSC::globalFuncDecodeURI):
1078         (JSC::globalFuncDecodeURIComponent):
1079         (JSC::globalFuncEncodeURI):
1080         (JSC::globalFuncEncodeURIComponent):
1081         (JSC::globalFuncEscape):
1082
1083 2015-05-17  Benjamin Poulain  <benjamin@webkit.org>
1084
1085         Do not use fastMallocGoodSize anywhere
1086         https://bugs.webkit.org/show_bug.cgi?id=145103
1087
1088         Reviewed by Michael Saboff.
1089
1090         * assembler/AssemblerBuffer.h:
1091         (JSC::AssemblerData::AssemblerData):
1092         (JSC::AssemblerData::grow):
1093
1094 2015-05-17  Benjamin Poulain  <benjamin@webkit.org>
1095
1096         [JSC] Make StringRecursionChecker faster in the simple cases without any recursion
1097         https://bugs.webkit.org/show_bug.cgi?id=145102
1098
1099         Reviewed by Darin Adler.
1100
1101         In general, the array targeted by Array.toString() or Array.join() are pretty
1102         simple. In those simple cases, we spend as much time in StringRecursionChecker
1103         as we do on the actual operation.
1104
1105         The reason for this is the HashSet stringRecursionCheckVisitedObjects used
1106         to detect recursion. We are constantly adding and removing objects which
1107         dirty buckets and force constant rehash.
1108
1109         This patch adds a simple shortcut for those simple case: in addition to the HashSet,
1110         we keep a pointer to the root object of the recursion.
1111         In the vast majority of cases, we no longer touch the HashSet at all.
1112
1113         This patch is a 12% progression on the overall score of ArrayWeighted.
1114
1115         * runtime/StringRecursionChecker.h:
1116         (JSC::StringRecursionChecker::performCheck):
1117         (JSC::StringRecursionChecker::~StringRecursionChecker):
1118         * runtime/VM.h:
1119
1120 2015-05-17  Filip Pizlo  <fpizlo@apple.com>
1121
1122         Insert store barriers late so that IR transformations don't have to worry about them
1123         https://bugs.webkit.org/show_bug.cgi?id=145015
1124
1125         Reviewed by Geoffrey Garen.
1126
1127         We have had three kinds of bugs with store barriers. For the sake of discussion we say
1128         that a store barrier is needed when we have something like:
1129
1130             base.field = value
1131
1132         - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
1133           This might happen if we prove value to be a non-cell even though in the FixupPhase it
1134           wasn't predicted non-cell.
1135
1136         - We sometimes have a barrier in the wrong place after object allocation sinking. We
1137           might sink an allocation to just above the store, but that puts it just after the
1138           StoreBarrier that FixupPhase inserted.
1139
1140         - We don't remove redundant barriers across basic blocks.
1141
1142         This comprehensively fixes these issues by doing store barrier insertion late, and
1143         removing the store barrier elision phase. Store barrier insertion uses an epoch-based
1144         algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
1145         base is in the current GC epoch (i.e. was the last object that we allocated or had a
1146         barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
1147         always been allocated before base). We do conservative things when merging epoch state
1148         between basic blocks, and we only do such inter-block removal in the FTL. FTL also
1149         queries AI to determine what type we've proved about value, and avoids barriers when
1150         value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
1151         the likelihood that this AI-based removal is effective.
1152
1153         Rolling back in after fixing some debug build test failures.
1154
1155         * CMakeLists.txt:
1156         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1157         * JavaScriptCore.xcodeproj/project.pbxproj:
1158         * dfg/DFGBlockMap.h:
1159         (JSC::DFG::BlockMap::at):
1160         * dfg/DFGConstantFoldingPhase.cpp:
1161         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
1162         * dfg/DFGEpoch.h:
1163         (JSC::DFG::Epoch::operator<):
1164         (JSC::DFG::Epoch::operator>):
1165         (JSC::DFG::Epoch::operator<=):
1166         (JSC::DFG::Epoch::operator>=):
1167         * dfg/DFGFixupPhase.cpp:
1168         (JSC::DFG::FixupPhase::fixupNode):
1169         (JSC::DFG::FixupPhase::speculateForBarrier):
1170         (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
1171         * dfg/DFGPlan.cpp:
1172         (JSC::DFG::Plan::compileInThreadImpl):
1173         * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
1174         * dfg/DFGStoreBarrierElisionPhase.h: Removed.
1175         * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
1176         (JSC::DFG::performFastStoreBarrierInsertion):
1177         (JSC::DFG::performGlobalStoreBarrierInsertion):
1178         * dfg/DFGStoreBarrierInsertionPhase.h: Added.
1179         * ftl/FTLOperations.cpp:
1180         (JSC::FTL::operationMaterializeObjectInOSR): Fix an unrelated debug-only bug.
1181         * tests/stress/load-varargs-then-inlined-call-and-exit.js: Test for that debug-only bug.
1182         * tests/stress/load-varargs-then-inlined-call-and-exit-strict.js: Strict version of that test.
1183
1184 2015-05-16  Commit Queue  <commit-queue@webkit.org>
1185
1186         Unreviewed, rolling out r184415.
1187         https://bugs.webkit.org/show_bug.cgi?id=145096
1188
1189         Broke several tests (Requested by msaboff on #webkit).
1190
1191         Reverted changeset:
1192
1193         "Insert store barriers late so that IR transformations don't
1194         have to worry about them"
1195         https://bugs.webkit.org/show_bug.cgi?id=145015
1196         http://trac.webkit.org/changeset/184415
1197
1198 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
1199
1200         Insert store barriers late so that IR transformations don't have to worry about them
1201         https://bugs.webkit.org/show_bug.cgi?id=145015
1202
1203         Reviewed by Geoffrey Garen.
1204
1205         We have had three kinds of bugs with store barriers. For the sake of discussion we say
1206         that a store barrier is needed when we have something like:
1207
1208             base.field = value
1209
1210         - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
1211           This might happen if we prove value to be a non-cell even though in the FixupPhase it
1212           wasn't predicted non-cell.
1213
1214         - We sometimes have a barrier in the wrong place after object allocation sinking. We
1215           might sink an allocation to just above the store, but that puts it just after the
1216           StoreBarrier that FixupPhase inserted.
1217
1218         - We don't remove redundant barriers across basic blocks.
1219
1220         This comprehensively fixes these issues by doing store barrier insertion late, and
1221         removing the store barrier elision phase. Store barrier insertion uses an epoch-based
1222         algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
1223         base is in the current GC epoch (i.e. was the last object that we allocated or had a
1224         barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
1225         always been allocated before base). We do conservative things when merging epoch state
1226         between basic blocks, and we only do such inter-block removal in the FTL. FTL also
1227         queries AI to determine what type we've proved about value, and avoids barriers when
1228         value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
1229         the likelihood that this AI-based removal is effective.
1230
1231         * CMakeLists.txt:
1232         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1233         * JavaScriptCore.xcodeproj/project.pbxproj:
1234         * dfg/DFGBlockMap.h:
1235         (JSC::DFG::BlockMap::at):
1236         * dfg/DFGConstantFoldingPhase.cpp:
1237         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
1238         * dfg/DFGEpoch.h:
1239         (JSC::DFG::Epoch::operator<):
1240         (JSC::DFG::Epoch::operator>):
1241         (JSC::DFG::Epoch::operator<=):
1242         (JSC::DFG::Epoch::operator>=):
1243         * dfg/DFGFixupPhase.cpp:
1244         (JSC::DFG::FixupPhase::fixupNode):
1245         (JSC::DFG::FixupPhase::speculateForBarrier):
1246         (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
1247         * dfg/DFGPlan.cpp:
1248         (JSC::DFG::Plan::compileInThreadImpl):
1249         * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
1250         * dfg/DFGStoreBarrierElisionPhase.h: Removed.
1251         * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
1252         (JSC::DFG::performFastStoreBarrierInsertion):
1253         (JSC::DFG::performGlobalStoreBarrierInsertion):
1254         * dfg/DFGStoreBarrierInsertionPhase.h: Added.
1255
1256 2015-05-15  Benjamin Poulain  <bpoulain@apple.com>
1257
1258         [ARM64] Do not fail branchConvertDoubleToInt32 when the result is zero and not negative zero
1259         https://bugs.webkit.org/show_bug.cgi?id=144976
1260
1261         Reviewed by Michael Saboff.
1262
1263         Failing the conversion on zero is pretty dangerous as we discovered on x86.
1264
1265         This patch does not really impact performance significantly because
1266         r184220 removed the zero checks from Kraken. This patch is just to be
1267         on the safe side for cases not covered by existing benchmarks.
1268
1269         * assembler/MacroAssemblerARM64.h:
1270         (JSC::MacroAssemblerARM64::branchConvertDoubleToInt32):
1271
1272 2015-05-15  Sungmann Cho  <sungmann.cho@navercorp.com>
1273
1274         Remove unnecessary forward declarations in PropertyNameArray.h.
1275         https://bugs.webkit.org/show_bug.cgi?id=145058
1276
1277         Reviewed by Andreas Kling.
1278
1279         No new tests, no behavior change.
1280
1281         * runtime/PropertyNameArray.h:
1282
1283 2015-05-15  Mark Lam  <mark.lam@apple.com>
1284
1285         JSArray::setLength() should reallocate instead of zero-filling if the reallocation would be small enough.
1286         https://bugs.webkit.org/show_bug.cgi?id=144622
1287
1288         Reviewed by Geoffrey Garen.
1289
1290         When setting the array to a new length that is shorter, we now check if it is worth
1291         just making a new butterfly instead of clearing out the slots in the old butterfly
1292         that resides beyond the new length.  If so, we will make a new butterfly instead.
1293
1294         There is no perf differences in the benchmark results.  However, this does benefit
1295         the perf of pathological cases where we need to shorten the length of a very large
1296         array, as is the case in tests/mozilla/js1_5/Array/regress-101964.js.  With this
1297         patch, we can expect that test to complete in a short time again.
1298
1299         * runtime/JSArray.cpp:
1300         (JSC::JSArray::setLength):
1301         * runtime/JSObject.cpp:
1302         (JSC::JSObject::reallocateAndShrinkButterfly):
1303         - makes a new butterfly with a new shorter length.
1304         * runtime/JSObject.h:
1305         * tests/mozilla/js1_5/Array/regress-101964.js:
1306         - Undo this test change since this patch will prevent us from spending a lot of time
1307           clearing a large butterfly.
1308
1309 2015-05-15  Basile Clement  <basile_clement@apple.com>
1310
1311         DFGLICMPhase shouldn't create NodeOrigins with forExit but without semantic
1312         https://bugs.webkit.org/show_bug.cgi?id=145062
1313
1314         Reviewed by Filip Pizlo.
1315
1316         We assert in various places (including NodeOrigin::isSet()) that a
1317         NodeOrigin's semantic and forExit must be either both set, or both
1318         unset.  However, LICM'ing a node with unset NodeOrigin would only set
1319         forExit, and leave semantic unset. This can for instance happen when a
1320         Phi node is constant-folded into a JSConstant, which in turn gets
1321         LICM'd.
1322
1323         This patch changes DFGLICMPhase to set the NodeOrigin's semantic in
1324         addition to its forExit if semantic was previously unset.
1325
1326         It also adds two validators to DFGValidate.cpp:
1327          - In both SSA and CPS form, a NodeOrigin semantic and forExit must be either both set or both unset
1328          - In CPS form, all nodes must have a set NodeOrigin forExit (this is
1329            the CPS counterpart to the SSA validator that checks that all nodes
1330            must have a set NodeOrigin except possibly for a continuous chunk of
1331            nodes at the top of a block)
1332
1333         * dfg/DFGLICMPhase.cpp:
1334         (JSC::DFG::LICMPhase::attemptHoist):
1335         * dfg/DFGValidate.cpp:
1336         (JSC::DFG::Validate::validate):
1337         (JSC::DFG::Validate::validateCPS):
1338
1339 2015-05-15  Filip Pizlo  <fpizlo@apple.com>
1340
1341         Unreviewed, remove an unused declaration.
1342
1343         * dfg/DFGSpeculativeJIT.h:
1344
1345 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
1346
1347         Remove unused constant-base and constant-value store barrier code in the DFG
1348         https://bugs.webkit.org/show_bug.cgi?id=145039
1349
1350         Reviewed by Andreas Kling.
1351
1352         Just killing dead code.
1353
1354         * dfg/DFGSpeculativeJIT.cpp:
1355         (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
1356         (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
1357         * dfg/DFGSpeculativeJIT.h:
1358         * dfg/DFGSpeculativeJIT32_64.cpp:
1359         (JSC::DFG::SpeculativeJIT::writeBarrier):
1360         * dfg/DFGSpeculativeJIT64.cpp:
1361         (JSC::DFG::SpeculativeJIT::writeBarrier):
1362
1363 2015-05-15  Alexandr Skachkov  <gskachkov@gmail.com>
1364
1365         Fix typo in function name parseFunctionParamters -> parseFunctionParameters
1366         https://bugs.webkit.org/show_bug.cgi?id=145040
1367
1368         Reviewed by Mark Lam.
1369
1370         * parser/Parser.h:
1371         * parser/Parser.cpp:
1372
1373 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
1374
1375         Remove StoreBarrierWithNullCheck, nobody ever generates this.
1376
1377         Rubber stamped by Benjamin Poulain and Michael Saboff.
1378
1379         If we did bring something like this back in the future, we would just use UntypedUse instead
1380         of CellUse to indicate that this is what we want.
1381
1382         * dfg/DFGAbstractInterpreterInlines.h:
1383         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1384         * dfg/DFGClobberize.h:
1385         (JSC::DFG::clobberize):
1386         * dfg/DFGDoesGC.cpp:
1387         (JSC::DFG::doesGC):
1388         * dfg/DFGFixupPhase.cpp:
1389         (JSC::DFG::FixupPhase::fixupNode):
1390         * dfg/DFGNode.h:
1391         (JSC::DFG::Node::isStoreBarrier):
1392         * dfg/DFGNodeType.h:
1393         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1394         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1395         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1396         * dfg/DFGPredictionPropagationPhase.cpp:
1397         (JSC::DFG::PredictionPropagationPhase::propagate):
1398         * dfg/DFGSafeToExecute.h:
1399         (JSC::DFG::safeToExecute):
1400         * dfg/DFGSpeculativeJIT.cpp:
1401         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
1402         * dfg/DFGSpeculativeJIT32_64.cpp:
1403         (JSC::DFG::SpeculativeJIT::compile):
1404         * dfg/DFGSpeculativeJIT64.cpp:
1405         (JSC::DFG::SpeculativeJIT::compile):
1406         * ftl/FTLCapabilities.cpp:
1407         (JSC::FTL::canCompile):
1408         * ftl/FTLLowerDFGToLLVM.cpp:
1409         (JSC::FTL::LowerDFGToLLVM::compileNode):
1410         (JSC::FTL::LowerDFGToLLVM::compileStoreBarrierWithNullCheck): Deleted.
1411
1412 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
1413
1414         PutGlobalVar should reference the global object it's storing into
1415         https://bugs.webkit.org/show_bug.cgi?id=145036
1416
1417         Reviewed by Michael Saboff.
1418
1419         This makes it easier to reason about store barrier insertion and elimination. This changes
1420         the format of PutGlobalVar so that child1 is the global object and child2 is the value.
1421         Previously it just had child1, and that was the value.
1422
1423         * dfg/DFGByteCodeParser.cpp:
1424         (JSC::DFG::ByteCodeParser::parseBlock):
1425         * dfg/DFGClobberize.h:
1426         (JSC::DFG::clobberize):
1427         * dfg/DFGFixupPhase.cpp:
1428         (JSC::DFG::FixupPhase::fixupNode):
1429         * dfg/DFGSpeculativeJIT32_64.cpp:
1430         (JSC::DFG::SpeculativeJIT::compile):
1431         * dfg/DFGSpeculativeJIT64.cpp:
1432         (JSC::DFG::SpeculativeJIT::compile):
1433         * ftl/FTLLowerDFGToLLVM.cpp:
1434         (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
1435
1436 2015-05-14  Michael Catanzaro  <mcatanzaro@igalia.com>
1437
1438         [CMake] Error out when ruby is too old
1439         https://bugs.webkit.org/show_bug.cgi?id=145014
1440
1441         Reviewed by Martin Robinson.
1442
1443         Don't enforce the check for the Ruby executable here; it's now enforced in the top-level
1444         CMakeLists.txt instead.
1445
1446         * CMakeLists.txt:
1447
1448 2015-05-12  Basile Clement  <basile_clement@apple.com>
1449
1450         Enforce options coherency
1451         https://bugs.webkit.org/show_bug.cgi?id=144921
1452
1453         Reviewed by Mark Lam.
1454
1455         JavaScriptCore should be failing early when the options are set in such
1456         a way that we don't have a meaningful way to execute JavaScript, rather
1457         than failing for obscure reasons at some point during execution.
1458
1459         This patch adds a new function that checks whether the options are set
1460         in a coherent way, and makes JSC::Options::initialize() crash when the
1461         environment enforces incoherent options.
1462         Client applications able to add or change additional options are
1463         responsible to check for coherency again before starting to actually
1464         execute JavaScript, if any additional options have been set. This is
1465         implemented for the jsc executable in this patch.
1466
1467         * jsc.cpp:
1468         (CommandLine::parseArguments):
1469         * runtime/Options.cpp:
1470         (JSC::Options::initialize):
1471         (JSC::Options::ensureOptionsAreCoherent): Added.
1472         * runtime/Options.h:
1473         (JSC::Options::ensureOptionsAreCoherent): Added.
1474
1475 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1476
1477         REGRESSION (r184337): [EFL] unresolved reference errors in ARM builds
1478         https://bugs.webkit.org/show_bug.cgi?id=145019
1479
1480         Reviewed by Ryosuke Niwa.
1481
1482         Attempt to fix compile errors in EFL ARM buildbots.
1483         By executing `nm`, found JSTemplateRegistryKey.cpp.o and TemplateRegistry.cpp.o have
1484         unresolved reference to Structure::get. That is inlined function in StructureInlines.h.
1485
1486         * runtime/JSTemplateRegistryKey.cpp:
1487         * runtime/TemplateRegistry.cpp:
1488
1489 2015-05-14  Alexandr Skachkov  <gskachkov@gmail.com>
1490
1491         Small refactoring before implementation of the ES6 arrow function.
1492         https://bugs.webkit.org/show_bug.cgi?id=144954
1493
1494         Reviewed by Ryosuke Niwa.
1495
1496         * parser/Parser.h:
1497         * parser/Parser.cpp:
1498
1499 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1500
1501         REGRESSION (r184337): ASSERT failed in debug builds for tagged templates
1502         https://bugs.webkit.org/show_bug.cgi?id=145013
1503
1504         Reviewed by Filip Pizlo.
1505
1506         Fix the regression introduced by r184337.
1507
1508         1. JSTemporaryRegistryKey::s_info should inherit the Base::s_info,
1509            JSDestructibleObject::s_info.
1510
1511         2. The first register argument of BytecodeGenerator::emitNode
1512            should be a referenced register if it is a temporary register.
1513
1514         * bytecompiler/NodesCodegen.cpp:
1515         (JSC::TaggedTemplateNode::emitBytecode):
1516         * runtime/JSTemplateRegistryKey.cpp:
1517
1518 2015-05-14  Andreas Kling  <akling@apple.com>
1519
1520         String.prototype.split() should create efficient substrings.
1521         <https://webkit.org/b/144985>
1522         <rdar://problem/20949344>
1523
1524         Reviewed by Geoffrey Garen.
1525
1526         Teach split() how to make substring JSStrings instead of relying on StringImpl's
1527         substring sharing mechanism. The optimization works by deferring the construction
1528         of a StringImpl until the substring's value is actually needed.
1529
1530         This knocks ~2MB off of theverge.com by avoiding the extra StringImpl allocations.
1531         Out of ~70000 substrings created by split(), only ~2000 of them get reified.
1532
1533         * runtime/StringPrototype.cpp:
1534         (JSC::jsSubstring):
1535         (JSC::splitStringByOneCharacterImpl):
1536         (JSC::stringProtoFuncSplit):
1537
1538 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1539
1540         Change the status of ES6 tagged templates to Done in features.json
1541         https://bugs.webkit.org/show_bug.cgi?id=145003
1542
1543         Reviewed by Benjamin Poulain.
1544
1545         Now it's implemented in r184337.
1546
1547         * features.json:
1548
1549 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1550
1551         Introduce SymbolType into SpeculativeTypes
1552         https://bugs.webkit.org/show_bug.cgi?id=142651
1553
1554         Reviewed by Filip Pizlo.
1555
1556         Introduce SpecSymbol type into speculative types.
1557         Previously symbol type is categorized into SpecCellOther.
1558         But SpecCellOther is not intended to be used for such cells.
1559
1560         This patch just introduces SpecSymbol.
1561         It represents the type of target value is definitely the symbol type.
1562         It is the part of SpecCell.
1563
1564         In this patch, we do not introduce SymbolUse tracking.
1565         It will be added in the separate patch.
1566
1567         * bytecode/SpeculatedType.cpp:
1568         (JSC::dumpSpeculation):
1569         (JSC::speculationFromStructure):
1570         * bytecode/SpeculatedType.h:
1571         (JSC::isSymbolSpeculation):
1572         * dfg/DFGAbstractInterpreterInlines.h:
1573         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1574         * dfg/DFGAbstractValue.cpp:
1575         (JSC::DFG::AbstractValue::setType):
1576         * dfg/DFGConstantFoldingPhase.cpp:
1577         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1578         * tests/stress/typeof-symbol.js: Added.
1579
1580 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1581
1582         [ES6] Implement tagged templates
1583         https://bugs.webkit.org/show_bug.cgi?id=143183
1584
1585         Reviewed by Oliver Hunt.
1586
1587         This patch implements ES6 tagged templates.
1588         In tagged templates, the function takes the template object.
1589
1590         The template object contains the raw and cooked template strings,
1591         so when parsing the tagged templates, we need to tokenize the raw and cooked strings.
1592         While tagged templates require the both strings, the template literal only requires
1593         the cooked strings. So when tokenizing under the template literal context,
1594         we only builds the cooked strings.
1595
1596         As per ES6 spec, the template objects for the same raw strings are shared in the same realm.
1597         The template objects is cached. And every time we evaluate the same tagged templates,
1598         the same (cached) template objects are used.
1599         Since the spec freezes this template objects completely,
1600         we cannot attach some properties to it.
1601         So we can say that it behaves as if the template objects are the primitive values (like JSString).
1602         Since we cannot attach properties, the only way to test the identity of the template object is comparing. (===)
1603         As the result, when there is no reference to the template object, we can garbage collect it
1604         because the user has no way to test that the newly created template object does not equal
1605         to the already collected template object.
1606
1607         So, to implement tagged templates, we implement the following components.
1608
1609         1. JSTemplateRegistryKey
1610         It holds the template registry key and it does not exposed to users.
1611         TemplateRegistryKey holds the vector of raw and cooked strings with the pre-computed hash value.
1612         When obtaining the template object for the (statically, a.k.a. at the parsing time) given raw string vectors,
1613         we use this JSTemplateRegistryKey as a key to the map and look up the template object from
1614         TemplateRegistry.
1615         JSTemplateRegistryKey is created at the bytecode compiling time and
1616         stored in the CodeBlock as like as JSString content values.
1617
1618         2. TemplateRegistry
1619         This manages the cached template objects.
1620         It holds the weak map (JSTemplateRegistryKey -> the template object).
1621         The template object is weakly referenced.
1622         So if there is no reference to the template object,
1623         the template object is automatically GC-ed.
1624         When looking up the template object, it searches the cached template object.
1625         If it is found, it is returned to the users.
1626         If there is no cached template objects, it creates the new template object and
1627         stores it with the given template registry key.
1628
1629         * CMakeLists.txt:
1630         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1631         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1632         * JavaScriptCore.xcodeproj/project.pbxproj:
1633         * bytecompiler/BytecodeGenerator.cpp:
1634         (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
1635         (JSC::BytecodeGenerator::emitGetTemplateObject):
1636         * bytecompiler/BytecodeGenerator.h:
1637         * bytecompiler/NodesCodegen.cpp:
1638         (JSC::TaggedTemplateNode::emitBytecode):
1639         (JSC::TemplateLiteralNode::emitBytecode): Deleted.
1640         * parser/ASTBuilder.h:
1641         (JSC::ASTBuilder::createTaggedTemplate):
1642         (JSC::ASTBuilder::createTemplateLiteral): Deleted.
1643         * parser/Lexer.cpp:
1644         (JSC::Lexer<T>::setCode):
1645         (JSC::Lexer<T>::parseTemplateLiteral):
1646         (JSC::Lexer<T>::lex):
1647         (JSC::Lexer<T>::scanTrailingTemplateString):
1648         (JSC::Lexer<T>::clear):
1649         * parser/Lexer.h:
1650         (JSC::Lexer<T>::makeEmptyIdentifier):
1651         * parser/NodeConstructors.h:
1652         (JSC::TaggedTemplateNode::TaggedTemplateNode):
1653         (JSC::TemplateLiteralNode::TemplateLiteralNode): Deleted.
1654         * parser/Nodes.h:
1655         (JSC::TemplateLiteralNode::templateStrings):
1656         (JSC::TemplateLiteralNode::templateExpressions):
1657         (JSC::TaggedTemplateNode::templateLiteral):
1658         * parser/Parser.cpp:
1659         (JSC::Parser<LexerType>::parseTemplateString):
1660         (JSC::Parser<LexerType>::parseTemplateLiteral):
1661         (JSC::Parser<LexerType>::parsePrimaryExpression):
1662         (JSC::Parser<LexerType>::parseMemberExpression):
1663         * parser/Parser.h:
1664         * parser/ParserArena.h:
1665         (JSC::IdentifierArena::makeEmptyIdentifier):
1666         * parser/SyntaxChecker.h:
1667         (JSC::SyntaxChecker::createTaggedTemplate):
1668         (JSC::SyntaxChecker::createTemplateLiteral): Deleted.
1669         * runtime/CommonIdentifiers.h:
1670         * runtime/JSGlobalObject.cpp:
1671         (JSC::getTemplateObject):
1672         (JSC::JSGlobalObject::JSGlobalObject):
1673         (JSC::JSGlobalObject::init):
1674         * runtime/JSGlobalObject.h:
1675         (JSC::JSGlobalObject::templateRegistry):
1676         * runtime/JSTemplateRegistryKey.cpp: Added.
1677         (JSC::JSTemplateRegistryKey::JSTemplateRegistryKey):
1678         (JSC::JSTemplateRegistryKey::create):
1679         (JSC::JSTemplateRegistryKey::destroy):
1680         * runtime/JSTemplateRegistryKey.h: Added.
1681         * runtime/ObjectConstructor.cpp:
1682         (JSC::objectConstructorFreeze):
1683         * runtime/ObjectConstructor.h:
1684         * runtime/TemplateRegistry.cpp: Added.
1685         (JSC::TemplateRegistry::TemplateRegistry):
1686         (JSC::TemplateRegistry::getTemplateObject):
1687         * runtime/TemplateRegistry.h: Added.
1688         * runtime/TemplateRegistryKey.h: Added.
1689         (JSC::TemplateRegistryKey::isDeletedValue):
1690         (JSC::TemplateRegistryKey::isEmptyValue):
1691         (JSC::TemplateRegistryKey::hash):
1692         (JSC::TemplateRegistryKey::rawStrings):
1693         (JSC::TemplateRegistryKey::cookedStrings):
1694         (JSC::TemplateRegistryKey::operator==):
1695         (JSC::TemplateRegistryKey::operator!=):
1696         (JSC::TemplateRegistryKey::Hasher::hash):
1697         (JSC::TemplateRegistryKey::Hasher::equal):
1698         (JSC::TemplateRegistryKey::TemplateRegistryKey):
1699         * runtime/VM.cpp:
1700         (JSC::VM::VM):
1701         * runtime/VM.h:
1702         * tests/stress/tagged-templates-identity.js: Added.
1703         (shouldBe):
1704         * tests/stress/tagged-templates-raw-strings.js: Added.
1705         (shouldBe):
1706         (tag):
1707         (testEval):
1708         * tests/stress/tagged-templates-syntax.js: Added.
1709         (tag):
1710         (testSyntax):
1711         (testSyntaxError):
1712         * tests/stress/tagged-templates-template-object.js: Added.
1713         (shouldBe):
1714         (tag):
1715         * tests/stress/tagged-templates-this.js: Added.
1716         (shouldBe):
1717         (tag):
1718         * tests/stress/tagged-templates.js: Added.
1719         (shouldBe):
1720         (raw):
1721         (cooked):
1722         (Counter):
1723
1724 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
1725
1726         REGRESSION(r180595): same-callee profiling no longer works
1727         https://bugs.webkit.org/show_bug.cgi?id=144787
1728
1729         Reviewed by Filip Pizlo.
1730
1731         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
1732         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
1733         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
1734
1735         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
1736         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
1737         our speculation that the callee is the same. To avoid recompiling the same code for different callee
1738         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
1739         LLint and baseline JIT when multiple callees are observed.
1740
1741         Tests: stress/create-this-with-callee-variants.js
1742
1743         * bytecode/BytecodeList.json: Increased the number of operands to 5.
1744         * bytecode/CodeBlock.cpp:
1745         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
1746         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
1747         * bytecompiler/BytecodeGenerator.cpp:
1748         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
1749         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
1750         operand.
1751         * dfg/DFGByteCodeParser.cpp:
1752         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
1753         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
1754         * jit/JITOpcodes.cpp:
1755         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
1756         as seenMultipleCalleeObjects() to indicate the polymorphic behavior and/or we've OSR exited here.
1757         (JSC::JIT::emitSlow_op_create_this):
1758         * jit/JITOpcodes32_64.cpp:
1759         (JSC::JIT::emit_op_create_this): Ditto.
1760         (JSC::JIT::emitSlow_op_create_this):
1761         * llint/LowLevelInterpreter32_64.asm:
1762         (_llint_op_create_this): Ditto.
1763         * llint/LowLevelInterpreter64.asm:
1764         (_llint_op_create_this): Ditto.
1765         * runtime/CommonSlowPaths.cpp:
1766         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
1767         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
1768         * runtime/JSCell.h:
1769         (JSC::JSCell::seenMultipleCalleeObjects): Added.
1770         * runtime/WriteBarrier.h:
1771         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
1772         * tests/stress/create-this-with-callee-variants.js: Added.
1773
1774 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
1775
1776         Clean up some possible RefPtr to PassRefPtr churn
1777         https://bugs.webkit.org/show_bug.cgi?id=144779
1778
1779         Reviewed by Darin Adler.
1780
1781         * runtime/GenericTypedArrayViewInlines.h:
1782         (JSC::GenericTypedArrayView<Adaptor>::create):
1783         (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
1784         * runtime/JSArrayBufferConstructor.cpp:
1785         (JSC::constructArrayBuffer):
1786         * runtime/Structure.cpp:
1787         (JSC::Structure::toStructureShape):
1788         * runtime/TypedArrayBase.h:
1789         (JSC::TypedArrayBase::create):
1790         (JSC::TypedArrayBase::createUninitialized):
1791         * tools/FunctionOverrides.cpp:
1792         (JSC::initializeOverrideInfo):
1793         Release the last use of a RefPtr as it is passed on.
1794
1795 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
1796
1797         ES6: Allow duplicate property names
1798         https://bugs.webkit.org/show_bug.cgi?id=142895
1799
1800         Reviewed by Geoffrey Garen.
1801
1802         Introduce new `op_put_getter_by_id` and `op_put_setter_by_id` opcodes
1803         that will define a single getter or setter property on an object.
1804
1805         The existing `op_put_getter_setter` opcode is still preferred for
1806         putting both a getter and setter at the same time but cannot be used
1807         for putting an individual getter or setter which is needed in
1808         some cases.
1809
1810         Add a new slow path when generating bytecodes for a property list
1811         with computed properties, as computed properties are the only time
1812         the list of properties cannot be determined statically.
1813
1814         * bytecompiler/NodesCodegen.cpp:
1815         (JSC::PropertyListNode::emitBytecode):
1816         - fast path for all constant properties
1817         - slow but paired getter/setter path if there are no computed properties
1818         - slow path, individual put operation for every property, if there are computed properties
1819
1820         * parser/Nodes.h:
1821         Distinguish a Computed property from a Constant property.
1822
1823         * parser/Parser.cpp:
1824         (JSC::Parser<LexerType>::parseProperty):
1825         (JSC::Parser<LexerType>::parsePropertyMethod):
1826         Distingish Computed and Constant properties.
1827
1828         (JSC::Parser<LexerType>::parseObjectLiteral):
1829         When we drop into strict mode it is because we saw a getter
1830         or setter, so be more explicit.
1831
1832         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
1833         Eliminate duplicate property syntax error exception.
1834
1835         * parser/SyntaxChecker.h:
1836         (JSC::SyntaxChecker::getName):
1837         * parser/ASTBuilder.h:
1838         (JSC::ASTBuilder::getName): Deleted.
1839         No longer used.
1840
1841         * runtime/JSObject.h:
1842         (JSC::JSObject::putDirectInternal):
1843         When updating a property. If the Accessor attribute changed
1844         update the Structure.
1845
1846         * runtime/JSObject.cpp:
1847         (JSC::JSObject::putGetter):
1848         (JSC::JSObject::putSetter):
1849         Called by the opcodes, just perform the same operation that
1850         __defineGetter__ or __defineSetter__ would do.
1851
1852         (JSC::JSObject::putDirectNonIndexAccessor):
1853         This transition is now handled in putDirectInternal.
1854
1855         * runtime/Structure.h:
1856         Add needed export.
1857
1858         * bytecode/BytecodeList.json:
1859         * bytecode/BytecodeUseDef.h:
1860         (JSC::computeUsesForBytecodeOffset):
1861         (JSC::computeDefsForBytecodeOffset):
1862         * bytecode/CodeBlock.cpp:
1863         (JSC::CodeBlock::dumpBytecode):
1864         * bytecompiler/BytecodeGenerator.cpp:
1865         (JSC::BytecodeGenerator::emitPutGetterById):
1866         (JSC::BytecodeGenerator::emitPutSetterById):
1867         * bytecompiler/BytecodeGenerator.h:
1868         * jit/JIT.cpp:
1869         (JSC::JIT::privateCompileMainPass):
1870         * jit/JIT.h:
1871         * jit/JITInlines.h:
1872         (JSC::JIT::callOperation):
1873         * jit/JITOperations.cpp:
1874         * jit/JITOperations.h:
1875         * jit/JITPropertyAccess.cpp:
1876         (JSC::JIT::emit_op_put_getter_by_id):
1877         (JSC::JIT::emit_op_put_setter_by_id):
1878         * jit/JITPropertyAccess32_64.cpp:
1879         (JSC::JIT::emit_op_put_getter_by_id):
1880         (JSC::JIT::emit_op_put_setter_by_id):
1881         * llint/LLIntSlowPaths.cpp:
1882         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1883         * llint/LLIntSlowPaths.h:
1884         * llint/LowLevelInterpreter.asm:
1885         New bytecodes. Modelled after existing op_put_getter_setter.
1886
1887 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
1888
1889         Creating a new blank document in icloud pages causes an AI error: Abstract value (CellBytecodedoubleBoolOther, TOP, TOP) for double node has type outside SpecFullDouble.
1890         https://bugs.webkit.org/show_bug.cgi?id=144856
1891
1892         Reviewed by Benjamin Poulain.
1893
1894         First I made fixTypeForRepresentation() print out better diagnostics when it dies.
1895
1896         Then I fixed the bug: Node::convertToIdentityOn(Node*) needs to make sure that when it
1897         converts to a representation-changing node, it needs to use one of the UseKinds that such
1898         a node expects. For example, DoubleRep(UntypedUse:) doesn't make sense; it needs to be
1899         something like DoubleRep(NumberUse:) since it will speculate that the input is a number.
1900
1901         * dfg/DFGAbstractInterpreter.h:
1902         (JSC::DFG::AbstractInterpreter::setBuiltInConstant):
1903         * dfg/DFGAbstractInterpreterInlines.h:
1904         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1905         * dfg/DFGAbstractValue.cpp:
1906         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
1907         * dfg/DFGAbstractValue.h:
1908         * dfg/DFGInPlaceAbstractState.cpp:
1909         (JSC::DFG::InPlaceAbstractState::initialize):
1910         * dfg/DFGNode.cpp:
1911         (JSC::DFG::Node::convertToIdentityOn):
1912         * tests/stress/cloned-arguments-get-by-val-double-array.js: Added.
1913         (foo):
1914
1915 2015-05-13  Commit Queue  <commit-queue@webkit.org>
1916
1917         Unreviewed, rolling out r184313.
1918         https://bugs.webkit.org/show_bug.cgi?id=144974
1919
1920         Introduced an assertion failure in class-syntax-
1921         declaration.js, class-syntax-expression.js, and object-
1922         literal-syntax.js (Requested by rniwa on #webkit).
1923
1924         Reverted changeset:
1925
1926         "Small refactoring before ES6 Arrow function implementation."
1927         https://bugs.webkit.org/show_bug.cgi?id=144954
1928         http://trac.webkit.org/changeset/184313
1929
1930 2015-05-13  Oliver Hunt  <oliver@apple.com>
1931         Ensure that all the smart pointer types in WTF clear their pointer before deref
1932         https://bugs.webkit.org/show_bug.cgi?id=143789
1933
1934         Reviewed by Ryosuke Niwa.
1935
1936         One of the simpler cases of this in JavaScriptCore. There
1937         are other cases where we need to guard the derefs but they
1938         are more complex cases.
1939
1940         * inspector/JSInjectedScriptHost.cpp:
1941         (Inspector::JSInjectedScriptHost::releaseImpl):
1942         * inspector/JSJavaScriptCallFrame.cpp:
1943         (Inspector::JSJavaScriptCallFrame::releaseImpl):
1944
1945 2015-05-13  Alexandr Skachkov  <gskachkov@gmail.com>
1946
1947         Small refactoring before ES6 Arrow function implementation.
1948         https://bugs.webkit.org/show_bug.cgi?id=144954
1949
1950         Reviewed by Filip Pizlo.
1951
1952         * parser/Parser.h:
1953         * parser/Parser.cpp:
1954
1955 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
1956
1957         The liveness pruning done by ObjectAllocationSinkingPhase ignores the possibility of an object's bytecode liveness being longer than its DFG liveness
1958         https://bugs.webkit.org/show_bug.cgi?id=144945
1959
1960         Reviewed by Michael Saboff.
1961
1962         We were making the mistake of using DFG liveness for object allocation sinking decisions.
1963         This is wrong. In fact we almost never want to use DFG liveness directly. The only place
1964         where that makes sense is pruning in DFG AI.
1965
1966         So, I created a CombinedLiveness class that combines the DFG liveness with bytecode
1967         liveness.
1968
1969         In the process of doing this, I realized that the DFGForAllKills definition of combined
1970         liveness at block tail was not strictly right; it was using the bytecode liveness at the
1971         block terminal instead of the union of the bytecode live-at-heads of successor blocks. So,
1972         I changed DFGForAllKills to work in terms of CombinedLiveness.
1973
1974         This allows me to unskip the test I added in r184260. I also added a new test that tries to
1975         trigger this bug more directly.
1976
1977         * CMakeLists.txt:
1978         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1979         * JavaScriptCore.xcodeproj/project.pbxproj:
1980         * dfg/DFGArgumentsEliminationPhase.cpp:
1981         * dfg/DFGCombinedLiveness.cpp: Added.
1982         (JSC::DFG::liveNodesAtHead):
1983         (JSC::DFG::CombinedLiveness::CombinedLiveness):
1984         * dfg/DFGCombinedLiveness.h: Added.
1985         (JSC::DFG::CombinedLiveness::CombinedLiveness):
1986         * dfg/DFGForAllKills.h:
1987         (JSC::DFG::forAllKillsInBlock):
1988         (JSC::DFG::forAllLiveNodesAtTail): Deleted.
1989         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1990         (JSC::DFG::ObjectAllocationSinkingPhase::performSinking):
1991         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
1992         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
1993         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
1994         * tests/stress/escape-object-in-diamond-then-exit.js: Added.
1995         * tests/stress/sink-object-past-invalid-check-sneaky.js:
1996
1997 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
1998
1999         I skipped a wrong test in r184270. Fix that.
2000         The failure is tracked by webkit.org/b/144947.
2001
2002         * tests/stress/arith-modulo-node-behaviors.js:
2003         * tests/stress/arith-mul-with-constants.js:
2004
2005 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
2006
2007         Avoid always running some debug code in type profiling
2008         https://bugs.webkit.org/show_bug.cgi?id=144775
2009
2010         Reviewed by Daniel Bates.
2011
2012         * runtime/TypeProfilerLog.cpp:
2013         (JSC::TypeProfilerLog::processLogEntries):
2014
2015 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
2016
2017         Pass String as reference in more places
2018         https://bugs.webkit.org/show_bug.cgi?id=144769
2019
2020         Reviewed by Daniel Bates.
2021
2022         * debugger/Breakpoint.h:
2023         (JSC::Breakpoint::Breakpoint):
2024         * parser/Parser.h:
2025         (JSC::Parser::setErrorMessage):
2026         (JSC::Parser::updateErrorWithNameAndMessage):
2027         * parser/ParserError.h:
2028         (JSC::ParserError::ParserError):
2029         * runtime/RegExp.cpp:
2030         (JSC::RegExpFunctionalTestCollector::outputOneTest):
2031         * runtime/RegExpObject.cpp:
2032         (JSC::regExpObjectSourceInternal):
2033         * runtime/TypeProfiler.cpp:
2034         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
2035         * runtime/TypeProfilerLog.cpp:
2036         (JSC::TypeProfilerLog::processLogEntries):
2037         * runtime/TypeProfilerLog.h:
2038         * tools/FunctionOverrides.cpp:
2039         (JSC::initializeOverrideInfo):
2040         * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
2041         (ObjCConversionHelpersGenerator._generate_enum_from_protocol_string):
2042
2043         * inspector/scripts/codegen/objc_generator_templates.py:
2044         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2045         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2046         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
2047         * inspector/scripts/tests/expected/enum-values.json-result:
2048         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2049         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2050         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
2051         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2052         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
2053         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
2054         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
2055         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2056         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2057         Rebaseline tests after updating the generator.
2058
2059 2015-05-13  Michael Saboff  <msaboff@apple.com>
2060
2061         com.apple.WebKit.WebContent crashed at JavaScriptCore: JSC::CodeBlock::finalizeUnconditionally
2062         https://bugs.webkit.org/show_bug.cgi?id=144933
2063
2064         Changed the RELEASE_ASSERT_NOT_REACHED into an ASSERT.  Added some diagnostic messages to
2065         help determine the cause for any crash.
2066
2067         Reviewed by Geoffrey Garen.
2068
2069         * bytecode/CodeBlock.cpp:
2070         (JSC::CodeBlock::finalizeUnconditionally):
2071
2072 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
2073
2074         REGRESSION(r184260): arguments elimination has stopped working because of Check(UntypedUse:) from SSAConversionPhase
2075         https://bugs.webkit.org/show_bug.cgi?id=144951
2076
2077         Reviewed by Michael Saboff.
2078
2079         There were two issues here:
2080
2081         - In r184260 we expected a small number of possible use kinds in Check nodes, and
2082           UntypedUse was not one of them. That seemed like a sensible assumption because we don't
2083           create Check nodes unless it's to have a check. But, SSAConversionPhase was creating a
2084           Check that could have UntypedUse. I fixed this. It's cleaner for SSAConversionPhase to
2085           follow the same idiom as everyone else and not create tautological checks.
2086
2087         - It's clearly not very robust to assume that Checks will not be used tautologically. So,
2088           this changes how we validate Checks in the escape analyses. We now use willHaveCheck,
2089           which catches cases that AI would have already marked as unnecessary. It then also uses
2090           a new helper called alreadyChecked(), which allows us to just ask if the check is
2091           unnecessary for objects. That's a good fall-back in case AI hadn't run yet.
2092
2093         * dfg/DFGArgumentsEliminationPhase.cpp:
2094         * dfg/DFGMayExit.cpp:
2095         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2096         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2097         * dfg/DFGSSAConversionPhase.cpp:
2098         (JSC::DFG::SSAConversionPhase::run):
2099         * dfg/DFGUseKind.h:
2100         (JSC::DFG::alreadyChecked):
2101         * dfg/DFGVarargsForwardingPhase.cpp:
2102
2103 k
2104 2015-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>
2105
2106         [ES6] Implement String.raw
2107         https://bugs.webkit.org/show_bug.cgi?id=144330
2108
2109         Reviewed by Filip Pizlo.
2110
2111         Implement String.raw. It is intended to be used with tagged-templates syntax.
2112         To implement ToString abstract operation efficiently,
2113         we introduce @toString bytecode intrinsic. It emits op_to_string directly.
2114
2115         * CMakeLists.txt:
2116         * builtins/StringConstructor.js: Added.
2117         (raw):
2118         * bytecompiler/NodesCodegen.cpp:
2119         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
2120         * runtime/CommonIdentifiers.h:
2121         * runtime/StringConstructor.cpp:
2122         * tests/stress/string-raw.js: Added.
2123         (shouldBe):
2124         (.get shouldBe):
2125         (Counter):
2126
2127 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
2128
2129         Temporarily disable the test on Windows. The failure is tracked in webkit.org/b/144897.
2130
2131         * tests/stress/arith-mul-with-constants.js:
2132
2133 2015-05-12  Filip Pizlo  <fpizlo@apple.com>
2134
2135         js/dom/stack-trace.html fails with eager compilation
2136         https://bugs.webkit.org/show_bug.cgi?id=144853
2137
2138         Reviewed by Benjamin Poulain.
2139
2140         All of our escape analyses were mishandling Check(). They were assuming that this is a
2141         non-escaping operation. But, if we do for example a Check(Int32:@x) and @x is an escape
2142         candidate, then we need to do something: if we eliminate or sink @x, then the check no
2143         longer makes any sense since a phantom allocation has no type. This will make us forget
2144         that this operation would have exited. This was causing us to not call a valueOf method in
2145         js/dom/stack-trace.html with eager compilation enabled, because it was doing something like
2146         +o where o had a valueOf method, and o was otherwise sinkable.
2147
2148         This changes our escape analyses to basically pretend that any Check() that isn't obviously
2149         unnecessary is an escape. We don't have to be super careful here. Most checks will be
2150         completely eliminated by constant-folding. If that doesn't run in time, then the most
2151         common check we will see is CellUse. So, we just recognize some very obvious check kinds
2152         that we know would have passed, and for all of the rest we just assume that it's an escape.
2153
2154         This was super tricky to test. The obvious way to test it is to use +o like
2155         stack-trace.html, except that doing so relies on the fact that we still haven't implemented
2156         the optimal behavior for op_to_number. So, I take four approaches in testing this patch:
2157
2158         1) Use +o. These will test what we want it to test for now, but at some point in the future
2159            these tests will just be a good sanity-check that our op_to_number implementation is
2160            right.
2161
2162         2) Do fancy control flow tricks to fool the profiling into thinking that some arithmetic
2163            operation always sees integers even though we eventually feed it an object and that
2164            object is a sink candidate.
2165
2166         3) Introduce a new jsc.cpp intrinsic called isInt32() which returns true if the incoming
2167            value is an int32. This intrinsic is required to be implemented by DFG by
2168            unconditionally speculating that the input is int32. This allows us to write much more
2169            targetted tests of the underlying issue.
2170
2171         4) I made a version of stack-trace.html that runs in run-jsc-stress-tests, so that we can
2172            get regression test coverage of this test in eager mode.
2173
2174         * dfg/DFGArgumentsEliminationPhase.cpp:
2175         * dfg/DFGByteCodeParser.cpp:
2176         (JSC::DFG::ByteCodeParser::handleIntrinsic):
2177         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2178         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2179         * dfg/DFGVarargsForwardingPhase.cpp:
2180         * ftl/FTLExitValue.cpp:
2181         (JSC::FTL::ExitValue::dumpInContext):
2182         * ftl/FTLLowerDFGToLLVM.cpp:
2183         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2184         * ftl/FTLOSRExitCompiler.cpp:
2185         (JSC::FTL::compileFTLOSRExit):
2186         * jsc.cpp:
2187         (GlobalObject::finishCreation):
2188         (functionIsInt32):
2189         * runtime/Intrinsic.h:
2190         * tests/stress/sink-arguments-past-invalid-check-dfg.js: Added.
2191         * tests/stress/sink-arguments-past-invalid-check-int32-dfg.js: Added.
2192         * tests/stress/sink-arguments-past-invalid-check-int32.js: Added.
2193         * tests/stress/sink-arguments-past-invalid-check-sneakier.js: Added.
2194         * tests/stress/sink-arguments-past-invalid-check.js: Added.
2195         * tests/stress/sink-function-past-invalid-check-sneakier.js: Added.
2196         * tests/stress/sink-function-past-invalid-check-sneaky.js: Added.
2197         * tests/stress/sink-object-past-invalid-check-int32.js: Added.
2198         * tests/stress/sink-object-past-invalid-check-sneakier.js: Added.
2199         * tests/stress/sink-object-past-invalid-check-sneaky.js: Added.
2200         * tests/stress/sink-object-past-invalid-check.js: Added.
2201
2202 2015-05-12  Benjamin Poulain  <benjamin@webkit.org>
2203
2204         Fix the iteration count of arith-modulo-node-behaviors.js
2205
2206         * tests/stress/arith-modulo-node-behaviors.js:
2207         No need for big numbers for the real testing.
2208
2209 2015-05-12  Mark Lam  <mark.lam@apple.com>
2210
2211         Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of another thread.
2212         https://bugs.webkit.org/show_bug.cgi?id=144924
2213
2214         Reviewed by Alex Christensen.
2215
2216         The present stack scanning code in the Windows port is expecting that the
2217         GetCurrentThread() API will provide a unique HANDLE for each thread.  The code
2218         then saves and later uses that HANDLE with GetThreadContext() to get the
2219         runtime state of the target thread from the GC thread.  According to
2220         https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx,
2221         GetCurrentThread() does not provide this unique HANDLE that we expect:
2222
2223             "The function cannot be used by one thread to create a handle that can
2224             be used by other threads to refer to the first thread. The handle is
2225             always interpreted as referring to the thread that is using it. A
2226             thread can create a "real" handle to itself that can be used by other
2227             threads, or inherited by other processes, by specifying the pseudo
2228             handle as the source handle in a call to the DuplicateHandle function."
2229
2230         As a result of this, GetCurrentThread() always returns the same HANDLE value, and
2231         we end up never scanning the stacks of other threads because we wrongly think that
2232         they are all equal (in identity) to the scanning thread.  This, in turn, results
2233         in crashes due to objects that are incorrectly collected.
2234
2235         The fix is to call DuplicateHandle() to create a HANDLE that we can use.  The
2236         MachineThreads::Thread class already accurately tracks the period of time when
2237         we need that HANDLE for the VM.  Hence, the life-cycle of the HANDLE can be tied
2238         to the life-cycle of the MachineThreads::Thread object for the corresponding thread.
2239
2240         * heap/MachineStackMarker.cpp:
2241         (JSC::getCurrentPlatformThread):
2242         (JSC::MachineThreads::Thread::Thread):
2243         (JSC::MachineThreads::Thread::~Thread):
2244         (JSC::MachineThreads::Thread::suspend):
2245         (JSC::MachineThreads::Thread::resume):
2246         (JSC::MachineThreads::Thread::getRegisters):
2247
2248 2015-05-12  Benjamin Poulain  <bpoulain@apple.com>
2249
2250         [JSC] Make the NegZero backward propagated flags of ArithMod stricter
2251         https://bugs.webkit.org/show_bug.cgi?id=144897
2252
2253         Reviewed by Geoffrey Garen.
2254
2255         The NegZero flags of ArithMod were the same as ArithDiv: both children were
2256         marked as needing to handle NegativeZero.
2257
2258         Lucky for us, ArithMod is quite a bit different than ArithDiv.
2259
2260         First, the sign of the result is completely independent from
2261         the sign of the divisor. A zero on the divisor always produces a NaN.
2262         That's great, we can remove the NodeBytecodeNeedsNegZero
2263         from the flags propagated to child2.
2264
2265         Second, the sign of the result is always the same as the sign of
2266         the dividend. A dividend of zero produces a zero of same sign
2267         unless the divisor is zero (in which case the result is NaN).
2268         This is great too: we can just pass the flags we got into
2269         ArithMod.
2270
2271         With those two out of the way, we can make a faster version of ArithRound
2272         for Kraken's oscillator. Since we no longer care about negative zero,
2273         rounding becomes cast<int32>(value + 0.5). This gives ~3% faster runtime
2274         on the benchmark.
2275
2276         Unfortunatelly, most of the time is spent in FTL and the same optimization
2277         does not apply well just yet: rdar://problem/20904149.
2278
2279         * dfg/DFGBackwardsPropagationPhase.cpp:
2280         (JSC::DFG::BackwardsPropagationPhase::propagate):
2281         Never add NodeBytecodeNeedsNegZero unless needed by the users of this node.
2282
2283         * dfg/DFGSpeculativeJIT.cpp:
2284         (JSC::DFG::SpeculativeJIT::compileArithRound):
2285         Faster Math.round() when negative zero is not important.
2286
2287         * tests/stress/arith-modulo-node-behaviors.js: Added.
2288         (moduloWithNegativeZeroDividend):
2289         (moduloWithUnusedNegativeZeroDividend):
2290         (moduloWithNegativeZeroDivisor):
2291
2292 2015-05-12  Mark Lam  <mark.lam@apple.com>
2293
2294         Refactor MachineStackMarker.cpp so that it's easier to reason about MachineThreads::Thread.
2295         https://bugs.webkit.org/show_bug.cgi?id=144925
2296
2297         Reviewed by Michael Saboff.
2298
2299         Currently, the code in MachineStackMarker.cpp is written as a bunch of functions that
2300         operate on the platformThread value in the MachineThreads::Thread struct.  Instead, we
2301         can apply better OO encapsulation and convert all these functions into methods of the
2302         MachineThreads::Thread struct.
2303
2304         This will also make it easier to reason about the fix for
2305         https://bugs.webkit.org/show_bug.cgi?id=144924 later.
2306
2307         * heap/MachineStackMarker.cpp:
2308         (JSC::getCurrentPlatformThread):
2309         (JSC::MachineThreads::Thread::createForCurrentThread):
2310         (JSC::MachineThreads::Thread::operator!=):
2311         (JSC::MachineThreads::Thread::operator==):
2312         (JSC::MachineThreads::addCurrentThread):
2313         (JSC::MachineThreads::removeThreadIfFound):
2314         (JSC::MachineThreads::Thread::suspend):
2315         (JSC::MachineThreads::Thread::resume):
2316         (JSC::MachineThreads::Thread::getRegisters):
2317         (JSC::MachineThreads::Thread::Registers::stackPointer):
2318         (JSC::MachineThreads::Thread::freeRegisters):
2319         (JSC::MachineThreads::Thread::captureStack):
2320         (JSC::MachineThreads::tryCopyOtherThreadStack):
2321         (JSC::MachineThreads::tryCopyOtherThreadStacks):
2322         (JSC::equalThread): Deleted.
2323         (JSC::suspendThread): Deleted.
2324         (JSC::resumeThread): Deleted.
2325         (JSC::getPlatformThreadRegisters): Deleted.
2326         (JSC::otherThreadStackPointer): Deleted.
2327         (JSC::freePlatformThreadRegisters): Deleted.
2328         (JSC::otherThreadStack): Deleted.
2329
2330 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
2331
2332         Array.slice should have a fast path like Array.splice
2333         https://bugs.webkit.org/show_bug.cgi?id=144901
2334
2335         Reviewed by Geoffrey Garen.
2336
2337         Add a fast memcpy path to Array.prototype.slice as done for Array.prototype.splice.
2338         In Kraken, this appears to be 30% win on stanford-crypto-ccm and 10% win on stanford-crypto-pbkdf2.
2339
2340         * runtime/ArrayPrototype.cpp:
2341         (JSC::arrayProtoFuncSlice):
2342         * runtime/JSArray.cpp:
2343         (JSC::JSArray::fastSlice): Added.
2344         * runtime/JSArray.h:
2345
2346 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
2347
2348         OSR availability analysis would be more scalable (and correct) if it did more liveness pruning
2349         https://bugs.webkit.org/show_bug.cgi?id=143078
2350
2351         Reviewed by Andreas Kling.
2352
2353         In https://bugs.webkit.org/show_bug.cgi?id=144883, we found an example of where liveness
2354         pruning is actually necessary. Well, not quite: we just need to prune out keys from the
2355         heap availability map where the base node doesn't dominate the point where we are asking
2356         for availability. If we don't do this, then eventually the IR gets corrupt because we'll
2357         insert PutHints that reference the base node in places where the base node doesn't
2358         dominate. But if we're going to do any pruning, then it makes sense to prune by bytecode
2359         liveness. This is the strongest possible pruning we can do, and it should be sound. We
2360         shouldn't have a node available for a virtual register if that register is live and the
2361         node doesn't dominate.
2362
2363         Making this work meant reusing the prune-to-liveness algorithm from the FTL backend. So, I
2364         abstracted this a bit better. You can now availabilityMap.pruneByLiveness(graph, origin).
2365
2366         * dfg/DFGAvailabilityMap.cpp:
2367         (JSC::DFG::AvailabilityMap::pruneHeap):
2368         (JSC::DFG::AvailabilityMap::pruneByLiveness):
2369         (JSC::DFG::AvailabilityMap::prune): Deleted.
2370         * dfg/DFGAvailabilityMap.h:
2371         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
2372         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
2373         * ftl/FTLLowerDFGToLLVM.cpp:
2374         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2375         * tests/stress/liveness-pruning-needed-for-osr-availability.js: Added. This is a proper regression test.
2376         * tests/stress/liveness-pruning-needed-for-osr-availability-eager.js: Added. This is the original reduced test case, requires eager-no-cjit to fail prior to this changeset.
2377
2378 2015-05-12  Gabor Loki  <loki@webkit.org>
2379
2380         Workaround for Cortex-A53 erratum 843419
2381         https://bugs.webkit.org/show_bug.cgi?id=144680
2382
2383         Reviewed by Michael Saboff.
2384
2385         This patch is about to give simple workaround for Cortex-A53 erratum 843419.
2386         It inserts nops after ADRP instruction to avoid wrong address accesses.
2387
2388         * assembler/ARM64Assembler.h:
2389         (JSC::ARM64Assembler::adrp):
2390         (JSC::ARM64Assembler::nopCortexA53Fix843419):
2391
2392 2015-05-11  Commit Queue  <commit-queue@webkit.org>
2393
2394         Unreviewed, rolling out r184009.
2395         https://bugs.webkit.org/show_bug.cgi?id=144900
2396
2397         Caused crashes on inspector tests (Requested by ap on
2398         #webkit).
2399
2400         Reverted changeset:
2401
2402         "MapDataImpl::add() shouldn't do the same hash lookup twice."
2403         https://bugs.webkit.org/show_bug.cgi?id=144759
2404         http://trac.webkit.org/changeset/184009
2405
2406 2015-05-11  Commit Queue  <commit-queue@webkit.org>
2407
2408         Unreviewed, rolling out r184123.
2409         https://bugs.webkit.org/show_bug.cgi?id=144899
2410
2411         Seems to have introduced flaky crashes in many JS tests
2412         (Requested by rniwa on #webkit).
2413
2414         Reverted changeset:
2415
2416         "REGRESSION(r180595): same-callee profiling no longer works"
2417         https://bugs.webkit.org/show_bug.cgi?id=144787
2418         http://trac.webkit.org/changeset/184123
2419
2420 2015-05-11  Brent Fulgham  <bfulgham@apple.com>
2421
2422         [Win] Move Windows build target to Windows 7 (or newer)
2423         https://bugs.webkit.org/show_bug.cgi?id=144890
2424         <rdar://problem/20707307>
2425
2426         Reviewed by Anders Carlsson.
2427
2428         Update linked SDK and minimal Windows level to be compatible with
2429         Windows 7 or newer.
2430
2431         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2432         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2433         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
2434         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
2435         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
2436         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
2437         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
2438         * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
2439         * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj:
2440         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
2441         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj:
2442         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
2443         * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
2444         * config.h:
2445
2446 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
2447
2448         CPS rethreading phase's flush detector flushes way too many SetLocals
2449         https://bugs.webkit.org/show_bug.cgi?id=144819
2450
2451         Reviewed by Geoffrey Garen.
2452
2453         After probably unrelated changes, this eventually caused some arguments elimination to stop
2454         working because it would cause more SetLocals to turn into PutStacks. But it was a bug for
2455         a long time. Basically, we don't want the children of a SetLocal to be flushed. Flushing is
2456         meant to only affect the SetLocal itself.
2457
2458         This is a speed-up on Octane/earley.
2459
2460         * dfg/DFGCPSRethreadingPhase.cpp:
2461         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
2462
2463 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
2464
2465         gmail and google maps fail to load with eager compilation: Failed to insert inline cache for varargs call (specifically, CallForwardVarargs) because we thought the size would be 250 but it ended up being 262 prior to compaction.
2466         https://bugs.webkit.org/show_bug.cgi?id=144854
2467
2468         Reviewed by Oliver Hunt.
2469
2470         This is easy: just lift the threshold. Also remove the need for some duplicate thresholds.
2471         It used to be that Construct required less code, but that's not the case for now.
2472
2473         * ftl/FTLInlineCacheSize.cpp:
2474         (JSC::FTL::sizeOfCallForwardVarargs):
2475         (JSC::FTL::sizeOfConstructVarargs):
2476         (JSC::FTL::sizeOfConstructForwardVarargs):
2477
2478 2015-05-11  Ryosuke Niwa  <rniwa@webkit.org>
2479
2480         REGRESSION(r180595): same-callee profiling no longer works
2481         https://bugs.webkit.org/show_bug.cgi?id=144787
2482
2483         Reviewed by Michael Saboff.
2484
2485         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
2486         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
2487         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
2488
2489         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
2490         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
2491         our speculation that the callee is the same. To avoid recompiling the same code for different callee
2492         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
2493         LLint and baseline JIT when multiple callees are observed.
2494
2495         Tests: stress/create-this-with-callee-variants.js
2496
2497         * bytecode/BytecodeList.json: Increased the number of operands to 5.
2498         * bytecode/BytecodeUseDef.h:
2499         (JSC::computeUsesForBytecodeOffset): op_create_this uses 2nd (constructor) and 4th (callee cache)
2500         operands.
2501         * bytecode/CodeBlock.cpp:
2502         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
2503         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
2504         * bytecompiler/BytecodeGenerator.cpp:
2505         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
2506         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
2507         operand.
2508         * dfg/DFGByteCodeParser.cpp:
2509         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
2510         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
2511         * jit/JITOpcodes.cpp:
2512         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
2513         as seenMultipleCalleeObjects() to indicate the polymorphic behavior.
2514         (JSC::JIT::emitSlow_op_create_this):
2515         * jit/JITOpcodes32_64.cpp:
2516         (JSC::JIT::emit_op_create_this): Ditto.
2517         (JSC::JIT::emitSlow_op_create_this):
2518         * llint/LowLevelInterpreter32_64.asm:
2519         (_llint_op_create_this): Ditto.
2520         * llint/LowLevelInterpreter64.asm:
2521         (_llint_op_create_this): Ditto.
2522         * runtime/CommonSlowPaths.cpp:
2523         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
2524         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
2525         * runtime/JSCell.h:
2526         (JSC::JSCell::seenMultipleCalleeObjects): Added.
2527         * runtime/WriteBarrier.h:
2528         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
2529         * tests/stress/create-this-with-callee-variants.js: Added.
2530
2531 2015-05-11  Andreas Kling  <akling@apple.com>
2532
2533         PropertyNameArray should use a Vector when there are few entries.
2534         <https://webkit.org/b/144874>
2535
2536         Reviewed by Geoffrey Garen.
2537
2538         Bring back an optimization that was lost in the for-in refactoring.
2539         PropertyNameArray now holds a Vector<AtomicStringImpl*> until there are
2540         enough (20) entries to justify converting to a HashSet for contains().
2541
2542         Also inlined the code while we're here, since it has so few clients and
2543         the call overhead adds up.
2544
2545         ~5% progression on Kraken/json-stringify-tinderbox.
2546
2547         * runtime/PropertyNameArray.cpp: Removed.
2548         * runtime/PropertyNameArray.h:
2549         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
2550         (JSC::PropertyNameArray::add):
2551         (JSC::PropertyNameArray::addKnownUnique):
2552
2553 2015-05-11  Matt Baker  <mattbaker@apple.com>
2554
2555         Web Inspector: REGRESSION (r175203): No profile information is shown in Inspector
2556         https://bugs.webkit.org/show_bug.cgi?id=144808
2557
2558         Reviewed by Darin Adler.
2559
2560         Since a profile can be started after a timeline recording has already begun, we can't assume a zero start time.
2561         The start time for the root node's call entry should be based on the stopwatch used by the ProfileGenerator.
2562
2563         * profiler/Profile.cpp:
2564         (JSC::Profile::create):
2565         (JSC::Profile::Profile):
2566         * profiler/Profile.h:
2567         * profiler/ProfileGenerator.cpp:
2568         (JSC::ProfileGenerator::ProfileGenerator):
2569         (JSC::AddParentForConsoleStartFunctor::operator()):
2570
2571 2015-05-11  Basile Clement  <basile_clement@apple.com>
2572
2573         Unreviewed, remove unintended change.
2574
2575         * dfg/DFGAbstractInterpreterInlines.h:
2576         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2577
2578 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
2579
2580         Make it easy to enable eager/non-concurrent JIT compilation
2581         https://bugs.webkit.org/show_bug.cgi?id=144877
2582
2583         Reviewed by Michael Saboff.
2584
2585         * runtime/Options.cpp:
2586         (JSC::recomputeDependentOptions):
2587         * runtime/Options.h:
2588
2589 2015-05-10  Filip Pizlo  <fpizlo@apple.com>
2590
2591         We shouldn't promote LoadVarargs to a sequence of GetStacks and PutStacks if doing so would exceed the LoadVarargs' limit
2592         https://bugs.webkit.org/show_bug.cgi?id=144851
2593
2594         Reviewed by Michael Saboff.
2595
2596         LoadVarargs loads arguments from some object and puts them on the stack. The region of
2597         stack is controlled by a bunch of meta-data, including InlineCallFrame. InlineCallFrame
2598         shouldn't really be edited after ByteCodeParser, so we cannot convert LoadVarargs to
2599         something that uses more stack than the LoadVarargs wanted to.
2600
2601         This check was missing in the ArgumentsEliminationPhase's LoadVarargs->GetStack+PutStack
2602         promoter. This is an important promotion rule for performance, and in cases where we are
2603         compiling truly hot code, the LoadVarargs limit will be at least as big as the length of
2604         the phantom arguments array that this phase sees. The LoadVarargs limit is based on
2605         profiling and the phantom arguments array is a proof; in most cases the profiling is more
2606         conservative.
2607
2608         But, you could write some crazy code where the statically obvious arguments array value is
2609         bigger than what the profiling would have told you. When this happens, this promotion
2610         effectively removes a bounds check. This either results in us clobbering a bunch of stack,
2611         or it means that we never initialize a region of the stack that a later operation will read
2612         (the uninitialization happens because PutStackSinkingPhase removes PutStacks that appear
2613         unnecessary, and a GetMyArgumentByVal will claim not to use the region of the stack outside
2614         the original LoadVarargs limit).
2615
2616         * dfg/DFGArgumentsEliminationPhase.cpp:
2617         * tests/stress/load-varargs-elimination-bounds-check-barely.js: Added.
2618         (foo):
2619         (bar):
2620         (baz):
2621         * tests/stress/load-varargs-elimination-bounds-check.js: Added.
2622         (foo):
2623         (bar):
2624         (baz):
2625
2626 2015-05-11  Andreas Kling  <akling@apple.com>
2627
2628         JSON.stringify shouldn't use generic get() to access Array.length
2629         <https://webkit.org/b/144847>
2630
2631         Reviewed by Geoffrey Garen.
2632
2633         If the value being serialized is a JSArray object, we can downcast and call its
2634         length() directly instead of doing a generic property lookup.
2635
2636         0.5% progression on Kraken/json-stringify-tinderbox.
2637
2638         * runtime/JSONObject.cpp:
2639         (JSC::Stringifier::Holder::appendNextProperty):
2640
2641 2015-05-10  Andreas Kling  <akling@apple.com>
2642
2643         Remove unnecessary AtomicStringImpl* hash specification in PropertyNameArray.
2644
2645         Follow up to r184050 suggested by Darin.
2646
2647         * runtime/PropertyNameArray.h:
2648
2649 2015-05-10  Andreas Kling  <akling@apple.com>
2650
2651         Remove unused things from PropertyNameArray.
2652         <https://webkit.org/b/144834>
2653
2654         Reviewed by Filip Pizlo.
2655
2656         PropertyNameArray had a bunch of bells and whistles added to it when for-in iteration
2657         was refactored and optimized last year. Then more refactoring happened and this class
2658         doesn't need to ring and toot anymore.
2659
2660         The RefCountedIdentifierSet class disappears since the JSPropertyNameEnumerator wasn't
2661         actually using it for anything and we were just wasting time creating these.
2662
2663         Also made the member functions take AtomicStringImpl* instead of plain StringImpl*.
2664
2665         * runtime/JSObject.cpp:
2666         (JSC::JSObject::getPropertyNames):
2667         * runtime/JSPropertyNameEnumerator.cpp:
2668         (JSC::JSPropertyNameEnumerator::create):
2669         (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
2670         * runtime/JSPropertyNameEnumerator.h:
2671         * runtime/PropertyNameArray.cpp:
2672         (JSC::PropertyNameArray::add):
2673         (JSC::PropertyNameArray::setPreviouslyEnumeratedProperties): Deleted.
2674         * runtime/PropertyNameArray.h:
2675         (JSC::PropertyNameArray::PropertyNameArray):
2676         (JSC::PropertyNameArray::add):
2677         (JSC::PropertyNameArray::addKnownUnique):
2678         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
2679         (JSC::RefCountedIdentifierSet::contains): Deleted.
2680         (JSC::RefCountedIdentifierSet::size): Deleted.
2681         (JSC::RefCountedIdentifierSet::add): Deleted.
2682         (JSC::PropertyNameArray::identifierSet): Deleted.
2683         (JSC::PropertyNameArray::numCacheableSlots): Deleted.
2684         (JSC::PropertyNameArray::setNumCacheableSlotsForObject): Deleted.
2685         (JSC::PropertyNameArray::setBaseObject): Deleted.
2686         (JSC::PropertyNameArray::setPreviouslyEnumeratedLength): Deleted.
2687
2688 2015-05-09  Yoav Weiss  <yoav@yoav.ws>
2689
2690         Remove the PICTURE_SIZES build flag
2691         https://bugs.webkit.org/show_bug.cgi?id=144679
2692
2693         Reviewed by Benjamin Poulain.
2694
2695         Removed the PICTURE_SIZES build time flag.
2696
2697         * Configurations/FeatureDefines.xcconfig:
2698
2699 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
2700
2701         Extend the SaneChain optimization to Contiguous arrays
2702         https://bugs.webkit.org/show_bug.cgi?id=144664
2703
2704         Reviewed by Mark Lam.
2705
2706         Previously if you loaded from a hole, you'd either have to take slow path for the array
2707         load (which means C++ calls and prototype chain walks) or you'd exit (if you hadn't
2708         gathered the necessary profiling yet). But that's unnecessary if we know that the
2709         prototype chain is sane - i.e. has no indexed properties. Then we can just return
2710         Undefined for the hole.
2711
2712         Making this change requires setting more watchpoints on the array prototype chain. But
2713         that hit a horrible bug: ArrayPrototype still uses the static lookup tables and builds
2714         itself up lazily. This means that this increased the number of recompilations we'd get
2715         due to the array prototype chain being built up.
2716
2717         So, this change also removes the laziness and static tables from ArrayPrototype.
2718
2719         But to make that change, I also had to add a helper for eagerly building up a prototype
2720         that has builtin functions.
2721
2722         * CMakeLists.txt:
2723         * DerivedSources.make:
2724         * dfg/DFGArrayMode.h:
2725         * dfg/DFGFixupPhase.cpp:
2726         (JSC::DFG::FixupPhase::fixupNode):
2727         * dfg/DFGSpeculativeJIT32_64.cpp:
2728         (JSC::DFG::SpeculativeJIT::compile):
2729         * dfg/DFGSpeculativeJIT64.cpp:
2730         (JSC::DFG::SpeculativeJIT::compile):
2731         * ftl/FTLLowerDFGToLLVM.cpp:
2732         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
2733         * runtime/ArrayPrototype.cpp:
2734         (JSC::ArrayPrototype::finishCreation):
2735         (JSC::ArrayPrototype::getOwnPropertySlot): Deleted.
2736         * runtime/ArrayPrototype.h:
2737         * runtime/JSObject.h:
2738
2739 2015-05-08  Michael Saboff  <msaboff@apple.com>
2740
2741         Creating a large MarkedBlock sometimes results in more than one cell in the block
2742         https://bugs.webkit.org/show_bug.cgi?id=144815
2743
2744         Reviewed by Mark Lam.
2745
2746         Large MarkedBlocks should have one and only one cell.  Changed the calculation of
2747         m_endAtom for large blocks to use the location of the first cell + 1.  This
2748         assures that large blocks only have one cell.
2749
2750         * heap/MarkedBlock.cpp:
2751         (JSC::MarkedBlock::MarkedBlock):
2752
2753 2015-05-08  Oliver Hunt  <oliver@apple.com>
2754
2755         MapDataImpl::add() shouldn't do the same hash lookup twice.
2756         https://bugs.webkit.org/show_bug.cgi?id=144759
2757
2758         Reviewed by Gavin Barraclough.
2759
2760         We don't actually need to do a double lookup here, all we need to
2761         do is update the index to point to the correct m_size.
2762
2763         * runtime/MapDataInlines.h:
2764         (JSC::JSIterator>::add):
2765
2766 2015-05-08  Andreas Kling  <akling@apple.com>
2767
2768         Micro-optimize JSON serialization of string primitives.
2769         <https://webkit.org/b/144800>
2770
2771         Reviewed by Sam Weinig.
2772
2773         Don't use the out-of-line JSValue::getString() to grab at string primitives
2774         in serialization. Just check if it's a JSString and then downcast to grab at
2775         the WTF::String inside.
2776
2777         2% progression on Kraken/json-stringify-tinderbox.
2778
2779         * runtime/JSONObject.cpp:
2780         (JSC::Stringifier::appendStringifiedValue):
2781
2782 2015-05-08  Andreas Kling  <akling@apple.com>
2783
2784         Optimize serialization of quoted JSON strings.
2785         <https://webkit.org/b/144754>
2786
2787         Reviewed by Darin Adler.
2788
2789         Optimized the serialization of quoted strings into JSON by moving the logic into
2790         StringBuilder so it can make smarter decisions about buffering.
2791
2792         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
2793
2794         * bytecompiler/NodesCodegen.cpp:
2795         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
2796
2797         * runtime/JSONObject.h:
2798         * runtime/JSONObject.cpp:
2799         (JSC::Stringifier::Holder::appendNextProperty):
2800         (JSC::appendStringToStringBuilder): Deleted.
2801         (JSC::appendQuotedJSONStringToBuilder): Deleted.
2802         (JSC::Stringifier::appendQuotedString): Deleted.
2803         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
2804         to StringBuilder and call that from here.
2805
2806 2015-05-07  Commit Queue  <commit-queue@webkit.org>
2807
2808         Unreviewed, rolling out r183961.
2809         https://bugs.webkit.org/show_bug.cgi?id=144784
2810
2811         Broke js/dom/JSON-stringify.html (Requested by kling on
2812         #webkit).
2813
2814         Reverted changeset:
2815
2816         "Optimize serialization of quoted JSON strings."
2817         https://bugs.webkit.org/show_bug.cgi?id=144754
2818         http://trac.webkit.org/changeset/183961
2819
2820 2015-05-07  Filip Pizlo  <fpizlo@apple.com>
2821
2822         GC has trouble with pathologically large array allocations
2823         https://bugs.webkit.org/show_bug.cgi?id=144609
2824
2825         Reviewed by Geoffrey Garen.
2826
2827         The bug was that SlotVisitor::copyLater() would return early for oversize blocks (right
2828         after pinning them), and would skip the accounting. The GC calculates the size of the heap
2829         in tandem with the scan to save time, and that accounting was part of how the GC would
2830         know how big the heap was. The GC would then think that oversize copied blocks use no
2831         memory, and would then mess up its scheduling of the next GC.
2832
2833         Fixing this bug is harder than it seems. When running an eden GC, we figure out the heap
2834         size by summing the size from the last collection and the size by walking the eden heap.
2835         But this breaks when we eagerly delete objects that the last collection touched. We can do
2836         that in one corner case: copied block reallocation. The old block will be deleted from old
2837         space during the realloc and a new block will be allocated in new space. In order for the
2838         GC to know that the size of old space actually shrank, we need a field to tell us how much
2839         such shrinkage could occur. Since this is a very dirty corner case and it only works for
2840         very particular reasons arising from the special properties of copied space (single owner,
2841         and the realloc is used in places where the compiler already knows that it cannot register
2842         allocate a pointer to the old block), I opted for an equally dirty shrinkage counter
2843         devoted just to this case. It's called bytesRemovedFromOldSpaceDueToReallocation.
2844
2845         To test this, I needed to add an Option to force a particular RAM size in the GC. This
2846         allows us to write tests that assert that the GC heap size is some value X, without
2847         worrying about machine-to-machine variations due to GC heuristics changing based on RAM
2848         size.
2849
2850         * heap/CopiedSpace.cpp:
2851         (JSC::CopiedSpace::CopiedSpace): Initialize the dirty shrinkage counter.
2852         (JSC::CopiedSpace::tryReallocateOversize): Bump the dirty shrinkage counter.
2853         * heap/CopiedSpace.h:
2854         (JSC::CopiedSpace::takeBytesRemovedFromOldSpaceDueToReallocation): Swap out the counter. Used by the GC when it does its accounting.
2855         * heap/Heap.cpp:
2856         (JSC::Heap::Heap): Allow the user to force the RAM size.
2857         (JSC::Heap::updateObjectCounts): Use the dirty shrinkage counter to good effect. Also, make this code less confusing.
2858         * heap/SlotVisitorInlines.h:
2859         (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
2860         * jsc.cpp: Add size measuring hooks to write the largeish test.
2861         (GlobalObject::finishCreation):
2862         (functionGCAndSweep):
2863         (functionFullGC):
2864         (functionEdenGC):
2865         (functionHeapSize):
2866         * runtime/Options.h:
2867         * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
2868         * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
2869         (foo):
2870         (test):
2871
2872 2015-05-07  Saam Barati  <saambarati1@gmail.com>
2873
2874         Global functions should be initialized as JSFunctions in byte code
2875         https://bugs.webkit.org/show_bug.cgi?id=144178
2876
2877         Reviewed by Geoffrey Garen.
2878
2879         This patch makes the initialization of global functions more explicit by
2880         moving initialization into bytecode. It also prepares JSC for having ES6
2881         style lexical scoping because initializing global functions in bytecode
2882         easily allows global functions to be initialized with the proper scope that
2883         will have access to global lexical variables. Global lexical variables
2884         should be visible to global functions but don't live on the global object.
2885
2886         * bytecode/UnlinkedCodeBlock.cpp:
2887         (JSC::UnlinkedProgramCodeBlock::visitChildren):
2888         * bytecode/UnlinkedCodeBlock.h:
2889         * bytecompiler/BytecodeGenerator.cpp:
2890         (JSC::BytecodeGenerator::generate):
2891         (JSC::BytecodeGenerator::BytecodeGenerator):
2892         * bytecompiler/BytecodeGenerator.h:
2893         * runtime/Executable.cpp:
2894         (JSC::ProgramExecutable::initializeGlobalProperties):
2895         * runtime/JSGlobalObject.cpp:
2896         (JSC::JSGlobalObject::addGlobalVar):
2897         (JSC::JSGlobalObject::addFunction):
2898         * runtime/JSGlobalObject.h:
2899
2900 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
2901
2902         Fix the x86 32bits build
2903
2904         * assembler/X86Assembler.h:
2905
2906 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
2907
2908         [JSC] Add basic DFG/FTL support for Math.round
2909         https://bugs.webkit.org/show_bug.cgi?id=144725
2910
2911         Reviewed by Filip Pizlo.
2912
2913         This patch adds two optimizations targeting Math.round():
2914         -Add a DFGNode ArithRound corresponding to the intrinsic RoundIntrinsic.
2915         -Change the MacroAssembler to be stricter on how we fail to convert a double
2916          to ingeter. Previously, any number valued zero would fail, now we only
2917          fail for -0.
2918
2919         Since ArithRound speculate it produces int32, the MacroAssembler assembler
2920         part became necessary because zero is a pretty common output of Math.round()
2921         and we would OSR exit a lot (and eventually recompile for doubles).
2922
2923         The implementation itself of the inline Math.round() is exactly the same
2924         as the C function that exists for Math.round(). We can very likely do better
2925         but it is a good start known to be valid and inlining alone alread provides
2926         significant speedups.
2927
2928         * assembler/X86Assembler.h:
2929         (JSC::X86Assembler::movmskpd_rr):
2930         * assembler/MacroAssemblerX86Common.h:
2931         (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
2932         When we have a zero, get the sign bit out of the double and check if is one.
2933
2934         I'll look into doing the same improvement for ARM.
2935
2936         * bytecode/SpeculatedType.cpp:
2937         (JSC::typeOfDoubleRounding):
2938         (JSC::typeOfDoubleFRound): Deleted.
2939         * bytecode/SpeculatedType.h:
2940         * dfg/DFGAbstractInterpreterInlines.h:
2941         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2942         * dfg/DFGByteCodeParser.cpp:
2943         (JSC::DFG::ByteCodeParser::handleIntrinsic):
2944         * dfg/DFGClobberize.h:
2945         (JSC::DFG::clobberize):
2946         * dfg/DFGDoesGC.cpp:
2947         (JSC::DFG::doesGC):
2948         * dfg/DFGFixupPhase.cpp:
2949         (JSC::DFG::FixupPhase::fixupNode):
2950         * dfg/DFGGraph.h:
2951         (JSC::DFG::Graph::roundShouldSpeculateInt32):
2952         (JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
2953         * dfg/DFGNode.h:
2954         (JSC::DFG::Node::arithNodeFlags):
2955         (JSC::DFG::Node::hasHeapPrediction):
2956         (JSC::DFG::Node::hasArithMode):
2957         * dfg/DFGNodeType.h:
2958         * dfg/DFGPredictionPropagationPhase.cpp:
2959         (JSC::DFG::PredictionPropagationPhase::propagate):
2960         * dfg/DFGSafeToExecute.h:
2961         (JSC::DFG::safeToExecute):
2962         * dfg/DFGSpeculativeJIT.cpp:
2963         (JSC::DFG::SpeculativeJIT::compileArithRound):
2964         * dfg/DFGSpeculativeJIT.h:
2965         * dfg/DFGSpeculativeJIT32_64.cpp:
2966         (JSC::DFG::SpeculativeJIT::compile):
2967         * dfg/DFGSpeculativeJIT64.cpp:
2968         (JSC::DFG::SpeculativeJIT::compile):
2969         * ftl/FTLCapabilities.cpp:
2970         (JSC::FTL::canCompile):
2971         * ftl/FTLIntrinsicRepository.h:
2972         * ftl/FTLLowerDFGToLLVM.cpp:
2973         (JSC::FTL::LowerDFGToLLVM::compileNode):
2974         (JSC::FTL::LowerDFGToLLVM::convertDoubleToInt32):
2975         (JSC::FTL::LowerDFGToLLVM::compileDoubleAsInt32):
2976         (JSC::FTL::LowerDFGToLLVM::compileArithRound):
2977         * ftl/FTLOutput.h:
2978         (JSC::FTL::Output::ceil64):
2979         * jit/ThunkGenerators.cpp:
2980         * runtime/MathCommon.cpp:
2981         * runtime/MathCommon.h:
2982         * runtime/MathObject.cpp:
2983         (JSC::mathProtoFuncRound):
2984         * tests/stress/math-round-basics.js: Added.
2985         (mathRoundOnIntegers):
2986         (mathRoundOnDoubles):
2987         (mathRoundOnBooleans):
2988         (uselessMathRound):
2989         (mathRoundWithOverflow):
2990         (mathRoundConsumedAsDouble):
2991         (mathRoundDoesNotCareAboutMinusZero):
2992         (mathRoundNoArguments):
2993         (mathRoundTooManyArguments):
2994         (testMathRoundOnConstants):
2995         (mathRoundStructTransition):
2996         (Math.round):
2997
2998 2015-05-07  Saam Barati  <saambarati1@gmail.com>
2999
3000         exceptionFuzz tests should explicitly initialize the exceptionFuzz boolean in JavaScript code through a function in jsc.cpp
3001         https://bugs.webkit.org/show_bug.cgi?id=144753
3002
3003         Reviewed by Mark Lam.
3004
3005         This allows the BytecodeGenerator to freely emit startup code that "may"
3006         throw exceptions without worrying that this startup code will trigger
3007         the exceptionFuzz exception. The exceptionFuzz counter will only begin
3008         ticking when the 'enableExceptionFuzz' function is explicitly called in
3009         the exceptionFuzz tests.
3010
3011         * jsc.cpp:
3012         (GlobalObject::finishCreation):
3013         (functionEnableExceptionFuzz):
3014         * tests/exceptionFuzz/3d-cube.js:
3015         * tests/exceptionFuzz/date-format-xparb.js:
3016         * tests/exceptionFuzz/earley-boyer.js:
3017
3018 2015-05-07  Andreas Kling  <akling@apple.com>
3019
3020         Optimize serialization of quoted JSON strings.
3021         <https://webkit.org/b/144754>
3022
3023         Reviewed by Darin Adler.
3024
3025         Optimized the serialization of quoted strings into JSON by moving the logic into
3026         StringBuilder so it can make smarter decisions about buffering.
3027
3028         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
3029
3030         * bytecompiler/NodesCodegen.cpp:
3031         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
3032
3033         * runtime/JSONObject.h:
3034         * runtime/JSONObject.cpp:
3035         (JSC::Stringifier::Holder::appendNextProperty):
3036         (JSC::appendStringToStringBuilder): Deleted.
3037         (JSC::appendQuotedJSONStringToBuilder): Deleted.
3038         (JSC::Stringifier::appendQuotedString): Deleted.
3039         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
3040         to StringBuilder and call that from here.
3041
3042 2015-05-07  Yusuke Suzuki  <utatane.tea@gmail.com>
3043
3044         FunctionCallBracketNode should store the base value to the temporary when subscript has assignment
3045         https://bugs.webkit.org/show_bug.cgi?id=144678
3046
3047         Reviewed by Geoffrey Garen.
3048
3049         Currently, FunctionCallBracketNode directly use the RegisterID returned by emitNode.
3050         But if the base part is the local register and the subscript part has assignment to it, the base result is accidentally rewritten.
3051
3052         function t() { var ok = {null: function () { } }; ok[ok = null](); }
3053         t();  // Should not throw error.
3054
3055         This patch takes care about `subscriptHasAssignment`.
3056         By using `emitNodeForLeftHandSide`, when there's assignment to local variables in RHS,
3057         it correctly moves the LHS value to a temporary register.
3058
3059         * bytecompiler/NodesCodegen.cpp:
3060         (JSC::FunctionCallBracketNode::emitBytecode):
3061         * parser/ASTBuilder.h:
3062         (JSC::ASTBuilder::makeFunctionCallNode):
3063         * parser/NodeConstructors.h:
3064         (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
3065         * parser/Nodes.h:
3066         * tests/stress/assignment-in-function-call-bracket-node.js: Added.
3067         (shouldBe):
3068         (shouldBe.):
3069
3070 2015-05-07  Basile Clement  <basile_clement@apple.com>
3071
3072         Unreviewed, add missing braces on a single-line if that got expanded in r183939
3073
3074         * ftl/FTLLowerDFGToLLVM.cpp:
3075         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
3076
3077 2015-05-05  Myles C. Maxfield  <mmaxfield@apple.com>
3078
3079         Revert "Introducing the Platform Abstraction Layer (PAL)"
3080         https://bugs.webkit.org/show_bug.cgi?id=144751
3081
3082         Unreviewed.
3083
3084         PAL should be a new target inside WebCore, rather than a top-level folder.
3085
3086         * Configurations/FeatureDefines.xcconfig: Updated
3087
3088 2015-05-07  Basile Clement  <basile_clement@apple.com>
3089
3090         Dumping OSR ExitValue should expand materializations only once
3091         https://bugs.webkit.org/show_bug.cgi?id=144694
3092
3093         Reviewed by Filip Pizlo.
3094
3095         Currently, dumping OSR exit values will print the full materialization
3096         information each time it is encountered. We change it to print only a
3097         brief description (only the materialization's address), and print the
3098         whole set of materializations later on.
3099
3100         This makes the dump less confusing (less likely to think that two
3101         instances of the same materialization are different), and will be a
3102         necessary change if/when we support materialization cycles.
3103
3104         * ftl/FTLCompile.cpp:
3105         (JSC::FTL::mmAllocateDataSection):
3106         * ftl/FTLExitValue.cpp:
3107         (JSC::FTL::ExitValue::dumpInContext):
3108         * ftl/FTLLowerDFGToLLVM.cpp:
3109         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
3110
3111 2015-05-07  Andreas Kling  <akling@apple.com>
3112
3113         Worker threads leak WeakBlocks (as seen on leaks bot)
3114         <https://webkit.org/b/144721>
3115         <rdar://problem/20848288>
3116
3117         Reviewed by Darin Adler.
3118
3119         Nuke any remaining empty WeakBlocks when the Heap is being torn down.
3120         Trying to peek into these blocks after the VM is dead would be a bug anyway.
3121
3122         This fixes a ~750 KB leak seen on the leaks bot.
3123
3124         * heap/Heap.cpp:
3125         (JSC::Heap::~Heap):
3126
3127 2015-05-05  Geoffrey Garen  <ggaren@apple.com>
3128
3129         Don't branch when accessing the callee
3130         https://bugs.webkit.org/show_bug.cgi?id=144645
3131
3132         Reviewed by Michael Saboff.
3133
3134         The branch was added in <http://trac.webkit.org/changeset/81040> without
3135         explanation.
3136
3137         kling found it to be a performance problem. See <https://webkit.org/b/144586>.
3138
3139         Our theory of access to Registers is that it's up to the client to access
3140         them in the right way. So, let's do that.
3141
3142         * interpreter/CallFrame.h:
3143         (JSC::ExecState::callee):
3144         (JSC::ExecState::setCallee): Call the field object instead of function
3145         because nothing guarantees that it's a function.
3146         * interpreter/ProtoCallFrame.h:
3147         (JSC::ProtoCallFrame::callee):
3148         (JSC::ProtoCallFrame::setCallee):
3149         * interpreter/Register.h:
3150         * runtime/JSObject.h:
3151         (JSC::Register::object): Just do a cast like our other accessors do.
3152         (JSC::Register::operator=):
3153         (JSC::Register::function): Deleted.
3154         (JSC::Register::withCallee): Deleted.
3155
3156 2015-05-07  Dan Bernstein  <mitz@apple.com>
3157
3158         <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
3159         https://bugs.webkit.org/show_bug.cgi?id=144727
3160
3161         Reviewed by Darin Adler.
3162
3163         * Configurations/Base.xcconfig: Don’t include AspenFamily.xcconfig, and define
3164         INSTALL_PATH_PREFIX and LD_DYLIB_INSTALL_NAME for the iOS 8.x Simulator.
3165
3166 2015-05-07  Andreas Kling  <akling@apple.com>
3167
3168         Special-case Int32 values in JSON.stringify().
3169         <https://webkit.org/b/144731>
3170
3171         Reviewed by Michael Saboff.
3172
3173         Add a fast path for serializing Int32 values to JSON. This is far faster than dragging
3174         simple integers through the full-blown dtoa() machinery.
3175
3176         ~50% speedup on Kraken/json-stringify-tinderbox.
3177
3178         * runtime/JSONObject.cpp:
3179         (JSC::Stringifier::appendStringifiedValue):
3180
3181 2015-05-06  Ryosuke Niwa  <rniwa@webkit.org>
3182
3183         ToT WebKit crashes while loading ES6 compatibility table
3184         https://bugs.webkit.org/show_bug.cgi?id=144726
3185
3186         Reviewed by Filip Pizlo.
3187
3188         The bug was caused by parseClass superfluously avoiding to build up the string after seeing {.
3189
3190         Always build the identifier here as it could be a method name.
3191
3192         * parser/Parser.cpp:
3193         (JSC::Parser<LexerType>::parseClass):
3194
3195 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
3196
3197         Sane chain and string watchpoints should be set in FixupPhase or the backend rather than WatchpointCollectionPhase
3198         https://bugs.webkit.org/show_bug.cgi?id=144665
3199
3200         Reviewed by Michael Saboff.
3201
3202         This is a step towards getting rid of WatchpointCollectionPhase. It's also a step towards
3203         extending SaneChain to all indexing shapes.
3204
3205         * dfg/DFGFixupPhase.cpp:
3206         (JSC::DFG::FixupPhase::fixupNode): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
3207         (JSC::DFG::FixupPhase::checkArray): Clarify the need for checking the structure. We often forget why we do this instead of always using CheckArray.
3208         * dfg/DFGSpeculativeJIT.cpp:
3209         (JSC::DFG::SpeculativeJIT::compileGetByValOnString): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
3210         * dfg/DFGWatchpointCollectionPhase.cpp:
3211         (JSC::DFG::WatchpointCollectionPhase::handle): Remove some code.
3212         (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal): Deleted.
3213         * ftl/FTLLowerDFGToLLVM.cpp:
3214         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
3215
3216 2015-04-02  Myles C. Maxfield  <mmaxfield@apple.com>
3217
3218         Introducing the Platform Abstraction Layer (PAL)
3219         https://bugs.webkit.org/show_bug.cgi?id=143358
3220
3221         Reviewed by Simon Fraser.
3222
3223         * Configurations/FeatureDefines.xcconfig: Updated
3224
3225 2015-05-06  Andreas Kling  <akling@apple.com>
3226
3227         Don't allocate a StringImpl for every Number JSValue in JSON.stringify().
3228         <https://webkit.org/b/144676>
3229
3230         Reviewed by Darin Adler.
3231
3232         We were creating a new String for every number JSValue passing through the JSON stringifier.
3233         These StringImpl allocations were dominating one of the Kraken JSON benchmarks.
3234         Optimize this by using StringBuilder::appendECMAScriptNumber() which uses a stack buffer
3235         for the conversion instead.
3236
3237         13% progression on Kraken/json-stringify-tinderbox.
3238
3239         * runtime/JSONObject.cpp:
3240         (JSC::Stringifier::appendStringifiedValue):
3241
3242 2015-05-06  Commit Queue  <commit-queue@webkit.org>
3243
3244         Unreviewed, rolling out r183847.
3245         https://bugs.webkit.org/show_bug.cgi?id=144691
3246
3247         Caused many assertion failures (Requested by ap on #webkit).
3248
3249         Reverted changeset:
3250
3251         "GC has trouble with pathologically large array allocations"
3252         https://bugs.webkit.org/show_bug.cgi?id=144609
3253         http://trac.webkit.org/changeset/183847
3254
3255 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
3256
3257         PutGlobalVar shouldn't have an unconditional store barrier
3258         https://bugs.webkit.org/show_bug.cgi?id=133104
3259
3260         Reviewed by Benjamin Poulain.
3261
3262         We don't need a store barrier on PutGlobalVar if the value being stored can be
3263         speculated to not be a cell.
3264
3265         * dfg/DFGFixupPhase.cpp:
3266         (JSC::DFG::FixupPhase::fixupNode):
3267
3268 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
3269
3270         CopiedBlock::reportLiveBytes() should be totally cool with oversize blocks
3271         https://bugs.webkit.org/show_bug.cgi?id=144667
3272
3273         Reviewed by Andreas Kling.
3274
3275         We are now calling this method for oversize blocks. It had an assertion that indirectly
3276         implied that the block is not oversize, because it was claiming that the number of live
3277         bytes should be smaller than the non-oversize-block size.
3278
3279         * heap/CopiedBlockInlines.h:
3280         (JSC::CopiedBlock::reportLiveBytes):
3281
3282 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
3283
3284         GC has trouble with pathologically large array allocations
3285         https://bugs.webkit.org/show_bug.cgi?id=144609
3286
3287         Reviewed by Mark Lam.
3288
3289         * heap/Heap.cpp:
3290         (JSC::Heap::updateObjectCounts): Make this code less confusing.
3291         * heap/SlotVisitorInlines.h:
3292         (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
3293         * jsc.cpp: Add size measuring hooks to write the largeish test.
3294         (GlobalObject::finishCreation):
3295         (functionGCAndSweep):
3296         (functionFullGC):
3297         (functionEdenGC):
3298         (functionHeapSize):
3299         * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
3300         * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
3301         (foo):
3302         (test):
3303
3304 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
3305
3306         FTL SwitchString slow case creates duplicate switch cases
3307         https://bugs.webkit.org/show_bug.cgi?id=144634
3308
3309         Reviewed by Geoffrey Garen.
3310
3311         The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
3312         added mostly-debug-only asserts to catch such issues earlier.
3313
3314         * bytecode/CallVariant.cpp:
3315         (JSC::variantListWithVariant): Assertion to prevent similar bugs.
3316         * ftl/FTLLowerDFGToLLVM.cpp:
3317         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
3318         (JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
3319         * jit/BinarySwitch.cpp:
3320         (JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
3321         * jit/Repatch.cpp:
3322         (JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
3323         * tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
3324         (foo):
3325         (cat):
3326
3327 2015-05-05  Basile Clement  <basile_clement@apple.com>
3328
3329         Fix debug builds after r183812
3330         https://bugs.webkit.org/show_bug.cgi?id=144300
3331
3332         Rubber stamped by Andreas Kling and Filip Pizlo.
3333
3334         hasObjectMaterializationData() didn't treat MaterializeCreateActivation
3335         as having materialization data, which was causing an assertion failure when
3336         sinking CreateActivations on debug builds.
3337
3338         * dfg/DFGNode.h:
3339         (JSC::DFG::Node::hasObjectMaterializationData):
3340
3341 2015-05-04  Basile Clement  <basile_clement@apple.com>
3342