Source/JavaScriptCore/ChangeLog

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