Source/JavaScriptCore/ChangeLog

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