Source/JavaScriptCore/ChangeLog

   1 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
   2
   3         Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
   4         causes many debug test failures.
   5
   6         * runtime/JSGlobalObject.cpp:
   7         (JSC::JSGlobalObject::init):
   8         (JSC::JSGlobalObject::visitChildren):
   9         * runtime/JSGlobalObject.h:
  10         (JSC::JSGlobalObject::regExpMatchesArrayStructure):
  11         * runtime/JSObject.h:
  12         (JSC::JSObject::initializeIndex):
  13         * runtime/RegExpMatchesArray.cpp:
  14         (JSC::createRegExpMatchesArray):
  15
  16 2015-04-27  Andreas Kling  <akling@apple.com>
  17
  18         RegExp matches arrays should use contiguous indexing.
  19         <https://webkit.org/b/144286>
  20
  21         Reviewed by Geoffrey Garen.
  22
  23         We had a custom Structure being used for RegExp matches arrays that would
  24         put the arrays into SlowPutArrayStorageShape mode. This was just left
  25         from when matches arrays were custom, lazily initialized objects.
  26
  27         This change removes that Structure and switches the matches arrays to
  28         using the default ContiguousShape Structure. This allows the FTL JIT
  29         to compile the inner loop of the Octane/regexp benchmark.
  30
  31         Also made a version of initializeIndex() [inline] that takes the indexing
  32         type in an argument, allowing createRegExpMatchesArray() to initialize
  33         the entire array without branching on the indexing type for each entry.
  34
  35         ~3% progression on Octane/regexp.
  36
  37         * runtime/JSGlobalObject.cpp:
  38         (JSC::JSGlobalObject::init):
  39         (JSC::JSGlobalObject::visitChildren):
  40         * runtime/JSGlobalObject.h:
  41         (JSC::JSGlobalObject::mapStructure):
  42         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
  43         * runtime/JSObject.h:
  44         (JSC::JSObject::initializeIndex):
  45         * runtime/RegExpMatchesArray.cpp:
  46         (JSC::createRegExpMatchesArray):
  47
  48 2015-04-27  Ryosuke Niwa  <rniwa@webkit.org>
  49
  50         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
  51         https://bugs.webkit.org/show_bug.cgi?id=144257
  52
  53         Temporarily disable skip these tests.
  54
  55         * tests/stress/template-literal-line-terminators.js:
  56         * tests/stress/template-literal-syntax.js:
  57         * tests/stress/template-literal.js:
  58
  59 2015-04-27  Basile Clement  <basile_clement@apple.com>
  60
  61         Function allocations shouldn't sink through Put operations
  62         https://bugs.webkit.org/show_bug.cgi?id=144176
  63
  64         Reviewed by Filip Pizlo.
  65
  66         By design, we don't support function allocation sinking through any
  67         related operation ; however object allocation can sink through PutByOffset et
  68         al.
  69
  70         Currently, the checks to prevent function allocation to sink through
  71         these are misguided and do not prevent anything ; function allocation sinking
  72         through these operations is prevented as a side effect of requiring an
  73         AllocatePropertyStorage through which the function allocation is seen as
  74         escaping.
  75
  76         This changes it so that ObjectAllocationSinkingPhase::handleNode()
  77         checks properly that only object allocations sink through related write
  78         operations.
  79
  80         * dfg/DFGObjectAllocationSinkingPhase.cpp:
  81         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
  82         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
  83
  84 2015-04-25  Filip Pizlo  <fpizlo@apple.com>
  85
  86         VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
  87         https://bugs.webkit.org/show_bug.cgi?id=143843
  88
  89         Reviewed by Geoffrey Garen.
  90
  91         It will soon come to pass that Phantom isn't available at the time that
  92         VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
  93         a value dies for OSR.
  94
  95         This is simplified by two things:
  96
  97         1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
  98            before by polishing the API.
  99
 100         2) This phase already operates on one node at a time and allows itself to do a full search
 101            of the enclosing basic block for that node. This is fine because CreateDirectArguments
 102            and friends is a rarely occurring node. The fact that it operates on one node at a time
 103            makes it even easier to reason about OSR liveness - we just track the list of locals in
 104            which it is live.
 105
 106         This change has no effect right now but it is a necessary prerequisite to implementing
 107         https://bugs.webkit.org/show_bug.cgi?id=143736.
 108
 109         * dfg/DFGBasicBlock.h:
 110         (JSC::DFG::BasicBlock::tryAt):
 111         * dfg/DFGForAllKills.h:
 112         (JSC::DFG::forAllKilledOperands):
 113         * dfg/DFGPhantomInsertionPhase.cpp:
 114         * dfg/DFGVarargsForwardingPhase.cpp:
 115
 116 2015-04-27  Jordan Harband  <ljharb@gmail.com>
 117
 118         Map#entries and Map#keys error for non-Maps is swapped
 119         https://bugs.webkit.org/show_bug.cgi?id=144253
 120
 121         Reviewed by Simon Fraser.
 122
 123         Correcting error messages on Set/Map methods when called on
 124         incompatible objects.
 125
 126         * runtime/MapPrototype.cpp:
 127         (JSC::mapProtoFuncEntries):
 128         (JSC::mapProtoFuncKeys):
 129         * runtime/SetPrototype.cpp:
 130         (JSC::setProtoFuncEntries):
 131
 132 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
 133
 134         Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
 135         https://bugs.webkit.org/show_bug.cgi?id=144186
 136
 137         Reviewed by Geoffrey Garen.
 138
 139         If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
 140         Int32. We may later perform code simplifications based on the proof that this is Int32, and
 141         we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
 142         which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
 143         except that we still need the overflow check!
 144
 145         Previously we mishandled this:
 146
 147         - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
 148           to keep it alive. That's dirty and it's just indicative of a deeper issue.
 149
 150         - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
 151           powerless. This was sort of hiding the bug.
 152
 153         - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
 154           something that you are relying on for subsequent simplifications.
 155
 156         This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
 157         nodes that may perform checks that are used by AI to guarantee the result type. As a result,
 158         we no longer need the weird MustGenerate node.
 159
 160         * dfg/DFGAbstractInterpreterInlines.h:
 161         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
 162         * dfg/DFGArgumentsEliminationPhase.cpp:
 163         * dfg/DFGClobberize.h:
 164         (JSC::DFG::clobberize):
 165         * dfg/DFGDCEPhase.cpp:
 166         (JSC::DFG::DCEPhase::run):
 167         * dfg/DFGDoesGC.cpp:
 168         (JSC::DFG::doesGC):
 169         * dfg/DFGFixupPhase.cpp:
 170         (JSC::DFG::FixupPhase::fixupNode):
 171         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
 172         * dfg/DFGIntegerCheckCombiningPhase.cpp:
 173         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
 174         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
 175         * dfg/DFGMayExit.cpp:
 176         (JSC::DFG::mayExit):
 177         * dfg/DFGNode.h:
 178         (JSC::DFG::Node::willHaveCodeGenOrOSR):
 179         * dfg/DFGNodeType.h:
 180         * dfg/DFGObjectAllocationSinkingPhase.cpp:
 181         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
 182         * dfg/DFGPhantomCanonicalizationPhase.cpp:
 183         (JSC::DFG::PhantomCanonicalizationPhase::run):
 184         * dfg/DFGPhantomRemovalPhase.cpp:
 185         (JSC::DFG::PhantomRemovalPhase::run):
 186         * dfg/DFGPlan.cpp:
 187         (JSC::DFG::Plan::compileInThreadImpl):
 188         * dfg/DFGPredictionPropagationPhase.cpp:
 189         (JSC::DFG::PredictionPropagationPhase::propagate):
 190         * dfg/DFGSafeToExecute.h:
 191         (JSC::DFG::safeToExecute):
 192         * dfg/DFGSpeculativeJIT32_64.cpp:
 193         (JSC::DFG::SpeculativeJIT::compile):
 194         * dfg/DFGSpeculativeJIT64.cpp:
 195         (JSC::DFG::SpeculativeJIT::compile):
 196         * dfg/DFGTypeCheckHoistingPhase.cpp:
 197         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
 198         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
 199         * dfg/DFGVarargsForwardingPhase.cpp:
 200         * ftl/FTLCapabilities.cpp:
 201         (JSC::FTL::canCompile):
 202         * ftl/FTLLowerDFGToLLVM.cpp:
 203         (JSC::FTL::LowerDFGToLLVM::compileNode):
 204         * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
 205         (foo):
 206         * tests/stress/fold-based-on-int32-proof-mul.js: Added.
 207         (foo):
 208         * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
 209         (foo):
 210         * tests/stress/fold-based-on-int32-proof.js: Added.
 211         (foo):
 212
 213 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
 214
 215         Class body ending with a semicolon throws a SyntaxError
 216         https://bugs.webkit.org/show_bug.cgi?id=144244
 217
 218         Reviewed by Darin Adler.
 219
 220         The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
 221         it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
 222         it by continue'ing when it encounters a semicolon.
 223
 224         * parser/Parser.cpp:
 225         (JSC::Parser<LexerType>::parseClass):
 226
 227 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
 228
 229         Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
 230         https://bugs.webkit.org/show_bug.cgi?id=144243
 231
 232         Reviewed by Darin Adler.
 233
 234         Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.
 235
 236         * parser/Parser.cpp:
 237         (JSC::Parser<LexerType>::parseGetterSetter):
 238
 239 2015-04-26  Jordan Harband  <ljharb@gmail.com>
 240
 241         Map#forEach does not pass "map" argument to callback.
 242         https://bugs.webkit.org/show_bug.cgi?id=144187
 243
 244         Reviewed by Darin Adler.
 245
 246         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
 247         step 7.a.i., the callback should be called with three arguments.
 248
 249         * runtime/MapPrototype.cpp:
 250         (JSC::mapProtoFuncForEach):
 251
 252 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
 253
 254         [ES6] Implement ES6 template literals
 255         https://bugs.webkit.org/show_bug.cgi?id=142691
 256
 257         Reviewed by Darin Adler.
 258
 259         This patch implements TemplateLiteral.
 260         Since TaggedTemplate requires some global states and
 261         primitive operations like GetTemplateObject,
 262         we separate the patch. It will be implemented in a subsequent patch.
 263
 264         Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
 265         By disabling it, we can disable Template Literal support.
 266
 267         To implement template literals, in this patch,
 268         we newly introduces bytecode op_to_string.
 269         In template literals, we alternately evaluate the expression and
 270         perform ToString onto the result of evaluation.
 271         For example,
 272
 273         `${f1()} ${f2()}`
 274
 275         In this template literal, execution order is the following,
 276         1. calling f1()
 277         2. ToString(the result of f1())
 278         3. calling f2()
 279         4. ToString(the result of f2())
 280
 281         op_strcat also performs ToString. However, performing ToString
 282         onto expressions are batched in op_strcat, it's not the same to the
 283         template literal spec. In the above example,
 284         ToString(f1()) should be called before calling f2().
 285
 286         * Configurations/FeatureDefines.xcconfig:
 287         * bytecode/BytecodeList.json:
 288         * bytecode/BytecodeUseDef.h:
 289         (JSC::computeUsesForBytecodeOffset):
 290         (JSC::computeDefsForBytecodeOffset):
 291         * bytecode/CodeBlock.cpp:
 292         (JSC::CodeBlock::dumpBytecode):
 293         * bytecompiler/BytecodeGenerator.h:
 294         (JSC::BytecodeGenerator::emitToString):
 295         (JSC::BytecodeGenerator::emitToNumber): Deleted.
 296         * bytecompiler/NodesCodegen.cpp:
 297         (JSC::TemplateStringNode::emitBytecode):
 298         (JSC::TemplateLiteralNode::emitBytecode):
 299         * dfg/DFGByteCodeParser.cpp:
 300         (JSC::DFG::ByteCodeParser::parseBlock):
 301         * dfg/DFGCapabilities.cpp:
 302         (JSC::DFG::capabilityLevel):
 303         * jit/JIT.cpp:
 304         (JSC::JIT::privateCompileMainPass):
 305         (JSC::JIT::privateCompileSlowCases):
 306         * jit/JIT.h:
 307         * jit/JITOpcodes.cpp:
 308         (JSC::JIT::emit_op_to_string):
 309         (JSC::JIT::emitSlow_op_to_string):
 310         * jit/JITOpcodes32_64.cpp:
 311         (JSC::JIT::emit_op_to_string):
 312         (JSC::JIT::emitSlow_op_to_string):
 313         * llint/LowLevelInterpreter32_64.asm:
 314         * llint/LowLevelInterpreter64.asm:
 315         * parser/ASTBuilder.h:
 316         (JSC::ASTBuilder::createTemplateString):
 317         (JSC::ASTBuilder::createTemplateStringList):
 318         (JSC::ASTBuilder::createTemplateExpressionList):
 319         (JSC::ASTBuilder::createTemplateLiteral):
 320         * parser/Lexer.cpp:
 321         (JSC::Lexer<T>::Lexer):
 322         (JSC::Lexer<T>::parseIdentifierSlowCase):
 323         (JSC::Lexer<T>::parseString):
 324         (JSC::LineNumberAdder::LineNumberAdder):
 325         (JSC::LineNumberAdder::clear):
 326         (JSC::LineNumberAdder::add):
 327         (JSC::Lexer<T>::parseTemplateLiteral):
 328         (JSC::Lexer<T>::lex):
 329         (JSC::Lexer<T>::scanRegExp):
 330         (JSC::Lexer<T>::scanTrailingTemplateString):
 331         (JSC::Lexer<T>::parseStringSlowCase): Deleted.
 332         * parser/Lexer.h:
 333         * parser/NodeConstructors.h:
 334         (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
 335         (JSC::TemplateStringNode::TemplateStringNode):
 336         (JSC::TemplateStringListNode::TemplateStringListNode):
 337         (JSC::TemplateLiteralNode::TemplateLiteralNode):
 338         * parser/Nodes.h:
 339         (JSC::TemplateExpressionListNode::value):
 340         (JSC::TemplateExpressionListNode::next):
 341         (JSC::TemplateStringNode::cooked):
 342         (JSC::TemplateStringNode::raw):
 343         (JSC::TemplateStringListNode::value):
 344         (JSC::TemplateStringListNode::next):
 345         * parser/Parser.cpp:
 346         (JSC::Parser<LexerType>::parseTemplateString):
 347         (JSC::Parser<LexerType>::parseTemplateLiteral):
 348         (JSC::Parser<LexerType>::parsePrimaryExpression):
 349         * parser/Parser.h:
 350         * parser/ParserTokens.h:
 351         * parser/SyntaxChecker.h:
 352         (JSC::SyntaxChecker::createTemplateString):
 353         (JSC::SyntaxChecker::createTemplateStringList):
 354         (JSC::SyntaxChecker::createTemplateExpressionList):
 355         (JSC::SyntaxChecker::createTemplateLiteral):
 356         (JSC::SyntaxChecker::createSpreadExpression): Deleted.
 357         * runtime/CommonSlowPaths.cpp:
 358         (JSC::SLOW_PATH_DECL):
 359         * runtime/CommonSlowPaths.h:
 360         * tests/stress/template-literal-line-terminators.js: Added.
 361         (test):
 362         (testEval):
 363         (testEvalLineNumber):
 364         * tests/stress/template-literal-syntax.js: Added.
 365         (testSyntax):
 366         (testSyntaxError):
 367         * tests/stress/template-literal.js: Added.
 368         (test):
 369         (testEval):
 370         (testEmbedded):
 371
 372 2015-04-26  Jordan Harband  <ljharb@gmail.com>
 373
 374         Set#forEach does not pass "key" or "set" arguments to callback.
 375         https://bugs.webkit.org/show_bug.cgi?id=144188
 376
 377         Reviewed by Darin Adler.
 378
 379         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
 380         Set#forEach should pass 3 arguments to the callback.
 381
 382         * runtime/SetPrototype.cpp:
 383         (JSC::setProtoFuncForEach):
 384
 385 2015-04-26  Benjamin Poulain  <benjamin@webkit.org>
 386
 387         [JSC] Implement Math.clz32(), remove Number.clz()
 388         https://bugs.webkit.org/show_bug.cgi?id=144205
 389
 390         Reviewed by Michael Saboff.
 391
 392         This patch adds the ES6 function Math.clz32(), and remove the non-standard
 393         Number.clz(). Number.clz() probably came from an older draft.
 394
 395         The new function has a corresponding instrinsic: Clz32Intrinsic,
 396         and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.
 397
 398         * assembler/MacroAssemblerX86Common.h:
 399         (JSC::MacroAssemblerX86Common::countLeadingZeros32):
 400         * assembler/X86Assembler.h:
 401         (JSC::X86Assembler::bsr_rr):
 402         The x86 assembler did not have countLeadingZeros32() because there is
 403         no native CLZ instruction on that architecture.
 404
 405         I have added the version with bsr + branches for the case of zero.
 406         An other popular version uses cmov to handle the case of zero. I kept
 407         it simple since the Assembler has no support for cmov.
 408
 409         It is unlikely to matter much. If the code is hot enough, LLVM picks
 410         something good based on the surrounding code.
 411
 412         * dfg/DFGAbstractInterpreterInlines.h:
 413         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
 414         Constant handling + effect propagation. The node only produces integer (between 0 and 32).
 415
 416         * dfg/DFGBackwardsPropagationPhase.cpp:
 417         (JSC::DFG::BackwardsPropagationPhase::propagate):
 418         Thanks to the definition of toUint32(), we can ignore plenty of details
 419         from doubles.
 420
 421         * dfg/DFGByteCodeParser.cpp:
 422         (JSC::DFG::ByteCodeParser::handleIntrinsic):
 423         * dfg/DFGClobberize.h:
 424         (JSC::DFG::clobberize):
 425         * dfg/DFGDoesGC.cpp:
 426         (JSC::DFG::doesGC):
 427         * dfg/DFGFixupPhase.cpp:
 428         (JSC::DFG::FixupPhase::fixupNode):
 429         * dfg/DFGNodeType.h:
 430         * dfg/DFGPredictionPropagationPhase.cpp:
 431         (JSC::DFG::PredictionPropagationPhase::propagate):
 432         * dfg/DFGSafeToExecute.h:
 433         (JSC::DFG::safeToExecute):
 434         * dfg/DFGSpeculativeJIT.cpp:
 435         (JSC::DFG::SpeculativeJIT::compileArithClz32):
 436         * dfg/DFGSpeculativeJIT.h:
 437         * dfg/DFGSpeculativeJIT32_64.cpp:
 438         (JSC::DFG::SpeculativeJIT::compile):
 439         * dfg/DFGSpeculativeJIT64.cpp:
 440         (JSC::DFG::SpeculativeJIT::compile):
 441         * ftl/FTLCapabilities.cpp:
 442         (JSC::FTL::canCompile):
 443         * ftl/FTLIntrinsicRepository.h:
 444         * ftl/FTLLowerDFGToLLVM.cpp:
 445         (JSC::FTL::LowerDFGToLLVM::compileNode):
 446         (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
 447         * ftl/FTLOutput.h:
 448         (JSC::FTL::Output::ctlz32):
 449         * jit/ThunkGenerators.cpp:
 450         (JSC::clz32ThunkGenerator):
 451         * jit/ThunkGenerators.h:
 452         * runtime/Intrinsic.h:
 453         * runtime/MathCommon.h:
 454         (JSC::clz32):
 455         Fun fact: InstCombine does not recognize this pattern to eliminate
 456         the branch which makes our FTL version better than the C version.
 457
 458         * runtime/MathObject.cpp:
 459         (JSC::MathObject::finishCreation):
 460         (JSC::mathProtoFuncClz32):
 461         * runtime/NumberPrototype.cpp:
 462         (JSC::clz): Deleted.
 463         (JSC::numberProtoFuncClz): Deleted.
 464         * runtime/VM.cpp:
 465         (JSC::thunkGeneratorForIntrinsic):
 466         * tests/stress/math-clz32-basics.js: Added.
 467         (mathClz32OnInteger):
 468         (testMathClz32OnIntegers):
 469         (verifyMathClz32OnIntegerWithOtherTypes):
 470         (mathClz32OnDouble):
 471         (testMathClz32OnDoubles):
 472         (verifyMathClz32OnDoublesWithOtherTypes):
 473         (mathClz32NoArguments):
 474         (mathClz32TooManyArguments):
 475         (testMathClz32OnConstants):
 476         (mathClz32StructTransition):
 477         (Math.clz32):
 478
 479 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
 480
 481         [ES6] Array.from need to accept iterables
 482         https://bugs.webkit.org/show_bug.cgi?id=141055
 483
 484         Reviewed by Darin Adler.
 485
 486         ES6 spec requires that Array.from accepts iterable objects.
 487         This patch introduces this functionality, Array.from accepting iterable objects.
 488
 489         Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
 490         However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
 491         `typeof thisObj === "function"` queries the given object has `[[Call]]`.
 492         This will be fixed in the subsequent patch[1].
 493
 494         [1]: https://bugs.webkit.org/show_bug.cgi?id=144093
 495
 496         * builtins/ArrayConstructor.js:
 497         (from):
 498         * parser/Parser.cpp:
 499         (JSC::Parser<LexerType>::parseInner):
 500         * runtime/CommonIdentifiers.h:
 501         * runtime/JSGlobalObject.cpp:
 502         (JSC::JSGlobalObject::init):
 503         * tests/stress/array-from-with-iterable.js: Added.
 504         (shouldBe):
 505         (.set for):
 506         (.set var):
 507         (.get var):
 508         (argumentsGenerators):
 509         (.set shouldBe):
 510         (.set new):
 511         * tests/stress/array-from-with-iterator.js: Added.
 512         (shouldBe):
 513         (shouldThrow):
 514         (createIterator.iterator.return):
 515         (createIterator):
 516         (.):
 517
 518 2015-04-25  Jordan Harband  <ljharb@gmail.com>
 519
 520         Set#keys !== Set#values
 521         https://bugs.webkit.org/show_bug.cgi?id=144190
 522
 523         Reviewed by Darin Adler.
 524
 525         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
 526         Set#keys should === Set#values
 527
 528         * runtime/SetPrototype.cpp:
 529         (JSC::SetPrototype::finishCreation):
 530         (JSC::setProtoFuncValues):
 531         (JSC::setProtoFuncEntries):
 532         (JSC::setProtoFuncKeys): Deleted.
 533
 534 2015-04-25  Joseph Pecoraro  <pecoraro@apple.com>
 535
 536         Allow for pausing a JSContext when opening a Web Inspector
 537         <rdar://problem/20564788>
 538
 539         Reviewed by Timothy Hatcher.
 540
 541         * inspector/remote/RemoteInspector.mm:
 542         (Inspector::RemoteInspector::receivedSetupMessage):
 543         * inspector/remote/RemoteInspectorConstants.h:
 544         * inspector/remote/RemoteInspectorDebuggable.h:
 545         * inspector/remote/RemoteInspectorDebuggableConnection.h:
 546         * inspector/remote/RemoteInspectorDebuggableConnection.mm:
 547         (Inspector::RemoteInspectorDebuggableConnection::setup):
 548         On any incoming setup message, we may want to automatically
 549         pause the debuggable. If requested, pause the debuggable
 550         after we have setup the frontend connection.
 551
 552         * runtime/JSGlobalObjectDebuggable.h:
 553         * runtime/JSGlobalObjectDebuggable.cpp:
 554         (JSC::JSGlobalObjectDebuggable::pause):
 555         Pass through to the inspector controller.
 556
 557         * inspector/JSGlobalObjectInspectorController.h:
 558         * inspector/JSGlobalObjectInspectorController.cpp:
 559         (Inspector::JSGlobalObjectInspectorController::pause):
 560         Enable pause on next statement.
 561
 562 2015-04-23  Ryosuke Niwa  <rniwa@webkit.org>
 563
 564         class methods should be non-enumerable
 565         https://bugs.webkit.org/show_bug.cgi?id=143181
 566
 567         Reviewed by Darin Adler.
 568
 569         Fixed the bug by using Object.defineProperty to define methods.
 570
 571         This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
 572         inside CodeBlock's constructor since bytecode can be linked against multiple global objects.
 573
 574         * bytecode/CodeBlock.cpp:
 575         (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
 576         index of zero.
 577         * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
 578         exactly one entry for Object.defineProperty.
 579         * bytecode/UnlinkedCodeBlock.h:
 580         (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
 581         constant register for the link time constant we're adding.
 582         (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
 583         * bytecompiler/BytecodeGenerator.cpp:
 584         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
 585         register for the specified link time constant and notify UnlinkedCodeBlock about it.
 586         (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
 587         Object.defineProperty with it.
 588         * bytecompiler/BytecodeGenerator.h:
 589         * bytecompiler/NodesCodegen.cpp:
 590         (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
 591         non-enumerable by using emitCallDefineProperty to define them.
 592         (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
 593         (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
 594         property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
 595         * runtime/CommonIdentifiers.h:
 596         * runtime/JSGlobalObject.cpp:
 597         (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
 598         (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
 599         * runtime/JSGlobalObject.h:
 600         (JSC::JSGlobalObject::definePropertyFunction): Added.
 601         (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
 602         (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
 603         returns a JSCell; e.g. Object.defineProperty.
 604         * runtime/ObjectConstructor.cpp:
 605         (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
 606         * runtime/ObjectConstructor.h:
 607
 608 2015-04-25  Yusuke Suzuki  <utatane.tea@gmail.com>
 609
 610         [ES6] Implement String.fromCodePoint
 611         https://bugs.webkit.org/show_bug.cgi?id=144160
 612
 613         Reviewed by Darin Adler.
 614
 615         This patch implements String.fromCodePoint.
 616         It accepts multiple code points and generates a string that consists of given code points.
 617         The range [0x0000 - 0x10FFFF] is valid for code points.
 618         If the given value is out of range, throw a range error.
 619
 620         When a 0xFFFF <= valid code point is given,
 621         String.fromCodePoint generates a string that contains surrogate pairs.
 622
 623         * runtime/StringConstructor.cpp:
 624         (JSC::stringFromCodePoint):
 625         (JSC::constructWithStringConstructor):
 626         * tests/stress/string-from-code-point.js: Added.
 627         (shouldBe):
 628         (shouldThrow):
 629         (toCodePoints):
 630         (passThrough):
 631
 632 2015-04-25  Martin Robinson  <mrobinson@igalia.com>
 633
 634         Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
 635         https://bugs.webkit.org/show_bug.cgi?id=144182
 636
 637         Reviewed by Simon Fraser.
 638
 639         * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.
 640
 641 2015-04-25  Mark Lam  <mark.lam@apple.com>
 642
 643         mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
 644         https://bugs.webkit.org/show_bug.cgi?id=144152
 645
 646         Reviewed by Filip Pizlo.
 647
 648         Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
 649         StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
 650         OSR exits.  This was overlooked in the original code.
 651
 652         While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
 653         the Branch node, the other 3 may also trigger the same bug for other nodes.
 654         To prevent this bug from manifesting with other nodes (and future ones that
 655         are yet to be added to mayExits()'s "potential won't exit" set), we fix the
 656         EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).
 657
 658         Also added a test to exercise a code path that will trigger this bug with
 659         the Branch node before the fix is applied.
 660
 661         * dfg/DFGMayExit.cpp:
 662         * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
 663         (inlinedFunction):
 664         (foo):
 665
 666 2015-04-24  Commit Queue  <commit-queue@webkit.org>
 667
 668         Unreviewed, rolling out r183288.
 669         https://bugs.webkit.org/show_bug.cgi?id=144189
 670
 671         Made js/sort-with-side-effecting-comparisons.html time out in
 672         debug builds (Requested by ap on #webkit).
 673
 674         Reverted changeset:
 675
 676         "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
 677         array."
 678         https://bugs.webkit.org/show_bug.cgi?id=144013
 679         http://trac.webkit.org/changeset/183288
 680
 681 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
 682
 683         CRASH in operationCreateDirectArgumentsDuringExit()
 684         https://bugs.webkit.org/show_bug.cgi?id=143962
 685
 686         Reviewed by Geoffrey Garen.
 687
 688         We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
 689         recoverable so long as they are live. Therefore, OSR exit should track liveness of
 690         constants instead of assuming that they are always live.
 691
 692         * dfg/DFGGenerationInfo.h:
 693         (JSC::DFG::GenerationInfo::noticeOSRBirth):
 694         (JSC::DFG::GenerationInfo::appendBirth):
 695         * dfg/DFGSpeculativeJIT.cpp:
 696         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
 697         * dfg/DFGVariableEvent.cpp:
 698         (JSC::DFG::VariableEvent::dump):
 699         * dfg/DFGVariableEvent.h:
 700         (JSC::DFG::VariableEvent::birth):
 701         (JSC::DFG::VariableEvent::id):
 702         (JSC::DFG::VariableEvent::dataFormat):
 703         * dfg/DFGVariableEventStream.cpp:
 704         (JSC::DFG::VariableEventStream::reconstruct):
 705         * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
 706         (foo):
 707         (bar):
 708         * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
 709         (foo):
 710         (bar):
 711
 712 2015-04-24  Benjamin Poulain  <bpoulain@apple.com>
 713
 714         [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
 715         https://bugs.webkit.org/show_bug.cgi?id=144169
 716
 717         Reviewed by Geoffrey Garen.
 718
 719         * runtime/JSObject.cpp:
 720         (JSC::JSObject::convertInt32ForValue):
 721         DoubleArray do not store NaN, they are used for holes.
 722         What happened was:
 723         1) We fail to insert the NaN in the Int32 array because it is a double.
 724         2) We were converting the array to DoubleArray.
 725         3) We were trying to insert the value again. We would fail again because
 726            DoubleArray does not store NaN.
 727         4) We would convert the DoubleArrayt to Contiguous Array, converting the values
 728            to boxed values.
 729
 730         * tests/stress/int32array-transition-on-nan.js: Added.
 731         The behavior is not really observable. This only test nothing crashes in those
 732         cases.
 733
 734         (insertNaNWhileFilling):
 735         (testInsertNaNWhileFilling):
 736         (insertNaNAfterFilling):
 737         (testInsertNaNAfterFilling):
 738         (pushNaNWhileFilling):
 739         (testPushNaNWhileFilling):
 740
 741 2015-04-21  Geoffrey Garen  <ggaren@apple.com>
 742
 743         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
 744         https://bugs.webkit.org/show_bug.cgi?id=144013
 745
 746         Reviewed by Mark Lam.
 747
 748         This patch implements Array.prototype.sort in JavaScript, removing the
 749         C++ implementations. It is simpler and less error-prone to express our
 750         operations in JavaScript, which provides memory safety, exception safety,
 751         and recursion safety.
 752
 753         The performance result is mixed, but net positive in my opinion. It's
 754         difficult to enumerate all the results, since we used to have so many
 755         different sorting modes, and there are lots of different data patterns
 756         across which you might want to measure sorting. Suffice it to say:
 757
 758             (*) The benchmarks we track are faster or unchanged.
 759
 760             (*) Sorting random input using a comparator -- which we think is
 761             common -- is 3X faster.
 762
 763             (*) Sorting random input in a non-array object -- which jQuery does
 764             -- is 4X faster.
 765
 766             (*) Sorting random input in a compact array of integers using a
 767             trivial pattern-matchable comparator is 2X *slower*.
 768
 769         * builtins/Array.prototype.js:
 770         (sort.min):
 771         (sort.stringComparator):
 772         (sort.compactSparse): Special case compaction for sparse arrays because
 773         we don't want to hang when sorting new Array(BIG).
 774
 775         (sort.compact):
 776         (sort.merge):
 777         (sort.mergeSort): Use merge sort because it's a reasonably efficient
 778         stable sort. We have evidence that some sites depend on stable sort,
 779         even though the ES6 spec does not mandate it. (See
 780         <http://trac.webkit.org/changeset/33967>.)
 781
 782         This is a textbook implementation of merge sort with three optimizations:
 783
 784             (1) Use iteration instead of recursion;
 785
 786             (2) Use array subscripting instead of array copying in order to
 787             create logical sub-lists without creating physical sub-lists;
 788
 789             (3) Swap src and dst at each iteration instead of copying src into
 790             dst, and only copy src into the subject array at the end if src is
 791             not the subject array.
 792
 793         (sort.inflate):
 794         (sort.comparatorSort):
 795         (sort): Sort in JavaScript for the win.
 796
 797         * builtins/BuiltinExecutables.cpp:
 798         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
 799         names so we can use helper functions.
 800
 801         * bytecode/CodeBlock.h:
 802         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
 803         * bytecode/UnlinkedCodeBlock.cpp:
 804         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
 805         * bytecode/UnlinkedCodeBlock.h:
 806         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
 807         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
 808         * bytecompiler/BytecodeGenerator.cpp:
 809         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
 810         * bytecompiler/BytecodeGenerator.h:
 811         * bytecompiler/NodesCodegen.cpp:
 812         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
 813         on pattern matching anymore. This was mainly an optimization to avoid
 814         the overhead of calling from C++ to JS, which we now avoid by
 815         sorting in JS.
 816
 817         * heap/Heap.cpp:
 818         (JSC::Heap::markRoots):
 819         (JSC::Heap::pushTempSortVector): Deleted.
 820         (JSC::Heap::popTempSortVector): Deleted.
 821         (JSC::Heap::visitTempSortVectors): Deleted.
 822         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
 823         in JavaScript using a normal JavaScript array for our temporary storage.
 824
 825         * parser/Parser.cpp:
 826         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
 827         helper functions.
 828
 829         * runtime/ArrayPrototype.cpp:
 830         (JSC::isNumericCompareFunction): Deleted.
 831         (JSC::attemptFastSort): Deleted.
 832         (JSC::performSlowSort): Deleted.
 833         (JSC::arrayProtoFuncSort): Deleted.
 834
 835         * runtime/CommonIdentifiers.h: New strings used by sort.
 836
 837         * runtime/JSArray.cpp:
 838         (JSC::compareNumbersForQSortWithInt32): Deleted.
 839         (JSC::compareNumbersForQSortWithDouble): Deleted.
 840         (JSC::compareNumbersForQSort): Deleted.
 841         (JSC::compareByStringPairForQSort): Deleted.
 842         (JSC::JSArray::sortNumericVector): Deleted.
 843         (JSC::JSArray::sortNumeric): Deleted.
 844         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
 845         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
 846         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
 847         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
 848         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
 849         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
 850         (JSC::JSArray::sortCompactedVector): Deleted.
 851         (JSC::JSArray::sort): Deleted.
 852         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
 853         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
 854         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
 855         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
 856         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
 857         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
 858         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
 859         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
 860         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
 861         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
 862         (JSC::JSArray::sortVector): Deleted.
 863         (JSC::JSArray::compactForSorting): Deleted.
 864         * runtime/JSArray.h:
 865
 866         * runtime/JSGlobalObject.cpp:
 867         (JSC::JSGlobalObject::init):
 868         * runtime/ObjectConstructor.cpp:
 869         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
 870         by sort.
 871
 872 2015-04-24  Matthew Mirman  <mmirman@apple.com>
 873
 874         Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
 875         https://bugs.webkit.org/show_bug.cgi?id=141865
 876         rdar://problem/19927273
 877
 878         Reviewed by Filip Pizlo.
 879
 880         * runtime/JSGlobalObjectFunctions.cpp:
 881         (JSC::globalFuncProtoGetter):
 882         (JSC::globalFuncProtoSetter):
 883
 884 2015-04-23  Benjamin Poulain  <bpoulain@apple.com>
 885
 886         Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
 887         https://bugs.webkit.org/show_bug.cgi?id=144118
 888
 889         Reviewed by Geoffrey Garen.
 890
 891         * dfg/DFGGraph.h:
 892         (JSC::DFG::Graph::addShouldSpeculateMachineInt):
 893         Both block do the same thing.
 894
 895 2015-04-23  Joseph Pecoraro  <pecoraro@apple.com>
 896
 897         Web Inspector: Speculative fix for non-main thread auto-attach failures
 898         https://bugs.webkit.org/show_bug.cgi?id=144134
 899
 900         Reviewed by Timothy Hatcher.
 901
 902         * inspector/remote/RemoteInspector.mm:
 903         (Inspector::RemoteInspector::singleton):
 904
 905 2015-04-23  Basile Clement  <basile_clement@apple.com>
 906
 907         Allow function allocation sinking
 908         https://bugs.webkit.org/show_bug.cgi?id=144016
 909
 910         Reviewed by Filip Pizlo.
 911
 912         This adds the ability to sink function allocations in the
 913         DFGObjectAllocationSinkingPhase.
 914
 915         In order to enable this, we add a new PhantomNewFunction node that is
 916         used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
 917         a sunk NewFunction and keep track of the allocations that have to be performed
 918         in case of OSR exit after the sunk allocation but before the real one.
 919         The FunctionExecutable and JSLexicalEnvironment (activation) of the function
 920         are stored onto the PhantomNewFunction through PutHints in order for them
 921         to be recovered on OSR exit.
 922
 923         Contrary to sunk object allocations, sunk function allocations do not
 924         support any kind of operations (e.g. storing into a field) ; any such operation
 925         will mark the function allocation as escaping and trigger materialization. As
 926         such, function allocations can only be sunk to places where it would have been
 927         correct to syntactically move them, and we don't need a special
 928         MaterializeNewFunction node to recover possible operations on the function. A
 929         sunk NewFunction node will simply create new NewFunction nodes, then replace
 930         itself with a PhantomNewFunction node.
 931
 932         In itself, this change is not expected to have a significant impact on
 933         performances other than in degenerate cases (see e.g.
 934         JSRegress/sink-function), but it is a step towards being able to sink recursive
 935         closures onces we support CreateActivation sinking as well as allocation cycles
 936         sinking.
 937
 938         * dfg/DFGAbstractInterpreterInlines.h:
 939         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
 940         * dfg/DFGClobberize.h:
 941         (JSC::DFG::clobberize):
 942         * dfg/DFGDoesGC.cpp:
 943         (JSC::DFG::doesGC):
 944         * dfg/DFGFixupPhase.cpp:
 945         (JSC::DFG::FixupPhase::fixupNode):
 946         * dfg/DFGNode.h:
 947         (JSC::DFG::Node::convertToPhantomNewFunction):
 948         (JSC::DFG::Node::isPhantomAllocation):
 949         * dfg/DFGNodeType.h:
 950         * dfg/DFGObjectAllocationSinkingPhase.cpp:
 951         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
 952         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
 953         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
 954         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
 955         * dfg/DFGPredictionPropagationPhase.cpp:
 956         (JSC::DFG::PredictionPropagationPhase::propagate):
 957         * dfg/DFGPromotedHeapLocation.cpp:
 958         (WTF::printInternal):
 959         * dfg/DFGPromotedHeapLocation.h:
 960         * dfg/DFGSafeToExecute.h:
 961         (JSC::DFG::safeToExecute):
 962         * dfg/DFGSpeculativeJIT32_64.cpp:
 963         (JSC::DFG::SpeculativeJIT::compile):
 964         * dfg/DFGSpeculativeJIT64.cpp:
 965         (JSC::DFG::SpeculativeJIT::compile):
 966         * dfg/DFGValidate.cpp:
 967         (JSC::DFG::Validate::validateCPS):
 968         * ftl/FTLCapabilities.cpp:
 969         (JSC::FTL::canCompile):
 970         * ftl/FTLLowerDFGToLLVM.cpp:
 971         (JSC::FTL::LowerDFGToLLVM::compileNode):
 972         * ftl/FTLOperations.cpp:
 973         (JSC::FTL::operationMaterializeObjectInOSR):
 974         * tests/stress/function-sinking-no-double-allocate.js: Added.
 975         (call):
 976         (.f):
 977         (sink):
 978         * tests/stress/function-sinking-osrexit.js: Added.
 979         (.g):
 980         (sink):
 981         * tests/stress/function-sinking-put.js: Added.
 982         (.g):
 983         (sink):
 984
 985 2015-04-23  Basile Clement  <basile_clement@apple.com>
 986
 987         Make FunctionRareData allocation thread-safe
 988         https://bugs.webkit.org/show_bug.cgi?id=144001
 989
 990         Reviewed by Mark Lam.
 991
 992         The two things we want to prevent are:
 993
 994          1. A thread seeing a pointer to a not-yet-fully-created rare data from
 995             a JSFunction
 996          2. A thread seeing a pointer to a not-yet-fully-created Structure from
 997             an ObjectAllocationProfile
 998
 999         For 1., only the JS thread can be creating the rare data (in
1000         runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
1001         worry about concurrent writes, and we don't need any fences when *reading* the
1002         rare data from the JS thread. Thus we only need a storeStoreFence between the
1003         rare data creation and assignment to m_rareData in
1004         JSFunction::createAndInitializeRareData() to ensure that when the store to
1005         m_rareData is issued, the rare data has been properly created.
1006
1007         For the DFG compilation threads, the only place they can access the
1008         rare data is through JSFunction::rareData(), and so we only need a
1009         loadLoadFence there to ensure that when we see a non-null pointer in
1010         m_rareData, the pointed object will be seen as a fully created
1011         FunctionRareData.
1012
1013
1014         For 2., the structure is created in
1015         ObjectAllocationProfile::initialize() (which appears to be called only by the
1016         JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
1017         which always happen in the JS thread), and read through
1018         ObjectAllocationProfile::structure() and
1019         ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
1020         put a storeStoreFence in ObjectAllocationProfile::initialize() and a
1021         loadLoadFence in ObjectAllocationProfile::structure() (and change
1022         ObjectAllocationProfile::inlineCapacity() to go through
1023         ObjectAllocationProfile::structure()).
1024
1025         We don't need a fence in ObjectAllocationProfile::clear() because
1026         clearing the structure is already as atomic as it gets.
1027
1028         Finally, notice that we don't care about the ObjectAllocationProfile's
1029         m_allocator as that is only used by ObjectAllocationProfile::initialize() and
1030         ObjectAllocationProfile::clear() that are always run in the JS thread.
1031         ObjectAllocationProfile::isNull() could cause some trouble, but it is
1032         currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
1033         thread.  Doing isNull()-style pre-checks would be wrong in any other concurrent
1034         thread anyway.
1035
1036         * bytecode/ObjectAllocationProfile.h:
1037         (JSC::ObjectAllocationProfile::initialize):
1038         (JSC::ObjectAllocationProfile::structure):
1039         (JSC::ObjectAllocationProfile::inlineCapacity):
1040         * runtime/JSFunction.cpp:
1041         (JSC::JSFunction::allocateAndInitializeRareData):
1042         * runtime/JSFunction.h:
1043         (JSC::JSFunction::rareData):
1044         (JSC::JSFunction::allocationStructure): Deleted.
1045         This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.
1046
1047 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
1048
1049         DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
1050         https://bugs.webkit.org/show_bug.cgi?id=143735
1051
1052         Reviewed by Geoffrey Garen.
1053
1054         We've always had bugs arising from the fact that we would MovHint something into a local,
1055         and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
1056         on those Nodes that were MovHinted. But this became increasingly tricky. Given the
1057         sophistication of the transformations we are doing today, this approach is just not sound
1058         anymore.
1059
1060         This comprehensively fixes these bugs by having the DFG backend automatically insert
1061         Phantoms just before codegen based on bytecode liveness. To make this practical, this also
1062         makes it much faster to query bytecode liveness.
1063
1064         It's about as perf-neutral as it gets for a change that increases compiler work without
1065         actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
1066         which should then speed us up. I can't really report concrete slow-down numbers because
1067         they are low enough to basically be in the noise. For example, a 20-iteration run of
1068         SunSpider yields "maybe 0.8% slower", whatever that means.
1069
1070         * CMakeLists.txt:
1071         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1072         * JavaScriptCore.xcodeproj/project.pbxproj:
1073         * bytecode/BytecodeLivenessAnalysis.cpp:
1074         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
1075         * bytecode/FullBytecodeLiveness.h:
1076         (JSC::FullBytecodeLiveness::getLiveness):
1077         * bytecode/VirtualRegister.h:
1078         (JSC::VirtualRegister::operator+):
1079         (JSC::VirtualRegister::operator-):
1080         * dfg/DFGForAllKills.h:
1081         (JSC::DFG::forAllLiveNodesAtTail):
1082         (JSC::DFG::forAllKilledOperands):
1083         (JSC::DFG::forAllKilledNodesAtNodeIndex):
1084         * dfg/DFGGraph.cpp:
1085         (JSC::DFG::Graph::isLiveInBytecode):
1086         (JSC::DFG::Graph::localsLiveInBytecode):
1087         * dfg/DFGGraph.h:
1088         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
1089         (JSC::DFG::Graph::forAllLiveInBytecode):
1090         * dfg/DFGMayExit.cpp:
1091         (JSC::DFG::mayExit):
1092         * dfg/DFGMovHintRemovalPhase.cpp:
1093         * dfg/DFGNodeType.h:
1094         * dfg/DFGPhantomInsertionPhase.cpp: Added.
1095         (JSC::DFG::performPhantomInsertion):
1096         * dfg/DFGPhantomInsertionPhase.h: Added.
1097         * dfg/DFGPlan.cpp:
1098         (JSC::DFG::Plan::compileInThreadImpl):
1099         * dfg/DFGScoreBoard.h:
1100         (JSC::DFG::ScoreBoard::sortFree):
1101         (JSC::DFG::ScoreBoard::assertClear):
1102         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
1103         (JSC::DFG::VirtualRegisterAllocationPhase::run):
1104         * ftl/FTLLowerDFGToLLVM.cpp:
1105         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1106         * tests/stress/phantom-inadequacy.js: Added.
1107         (bar):
1108         (baz):
1109         (foo):
1110
1111 2015-04-23  Filip Pizlo  <fpizlo@apple.com>
1112
1113         Rename HardPhantom to MustGenerate.
1114
1115         Rubber stamped by Geoffrey Garen.
1116
1117         We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
1118         is more than that; it's a utility for forcing the execution of otherwise killable nodes.
1119         NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
1120         node should just be called MustGenerate.
1121
1122         * dfg/DFGAbstractInterpreterInlines.h:
1123         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1124         * dfg/DFGArgumentsEliminationPhase.cpp:
1125         * dfg/DFGClobberize.h:
1126         (JSC::DFG::clobberize):
1127         * dfg/DFGDCEPhase.cpp:
1128         (JSC::DFG::DCEPhase::run):
1129         * dfg/DFGDoesGC.cpp:
1130         (JSC::DFG::doesGC):
1131         * dfg/DFGFixupPhase.cpp:
1132         (JSC::DFG::FixupPhase::fixupNode):
1133         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1134         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1135         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
1136         * dfg/DFGMayExit.cpp:
1137         (JSC::DFG::mayExit):
1138         * dfg/DFGNode.h:
1139         (JSC::DFG::Node::willHaveCodeGenOrOSR):
1140         * dfg/DFGNodeType.h:
1141         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1142         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1143         * dfg/DFGPhantomCanonicalizationPhase.cpp:
1144         (JSC::DFG::PhantomCanonicalizationPhase::run):
1145         * dfg/DFGPhantomRemovalPhase.cpp:
1146         (JSC::DFG::PhantomRemovalPhase::run):
1147         * dfg/DFGPredictionPropagationPhase.cpp:
1148         (JSC::DFG::PredictionPropagationPhase::propagate):
1149         * dfg/DFGSafeToExecute.h:
1150         (JSC::DFG::safeToExecute):
1151         * dfg/DFGSpeculativeJIT32_64.cpp:
1152         (JSC::DFG::SpeculativeJIT::compile):
1153         * dfg/DFGSpeculativeJIT64.cpp:
1154         (JSC::DFG::SpeculativeJIT::compile):
1155         * dfg/DFGTypeCheckHoistingPhase.cpp:
1156         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1157         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1158         * dfg/DFGVarargsForwardingPhase.cpp:
1159         * ftl/FTLCapabilities.cpp:
1160         (JSC::FTL::canCompile):
1161         * ftl/FTLLowerDFGToLLVM.cpp:
1162         (JSC::FTL::LowerDFGToLLVM::compileNode):
1163
1164 2015-04-23  Jordan Harband  <ljharb@gmail.com>
1165
1166         Implement `Object.assign`
1167         https://bugs.webkit.org/show_bug.cgi?id=143980
1168
1169         Reviewed by Filip Pizlo.
1170
1171         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign
1172
1173         * builtins/ObjectConstructor.js: Added.
1174         (assign):
1175         * runtime/CommonIdentifiers.h:
1176         * runtime/JSGlobalObject.cpp:
1177         (JSC::JSGlobalObject::init):
1178         * runtime/ObjectConstructor.cpp:
1179         * runtime/ObjectConstructor.h:
1180
1181 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
1182
1183         Unreviewed, fix debug build.
1184
1185         * dfg/DFGGraph.h:
1186         (JSC::DFG::Graph::performSubstitutionForEdge):
1187
1188 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
1189
1190         Nodes should have an optional epoch field
1191         https://bugs.webkit.org/show_bug.cgi?id=144084
1192
1193         Reviewed by Ryosuke Niwa and Mark Lam.
1194
1195         This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
1196         https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
1197         used.
1198
1199         * dfg/DFGCPSRethreadingPhase.cpp:
1200         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
1201         * dfg/DFGCSEPhase.cpp:
1202         * dfg/DFGEpoch.h:
1203         (JSC::DFG::Epoch::fromUnsigned):
1204         (JSC::DFG::Epoch::toUnsigned):
1205         * dfg/DFGGraph.cpp:
1206         (JSC::DFG::Graph::clearReplacements):
1207         (JSC::DFG::Graph::clearEpochs):
1208         * dfg/DFGGraph.h:
1209         (JSC::DFG::Graph::performSubstitutionForEdge):
1210         * dfg/DFGNode.h:
1211         (JSC::DFG::Node::Node):
1212         (JSC::DFG::Node::replaceWith):
1213         (JSC::DFG::Node::replacement):
1214         (JSC::DFG::Node::setReplacement):
1215         (JSC::DFG::Node::epoch):
1216         (JSC::DFG::Node::setEpoch):
1217         * dfg/DFGSSAConversionPhase.cpp:
1218         (JSC::DFG::SSAConversionPhase::run):
1219
1220 2015-04-22  Mark Lam  <mark.lam@apple.com>
1221
1222         Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
1223         https://bugs.webkit.org/show_bug.cgi?id=143898
1224
1225         Reviewed by Filip Pizlo.
1226
1227         CodeBlock::dumpSource() will access SourceCode strings in a way that requires
1228         ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
1229         compilation threads because StringImpls are not thread safe. As a result, we get
1230         an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
1231         build.
1232
1233         This patch fixes the issue by only collecting the CodeBlock (and associated info)
1234         into a DeferredSourceDump record while compiling, and stashing it away in a
1235         deferredSourceDump list in the DeferredCompilationCallback object to be dumped
1236         later.
1237
1238         When compilation is done, the callback object will be notified that
1239         compilationDidComplete().  We will dump the SourceCode strings from there.
1240         Since compilationDidComplete() is guaranteed to only be called on the thread
1241         doing JS execution, it is safe to access the SourceCode strings there and ref
1242         their underlying StringImpls as needed.
1243
1244         * CMakeLists.txt:
1245         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1246         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1247         * JavaScriptCore.xcodeproj/project.pbxproj:
1248         * bytecode/DeferredCompilationCallback.cpp:
1249         (JSC::DeferredCompilationCallback::compilationDidComplete):
1250         (JSC::DeferredCompilationCallback::sourceDumpInfo):
1251         (JSC::DeferredCompilationCallback::dumpCompiledSources):
1252         * bytecode/DeferredCompilationCallback.h:
1253         * bytecode/DeferredSourceDump.cpp: Added.
1254         (JSC::DeferredSourceDump::DeferredSourceDump):
1255         (JSC::DeferredSourceDump::dump):
1256         * bytecode/DeferredSourceDump.h: Added.
1257         * dfg/DFGByteCodeParser.cpp:
1258         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1259         * dfg/DFGDriver.cpp:
1260         (JSC::DFG::compileImpl):
1261
1262 2015-04-22  Benjamin Poulain  <benjamin@webkit.org>
1263
1264         Implement String.codePointAt()
1265         https://bugs.webkit.org/show_bug.cgi?id=143934
1266
1267         Reviewed by Darin Adler.
1268
1269         This patch adds String.codePointAt() as defined by ES6.
1270         I opted for a C++ implementation for now.
1271
1272         * runtime/StringPrototype.cpp:
1273         (JSC::StringPrototype::finishCreation):
1274         (JSC::codePointAt):
1275         (JSC::stringProtoFuncCodePointAt):
1276
1277 2015-04-22  Mark Lam  <mark.lam@apple.com>
1278
1279         SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
1280         https://bugs.webkit.org/show_bug.cgi?id=144067
1281
1282         Reviewed by Michael Saboff.
1283
1284         Currently, there are a few places where the JSObject that owns the
1285         SparseArrayValueMap is designated as the owner of the SparseArrayEntry
1286         write barrier.  This is a bug and can result in the GC collecting the
1287         SparseArrayEntry even though it is being referenced by the
1288         SparseArrayValueMap.  This patch fixes the bug.
1289
1290         * runtime/JSObject.cpp:
1291         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
1292         (JSC::JSObject::putIndexedDescriptor):
1293         * tests/stress/sparse-array-entry-update-144067.js: Added.
1294         (useMemoryToTriggerGCs):
1295         (foo):
1296
1297 2015-04-22  Mark Lam  <mark.lam@apple.com>
1298
1299         Give the heap object iterators the ability to return early.
1300         https://bugs.webkit.org/show_bug.cgi?id=144011
1301
1302         Reviewed by Michael Saboff.
1303
1304         JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
1305         candidate cell pointers, and, when in use, is called a lot more often than
1306         the normal way those iterators are used.  As a result, I see my instrumented
1307         VM killed with a SIGXCPU (CPU time limit exceeded).  This patch gives the
1308         callback functor the ability to tell the iterators to return early when the
1309         functor no longer needs to continue iterating.  With this, my instrumented
1310         VM is useful again for debugging.
1311
1312         Since heap iteration is not something that we do in a typical fast path,
1313         I don't expect this to have any noticeable impact on performance.
1314
1315         I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
1316         it checks JSCell addresses, not just JSObjects.
1317
1318         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1319         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1320         * JavaScriptCore.xcodeproj/project.pbxproj:
1321         * debugger/Debugger.cpp:
1322         * heap/GCLogging.cpp:
1323         (JSC::LoggingFunctor::operator()):
1324         * heap/Heap.cpp:
1325         (JSC::Zombify::visit):
1326         (JSC::Zombify::operator()):
1327         * heap/HeapStatistics.cpp:
1328         (JSC::StorageStatistics::visit):
1329         (JSC::StorageStatistics::operator()):
1330         * heap/HeapVerifier.cpp:
1331         (JSC::GatherLiveObjFunctor::visit):
1332         (JSC::GatherLiveObjFunctor::operator()):
1333         * heap/MarkedBlock.cpp:
1334         (JSC::SetNewlyAllocatedFunctor::operator()):
1335         * heap/MarkedBlock.h:
1336         (JSC::MarkedBlock::forEachCell):
1337         (JSC::MarkedBlock::forEachLiveCell):
1338         (JSC::MarkedBlock::forEachDeadCell):
1339         * heap/MarkedSpace.h:
1340         (JSC::MarkedSpace::forEachLiveCell):
1341         (JSC::MarkedSpace::forEachDeadCell):
1342         * inspector/agents/InspectorRuntimeAgent.cpp:
1343         (Inspector::TypeRecompiler::visit):
1344         (Inspector::TypeRecompiler::operator()):
1345         * runtime/IterationStatus.h: Added.
1346         * runtime/JSGlobalObject.cpp:
1347         * runtime/VM.cpp:
1348         (JSC::StackPreservingRecompiler::visit):
1349         (JSC::StackPreservingRecompiler::operator()):
1350         * tools/JSDollarVMPrototype.cpp:
1351         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
1352         (JSC::CellAddressCheckFunctor::operator()):
1353         (JSC::JSDollarVMPrototype::isValidCell):
1354         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
1355         (JSC::ObjectAddressCheckFunctor::operator()): Deleted.
1356
1357 2015-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1358
1359         [[Set]] should be properly executed in JS builtins
1360         https://bugs.webkit.org/show_bug.cgi?id=143996
1361
1362         Reviewed by Geoffrey Garen.
1363
1364         Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
1365         However,
1366
1367         1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
1368         2. It's different from the default JS behavior.
1369
1370         In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
1371         And dropping the current hack for builtins.
1372
1373         * builtins/Array.prototype.js:
1374         (filter):
1375         (map):
1376         (find):
1377         * bytecompiler/BytecodeGenerator.cpp:
1378         (JSC::BytecodeGenerator::emitPutByVal):
1379         * tests/stress/array-fill-put-by-val.js: Added.
1380         (shouldThrow):
1381         (.set get array):
1382         * tests/stress/array-filter-put-by-val-direct.js: Added.
1383         (shouldBe):
1384         (.set get var):
1385         * tests/stress/array-find-does-not-lookup-twice.js: Added.
1386         (shouldBe):
1387         (shouldThrow):
1388         (.get shouldBe):
1389         * tests/stress/array-from-put-by-val-direct.js: Added.
1390         (shouldBe):
1391         (.set get var):
1392         * tests/stress/array-from-set-length.js: Added.
1393         (shouldBe):
1394         (ArrayLike):
1395         (ArrayLike.prototype.set length):
1396         (ArrayLike.prototype.get length):
1397         * tests/stress/array-map-put-by-val-direct.js: Added.
1398         (shouldBe):
1399         (.set get var):
1400
1401 2015-04-22  Basile Clement  <basile_clement@apple.com>
1402
1403         Don't de-allocate FunctionRareData
1404         https://bugs.webkit.org/show_bug.cgi?id=144000
1405
1406         Reviewed by Michael Saboff.
1407
1408         A function rare data (containing most notably its allocation profile) is currently
1409         freed and re-allocated each time the function's prototype is cleared.
1410         This is not optimal as it means we are invalidating the watchpoint and recompiling the
1411         scope each time the prototype is cleared.
1412
1413         This makes it so that a single rare data is reused, clearing the underlying
1414         ObjectAllocationProfile instead of throwing away the whole rare data on
1415         .prototype updates.
1416
1417         * runtime/FunctionRareData.cpp:
1418         (JSC::FunctionRareData::create):
1419         (JSC::FunctionRareData::finishCreation):
1420         * runtime/FunctionRareData.h:
1421         * runtime/JSFunction.cpp:
1422         (JSC::JSFunction::allocateAndInitializeRareData):
1423         (JSC::JSFunction::initializeRareData):
1424
1425 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
1426
1427         Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.
1428
1429         * dfg/DFGSpeculativeJIT32_64.cpp:
1430         (JSC::DFG::SpeculativeJIT::compile):
1431
1432 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
1433
1434         DFG should allow Phantoms after terminals
1435         https://bugs.webkit.org/show_bug.cgi?id=126778
1436
1437         Reviewed by Mark Lam.
1438
1439         It's important for us to be able to place liveness-marking nodes after nodes that do
1440         things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
1441         terminals. That made things awkward, especially for Switch and Branch, which may do
1442         things that necessitate liveness markers (for example they might want to use a converted
1443         version of a value rather than the value that was MovHinted). We previously made this
1444         work by disallowing certain optimizations on Switch and Branch, which was probably a bad
1445         thing.
1446
1447         This changes our IR to allow for the terminal to not be the last node in a block. Asking
1448         for the terminal involves a search. DFG::validate() checks that the nodes after the
1449         terminal are liveness markers that have no effects or checks.
1450
1451         This is perf-neutral but will allow more optimizations in the future. It will also make
1452         it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.
1453
1454         * dfg/DFGBasicBlock.cpp:
1455         (JSC::DFG::BasicBlock::replaceTerminal):
1456         * dfg/DFGBasicBlock.h:
1457         (JSC::DFG::BasicBlock::findTerminal):
1458         (JSC::DFG::BasicBlock::terminal):
1459         (JSC::DFG::BasicBlock::insertBeforeTerminal):
1460         (JSC::DFG::BasicBlock::numSuccessors):
1461         (JSC::DFG::BasicBlock::successor):
1462         (JSC::DFG::BasicBlock::successorForCondition):
1463         (JSC::DFG::BasicBlock::successors):
1464         (JSC::DFG::BasicBlock::last): Deleted.
1465         (JSC::DFG::BasicBlock::takeLast): Deleted.
1466         (JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
1467         (JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
1468         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
1469         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
1470         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
1471         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
1472         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
1473         (JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
1474         (JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
1475         * dfg/DFGBasicBlockInlines.h:
1476         (JSC::DFG::BasicBlock::appendNonTerminal):
1477         (JSC::DFG::BasicBlock::replaceTerminal):
1478         * dfg/DFGByteCodeParser.cpp:
1479         (JSC::DFG::ByteCodeParser::addToGraph):
1480         (JSC::DFG::ByteCodeParser::inlineCall):
1481         (JSC::DFG::ByteCodeParser::handleInlining):
1482         (JSC::DFG::ByteCodeParser::parseBlock):
1483         (JSC::DFG::ByteCodeParser::linkBlock):
1484         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1485         * dfg/DFGCFGSimplificationPhase.cpp:
1486         (JSC::DFG::CFGSimplificationPhase::run):
1487         (JSC::DFG::CFGSimplificationPhase::convertToJump):
1488         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
1489         * dfg/DFGCPSRethreadingPhase.cpp:
1490         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1491         * dfg/DFGCommon.h:
1492         (JSC::DFG::NodeAndIndex::NodeAndIndex):
1493         (JSC::DFG::NodeAndIndex::operator!):
1494         * dfg/DFGFixupPhase.cpp:
1495         (JSC::DFG::FixupPhase::fixupBlock):
1496         (JSC::DFG::FixupPhase::fixupNode):
1497         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
1498         (JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
1499         * dfg/DFGForAllKills.h:
1500         (JSC::DFG::forAllLiveNodesAtTail):
1501         * dfg/DFGGraph.cpp:
1502         (JSC::DFG::Graph::terminalsAreValid):
1503         (JSC::DFG::Graph::dumpBlockHeader):
1504         * dfg/DFGGraph.h:
1505         * dfg/DFGInPlaceAbstractState.cpp:
1506         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
1507         * dfg/DFGLICMPhase.cpp:
1508         (JSC::DFG::LICMPhase::run):
1509         (JSC::DFG::LICMPhase::attemptHoist):
1510         * dfg/DFGMovHintRemovalPhase.cpp:
1511         * dfg/DFGNode.h:
1512         (JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
1513         (JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
1514         (JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
1515         (JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
1516         (JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
1517         (JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
1518         (JSC::DFG::Node::SuccessorsIterable::begin):
1519         (JSC::DFG::Node::SuccessorsIterable::end):
1520         (JSC::DFG::Node::successors):
1521         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1522         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
1523         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
1524         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
1525         * dfg/DFGPhantomRemovalPhase.cpp:
1526         (JSC::DFG::PhantomRemovalPhase::run):
1527         * dfg/DFGPutStackSinkingPhase.cpp:
1528         * dfg/DFGSSAConversionPhase.cpp:
1529         (JSC::DFG::SSAConversionPhase::run):
1530         * dfg/DFGSpeculativeJIT.h:
1531         (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
1532         * dfg/DFGSpeculativeJIT32_64.cpp:
1533         (JSC::DFG::SpeculativeJIT::compile):
1534         * dfg/DFGSpeculativeJIT64.cpp:
1535         (JSC::DFG::SpeculativeJIT::compile):
1536         * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
1537         (JSC::DFG::StaticExecutionCountEstimationPhase::run):
1538         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1539         (JSC::DFG::TierUpCheckInjectionPhase::run):
1540         * dfg/DFGValidate.cpp:
1541         (JSC::DFG::Validate::validate):
1542         * ftl/FTLLowerDFGToLLVM.cpp:
1543         (JSC::FTL::LowerDFGToLLVM::compileNode):
1544         * tests/stress/closure-call-exit.js: Added.
1545         (foo):
1546
1547 2015-04-21  Basile Clement  <basile_clement@apple.com>
1548
1549         PhantomNewObject should be marked NodeMustGenerate
1550         https://bugs.webkit.org/show_bug.cgi?id=143974
1551
1552         Reviewed by Filip Pizlo.
1553
1554         * dfg/DFGNode.h:
1555         (JSC::DFG::Node::convertToPhantomNewObject):
1556         Was not properly marking NodeMustGenerate when converting.
1557
1558 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
1559
1560         DFG Call/ConstructForwardVarargs fails to restore the stack pointer
1561         https://bugs.webkit.org/show_bug.cgi?id=144007
1562
1563         Reviewed by Mark Lam.
1564
1565         We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
1566         if isForwardVarargs.
1567
1568         * dfg/DFGSpeculativeJIT32_64.cpp:
1569         (JSC::DFG::SpeculativeJIT::emitCall):
1570         * dfg/DFGSpeculativeJIT64.cpp:
1571         (JSC::DFG::SpeculativeJIT::emitCall):
1572         * tests/stress/varargs-then-slow-call.js: Added.
1573         (foo):
1574         (bar):
1575         (fuzz):
1576         (baz):
1577
1578 2015-04-21  Basile Clement  <basile_clement@apple.com>
1579
1580         Remove AllocationProfileWatchpoint node
1581         https://bugs.webkit.org/show_bug.cgi?id=143999
1582
1583         Reviewed by Filip Pizlo.
1584
1585         * dfg/DFGAbstractInterpreterInlines.h:
1586         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1587         * dfg/DFGByteCodeParser.cpp:
1588         (JSC::DFG::ByteCodeParser::parseBlock):
1589         * dfg/DFGClobberize.h:
1590         (JSC::DFG::clobberize):
1591         * dfg/DFGDoesGC.cpp:
1592         (JSC::DFG::doesGC):
1593         * dfg/DFGFixupPhase.cpp:
1594         (JSC::DFG::FixupPhase::fixupNode):
1595         * dfg/DFGHeapLocation.cpp:
1596         (WTF::printInternal):
1597         * dfg/DFGHeapLocation.h:
1598         * dfg/DFGNode.h:
1599         (JSC::DFG::Node::hasCellOperand):
1600         * dfg/DFGNodeType.h:
1601         * dfg/DFGPredictionPropagationPhase.cpp:
1602         (JSC::DFG::PredictionPropagationPhase::propagate):
1603         * dfg/DFGSafeToExecute.h:
1604         (JSC::DFG::safeToExecute):
1605         * dfg/DFGSpeculativeJIT32_64.cpp:
1606         (JSC::DFG::SpeculativeJIT::compile):
1607         * dfg/DFGSpeculativeJIT64.cpp:
1608         (JSC::DFG::SpeculativeJIT::compile):
1609         * dfg/DFGWatchpointCollectionPhase.cpp:
1610         (JSC::DFG::WatchpointCollectionPhase::handle):
1611         * ftl/FTLCapabilities.cpp:
1612         (JSC::FTL::canCompile):
1613         * ftl/FTLLowerDFGToLLVM.cpp:
1614         (JSC::FTL::LowerDFGToLLVM::compileNode):
1615         * runtime/JSFunction.h:
1616         (JSC::JSFunction::rareData):
1617         (JSC::JSFunction::allocationProfileWatchpointSet): Deleted.
1618
1619 2015-04-19  Filip Pizlo  <fpizlo@apple.com>
1620
1621         MovHint should be a strong use
1622         https://bugs.webkit.org/show_bug.cgi?id=143734
1623
1624         Reviewed by Geoffrey Garen.
1625
1626         This disables any DCE that assumes equivalence between DFG IR uses and bytecode uses. Doing
1627         so is a major step towards allowing more fancy DFG transformations and also probably fixing
1628         some bugs.
1629
1630         Just making MovHint a strong use would also completely disable DCE. So we mitigate this by
1631         introducing a MovHint removal phase that runs in FTL.
1632
1633         This is a slight slowdown on Octane/gbemu, but it's basically neutral on suite averages.
1634
1635         * CMakeLists.txt:
1636         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1637         * JavaScriptCore.xcodeproj/project.pbxproj:
1638         * bytecode/CodeOrigin.cpp:
1639         (JSC::InlineCallFrame::dumpInContext):
1640         * dfg/DFGDCEPhase.cpp:
1641         (JSC::DFG::DCEPhase::fixupBlock):
1642         * dfg/DFGDisassembler.cpp:
1643         (JSC::DFG::Disassembler::createDumpList):
1644         * dfg/DFGEpoch.cpp: Added.
1645         (JSC::DFG::Epoch::dump):
1646         * dfg/DFGEpoch.h: Added.
1647         (JSC::DFG::Epoch::Epoch):
1648         (JSC::DFG::Epoch::first):
1649         (JSC::DFG::Epoch::operator!):
1650         (JSC::DFG::Epoch::next):
1651         (JSC::DFG::Epoch::bump):
1652         (JSC::DFG::Epoch::operator==):
1653         (JSC::DFG::Epoch::operator!=):
1654         * dfg/DFGMayExit.cpp:
1655         (JSC::DFG::mayExit):
1656         * dfg/DFGMovHintRemovalPhase.cpp: Added.
1657         (JSC::DFG::performMovHintRemoval):
1658         * dfg/DFGMovHintRemovalPhase.h: Added.
1659         * dfg/DFGNodeType.h:
1660         * dfg/DFGPlan.cpp:
1661         (JSC::DFG::Plan::compileInThreadImpl):
1662         * dfg/DFGSpeculativeJIT.cpp:
1663         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1664         * dfg/DFGSpeculativeJIT64.cpp:
1665         (JSC::DFG::SpeculativeJIT::compile):
1666         * runtime/Options.h:
1667
1668 2015-04-21  Basile Clement  <basile_clement@apple.com>
1669
1670         REGRESSION (r182899): icloud.com crashes
1671         https://bugs.webkit.org/show_bug.cgi?id=143960
1672
1673         Reviewed by Filip Pizlo.
1674
1675         * runtime/JSFunction.h:
1676         (JSC::JSFunction::allocationStructure):
1677         * tests/stress/dfg-rare-data.js: Added.
1678         (F): Regression test
1679
1680 2015-04-21  Michael Saboff  <msaboff@apple.com>
1681
1682         Crash in JSC::Interpreter::execute
1683         https://bugs.webkit.org/show_bug.cgi?id=142625
1684
1685         Reviewed by Filip Pizlo.
1686
1687         We need to keep the FunctionExecutables in the code block for the eval flavor of
1688         Interpreter::execute() in order to create the scope used to eval.
1689
1690         * bytecode/CodeBlock.cpp:
1691         (JSC::CodeBlock::jettisonFunctionDeclsAndExprs): Deleted.
1692         * bytecode/CodeBlock.h:
1693         * dfg/DFGGraph.cpp:
1694         (JSC::DFG::Graph::registerFrozenValues):
1695
1696 2015-04-21  Chris Dumez  <cdumez@apple.com>
1697
1698         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&) constructor explicit
1699         https://bugs.webkit.org/show_bug.cgi?id=143970
1700
1701         Reviewed by Darin Adler.
1702
1703         Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&)
1704         constructor explicit as it copies the vector and it is easy to call it
1705         by mistake.
1706
1707         * bytecode/UnlinkedInstructionStream.cpp:
1708         (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
1709         * bytecode/UnlinkedInstructionStream.h:
1710         * ftl/FTLLowerDFGToLLVM.cpp:
1711         (JSC::FTL::LowerDFGToLLVM::lower):
1712
1713 2015-04-20  Basile Clement  <basile_clement@apple.com>
1714
1715         PhantomNewObject should be marked NodeMustGenerate
1716         https://bugs.webkit.org/show_bug.cgi?id=143974
1717
1718         Reviewed by Filip Pizlo.
1719
1720         * dfg/DFGNodeType.h: Mark PhantomNewObject as NodeMustGenerate
1721
1722 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
1723
1724         Cleanup some StringBuilder use
1725         https://bugs.webkit.org/show_bug.cgi?id=143550
1726
1727         Reviewed by Darin Adler.
1728
1729         * runtime/Symbol.cpp:
1730         (JSC::Symbol::descriptiveString):
1731         * runtime/TypeProfiler.cpp:
1732         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
1733         * runtime/TypeSet.cpp:
1734         (JSC::TypeSet::toJSONString):
1735         (JSC::StructureShape::propertyHash):
1736         (JSC::StructureShape::stringRepresentation):
1737         (JSC::StructureShape::toJSONString):
1738
1739 2015-04-20  Mark Lam  <mark.lam@apple.com>
1740
1741         Add debugging tools to test if a given pointer is a valid object and in the heap.
1742         https://bugs.webkit.org/show_bug.cgi?id=143910
1743
1744         Reviewed by Geoffrey Garen.
1745
1746         When doing debugging from lldb, sometimes, it is useful to be able to tell if a
1747         purported JSObject is really a valid object in the heap or not.  We can add the
1748         following utility functions to help:
1749             isValidCell(heap, candidate) - returns true if the candidate is a "live" cell in the heap.
1750             isInHeap(heap, candidate) - returns true if the candidate is the heap's Object space or Storage space.
1751             isInObjectSpace(heap, candidate) - returns true if the candidate is the heap's Object space.
1752             isInStorageSpace(heap, candidate) - returns true if the candidate is the heap's Storage space.
1753
1754         Also moved lldb callable debug utility function prototypes from
1755         JSDollarVMPrototype.cpp to JSDollarVMPrototype.h as static members of the
1756         JSDollarVMPrototype class.  This is so that we can conveniently #include that
1757         file to get the prototypes when we need to call them programmatically from
1758         instrumentation that we add while debugging an issue.
1759
1760         * heap/Heap.h:
1761         (JSC::Heap::storageSpace):
1762         * tools/JSDollarVMPrototype.cpp:
1763         (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
1764         (JSC::ensureCurrentThreadOwnsJSLock):
1765         (JSC::JSDollarVMPrototype::gc):
1766         (JSC::functionGC):
1767         (JSC::JSDollarVMPrototype::edenGC):
1768         (JSC::functionEdenGC):
1769         (JSC::JSDollarVMPrototype::isInHeap):
1770         (JSC::JSDollarVMPrototype::isInObjectSpace):
1771         (JSC::JSDollarVMPrototype::isInStorageSpace):
1772         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor):
1773         (JSC::ObjectAddressCheckFunctor::operator()):
1774         (JSC::JSDollarVMPrototype::isValidCell):
1775         (JSC::JSDollarVMPrototype::isValidCodeBlock):
1776         (JSC::JSDollarVMPrototype::codeBlockForFrame):
1777         (JSC::functionCodeBlockForFrame):
1778         (JSC::codeBlockFromArg):
1779         (JSC::JSDollarVMPrototype::printCallFrame):
1780         (JSC::JSDollarVMPrototype::printStack):
1781         (JSC::JSDollarVMPrototype::printValue):
1782         (JSC::currentThreadOwnsJSLock): Deleted.
1783         (JSC::gc): Deleted.
1784         (JSC::edenGC): Deleted.
1785         (JSC::isValidCodeBlock): Deleted.
1786         (JSC::codeBlockForFrame): Deleted.
1787         (JSC::printCallFrame): Deleted.
1788         (JSC::printStack): Deleted.
1789         (JSC::printValue): Deleted.
1790         * tools/JSDollarVMPrototype.h:
1791
1792 2015-04-20  Joseph Pecoraro  <pecoraro@apple.com>
1793
1794         Web Inspector: Improve Support for WeakSet in Console
1795         https://bugs.webkit.org/show_bug.cgi?id=143951
1796
1797         Reviewed by Darin Adler.
1798
1799         * inspector/InjectedScriptSource.js:
1800         * inspector/JSInjectedScriptHost.cpp:
1801         (Inspector::JSInjectedScriptHost::subtype):
1802         (Inspector::JSInjectedScriptHost::weakSetSize):
1803         (Inspector::JSInjectedScriptHost::weakSetEntries):
1804         * inspector/JSInjectedScriptHost.h:
1805         * inspector/JSInjectedScriptHostPrototype.cpp:
1806         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1807         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
1808         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
1809         Treat WeakSets like special sets.
1810
1811         * inspector/protocol/Runtime.json:
1812         Add a new object subtype, "weakset".
1813
1814 2015-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1815
1816         HashMap storing PropertyKey StringImpl* need to use IdentifierRepHash to handle Symbols
1817         https://bugs.webkit.org/show_bug.cgi?id=143947
1818
1819         Reviewed by Darin Adler.
1820
1821         Type profiler has map between PropertyKey (StringImpl*) and offset.
1822         StringImpl* is also used for Symbol PropertyKey.
1823         So equality of hash tables is considered by interned StringImpl*'s pointer value.
1824         To do so, use IdentifierRepHash instead of StringHash.
1825
1826         * runtime/SymbolTable.h:
1827
1828 2015-04-20  Jordan Harband  <ljharb@gmail.com>
1829
1830         Implement `Object.is`
1831         https://bugs.webkit.org/show_bug.cgi?id=143865
1832
1833         Reviewed by Darin Adler.
1834
1835         Expose sameValue to JS, via Object.is
1836         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.is
1837
1838         * runtime/ObjectConstructor.cpp:
1839         (JSC::objectConstructorIs):
1840         * runtime/PropertyDescriptor.cpp:
1841         (JSC::sameValue):
1842
1843 2015-04-19  Darin Adler  <darin@apple.com>
1844
1845         Remove all the remaining uses of OwnPtr and PassOwnPtr in JavaScriptCore
1846         https://bugs.webkit.org/show_bug.cgi?id=143941
1847
1848         Reviewed by Gyuyoung Kim.
1849
1850         * API/JSCallbackObject.h: Use unique_ptr for m_callbackObjectData.
1851         * API/JSCallbackObjectFunctions.h: Ditto.
1852
1853         * API/ObjCCallbackFunction.h: Use unique_ptr for the arguments to the
1854         create function and the constructor and for m_impl.
1855         * API/ObjCCallbackFunction.mm:
1856         (CallbackArgumentOfClass::CallbackArgumentOfClass): Streamline this
1857         class by using RetainPtr<Class>.
1858         (ArgumentTypeDelegate::typeInteger): Use make_unique.
1859         (ArgumentTypeDelegate::typeDouble): Ditto.
1860         (ArgumentTypeDelegate::typeBool): Ditto.
1861         (ArgumentTypeDelegate::typeVoid): Ditto.
1862         (ArgumentTypeDelegate::typeId): Ditto.
1863         (ArgumentTypeDelegate::typeOfClass): Ditto.
1864         (ArgumentTypeDelegate::typeBlock): Ditto.
1865         (ArgumentTypeDelegate::typeStruct): Ditto.
1866         (ResultTypeDelegate::typeInteger): Ditto.
1867         (ResultTypeDelegate::typeDouble): Ditto.
1868         (ResultTypeDelegate::typeBool): Ditto.
1869         (ResultTypeDelegate::typeVoid): Ditto.
1870         (ResultTypeDelegate::typeId): Ditto.
1871         (ResultTypeDelegate::typeOfClass): Ditto.
1872         (ResultTypeDelegate::typeBlock): Ditto.
1873         (ResultTypeDelegate::typeStruct): Ditto.
1874         (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): Use
1875         unique_ptr for the arguments to the constructor, m_arguments, and m_result.
1876         Use RetainPtr<Class> for m_instanceClass.
1877         (JSC::objCCallbackFunctionCallAsConstructor): Use nullptr instead of nil or 0
1878         for non-Objective-C object pointer null.
1879         (JSC::ObjCCallbackFunction::ObjCCallbackFunction): Use unique_ptr for
1880         the arguments to the constructor and for m_impl.
1881         (JSC::ObjCCallbackFunction::create): Use unique_ptr for arguments.
1882         (skipNumber): Mark this static since it's local to this source file.
1883         (objCCallbackFunctionForInvocation): Call parseObjCType without doing any
1884         explicit adoptPtr since the types in the traits are now unique_ptr. Also use
1885         nullptr instead of nil for JSObjectRef values.
1886         (objCCallbackFunctionForMethod): Tweaked comment.
1887         (objCCallbackFunctionForBlock): Use nullptr instead of 0 for JSObjectRef.
1888
1889         * bytecode/CallLinkInfo.h: Removed unneeded include of OwnPtr.h.
1890
1891         * heap/GCThread.cpp:
1892         (JSC::GCThread::GCThread): Use unique_ptr.
1893         * heap/GCThread.h: Use unique_ptr for arguments to the constructor and for
1894         m_slotVisitor and m_copyVisitor.
1895         * heap/GCThreadSharedData.cpp:
1896         (JSC::GCThreadSharedData::GCThreadSharedData): Ditto.
1897
1898         * parser/SourceProvider.h: Removed unneeded include of PassOwnPtr.h.
1899
1900 2015-04-19  Benjamin Poulain  <benjamin@webkit.org>
1901
1902         Improve the feature.json files
1903
1904         * features.json:
1905
1906 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1907
1908         Introduce bytecode intrinsics
1909         https://bugs.webkit.org/show_bug.cgi?id=143926
1910
1911         Reviewed by Filip Pizlo.
1912
1913         This patch introduces bytecode level intrinsics into builtins/*.js JS code.
1914         When implementing functions in builtins/*.js,
1915         sometimes we require lower level functionality.
1916
1917         For example, in the current Array.from, we use `result[k] = value`.
1918         The spec requires `[[DefineOwnProperty]]` operation here.
1919         However, usual `result[k] = value` is evaluated as `[[Set]]`. (`PutValue` => `[[Set]]`)
1920         So if we implement `Array.prototype[k]` getter/setter, the difference is observable.
1921
1922         Ideally, reaching here, we would like to use put_by_val_direct bytecode.
1923         However, there's no syntax to generate it directly.
1924
1925         This patch introduces bytecode level intrinsics into JSC BytecodeCompiler.
1926         Like @call, @apply, we introduce a new node, Intrinsic.
1927         These are generated when calling appropriate private symbols in privileged code.
1928         AST parser detects them and generates Intrinsic nodes and
1929         BytecodeCompiler detects them and generate required bytecodes.
1930
1931         Currently, Array.from implementation works fine without this patch.
1932         This is because when the target code is builtin JS,
1933         BytecodeGenerator emits put_by_val_direct instead of put_by_val.
1934         This solves the above issue. However, instead of solving this issue,
1935         it raises another issue; There's no way to emit `[[Set]]` operation.
1936         `[[Set]]` operation is actually used in the spec (Array.from's "length" is set by `[[Set]]`).
1937         So to implement it precisely, introducing bytecode level intrinsics is necessary.
1938
1939         In the subsequent fixes, we'll remove that special path emitting put_by_val_direct
1940         for `result[k] = value` under builtin JS environment. Instead of that special handling,
1941         use bytecode intrinsics instead. It solves problems and it is more intuitive
1942         because written JS code in builtin works as the same to the usual JS code.
1943
1944         * CMakeLists.txt:
1945         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1946         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1947         * JavaScriptCore.xcodeproj/project.pbxproj:
1948         * builtins/ArrayConstructor.js:
1949         (from):
1950         * bytecode/BytecodeIntrinsicRegistry.cpp: Added.
1951         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1952         (JSC::BytecodeIntrinsicRegistry::lookup):
1953         * bytecode/BytecodeIntrinsicRegistry.h: Added.
1954         * bytecompiler/NodesCodegen.cpp:
1955         (JSC::BytecodeIntrinsicNode::emitBytecode):
1956         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
1957         * parser/ASTBuilder.h:
1958         (JSC::ASTBuilder::makeFunctionCallNode):
1959         * parser/NodeConstructors.h:
1960         (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
1961         * parser/Nodes.h:
1962         (JSC::BytecodeIntrinsicNode::identifier):
1963         * runtime/CommonIdentifiers.cpp:
1964         (JSC::CommonIdentifiers::CommonIdentifiers):
1965         * runtime/CommonIdentifiers.h:
1966         (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry):
1967         * tests/stress/array-from-with-accessors.js: Added.
1968         (shouldBe):
1969
1970 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1971
1972         Make Builtin functions non constructible
1973         https://bugs.webkit.org/show_bug.cgi?id=143923
1974
1975         Reviewed by Darin Adler.
1976
1977         Builtin functions defined by builtins/*.js accidentally have [[Construct]].
1978         According to the spec, these functions except for explicitly defined as a constructor do not have [[Construct]].
1979         This patch fixes it. When the JS function used for a construction is builtin function, throw not a constructor error.
1980
1981         Ideally, returning ConstructTypeNone in JSFunction::getConstructData is enough.
1982         However, to avoid calling getConstructData (it involves indirect call of function pointer of getConstructData), some places do not check ConstructType.
1983         In these places, they only check the target function is JSFunction because previously JSFunction always has [[Construct]].
1984         So in this patch, we check `isBuiltinFunction()` in those places.
1985
1986         * dfg/DFGByteCodeParser.cpp:
1987         (JSC::DFG::ByteCodeParser::inliningCost):
1988         * jit/JITOperations.cpp:
1989         * llint/LLIntSlowPaths.cpp:
1990         (JSC::LLInt::setUpCall):
1991         * runtime/JSFunction.cpp:
1992         (JSC::JSFunction::getConstructData):
1993         * tests/stress/builtin-function-is-construct-type-none.js: Added.
1994         (shouldThrow):
1995
1996 2015-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1997
1998         [ES6] Implement WeakSet
1999         https://bugs.webkit.org/show_bug.cgi?id=142408
2000
2001         Reviewed by Darin Adler.
2002
2003         This patch implements ES6 WeakSet.
2004         Current implementation simply leverages WeakMapData with undefined value.
2005         This WeakMapData should be optimized in the same manner as MapData/SetData in the subsequent patch[1].
2006
2007         And in this patch, we also fix WeakMap/WeakSet behavior to conform the ES6 spec.
2008         Except for adders (WeakMap.prototype.set/WeakSet.prototype.add),
2009         methods return false (or undefined for WeakMap.prototype.get)
2010         when a key is not Object instead of throwing a type error.
2011
2012         [1]: https://bugs.webkit.org/show_bug.cgi?id=143919
2013
2014         * CMakeLists.txt:
2015         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2016         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2017         * JavaScriptCore.xcodeproj/project.pbxproj:
2018         * runtime/CommonIdentifiers.h:
2019         * runtime/JSGlobalObject.cpp:
2020         * runtime/JSGlobalObject.h:
2021         * runtime/JSWeakSet.cpp: Added.
2022         (JSC::JSWeakSet::finishCreation):
2023         (JSC::JSWeakSet::visitChildren):
2024         * runtime/JSWeakSet.h: Added.
2025         (JSC::JSWeakSet::createStructure):
2026         (JSC::JSWeakSet::create):
2027         (JSC::JSWeakSet::weakMapData):
2028         (JSC::JSWeakSet::JSWeakSet):
2029         * runtime/WeakMapPrototype.cpp:
2030         (JSC::getWeakMapData):
2031         (JSC::protoFuncWeakMapDelete):
2032         (JSC::protoFuncWeakMapGet):
2033         (JSC::protoFuncWeakMapHas):
2034         * runtime/WeakSetConstructor.cpp: Added.
2035         (JSC::WeakSetConstructor::finishCreation):
2036         (JSC::callWeakSet):
2037         (JSC::constructWeakSet):
2038         (JSC::WeakSetConstructor::getConstructData):
2039         (JSC::WeakSetConstructor::getCallData):
2040         * runtime/WeakSetConstructor.h: Added.
2041         (JSC::WeakSetConstructor::create):
2042         (JSC::WeakSetConstructor::createStructure):
2043         (JSC::WeakSetConstructor::WeakSetConstructor):
2044         * runtime/WeakSetPrototype.cpp: Added.
2045         (JSC::WeakSetPrototype::finishCreation):
2046         (JSC::getWeakMapData):
2047         (JSC::protoFuncWeakSetDelete):
2048         (JSC::protoFuncWeakSetHas):
2049         (JSC::protoFuncWeakSetAdd):
2050         * runtime/WeakSetPrototype.h: Added.
2051         (JSC::WeakSetPrototype::create):
2052         (JSC::WeakSetPrototype::createStructure):
2053         (JSC::WeakSetPrototype::WeakSetPrototype):
2054         * tests/stress/weak-set-constructor-adder.js: Added.
2055         (WeakSet.prototype.add):
2056         * tests/stress/weak-set-constructor.js: Added.
2057
2058 2015-04-17  Alexey Proskuryakov  <ap@apple.com>
2059
2060         Remove unused BoundsCheckedPointer
2061         https://bugs.webkit.org/show_bug.cgi?id=143896
2062
2063         Reviewed by Geoffrey Garen.
2064
2065         * bytecode/SpeculatedType.cpp: The header was included here.
2066
2067 2015-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2068
2069         [ES6] Fix name enumeration of static functions for Symbol constructor
2070         https://bugs.webkit.org/show_bug.cgi?id=143891
2071
2072         Reviewed by Geoffrey Garen.
2073
2074         Fix missing symbolPrototypeTable registration to the js class object.
2075         This patch fixes name enumeration of static functions (Symbol.key, Symbol.keyFor) for Symbol constructor.
2076
2077         * runtime/SymbolConstructor.cpp:
2078
2079 2015-04-17  Basile Clement  <basile_clement@apple.com>
2080
2081         Inline JSFunction allocation in DFG
2082         https://bugs.webkit.org/show_bug.cgi?id=143858
2083
2084         Reviewed by Filip Pizlo.
2085
2086         Followup to my previous patch which inlines JSFunction allocation when
2087         using FTL, now also enabled in DFG.
2088
2089         * dfg/DFGSpeculativeJIT.cpp:
2090         (JSC::DFG::SpeculativeJIT::compileNewFunction):
2091
2092 2015-04-16  Jordan Harband  <ljharb@gmail.com>
2093
2094         Number.parseInt is not === global parseInt in nightly r182673
2095         https://bugs.webkit.org/show_bug.cgi?id=143799
2096
2097         Reviewed by Darin Adler.
2098
2099         Ensuring parseInt === Number.parseInt, per spec
2100         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
2101
2102         * runtime/CommonIdentifiers.h:
2103         * runtime/JSGlobalObject.cpp:
2104         (JSC::JSGlobalObject::init):
2105         * runtime/JSGlobalObject.h:
2106         (JSC::JSGlobalObject::parseIntFunction):
2107         * runtime/NumberConstructor.cpp:
2108         (JSC::NumberConstructor::finishCreation):
2109
2110 2015-04-16  Mark Lam  <mark.lam@apple.com>
2111
2112         Gardening: fix CLOOP build after r182927.
2113
2114         Not reviewed.
2115
2116         * interpreter/StackVisitor.cpp:
2117         (JSC::StackVisitor::Frame::print):
2118
2119 2015-04-16  Basile Clement  <basile_clement@apple.com>
2120
2121         Inline JSFunction allocation in FTL
2122         https://bugs.webkit.org/show_bug.cgi?id=143851
2123
2124         Reviewed by Filip Pizlo.
2125
2126         JSFunction allocation is a simple operation that should be inlined when possible.
2127
2128         * ftl/FTLAbstractHeapRepository.h:
2129         * ftl/FTLLowerDFGToLLVM.cpp:
2130         (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
2131         * runtime/JSFunction.h:
2132         (JSC::JSFunction::allocationSize):
2133
2134 2015-04-16  Mark Lam  <mark.lam@apple.com>
2135
2136         Add $vm debugging tool.
2137         https://bugs.webkit.org/show_bug.cgi?id=143809
2138
2139         Reviewed by Geoffrey Garen.
2140
2141         For debugging VM bugs, it would be useful to be able to dump VM data structures
2142         from JS code that we instrument.  To this end, let's introduce a
2143         JS_enableDollarVM option that, if true, installs an $vm property into each JS
2144         global object at creation time.  The $vm property refers to an object that
2145         provides a collection of useful utility functions.  For this initial
2146         implementation, $vm will have the following:
2147
2148             crash() - trigger an intentional crash.
2149
2150             dfgTrue() - returns true if the current function is DFG compiled, else returns false.
2151             jitTrue() - returns true if the current function is compiled by the baseline JIT, else returns false.
2152             llintTrue() - returns true if the current function is interpreted by the LLINT, else returns false.
2153
2154             gc() - runs a full GC.
2155             edenGC() - runs an eden GC.
2156
2157             codeBlockForFrame(frameNumber) - gets the codeBlock at the specified frame (0 = current, 1 = caller, etc).
2158             printSourceFor(codeBlock) - prints the source code for the codeBlock.
2159             printByteCodeFor(codeBlock) - prints the bytecode for the codeBlock.
2160
2161             print(str) - prints a string to dataLog output.
2162             printCallFrame() - prints the current CallFrame.
2163             printStack() - prints the JS stack.
2164             printInternal(value) - prints the JSC internal info for the specified value.
2165
2166         With JS_enableDollarVM=true, JS code can use the above functions like so:
2167
2168             $vm.print("Using $vm features\n");
2169
2170         * CMakeLists.txt:
2171         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2172         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2173         * JavaScriptCore.xcodeproj/project.pbxproj:
2174         * bytecode/CodeBlock.cpp:
2175         (JSC::CodeBlock::printCallOp):
2176         - FTL compiled functions don't like it when we try to compute the CallLinkStatus.
2177           Hence, we skip this step if we're dumping an FTL codeBlock.
2178
2179         * heap/Heap.cpp:
2180         (JSC::Heap::collectAndSweep):
2181         (JSC::Heap::collectAllGarbage): Deleted.
2182         * heap/Heap.h:
2183         (JSC::Heap::collectAllGarbage):
2184         - Add ability to do an Eden collection and sweep.
2185
2186         * interpreter/StackVisitor.cpp:
2187         (JSC::printIndents):
2188         (JSC::log):
2189         (JSC::logF):
2190         (JSC::StackVisitor::Frame::print):
2191         (JSC::jitTypeName): Deleted.
2192         (JSC::printif): Deleted.
2193         - Modernize the implementation of StackVisitor::Frame::print(), and remove some
2194           now redundant code.
2195         - Also fix it so that it downgrades gracefully when encountering inlined DFG
2196           and compiled FTL functions.
2197
2198         (DebugPrintFrameFunctor::DebugPrintFrameFunctor): Deleted.
2199         (DebugPrintFrameFunctor::operator()): Deleted.
2200         (debugPrintCallFrame): Deleted.
2201         (debugPrintStack): Deleted.
2202         - these have been moved into JSDollarVMPrototype.cpp.
2203
2204         * interpreter/StackVisitor.h:
2205         - StackVisitor::Frame::print() is now enabled for release builds as well so that
2206           we can call it from $vm.
2207
2208         * runtime/JSGlobalObject.cpp:
2209         (JSC::JSGlobalObject::init):
2210         (JSC::JSGlobalObject::visitChildren):
2211         * runtime/JSGlobalObject.h:
2212         - Added the $vm instance to global objects conditional on the JSC_enableDollarVM
2213           option.
2214
2215         * runtime/Options.h:
2216         - Added the JSC_enableDollarVM option.
2217
2218         * tools/JSDollarVM.cpp: Added.
2219         * tools/JSDollarVM.h: Added.
2220         (JSC::JSDollarVM::createStructure):
2221         (JSC::JSDollarVM::create):
2222         (JSC::JSDollarVM::JSDollarVM):
2223
2224         * tools/JSDollarVMPrototype.cpp: Added.
2225         - This file contains 2 sets of functions:
2226
2227           a. a C++ implementation of debugging utility functions that are callable when
2228              doing debugging from lldb.  To the extent possible, these functions try to
2229              be cautious and not cause unintended crashes should the user call them with
2230              the wrong info.  Hence, they are designed to be robust rather than speedy.
2231
2232           b. the native implementations of JS functions in the $vm object.  Where there
2233              is overlapping functionality, these are built on top of the C++ functions
2234              above to do the work.
2235
2236           Note: it does not make sense for all of the $vm functions to have a C++
2237           counterpart for lldb debugging.  For example, the $vm.dfgTrue() function is
2238           only useful for JS code, and works via the DFG intrinsics mechanism.
2239           When doing debugging via lldb, the optimization level of the currently
2240           executing JS function can be gotten by dumping the current CallFrame instead.
2241
2242         (JSC::currentThreadOwnsJSLock):
2243         (JSC::ensureCurrentThreadOwnsJSLock):
2244         (JSC::JSDollarVMPrototype::addFunction):
2245         (JSC::functionCrash): - $vm.crash()
2246         (JSC::functionDFGTrue): - $vm.dfgTrue()
2247         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
2248         (JSC::CallerFrameJITTypeFunctor::operator()):
2249         (JSC::CallerFrameJITTypeFunctor::jitType):
2250         (JSC::functionLLintTrue): - $vm.llintTrue()
2251         (JSC::functionJITTrue): - $vm.jitTrue()
2252         (JSC::gc):
2253         (JSC::functionGC): - $vm.gc()
2254         (JSC::edenGC):
2255         (JSC::functionEdenGC): - $vm.edenGC()
2256         (JSC::isValidCodeBlock):
2257         (JSC::codeBlockForFrame):
2258         (JSC::functionCodeBlockForFrame): - $vm.codeBlockForFrame(frameNumber)
2259         (JSC::codeBlockFromArg):
2260         (JSC::functionPrintSourceFor): - $vm.printSourceFor(codeBlock)
2261         (JSC::functionPrintByteCodeFor): - $vm.printBytecodeFor(codeBlock)
2262         (JSC::functionPrint): - $vm.print(str)
2263         (JSC::PrintFrameFunctor::PrintFrameFunctor):
2264         (JSC::PrintFrameFunctor::operator()):
2265         (JSC::printCallFrame):
2266         (JSC::printStack):
2267         (JSC::functionPrintCallFrame): - $vm.printCallFrame()
2268         (JSC::functionPrintStack): - $vm.printStack()
2269         (JSC::printValue):
2270         (JSC::functionPrintValue): - $vm.printValue()
2271         (JSC::JSDollarVMPrototype::finishCreation):
2272         * tools/JSDollarVMPrototype.h: Added.
2273         (JSC::JSDollarVMPrototype::create):
2274         (JSC::JSDollarVMPrototype::createStructure):
2275         (JSC::JSDollarVMPrototype::JSDollarVMPrototype):
2276
2277 2015-04-16  Geoffrey Garen  <ggaren@apple.com>
2278
2279         Speculative fix after r182915
2280         https://bugs.webkit.org/show_bug.cgi?id=143404
2281
2282         Reviewed by Alexey Proskuryakov.
2283
2284         * runtime/SymbolConstructor.h:
2285
2286 2015-04-16  Mark Lam  <mark.lam@apple.com>
2287
2288         Fixed some typos in a comment.
2289
2290         Not reviewed.
2291
2292         * dfg/DFGGenerationInfo.h:
2293
2294 2015-04-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2295
2296         [ES6] Implement Symbol.for and Symbol.keyFor
2297         https://bugs.webkit.org/show_bug.cgi?id=143404
2298
2299         Reviewed by Geoffrey Garen.
2300
2301         This patch implements Symbol.for and Symbol.keyFor.
2302         SymbolRegistry maintains registered StringImpl* symbols.
2303         And to make this mapping enabled over realms,
2304         VM owns this mapping (not JSGlobalObject).
2305
2306         While there's Default AtomicStringTable per thread,
2307         SymbolRegistry should not exist over VMs.
2308         So everytime VM is created, SymbolRegistry is also created.
2309
2310         In SymbolRegistry implementation, we don't leverage WeakGCMap (or weak reference design).
2311         Theres are several reasons.
2312         1. StringImpl* which represents identity of Symbols is not GC-managed object.
2313            So we cannot use WeakGCMap directly.
2314            While Symbol* is GC-managed object, holding weak reference to Symbol* doesn't maintain JS symbols (exposed primitive values to users) liveness,
2315            because distinct Symbol* can exist.
2316            Distinct Symbol* means the Symbol* object that pointer value (Symbol*) is different from weakly referenced Symbol* but held StringImpl* is the same.
2317
2318         2. We don't use WTF::WeakPtr. If we add WeakPtrFactory into StringImpl's member, we can track StringImpl*'s liveness by WeakPtr.
2319            However there's problem about when we prune staled entries in SymbolRegistry.
2320            Since the memory allocated for the Symbol is typically occupied by allocated symbolized StringImpl*'s content,
2321            and it is not in GC-heap.
2322            While heavily registering Symbols and storing StringImpl* into SymbolRegistry, Heap's EdenSpace is not so occupied.
2323            So GC typically attempt to perform EdenCollection, and it doesn't call WeakGCMap's pruleStaleEntries callback.
2324            As a result, before pruning staled entries in SymbolRegistry, fast malloc-ed memory fills up the system memory.
2325
2326         So instead of using Weak reference, we take relatively easy design.
2327         When we register symbolized StringImpl* into SymbolRegistry, symbolized StringImpl* is aware of that.
2328         And when destructing it, it removes its reference from SymbolRegistry as if atomic StringImpl do so with AtomicStringTable.
2329
2330         * CMakeLists.txt:
2331         * DerivedSources.make:
2332         * runtime/SymbolConstructor.cpp:
2333         (JSC::SymbolConstructor::getOwnPropertySlot):
2334         (JSC::symbolConstructorFor):
2335         (JSC::symbolConstructorKeyFor):
2336         * runtime/SymbolConstructor.h:
2337         * runtime/VM.cpp:
2338         * runtime/VM.h:
2339         (JSC::VM::symbolRegistry):
2340         * tests/stress/symbol-registry.js: Added.
2341         (test):
2342
2343 2015-04-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2344
2345         [ES6] Use specific functions for @@iterator functions
2346         https://bugs.webkit.org/show_bug.cgi?id=143838
2347
2348         Reviewed by Geoffrey Garen.
2349
2350         In ES6, some methods are defined with the different names.
2351
2352         For example,
2353
2354         Map.prototype[Symbol.iterator] === Map.prototype.entries
2355         Set.prototype[Symbol.iterator] === Set.prototype.values
2356         Array.prototype[Symbol.iterator] === Array.prototype.values
2357         %Arguments%[Symbol.iterator] === Array.prototype.values
2358
2359         However, current implementation creates different function objects per name.
2360         This patch fixes it by setting the object that is used for the other method to @@iterator.
2361         e.g. Setting Array.prototype.values function object to Array.prototype[Symbol.iterator].
2362
2363         And we drop Arguments' iterator implementation and replace Argument[@@iterator] implementation
2364         with Array.prototype.values to conform to the spec.
2365
2366         * CMakeLists.txt:
2367         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2368         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2369         * JavaScriptCore.xcodeproj/project.pbxproj:
2370         * inspector/JSInjectedScriptHost.cpp:
2371         (Inspector::JSInjectedScriptHost::subtype):
2372         (Inspector::JSInjectedScriptHost::getInternalProperties):
2373         (Inspector::JSInjectedScriptHost::iteratorEntries):
2374         * runtime/ArgumentsIteratorConstructor.cpp: Removed.
2375         * runtime/ArgumentsIteratorConstructor.h: Removed.
2376         * runtime/ArgumentsIteratorPrototype.cpp: Removed.
2377         * runtime/ArgumentsIteratorPrototype.h: Removed.
2378         * runtime/ArrayPrototype.cpp:
2379         (JSC::ArrayPrototype::finishCreation):
2380         * runtime/ArrayPrototype.h:
2381         * runtime/ClonedArguments.cpp:
2382         (JSC::ClonedArguments::getOwnPropertySlot):
2383         (JSC::ClonedArguments::put):
2384         (JSC::ClonedArguments::deleteProperty):
2385         (JSC::ClonedArguments::defineOwnProperty):
2386         (JSC::ClonedArguments::materializeSpecials):
2387         * runtime/ClonedArguments.h:
2388         * runtime/CommonIdentifiers.h:
2389         * runtime/DirectArguments.cpp:
2390         (JSC::DirectArguments::overrideThings):
2391         * runtime/GenericArgumentsInlines.h:
2392         (JSC::GenericArguments<Type>::getOwnPropertySlot):
2393         (JSC::GenericArguments<Type>::getOwnPropertyNames):
2394         (JSC::GenericArguments<Type>::put):
2395         (JSC::GenericArguments<Type>::deleteProperty):
2396         (JSC::GenericArguments<Type>::defineOwnProperty):
2397         * runtime/JSArgumentsIterator.cpp: Removed.
2398         * runtime/JSArgumentsIterator.h: Removed.
2399         * runtime/JSGlobalObject.cpp:
2400         (JSC::JSGlobalObject::init):
2401         (JSC::JSGlobalObject::visitChildren):
2402         * runtime/JSGlobalObject.h:
2403         (JSC::JSGlobalObject::arrayProtoValuesFunction):
2404         * runtime/MapPrototype.cpp:
2405         (JSC::MapPrototype::finishCreation):
2406         * runtime/ScopedArguments.cpp:
2407         (JSC::ScopedArguments::overrideThings):
2408         * runtime/SetPrototype.cpp:
2409         (JSC::SetPrototype::finishCreation):
2410         * tests/stress/arguments-iterator.js: Added.
2411         (test):
2412         (testArguments):
2413         * tests/stress/iterator-functions.js: Added.
2414         (test):
2415         (argumentsTests):
2416
2417 2015-04-14  Mark Lam  <mark.lam@apple.com>
2418
2419         Add JSC_functionOverrides=<overrides file> debugging tool.
2420         https://bugs.webkit.org/show_bug.cgi?id=143717
2421
2422         Reviewed by Geoffrey Garen.
2423
2424         This tool allows us to do runtime replacement of function bodies with alternatives
2425         for debugging purposes.  For example, this is useful when we need to debug VM bugs
2426         which manifest in scripts executing in webpages downloaded from remote servers
2427         that we don't control.  The tool allows us to augment those scripts with logging
2428         or test code to help isolate the bugs.
2429
2430         This tool works by substituting the SourceCode at FunctionExecutable creation
2431         time.  It identifies which SourceCode to substitute by comparing the source
2432         string against keys in a set of key value pairs.
2433
2434         The keys are function body strings defined by 'override' clauses in the overrides
2435         file specified by in the JSC_functionOverrides option.  The values are function
2436         body strings defines by 'with' clauses in the overrides file.
2437         See comment blob at top of FunctionOverrides.cpp on the formatting
2438         of the overrides file.
2439
2440         At FunctionExecutable creation time, if the SourceCode string matches one of the
2441         'override' keys from the overrides file, the tool will replace the SourceCode with
2442         a new one based on the corresponding 'with' value string.  The FunctionExecutable
2443         will then be created with the new SourceCode instead.
2444
2445         Some design decisions:
2446         1. We opted to require that the 'with' clause appear on a separate line than the
2447            'override' clause because this makes it easier to read and write when the
2448            'override' clause's function body is single lined and long.
2449
2450         2. The user can use any sequence of characters for the delimiter (except for '{',
2451            '}' and white space characters) because this ensures that there can always be
2452            some delimiter pattern that does not appear in the function body in the clause
2453            e.g. in the body of strings in the JS code.
2454
2455            '{' and '}' are disallowed because they are used to mark the boundaries of the
2456            function body string.  White space characters are disallowed because they can
2457            be error prone (the user may not be able to tell between spaces and tabs).
2458
2459         3. The start and end delimiter must be an identical sequence of characters.
2460
2461            I had considered allowing the use of complementary characters like <>, [], and
2462            () for making delimiter pairs like:
2463                [[[[ ... ]]]]
2464                <[([( ... )])]>
2465
2466            But in the end, decided against it because:
2467            a. These sequences of complementary characters can exists in JS code.
2468               In contrast, a repeating delimiter like %%%% is unlikely to appear in JS
2469               code.
2470            b. It can be error prone for the user to have to type the exact complement
2471               character for the end delimiter in reverse order.
2472               In contrast, a repeating delimiter like %%%% is much easier to type and
2473               less error prone.  Even a sequence like @#$%^ is less error prone than
2474               a complementary sequence because it can be copy-pasted, and need not be
2475               typed in reverse order.
2476            c. It is easier to parse for the same delimiter string for both start and end.
2477
2478         4. The tool does a lot of checks for syntax errors in the overrides file because
2479            we don't want any overrides to fail silently.  If a syntax error is detected,
2480            the tool will print an error message and call exit().  This avoids the user
2481            wasting time doing debugging only to be surprised later that their specified
2482            overrides did not take effect because of some unnoticed typo.
2483
2484         * CMakeLists.txt:
2485         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2486         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2487         * JavaScriptCore.xcodeproj/project.pbxproj:
2488         * bytecode/UnlinkedCodeBlock.cpp:
2489         (JSC::UnlinkedFunctionExecutable::link):
2490         * runtime/Executable.h:
2491         * runtime/Options.h:
2492         * tools/FunctionOverrides.cpp: Added.
2493         (JSC::FunctionOverrides::overrides):
2494         (JSC::FunctionOverrides::FunctionOverrides):
2495         (JSC::initializeOverrideInfo):
2496         (JSC::FunctionOverrides::initializeOverrideFor):
2497         (JSC::hasDisallowedCharacters):
2498         (JSC::parseClause):
2499         (JSC::FunctionOverrides::parseOverridesInFile):
2500         * tools/FunctionOverrides.h: Added.
2501
2502 2015-04-16  Basile Clement  <basile_clement@apple.com>
2503
2504         Extract the allocation profile from JSFunction into a rare object
2505         https://bugs.webkit.org/show_bug.cgi?id=143807
2506
2507         Reviewed by Filip Pizlo.
2508
2509         The allocation profile is only needed for those functions that are used
2510         to create objects with [new].
2511         Extracting it into its own JSCell removes the need for JSFunction and
2512         JSCallee to be JSDestructibleObjects, which should improve performances in most
2513         cases at the cost of an extra pointer dereference when the allocation profile
2514         is actually needed.
2515
2516         * CMakeLists.txt:
2517         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2518         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2519         * JavaScriptCore.xcodeproj/project.pbxproj:
2520         * dfg/DFGOperations.cpp:
2521         * dfg/DFGSpeculativeJIT32_64.cpp:
2522         (JSC::DFG::SpeculativeJIT::compile):
2523         * dfg/DFGSpeculativeJIT64.cpp:
2524         (JSC::DFG::SpeculativeJIT::compile):
2525         * jit/JITOpcodes.cpp:
2526         (JSC::JIT::emit_op_create_this):
2527         * jit/JITOpcodes32_64.cpp:
2528         (JSC::JIT::emit_op_create_this):
2529         * llint/LowLevelInterpreter32_64.asm:
2530         * llint/LowLevelInterpreter64.asm:
2531         * runtime/CommonSlowPaths.cpp:
2532         (JSC::SLOW_PATH_DECL):
2533         * runtime/FunctionRareData.cpp: Added.
2534         (JSC::FunctionRareData::create):
2535         (JSC::FunctionRareData::destroy):
2536         (JSC::FunctionRareData::createStructure):
2537         (JSC::FunctionRareData::visitChildren):
2538         (JSC::FunctionRareData::FunctionRareData):
2539         (JSC::FunctionRareData::~FunctionRareData):
2540         (JSC::FunctionRareData::finishCreation):
2541         * runtime/FunctionRareData.h: Added.
2542         (JSC::FunctionRareData::offsetOfAllocationProfile):
2543         (JSC::FunctionRareData::allocationProfile):
2544         (JSC::FunctionRareData::allocationStructure):
2545         (JSC::FunctionRareData::allocationProfileWatchpointSet):
2546         * runtime/JSBoundFunction.cpp:
2547         (JSC::JSBoundFunction::destroy): Deleted.
2548         * runtime/JSBoundFunction.h:
2549         * runtime/JSCallee.cpp:
2550         (JSC::JSCallee::destroy): Deleted.
2551         * runtime/JSCallee.h:
2552         * runtime/JSFunction.cpp:
2553         (JSC::JSFunction::JSFunction):
2554         (JSC::JSFunction::createRareData):
2555         (JSC::JSFunction::visitChildren):
2556         (JSC::JSFunction::put):
2557         (JSC::JSFunction::defineOwnProperty):
2558         (JSC::JSFunction::destroy): Deleted.
2559         (JSC::JSFunction::createAllocationProfile): Deleted.
2560         * runtime/JSFunction.h:
2561         (JSC::JSFunction::offsetOfRareData):
2562         (JSC::JSFunction::rareData):
2563         (JSC::JSFunction::allocationStructure):
2564         (JSC::JSFunction::allocationProfileWatchpointSet):
2565         (JSC::JSFunction::offsetOfAllocationProfile): Deleted.
2566         (JSC::JSFunction::allocationProfile): Deleted.
2567         * runtime/JSFunctionInlines.h:
2568         (JSC::JSFunction::JSFunction):
2569         * runtime/VM.cpp:
2570         (JSC::VM::VM):
2571         * runtime/VM.h:
2572
2573 2015-04-16  Csaba Osztrogonác  <ossy@webkit.org>
2574
2575         Remove the unnecessary WTF_CHANGES define
2576         https://bugs.webkit.org/show_bug.cgi?id=143825
2577
2578         Reviewed by Andreas Kling.
2579
2580         * config.h:
2581
2582 2015-04-15  Andreas Kling  <akling@apple.com>
2583
2584         Make MarkedBlock and WeakBlock 4x smaller.
2585         <https://webkit.org/b/143802>
2586
2587         Reviewed by Mark Hahnenberg.
2588
2589         To reduce GC heap fragmentation and generally use less memory, reduce the size of MarkedBlock
2590         and its buddy WeakBlock by 4x, bringing them from 64kB+4kB to 16kB+1kB.
2591
2592         In a sampling of cool web sites, I'm seeing ~8% average reduction in overall GC heap size.
2593         Some examples:
2594
2595                    apple.com:  6.3MB ->  5.5MB (14.5% smaller)
2596                   reddit.com:  4.5MB ->  4.1MB ( 9.7% smaller)
2597                  twitter.com: 23.2MB -> 21.4MB ( 8.4% smaller)
2598             cuteoverload.com: 24.5MB -> 23.6MB ( 3.8% smaller)
2599
2600         Benchmarks look mostly neutral.
2601         Some small slowdowns on Octane, some slightly bigger speedups on Kraken and SunSpider.
2602
2603         * heap/MarkedBlock.h:
2604         * heap/WeakBlock.h:
2605         * llint/LLIntData.cpp:
2606         (JSC::LLInt::Data::performAssertions):
2607         * llint/LowLevelInterpreter.asm:
2608
2609 2015-04-15  Jordan Harband  <ljharb@gmail.com>
2610
2611         String.prototype.startsWith/endsWith/includes have wrong length in r182673
2612         https://bugs.webkit.org/show_bug.cgi?id=143659
2613
2614         Reviewed by Benjamin Poulain.
2615
2616         Fix lengths of String.prototype.{includes,startsWith,endsWith} per spec
2617         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
2618         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
2619         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
2620
2621         * runtime/StringPrototype.cpp:
2622         (JSC::StringPrototype::finishCreation):
2623
2624 2015-04-15  Mark Lam  <mark.lam@apple.com>
2625
2626         Remove obsolete VMInspector debugging tool.
2627         https://bugs.webkit.org/show_bug.cgi?id=143798
2628
2629         Reviewed by Michael Saboff.
2630
2631         I added the VMInspector tool 3 years ago to aid in VM hacking work.  Some of it
2632         has bit rotted, and now the VM also has better ways to achieve its functionality.
2633         Hence this code is now obsolete and should be removed.
2634
2635         * CMakeLists.txt:
2636         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2637         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2638         * JavaScriptCore.xcodeproj/project.pbxproj:
2639         * interpreter/CallFrame.h:
2640         * interpreter/VMInspector.cpp: Removed.
2641         * interpreter/VMInspector.h: Removed.
2642         * llint/LowLevelInterpreter.cpp:
2643
2644 2015-04-15  Jordan Harband  <ljharb@gmail.com>
2645
2646         Math.imul has wrong length in Safari 8.0.4
2647         https://bugs.webkit.org/show_bug.cgi?id=143658
2648
2649         Reviewed by Benjamin Poulain.
2650
2651         Correcting function length from 1, to 2, to match spec
2652         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-math.imul
2653
2654         * runtime/MathObject.cpp:
2655         (JSC::MathObject::finishCreation):
2656
2657 2015-04-15  Jordan Harband  <ljharb@gmail.com>
2658
2659         Number.parseInt in nightly r182673 has wrong length
2660         https://bugs.webkit.org/show_bug.cgi?id=143657
2661
2662         Reviewed by Benjamin Poulain.
2663
2664         Correcting function length from 1, to 2, to match spec
2665         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
2666
2667         * runtime/NumberConstructor.cpp:
2668         (JSC::NumberConstructor::finishCreation):
2669
2670 2015-04-15  Filip Pizlo  <fpizlo@apple.com>
2671
2672         Harden DFGForAllKills
2673         https://bugs.webkit.org/show_bug.cgi?id=143792
2674
2675         Reviewed by Geoffrey Garen.
2676
2677         Unfortunately, we don't have a good way to test this yet - but it will be needed to prevent
2678         bugs in https://bugs.webkit.org/show_bug.cgi?id=143734.
2679
2680         Previously ForAllKills used the bytecode kill analysis. That seemed like a good idea because
2681         that analysis is cheaper than the full liveness analysis. Unfortunately, it's probably wrong:
2682
2683         - It looks for kill sites at forExit origin boundaries. But, something might have been killed
2684           by an operation that was logically in between the forExit origins at the boundary, but was
2685           removed from the DFG for whatever reason. The DFG is allowed to have bytecode instruction
2686           gaps.
2687
2688         - It overlooked the fact that a MovHint that addresses a local that is always live kills that
2689           local. For example, storing to an argument means that the prior value of the argument is
2690           killed.
2691
2692         This fixes the analysis by making it handle MovHints directly, and making it define kills in
2693         the most conservative way possible: it asks if you were live before but dead after. If we
2694         have the compile time budget to afford this more direct approach, then it's definitel a good
2695         idea since it's so fool-proof.
2696
2697         * dfg/DFGArgumentsEliminationPhase.cpp:
2698         * dfg/DFGForAllKills.h:
2699         (JSC::DFG::forAllKilledOperands):
2700         (JSC::DFG::forAllKilledNodesAtNodeIndex):
2701         (JSC::DFG::forAllDirectlyKilledOperands): Deleted.
2702
2703 2015-04-15  Joseph Pecoraro  <pecoraro@apple.com>
2704
2705         Provide SPI to allow changing whether JSContexts are remote debuggable by default
2706         https://bugs.webkit.org/show_bug.cgi?id=143681
2707
2708         Reviewed by Darin Adler.
2709
2710         * API/JSRemoteInspector.h:
2711         * API/JSRemoteInspector.cpp:
2712         (JSRemoteInspectorGetInspectionEnabledByDefault):
2713         (JSRemoteInspectorSetInspectionEnabledByDefault):
2714         Provide SPI to toggle the default enabled inspection state of debuggables.
2715
2716         * API/JSContextRef.cpp:
2717         (JSGlobalContextCreateInGroup):
2718         Respect the default setting.
2719
2720 2015-04-15  Joseph Pecoraro  <pecoraro@apple.com>
2721
2722         JavaScriptCore: Use kCFAllocatorDefault where possible
2723         https://bugs.webkit.org/show_bug.cgi?id=143747
2724
2725         Reviewed by Darin Adler.
2726
2727         * heap/HeapTimer.cpp:
2728         (JSC::HeapTimer::HeapTimer):
2729         * inspector/remote/RemoteInspectorDebuggableConnection.mm:
2730         (Inspector::RemoteInspectorInitializeGlobalQueue):
2731         (Inspector::RemoteInspectorDebuggableConnection::setupRunLoop):
2732         For consistency and readability use the constant instead of
2733         different representations of null.
2734
2735 2015-04-14  Michael Saboff  <msaboff@apple.com>
2736
2737         Remove JavaScriptCoreUseJIT default from JavaScriptCore
2738         https://bugs.webkit.org/show_bug.cgi?id=143746
2739
2740         Reviewed by Mark Lam.
2741
2742         * runtime/VM.cpp:
2743         (JSC::enableAssembler):
2744
2745 2015-04-14  Chris Dumez  <cdumez@apple.com>
2746
2747         Regression(r180020): Web Inspector crashes on pages that have a stylesheet with an invalid MIME type
2748         https://bugs.webkit.org/show_bug.cgi?id=143745
2749         <rdar://problem/20243916>
2750
2751         Reviewed by Joseph Pecoraro.
2752
2753         Add assertion in ContentSearchUtilities::findMagicComment() to make
2754         sure the content String is not null or we would crash in
2755         JSC::Yarr::interpret() later.
2756
2757         * inspector/ContentSearchUtilities.cpp:
2758         (Inspector::ContentSearchUtilities::findMagicComment):
2759
2760 2015-04-14  Michael Saboff  <msaboff@apple.com>
2761
2762         DFG register fillSpeculate*() functions should validate incoming spill format is compatible with requested fill format
2763         https://bugs.webkit.org/show_bug.cgi?id=143727
2764
2765         Reviewed by Geoffrey Garen.
2766
2767         Used the result of AbstractInterpreter<>::filter() to check that the current spill format is compatible
2768         with the requested fill format.  If filter() reports a contradiction, then we force an OSR exit.
2769         Removed individual checks made redundant by the new check.
2770
2771         * dfg/DFGSpeculativeJIT32_64.cpp:
2772         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
2773         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2774         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2775         * dfg/DFGSpeculativeJIT64.cpp:
2776         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
2777         (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
2778         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2779         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2780
2781 2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>
2782
2783         Replace JavaScriptCoreOutputConsoleMessagesToSystemConsole default with an SPI
2784         https://bugs.webkit.org/show_bug.cgi?id=143691
2785
2786         Reviewed by Geoffrey Garen.
2787
2788         * API/JSRemoteInspector.h:
2789         * API/JSRemoteInspector.cpp:
2790         (JSRemoteInspectorSetLogToSystemConsole):
2791         Add SPI to enable/disable logging to the system console.
2792         This only affects JSContext `console` logs and warnings.
2793
2794         * inspector/JSGlobalObjectConsoleClient.h:
2795         * inspector/JSGlobalObjectConsoleClient.cpp:
2796         (Inspector::JSGlobalObjectConsoleClient::logToSystemConsole):
2797         (Inspector::JSGlobalObjectConsoleClient::setLogToSystemConsole):
2798         (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
2799         (Inspector::JSGlobalObjectConsoleClient::initializeLogToSystemConsole): Deleted.
2800         Simplify access to the setting now that it doesn't need to
2801         initialize its value from preferences.
2802
2803 2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>
2804
2805         Web Inspector: Auto-attach fails after r179562, initialization too late after dispatch
2806         https://bugs.webkit.org/show_bug.cgi?id=143682
2807
2808         Reviewed by Timothy Hatcher.
2809
2810         * inspector/remote/RemoteInspector.mm:
2811         (Inspector::RemoteInspector::singleton):
2812         If we are on the main thread, run the initialization immediately.
2813         Otherwise dispatch to the main thread. This way if the first JSContext
2814         was created on the main thread it can get auto-attached if applicable.
2815
2816 2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>
2817
2818         Unreviewed build fix for Mavericks.
2819
2820         Mavericks includes this file but does not enable ENABLE_REMOTE_INSPECTOR
2821         so the Inspector namespace is not available when compiling this file.
2822
2823         * API/JSRemoteInspector.cpp:
2824
2825 2015-04-14  Joseph Pecoraro  <pecoraro@apple.com>
2826
2827         Web Inspector: Expose private APIs to interact with RemoteInspector instead of going through WebKit
2828         https://bugs.webkit.org/show_bug.cgi?id=143729
2829
2830         Reviewed by Timothy Hatcher.
2831
2832         * API/JSRemoteInspector.h: Added.
2833         * API/JSRemoteInspector.cpp: Added.
2834         (JSRemoteInspectorDisableAutoStart):
2835         (JSRemoteInspectorStart):
2836         (JSRemoteInspectorSetParentProcessInformation):
2837         Add the new SPIs for basic remote inspection behavior.
2838
2839         * JavaScriptCore.xcodeproj/project.pbxproj:
2840         Add the new files to Mac only, since remote inspection is only
2841         enabled there anyways.
2842
2843 2015-04-14  Mark Lam  <mark.lam@apple.com>
2844
2845         Rename JSC_dfgFunctionWhitelistFile to JSC_dfgWhitelist.
2846         https://bugs.webkit.org/show_bug.cgi?id=143722
2847
2848         Reviewed by Michael Saboff.
2849
2850         Renaming JSC_dfgFunctionWhitelistFile to JSC_dfgWhitelist so that it is
2851         shorter, and easier to remember (without having to look it up) and to
2852         type.  JSC options now support descriptions, and one can always look up
2853         the description if the option's purpose is not already obvious.
2854
2855         * dfg/DFGFunctionWhitelist.cpp:
2856         (JSC::DFG::FunctionWhitelist::ensureGlobalWhitelist):
2857         (JSC::DFG::FunctionWhitelist::contains):
2858         * runtime/Options.h:
2859
2860 2015-04-13  Filip Pizlo  <fpizlo@apple.com>
2861
2862         Unreviewed, fix Windows build. Windows doesn't take kindly to private classes that use FAST_ALLOCATED.
2863
2864         * runtime/InferredValue.h:
2865
2866 2015-04-13  Filip Pizlo  <fpizlo@apple.com>
2867
2868         Unreviewed, fix build. I introduced a new cell type at the same time as kling changed how new cell types are written.
2869
2870         * runtime/InferredValue.h:
2871
2872 2015-04-08  Filip Pizlo  <fpizlo@apple.com>
2873
2874         JSC should detect singleton functions
2875         https://bugs.webkit.org/show_bug.cgi?id=143232
2876
2877         Reviewed by Geoffrey Garen.
2878
2879         This started out as an attempt to make constructors faster by detecting when a constructor is a
2880         singleton. The idea is that each FunctionExecutable has a VariableWatchpointSet - a watchpoint
2881         along with an inferred value - that detects if only one JSFunction has been allocated for that
2882         executable, and if so, what that JSFunction is. Then, inside the code for the FunctionExecutable,
2883         if the watchpoint set has an inferred value (i.e. it's been initialized and it is still valid),
2884         we can constant-fold GetCallee.
2885
2886         Unfortunately, constructors don't use GetCallee anymore, so that didn't pan out. But in the
2887         process I realized a bunch of things:
2888
2889         - This allows us to completely eliminate the GetCallee/GetScope sequence that we still sometimes
2890           had even in code where our singleton-closure detection worked. That's because singleton-closure
2891           inference worked at the op_resolve_scope, and that op_resolve_scope still needed to keep alive
2892           the incoming scope in case we OSR exit. But by constant-folding GetCallee, that sequence
2893           disappears. OSR exit can rematerialize the callee or the scope by just knowing their constant
2894           values.
2895
2896         - Singleton detection should be a reusable thing. So, I got rid of VariableWatchpointSet and
2897           created InferredValue. InferredValue is a cell, so it can handle its own GC magic.
2898           FunctionExecutable uses an InferredValue to tell you about singleton JSFunctions.
2899
2900         - The old singleton-scope detection in op_resolve_scope is better abstracted as a SymbolTable
2901           detecting a singleton JSSymbolTableObject. So, SymbolTable uses an InferredValue to tell you
2902           about singleton JSSymbolTableObjects. It's curious that we want to have singleton detection in
2903           SymbolTable if we already have it in FunctionExecutable. This comes into play in two ways.
2904           First, it means that the DFG can realize sooner that a resolve_scope resolves to a constant
2905           scope. Ths saves compile times and it allows prediction propagation to benefit from the
2906           constant folding. Second, it means that we will detect a singleton scope even if it is
2907           referenced from a non-singleton scope that is nearer to us in the scope chain. This refactoring
2908           allows us to eliminate the function reentry watchpoint.
2909
2910         - This allows us to use a normal WatchpointSet, instead of a VariableWatchpointSet, for inferring
2911           constant values in scopes. Previously when the DFG inferred that a closure variable was
2912           constant, it wouldn't know which closure that variable was in and so it couldn't just load that
2913           value. But now we are first inferring that the function is a singleton, which means that we
2914           know exactly what scope it points to, and we can load the value from the scope. Using a
2915           WatchpointSet instead of a VariableWatchpointSet saves some memory and simplifies a bunch of
2916           code. This also means that now, the only user of VariableWatchpointSet is FunctionExecutable.
2917           I've tweaked the code of VariableWatchpointSet to reduce its power to just be what
2918           FunctionExecutable wants.
2919
2920         This also has the effect of simplifying the implementation of block scoping. Prior to this
2921         change, block scoping would have needed to have some story for the function reentry watchpoint on
2922         any nested symbol table. That's totally weird to think about; it's not really a function reentry
2923         but a scope reentry. Now we don't have to think about this. Constant inference on nested scopes
2924         will "just work": if we prove that we know the constant value of the scope then the machinery
2925         kicks in, otherwise it doesn't.
2926
2927         This is a small Octane and AsmBench speed-up. AsmBench sees 1% while Octane sees sub-1%.
2928
2929         * CMakeLists.txt:
2930         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2931         * JavaScriptCore.xcodeproj/project.pbxproj:
2932         * bytecode/BytecodeList.json:
2933         * bytecode/BytecodeUseDef.h:
2934         (JSC::computeUsesForBytecodeOffset):
2935         (JSC::computeDefsForBytecodeOffset):
2936         * bytecode/CodeBlock.cpp:
2937         (JSC::CodeBlock::dumpBytecode):
2938         (JSC::CodeBlock::CodeBlock):
2939         (JSC::CodeBlock::finalizeUnconditionally):
2940         (JSC::CodeBlock::valueProfileForBytecodeOffset):
2941         * bytecode/CodeBlock.h:
2942         (JSC::CodeBlock::valueProfileForBytecodeOffset): Deleted.
2943         * bytecode/CodeOrigin.cpp:
2944         (JSC::InlineCallFrame::calleeConstant):
2945         (JSC::InlineCallFrame::visitAggregate):
2946         * bytecode/CodeOrigin.h:
2947         (JSC::InlineCallFrame::calleeConstant): Deleted.
2948         (JSC::InlineCallFrame::visitAggregate): Deleted.
2949         * bytecode/Instruction.h:
2950         * bytecode/VariableWatchpointSet.cpp: Removed.
2951         * bytecode/VariableWatchpointSet.h: Removed.
2952         * bytecode/VariableWatchpointSetInlines.h: Removed.
2953         * bytecode/VariableWriteFireDetail.cpp: Added.
2954         (JSC::VariableWriteFireDetail::dump):
2955         (JSC::VariableWriteFireDetail::touch):
2956         * bytecode/VariableWriteFireDetail.h: Added.
2957         (JSC::VariableWriteFireDetail::VariableWriteFireDetail):
2958         * bytecode/Watchpoint.h:
2959         (JSC::WatchpointSet::stateOnJSThread):
2960         (JSC::WatchpointSet::startWatching):
2961         (JSC::WatchpointSet::fireAll):
2962         (JSC::WatchpointSet::touch):
2963         (JSC::WatchpointSet::invalidate):
2964         (JSC::InlineWatchpointSet::stateOnJSThread):
2965         (JSC::InlineWatchpointSet::state):
2966         (JSC::InlineWatchpointSet::hasBeenInvalidated):
2967         (JSC::InlineWatchpointSet::invalidate):
2968         (JSC::InlineWatchpointSet::touch):
2969         * bytecompiler/BytecodeGenerator.cpp:
2970         (JSC::BytecodeGenerator::BytecodeGenerator):
2971         * dfg/DFGAbstractInterpreterInlines.h:
2972         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2973         * dfg/DFGByteCodeParser.cpp:
2974         (JSC::DFG::ByteCodeParser::get):
2975         (JSC::DFG::ByteCodeParser::parseBlock):
2976         (JSC::DFG::ByteCodeParser::getScope): Deleted.
2977         * dfg/DFGCapabilities.cpp:
2978         (JSC::DFG::capabilityLevel):
2979         * dfg/DFGClobberize.h:
2980         (JSC::DFG::clobberize):
2981         * dfg/DFGDesiredWatchpoints.cpp:
2982         (JSC::DFG::InferredValueAdaptor::add):
2983         (JSC::DFG::DesiredWatchpoints::addLazily):
2984         (JSC::DFG::DesiredWatchpoints::reallyAdd):
2985         (JSC::DFG::DesiredWatchpoints::areStillValid):
2986         * dfg/DFGDesiredWatchpoints.h:
2987         (JSC::DFG::InferredValueAdaptor::hasBeenInvalidated):
2988         (JSC::DFG::DesiredWatchpoints::isWatched):
2989         * dfg/DFGGraph.cpp:
2990         (JSC::DFG::Graph::dump):
2991         (JSC::DFG::Graph::tryGetConstantClosureVar):
2992         * dfg/DFGNode.h:
2993         (JSC::DFG::Node::hasWatchpointSet):
2994         (JSC::DFG::Node::watchpointSet):
2995         (JSC::DFG::Node::hasVariableWatchpointSet): Deleted.
2996         (JSC::DFG::Node::variableWatchpointSet): Deleted.
2997         * dfg/DFGOperations.cpp:
2998         * dfg/DFGOperations.h:
2999         * dfg/DFGSpeculativeJIT.cpp:
3000         (JSC::DFG::SpeculativeJIT::compileNewFunction):
3001         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
3002         (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
3003         * dfg/DFGSpeculativeJIT.h:
3004         (JSC::DFG::SpeculativeJIT::callOperation):
3005         * dfg/DFGSpeculativeJIT32_64.cpp:
3006         (JSC::DFG::SpeculativeJIT::compile):
3007         * dfg/DFGSpeculativeJIT64.cpp:
3008         (JSC::DFG::SpeculativeJIT::compile):
3009         * dfg/DFGVarargsForwardingPhase.cpp:
3010         * ftl/FTLIntrinsicRepository.h:
3011         * ftl/FTLLowerDFGToLLVM.cpp:
3012         (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
3013         (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
3014         (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite):
3015         * interpreter/Interpreter.cpp:
3016         (JSC::StackFrame::friendlySourceURL):
3017         (JSC::StackFrame::friendlyFunctionName):
3018         * interpreter/Interpreter.h:
3019         (JSC::StackFrame::friendlySourceURL): Deleted.
3020         (JSC::StackFrame::friendlyFunctionName): Deleted.
3021         * jit/JIT.cpp:
3022         (JSC::JIT::emitNotifyWrite):
3023         (JSC::JIT::privateCompileMainPass):
3024         * jit/JIT.h:
3025         * jit/JITOpcodes.cpp:
3026         (JSC::JIT::emit_op_touch_entry): Deleted.
3027         * jit/JITOperations.cpp:
3028         * jit/JITOperations.h:
3029         * jit/JITPropertyAccess.cpp:
3030         (JSC::JIT::emitPutGlobalVar):
3031         (JSC::JIT::emitPutClosureVar):
3032         (JSC::JIT::emitNotifyWrite): Deleted.
3033         * jit/JITPropertyAccess32_64.cpp:
3034         (JSC::JIT::emitPutGlobalVar):
3035         (JSC::JIT::emitPutClosureVar):
3036         (JSC::JIT::emitNotifyWrite): Deleted.
3037         * llint/LLIntSlowPaths.cpp:
3038         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3039         * llint/LowLevelInterpreter.asm:
3040         * llint/LowLevelInterpreter32_64.asm:
3041         * llint/LowLevelInterpreter64.asm:
3042         * runtime/CommonSlowPaths.cpp:
3043         (JSC::SLOW_PATH_DECL): Deleted.
3044         * runtime/CommonSlowPaths.h:
3045         * runtime/Executable.cpp:
3046         (JSC::FunctionExecutable::finishCreation):
3047         (JSC::FunctionExecutable::visitChildren):
3048         * runtime/Executable.h:
3049         (JSC::FunctionExecutable::singletonFunction):
3050         * runtime/InferredValue.cpp: Added.
3051         (JSC::InferredValue::create):
3052         (JSC::InferredValue::destroy):
3053         (JSC::InferredValue::createStructure):
3054         (JSC::InferredValue::visitChildren):
3055         (JSC::InferredValue::InferredValue):
3056         (JSC::InferredValue::~InferredValue):
3057         (JSC::InferredValue::notifyWriteSlow):
3058         (JSC::InferredValue::ValueCleanup::ValueCleanup):
3059         (JSC::InferredValue::ValueCleanup::~ValueCleanup):
3060         (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
3061         * runtime/InferredValue.h: Added.
3062         (JSC::InferredValue::inferredValue):
3063         (JSC::InferredValue::state):
3064         (JSC::InferredValue::isStillValid):
3065         (JSC::InferredValue::hasBeenInvalidated):
3066         (JSC::InferredValue::add):
3067         (JSC::InferredValue::notifyWrite):
3068         (JSC::InferredValue::invalidate):
3069         * runtime/JSEnvironmentRecord.cpp:
3070         (JSC::JSEnvironmentRecord::visitChildren):
3071         * runtime/JSEnvironmentRecord.h:
3072         (JSC::JSEnvironmentRecord::isValid):
3073         (JSC::JSEnvironmentRecord::finishCreation):
3074         * runtime/JSFunction.cpp:
3075         (JSC::JSFunction::create):
3076         * runtime/JSFunction.h:
3077         (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
3078         (JSC::JSFunction::createImpl):
3079         (JSC::JSFunction::create): Deleted.
3080         * runtime/JSGlobalObject.cpp:
3081         (JSC::JSGlobalObject::addGlobalVar):
3082         (JSC::JSGlobalObject::addFunction):
3083         * runtime/JSGlobalObject.h:
3084         * runtime/JSLexicalEnvironment.cpp:
3085         (JSC::JSLexicalEnvironment::symbolTablePut):
3086         * runtime/JSScope.h:
3087         (JSC::ResolveOp::ResolveOp):
3088         * runtime/JSSegmentedVariableObject.h:
3089         (JSC::JSSegmentedVariableObject::finishCreation):
3090         * runtime/JSSymbolTableObject.h:
3091         (JSC::JSSymbolTableObject::JSSymbolTableObject):
3092         (JSC::JSSymbolTableObject::setSymbolTable):
3093         (JSC::symbolTablePut):
3094         (JSC::symbolTablePutWithAttributes):
3095         * runtime/PutPropertySlot.h:
3096         * runtime/SymbolTable.cpp:
3097         (JSC::SymbolTableEntry::prepareToWatch):
3098         (JSC::SymbolTable::SymbolTable):
3099         (JSC::SymbolTable::finishCreation):
3100         (JSC::SymbolTable::visitChildren):
3101         (JSC::SymbolTableEntry::inferredValue): Deleted.
3102         (JSC::SymbolTableEntry::notifyWriteSlow): Deleted.
3103         (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup): Deleted.
3104         (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup): Deleted.
3105         (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally): Deleted.
3106         * runtime/SymbolTable.h:
3107         (JSC::SymbolTableEntry::disableWatching):
3108         (JSC::SymbolTableEntry::watchpointSet):
3109         (JSC::SymbolTable::singletonScope):
3110         (JSC::SymbolTableEntry::notifyWrite): Deleted.
3111         * runtime/TypeProfiler.cpp:
3112         * runtime/VM.cpp:
3113         (JSC::VM::VM):
3114         * runtime/VM.h:
3115         * tests/stress/infer-uninitialized-closure-var.js: Added.
3116         (foo.f):
3117         (foo):
3118         * tests/stress/singleton-scope-then-overwrite.js: Added.
3119         (foo.f):
3120         (foo):
3121         * tests/stress/singleton-scope-then-realloc-and-overwrite.js: Added.
3122         (foo):
3123         * tests/stress/singleton-scope-then-realloc.js: Added.
3124         (foo):
3125
3126 2015-04-13  Andreas Kling  <akling@apple.com>
3127
3128         Don't segregate heap objects based on Structure immortality.
3129         <https://webkit.org/b/143638>
3130
3131         Reviewed by Darin Adler.
3132
3133         Put all objects that need a destructor call into the same MarkedBlock.
3134         This reduces memory consumption in many situations, while improving locality,
3135         since much more of the MarkedBlock space can be shared.
3136
3137         Instead of branching on the MarkedBlock type, we now check a bit in the
3138         JSCell's inline type flags (StructureIsImmortal) to see whether it's safe
3139         to access the cell's Structure during destruction or not.
3140
3141         Performance benchmarks look mostly neutral. Maybe a small regression on
3142         SunSpider's date objects.
3143
3144         On the amazon.com landing page, this saves us 50 MarkedBlocks (3200kB) along
3145         with a bunch of WeakBlocks that were hanging off of them. That's on the higher
3146         end of savings we can get from this, but still a very real improvement.
3147
3148         Most of this patch is removing the "hasImmortalStructure" constant from JSCell
3149         derived classes and passing that responsibility to the StructureIsImmortal flag.
3150         StructureFlags is made public so that it's accessible from non-member functions.
3151         I made sure to declare it everywhere and make classes final to try to make it
3152         explicit what each class is doing to its inherited flags.
3153
3154         * API/JSCallbackConstructor.h:
3155         * API/JSCallbackObject.h:
3156         * bytecode/UnlinkedCodeBlock.h:
3157         * debugger/DebuggerScope.h:
3158         * dfg/DFGSpeculativeJIT.cpp:
3159         (JSC::DFG::SpeculativeJIT::compileMakeRope):
3160         * ftl/FTLLowerDFGToLLVM.cpp:
3161         (JSC::FTL::LowerDFGToLLVM::compileMakeRope):
3162         * heap/Heap.h:
3163         (JSC::Heap::subspaceForObjectDestructor):
3164         (JSC::Heap::allocatorForObjectWithDestructor):
3165         (JSC::Heap::subspaceForObjectNormalDestructor): Deleted.
3166         (JSC::Heap::subspaceForObjectsWithImmortalStructure): Deleted.
3167         (JSC::Heap::allocatorForObjectWithNormalDestructor): Deleted.
3168         (JSC::Heap::allocatorForObjectWithImmortalStructureDestructor): Deleted.
3169         * heap/HeapInlines.h:
3170         (JSC::Heap::allocateWithDestructor):
3171         (JSC::Heap::allocateObjectOfType):
3172         (JSC::Heap::subspaceForObjectOfType):
3173         (JSC::Heap::allocatorForObjectOfType):
3174         (JSC::Heap::allocateWithNormalDestructor): Deleted.
3175         (JSC::Heap::allocateWithImmortalStructureDestructor): Deleted.
3176         * heap/MarkedAllocator.cpp:
3177         (JSC::MarkedAllocator::allocateBlock):
3178         * heap/MarkedAllocator.h:
3179         (JSC::MarkedAllocator::needsDestruction):
3180         (JSC::MarkedAllocator::MarkedAllocator):
3181         (JSC::MarkedAllocator::init):
3182         (JSC::MarkedAllocator::destructorType): Deleted.
3183         * heap/MarkedBlock.cpp:
3184         (JSC::MarkedBlock::create):
3185         (JSC::MarkedBlock::MarkedBlock):
3186         (JSC::MarkedBlock::callDestructor):
3187         (JSC::MarkedBlock::specializedSweep):
3188         (JSC::MarkedBlock::sweep):
3189         (JSC::MarkedBlock::sweepHelper):
3190         * heap/MarkedBlock.h:
3191         (JSC::MarkedBlock::needsDestruction):
3192         (JSC::MarkedBlock::destructorType): Deleted.
3193         * heap/MarkedSpace.cpp:
3194         (JSC::MarkedSpace::MarkedSpace):
3195         (JSC::MarkedSpace::resetAllocators):
3196         (JSC::MarkedSpace::forEachAllocator):
3197         (JSC::MarkedSpace::isPagedOut):
3198         (JSC::MarkedSpace::clearNewlyAllocated):
3199         * heap/MarkedSpace.h:
3200         (JSC::MarkedSpace::subspaceForObjectsWithDestructor):
3201         (JSC::MarkedSpace::destructorAllocatorFor):
3202         (JSC::MarkedSpace::allocateWithDestructor):
3203         (JSC::MarkedSpace::forEachBlock):
3204         (JSC::MarkedSpace::subspaceForObjectsWithNormalDestructor): Deleted.
3205         (JSC::MarkedSpace::subspaceForObjectsWithImmortalStructure): Deleted.
3206         (JSC::MarkedSpace::immortalStructureDestructorAllocatorFor): Deleted.
3207         (JSC::MarkedSpace::normalDestructorAllocatorFor): Deleted.
3208         (JSC::MarkedSpace::allocateWithImmortalStructureDestructor): Deleted.
3209         (JSC::MarkedSpace::allocateWithNormalDestructor): Deleted.
3210         * inspector/JSInjectedScriptHost.h:
3211         * inspector/JSInjectedScriptHostPrototype.h:
3212         * inspector/JSJavaScriptCallFrame.h:
3213         * inspector/JSJavaScriptCallFramePrototype.h:
3214         * jsc.cpp:
3215         * runtime/ArrayBufferNeuteringWatchpoint.h:
3216         * runtime/ArrayConstructor.h:
3217         * runtime/ArrayIteratorPrototype.h:
3218         * runtime/BooleanPrototype.h:
3219         * runtime/ClonedArguments.h:
3220         * runtime/CustomGetterSetter.h:
3221         * runtime/DateConstructor.h:
3222         * runtime/DatePrototype.h:
3223         * runtime/ErrorPrototype.h:
3224         * runtime/ExceptionHelpers.h:
3225         * runtime/Executable.h:
3226         * runtime/GenericArguments.h:
3227         * runtime/GetterSetter.h:
3228         * runtime/InternalFunction.h:
3229         * runtime/JSAPIValueWrapper.h:
3230         * runtime/JSArgumentsIterator.h:
3231         * runtime/JSArray.h:
3232         * runtime/JSArrayBuffer.h:
3233         * runtime/JSArrayBufferView.h:
3234         * runtime/JSBoundFunction.h:
3235         * runtime/JSCallee.h:
3236         * runtime/JSCell.h:
3237         * runtime/JSCellInlines.h:
3238         (JSC::JSCell::classInfo):
3239         * runtime/JSDataViewPrototype.h:
3240         * runtime/JSEnvironmentRecord.h:
3241         * runtime/JSFunction.h:
3242         * runtime/JSGenericTypedArrayView.h:
3243         * runtime/JSGlobalObject.h:
3244         * runtime/JSLexicalEnvironment.h:
3245         * runtime/JSNameScope.h:
3246         * runtime/JSNotAnObject.h:
3247         * runtime/JSONObject.h:
3248         * runtime/JSObject.h:
3249         (JSC::JSFinalObject::JSFinalObject):
3250         * runtime/JSPromiseConstructor.h:
3251         * runtime/JSPromiseDeferred.h:
3252         * runtime/JSPromisePrototype.h:
3253         * runtime/JSPromiseReaction.h:
3254         * runtime/JSPropertyNameEnumerator.h:
3255         * runtime/JSProxy.h:
3256         * runtime/JSScope.h:
3257         * runtime/JSString.h:
3258         * runtime/JSSymbolTableObject.h:
3259         * runtime/JSTypeInfo.h:
3260         (JSC::TypeInfo::structureIsImmortal):
3261         * runtime/MathObject.h:
3262         * runtime/NumberConstructor.h:
3263         * runtime/NumberPrototype.h:
3264         * runtime/ObjectConstructor.h:
3265         * runtime/PropertyMapHashTable.h:
3266         * runtime/RegExp.h:
3267         * runtime/RegExpConstructor.h:
3268         * runtime/RegExpObject.h:
3269         * runtime/RegExpPrototype.h:
3270         * runtime/ScopedArgumentsTable.h:
3271         * runtime/SparseArrayValueMap.h:
3272         * runtime/StrictEvalActivation.h:
3273         * runtime/StringConstructor.h:
3274         * runtime/StringIteratorPrototype.h:
3275         * runtime/StringObject.h:
3276         * runtime/StringPrototype.h:
3277         * runtime/Structure.cpp:
3278         (JSC::Structure::Structure):
3279         * runtime/Structure.h:
3280         * runtime/StructureChain.h:
3281         * runtime/StructureRareData.h:
3282         * runtime/Symbol.h:
3283         * runtime/SymbolPrototype.h:
3284         * runtime/SymbolTable.h:
3285         * runtime/WeakMapData.h:
3286
3287 2015-04-13  Mark Lam  <mark.lam@apple.com>
3288
3289         DFG inlining of op_call_varargs should keep the callee alive in case of OSR exit.
3290         https://bugs.webkit.org/show_bug.cgi?id=143407
3291
3292         Reviewed by Filip Pizlo.
3293
3294         DFG inlining of a varargs call / construct needs to keep the local
3295         containing the callee alive with a Phantom node because the LoadVarargs
3296         node may OSR exit.  After the OSR exit, the baseline JIT executes the
3297         op_call_varargs with that callee in the local.
3298
3299         Previously, because that callee local was not explicitly kept alive,
3300         the op_call_varargs case can OSR exit a DFG function and leave an
3301         undefined value in that local.  As a result, the baseline observes the
3302         side effect of an op_call_varargs on an undefined value instead of the
3303         function it expected.
3304
3305         Note: this issue does not manifest with op_construct_varargs because
3306         the inlined constructor will have an op_create_this which operates on
3307         the incoming callee value, thereby keeping it alive.
3308
3309         * dfg/DFGByteCodeParser.cpp:
3310         (JSC::DFG::ByteCodeParser::handleInlining):
3311         * tests/stress/call-varargs-with-different-arguments-length-after-warmup.js: Added.
3312         (foo):
3313         (Foo):
3314         (doTest):
3315
3316 2015-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
3317
3318         [ES6] Implement Array.prototype.values
3319         https://bugs.webkit.org/show_bug.cgi?id=143633
3320
3321         Reviewed by Darin Adler.
3322
3323         Symbol.unscopables is implemented, so we can implement Array.prototype.values
3324         without largely breaking the web. The following script passes.
3325
3326         var array = [];
3327         var values = 42;
3328         with (array) {
3329             assert(values, 42);
3330         }
3331
3332         * runtime/ArrayPrototype.cpp:
3333         * tests/stress/array-iterators-next.js:
3334         * tests/stress/map-iterators-next.js:
3335         * tests/stress/set-iterators-next.js:
3336         * tests/stress/values-unscopables.js: Added.
3337         (test):
3338
3339 2015-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
3340
3341         Run flaky conservative GC related test first before polluting stack and registers
3342         https://bugs.webkit.org/show_bug.cgi?id=143634
3343
3344         Reviewed by Ryosuke Niwa.
3345
3346         After r182653, JSC API tests fail. However, it's not related to the change.
3347         After investigating the cause of this failure, I've found that the failed test is flaky
3348         because JSC's GC is conservative. If previously allocated JSGlobalObject is accidentally alive
3349         due to conservative roots in C stack and registers, this test fails.
3350
3351         Since GC marks C stack and registers as roots conservatively,
3352         objects not referenced logically can be accidentally marked and alive.
3353         To avoid this situation as possible as we can,
3354         1. run this test first before stack is polluted,
3355         2. extract this test as a function to suppress stack height.
3356
3357         * API/tests/testapi.mm:
3358         (testWeakValue):
3359         (testObjectiveCAPIMain):
3360         (testObjectiveCAPI):
3361
3362 2015-04-11  Matt Baker  <mattbaker@apple.com>
3363
3364         Web Inspector: create content view and details sidebar for Frames timeline
3365         https://bugs.webkit.org/show_bug.cgi?id=143533
3366
3367         Reviewed by Timothy Hatcher.
3368
3369         Refactoring: RunLoop prefix changed to RenderingFrame.
3370
3371         * inspector/protocol/Timeline.json:
3372
3373 2015-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
3374
3375         [ES6] Enable Symbol in web pages
3376         https://bugs.webkit.org/show_bug.cgi?id=143375
3377
3378         Reviewed by Ryosuke Niwa.
3379
3380         Expose Symbol to web pages.
3381         Symbol was exposed, but it was hidden since it breaks Facebook comments.
3382         This is because at that time Symbol is implemented,
3383         but methods for Symbol.iterator and Object.getOwnPropertySymbols are not implemented yet
3384         and it breaks React.js and immutable.js.
3385
3386         Now methods for Symbol.iterator and Object.getOwnPropertySymbols are implemented
3387         and make sure that Facebook comment input functionality is not broken with exposed Symbol.
3388
3389         So this patch replaces runtime flags SymbolEnabled to SymbolDisabled
3390         and makes enabling symbols by default.
3391
3392         * runtime/ArrayPrototype.cpp:
3393         (JSC::ArrayPrototype::finishCreation):
3394         * runtime/CommonIdentifiers.h:
3395         * runtime/JSGlobalObject.cpp:
3396         (JSC::JSGlobalObject::init):
3397         * runtime/ObjectConstructor.cpp:
3398         (JSC::ObjectConstructor::finishCreation):
3399         * runtime/RuntimeFlags.h:
3400
3401 2015-04-10  Yusuke Suzuki  <utatane.tea@gmail.com>
3402
3403         ES6: Iterator toString names should be consistent
3404         https://bugs.webkit.org/show_bug.cgi?id=142424
3405
3406         Reviewed by Geoffrey Garen.
3407
3408         Iterator Object Names in the spec right now have spaces.
3409         In our implementation some do and some don't.
3410         This patch aligns JSC to the spec.
3411
3412         * runtime/JSArrayIterator.cpp:
3413         * runtime/JSStringIterator.cpp:
3414         * tests/stress/iterator-names.js: Added.
3415         (test):
3416         (iter):
3417         (check):
3418
3419 2015-04-10  Michael Saboff  <msaboff@apple.com>
3420
3421         REGRESSION (182567): regress/script-tests/sorting-benchmark.js fails on 32 bit dfg-eager tests
3422         https://bugs.webkit.org/show_bug.cgi?id=143582
3423
3424         Reviewed by Mark Lam.
3425
3426         For 32 bit builds, we favor spilling unboxed values.  The ASSERT at the root of this bug doesn't
3427         fire for 64 bit builds, because we spill an "Other" value as a full JS value (DataFormatJS).
3428         For 32 bit builds however, if we are able, we spill Other values as JSCell* (DataFormatCell).
3429         The fix is to add a check in fillSpeculateInt32Internal() before the ASSERT that always OSR exits
3430         if the spillFormat is DataFormatCell.  Had we spilled in DataFormatJS and the value was a JSCell*,
3431         we would still OSR exit after the speculation check.
3432
3433         * dfg/DFGFixupPhase.cpp:
3434         (JSC::DFG::FixupPhase::fixupNode): Fixed an error in a comment while debugging.
3435         * dfg/DFGSpeculativeJIT32_64.cpp:
3436         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
3437
3438 2015-04-10  Milan Crha  <mcrha@redhat.com>
3439
3440         Disable Linux-specific code in a Windows build
3441         https://bugs.webkit.org/show_bug.cgi?id=137973
3442
3443         Reviewed by Joseph Pecoraro.
3444
3445         * inspector/JSGlobalObjectInspectorController.cpp:
3446         (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
3447
3448 2015-04-10  Csaba Osztrogonác  <ossy@webkit.org>
3449
3450         [ARM] Fix calleeSaveRegisters() on non iOS platforms after r180516
3451         https://bugs.webkit.org/show_bug.cgi?id=143368
3452
3453         Reviewed by Michael Saboff.
3454
3455         * jit/RegisterSet.cpp:
3456         (JSC::RegisterSet::calleeSaveRegisters):
3457
3458 2015-04-08  Joseph Pecoraro  <pecoraro@apple.com>
3459
3460         Use jsNontrivialString in more places if the string is guaranteed to be 2 or more characters
3461         https://bugs.webkit.org/show_bug.cgi?id=143430
3462
3463         Reviewed by Darin Adler.
3464
3465         * runtime/ExceptionHelpers.cpp:
3466         (JSC::errorDescriptionForValue):
3467         * runtime/NumberPrototype.cpp:
3468         (JSC::numberProtoFuncToExponential):
3469         (JSC::numberProtoFuncToPrecision):
3470         (JSC::numberProtoFuncToString):
3471         * runtime/SymbolPrototype.cpp:
3472         (JSC::symbolProtoFuncToString):
3473
3474 2015-04-08  Filip Pizlo  <fpizlo@apple.com>
3475
3476         JSArray::sortNumeric should handle ArrayWithUndecided
3477         https://bugs.webkit.org/show_bug.cgi?id=143535
3478
3479         Reviewed by Geoffrey Garen.
3480
3481         ArrayWithUndecided is what you get if you haven't stored anything into the array yet. We need to handle it.
3482
3483         * runtime/JSArray.cpp:
3484         (JSC::JSArray::sortNumeric):
3485         * tests/stress/sort-array-with-undecided.js: Added.
3486
3487 2015-04-08  Filip Pizlo  <fpizlo@apple.com>
3488
3489         DFG::IntegerCheckCombiningPhase's wrap-around check shouldn't trigger C++ undef behavior on wrap-around
3490         https://bugs.webkit.org/show_bug.cgi?id=143532
3491
3492         Reviewed by Gavin Barraclough.
3493
3494         Oh the irony!  We were protecting an optimization that only worked if there was no wrap-around in JavaScript.
3495         But the C++ code had wrap-around, which is undef in C++.  So, if the compiler was smart enough, our compiler
3496         would think that there never was wrap-around.
3497
3498         This fixes a failure in stress/tricky-array-boiunds-checks.js when JSC is compiled with bleeding-edge clang.
3499
3500         * dfg/DFGIntegerCheckCombiningPhase.cpp:
3501         (JSC::DFG::IntegerCheckCombiningPhase::isValid):
3502
3503 2015-04-07  Michael Saboff  <msaboff@apple.com>
3504
3505         Lazily initialize LogToSystemConsole flag to reduce memory usage
3506         https://bugs.webkit.org/show_bug.cgi?id=143506
3507
3508         Reviewed by Mark Lam.
3509
3510         Only call into CF preferences code when we need to in order to reduce memory usage.
3511
3512         * inspector/JSGlobalObjectConsoleClient.cpp:
3513         (Inspector::JSGlobalObjectConsoleClient::logToSystemConsole):
3514         (Inspector::JSGlobalObjectConsoleClient::setLogToSystemConsole):
3515         (Inspector::JSGlobalObjectConsoleClient::initializeLogToSystemConsole):
3516         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
3517
3518 2015-04-07  Benjamin Poulain  <benjamin@webkit.org>
3519
3520         Get the features.json files ready for open contributions
3521         https://bugs.webkit.org/show_bug.cgi?id=143436
3522
3523         Reviewed by Darin Adler.
3524
3525         * features.json:
3526
3527 2015-04-07  Filip Pizlo  <fpizlo@apple.com>
3528
3529         Constant folding of typed array properties should be handled by AI rather than strength reduction
3530         https://bugs.webkit.org/show_bug.cgi?id=143496
3531
3532         Reviewed by Geoffrey Garen.
3533
3534         Handling constant folding in AI is better because it precludes us from having to fixpoint the CFA
3535         phase and whatever other phase did the folding in order to find all constants.
3536
3537         This also removes the TypedArrayWatchpoint node type because we can just set the watchpoint
3538         directly.
3539
3540         This also fixes a bug in FTL lowering of GetTypedArrayByteOffset. The bug was previously not
3541         found because all of the tests for it involved the property getting constant folded. I found that
3542         the codegen was bad because an earlier version of the patch broke that constant folding. This
3543         adds a new test for that node type, which makes constant folding impossible by allocating a new
3544         typed array every type. The lesson here is: if you write a test for something, run the test with
3545         full IR dumps to make sure it's actually testing the thing you want it to test.
3546
3547         * dfg/DFGAbstractInterpreterInlines.h:
3548         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3549         * dfg/DFGClobberize.h:
3550         (JSC::DFG::clobberize):
3551         * dfg/DFGConstantFoldingPhase.cpp:
3552         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3553         * dfg/DFGDoesGC.cpp:
3554         (JSC::DFG::doesGC):
3555         * dfg/DFGFixupPhase.cpp:
3556         (JSC::DFG::FixupPhase::fixupNode):
3557         * dfg/DFGGraph.cpp:
3558         (JSC::DFG::Graph::dump):
3559         (JSC::DFG::Graph::tryGetFoldableView):
3560         (JSC::DFG::Graph::tryGetFoldableViewForChild1): Deleted.
3561         * dfg/DFGGraph.h:
3562         * dfg/DFGNode.h:
3563         (JSC::DFG::Node::hasTypedArray): Deleted.
3564         (JSC::DFG::Node::typedArray): Deleted.
3565         * dfg/DFGNodeType.h:
3566         * dfg/DFGPredictionPropagationPhase.cpp:
3567         (JSC::DFG::PredictionPropagationPhase::propagate):
3568         * dfg/DFGSafeToExecute.h:
3569         (JSC::DFG::safeToExecute):
3570         * dfg/DFGSpeculativeJIT.cpp:
3571         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds):
3572         * dfg/DFGSpeculativeJIT32_64.cpp:
3573         (JSC::DFG::SpeculativeJIT::compile):
3574         * dfg/DFGSpeculativeJIT64.cpp:
3575         (JSC::DFG::SpeculativeJIT::compile):
3576         * dfg/DFGStrengthReductionPhase.cpp:
3577         (JSC::DFG::StrengthReductionPhase::handleNode):
3578         (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant): Deleted.
3579         (JSC::DFG::StrengthReductionPhase::prepareToFoldTypedArray): Deleted.
3580         * dfg/DFGWatchpointCollectionPhase.cpp:
3581         (JSC::DFG::WatchpointCollectionPhase::handle):
3582         (JSC::DFG::WatchpointCollectionPhase::addLazily):
3583         * ftl/FTLCapabilities.cpp:
3584         (JSC::FTL::canCompile):
3585         * ftl/FTLLowerDFGToLLVM.cpp:
3586         (JSC::FTL::LowerDFGToLLVM::compileNode):
3587         (JSC::FTL::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
3588         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
3589         * tests/stress/fold-typed-array-properties.js:
3590         (foo):
3591         * tests/stress/typed-array-byte-offset.js: Added.
3592         (foo):
3593
3594 2015-04-07  Matthew Mirman  <mmirman@apple.com>
3595
3596         Source and stack information should get appended only to native errors
3597         and should be added directly after construction rather than when thrown.
3598         This fixes frozen objects being unfrozen when thrown while conforming to
3599         ecma script standard and other browser behavior.
3600         rdar://problem/19927293
3601         https://bugs.webkit.org/show_bug.cgi?id=141871
3602
3603         Reviewed by Geoffrey Garen.
3604
3605         Appending stack, source, line, and column information to an object whenever that object is thrown
3606         is incorrect because it violates the ecma script standard for the behavior of throw.  Suppose for example
3607         that the object being thrown already has one of these properties or is frozen.  Adding the properties
3608         would then violate the frozen contract or overwrite those properties.  Other browsers do not do this,
3609         and doing this causes unnecessary performance hits in code with heavy use of the throw construct as
3610         a control flow construct rather than just an error reporting mechanism.
3611
3612         Because WebCore adds "native" errors which do not inherit from any JSC native error,
3613         appending the error properties as a seperate call after construction of the error is required
3614         to avoid having to manually truncate the stack and gather local source information due to
3615         the stack being extended by a nested call to construct one of the native jsc error.
3616
3617         * interpreter/Interpreter.cpp:
3618         (JSC::Interpreter::execute):
3619         * interpreter/Interpreter.h:
3620         * parser/ParserError.h:
3621         (JSC::ParserError::toErrorObject):
3622         * runtime/CommonIdentifiers.h:
3623         * runtime/Error.cpp:
3624         (JSC::createError):
3625         (JSC::createEvalError):
3626         (JSC::createRangeError):
3627         (JSC::createReferenceError):
3628         (JSC::createSyntaxError):
3629         (JSC::createTypeError):
3630         (JSC::createNotEnoughArgumentsError):
3631         (JSC::createURIError):
3632         (JSC::createOutOfMemoryError):
3633         (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
3634         (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
3635         (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame):
3636         (JSC::FindFirstCallerFrameWithCodeblockFunctor::index):
3637         (JSC::addErrorInfoAndGetBytecodeOffset):  Added.
3638         (JSC::addErrorInfo): Added special case for appending complete error info
3639         to a newly constructed error object.
3640         * runtime/Error.h:
3641         * runtime/ErrorConstructor.cpp:
3642         (JSC::Interpreter::constructWithErrorConstructor):
3643         (JSC::Interpreter::callErrorConstructor):
3644         * runtime/ErrorInstance.cpp:
3645         (JSC::appendSourceToError): Moved from VM.cpp
3646         (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
3647         (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
3648         (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame):
3649         (JSC::FindFirstCallerFrameWithCodeblockFunctor::index):
3650         (JSC::addErrorInfoAndGetBytecodeOffset):
3651         (JSC::ErrorInstance::finishCreation):
3652         * runtime/ErrorInstance.h:
3653         (JSC::ErrorInstance::create):
3654         * runtime/ErrorPrototype.cpp:
3655         (JSC::ErrorPrototype::finishCreation):
3656         * runtime/ExceptionFuzz.cpp:
3657         (JSC::doExceptionFuzzing):
3658         * runtime/ExceptionHelpers.cpp:
3659         (JSC::createError):
3660         (JSC::createInvalidFunctionApplyParameterError):
3661         (JSC::createInvalidInParameterError):
3662         (JSC::createInvalidInstanceofParameterError):
3663         (JSC::createNotAConstructorError):
3664         (JSC::createNotAFunctionError):
3665         (JSC::createNotAnObjectError):
3666         (JSC::throwOutOfMemoryError):
3667         (JSC::createStackOverflowError): Deleted.
3668         (JSC::createOutOfMemoryError): Deleted.
3669         * runtime/ExceptionHelpers.h:
3670         * runtime/JSArrayBufferConstructor.cpp:
3671         (JSC::constructArrayBuffer):
3672         * runtime/JSArrayBufferPrototype.cpp:
3673         (JSC::arrayBufferProtoFuncSlice):
3674         * runtime/JSGenericTypedArrayViewInlines.h:
3675         (JSC::JSGenericTypedArrayView<Adaptor>::create):
3676         (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
3677         * runtime/NativeErrorConstructor.cpp:
3678         (JSC::Interpreter::constructWithNativeErrorConstructor):
3679         (JSC::Interpreter::callNativeErrorConstructor):
3680         * runtime/VM.cpp:
3681         (JSC::VM::throwException):
3682         (JSC::appendSourceToError): Moved to Error.cpp
3683         (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor): Deleted.
3684         (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()): Deleted.
3685         (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame): Deleted.
3686         (JSC::FindFirstCallerFrameWithCodeblockFunctor::index): Deleted.
3687         * tests/stress/freeze_leek.js: Added.
3688
3689 2015-04-07  Joseph Pecoraro  <pecoraro@apple.com>
3690
3691         Web Inspector: ES6: Show Symbol properties on Objects
3692         https://bugs.webkit.org/show_bug.cgi?id=141279
3693
3694         Reviewed by Timothy Hatcher.
3695
3696         * inspector/protocol/Runtime.json:
3697         Give PropertyDescriptor a reference to the Symbol RemoteObject
3698         if the property is a symbol property.
3699
3700         * inspector/InjectedScriptSource.js:
3701         Enumerate symbol properties on objects.
3702
3703 2015-04-07  Filip Pizlo  <fpizlo@apple.com>
3704
3705         Make it possible to enable LLVM FastISel
3706         https://bugs.webkit.org/show_bug.cgi?id=143489
3707
3708         Reviewed by Michael Saboff.
3709
3710         The decision to enable FastISel is made by Options.h|cpp, but the LLVM library can disable it if it finds that it is built
3711         against a version of LLVM that doesn't support it. Thereafter, JSC::enableLLVMFastISel is the flag that tells the system
3712         if we should enable it.
3713
3714         * ftl/FTLCompile.cpp:
3715         (JSC::FTL::mmAllocateDataSection):
3716         * llvm/InitializeLLVM.cpp:
3717         (JSC::initializeLLVMImpl):
3718         * llvm/InitializeLLVM.h:
3719         * llvm/InitializeLLVMLinux.cpp:
3720         (JSC::getLLVMInitializerFunction):
3721         (JSC::initializeLLVMImpl): Deleted.
3722         * llvm/InitializeLLVMMac.cpp:
3723         (JSC::getLLVMInitializerFunction):
3724         (JSC::initializeLLVMImpl): Deleted.
3725         * llvm/InitializeLLVMPOSIX.cpp:
3726         (JSC::getLLVMInitializerFunctionPOSIX):
3727         (JSC::initializeLLVMPOSIX): Deleted.
3728         * llvm/InitializeLLVMPOSIX.h:
3729         * llvm/InitializeLLVMWin.cpp:
3730         (JSC::getLLVMInitializerFunction):
3731         (JSC::initializeLLVMImpl): Deleted.
3732         * llvm/LLVMAPI.cpp:
3733         * llvm/LLVMAPI.h:
3734         * llvm/library/LLVMExports.cpp:
3735         (initCommandLine):
3736         (initializeAndGetJSCLLVMAPI):
3737         * runtime/Options.cpp:
3738         (JSC::Options::initialize):
3739
3740 2015-04-06  Yusuke Suzuki  <utatane.tea@gmail.com>
3741
3742         put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
3743         https://bugs.webkit.org/show_bug.cgi?id=140426
3744
3745         Reviewed by Darin Adler.
3746
3747         In the put_by_val_direct operation, we use JSObject::putDirect.
3748         However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
3749         This patch checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.
3750
3751         * dfg/DFGOperations.cpp:
3752         (JSC::DFG::putByVal):
3753         (JSC::DFG::operationPutByValInternal):
3754         * jit/JITOperations.cpp:
3755         * llint/LLIntSlowPaths.cpp:
3756         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3757         * runtime/Identifier.h:
3758         (JSC::isIndex):
3759         (JSC::parseIndex):
3760         * tests/stress/dfg-put-by-val-direct-with-edge-numbers.js: Added.
3761         (lookupWithKey):
3762         (toStringThrowsError.toString):
3763
3764 2015-04-06  Alberto Garcia  <berto@igalia.com>
3765
3766         [GTK] Fix HPPA build
3767         https://bugs.webkit.org/show_bug.cgi?id=143453
3768
3769         Reviewed by Darin Adler.
3770
3771         Add HPPA to the list of supported CPUs.
3772
3773         * CMakeLists.txt:
3774
3775 2015-04-06  Mark Lam  <mark.lam@apple.com>
3776
3777         In the 64-bit DFG and FTL, Array::Double case for HasIndexedProperty should set its result to true when all is well.
3778         <https://webkit.org/b/143396>
3779
3780         Reviewed by Filip Pizlo.
3781
3782         The DFG was neglecting to set the result boolean.  The FTL was setting it with
3783         an inverted value.  Both of these are now resolved.
3784
3785         * dfg/DFGSpeculativeJIT64.cpp:
3786         (JSC::DFG::SpeculativeJIT::compile):
3787         * ftl/FTLLowerDFGToLLVM.cpp:
3788         (JSC::FTL::LowerDFGToLLVM::compileHasIndexedProperty):
3789         * tests/stress/for-in-array-mode.js: Added.
3790         (.):
3791         (test):
3792
3793 2015-04-06  Yusuke Suzuki  <utatane.tea@gmail.com>
3794
3795         [ES6] DFG and FTL should be aware of that StringConstructor behavior for symbols becomes different from ToString
3796         https://bugs.webkit.org/show_bug.cgi?id=143424
3797
3798         Reviewed by Geoffrey Garen.
3799
3800         In ES6, StringConstructor behavior becomes different from ToString abstract operations in the spec. (and JSValue::toString).
3801
3802         ToString(symbol) throws a type error.
3803         However, String(symbol) produces SymbolDescriptiveString(symbol).
3804
3805         So, in DFG and FTL phase, they should not inline StringConstructor to ToString.
3806
3807         Now, in the template literals patch, ToString DFG operation is planned to be used.
3808         And current ToString behavior is aligned to the spec (and JSValue::toString) and it's better.
3809         So intead of changing ToString behavior, this patch adds CallStringConstructor operation into DFG and FTL.
3810         In CallStringConstructor, all behavior in DFG analysis is the same.
3811         Only the difference from ToString is, when calling DFG operation functions, it calls
3812         operationCallStringConstructorOnCell and operationCallStringConstructor instead of
3813         operationToStringOnCell and operationToString.
3814
3815         * dfg/DFGAbstractInterpreterInlines.h:
3816         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3817         * dfg/DFGBackwardsPropagationPhase.cpp:
3818         (JSC::DFG::BackwardsPropagationPhase::propagate):
3819         * dfg/DFGByteCodeParser.cpp:
3820         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
3821         * dfg/DFGClobberize.h:
3822         (JSC::DFG::clobberize):
3823         * dfg/DFGDoesGC.cpp:
3824         (JSC::DFG::doesGC):
3825         * dfg/DFGFixupPhase.cpp:
3826         (JSC::DFG::FixupPhase::fixupNode):
3827         (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
3828         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
3829         (JSC::DFG::FixupPhase::fixupToString): Deleted.
3830         * dfg/DFGNodeType.h:
3831         * dfg/DFGOperations.cpp:
3832         * dfg/DFGOperations.h:
3833         * dfg/DFGPredictionPropagationPhase.cpp:
3834         (JSC::DFG::PredictionPropagationPhase::propagate):
3835         * dfg/DFGSafeToExecute.h:
3836         (JSC::DFG::safeToExecute):
3837         * dfg/DFGSpeculativeJIT.cpp:
3838         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
3839         (JSC::DFG::SpeculativeJIT::compileToStringOnCell): Deleted.
3840         * dfg/DFGSpeculativeJIT.h:
3841         * dfg/DFGSpeculativeJIT32_64.cpp:
3842         (JSC::DFG::SpeculativeJIT::compile):
3843         * dfg/DFGSpeculativeJIT64.cpp:
3844         (JSC::DFG::SpeculativeJIT::compile):
3845         * dfg/DFGStructureRegistrationPhase.cpp:
3846         (JSC::DFG::StructureRegistrationPhase::run):
3847         * ftl/FTLCapabilities.cpp:
3848         (JSC::FTL::canCompile):
3849         * ftl/FTLLowerDFGToLLVM.cpp:
3850         (JSC::FTL::LowerDFGToLLVM::compileNode):
3851         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
3852         (JSC::FTL::LowerDFGToLLVM::compileToString): Deleted.
3853         * runtime/StringConstructor.cpp:
3854         (JSC::stringConstructor):
3855         (JSC::callStringConstructor):
3856         * runtime/StringConstructor.h:
3857         * tests/stress/symbol-and-string-constructor.js: Added.
3858         (performString):
3859
3860 2015-04-06  Yusuke Suzuki  <utatane.tea@gmail.com>
3861
3862         Return Optional<uint32_t> from PropertyName::asIndex
3863         https://bugs.webkit.org/show_bug.cgi?id=143422
3864
3865         Reviewed by Darin Adler.
3866
3867         PropertyName::asIndex returns uint32_t and use UINT_MAX as NotAnIndex.
3868         But it's not obvious to callers.
3869
3870         This patch changes
3871         1. PropertyName::asIndex() to return Optional<uint32_t> and
3872         2. function name `asIndex()` to `parseIndex()`.
3873         It forces callers to check the value is index or not explicitly.
3874
3875         * bytecode/GetByIdStatus.cpp:
3876         (JSC::GetByIdStatus::computeFor):
3877         * bytecode/PutByIdStatus.cpp:
3878         (JSC::PutByIdStatus::computeFor):
3879         * bytecompiler/BytecodeGenerator.cpp:
3880         (JSC::BytecodeGenerator::emitDirectPutById):
3881         * jit/Repatch.cpp:
3882         (JSC::emitPutTransitionStubAndGetOldStructure):
3883         * jsc.cpp:
3884         * runtime/ArrayPrototype.cpp:
3885         (JSC::arrayProtoFuncSort):
3886         * runtime/GenericArgumentsInlines.h:
3887         (JSC::GenericArguments<Type>::getOwnPropertySlot):
3888         (JSC::GenericArguments<Type>::put):
3889         (JSC::GenericArguments<Type>::deleteProperty):
3890         (JSC::GenericArguments<Type>::defineOwnProperty):
3891         * runtime/Identifier.h:
3892         (JSC::parseIndex):
3893         (JSC::Identifier::isSymbol):
3894         * runtime/JSArray.cpp:
3895         (JSC::JSArray::defineOwnProperty):
3896         * runtime/JSCJSValue.cpp:
3897         (JSC::JSValue::putToPrimitive):
3898         * runtime/JSGenericTypedArrayViewInlines.h:
3899         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
3900         (JSC::JSGenericTypedArrayView<Adaptor>::put):