Source/JavaScriptCore/ChangeLog

   1 2013-04-05  Allan Sandfeld Jensen  <allan.jensen@digia.com>
   2
   3         LLint should be able to use x87 instead of SSE for floating pointer
   4
   5         https://bugs.webkit.org/show_bug.cgi?id=112239
   6
   7         Reviewed by Filip Pizlo.
   8
   9         Implements LLInt floating point operations in x87, to ensure we support
  10         x86 without SSE2.
  11
  12         X86 (except 64bit) now defaults to using x87 instructions in order to
  13         support all 32bit x86 back to i686. The implementation uses the fucomi
  14         instruction from i686 which sets the new minimum.
  15
  16         * offlineasm/x86.rb:
  17
  18 2013-04-04  Christophe Dumez  <ch.dumez@sisa.samsung.com>
  19
  20         Unreviewed EFL build fix.
  21
  22         We had undefined reference to `JSC::CodeOrigin::maximumBytecodeIndex'.
  23
  24         * bytecode/CodeBlock.cpp:
  25         (JSC::CodeBlock::findClosureCallForReturnPC):
  26         (JSC::CodeBlock::bytecodeOffset):
  27
  28 2013-04-04  Geoffrey Garen  <ggaren@apple.com>
  29
  30         Stop pretending that statements return a value
  31         https://bugs.webkit.org/show_bug.cgi?id=113969
  32
  33         Reviewed by Oliver Hunt.
  34
  35         Expressions have an intrinsic value, which they return to their parent
  36         in the AST.
  37
  38         Statements just execute for effect in sequence.
  39
  40         This patch moves emitBytecode into the ExpressionNode and StatementNode
  41         subclasses, and changes the SatementNode subclass to return void. This
  42         eliminates some cruft where we used to return 0, or try to save a bogus
  43         register and return it, as if a statement had a consuming parent in the
  44         AST.
  45
  46         * bytecompiler/BytecodeGenerator.h:
  47         (JSC::BytecodeGenerator::emitNode):
  48         (BytecodeGenerator):
  49         (JSC::BytecodeGenerator::emitNodeInConditionContext):
  50         * bytecompiler/NodesCodegen.cpp:
  51         (JSC::ConstStatementNode::emitBytecode):
  52         (JSC::BlockNode::emitBytecode):
  53         (JSC::EmptyStatementNode::emitBytecode):
  54         (JSC::DebuggerStatementNode::emitBytecode):
  55         (JSC::ExprStatementNode::emitBytecode):
  56         (JSC::VarStatementNode::emitBytecode):
  57         (JSC::IfNode::emitBytecode):
  58         (JSC::IfElseNode::emitBytecode):
  59         (JSC::DoWhileNode::emitBytecode):
  60         (JSC::WhileNode::emitBytecode):
  61         (JSC::ForNode::emitBytecode):
  62         (JSC::ForInNode::emitBytecode):
  63         (JSC::ContinueNode::emitBytecode):
  64         (JSC::BreakNode::emitBytecode):
  65         (JSC::ReturnNode::emitBytecode):
  66         (JSC::WithNode::emitBytecode):
  67         (JSC::CaseClauseNode::emitBytecode):
  68         (JSC::CaseBlockNode::emitBytecodeForBlock):
  69         (JSC::SwitchNode::emitBytecode):
  70         (JSC::LabelNode::emitBytecode):
  71         (JSC::ThrowNode::emitBytecode):
  72         (JSC::TryNode::emitBytecode):
  73         (JSC::ScopeNode::emitStatementsBytecode):
  74         (JSC::ProgramNode::emitBytecode):
  75         (JSC::EvalNode::emitBytecode):
  76         (JSC::FunctionBodyNode::emitBytecode):
  77         (JSC::FuncDeclNode::emitBytecode):
  78         * parser/NodeConstructors.h:
  79         (JSC::PropertyListNode::PropertyListNode):
  80         (JSC::ArgumentListNode::ArgumentListNode):
  81         * parser/Nodes.h:
  82         (Node):
  83         (ExpressionNode):
  84         (StatementNode):
  85         (ConstStatementNode):
  86         (BlockNode):
  87         (EmptyStatementNode):
  88         (DebuggerStatementNode):
  89         (ExprStatementNode):
  90         (VarStatementNode):
  91         (IfNode):
  92         (IfElseNode):
  93         (DoWhileNode):
  94         (WhileNode):
  95         (ForNode):
  96         (ForInNode):
  97         (ContinueNode):
  98         (BreakNode):
  99         (ReturnNode):
 100         (WithNode):
 101         (LabelNode):
 102         (ThrowNode):
 103         (TryNode):
 104         (ProgramNode):
 105         (EvalNode):
 106         (FunctionBodyNode):
 107         (FuncDeclNode):
 108         (CaseBlockNode):
 109         (SwitchNode):
 110
 111 2013-04-04  Oliver Hunt  <oliver@apple.com>
 112
 113         Exception stack unwinding doesn't handle inline callframes correctly
 114         https://bugs.webkit.org/show_bug.cgi?id=113952
 115
 116         Reviewed by Geoffrey Garen.
 117
 118         The basic problem here is that the exception stack unwinding was
 119         attempting to be "clever" and avoid doing a correct stack walk
 120         as it "knew" inline callframes couldn't have exception handlers.
 121
 122         This used to be safe as the exception handling machinery was
 123         designed to fail gently and just claim that no handler existed.
 124         This was "safe" and even "correct" inasmuch as we currently
 125         don't run any code with exception handlers through the dfg.
 126
 127         This patch fixes the logic by simply making everything uniformly
 128         use the safe stack walking machinery, and making the correct
 129         boundary checks occur everywhere that they should.
 130
 131         * bytecode/CodeBlock.cpp:
 132         (JSC::CodeBlock::findClosureCallForReturnPC):
 133         (JSC::CodeBlock::bytecodeOffset):
 134         * interpreter/Interpreter.cpp:
 135         (JSC):
 136         (JSC::Interpreter::dumpRegisters):
 137         (JSC::Interpreter::unwindCallFrame):
 138         (JSC::getCallerInfo):
 139         (JSC::Interpreter::getStackTrace):
 140         (JSC::Interpreter::retrieveCallerFromVMCode):
 141
 142 2013-04-04  Geoffrey Garen  <ggaren@apple.com>
 143
 144         Removed a defunct comment
 145         https://bugs.webkit.org/show_bug.cgi?id=113948
 146
 147         Reviewed by Oliver Hunt.
 148
 149         This is also a convenient way to test the EWS.
 150
 151         * bytecompiler/BytecodeGenerator.cpp:
 152         (JSC):
 153
 154 2013-04-04  Martin Robinson  <mrobinson@igalia.com>
 155
 156         [GTK] Remove the gyp build
 157         https://bugs.webkit.org/show_bug.cgi?id=113942
 158
 159         Reviewed by Gustavo Noronha Silva.
 160
 161         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Removed.
 162         * JavaScriptCore.gyp/redirect-stdout.sh: Removed.
 163
 164 2013-04-04  Geoffrey Garen  <ggaren@apple.com>
 165
 166         Simplified bytecode generation by merging prefix and postfix nodes
 167         https://bugs.webkit.org/show_bug.cgi?id=113925
 168
 169         Reviewed by Filip Pizlo.
 170
 171         PostfixNode now inherits from PrefixNode, so when we detect that we're
 172         in a context where postifx and prefix are equivalent, PostFixNode can
 173         just call through to PrefixNode codegen, instead of duplicating the
 174         logic.
 175
 176         * bytecompiler/NodesCodegen.cpp:
 177         (JSC::PostfixNode::emitResolve):
 178         (JSC::PostfixNode::emitBracket):
 179         (JSC::PostfixNode::emitDot):
 180         * parser/NodeConstructors.h:
 181         (JSC::PostfixNode::PostfixNode):
 182         * parser/Nodes.h:
 183         (JSC):
 184         (PrefixNode):
 185         (PostfixNode):
 186
 187 2013-04-04  Andras Becsi  <andras.becsi@digia.com>
 188
 189         Fix the build with GCC 4.8
 190         https://bugs.webkit.org/show_bug.cgi?id=113147
 191
 192         Reviewed by Allan Sandfeld Jensen.
 193
 194         Initialize JSObject* exception to suppress warnings that make
 195         the build fail because of -Werror=maybe-uninitialized.
 196
 197         * runtime/Executable.cpp:
 198         (JSC::FunctionExecutable::compileForCallInternal):
 199         (JSC::FunctionExecutable::compileForConstructInternal):
 200
 201 2013-04-02  Mark Hahnenberg  <mhahnenberg@apple.com>
 202
 203         get_by_pname can become confused when iterating over objects with static properties
 204         https://bugs.webkit.org/show_bug.cgi?id=113831
 205
 206         Reviewed by Geoffrey Garen.
 207
 208         get_by_pname doesn't take static properties into account when using a JSPropertyNameIterator to directly
 209         access an object's backing store. One way to fix this is to not cache any properties when iterating over
 210         objects with static properties. This patch fixes the bug that was originally reported on swisscom.ch.
 211
 212         * runtime/JSObject.cpp:
 213         (JSC::JSObject::getOwnNonIndexPropertyNames):
 214         * runtime/JSPropertyNameIterator.cpp:
 215         (JSC::JSPropertyNameIterator::create):
 216         * runtime/PropertyNameArray.h:
 217         (JSC::PropertyNameArray::PropertyNameArray):
 218         (JSC::PropertyNameArray::numCacheableSlots):
 219         (JSC::PropertyNameArray::setNumCacheableSlots):
 220         (PropertyNameArray):
 221
 222 2013-04-02  Geoffrey Garen  <ggaren@apple.com>
 223
 224         DFG should compile a little sooner
 225         https://bugs.webkit.org/show_bug.cgi?id=113835
 226
 227         Unreviewed.
 228
 229         Rolled out r147511 because it was based on incorrect performance
 230         measurement.
 231
 232         * bytecode/CodeBlock.cpp:
 233         (JSC::CodeBlock::optimizationThresholdScalingFactor):
 234
 235 2013-04-02  Geoffrey Garen  <ggaren@apple.com>
 236
 237         DFG should compile a little sooner
 238         https://bugs.webkit.org/show_bug.cgi?id=113835
 239
 240         Reviewed by Michael Saboff.
 241
 242         2% speedup on SunSpider.
 243
 244         2% speedup on JSRegress.
 245
 246         Neutral on Octane, v8, and Kraken.
 247
 248         The worst-hit single sub-test is kraken-stanford-crypto-ccm.js, which gets
 249         18% slower. Since Kraken is neutral overall in its preferred mean, I
 250         think that's OK for now.
 251
 252         (Our array indexing speculation fails pathologically on
 253         kraken-stanford-crypto-ccm.js. Compiling sooner is a regression because
 254         it triggers those failures sooner. I'm going to file some follow-up bugs
 255         explaining how to fix our speculations on this sub-test, at which point
 256         compiling earlier should become a slight speedup on Kraken overall.)
 257
 258         * bytecode/CodeBlock.cpp:
 259         (JSC::CodeBlock::optimizationThresholdScalingFactor): I experimented
 260         with a few different options, including reducing the coefficient 'a'.
 261         A simple linear reduction on instruction count worked best.
 262
 263 2013-04-01  Benjamin Poulain  <benjamin@webkit.org>
 264
 265         Use Vector::reserveInitialCapacity and Vector::uncheckedAppend for JSC's APIs
 266         https://bugs.webkit.org/show_bug.cgi?id=113651
 267
 268         Reviewed by Andreas Kling.
 269
 270         This removes a bunch of branches on initialization and when
 271         filling the vector.
 272
 273         * API/JSCallbackConstructor.cpp:
 274         (JSC::constructJSCallback):
 275         * API/JSCallbackFunction.cpp:
 276         (JSC::JSCallbackFunction::call):
 277         * API/JSCallbackObjectFunctions.h:
 278         (JSC::::construct):
 279         (JSC::::call):
 280         * API/JSObjectRef.cpp:
 281         (JSObjectCopyPropertyNames):
 282
 283 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
 284
 285         Fixing borked VS 2010 project file
 286
 287         Unreviewed bot greening.
 288
 289         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
 290         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
 291
 292 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
 293
 294         One more Windows build fix
 295
 296         Unreviewed.
 297
 298         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
 299
 300 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
 301
 302         More build fallout fixes.
 303
 304         Unreviewed build fix.
 305
 306         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def: Add new export symbols.
 307         * heap/SuperRegion.cpp: Windows didn't like "LLU".
 308
 309 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
 310
 311         r147324 broke the world
 312         https://bugs.webkit.org/show_bug.cgi?id=113704
 313
 314         Unreviewed build fix.
 315
 316         Remove a bunch of unused variables and use the correctly sized types for 32-bit platforms.
 317
 318         * heap/BlockAllocator.cpp:
 319         (JSC::BlockAllocator::BlockAllocator):
 320         * heap/BlockAllocator.h:
 321         (BlockAllocator):
 322         * heap/Heap.cpp:
 323         (JSC::Heap::Heap):
 324         * heap/SuperRegion.cpp:
 325         (JSC::SuperRegion::SuperRegion):
 326         * heap/SuperRegion.h:
 327         (SuperRegion):
 328
 329 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
 330
 331         32-bit Windows build fix
 332
 333         Unreviewed build fix.
 334
 335         * heap/SuperRegion.cpp:
 336         * heap/SuperRegion.h: Use uint64_t instead of size_t.
 337         (SuperRegion):
 338
 339 2013-04-01  Mark Hahnenberg  <mhahnenberg@apple.com>
 340
 341         EFL build fix
 342
 343         Unreviewed build fix.
 344
 345         * CMakeLists.txt:
 346
 347 2013-03-31  Mark Hahnenberg  <mhahnenberg@apple.com>
 348
 349         Regions should be allocated from the same contiguous segment of virtual memory
 350         https://bugs.webkit.org/show_bug.cgi?id=113662
 351
 352         Reviewed by Filip Pizlo.
 353
 354         Instead of letting the OS spread our Regions all over the place, we should allocate them all within
 355         some range of each other. This change will open the door to some other optimizations, e.g. doing simple
 356         range checks for our write barriers and compressing JSCell pointers to 32-bits.
 357
 358         Added new SuperRegion class that encapsulates allocating Regions from a contiguous reserved chunk of
 359         virtual address space. It functions very similarly to the FixedVMPoolExecutableAllocator class used by the JIT.
 360
 361         Also added two new subclasses of Region, NormalRegion and ExcessRegion.
 362
 363         NormalRegion is the type of Region that is normally allocated when there is available space remaining
 364         in the SuperRegion. If we ever run out of space in the SuperRegion, we fall back to allocating
 365         ExcessRegions, which are identical to how Regions have behaved up until now, i.e. they contain a
 366         PageAllocationAligned.
 367
 368         We only use the SuperRegion (and NormalRegions) on 64-bit systems, since it doesn't make sense to reserve the
 369         entire 4 GB address space on 32-bit systems just for the JS heap.
 370
 371         * GNUmakefile.list.am:
 372         * JavaScriptCore.gypi:
 373         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
 374         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
 375         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
 376         * JavaScriptCore.xcodeproj/project.pbxproj:
 377         * Target.pri:
 378         * heap/BlockAllocator.cpp:
 379         (JSC::BlockAllocator::BlockAllocator):
 380         * heap/BlockAllocator.h:
 381         (JSC):
 382         (BlockAllocator):
 383         (JSC::BlockAllocator::allocate):
 384         (JSC::BlockAllocator::allocateCustomSize):
 385         (JSC::BlockAllocator::deallocateCustomSize):
 386         * heap/Heap.cpp:
 387         (JSC::Heap::Heap):
 388         (JSC):
 389         (JSC::Heap::didExceedFixedHeapSizeLimit):
 390         * heap/Heap.h:
 391         (Heap):
 392         * heap/MarkedBlock.cpp:
 393         (JSC::MarkedBlock::create):
 394         * heap/Region.h:
 395         (Region):
 396         (JSC):
 397         (NormalRegion):
 398         (JSC::NormalRegion::base):
 399         (JSC::NormalRegion::size):
 400         (ExcessRegion):
 401         (JSC::ExcessRegion::base):
 402         (JSC::ExcessRegion::size):
 403         (JSC::NormalRegion::NormalRegion):
 404         (JSC::NormalRegion::tryCreate):
 405         (JSC::NormalRegion::tryCreateCustomSize):
 406         (JSC::NormalRegion::reset):
 407         (JSC::ExcessRegion::ExcessRegion):
 408         (JSC::ExcessRegion::~ExcessRegion):
 409         (JSC::ExcessRegion::create):
 410         (JSC::ExcessRegion::createCustomSize):
 411         (JSC::ExcessRegion::reset):
 412         (JSC::Region::Region):
 413         (JSC::Region::initializeBlockList):
 414         (JSC::Region::create):
 415         (JSC::Region::createCustomSize):
 416         (JSC::Region::~Region):
 417         (JSC::Region::destroy):
 418         (JSC::Region::reset):
 419         (JSC::Region::deallocate):
 420         (JSC::Region::base):
 421         (JSC::Region::size):
 422         * heap/SuperRegion.cpp: Added.
 423         (JSC):
 424         (JSC::SuperRegion::SuperRegion):
 425         (JSC::SuperRegion::getAlignedBase):
 426         (JSC::SuperRegion::allocateNewSpace):
 427         (JSC::SuperRegion::notifyNeedPage):
 428         (JSC::SuperRegion::notifyPageIsFree):
 429         * heap/SuperRegion.h: Added.
 430         (JSC):
 431         (SuperRegion):
 432
 433 2013-04-01  Benjamin Poulain  <benjamin@webkit.org>
 434
 435         Remove an unused variable from the ARMv7 Assembler
 436         https://bugs.webkit.org/show_bug.cgi?id=113653
 437
 438         Reviewed by Andreas Kling.
 439
 440         * assembler/ARMv7Assembler.h:
 441         (ARMv7Assembler):
 442
 443 2013-03-31  Adam Barth  <abarth@webkit.org>
 444
 445         [Chromium] Yarr should build using a separate GYP file from JavaScriptCore
 446         https://bugs.webkit.org/show_bug.cgi?id=113652
 447
 448         Reviewed by Nico Weber.
 449
 450         This patch moves JavaScriptCore.gyp to yarr.gyp because Chromium only
 451         uses this GYP file to build yarr.
 452
 453         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp:
 454         * JavaScriptCore.gypi:
 455         * yarr/yarr.gyp: Renamed from Source/JavaScriptCore/JavaScriptCore.gyp/JavaScriptCore.gyp.
 456
 457 2013-03-31  Filip Pizlo  <fpizlo@apple.com>
 458
 459         Unreviewed, fix a comment. While thinking about TBAA for array accesses,
 460         I realized that we have to be super careful about aliasing of typed arrays.
 461
 462         * dfg/DFGCSEPhase.cpp:
 463         (JSC::DFG::CSEPhase::getByValLoadElimination):
 464
 465 2013-03-30  Mark Hahnenberg  <mhahnenberg@apple.com>
 466
 467         Move Region into its own header
 468         https://bugs.webkit.org/show_bug.cgi?id=113617
 469
 470         Reviewed by Geoffrey Garen.
 471
 472         BlockAllocator.h is getting a little crowded. We should move the Region class into its own
 473         header, since it's pretty independent from the BlockAllocator.
 474
 475         * GNUmakefile.list.am:
 476         * JavaScriptCore.gypi:
 477         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
 478         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
 479         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
 480         * JavaScriptCore.xcodeproj/project.pbxproj:
 481         * heap/BlockAllocator.h:
 482         (JSC):
 483         * heap/Region.h: Added.
 484         (JSC):
 485         (DeadBlock):
 486         (JSC::DeadBlock::DeadBlock):
 487         (Region):
 488         (JSC::Region::blockSize):
 489         (JSC::Region::isFull):
 490         (JSC::Region::isEmpty):
 491         (JSC::Region::isCustomSize):
 492         (JSC::Region::create):
 493         (JSC::Region::createCustomSize):
 494         (JSC::Region::Region):
 495         (JSC::Region::~Region):
 496         (JSC::Region::reset):
 497         (JSC::Region::allocate):
 498         (JSC::Region::deallocate):
 499
 500 2013-03-29  Mark Hahnenberg  <mhahnenberg@apple.com>
 501
 502         Objective-C API: Remove -[JSManagedValue managedValueWithValue:owner:]
 503         https://bugs.webkit.org/show_bug.cgi?id=113602
 504
 505         Reviewed by Geoffrey Garen.
 506
 507         Since we put the primary way of keeping track of external object graphs (i.e. "managed" references)
 508         in JSVirtualMachine, there is some overlap in the functionality of that interface and JSManagedValue.
 509         Specifically, we no longer need the methods that include an owner, since ownership is now tracked
 510         by JSVirtualMachine. These JSManagedValues will become weak pointers unless they are used
 511         with [JSVirtualMachine addManagedReference:withOwner:], in which case their lifetime is tied to that
 512         of their owner.
 513
 514         * API/JSManagedValue.h:
 515         * API/JSManagedValue.mm:
 516         (-[JSManagedValue init]):
 517         (-[JSManagedValue initWithValue:]):
 518         (JSManagedValueHandleOwner::isReachableFromOpaqueRoots):
 519         * API/JSVirtualMachine.mm:
 520         (getInternalObjcObject):
 521         * API/tests/testapi.mm:
 522         (-[TextXYZ setOnclick:]):
 523         (-[TextXYZ dealloc]):
 524
 525 2013-03-29  Geoffrey Garen  <ggaren@apple.com>
 526
 527         Simplified bytecode generation by unforking "condition context" codegen
 528         https://bugs.webkit.org/show_bug.cgi?id=113554
 529
 530         Reviewed by Mark Hahnenberg.
 531
 532         Now, a node that establishes a condition context can always ask its child
 533         nodes to generate into that context.
 534
 535         This has a few advantages:
 536
 537         (*) Removes a bunch of code;
 538
 539         (*) Optimizes a few missed cases like "if (!(x < 2))", "if (!!x)", and
 540         "if (!x || !y)";
 541
 542         (*) Paves the way to removing more opcodes.
 543
 544         * bytecode/Opcode.h:
 545         (JSC): Separated out the branching opcodes for clarity.
 546         * bytecompiler/NodesCodegen.cpp:
 547         (JSC::ExpressionNode::emitBytecodeInConditionContext): All expressions
 548         can be emitted in a condition context now -- the default behavior is
 549         to branch based on the expression's value.
 550
 551         (JSC::LogicalNotNode::emitBytecodeInConditionContext):
 552         (JSC::LogicalOpNode::emitBytecodeInConditionContext):
 553         (JSC::ConditionalNode::emitBytecode):
 554         (JSC::IfNode::emitBytecode):
 555         (JSC::IfElseNode::emitBytecode):
 556         (JSC::DoWhileNode::emitBytecode):
 557         (JSC::WhileNode::emitBytecode):
 558         (JSC::ForNode::emitBytecode):
 559         * parser/Nodes.h:
 560         (JSC::ExpressionNode::isSubtract):
 561         (ExpressionNode):
 562         (LogicalNotNode):
 563         (LogicalOpNode): Removed lots of code for handling expressions
 564         that couldn't generate into a condition context because all expressions
 565         can now.
 566
 567 2013-03-28  Geoffrey Garen  <ggaren@apple.com>
 568
 569         Simplified the bytecode by removing op_loop and op_loop_if_*
 570         https://bugs.webkit.org/show_bug.cgi?id=113548
 571
 572         Reviewed by Filip Pizlo.
 573
 574         Regular jumps will suffice.
 575
 576         These opcodes are identical to branches, except they also do timeout
 577         checking. That style of timeout checking has been broken for a long
 578         time, and when we add back timeout checking, it won't use these opcodes.
 579
 580         * JavaScriptCore.order:
 581         * bytecode/CodeBlock.cpp:
 582         (JSC::CodeBlock::dumpBytecode):
 583         * bytecode/Opcode.h:
 584         (JSC):
 585         (JSC::padOpcodeName):
 586         * bytecode/PreciseJumpTargets.cpp:
 587         (JSC::computePreciseJumpTargets):
 588         * bytecompiler/BytecodeGenerator.cpp:
 589         (JSC::BytecodeGenerator::emitJump):
 590         (JSC::BytecodeGenerator::emitJumpIfTrue):
 591         (JSC::BytecodeGenerator::emitJumpIfFalse):
 592         * dfg/DFGByteCodeParser.cpp:
 593         (JSC::DFG::ByteCodeParser::parseBlock):
 594         * dfg/DFGCapabilities.h:
 595         (JSC::DFG::canCompileOpcode):
 596         * jit/JIT.cpp:
 597         (JSC::JIT::privateCompileMainPass):
 598         (JSC::JIT::privateCompileSlowCases):
 599         * jit/JIT.h:
 600         (JIT):
 601         (JSC):
 602         * llint/LowLevelInterpreter.asm:
 603         * llint/LowLevelInterpreter32_64.asm:
 604         * llint/LowLevelInterpreter64.asm:
 605
 606 2013-03-28  Geoffrey Garen  <ggaren@apple.com>
 607
 608         Simplified the bytecode by removing op_jmp_scopes
 609         https://bugs.webkit.org/show_bug.cgi?id=113545
 610
 611         Reviewed by Filip Pizlo.
 612
 613         We already have op_pop_scope and op_jmp, so we don't need op_jmp_scopes.
 614         Using op_jmp_scopes was also adding a "jump to self" to codegen for
 615         return statements, which was pretty silly.
 616
 617         * JavaScriptCore.order:
 618         * bytecode/CodeBlock.cpp:
 619         (JSC::CodeBlock::dumpBytecode):
 620         * bytecode/Opcode.h:
 621         (JSC::padOpcodeName):
 622         * bytecode/PreciseJumpTargets.cpp:
 623         (JSC::computePreciseJumpTargets):
 624         * bytecompiler/BytecodeGenerator.cpp:
 625         (JSC::BytecodeGenerator::emitComplexPopScopes):
 626         (JSC::BytecodeGenerator::emitPopScopes):
 627         * bytecompiler/BytecodeGenerator.h:
 628         (BytecodeGenerator):
 629         * bytecompiler/NodesCodegen.cpp:
 630         (JSC::ContinueNode::emitBytecode):
 631         (JSC::BreakNode::emitBytecode):
 632         (JSC::ReturnNode::emitBytecode):
 633         * jit/JIT.cpp:
 634         (JSC::JIT::privateCompileMainPass):
 635         * jit/JIT.h:
 636         * jit/JITOpcodes.cpp:
 637         * jit/JITOpcodes32_64.cpp:
 638         * jit/JITStubs.cpp:
 639         * jit/JITStubs.h:
 640         * llint/LLIntSlowPaths.cpp:
 641         * llint/LLIntSlowPaths.h:
 642         * llint/LowLevelInterpreter.asm:
 643
 644 2013-03-28  Mark Hahnenberg  <mhahnenberg@apple.com>
 645
 646         Safari hangs during test262 run in CodeCache::pruneSlowCase
 647         https://bugs.webkit.org/show_bug.cgi?id=113469
 648
 649         Reviewed by Geoffrey Garen.
 650
 651         We can end up hanging for quite some time if we add a lot of small keys to the CodeCache.
 652         By the time we get around to pruning the cache, we have a potentially tens or hundreds of
 653         thousands of small entries, which can cause a noticeable hang when pruning them.
 654
 655         To fix this issue we added a hard cap to the number of entries in the cache because we
 656         could potentially have to remove every element in the map.
 657
 658         * runtime/CodeCache.cpp:
 659         (JSC::CodeCacheMap::pruneSlowCase): We need to prune until we're both under the hard cap and the
 660         capacity in bytes.
 661         * runtime/CodeCache.h:
 662         (CodeCacheMap):
 663         (JSC::CodeCacheMap::numberOfEntries): Convenience accessor function to the number of entries in
 664         the map that does the cast to size_t of m_map.size() for us.
 665         (JSC::CodeCacheMap::canPruneQuickly): Checks that the total number is under the hard cap. We put this
 666         check inside a function to more accurately describe why we're doing the check and to abstract out
 667         the actual calculation in case we want to coalesce calls to pruneSlowCase in the future.
 668         (JSC::CodeCacheMap::prune): Check the number of entries against our hard cap. If it's greater than
 669         the cap then we need to drop down to pruneSlowCase.
 670
 671 2013-03-28  Zan Dobersek  <zdobersek@igalia.com>
 672
 673         Unreviewed build fix for the EFL and GTK ports.
 674
 675         * runtime/CodeCache.cpp:
 676         (JSC::CodeCacheMap::pruneSlowCase): Pass a 0 casted to the int64_t type instead of 0LL
 677         to the std::max call so the arguments' types match.
 678
 679 2013-03-27  Geoffrey Garen  <ggaren@apple.com>
 680
 681         Unreviewed build fix: Removed a dead field.
 682
 683         Pointed out by Mark Lam.
 684
 685         * dfg/DFGByteCodeParser.cpp:
 686         (JSC::DFG::ByteCodeParser::ByteCodeParser):
 687         (ByteCodeParser):
 688
 689 2013-03-27  Geoffrey Garen  <ggaren@apple.com>
 690
 691         Unreviewed build fix: Removed a dead field.
 692
 693         * dfg/DFGByteCodeParser.cpp:
 694         (JSC::DFG::ByteCodeParser::ByteCodeParser):
 695         (ByteCodeParser):
 696
 697 2013-03-27  Geoffrey Garen  <ggaren@apple.com>
 698
 699         Removed some dead code in the DFG bytecode parser
 700         https://bugs.webkit.org/show_bug.cgi?id=113472
 701
 702         Reviewed by Sam Weinig.
 703
 704         Now that Phi creation and liveness analysis are separate passes, we can
 705         remove the vestiges of code that used to do that in the bytecode
 706         parser.
 707
 708         * dfg/DFGByteCodeParser.cpp:
 709         (ByteCodeParser):
 710         (JSC::DFG::ByteCodeParser::addToGraph):
 711         (JSC::DFG::ByteCodeParser::parse):
 712
 713 2013-03-27  Filip Pizlo  <fpizlo@apple.com>
 714
 715         JIT and DFG should NaN-check loads from Float32 arrays
 716         https://bugs.webkit.org/show_bug.cgi?id=113462
 717         <rdar://problem/13490804>
 718
 719         Reviewed by Mark Hahnenberg.
 720
 721         * dfg/DFGSpeculativeJIT.cpp:
 722         (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
 723         * jit/JITPropertyAccess.cpp:
 724         (JSC::JIT::emitFloatTypedArrayGetByVal):
 725
 726 2013-03-27  Mark Hahnenberg  <mhahnenberg@apple.com>
 727
 728         CodeCache::m_capacity can becoming negative, producing undefined results in pruneSlowCase
 729         https://bugs.webkit.org/show_bug.cgi?id=113453
 730
 731         Reviewed by Geoffrey Garen.
 732
 733         * runtime/CodeCache.cpp:
 734         (JSC::CodeCacheMap::pruneSlowCase): We make sure that m_minCapacity doesn't drop below zero now.
 735         This prevents m_capacity from doing the same.
 736
 737 2013-03-27  Filip Pizlo  <fpizlo@apple.com>
 738
 739         DFG should use CheckStructure for typed array checks whenever possible
 740         https://bugs.webkit.org/show_bug.cgi?id=113374
 741
 742         Reviewed by Geoffrey Garen.
 743
 744         We used to do the right thing, but it appears that this regressed at some point. Since the
 745         FixupPhase now has the ability to outright remove spurious CheckStructures on array
 746         operations, it is profitable for the ByteCodeParser to insert CheckStructures whenver there
 747         is a chance that it might be profitable, and when the profiling tells us what structure to
 748         check.
 749
 750         Also added some code for doing ArrayProfile debugging.
 751
 752         This is a slightly speed-up. Maybe 3% on Mandreel.
 753
 754         * bytecode/ArrayProfile.cpp:
 755         (JSC::ArrayProfile::computeUpdatedPrediction):
 756         * dfg/DFGArrayMode.h:
 757         (JSC::DFG::ArrayMode::benefitsFromStructureCheck):
 758
 759 2013-03-27  Zeno Albisser  <zeno@webkit.org>
 760
 761         [Qt] Remove Qt specific WorkQueueItem definitions.
 762         https://bugs.webkit.org/show_bug.cgi?id=112891
 763
 764         This patch is preparation work for removing
 765         WorkQueue related code from TestRunnerQt and
 766         replacing it with generic TestRunner code.
 767
 768         Reviewed by Benjamin Poulain.
 769
 770         * API/JSStringRefQt.cpp:
 771         (JSStringCreateWithQString):
 772             Adding a convenience function to create a
 773             JSStringRef from a QString.
 774         * API/JSStringRefQt.h:
 775
 776 2013-03-26  Filip Pizlo  <fpizlo@apple.com>
 777
 778         REGRESSION: Sometimes, operations on proven strings ignore changes to the string prototype
 779         https://bugs.webkit.org/show_bug.cgi?id=113353
 780         <rdar://problem/13510778>
 781
 782         Reviewed by Mark Hahnenberg and Geoffrey Garen.
 783
 784         ToString should call speculateStringObject() even if you know that it's a string object, since
 785         it calls it to also get the watchpoint. Note that even with this change, if you do
 786         Phantom(Check:StringObject:@a), it might get eliminated just because we proved that @a is a
 787         string object (thereby eliminating the prototype watchpoint); that's fine since ToString is
 788         MustGenerate and never decays to Phantom.
 789
 790         * dfg/DFGSpeculativeJIT.cpp:
 791         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
 792         (JSC::DFG::SpeculativeJIT::speculateStringObject):
 793         (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
 794         * dfg/DFGSpeculativeJIT.h:
 795         (SpeculativeJIT):
 796         (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
 797
 798 2013-03-26  Mark Hahnenberg  <mhahnenberg@apple.com>
 799
 800         REGRESSION(r144131): It made fast/js/regress/string-repeat-arith.html assert on 32 bit
 801         https://bugs.webkit.org/show_bug.cgi?id=112106
 802
 803         Rubber stamped by Filip Pizlo.
 804
 805         * dfg/DFGSpeculativeJIT.cpp:
 806         (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): Get rid of the case for constants because
 807         we would have done constant folding anyways on a ValueToInt32.
 808         * dfg/DFGSpeculativeJIT32_64.cpp:
 809         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): Fixed a random compile error with this flag enabled.
 810
 811 2013-03-26  Filip Pizlo  <fpizlo@apple.com>
 812
 813         JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere
 814         https://bugs.webkit.org/show_bug.cgi?id=113144
 815
 816         Reviewed by Geoffrey Garen.
 817
 818         Forgot to include Geoff's requested change in the original commit.
 819
 820         * profiler/ProfilerDatabase.cpp:
 821         (Profiler):
 822
 823 2013-03-25  Filip Pizlo  <fpizlo@apple.com>
 824
 825         JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere
 826         https://bugs.webkit.org/show_bug.cgi?id=113144
 827
 828         Reviewed by Geoffrey Garen.
 829
 830         Added the ability to save profiler output with JSC_enableProfiler=true. It will save it
 831         to the current directory, or JSC_PROFILER_PATH if the latter was specified.
 832
 833         This works by saving the Profiler::Database either when it is destroyed or atexit(),
 834         whichever happens first.
 835
 836         This allows use of the profiler from any WebKit client.
 837
 838         * jsc.cpp:
 839         (jscmain):
 840         * profiler/ProfilerDatabase.cpp:
 841         (Profiler):
 842         (JSC::Profiler::Database::Database):
 843         (JSC::Profiler::Database::~Database):
 844         (JSC::Profiler::Database::registerToSaveAtExit):
 845         (JSC::Profiler::Database::addDatabaseToAtExit):
 846         (JSC::Profiler::Database::removeDatabaseFromAtExit):
 847         (JSC::Profiler::Database::performAtExitSave):
 848         (JSC::Profiler::Database::removeFirstAtExitDatabase):
 849         (JSC::Profiler::Database::atExitCallback):
 850         * profiler/ProfilerDatabase.h:
 851         (JSC::Profiler::Database::databaseID):
 852         (Database):
 853         * runtime/JSGlobalData.cpp:
 854         (JSC::JSGlobalData::JSGlobalData):
 855
 856 2013-03-25  Filip Pizlo  <fpizlo@apple.com>
 857
 858         ArrayMode should not consider SpecOther when refining the base
 859         https://bugs.webkit.org/show_bug.cgi?id=113271
 860
 861         Reviewed by Geoffrey Garen.
 862
 863         9% speed-up on Octane/pdfjs.
 864
 865         * dfg/DFGArrayMode.cpp:
 866         (JSC::DFG::ArrayMode::refine):
 867
 868 2013-03-26  Csaba Osztrogonác  <ossy@webkit.org>
 869
 870         Fix unused parameter warnings in JITInlines.h
 871         https://bugs.webkit.org/show_bug.cgi?id=112560
 872
 873         Reviewed by Zoltan Herczeg.
 874
 875         * jit/JITInlines.h:
 876         (JSC::JIT::beginUninterruptedSequence):
 877         (JSC::JIT::endUninterruptedSequence):
 878         (JSC):
 879
 880 2013-03-25  Kent Tamura  <tkent@chromium.org>
 881
 882         Rename ENABLE_INPUT_TYPE_DATETIME
 883         https://bugs.webkit.org/show_bug.cgi?id=113254
 884
 885         Reviewed by Kentaro Hara.
 886
 887         Rename ENABLE_INPUT_TYPE_DATETIME to ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE.
 888         Actually I'd like to remove the code, but we shouldn't remove it yet
 889         because we shipped products with it on some platforms.
 890
 891         * Configurations/FeatureDefines.xcconfig:
 892
 893 2013-03-25  Mark Lam  <mark.lam@apple.com>
 894
 895         Offlineasm cloop backend compiles op+branch incorrectly.
 896         https://bugs.webkit.org/show_bug.cgi?id=113146.
 897
 898         Reviewed by Geoffrey Garen.
 899
 900         * dfg/DFGRepatch.h:
 901         (JSC::DFG::dfgResetGetByID):
 902         (JSC::DFG::dfgResetPutByID):
 903         - These functions never return when the DFG is dsiabled, not just when
 904           asserts are enabled. Changing the attribute from NO_RETURN_DUE_TO_ASSERT
 905           to NO_RETURN.
 906         * llint/LLIntOfflineAsmConfig.h:
 907         - Added some #defines needed to get the cloop building again.
 908         * offlineasm/cloop.rb:
 909         - Fix cloopEmitOpAndBranchIfOverflow() and cloopEmitOpAndBranch() to
 910           emit code that unconditionally executes the specified operation before
 911           doing the conditional branch.
 912
 913 2013-03-25  Mark Hahnenberg  <mhahnenberg@apple.com>
 914
 915         JSObject::enterDictionaryIndexingMode doesn't have a case for ALL_BLANK_INDEXING_TYPES
 916         https://bugs.webkit.org/show_bug.cgi?id=113236
 917
 918         Reviewed by Geoffrey Garen.
 919
 920         * runtime/JSObject.cpp:
 921         (JSC::JSObject::enterDictionaryIndexingMode): We forgot blank indexing types.
 922
 923 2013-03-23  Mark Hahnenberg  <mhahnenberg@apple.com>
 924
 925         HandleSet should use HeapBlocks for storing handles
 926         https://bugs.webkit.org/show_bug.cgi?id=113145
 927
 928         Reviewed by Geoffrey Garen.
 929
 930         * GNUmakefile.list.am: Build project changes.
 931         * JavaScriptCore.gypi: Ditto.
 932         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto.
 933         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto.
 934         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
 935         * JavaScriptCore.xcodeproj/project.pbxproj: Ditto.
 936         * heap/BlockAllocator.cpp: Rename the RegionSet to m_fourKBBlockRegionSet because there are
 937         too many block types to include them all in the name now.
 938         (JSC::BlockAllocator::BlockAllocator):
 939         * heap/BlockAllocator.h:
 940         (BlockAllocator): Add the appropriate override for regionSetFor.
 941         (JSC::WeakBlock):
 942         (JSC::MarkStackSegment):
 943         (JSC::HandleBlock):
 944         * heap/HandleBlock.h: Added.
 945         (HandleBlock): New class for HandleBlocks.
 946         (JSC::HandleBlock::blockFor): Static method to get the block of the given HandleNode pointer. Allows
 947         us to quickly figure out which HandleSet the HandleNode belongs to without storing the pointer to it
 948         in the HandleNode.
 949         (JSC::HandleBlock::handleSet): Getter.
 950         * heap/HandleBlockInlines.h: Added.
 951         (JSC::HandleBlock::create):
 952         (JSC::HandleBlock::HandleBlock):
 953         (JSC::HandleBlock::payloadEnd):
 954         (JSC::HandleBlock::payload):
 955         (JSC::HandleBlock::nodes):
 956         (JSC::HandleBlock::nodeAtIndex):
 957         (JSC::HandleBlock::nodeCapacity):
 958         * heap/HandleSet.cpp:
 959         (JSC::HandleSet::~HandleSet):
 960         (JSC::HandleSet::grow):
 961         * heap/HandleSet.h:
 962         (HandleNode): Move the internal Node class from HandleSet to be its own public class so it can be
 963         used by HandleBlock.
 964         (HandleSet): Add a typedef so that Node refers to the new HandleNode class.
 965         (JSC::HandleSet::toHandle):
 966         (JSC::HandleSet::toNode):
 967         (JSC::HandleSet::allocate):
 968         (JSC::HandleSet::deallocate):
 969         (JSC::HandleNode::HandleNode):
 970         (JSC::HandleNode::slot):
 971         (JSC::HandleNode::handleSet): Use the new blockFor static function to get the right HandleBlock and lookup
 972         the HandleSet.
 973         (JSC::HandleNode::setPrev):
 974         (JSC::HandleNode::prev):
 975         (JSC::HandleNode::setNext):
 976         (JSC::HandleNode::next):
 977         (JSC::HandleSet::forEachStrongHandle):
 978         * heap/Heap.h: Friend HandleSet so that it can access the BlockAllocator when allocating HandleBlocks.
 979
 980 2013-03-22  David Kilzer  <ddkilzer@apple.com>
 981
 982         BUILD FIX (r145119): Make JSValue* properties default to (assign)
 983         <rdar://problem/13380794>
 984
 985         Reviewed by Mark Hahnenberg.
 986
 987         Fixes the following build failures:
 988
 989             Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute]
 990             @property JSValue *onclick;
 991             ^
 992             Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: default property attrib ute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute]
 993             Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute]
 994             @property JSValue *weakOnclick;
 995             ^
 996             Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: default property attribute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute]
 997             4 errors generated.
 998
 999         * API/tests/testapi.mm: Default to (assign) for JSValue*
1000         properties.
1001
1002 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>
1003
1004         testLeakingPrototypesAcrossContexts added in r146682 doesn't compile on Win and fails on Mac
1005         https://bugs.webkit.org/show_bug.cgi?id=113125
1006
1007         Reviewed by Mark Hahnenberg
1008
1009         Remove the test added in r146682 as it's now failing on Mac.
1010         This is the test that was causing a compilation failure on Windows.
1011
1012         * API/tests/testapi.c:
1013         (main):
1014
1015 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>
1016
1017         Fix the typo: WIN -> WINDOWS.
1018
1019         * API/tests/testapi.c:
1020         (main):
1021
1022 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>
1023
1024         I really can't figure out what's wrong with this one.
1025         Temporarily disable the test added by r146682 on Windows since it doesn't compile.
1026
1027         * API/tests/testapi.c:
1028         (main):
1029
1030 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>
1031
1032         Another build fix (after r146693) for r146682.
1033
1034         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
1035         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
1036
1037 2013-03-22  Roger Fong  <roger_fong@apple.com>
1038
1039         Unreviewed. AppleWin build fix.
1040
1041         * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd:
1042         * JavaScriptCore.vcxproj/copy-files.cmd:
1043
1044 2013-03-22  Mark Hahnenberg  <mhahnenberg@apple.com>
1045
1046         -[TinyDOMNode dealloc] should call [super dealloc] when ARC is not enabled
1047         https://bugs.webkit.org/show_bug.cgi?id=113054
1048
1049         Reviewed by Geoffrey Garen.
1050
1051         * API/tests/testapi.mm:
1052         (-[TinyDOMNode dealloc]):
1053
1054 2013-03-22  Mark Hahnenberg  <mhahnenberg@apple.com>
1055
1056         opaqueJSClassData should be cached on JSGlobalObject, not the JSGlobalData
1057         https://bugs.webkit.org/show_bug.cgi?id=113086
1058
1059         Reviewed by Geoffrey Garen.
1060
1061         opaqueJSClassData stores cached prototypes for JSClassRefs in the C API. It doesn't make sense to
1062         share these prototypes within a JSGlobalData across JSGlobalObjects, and in fact doing so will cause
1063         a leak of the original JSGlobalObject that these prototypes were created in. Therefore we should move
1064         this cache to JSGlobalObject where it belongs and where it won't cause memory leaks.
1065
1066         * API/JSBase.cpp: Needed to add an extern "C" so that testapi.c can use the super secret GC function.
1067         * API/JSClassRef.cpp: We now grab the cached context data from the global object rather than the global data.
1068         (OpaqueJSClass::contextData):
1069         * API/JSClassRef.h: Remove this header because it's unnecessary and causes circular dependencies.
1070         * API/tests/testapi.c: Added a new test that makes sure that using the same JSClassRef in two different contexts
1071         doesn't cause leaks of the original global object.
1072         (leakFinalize):
1073         (nestedAllocateObject): This is a hack to bypass the conservative scan of the GC, which was unnecessarily marking
1074         objects and keeping them alive, ruining the test result.
1075         (testLeakingPrototypesAcrossContexts):
1076         (main):
1077         * API/tests/testapi.mm: extern "C" this so we can continue using it here.
1078         * runtime/JSGlobalData.cpp: Remove JSClassRef related stuff.
1079         (JSC::JSGlobalData::~JSGlobalData):
1080         * runtime/JSGlobalData.h:
1081         (JSGlobalData):
1082         * runtime/JSGlobalObject.h: Add the stuff that JSGlobalData had. We add it to JSGlobalObjectRareData so that
1083         clients who don't use the C API don't have to pay the memory cost of this extra HashMap.
1084         (JSGlobalObject):
1085         (JSGlobalObjectRareData):
1086         (JSC::JSGlobalObject::opaqueJSClassData):
1087
1088 2013-03-19  Martin Robinson  <mrobinson@igalia.com>
1089
1090         [GTK] Add support for building the WebCore bindings to the gyp build
1091         https://bugs.webkit.org/show_bug.cgi?id=112638
1092
1093         Reviewed by Nico Weber.
1094
1095         * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Export all include directories to direct
1096         dependents and fix the indentation of the libjavascriptcore target.
1097
1098 2013-03-21  Filip Pizlo  <fpizlo@apple.com>
1099
1100         Fix some minor issues in the DFG's profiling of heap accesses
1101         https://bugs.webkit.org/show_bug.cgi?id=113010
1102
1103         Reviewed by Goeffrey Garen.
1104
1105         1) If a CodeBlock gets jettisoned by GC, we should count the exit sites.
1106
1107         2) If a CodeBlock clears a structure stub during GC, it should record this, and
1108         the DFG should prefer to not inline that access (i.e. treat it as if it had an
1109         exit site).
1110
1111         3) If a PutById was seen by the baseline JIT, and the JIT attempted to cache it,
1112         but it chose not to, then assume that it will take slow path.
1113
1114         4) If we frequently exited because of a structure check on a weak constant,
1115         don't try to inline that access in the future.
1116
1117         5) Treat all exits that were counted as being frequent.
1118
1119         81% speed-up on Octane/gbemu. Small speed-ups elsewhere, and no regressions.
1120
1121         * bytecode/CodeBlock.cpp:
1122         (JSC::CodeBlock::finalizeUnconditionally):
1123         (JSC):
1124         (JSC::CodeBlock::resetStubDuringGCInternal):
1125         (JSC::CodeBlock::reoptimize):
1126         (JSC::CodeBlock::jettison):
1127         (JSC::ProgramCodeBlock::jettisonImpl):
1128         (JSC::EvalCodeBlock::jettisonImpl):
1129         (JSC::FunctionCodeBlock::jettisonImpl):
1130         (JSC::CodeBlock::tallyFrequentExitSites):
1131         * bytecode/CodeBlock.h:
1132         (CodeBlock):
1133         (JSC::CodeBlock::tallyFrequentExitSites):
1134         (ProgramCodeBlock):
1135         (EvalCodeBlock):
1136         (FunctionCodeBlock):
1137         * bytecode/GetByIdStatus.cpp:
1138         (JSC::GetByIdStatus::computeFor):
1139         * bytecode/PutByIdStatus.cpp:
1140         (JSC::PutByIdStatus::computeFor):
1141         * bytecode/StructureStubInfo.h:
1142         (JSC::StructureStubInfo::StructureStubInfo):
1143         (StructureStubInfo):
1144         * dfg/DFGByteCodeParser.cpp:
1145         (JSC::DFG::ByteCodeParser::handleGetById):
1146         (JSC::DFG::ByteCodeParser::parseBlock):
1147         * dfg/DFGOSRExit.cpp:
1148         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
1149         * dfg/DFGOSRExit.h:
1150         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
1151         (OSRExit):
1152         * jit/JITStubs.cpp:
1153         (JSC::DEFINE_STUB_FUNCTION):
1154         * runtime/Options.h:
1155         (JSC):
1156
1157 2013-03-22  Filip Pizlo  <fpizlo@apple.com>
1158
1159         DFG folding of PutById to SimpleReplace should consider the specialized function case
1160         https://bugs.webkit.org/show_bug.cgi?id=113093
1161
1162         Reviewed by Geoffrey Garen and Mark Hahnenberg.
1163
1164         * bytecode/PutByIdStatus.cpp:
1165         (JSC::PutByIdStatus::computeFor):
1166
1167 2013-03-22  David Kilzer  <ddkilzer@apple.com>
1168
1169         BUILD FIX (r146558): Build testapi.mm with ARC enabled for armv7s
1170         <http://webkit.org/b/112608>
1171
1172         Fixes the following build failure:
1173
1174             Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls]
1175             }
1176             ^
1177             1 error generated.
1178
1179         * Configurations/ToolExecutable.xcconfig: Enable ARC for armv7s
1180         architecture.
1181
1182 2013-03-22  David Kilzer  <ddkilzer@apple.com>
1183
1184         Revert "BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc]"
1185
1186         This fixes a build failure introduced by this change:
1187
1188             Source/JavaScriptCore/API/tests/testapi.mm:206:6: error: ARC forbids explicit message send of 'dealloc'
1189                 [super dealloc];
1190                  ^     ~~~~~~~
1191             1 error generated.
1192
1193         Not sure why this didn't fail locally on my Mac Pro.
1194
1195         * API/tests/testapi.mm:
1196         (-[TinyDOMNode dealloc]): Remove call to [super dealloc].
1197
1198 2013-03-22  David Kilzer  <ddkilzer@apple.com>
1199
1200         BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc]
1201         <http://webkit.org/b/112608>
1202
1203         Fixes the following build failure:
1204
1205             Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls]
1206             }
1207             ^
1208             1 error generated.
1209
1210         * API/tests/testapi.mm:
1211         (-[TinyDOMNode dealloc]): Call [super dealloc].
1212
1213 2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>
1214
1215         Leak bots erroneously report JSC::WatchpointSet as leaking
1216         https://bugs.webkit.org/show_bug.cgi?id=107781
1217
1218         Reviewed by Filip Pizlo.
1219
1220         Since leaks doesn't support tagged pointers, avoid using it by flipping the bit flag to indicate
1221         the entry is "fat". We set the flag when the entry is NOT fat; i.e. slim.
1222
1223         Replaced FatFlag by SlimFlag and initialized m_bits with this flag to indicate that the entry is
1224         initially "slim".
1225
1226         * runtime/SymbolTable.cpp:
1227         (JSC::SymbolTableEntry::copySlow): Don't set FatFlag since it has been replaced by SlimFlag.
1228         (JSC::SymbolTableEntry::inflateSlow): Ditto.
1229
1230         * runtime/SymbolTable.h:
1231         (JSC::SymbolTableEntry::Fast::Fast): Set SlimFlag by default.
1232         (JSC::SymbolTableEntry::Fast::isNull): Ignore SlimFlag.
1233         (JSC::SymbolTableEntry::Fast::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag
1234         is not set.
1235
1236         (JSC::SymbolTableEntry::SymbolTableEntry): Set SlimFlag by default.
1237         (JSC::SymbolTableEntry::SymbolTableEntry::getFast): Set SlimFlag when creating Fast from a fat entry.
1238         (JSC::SymbolTableEntry::isNull): Ignore SlimFlag.
1239         (JSC::SymbolTableEntry::FatEntry::FatEntry): Strip SlimFlag.
1240         (JSC::SymbolTableEntry::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag is unset.
1241         (JSC::SymbolTableEntry::fatEntry): Don't strip FatFlag as this flag doesn't exist anymore.
1242         (JSC::SymbolTableEntry::pack): Preserve SlimFlag.
1243
1244         (JSC::SymbolTableIndexHashTraits): empty value is no longer zero so don't set emptyValueIsZero true.
1245
1246 2013-03-21  Mark Hahnenberg  <mhahnenberg@apple.com>
1247
1248         Objective-C API: Need a good way to preserve custom properties on JS wrappers
1249         https://bugs.webkit.org/show_bug.cgi?id=112608
1250
1251         Reviewed by Geoffrey Garen.
1252
1253         Currently, we just use a weak map, which means that garbage collection can cause a wrapper to
1254         disappear if it isn't directly exported to JavaScript.
1255
1256         The most straightforward and safe way (with respect to garbage collection and concurrency) is to have
1257         clients add and remove their external references along with their owners. Effectively, the client is
1258         recording the structure of the external object graph so that the garbage collector can make sure to
1259         mark any wrappers that are reachable through either the JS object graph of the external Obj-C object
1260         graph. By keeping these wrappers alive, this has the effect that custom properties on these wrappers
1261         will also remain alive.
1262
1263         The rule for if an object needs to be tracked by the runtime (and therefore whether the client should report it) is as follows:
1264         For a particular object, its references to its children should be added if:
1265         1. The child is referenced from JavaScript.
1266         2. The child contains references to other objects for which (1) or (2) are true.
1267
1268         * API/JSAPIWrapperObject.mm:
1269         (JSAPIWrapperObjectHandleOwner::finalize):
1270         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots): A wrapper object is kept alive only if its JSGlobalObject
1271         is marked and its corresponding Objective-C object was added to the set of opaque roots.
1272         (JSC::JSAPIWrapperObject::visitChildren): We now call out to scanExternalObjectGraph, which handles adding all Objective-C
1273         objects to the set of opaque roots.
1274         * API/JSAPIWrapperObject.h:
1275         (JSAPIWrapperObject):
1276         * API/JSContext.mm: Moved dealloc to its proper place in the main implementation.
1277         (-[JSContext dealloc]):
1278         * API/JSVirtualMachine.h:
1279         * API/JSVirtualMachine.mm:
1280         (-[JSVirtualMachine initWithContextGroupRef:]):
1281         (-[JSVirtualMachine dealloc]):
1282         (getInternalObjcObject): Helper funciton to get the Objective-C object out of JSManagedValues or JSValues if there is one.
1283         (-[JSVirtualMachine addManagedReference:withOwner:]): Adds the Objective-C object to the set of objects
1284         owned by the owner object in that particular virtual machine.
1285         (-[JSVirtualMachine removeManagedReference:withOwner:]): Removes the relationship between the two objects.
1286         (-[JSVirtualMachine externalObjectGraph]):
1287         (scanExternalObjectGraph): Does a depth-first search of the external object graph in a particular virtual machine starting at
1288         the specified root. Each new object it encounters it adds to the set of opaque roots. These opaque roots will keep their
1289         corresponding wrapper objects alive if they have them.
1290         * API/JSManagedReferenceInternal.h: Added.
1291         * API/JSVirtualMachine.mm: Added the per-JSVirtualMachine map between objects and the objects they own, which is more formally
1292         known as that virtual machine's external object graph.
1293         * API/JSWrapperMap.mm:
1294         (-[JSWrapperMap dealloc]): We were leaking this before :-(
1295         (-[JSVirtualMachine initWithContextGroupRef:]):
1296         (-[JSVirtualMachine dealloc]):
1297         (-[JSVirtualMachine externalObjectGraph]):
1298         * API/JSVirtualMachineInternal.h:
1299         * API/tests/testapi.mm: Added two new tests using the TinyDOMNode class. The first tests that a custom property added to a wrapper
1300         doesn't vanish after GC, even though that wrapper isn't directly accessible to the JS garbage collector but is accessible through
1301         the external Objective-C object graph. The second test makes sure that adding an object to the external object graph with the same
1302         owner doesn't cause any sort of problems.
1303         (+[TinyDOMNode sharedVirtualMachine]):
1304         (-[TinyDOMNode init]):
1305         (-[TinyDOMNode dealloc]):
1306         (-[TinyDOMNode appendChild:]):
1307         (-[TinyDOMNode numberOfChildren]):
1308         (-[TinyDOMNode childAtIndex:]):
1309         (-[TinyDOMNode removeChildAtIndex:]):
1310         * JavaScriptCore.xcodeproj/project.pbxproj:
1311         * heap/SlotVisitor.h:
1312         (SlotVisitor):
1313         * heap/SlotVisitorInlines.h:
1314         (JSC::SlotVisitor::containsOpaqueRootTriState): Added a new method to SlotVisitor to allow scanExternalObjectGraph to have a
1315         thread-safe view of opaque roots during parallel marking. The set of opaque roots available to any one SlotVisitor isn't guaranteed
1316         to be 100% correct, but that just results in a small duplication of work in scanExternalObjectGraph. To indicate this change for
1317         false negatives we return a TriState that's either true or mixed, but never false.
1318
1319 2013-03-21  Mark Lam  <mark.lam@apple.com>
1320
1321         Fix O(n^2) op_debug bytecode charPosition to column computation.
1322         https://bugs.webkit.org/show_bug.cgi?id=112957.
1323
1324         Reviewed by Geoffrey Garen.
1325
1326         The previous algorithm does a linear reverse scan of the source string
1327         to find the line start for any given char position. This results in a
1328         O(n^2) algortithm when the source string has no line breaks.
1329
1330         The new algorithm computes a line start column table for a
1331         SourceProvider on first use. This line start table is used to fix up
1332         op_debug's charPosition operand into a column operand when an
1333         UnlinkedCodeBlock is linked into a CodeBlock. The initialization of
1334         the line start table is O(n), and the CodeBlock column fix up is
1335         O(log(n)).
1336
1337         * bytecode/CodeBlock.cpp:
1338         (JSC::CodeBlock::dumpBytecode):
1339         (JSC::CodeBlock::CodeBlock): - do column fix up.
1340         * interpreter/Interpreter.cpp:
1341         (JSC::Interpreter::debug): - no need to do column fixup anymore.
1342         * interpreter/Interpreter.h:
1343         * jit/JITStubs.cpp:
1344         (JSC::DEFINE_STUB_FUNCTION):
1345         * llint/LLIntSlowPaths.cpp:
1346         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1347         * parser/SourceProvider.cpp:
1348         (JSC::SourceProvider::lineStarts):
1349         (JSC::charPositionExtractor):
1350         (JSC::SourceProvider::charPositionToColumnNumber):
1351         - initialize line start column table if needed.
1352         - look up line start for the given char position.
1353         * parser/SourceProvider.h:
1354
1355 2013-03-21  Filip Pizlo  <fpizlo@apple.com>
1356
1357         JSC profiler should have an at-a-glance report of the success of DFG optimization
1358         https://bugs.webkit.org/show_bug.cgi?id=112988
1359
1360         Reviewed by Geoffrey Garen.
1361
1362         * dfg/DFGByteCodeParser.cpp:
1363         (JSC::DFG::ByteCodeParser::handleCall):
1364         (JSC::DFG::ByteCodeParser::handleGetById):
1365         (JSC::DFG::ByteCodeParser::parseBlock):
1366         * profiler/ProfilerCompilation.cpp:
1367         (JSC::Profiler::Compilation::Compilation):
1368         (JSC::Profiler::Compilation::toJS):
1369         * profiler/ProfilerCompilation.h:
1370         (JSC::Profiler::Compilation::noticeInlinedGetById):
1371         (JSC::Profiler::Compilation::noticeInlinedPutById):
1372         (JSC::Profiler::Compilation::noticeInlinedCall):
1373         (Compilation):
1374         * runtime/CommonIdentifiers.h:
1375
1376 2013-03-21  Mark Lam  <mark.lam@apple.com>
1377
1378         Fix lexer charPosition computation when "rewind"ing the lexer.
1379         https://bugs.webkit.org/show_bug.cgi?id=112952.
1380
1381         Reviewed by Michael Saboff.
1382
1383         Changed the Lexer to no longer keep a m_charPosition. Instead, we compute
1384         currentCharPosition() from m_code and m_codeStartPlusOffset, where
1385         m_codeStartPlusOffset is the SourceProvider m_codeStart + the SourceCode
1386         start offset. This ensures that the charPosition is always in sync with
1387         m_code.
1388
1389         * parser/Lexer.cpp:
1390         (JSC::::setCode):
1391         (JSC::::internalShift):
1392         (JSC::::shift):
1393         (JSC::::lex):
1394         * parser/Lexer.h:
1395         (JSC::Lexer::currentCharPosition):
1396         (JSC::::lexExpectIdentifier):
1397
1398 2013-03-21  Alberto Garcia  <agarcia@igalia.com>
1399
1400         [BlackBerry] GCActivityCallback: replace JSLock with JSLockHolder
1401         https://bugs.webkit.org/show_bug.cgi?id=112448
1402
1403         Reviewed by Xan Lopez.
1404
1405         This changed in r121381.
1406
1407         * runtime/GCActivityCallbackBlackBerry.cpp:
1408         (JSC::DefaultGCActivityCallback::doWork):
1409
1410 2013-03-21  Mark Hahnenberg  <mhahnenberg@apple.com>
1411
1412         Objective-C API: wrapperClass holds a static JSClassRef, which causes JSGlobalObjects to leak
1413         https://bugs.webkit.org/show_bug.cgi?id=112856
1414
1415         Reviewed by Geoffrey Garen.
1416
1417         Through a very convoluted path that involves the caching of prototypes on the JSClassRef, we can leak
1418         JSGlobalObjects when inserting an Objective-C object into multiple independent JSContexts.
1419
1420         * API/JSAPIWrapperObject.cpp: Removed.
1421         * API/JSAPIWrapperObject.h:
1422         (JSAPIWrapperObject):
1423         * API/JSAPIWrapperObject.mm: Copied from Source/JavaScriptCore/API/JSAPIWrapperObject.cpp. Made this an
1424         Objective-C++ file so that we can call release on the wrappedObject. Also added a WeakHandleOwner for
1425         JSAPIWrapperObjects. This will also be used in a future patch for https://bugs.webkit.org/show_bug.cgi?id=112608.
1426         (JSAPIWrapperObjectHandleOwner):
1427         (jsAPIWrapperObjectHandleOwner):
1428         (JSAPIWrapperObjectHandleOwner::finalize): This finalize replaces the old finalize that was done through
1429         the C API.
1430         (JSC::JSAPIWrapperObject::finishCreation): Allocate the WeakImpl. Balanced in finalize.
1431         (JSC::JSAPIWrapperObject::setWrappedObject): We now do the retain of the wrappedObject here rather than in random
1432         places scattered around JSWrapperMap.mm
1433         * API/JSObjectRef.cpp: Added some ifdefs for platforms that don't support the Obj-C API.
1434         (JSObjectGetPrivate): Ditto.
1435         (JSObjectSetPrivate): Ditto.
1436         (JSObjectGetPrivateProperty): Ditto.
1437         (JSObjectSetPrivateProperty): Ditto.
1438         (JSObjectDeletePrivateProperty): Ditto.
1439         * API/JSValueRef.cpp: Ditto.
1440         (JSValueIsObjectOfClass): Ditto.
1441         * API/JSWrapperMap.mm: Remove wrapperClass().
1442         (objectWithCustomBrand): Change to no longer use a parent class, which was only used to give the ability to
1443         finalize wrapper objects.
1444         (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Change to no longer use wrapperClass().
1445         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Ditto.
1446         (tryUnwrapObjcObject): We now check if the object inherits from JSAPIWrapperObject.
1447         * API/tests/testapi.mm: Added a test that exports an Objective-C object to two different JSContexts and makes
1448         sure that the first one is collected properly by using a weak JSManagedValue for the wrapper in the first JSContext.
1449         * CMakeLists.txt: Build file modifications.
1450         * GNUmakefile.list.am: Ditto.
1451         * JavaScriptCore.gypi: Ditto.
1452         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto.
1453         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto.
1454         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
1455         * JavaScriptCore.xcodeproj/project.pbxproj: Ditto.
1456         * runtime/JSGlobalObject.cpp: More ifdefs for unsupported platforms.
1457         (JSC::JSGlobalObject::reset): Ditto.
1458         (JSC::JSGlobalObject::visitChildren): Ditto.
1459         * runtime/JSGlobalObject.h: Ditto.
1460         (JSGlobalObject): Ditto.
1461         (JSC::JSGlobalObject::objcCallbackFunctionStructure): Ditto.
1462
1463 2013-03-21  Anton Muhin  <antonm@chromium.org>
1464
1465         Unreviewed, rolling out r146483.
1466         http://trac.webkit.org/changeset/146483
1467         https://bugs.webkit.org/show_bug.cgi?id=111695
1468
1469         Breaks debug builds.
1470
1471         * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo.
1472
1473 2013-03-21  Gabor Rapcsanyi  <rgabor@webkit.org>
1474
1475         Implement LLInt for CPU(ARM_TRADITIONAL)
1476         https://bugs.webkit.org/show_bug.cgi?id=97589
1477
1478         Reviewed by Zoltan Herczeg.
1479
1480         Enable LLInt for ARMv5 and ARMv7 traditional as well.
1481
1482         * llint/LLIntOfflineAsmConfig.h:
1483         * llint/LowLevelInterpreter.asm:
1484         * llint/LowLevelInterpreter32_64.asm:
1485         * offlineasm/arm.rb:
1486         * offlineasm/backends.rb:
1487         * offlineasm/instructions.rb:
1488
1489 2013-03-20  Cosmin Truta  <ctruta@blackberry.com>
1490
1491         [QNX][ARM] REGRESSION(r135330): Various failures in Octane
1492         https://bugs.webkit.org/show_bug.cgi?id=112863
1493
1494         Reviewed by Yong Li.
1495
1496         This was fixed in http://trac.webkit.org/changeset/146396 on Linux only.
1497         Enable this fix on QNX.
1498
1499         * assembler/ARMv7Assembler.h:
1500         (ARMv7Assembler):
1501         (JSC::ARMv7Assembler::replaceWithJump):
1502         (JSC::ARMv7Assembler::maxJumpReplacementSize):
1503         * assembler/MacroAssemblerARMv7.h:
1504         (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):
1505
1506 2013-03-20  Filip Pizlo  <fpizlo@apple.com>
1507
1508         Fix indentation of JSString.h
1509
1510         Rubber stamped by Mark Hahnenberg.
1511
1512         * runtime/JSString.h:
1513
1514 2013-03-20  Filip Pizlo  <fpizlo@apple.com>
1515
1516         "" + x where x is not a string should be optimized by the DFG to some manner of ToString conversion
1517         https://bugs.webkit.org/show_bug.cgi?id=112845
1518
1519         Reviewed by Mark Hahnenberg.
1520
1521         I like to do "" + x. So I decided to make DFG recognize it, and related idioms.
1522
1523         * dfg/DFGFixupPhase.cpp:
1524         (JSC::DFG::FixupPhase::fixupNode):
1525         (JSC::DFG::FixupPhase::fixupToPrimitive):
1526         (FixupPhase):
1527         (JSC::DFG::FixupPhase::fixupToString):
1528         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1529         * dfg/DFGPredictionPropagationPhase.cpp:
1530         (JSC::DFG::resultOfToPrimitive):
1531         (DFG):
1532         (JSC::DFG::PredictionPropagationPhase::propagate):
1533         * dfg/DFGPredictionPropagationPhase.h:
1534         (DFG):
1535
1536 2013-03-20  Zoltan Herczeg  <zherczeg@webkit.org>
1537
1538         ARMv7 replaceWithJump ASSERT failure after r135330.
1539         https://bugs.webkit.org/show_bug.cgi?id=103146
1540
1541         Reviewed by Filip Pizlo.
1542
1543         On Linux, the 24 bit distance range of jumps sometimes does not
1544         enough to cover all targets addresses. This patch supports jumps
1545         outside of this range using a mov/movt/bx 10 byte long sequence.
1546
1547         * assembler/ARMv7Assembler.h:
1548         (ARMv7Assembler):
1549         (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2):
1550         (JSC::ARMv7Assembler::nopw):
1551         (JSC::ARMv7Assembler::label):
1552         (JSC::ARMv7Assembler::replaceWithJump):
1553         (JSC::ARMv7Assembler::maxJumpReplacementSize):
1554         * assembler/MacroAssemblerARMv7.h:
1555         (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):
1556
1557 2013-03-20  Mark Hahnenberg  <mhahnenberg@apple.com>
1558
1559         Objective-C API: Fix over-releasing in allocateConstructorAndPrototypeWithSuperClassInfo:
1560         https://bugs.webkit.org/show_bug.cgi?id=112832
1561
1562         Reviewed by Geoffrey Garen.
1563
1564         If either the m_constructor or m_prototype (but not both) is collected, we will call
1565         allocateConstructorAndPrototypeWithSuperClassInfo, which will create a new object to replace the one
1566         that was collected, but at the end of the method we call release on both of them.
1567         This is incorrect since we autorelease the JSValue in the case that the object doesn't need to be
1568         reallocated. Thus we'll end up overreleasing later during the drain of the autorelease pool.
1569
1570         * API/JSWrapperMap.mm:
1571         (objectWithCustomBrand): We no longer alloc here. We instead call the JSValue valueWithValue class method,
1572         which autoreleases for us.
1573         (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We no longer call release on the
1574         constructor or prototype JSValues.
1575         * API/tests/testapi.mm: Added a new test that crashes on ToT due to over-releasing.
1576
1577 2013-03-19  Filip Pizlo  <fpizlo@apple.com>
1578
1579         It's called "Hash Consing" not "Hash Consting"
1580         https://bugs.webkit.org/show_bug.cgi?id=112768
1581
1582         Rubber stamped by Mark Hahnenberg.
1583
1584         See http://en.wikipedia.org/wiki/Hash_consing
1585
1586         * heap/GCThreadSharedData.cpp:
1587         (JSC::GCThreadSharedData::GCThreadSharedData):
1588         (JSC::GCThreadSharedData::reset):
1589         * heap/GCThreadSharedData.h:
1590         (GCThreadSharedData):
1591         * heap/SlotVisitor.cpp:
1592         (JSC::SlotVisitor::SlotVisitor):
1593         (JSC::SlotVisitor::setup):
1594         (JSC::SlotVisitor::reset):
1595         (JSC::JSString::tryHashConsLock):
1596         (JSC::JSString::releaseHashConsLock):
1597         (JSC::JSString::shouldTryHashCons):
1598         (JSC::SlotVisitor::internalAppend):
1599         * heap/SlotVisitor.h:
1600         (SlotVisitor):
1601         * runtime/JSGlobalData.cpp:
1602         (JSC::JSGlobalData::JSGlobalData):
1603         * runtime/JSGlobalData.h:
1604         (JSGlobalData):
1605         (JSC::JSGlobalData::haveEnoughNewStringsToHashCons):
1606         (JSC::JSGlobalData::resetNewStringsSinceLastHashCons):
1607         * runtime/JSString.h:
1608         (JSC::JSString::finishCreation):
1609         (JSString):
1610         (JSC::JSString::isHashConsSingleton):
1611         (JSC::JSString::clearHashConsSingleton):
1612         (JSC::JSString::setHashConsSingleton):
1613
1614 2013-03-20  Filip Pizlo  <fpizlo@apple.com>
1615
1616         DFG implementation of op_strcat should inline rope allocations
1617         https://bugs.webkit.org/show_bug.cgi?id=112780
1618
1619         Reviewed by Oliver Hunt.
1620
1621         This gets rid of the StrCat node and adds a MakeRope node. The MakeRope node can
1622         take either two or three operands, and allocates a rope string with either two or
1623         three fibers. (The magic choice of three children for non-VarArg nodes happens to
1624         match exactly with the magic choice of three fibers for rope strings.)
1625
1626         ValueAdd on KnownString is replaced with MakeRope with two children.
1627
1628         StrCat gets replaced by an appropriate sequence of MakeRope's.
1629
1630         MakeRope does not do the dynamic check to see if its children are empty strings.
1631         This is replaced by a static check, instead. The downside is that we may use more
1632         memory if the strings passed to MakeRope turn out to dynamically be empty. The
1633         upside is that we do fewer checks in the cases where either the strings are not
1634         empty, or where the strings are statically known to be empty. I suspect both of
1635         those cases are more common, than the case where the string is dynamically empty.
1636
1637         This also results in some badness for X86. MakeRope needs six registers if it is
1638         allocating a three-rope. We don't have six registers to spare on X86. Currently,
1639         the code side-steps this problem by just never usign three-ropes in optimized
1640         code on X86. All other architectures, including X86_64, don't have this problem.
1641
1642         This is a shocking speed-up. 9% progressions on both V8/splay and
1643         SunSpider/date-format-xparb. 1% progression on V8v7 overall, and ~0.5% progression
1644         on SunSpider. 2x speed-up on microbenchmarks that test op_strcat.
1645
1646         * dfg/DFGAbstractState.cpp:
1647         (JSC::DFG::AbstractState::executeEffects):
1648         * dfg/DFGAdjacencyList.h:
1649         (AdjacencyList):
1650         (JSC::DFG::AdjacencyList::removeEdge):
1651         * dfg/DFGArgumentsSimplificationPhase.cpp:
1652         (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
1653         * dfg/DFGBackwardsPropagationPhase.cpp:
1654         (JSC::DFG::BackwardsPropagationPhase::propagate):
1655         * dfg/DFGByteCodeParser.cpp:
1656         (JSC::DFG::ByteCodeParser::parseBlock):
1657         * dfg/DFGCSEPhase.cpp:
1658         (JSC::DFG::CSEPhase::putStructureStoreElimination):
1659         (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
1660         (JSC::DFG::CSEPhase::performNodeCSE):
1661         * dfg/DFGDCEPhase.cpp:
1662         (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
1663         * dfg/DFGFixupPhase.cpp:
1664         (JSC::DFG::FixupPhase::fixupNode):
1665         (JSC::DFG::FixupPhase::createToString):
1666         (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
1667         (JSC::DFG::FixupPhase::convertStringAddUse):
1668         (FixupPhase):
1669         (JSC::DFG::FixupPhase::convertToMakeRope):
1670         (JSC::DFG::FixupPhase::fixupMakeRope):
1671         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1672         * dfg/DFGNodeType.h:
1673         (DFG):
1674         * dfg/DFGOperations.cpp:
1675         * dfg/DFGOperations.h:
1676         * dfg/DFGPredictionPropagationPhase.cpp:
1677         (JSC::DFG::PredictionPropagationPhase::propagate):
1678         * dfg/DFGSpeculativeJIT.cpp:
1679         (JSC::DFG::SpeculativeJIT::compileAdd):
1680         (JSC::DFG::SpeculativeJIT::compileMakeRope):
1681         (DFG):
1682         * dfg/DFGSpeculativeJIT.h:
1683         (JSC::DFG::SpeculativeJIT::callOperation):
1684         (SpeculativeJIT):
1685         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
1686         (JSC::DFG::SpeculateCellOperand::~SpeculateCellOperand):
1687         (JSC::DFG::SpeculateCellOperand::gpr):
1688         (JSC::DFG::SpeculateCellOperand::use):
1689         * dfg/DFGSpeculativeJIT32_64.cpp:
1690         (JSC::DFG::SpeculativeJIT::compile):
1691         * dfg/DFGSpeculativeJIT64.cpp:
1692         (JSC::DFG::SpeculativeJIT::compile):
1693         * runtime/JSString.h:
1694         (JSRopeString):
1695
1696 2013-03-20  Peter Gal  <galpeter@inf.u-szeged.hu>
1697
1698         Implement and32 on MIPS platform
1699         https://bugs.webkit.org/show_bug.cgi?id=112665
1700
1701         Reviewed by Zoltan Herczeg.
1702
1703         * assembler/MacroAssemblerMIPS.h:
1704         (JSC::MacroAssemblerMIPS::and32): Added missing method.
1705         (MacroAssemblerMIPS):
1706
1707 2013-03-20  Mark Lam  <mark.lam@apple.com>
1708
1709         Fix incorrect debugger column number value.
1710         https://bugs.webkit.org/show_bug.cgi?id=112741.
1711
1712         Reviewed by Oliver Hunt.
1713
1714         1. In lexer, parser, and debugger code, renamed column to charPosition.
1715         2. Convert the charPosition to the equivalent column number before
1716            passing it to the debugger.
1717         3. Changed ScopeNodes to take both a startLocation and an endLocation.
1718            This allows FunctionBodyNodes, ProgramNodes, and EvalNodess to emit
1719            correct debug hooks with correct starting line and column numbers.
1720         4. Fixed the Lexer to not reset the charPosition (previously
1721            columnNumber) in Lexer::lex().
1722
1723         * JavaScriptCore.order:
1724         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
1725         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
1726         * bytecode/CodeBlock.cpp:
1727         (JSC::CodeBlock::dumpBytecode):
1728         * bytecompiler/BytecodeGenerator.cpp:
1729         (JSC::BytecodeGenerator::emitDebugHook):
1730         * bytecompiler/BytecodeGenerator.h:
1731         (JSC::BytecodeGenerator::emitExpressionInfo):
1732         * bytecompiler/NodesCodegen.cpp:
1733         (JSC::ArrayNode::toArgumentList):
1734         (JSC::ConstStatementNode::emitBytecode):
1735         (JSC::EmptyStatementNode::emitBytecode):
1736         (JSC::DebuggerStatementNode::emitBytecode):
1737         (JSC::ExprStatementNode::emitBytecode):
1738         (JSC::VarStatementNode::emitBytecode):
1739         (JSC::IfNode::emitBytecode):
1740         (JSC::IfElseNode::emitBytecode):
1741         (JSC::DoWhileNode::emitBytecode):
1742         (JSC::WhileNode::emitBytecode):
1743         (JSC::ForNode::emitBytecode):
1744         (JSC::ForInNode::emitBytecode):
1745         (JSC::ContinueNode::emitBytecode):
1746         (JSC::BreakNode::emitBytecode):
1747         (JSC::ReturnNode::emitBytecode):
1748         (JSC::WithNode::emitBytecode):
1749         (JSC::SwitchNode::emitBytecode):
1750         (JSC::LabelNode::emitBytecode):
1751         (JSC::ThrowNode::emitBytecode):
1752         (JSC::TryNode::emitBytecode):
1753         (JSC::ProgramNode::emitBytecode):
1754         (JSC::EvalNode::emitBytecode):
1755         (JSC::FunctionBodyNode::emitBytecode):
1756         * interpreter/Interpreter.cpp:
1757         (JSC::Interpreter::debug):
1758         - convert charPosition to column for the debugger.
1759         * interpreter/Interpreter.h:
1760         * jit/JITStubs.cpp:
1761         (DEFINE_STUB_FUNCTION(void, op_debug)):
1762         * llint/LLIntSlowPaths.cpp:
1763         (LLINT_SLOW_PATH_DECL(slow_op_debug)):
1764         * parser/ASTBuilder.h:
1765         (JSC::ASTBuilder::createFunctionExpr):
1766         (JSC::ASTBuilder::createFunctionBody):
1767         (JSC::ASTBuilder::createGetterOrSetterProperty):
1768         (JSC::ASTBuilder::createFuncDeclStatement):
1769         (JSC::ASTBuilder::createBlockStatement):
1770         (JSC::ASTBuilder::createExprStatement):
1771         (JSC::ASTBuilder::createIfStatement):
1772         (JSC::ASTBuilder::createForLoop):
1773         (JSC::ASTBuilder::createForInLoop):
1774         (JSC::ASTBuilder::createVarStatement):
1775         (JSC::ASTBuilder::createReturnStatement):
1776         (JSC::ASTBuilder::createBreakStatement):
1777         (JSC::ASTBuilder::createContinueStatement):
1778         (JSC::ASTBuilder::createTryStatement):
1779         (JSC::ASTBuilder::createSwitchStatement):
1780         (JSC::ASTBuilder::createWhileStatement):
1781         (JSC::ASTBuilder::createDoWhileStatement):
1782         (JSC::ASTBuilder::createWithStatement):
1783         (JSC::ASTBuilder::createThrowStatement):
1784         (JSC::ASTBuilder::createDebugger):
1785         (JSC::ASTBuilder::createConstStatement):
1786         * parser/Lexer.cpp:
1787         (JSC::::setCode):
1788         (JSC::::internalShift):
1789         (JSC::::shift):
1790         (JSC::::lex):
1791         * parser/Lexer.h:
1792         (JSC::Lexer::currentCharPosition):
1793         (Lexer):
1794         (JSC::::lexExpectIdentifier):
1795         * parser/NodeConstructors.h:
1796         (JSC::Node::Node):
1797         * parser/Nodes.cpp:
1798         (JSC::StatementNode::setLoc):
1799         (JSC::ScopeNode::ScopeNode):
1800         (JSC::ProgramNode::ProgramNode):
1801         (JSC::ProgramNode::create):
1802         (JSC::EvalNode::EvalNode):
1803         (JSC::EvalNode::create):
1804         (JSC::FunctionBodyNode::FunctionBodyNode):
1805         (JSC::FunctionBodyNode::create):
1806         * parser/Nodes.h:
1807         (JSC::Node::charPosition):
1808         (Node):
1809         (StatementNode):
1810         (JSC::StatementNode::lastLine):
1811         (ScopeNode):
1812         (JSC::ScopeNode::startLine):
1813         (JSC::ScopeNode::startCharPosition):
1814         (ProgramNode):
1815         (EvalNode):
1816         (FunctionBodyNode):
1817         * parser/Parser.cpp:
1818         (JSC::::Parser):
1819         (JSC::::parseFunctionBody):
1820         (JSC::::parseFunctionInfo):
1821         * parser/Parser.h:
1822         (JSC::::parse):
1823         * parser/ParserTokens.h:
1824         (JSC::JSTokenLocation::JSTokenLocation):
1825         (JSTokenLocation):
1826         * parser/SyntaxChecker.h:
1827         (JSC::SyntaxChecker::createFunctionBody):
1828
1829 2013-03-20  Csaba Osztrogonác  <ossy@webkit.org>
1830
1831         REGRESSION(r146089): It broke 20 sputnik tests on ARM traditional and Thumb2
1832         https://bugs.webkit.org/show_bug.cgi?id=112676
1833
1834         Rubber-stamped by Filip Pizlo.
1835
1836         Add one more EABI_32BIT_DUMMY_ARG to make DFG JIT ARM EABI compatible
1837         again after r146089 similar to https://bugs.webkit.org/show_bug.cgi?id=84449
1838
1839         * dfg/DFGSpeculativeJIT.h:
1840         (JSC::DFG::SpeculativeJIT::callOperation):
1841
1842 2013-03-19  Michael Saboff  <msaboff@apple.com>
1843
1844         Crash when loading http://www.jqchart.com/jquery/gauges/RadialGauge/LiveData
1845         https://bugs.webkit.org/show_bug.cgi?id=112694
1846
1847         Reviewed by Filip Pizlo.
1848
1849         We were trying to convert an NewArray to a Phantom, but convertToPhantom doesn't handle
1850         nodes with variable arguments.  Added code to insert a Phantom node in front of all the
1851         live children of a var args node.  Added ASSERT not var args for convertToPhantom to
1852         catch any other similar cases.  Added a new convertToPhantomUnchecked() for converting
1853         var arg nodes.
1854
1855         * dfg/DFGDCEPhase.cpp:
1856         (JSC::DFG::DCEPhase::run):
1857         * dfg/DFGNode.h:
1858         (Node):
1859         (JSC::DFG::Node::setOpAndDefaultNonExitFlags): Added ASSERT(!(m_flags & NodeHasVarArgs))
1860         (JSC::DFG::Node::setOpAndDefaultNonExitFlagsUnchecked):
1861         (JSC::DFG::Node::convertToPhantomUnchecked):
1862
1863 2013-03-19  Mark Hahnenberg  <mhahnenberg@apple.com>
1864
1865         Crash in SpeculativeJIT::fillSpeculateIntInternal<false> on http://bellard.org/jslinux
1866         https://bugs.webkit.org/show_bug.cgi?id=112738
1867
1868         Reviewed by Filip Pizlo.
1869
1870         * dfg/DFGFixupPhase.cpp:
1871         (JSC::DFG::FixupPhase::fixIntEdge): We shouldn't be killing this node because it could be
1872         referenced by other people.
1873
1874 2013-03-19  Oliver Hunt  <oliver@apple.com>
1875
1876         RELEASE_ASSERT fires in exception handler lookup
1877
1878         RS=Geoff Garen.
1879
1880         Temporarily switch this RELEASE_ASSERT into a regular ASSERT
1881         as currently this is producing fairly bad crashiness.
1882
1883         * bytecode/CodeBlock.cpp:
1884         (JSC::CodeBlock::handlerForBytecodeOffset):
1885
1886 2013-03-18  Filip Pizlo  <fpizlo@apple.com>
1887
1888         DFG should optimize StringObject.length and StringOrStringObject.length
1889         https://bugs.webkit.org/show_bug.cgi?id=112658
1890
1891         Reviewed by Mark Hahnenberg.
1892
1893         Implemented by injecting a ToString(StringObject:@a) or ToString(StringOrStringObject:@a) prior
1894         to GetArrayLength with ArrayMode(Array::String) if @a is predicted StringObject or
1895         StringOrStringObject.
1896
1897         * dfg/DFGFixupPhase.cpp:
1898         (JSC::DFG::FixupPhase::fixupNode):
1899         (JSC::DFG::FixupPhase::createToString):
1900         (FixupPhase):
1901         (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
1902         (JSC::DFG::FixupPhase::convertStringAddUse):
1903
1904 2013-03-19  Gabor Rapcsanyi  <rgabor@webkit.org>
1905
1906         Implement and32 on ARMv7 and ARM traditional platforms
1907         https://bugs.webkit.org/show_bug.cgi?id=112663
1908
1909         Reviewed by Zoltan Herczeg.
1910
1911         * assembler/MacroAssemblerARM.h:
1912         (JSC::MacroAssemblerARM::and32): Add missing method.
1913         (MacroAssemblerARM):
1914         * assembler/MacroAssemblerARMv7.h:
1915         (JSC::MacroAssemblerARMv7::and32): Add missing method.
1916         (MacroAssemblerARMv7):
1917
1918 2013-03-18  Filip Pizlo  <fpizlo@apple.com>
1919
1920         DFG ToString generic cases should work correctly
1921         https://bugs.webkit.org/show_bug.cgi?id=112654
1922         <rdar://problem/13447250>
1923
1924         Reviewed by Geoffrey Garen.
1925
1926         * dfg/DFGSpeculativeJIT.cpp:
1927         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
1928         * dfg/DFGSpeculativeJIT32_64.cpp:
1929         (JSC::DFG::SpeculativeJIT::compile):
1930         * dfg/DFGSpeculativeJIT64.cpp:
1931         (JSC::DFG::SpeculativeJIT::compile):
1932
1933 2013-03-18  Michael Saboff  <msaboff@apple.com>
1934
1935         Unreviewed build fix for 32 bit builds.
1936
1937         * dfg/DFGSpeculativeJIT32_64.cpp:
1938         (JSC::DFG::SpeculativeJIT::compile):
1939
1940 2013-03-18  Michael Saboff  <msaboff@apple.com>
1941
1942         EFL: Unsafe branch detected in compilePutByValForFloatTypedArray()
1943         https://bugs.webkit.org/show_bug.cgi?id=112609
1944
1945         Reviewed by Geoffrey Garen.
1946
1947         Created local valueFPR and scratchFPR and filled them with valueOp.fpr() and scratch.fpr()
1948         respectively so that if valueOp.fpr() causes a spill during allocation, it occurs before the
1949         branch and also to follow convention.  Added register allocation checks to FPRTemporary.
1950         Cleaned up a couple of other places to follow the "AllocatVirtualRegType foo, get machine
1951         reg from foo" pattern.
1952
1953         * dfg/DFGSpeculativeJIT.cpp:
1954         (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
1955         * dfg/DFGSpeculativeJIT.h:
1956         (JSC::DFG::SpeculativeJIT::fprAllocate):
1957         * dfg/DFGSpeculativeJIT32_64.cpp:
1958         (JSC::DFG::SpeculativeJIT::convertToDouble):
1959         (JSC::DFG::SpeculativeJIT::compile):
1960         * dfg/DFGSpeculativeJIT64.cpp:
1961         (JSC::DFG::SpeculativeJIT::compile):
1962
1963 2013-03-18  Filip Pizlo  <fpizlo@apple.com>
1964
1965         DFG should inline binary string concatenations (i.e. ValueAdd with string children)
1966         https://bugs.webkit.org/show_bug.cgi?id=112599
1967
1968         Reviewed by Oliver Hunt.
1969
1970         This does as advertised: if you do x + y where x and y are strings, you'll get
1971         a fast inlined JSRopeString allocation (along with whatever checks are necessary).
1972         It also does good things if either x or y (or both) are StringObjects, or some
1973         other thing like StringOrStringObject. It also lays the groundwork for making this
1974         fast if either x or y are numbers, or some other reasonably-cheap-to-convert
1975         value.
1976
1977         * dfg/DFGAbstractState.cpp:
1978         (JSC::DFG::AbstractState::executeEffects):
1979         * dfg/DFGFixupPhase.cpp:
1980         (JSC::DFG::FixupPhase::fixupNode):
1981         (FixupPhase):
1982         (JSC::DFG::FixupPhase::isStringObjectUse):
1983         (JSC::DFG::FixupPhase::convertStringAddUse):
1984         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1985         * dfg/DFGOperations.cpp:
1986         * dfg/DFGOperations.h:
1987         * dfg/DFGSpeculativeJIT.cpp:
1988         (JSC::DFG::SpeculativeJIT::compileAdd):
1989         * dfg/DFGSpeculativeJIT.h:
1990         (JSC::DFG::SpeculativeJIT::callOperation):
1991         (SpeculativeJIT):
1992         (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
1993         (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
1994         * runtime/JSString.h:
1995         (JSC::JSString::offsetOfFlags):
1996         (JSString):
1997         (JSRopeString):
1998         (JSC::JSRopeString::offsetOfFibers):
1999
2000 2013-03-18  Filip Pizlo  <fpizlo@apple.com>
2001
2002         JSC_NATIVE_FUNCTION() takes an identifier for the name and then uses #name, which is unsafe if name was already #define'd to something else
2003         https://bugs.webkit.org/show_bug.cgi?id=112639
2004
2005         Reviewed by Michael Saboff.
2006
2007         Change it to take a string instead.
2008
2009         * runtime/JSObject.h:
2010         (JSC):
2011         * runtime/ObjectPrototype.cpp:
2012         (JSC::ObjectPrototype::finishCreation):
2013         * runtime/StringPrototype.cpp:
2014         (JSC::StringPrototype::finishCreation):
2015
2016 2013-03-18  Brent Fulgham  <bfulgham@webkit.org>
2017
2018         [WinCairo] Get build working under VS2010.
2019         https://bugs.webkit.org/show_bug.cgi?id=112604
2020
2021         Reviewed by Tim Horton.
2022
2023         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Use CFLite-specific
2024         build target (standard version links against CoreFoundation.lib
2025         instead of CFLite.lib).
2026         * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Added.
2027         * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Added.
2028         * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Added.
2029
2030 2013-03-18  Roger Fong  <roger_fong@apple.com>
2031
2032         AppleWin VS2010 Debug configuration build fix..
2033
2034         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2035
2036 2013-03-18  Brent Fulgham  <bfulgham@webkit.org>
2037
2038         [WinCairo] Get build working under VS2010.
2039         https://bugs.webkit.org/show_bug.cgi?id=112604
2040
2041         Reviewed by Tim Horton.
2042
2043         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add build targets for
2044         Debug_WinCairo and Release_WinCairo using CFLite.
2045         * JavaScriptCore.vcxproj/JavaScriptCoreCFLite.props: Added.
2046         * JavaScriptCore.vcxproj/JavaScriptCoreDebugCFLite.props: Added.
2047         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExportGenerator.vcxproj:
2048         Add Debug_WinCairo and Release_WinCairo build targets to
2049         make sure headers are copied to proper build folder.
2050         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Ditto.
2051         * JavaScriptCore.vcxproj/JavaScriptCoreReleaseCFLite.props: Added.
2052         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
2053         Add Debug_WinCairo and Release_WinCairo build targets to
2054         make sure headers are copied to proper build folder.
2055         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
2056         Ditto.
2057         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
2058         Ditto.
2059         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Ditto.
2060         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Ditto.
2061         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Ditto.
2062
2063 2013-03-18  Michael Saboff  <msaboff@apple.com>
2064
2065         Potentially unsafe register allocations in DFG code generation
2066         https://bugs.webkit.org/show_bug.cgi?id=112477
2067
2068         Reviewed by Geoffrey Garen.
2069
2070         Moved allocation of temporary GPRs to be before any generated branches in the functions below.
2071
2072         * dfg/DFGSpeculativeJIT32_64.cpp:
2073         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
2074         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
2075         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
2076         * dfg/DFGSpeculativeJIT64.cpp:
2077         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
2078         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
2079         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
2080
2081 2013-03-15  Filip Pizlo  <fpizlo@apple.com>
2082
2083         DFG string conversions and allocations should be inlined
2084         https://bugs.webkit.org/show_bug.cgi?id=112376
2085
2086         Reviewed by Geoffrey Garen.
2087
2088         This turns new String(), String(), String.prototype.valueOf(), and
2089         String.prototype.toString() into intrinsics. It gives the DFG the ability to handle
2090         conversions from StringObject to JSString and vice-versa, and also gives it the
2091         ability to handle cases where a variable may be either a StringObject or a JSString.
2092         To do this, I added StringObject to value profiling (and removed the stale
2093         distinction between Myarguments and Foreignarguments). I also cleaned up ToPrimitive
2094         handling, using some of the new functionality but also taking advantage of the
2095         existence of Identity(String:@a).
2096
2097         This is a 2% SunSpider speed-up. Also there are some speed-ups on V8v7 and Kraken.
2098         On microbenchmarks that stress new String() this is a 14x speed-up.
2099
2100         * CMakeLists.txt:
2101         * DerivedSources.make:
2102         * DerivedSources.pri:
2103         * GNUmakefile.list.am:
2104         * bytecode/CodeBlock.h:
2105         (CodeBlock):
2106         (JSC::CodeBlock::hasExitSite):
2107         (JSC):
2108         * bytecode/DFGExitProfile.cpp:
2109         (JSC::DFG::ExitProfile::hasExitSite):
2110         (DFG):
2111         * bytecode/DFGExitProfile.h:
2112         (ExitProfile):
2113         (JSC::DFG::ExitProfile::hasExitSite):
2114         * bytecode/ExitKind.cpp:
2115         (JSC::exitKindToString):
2116         * bytecode/ExitKind.h:
2117         * bytecode/SpeculatedType.cpp:
2118         (JSC::dumpSpeculation):
2119         (JSC::speculationToAbbreviatedString):
2120         (JSC::speculationFromClassInfo):
2121         * bytecode/SpeculatedType.h:
2122         (JSC):
2123         (JSC::isStringObjectSpeculation):
2124         (JSC::isStringOrStringObjectSpeculation):
2125         * create_hash_table:
2126         * dfg/DFGAbstractState.cpp:
2127         (JSC::DFG::AbstractState::executeEffects):
2128         * dfg/DFGAbstractState.h:
2129         (JSC::DFG::AbstractState::filterEdgeByUse):
2130         * dfg/DFGByteCodeParser.cpp:
2131         (ByteCodeParser):
2132         (JSC::DFG::ByteCodeParser::handleCall):
2133         (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
2134         (DFG):
2135         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2136         * dfg/DFGCSEPhase.cpp:
2137         (JSC::DFG::CSEPhase::putStructureStoreElimination):
2138         * dfg/DFGEdge.h:
2139         (JSC::DFG::Edge::shift):
2140         * dfg/DFGFixupPhase.cpp:
2141         (JSC::DFG::FixupPhase::fixupNode):
2142         (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
2143         (FixupPhase):
2144         (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
2145         (JSC::DFG::FixupPhase::observeUseKindOnNode):
2146         * dfg/DFGGraph.h:
2147         (JSC::DFG::Graph::hasGlobalExitSite):
2148         (Graph):
2149         (JSC::DFG::Graph::hasExitSite):
2150         (JSC::DFG::Graph::clobbersWorld):
2151         * dfg/DFGNode.h:
2152         (JSC::DFG::Node::convertToToString):
2153         (Node):
2154         (JSC::DFG::Node::hasStructure):
2155         (JSC::DFG::Node::shouldSpeculateStringObject):
2156         (JSC::DFG::Node::shouldSpeculateStringOrStringObject):
2157         * dfg/DFGNodeType.h:
2158         (DFG):
2159         * dfg/DFGOperations.cpp:
2160         * dfg/DFGOperations.h:
2161         * dfg/DFGPredictionPropagationPhase.cpp:
2162         (JSC::DFG::PredictionPropagationPhase::propagate):
2163         * dfg/DFGSpeculativeJIT.cpp:
2164         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
2165         (DFG):
2166         (JSC::DFG::SpeculativeJIT::compileNewStringObject):
2167         (JSC::DFG::SpeculativeJIT::speculateObject):
2168         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
2169         (JSC::DFG::SpeculativeJIT::speculateString):
2170         (JSC::DFG::SpeculativeJIT::speculateStringObject):
2171         (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
2172         (JSC::DFG::SpeculativeJIT::speculate):
2173         * dfg/DFGSpeculativeJIT.h:
2174         (JSC::DFG::SpeculativeJIT::callOperation):
2175         (SpeculativeJIT):
2176         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
2177         (DFG):
2178         (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
2179         * dfg/DFGSpeculativeJIT32_64.cpp:
2180         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2181         (JSC::DFG::SpeculativeJIT::compile):
2182         * dfg/DFGSpeculativeJIT64.cpp:
2183         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2184         (JSC::DFG::SpeculativeJIT::compile):
2185         * dfg/DFGUseKind.cpp:
2186         (WTF::printInternal):
2187         * dfg/DFGUseKind.h:
2188         (JSC::DFG::typeFilterFor):
2189         * interpreter/CallFrame.h:
2190         (JSC::ExecState::regExpPrototypeTable):
2191         * runtime/CommonIdentifiers.h:
2192         * runtime/Intrinsic.h:
2193         * runtime/JSDestructibleObject.h:
2194         (JSDestructibleObject):
2195         (JSC::JSDestructibleObject::classInfoOffset):
2196         * runtime/JSGlobalData.cpp:
2197         (JSC):
2198         (JSC::JSGlobalData::JSGlobalData):
2199         (JSC::JSGlobalData::~JSGlobalData):
2200         * runtime/JSGlobalData.h:
2201         (JSGlobalData):
2202         * runtime/JSObject.cpp:
2203         * runtime/JSObject.h:
2204         (JSC):
2205         * runtime/JSWrapperObject.h:
2206         (JSC::JSWrapperObject::allocationSize):
2207         (JSWrapperObject):
2208         (JSC::JSWrapperObject::internalValueOffset):
2209         (JSC::JSWrapperObject::internalValueCellOffset):
2210         * runtime/StringPrototype.cpp:
2211         (JSC):
2212         (JSC::StringPrototype::finishCreation):
2213         (JSC::StringPrototype::create):
2214         * runtime/StringPrototype.h:
2215         (StringPrototype):
2216
2217 2013-03-18  Filip Pizlo  <fpizlo@apple.com>
2218
2219         ObjectPrototype properties should be eagerly created rather than lazily via static tables
2220         https://bugs.webkit.org/show_bug.cgi?id=112539
2221
2222         Reviewed by Oliver Hunt.
2223
2224         This is the first part of https://bugs.webkit.org/show_bug.cgi?id=112233. Rolling this
2225         in first since it's the less-likely-to-be-broken part.
2226
2227         * CMakeLists.txt:
2228         * DerivedSources.make:
2229         * DerivedSources.pri:
2230         * GNUmakefile.list.am:
2231         * interpreter/CallFrame.h:
2232         (JSC::ExecState::objectConstructorTable):
2233         * runtime/CommonIdentifiers.h:
2234         * runtime/JSGlobalData.cpp:
2235         (JSC):
2236         (JSC::JSGlobalData::JSGlobalData):
2237         (JSC::JSGlobalData::~JSGlobalData):
2238         * runtime/JSGlobalData.h:
2239         (JSGlobalData):
2240         * runtime/JSObject.cpp:
2241         (JSC::JSObject::putDirectNativeFunction):
2242         (JSC):
2243         * runtime/JSObject.h:
2244         (JSObject):
2245         (JSC):
2246         * runtime/Lookup.cpp:
2247         (JSC::setUpStaticFunctionSlot):
2248         * runtime/ObjectPrototype.cpp:
2249         (JSC):
2250         (JSC::ObjectPrototype::finishCreation):
2251         (JSC::ObjectPrototype::create):
2252         * runtime/ObjectPrototype.h:
2253         (ObjectPrototype):
2254
2255 2013-03-16  Pratik Solanki  <psolanki@apple.com>
2256
2257         Disable High DPI Canvas on iOS
2258         https://bugs.webkit.org/show_bug.cgi?id=112511
2259
2260         Reviewed by Joseph Pecoraro.
2261
2262         * Configurations/FeatureDefines.xcconfig:
2263
2264 2013-03-15  Andreas Kling  <akling@apple.com>
2265
2266         Don't also clone StructureRareData when cloning Structure.
2267         <http://webkit.org/b/111672>
2268
2269         Reviewed by Mark Hahnenberg.
2270
2271         We were cloning a lot of StructureRareData with only the previousID pointer set since
2272         the enumerationCache is not shared between clones.
2273
2274         Let the Structure copy constructor decide whether it wants to clone the rare data.
2275         The decision is made by StructureRareData::needsCloning() and will currently always
2276         return false, since StructureRareData only holds on to caches at present.
2277         This may change in the future as more members are added to StructureRareData.
2278
2279         * runtime/Structure.cpp:
2280         (JSC::Structure::Structure):
2281         (JSC::Structure::cloneRareDataFrom):
2282         * runtime/StructureInlines.h:
2283         (JSC::Structure::create):
2284
2285 2013-03-15  Mark Hahnenberg  <mhahnenberg@apple.com>
2286
2287         Roll out r145838
2288         https://bugs.webkit.org/show_bug.cgi?id=112458
2289
2290         Unreviewed. Requested by Filip Pizlo.
2291
2292         * CMakeLists.txt:
2293         * DerivedSources.make:
2294         * DerivedSources.pri:
2295         * GNUmakefile.list.am:
2296         * dfg/DFGOperations.cpp:
2297         * interpreter/CallFrame.h:
2298         (JSC::ExecState::objectPrototypeTable):
2299         * jit/JITStubs.cpp:
2300         (JSC::getByVal):
2301         * llint/LLIntSlowPaths.cpp:
2302         (JSC::LLInt::getByVal):
2303         * runtime/CommonIdentifiers.h:
2304         * runtime/JSCell.cpp:
2305         (JSC):
2306         * runtime/JSCell.h:
2307         (JSCell):
2308         * runtime/JSCellInlines.h:
2309         (JSC):
2310         (JSC::JSCell::fastGetOwnProperty):
2311         * runtime/JSGlobalData.cpp:
2312         (JSC):
2313         (JSC::JSGlobalData::JSGlobalData):
2314         (JSC::JSGlobalData::~JSGlobalData):
2315         * runtime/JSGlobalData.h:
2316         (JSGlobalData):
2317         * runtime/JSObject.cpp:
2318         (JSC):
2319         * runtime/JSObject.h:
2320         (JSObject):
2321         (JSC):
2322         * runtime/Lookup.cpp:
2323         (JSC::setUpStaticFunctionSlot):
2324         * runtime/ObjectPrototype.cpp:
2325         (JSC):
2326         (JSC::ObjectPrototype::finishCreation):
2327         (JSC::ObjectPrototype::getOwnPropertySlot):
2328         (JSC::ObjectPrototype::getOwnPropertyDescriptor):
2329         * runtime/ObjectPrototype.h:
2330         (JSC::ObjectPrototype::create):
2331         (ObjectPrototype):
2332         * runtime/PropertyMapHashTable.h:
2333         (JSC::PropertyTable::findWithString):
2334         * runtime/Structure.h:
2335         (Structure):
2336         * runtime/StructureInlines.h:
2337         (JSC::Structure::get):
2338
2339 2013-03-15  Michael Saboff  <msaboff@apple.com>
2340
2341         Cleanup of DFG and Baseline JIT debugging code
2342         https://bugs.webkit.org/show_bug.cgi?id=111871
2343
2344         Reviewed by Geoffrey Garen.
2345
2346         Fixed various debug related issue in baseline and DFG JITs. See below.
2347
2348         * dfg/DFGRepatch.cpp:
2349         (JSC::DFG::dfgLinkClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL.
2350         * dfg/DFGScratchRegisterAllocator.h: Now use ScratchBuffer::activeLengthPtr() to get
2351         pointer to scratch register length.
2352         (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer):
2353         (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer):
2354         * dfg/DFGSpeculativeJIT.cpp:
2355         (JSC::DFG::SpeculativeJIT::checkConsistency): Added missing case labels for DataFormatOSRMarker,
2356         DataFormatDead, and DataFormatArguments and made them RELEASE_ASSERT_NOT_REACHED();
2357         * jit/JITCall.cpp:
2358         (JSC::JIT::privateCompileClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL.
2359         * jit/JITCall32_64.cpp:
2360         (JSC::JIT::privateCompileClosureCall): Used pointerDump() to handle when calleeCodeBlock is NULL.
2361         * runtime/JSGlobalData.h:
2362         (JSC::ScratchBuffer::ScratchBuffer): Fixed buffer allocation alignment to
2363         be on a double boundary.
2364         (JSC::ScratchBuffer::setActiveLength):
2365         (JSC::ScratchBuffer::activeLength):
2366         (JSC::ScratchBuffer::activeLengthPtr):
2367
2368 2013-03-15  Michael Saboff  <msaboff@apple.com>
2369
2370         Add runtime check for improper register allocations in DFG
2371         https://bugs.webkit.org/show_bug.cgi?id=112380
2372
2373         Reviewed by Geoffrey Garen.
2374
2375         Added framework to check for register allocation within a branch source - target range.  All register allocations
2376         are saved using the offset in the code stream where the allocation occurred.  Later when a jump is linked, the
2377         currently saved register allocations are checked to make sure that they didn't occur in the range of code that was
2378         jumped over.  This protects against the case where an allocation could have spilled register contents to free up
2379         a register and that spill only occurs on one path of a many through the code.  A subsequent fill of the spilled
2380         register may load garbage.  See https://bugs.webkit.org/show_bug.cgi?id=111777 for one such bug.
2381         This code is protected by the compile time check of #if ENABLE(DFG_REGISTER_ALLOCATION_VALIDATION).
2382         The check is only done during the processing of SpeculativeJIT::compile(Node* node) and its callees.
2383
2384         * assembler/AbstractMacroAssembler.h:
2385         (JSC::AbstractMacroAssembler::Jump::link): Invoke register allocation checks using source and target of link.
2386         (JSC::AbstractMacroAssembler::Jump::linkTo): Invoke register allocation checks using source and target of link.
2387         (AbstractMacroAssembler):
2388         (RegisterAllocationOffset): New helper class to store the instruction stream offset and compare against a
2389         jump range.
2390         (JSC::AbstractMacroAssembler::RegisterAllocationOffset::RegisterAllocationOffset):
2391         (JSC::AbstractMacroAssembler::RegisterAllocationOffset::check):
2392         (JSC::AbstractMacroAssembler::addRegisterAllocationAtOffset):
2393         (JSC::AbstractMacroAssembler::clearRegisterAllocationOffsets):
2394         (JSC::AbstractMacroAssembler::checkRegisterAllocationAgainstBranchRange):
2395         * dfg/DFGSpeculativeJIT.h:
2396         (JSC::DFG::SpeculativeJIT::allocate):
2397         * dfg/DFGSpeculativeJIT32_64.cpp:
2398         (JSC::DFG::SpeculativeJIT::compile):
2399         * dfg/DFGSpeculativeJIT64.cpp:
2400         (JSC::DFG::SpeculativeJIT::compile):
2401
2402 2013-03-14  Oliver Hunt  <oliver@apple.com>
2403
2404         REGRESSION(r145000): Crash loading arstechnica.com when Safari Web Inspector is open
2405         https://bugs.webkit.org/show_bug.cgi?id=111868
2406
2407         Reviewed by Antti Koivisto.
2408
2409         Don't allow non-local property lookup when the debugger is enabled.
2410
2411         * bytecompiler/BytecodeGenerator.cpp:
2412         (JSC::BytecodeGenerator::resolve):
2413
2414 2013-03-11  Mark Hahnenberg  <mhahnenberg@apple.com>
2415
2416         Objective-C API: Objective-C functions exposed to JavaScript have the wrong type (object instead of function)
2417         https://bugs.webkit.org/show_bug.cgi?id=105892
2418
2419         Reviewed by Geoffrey Garen.
2420
2421         Changed ObjCCallbackFunction to subclass JSCallbackFunction which already has all of the machinery to call
2422         functions using the C API. Since ObjCCallbackFunction is now a JSCell, we changed the old implementation of
2423         ObjCCallbackFunction to be the internal implementation and keep track of all the proper data so that we
2424         don't have to put all of that in the header, which will now be included from C++ files (e.g. JSGlobalObject.cpp).
2425
2426         * API/JSCallbackFunction.cpp: Change JSCallbackFunction to allow subclassing. Originally it was internally
2427         passing its own Structure up the chain of constructors, but we now want to be able to pass other Structures as well.
2428         (JSC::JSCallbackFunction::JSCallbackFunction):
2429         (JSC::JSCallbackFunction::create):
2430         * API/JSCallbackFunction.h:
2431         (JSCallbackFunction):
2432         * API/JSWrapperMap.mm: Changed interface to tryUnwrapBlock.
2433         (tryUnwrapObjcObject):
2434         * API/ObjCCallbackFunction.h:
2435         (ObjCCallbackFunction): Moved into the JSC namespace, just like JSCallbackFunction.
2436         (JSC::ObjCCallbackFunction::createStructure): Overridden so that the correct ClassInfo gets used since we have
2437         a destructor.
2438         (JSC::ObjCCallbackFunction::impl): Getter for the internal impl.
2439         * API/ObjCCallbackFunction.mm:
2440         (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): What used to be ObjCCallbackFunction is now
2441         ObjCCallbackFunctionImpl. It handles the Objective-C specific parts of managing callback functions.
2442         (JSC::ObjCCallbackFunctionImpl::~ObjCCallbackFunctionImpl):
2443         (JSC::objCCallbackFunctionCallAsFunction): Same as the old one, but now it casts to ObjCCallbackFunction and grabs the impl
2444         rather than using JSObjectGetPrivate.
2445         (JSC::ObjCCallbackFunction::ObjCCallbackFunction): New bits to allow being part of the JSCell hierarchy.
2446         (JSC::ObjCCallbackFunction::create):
2447         (JSC::ObjCCallbackFunction::destroy):
2448         (JSC::ObjCCallbackFunctionImpl::call): Handles the actual invocation, just like it used to.
2449         (objCCallbackFunctionForInvocation):
2450         (tryUnwrapBlock): Changed to check the ClassInfo for inheritance directly, rather than going through the C API call.
2451         * API/tests/testapi.mm: Added new test to make sure that doing Function.prototype.toString.call(f) won't result in
2452         an error when f is an Objective-C method or block underneath the covers.
2453         * runtime/JSGlobalObject.cpp: Added new Structure for ObjCCallbackFunction.
2454         (JSC::JSGlobalObject::reset):
2455         (JSC::JSGlobalObject::visitChildren):
2456         * runtime/JSGlobalObject.h:
2457         (JSGlobalObject):
2458         (JSC::JSGlobalObject::objcCallbackFunctionStructure):
2459
2460 2013-03-14  Mark Hahnenberg  <mhahnenberg@apple.com>
2461
2462         Objective-C API: Nested dictionaries are not converted properly in the Objective-C binding
2463         https://bugs.webkit.org/show_bug.cgi?id=112377
2464
2465         Reviewed by Oliver Hunt.
2466
2467         Accidental reassignment of the root task in the container conversion logic was causing the last
2468         array or dictionary processed to be returned in the case of nested containers.
2469
2470         * API/JSValue.mm:
2471         (containerValueToObject):
2472         * API/tests/testapi.mm:
2473
2474 2013-03-13  Filip Pizlo  <fpizlo@apple.com>
2475
2476         JSObject fast by-string access optimizations should work even on the prototype chain, and even when the result is undefined
2477         https://bugs.webkit.org/show_bug.cgi?id=112233
2478
2479         Reviewed by Oliver Hunt.
2480
2481         Extended the existing fast access path for String keys to work over the entire prototype chain,
2482         not just the self access case. This will fail as soon as it sees an object that intercepts
2483         getOwnPropertySlot, so this patch also ensures that ObjectPrototype does not fall into that
2484         category. This is accomplished by making ObjectPrototype eagerly reify all of its properties.
2485         This is safe for ObjectPrototype because it's so common and we expect all of its properties to
2486         be reified for any interesting programs anyway. A new idiom for adding native functions to
2487         prototypes is introduced, which ought to work well for any other prototypes that we wish to do
2488         this conversion for.
2489
2490         This is a >60% speed-up in the case that you frequently do by-string lookups that "miss", i.e.
2491         they don't turn up anything.
2492
2493         * CMakeLists.txt:
2494         * DerivedSources.make:
2495         * DerivedSources.pri:
2496         * GNUmakefile.list.am:
2497         * dfg/DFGOperations.cpp:
2498         * interpreter/CallFrame.h:
2499         (JSC::ExecState::objectConstructorTable):
2500         * jit/JITStubs.cpp:
2501         (JSC::getByVal):
2502         * llint/LLIntSlowPaths.cpp:
2503         (JSC::LLInt::getByVal):
2504         * runtime/CommonIdentifiers.h:
2505         * runtime/JSCell.cpp:
2506         (JSC::JSCell::getByStringSlow):
2507         (JSC):
2508         * runtime/JSCell.h:
2509         (JSCell):
2510         * runtime/JSCellInlines.h:
2511         (JSC):
2512         (JSC::JSCell::getByStringAndKey):
2513         (JSC::JSCell::getByString):
2514         * runtime/JSGlobalData.cpp:
2515         (JSC):
2516         (JSC::JSGlobalData::JSGlobalData):
2517         (JSC::JSGlobalData::~JSGlobalData):
2518         * runtime/JSGlobalData.h:
2519         (JSGlobalData):
2520         * runtime/JSObject.cpp:
2521         (JSC::JSObject::putDirectNativeFunction):
2522         (JSC):
2523         * runtime/JSObject.h:
2524         (JSObject):
2525         (JSC):
2526         * runtime/Lookup.cpp:
2527         (JSC::setUpStaticFunctionSlot):
2528         * runtime/ObjectPrototype.cpp:
2529         (JSC):
2530         (JSC::ObjectPrototype::finishCreation):
2531         (JSC::ObjectPrototype::create):
2532         * runtime/ObjectPrototype.h:
2533         (ObjectPrototype):
2534         * runtime/PropertyMapHashTable.h:
2535         (JSC::PropertyTable::findWithString):
2536         * runtime/Structure.h:
2537         (Structure):
2538         * runtime/StructureInlines.h:
2539         (JSC::Structure::get):
2540         (JSC):
2541
2542 2013-03-13  Filip Pizlo  <fpizlo@apple.com>
2543
2544         DFG bytecode parser is too aggressive about getting rid of GetLocals on captured variables
2545         https://bugs.webkit.org/show_bug.cgi?id=112287
2546         <rdar://problem/13342340>
2547
2548         Reviewed by Oliver Hunt.
2549
2550         * bytecode/CodeBlock.cpp:
2551         (JSC::CodeBlock::dumpBytecode):
2552         (JSC::CodeBlock::finalizeUnconditionally):
2553         * dfg/DFGByteCodeParser.cpp:
2554         (JSC::DFG::ByteCodeParser::getLocal):
2555
2556 2013-03-13  Ryosuke Niwa  <rniwa@webkit.org>
2557
2558         Threaded HTML Parser is missing feature define flags in all but Chromium port's build files
2559         https://bugs.webkit.org/show_bug.cgi?id=112277
2560
2561         Reviewed by Adam Barth.
2562
2563         * Configurations/FeatureDefines.xcconfig:
2564
2565 2013-03-13  Csaba Osztrogonác  <ossy@webkit.org>
2566
2567         LLINT C loop warning fix for GCC
2568         https://bugs.webkit.org/show_bug.cgi?id=112145
2569
2570         Reviewed by Filip Pizlo.
2571
2572         * llint/LowLevelInterpreter.cpp:
2573         (JSC::CLoop::execute):
2574
2575 2013-02-13  Simon Hausmann  <simon.hausmann@digia.com>
2576
2577         Add support for convenient conversion from JSStringRef to QString
2578         https://bugs.webkit.org/show_bug.cgi?id=109694
2579
2580         Reviewed by Allan Sandfeld Jensen.
2581
2582         Add JSStringCopyQString helper function that allows for the convenient
2583         extraction of a QString out of a JSStringRef.
2584
2585         * API/JSStringRefQt.cpp: Added.
2586         (JSStringCopyQString):
2587         * API/JSStringRefQt.h: Added.
2588         * API/OpaqueJSString.h:
2589         (OpaqueJSString):
2590         (OpaqueJSString::qString):
2591         (OpaqueJSString::OpaqueJSString):
2592         * Target.pri:
2593
2594 2013-03-13  Peter Gal  <galpeter@inf.u-szeged.hu>
2595
2596         Token 'not' is ignored in the offlineasm.
2597         https://bugs.webkit.org/show_bug.cgi?id=111568
2598
2599         Reviewed by Filip Pizlo.
2600
2601         * offlineasm/parser.rb: Build the Not AST node if the 'not' token is found.
2602
2603 2013-03-12  Tim Horton  <timothy_horton@apple.com>
2604
2605         WTF uses macros for exports. Try to fix the Windows build. Unreviewed.
2606
2607         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
2608         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
2609
2610 2013-03-12  Filip Pizlo  <fpizlo@apple.com>
2611
2612         Array.prototype.sort should at least try to be PTIME even when the array is in some bizarre mode
2613         https://bugs.webkit.org/show_bug.cgi?id=112187
2614         <rdar://problem/13393550>
2615
2616         Reviewed by Michael Saboff and Gavin Barraclough.
2617
2618         If we have an array-like object in crazy mode passed into Array.prototype.sort, and its length is large,
2619         then first copy all elements into a separate, compact, un-holy array and sort that. Then copy back.
2620         This means that sorting will be at worst O(n^2) in the actual number of things in the array, rather than
2621         O(n^2) in the array's length.
2622
2623         * runtime/ArrayPrototype.cpp:
2624         (JSC::attemptFastSort):
2625         (JSC::performSlowSort):
2626         (JSC):
2627         (JSC::arrayProtoFuncSort):
2628
2629 2013-03-12  Tim Horton  <timothy_horton@apple.com>
2630
2631         Try to fix the Windows build.
2632
2633         Not reviewed.
2634
2635         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
2636
2637 2013-03-12  Geoffrey Garen  <ggaren@apple.com>
2638
2639         Try to fix the Windows build.
2640
2641         Not reviewed.
2642
2643         * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
2644         Export a thing.
2645
2646 2013-03-11  Oliver Hunt  <oliver@apple.com>
2647
2648         Harden JSStringJoiner
2649         https://bugs.webkit.org/show_bug.cgi?id=112093
2650
2651         Reviewed by Filip Pizlo.
2652
2653         Harden JSStringJoiner, make it use our CheckedArithmetic
2654         class to simplify everything.
2655
2656         * runtime/JSStringJoiner.cpp:
2657         (JSC::JSStringJoiner::build):
2658         * runtime/JSStringJoiner.h:
2659         (JSStringJoiner):
2660         (JSC::JSStringJoiner::JSStringJoiner):
2661         (JSC::JSStringJoiner::append):
2662
2663 2013-03-12  Filip Pizlo  <fpizlo@apple.com>
2664
2665         DFG generic array access cases should not be guarded by CheckStructure even of the profiling tells us that it could be
2666         https://bugs.webkit.org/show_bug.cgi?id=112183
2667
2668         Reviewed by Oliver Hunt.
2669
2670         Slight speed-up on string-unpack-code.
2671
2672         * dfg/DFGFixupPhase.cpp:
2673         (JSC::DFG::FixupPhase::findAndRemoveUnnecessaryStructureCheck):
2674         (FixupPhase):
2675         (JSC::DFG::FixupPhase::checkArray):
2676         (JSC::DFG::FixupPhase::blessArrayOperation):
2677
2678 2013-03-12  Gabor Rapcsanyi  <rgabor@webkit.org>
2679
2680         https://bugs.webkit.org/show_bug.cgi?id=112141
2681         LLInt CLoop backend misses Double2Ints() on 32bit architectures
2682
2683         Reviewed by Filip Pizlo.
2684
2685         Implement Double2Ints() in CLoop backend of LLInt on 32bit architectures.
2686
2687         * llint/LowLevelInterpreter.cpp:
2688         (LLInt):
2689         (JSC::LLInt::Double2Ints):
2690         * offlineasm/cloop.rb:
2691
2692 2013-03-12  Gabor Rapcsanyi  <rgabor@webkit.org>
2693
2694         Making more sophisticated cache flush on ARM Linux platform
2695         https://bugs.webkit.org/show_bug.cgi?id=111854
2696
2697         Reviewed by Zoltan Herczeg.
2698
2699         The cache flush on ARM Linux invalidates whole pages
2700         instead of just the required area.
2701
2702         * assembler/ARMAssembler.h:
2703         (ARMAssembler):
2704         (JSC::ARMAssembler::linuxPageFlush):
2705         (JSC::ARMAssembler::cacheFlush):
2706         * assembler/ARMv7Assembler.h:
2707         (ARMv7Assembler):
2708         (JSC::ARMv7Assembler::linuxPageFlush):
2709         (JSC::ARMv7Assembler::cacheFlush):
2710
2711 2013-03-12  Gabor Rapcsanyi  <rgabor@webkit.org>
2712
2713         Renaming the armv7.rb LLINT backend to arm.rb
2714         https://bugs.webkit.org/show_bug.cgi?id=110565
2715
2716         Reviewed by Zoltan Herczeg.
2717
2718         This is the first step of a unified ARM backend for
2719         all ARM 32 bit architectures in LLInt.
2720
2721         * CMakeLists.txt:
2722         * GNUmakefile.list.am:
2723         * JavaScriptCore.gypi:
2724         * LLIntOffsetsExtractor.pro:
2725         * offlineasm/arm.rb: Copied from Source/JavaScriptCore/offlineasm/armv7.rb.
2726         * offlineasm/armv7.rb: Removed.
2727         * offlineasm/backends.rb:
2728         * offlineasm/risc.rb:
2729
2730 2013-03-12  Csaba Osztrogonác  <ossy@webkit.org>
2731
2732         REGRESSION(r145482): It broke 33 jsc tests and zillion layout tests on all platform
2733         https://bugs.webkit.org/show_bug.cgi?id=112112
2734
2735         Reviewed by Oliver Hunt.
2736
2737         Rolling out https://trac.webkit.org/changeset/145482 to unbreak the bots.
2738
2739         * runtime/JSStringJoiner.cpp:
2740         (JSC::JSStringJoiner::build):
2741         * runtime/JSStringJoiner.h:
2742         (JSStringJoiner):
2743         (JSC::JSStringJoiner::JSStringJoiner):
2744         (JSC::JSStringJoiner::append):
2745
2746 2013-03-12  Filip Pizlo  <fpizlo@apple.com>
2747
2748         DFG prediction propagation phase should not rerun forward propagation if double voting has already converged
2749         https://bugs.webkit.org/show_bug.cgi?id=111920
2750
2751         Reviewed by Oliver Hunt.
2752
2753         I don't know why we weren't exiting early after double voting if !m_changed.
2754
2755         This change also removes backwards propagation from the voting fixpoint, since at that
2756         point short-circuiting loops is probably not particularly profitable. Profiling shows
2757         that this reduces the time spent in prediction propagation even further.
2758
2759         This change appears to be a 1% SunSpider speed-up.
2760
2761         * dfg/DFGPredictionPropagationPhase.cpp:
2762         (JSC::DFG::PredictionPropagationPhase::run):
2763
2764 2013-03-11  Filip Pizlo  <fpizlo@apple.com>
2765
2766         DFG overflow check elimination is too smart for its own good
2767         https://bugs.webkit.org/show_bug.cgi?id=111832
2768
2769         Reviewed by Oliver Hunt and Gavin Barraclough.
2770
2771         Rolling this back in after fixing accidental misuse of JSValue. The code was doing value < someInt
2772         rather than value.asInt32() < someInt. This "worked" when isWithinPowerOfTwo wasn't templatized.
2773         It worked by always being false and always disabling the relvant optimization.
2774
2775         This improves overflow check elimination in three ways:
2776
2777         1) It reduces the amount of time the compiler will spend doing it.
2778
2779         2) It fixes bugs where overflow check elimination was overzealous. Precisely, for a binary operation
2780            over @a and @b where both @a and @b will type check that their inputs (@a->children, @b->children)
2781            are int32's and then perform a possibly-overflowing operation, we must be careful not to assume
2782            that @a's non-int32 parts don't matter if at the point that @a runs we have as yet not proved that
2783            @b->children are int32's and that hence @b might produce a large enough result that doubles would
2784            start chopping low bits. The specific implication of this is that for a binary operation to not
2785            propagate that it cares about non-int32 parts (NodeUsedAsNumber), we must prove that at least one
2786            of the inputs is guaranteed to produce a result within 2^32 and that there won't be a tower of such
2787            operations large enough to ultimately produce a double greater than 2^52 (roughly). We achieve the
2788            latter by disabling this optimization for very large basic blocks. It's noteworthy that blocks that
2789            large won't even make it into the DFG currently.
2790
2791         3) It makes the overflow check elimination more precise for cases where the inputs to an Add or Sub
2792            are the outputs of a bit-op. For example in (@a + (@b | 0)) | 0, we don't need to propagate
2793            NodeUsedAsNumber to either @a or @b.
2794
2795         This is neutral on V8v7 and a slight speed-up on compile time benchmarks.
2796
2797         * CMakeLists.txt:
2798         * GNUmakefile.list.am:
2799         * JavaScriptCore.xcodeproj/project.pbxproj:
2800         * Target.pri:
2801         * dfg/DFGArrayMode.cpp:
2802         (JSC::DFG::ArrayMode::refine):
2803         * dfg/DFGBackwardsPropagationPhase.cpp: Added.
2804         (DFG):
2805         (BackwardsPropagationPhase):
2806         (JSC::DFG::BackwardsPropagationPhase::BackwardsPropagationPhase):
2807         (JSC::DFG::BackwardsPropagationPhase::run):
2808         (JSC::DFG::BackwardsPropagationPhase::isNotNegZero):
2809         (JSC::DFG::BackwardsPropagationPhase::isNotZero):
2810         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoForConstant):
2811         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoNonRecursive):
2812         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
2813         (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags):
2814         (JSC::DFG::BackwardsPropagationPhase::propagate):
2815         (JSC::DFG::performBackwardsPropagation):
2816         * dfg/DFGBackwardsPropagationPhase.h: Added.
2817         (DFG):
2818         * dfg/DFGCPSRethreadingPhase.cpp:
2819         (JSC::DFG::CPSRethreadingPhase::run):
2820         (JSC::DFG::CPSRethreadingPhase::clearIsLoadedFrom):
2821         (CPSRethreadingPhase):
2822         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2823         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
2824         * dfg/DFGDriver.cpp:
2825         (JSC::DFG::compile):
2826         * dfg/DFGGraph.cpp:
2827         (JSC::DFG::Graph::dump):
2828         * dfg/DFGNodeFlags.cpp:
2829         (JSC::DFG::dumpNodeFlags):
2830         (DFG):
2831         * dfg/DFGNodeFlags.h:
2832         (DFG):
2833         * dfg/DFGPredictionPropagationPhase.cpp:
2834         (PredictionPropagationPhase):
2835         (JSC::DFG::PredictionPropagationPhase::propagate):
2836         * dfg/DFGUnificationPhase.cpp:
2837         (JSC::DFG::UnificationPhase::run):
2838         * dfg/DFGVariableAccessData.h:
2839         (JSC::DFG::VariableAccessData::VariableAccessData):
2840         (JSC::DFG::VariableAccessData::mergeIsLoadedFrom):
2841         (VariableAccessData):
2842         (JSC::DFG::VariableAccessData::setIsLoadedFrom):
2843         (JSC::DFG::VariableAccessData::isLoadedFrom):
2844
2845 2013-03-11  Oliver Hunt  <oliver@apple.com>
2846
2847         Harden JSStringJoiner
2848         https://bugs.webkit.org/show_bug.cgi?id=112093
2849
2850         Reviewed by Filip Pizlo.
2851
2852         Harden JSStringJoiner, make it use our CheckedArithmetic
2853         class to simplify everything.
2854
2855         * runtime/JSStringJoiner.cpp:
2856         (JSC::JSStringJoiner::build):
2857         * runtime/JSStringJoiner.h:
2858         (JSStringJoiner):
2859         (JSC::JSStringJoiner::JSStringJoiner):
2860         (JSC::JSStringJoiner::append):
2861
2862 2013-03-11  Michael Saboff  <msaboff@apple.com>
2863
2864         Crash beneath operationCreateInlinedArguments running fast/js/dfg-create-inlined-arguments-in-closure-inline.html (32-bit only)
2865         https://bugs.webkit.org/show_bug.cgi?id=112067
2866
2867         Reviewed by Geoffrey Garen.
2868
2869         We weren't setting the tag in SetCallee.  Therefore set it to CellTag.
2870
2871         * dfg/DFGSpeculativeJIT32_64.cpp:
2872         (JSC::DFG::SpeculativeJIT::compile):
2873
2874 2013-03-11  Oliver Hunt  <oliver@apple.com>
2875
2876         Make SegmentedVector Noncopyable
2877         https://bugs.webkit.org/show_bug.cgi?id=112059
2878
2879         Reviewed by Geoffrey Garen.
2880
2881         Copying a SegmentedVector is very expensive, and really shouldn't
2882         be necessary.  So I've taken the one place where we currently copy
2883         and replaced it with a regular Vector, and replaced the address
2884         dependent logic with a indexing ref instead.
2885
2886         * bytecompiler/BytecodeGenerator.cpp:
2887         (JSC::BytecodeGenerator::newLabelScope):
2888         (JSC::BytecodeGenerator::emitComplexJumpScopes):
2889         * bytecompiler/BytecodeGenerator.h:
2890         (BytecodeGenerator):
2891         * bytecompiler/LabelScope.h:
2892         (JSC):
2893         (JSC::LabelScopePtr::LabelScopePtr):
2894         (LabelScopePtr):
2895         (JSC::LabelScopePtr::operator=):
2896         (JSC::LabelScopePtr::~LabelScopePtr):
2897         (JSC::LabelScopePtr::operator*):
2898         (JSC::LabelScopePtr::operator->):
2899         * bytecompiler/NodesCodegen.cpp:
2900         (JSC::DoWhileNode::emitBytecode):
2901         (JSC::WhileNode::emitBytecode):
2902         (JSC::ForNode::emitBytecode):
2903         (JSC::ForInNode::emitBytecode):
2904         (JSC::SwitchNode::emitBytecode):
2905         (JSC::LabelNode::emitBytecode):
2906
2907 2013-03-10  Andreas Kling  <akling@apple.com>
2908
2909         SpeculativeJIT should use OwnPtr<SlowPathGenerator>.
2910         <http://webkit.org/b/111942>
2911
2912         Reviewed by Anders Carlsson.
2913
2914         There's no need to include DFGSlowPathGenerator.h from the header as long as the destructor is out-of-line,
2915         so let's use OwnPtr instead of raw pointers + deleteAllValues().
2916
2917         * dfg/DFGSpeculativeJIT.cpp:
2918         (JSC::DFG::SpeculativeJIT::~SpeculativeJIT):
2919         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
2920         * dfg/DFGSpeculativeJIT.h:
2921         (SpeculativeJIT):
2922
2923 2013-03-09  Sheriff Bot  <webkit.review.bot@gmail.com>
2924
2925         Unreviewed, rolling out r145299.
2926         http://trac.webkit.org/changeset/145299
2927         https://bugs.webkit.org/show_bug.cgi?id=111928
2928
2929         compilation failure with recent clang
2930         (DFGBackwardsPropagationPhase.cpp:132:35: error: comparison of
2931         constant 10 with expression of type 'bool' is always false)
2932         (Requested by thorton on #webkit).
2933
2934         * CMakeLists.txt:
2935         * GNUmakefile.list.am:
2936         * JavaScriptCore.xcodeproj/project.pbxproj:
2937         * Target.pri:
2938         * dfg/DFGArrayMode.cpp:
2939         (JSC::DFG::ArrayMode::refine):
2940         * dfg/DFGBackwardsPropagationPhase.cpp: Removed.
2941         * dfg/DFGBackwardsPropagationPhase.h: Removed.
2942         * dfg/DFGCPSRethreadingPhase.cpp:
2943         (JSC::DFG::CPSRethreadingPhase::run):
2944         (CPSRethreadingPhase):
2945         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2946         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
2947         * dfg/DFGDriver.cpp:
2948         (JSC::DFG::compile):
2949         * dfg/DFGGraph.cpp:
2950         (JSC::DFG::Graph::dump):
2951         * dfg/DFGNodeFlags.cpp:
2952         (JSC::DFG::nodeFlagsAsString):
2953         (DFG):
2954         * dfg/DFGNodeFlags.h:
2955         (DFG):
2956         * dfg/DFGPredictionPropagationPhase.cpp:
2957         (JSC::DFG::PredictionPropagationPhase::isNotNegZero):
2958         (PredictionPropagationPhase):
2959         (JSC::DFG::PredictionPropagationPhase::isNotZero):
2960         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoForConstant):
2961         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwoNonRecursive):
2962         (JSC::DFG::PredictionPropagationPhase::isWithinPowerOfTwo):
2963         (JSC::DFG::PredictionPropagationPhase::propagate):
2964         (JSC::DFG::PredictionPropagationPhase::mergeDefaultFlags):
2965         * dfg/DFGUnificationPhase.cpp:
2966         (JSC::DFG::UnificationPhase::run):
2967         * dfg/DFGVariableAccessData.h:
2968         (JSC::DFG::VariableAccessData::VariableAccessData):
2969         (VariableAccessData):
2970
2971 2013-03-08  Filip Pizlo  <fpizlo@apple.com>
2972
2973         DFG overflow check elimination is too smart for its own good
2974         https://bugs.webkit.org/show_bug.cgi?id=111832
2975
2976         Reviewed by Oliver Hunt and Gavin Barraclough.
2977
2978         This improves overflow check elimination in three ways:
2979
2980         1) It reduces the amount of time the compiler will spend doing it.
2981
2982         2) It fixes bugs where overflow check elimination was overzealous. Precisely, for a binary operation
2983            over @a and @b where both @a and @b will type check that their inputs (@a->children, @b->children)
2984            are int32's and then perform a possibly-overflowing operation, we must be careful not to assume
2985            that @a's non-int32 parts don't matter if at the point that @a runs we have as yet not proved that
2986            @b->children are int32's and that hence @b might produce a large enough result that doubles would
2987            start chopping low bits. The specific implication of this is that for a binary operation to not
2988            propagate that it cares about non-int32 parts (NodeUsedAsNumber), we must prove that at least one
2989            of the inputs is guaranteed to produce a result within 2^32 and that there won't be a tower of such
2990            operations large enough to ultimately produce a double greater than 2^52 (roughly). We achieve the
2991            latter by disabling this optimization for very large basic blocks. It's noteworthy that blocks that
2992            large won't even make it into the DFG currently.
2993
2994         3) It makes the overflow check elimination more precise for cases where the inputs to an Add or Sub
2995            are the outputs of a bit-op. For example in (@a + (@b | 0)) | 0, we don't need to propagate
2996            NodeUsedAsNumber to either @a or @b.
2997
2998         This is neutral on V8v7 and a slight speed-up on compile time benchmarks.
2999
3000         * CMakeLists.txt:
3001         * GNUmakefile.list.am:
3002         * JavaScriptCore.xcodeproj/project.pbxproj:
3003         * Target.pri:
3004         * dfg/DFGArrayMode.cpp:
3005         (JSC::DFG::ArrayMode::refine):
3006         * dfg/DFGBackwardsPropagationPhase.cpp: Added.
3007         (DFG):
3008         (BackwardsPropagationPhase):
3009         (JSC::DFG::BackwardsPropagationPhase::BackwardsPropagationPhase):
3010         (JSC::DFG::BackwardsPropagationPhase::run):
3011         (JSC::DFG::BackwardsPropagationPhase::isNotNegZero):
3012         (JSC::DFG::BackwardsPropagationPhase::isNotZero):
3013         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoForConstant):
3014         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoNonRecursive):
3015         (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo):
3016         (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags):
3017         (JSC::DFG::BackwardsPropagationPhase::propagate):
3018         (JSC::DFG::performBackwardsPropagation):
3019         * dfg/DFGBackwardsPropagationPhase.h: Added.
3020         (DFG):
3021         * dfg/DFGCPSRethreadingPhase.cpp:
3022         (JSC::DFG::CPSRethreadingPhase::run):
3023         (JSC::DFG::CPSRethreadingPhase::clearIsLoadedFrom):
3024         (CPSRethreadingPhase):
3025         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
3026         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
3027         * dfg/DFGDriver.cpp:
3028         (JSC::DFG::compile):
3029         * dfg/DFGGraph.cpp:
3030         (JSC::DFG::Graph::dump):
3031         * dfg/DFGNodeFlags.cpp:
3032         (JSC::DFG::dumpNodeFlags):
3033         (DFG):
3034         * dfg/DFGNodeFlags.h:
3035         (DFG):
3036         * dfg/DFGPredictionPropagationPhase.cpp:
3037         (PredictionPropagationPhase):
3038         (JSC::DFG::PredictionPropagationPhase::propagate):
3039         * dfg/DFGUnificationPhase.cpp:
3040         (JSC::DFG::UnificationPhase::run):
3041         * dfg/DFGVariableAccessData.h:
3042         (JSC::DFG::VariableAccessData::VariableAccessData):
3043         (JSC::DFG::VariableAccessData::mergeIsLoadedFrom):
3044         (VariableAccessData):
3045         (JSC::DFG::VariableAccessData::setIsLoadedFrom):
3046         (JSC::DFG::VariableAccessData::isLoadedFrom):
3047
3048 2013-03-08  Roger Fong  <roger_fong@apple.com>
3049
3050         Makefile fixes.
3051
3052         * JavaScriptCore.vcxproj/JavaScriptCore.make:
3053
3054 2013-03-08  Gabor Rapcsanyi  <rgabor@webkit.org>
3055
3056         Cache flush problem on ARMv7 JSC
3057         https://bugs.webkit.org/show_bug.cgi?id=111441
3058
3059         Reviewed by Zoltan Herczeg.
3060
3061         Not proper cache flush causing random crashes on ARMv7 Linux with V8 tests.
3062         The problem is similar to https://bugs.webkit.org/show_bug.cgi?id=77712.
3063         Change the cache fulsh mechanism similar to ARM traditinal and revert the
3064         temporary fix.
3065
3066         * assembler/ARMv7Assembler.h:
3067         (JSC::ARMv7Assembler::cacheFlush):
3068
3069 2013-03-07  Geoffrey Garen  <ggaren@apple.com>
3070
3071         REGRESSION (r143759): 40% JSBench regression, 20% Octane/closure regression, 40% Octane/jquery regression, 2% Octane regression
3072         https://bugs.webkit.org/show_bug.cgi?id=111797
3073
3074         Reviewed by Oliver Hunt.
3075
3076         The bot's testing configuration stresses the cache's starting guess
3077         of 1MB.
3078
3079         This patch removes any starting guess, and just uses wall clock time
3080         to discover the initial working set size of an app, in code size.
3081
3082         * runtime/CodeCache.cpp:
3083         (JSC::CodeCacheMap::pruneSlowCase): Update our timer as we go.
3084
3085         Also fixed a bug where pruning from 0 to 0 would hang -- that case is
3086         a possibility now that we start with a capacity of 0.
3087
3088         * runtime/CodeCache.h:
3089         (CodeCacheMap):
3090         (JSC::CodeCacheMap::CodeCacheMap):
3091         (JSC::CodeCacheMap::add):
3092         (JSC::CodeCacheMap::prune): Don't prune if we're in the middle of
3093         discovering the working set size of an app, in code size.
3094
3095 2013-03-07  Michael Saboff  <msaboff@apple.com>
3096
3097         Crash when updating predictions below JSC::arrayProtoFuncForEach on tuaw.com article
3098         https://bugs.webkit.org/show_bug.cgi?id=111777
3099
3100         Reviewed by Filip Pizlo.
3101
3102         Moved register allocations to be above any generated control flow so that any
3103         resulting spill would be visible to all subsequently generated code.
3104
3105         * dfg/DFGSpeculativeJIT32_64.cpp:
3106         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
3107         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
3108         (JSC::DFG::SpeculativeJIT::compile):
3109         * dfg/DFGSpeculativeJIT64.cpp:
3110         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
3111         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
3112         (JSC::DFG::SpeculativeJIT::compile):
3113
3114 2013-03-07  Filip Pizlo  <fpizlo@apple.com>
3115
3116         DFG should not get corrupted IR in the case of code that is dead, unreachable, and contains a chain of nodes that use each other in an untyped way
3117         https://bugs.webkit.org/show_bug.cgi?id=111783
3118
3119         Reviewed by Mark Hahnenberg.
3120
3121         Unreachable code is not touched by CFA and so thinks that even untyped uses are checked.
3122         But dead untyped uses don't need checks and hence don't need to be Phantom'd. The DCE knew
3123         this in findTypeCheckRoot() but not in eliminateIrrelevantPhantomChildren(), leading to a
3124         Phantom node that had another Phantom node as one of its kids.
3125
3126         * dfg/DFGDCEPhase.cpp:
3127         (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
3128
3129 2013-03-07  Filip Pizlo  <fpizlo@apple.com>
3130
3131         The DFG fixpoint is not strictly profitable, and should be straight-lined
3132         https://bugs.webkit.org/show_bug.cgi?id=111764
3133
3134         Reviewed by Oliver Hunt and Geoffrey Garen.
3135
3136         The DFG previously ran optimizations to fixpoint because there exists a circular dependency:
3137
3138         CSE depends on CFG simplification: CFG simplification merges blocks, and CSE is block-local.
3139
3140         CFG simplification depends on CFA and constant folding: constant folding reveals branches on
3141         constants.
3142
3143         CFA depends on CSE: CSE reveals must-alias relationships by proving that two operations
3144         always produce identical values.
3145
3146         Arguments simplification also depends on CSE, but it ought not depend on anything else.
3147
3148         Hence we get a cycle like: CFA -> folding -> CFG -> CSE -> CFA.
3149
3150         Note that before we had sparse conditional CFA, we also had CFA depending on CFG. This ought
3151         not be the case anymore: CFG simplification should not by itself lead to better CFA results.
3152
3153         My guess is that the weakest link in this cycle is CFG -> CSE. CSE cuts both ways: if you
3154         CSE too much then you increase register pressure. Hence it's not clear that you always want
3155         to CSE after simplifying control flow. This leads to an order of optimization as follows:
3156
3157         CSE -> arguments -> CFA -> folding -> CFG
3158
3159         This is a 2.5% speed-up on SunSpider, a 4% speed-up on V8Spider, a possible 0.3% slow-down
3160         on V8v7, nothing on Kraken, and 1.2% speed-up in the JSRegress geomean. I'll take a 2.5%
3161         speed-up over a 0.3% V8v7 speed-up.
3162
3163         * dfg/DFGDriver.cpp:
3164         (JSC::DFG::compile):
3165
3166 2013-03-07  Roger Fong  <roger_fong@apple.com>
3167
3168         Build fix for AppleWin VS2010.
3169
3170         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3171         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3172
3173 2013-03-05  Mark Hahnenberg  <mhahnenberg@apple.com>
3174
3175         Objective-C API: Need a good way to reference event handlers without causing cycles
3176         https://bugs.webkit.org/show_bug.cgi?id=111088
3177
3178         Reviewed by Geoffrey Garen.
3179
3180         JSManagedValue is like a special kind of weak value. When you create a JSManagedValue, you can
3181         supply an Objective-C object as its "owner". As long as the Objective-C owner object remains
3182         alive and its wrapper remains accessible to the JSC garbage collector (e.g. by being marked by
3183         the global object), the reference to the JavaScript value is strong. As soon as the Objective-C
3184         owner is deallocated or its wrapper becomes inaccessible to the garbage collector, the reference
3185         becomes weak.
3186
3187         If you do not supply an owner or you use the weakValueWithValue: convenience class method, the
3188         returned JSManagedValue behaves as a normal weak reference.
3189
3190         This new class allows clients to maintain references to JavaScript values in the Objective-C
3191         heap without creating reference cycles/leaking memory.
3192
3193         * API/JSAPIWrapperObject.cpp: Added.
3194         (JSC):
3195         (JSC::::createStructure):
3196         (JSC::JSAPIWrapperObject::JSAPIWrapperObject): This is a special JSObject for the Objective-C API that knows
3197         for the purposes of garbage collection/marking that it wraps an opaque Objective-C object.
3198         (JSC::JSAPIWrapperObject::visitChildren): We add the pointer to the wrapped Objective-C object to the set of
3199         opaque roots so that the weak handle owner for JSManagedValues can find it later.
3200         * API/JSAPIWrapperObject.h: Added.
3201         (JSC):
3202         (JSAPIWrapperObject):
3203         (JSC::JSAPIWrapperObject::wrappedObject):
3204         (JSC::JSAPIWrapperObject::setWrappedObject):
3205         * API/JSBase.cpp:
3206         (JSSynchronousGarbageCollect):
3207         * API/JSBasePrivate.h:
3208         * API/JSCallbackObject.cpp:
3209         (JSC):
3210         * API/JSCallbackObject.h:
3211         (JSC::JSCallbackObject::destroy): Moved this to the header so that we don't get link errors with JSAPIWrapperObject.
3212         * API/JSContext.mm:
3213         (-[JSContext initWithVirtualMachine:]): We weren't adding manually allocated/initialized JSVirtualMachine objects to
3214         the global cache of virtual machines. The init methods handle this now rather than contextWithGlobalContextRef, since
3215         not everyone is guaranteed to use the latter.
3216         (-[JSContext initWithGlobalContextRef:]):
3217         (+[JSContext contextWithGlobalContextRef:]):
3218         * API/JSManagedValue.h: Added.
3219         * API/JSManagedValue.mm: Added.
3220         (JSManagedValueHandleOwner):
3221         (managedValueHandleOwner):
3222         (+[JSManagedValue weakValueWithValue:]):
3223         (+[JSManagedValue managedValueWithValue:owner:]):
3224         (-[JSManagedValue init]): We explicitly call the ARC entrypoints to initialize/get the weak owner field since we don't
3225         use ARC when building our framework.
3226         (-[JSManagedValue initWithValue:]):
3227         (-[JSManagedValue initWithValue:owner:]):
3228         (-[JSManagedValue dealloc]):
3229         (-[JSManagedValue value]):
3230         (-[JSManagedValue weakOwner]):
3231         (JSManagedValueHandleOwner::isReachableFromOpaqueRoots): If the Objective-C owner is still alive (i.e. loading the weak field
3232         returns non-nil) and that value was added to the set of opaque roots by the wrapper for that Objective-C owner, then the the
3233         JSObject to which the JSManagedObject refers is still alive.
3234         * API/JSObjectRef.cpp: We have to add explicit checks for the JSAPIWrapperObject, just like the other types of JSCallbackObjects.
3235         (JSObjectGetPrivate):
3236         (JSObjectSetPrivate):
3237         (JSObjectGetPrivateProperty):
3238         (JSObjectSetPrivateProperty):
3239         (JSObjectDeletePrivateProperty):
3240         * API/JSValue.mm:
3241         (objectToValueWithoutCopy):
3242         * API/JSValueRef.cpp:
3243         (JSValueIsObjectOfClass):
3244         * API/JSVirtualMachine.mm:
3245         (-[JSVirtualMachine initWithContextGroupRef:]):
3246         (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
3247         * API/JSWrapperMap.mm:
3248         (wrapperFinalize):
3249         (makeWrapper): This is our own internal version of JSObjectMake which creates JSAPIWrapperObjects, the Obj-C API
3250         version of JSCallbackObjects.
3251         (createObjectWithCustomBrand):
3252         (-[JSObjCClassInfo wrapperForObject:]):
3253         (tryUnwrapObjcObject):
3254         * API/JavaScriptCore.h:
3255         * API/tests/testapi.mm: Added new tests for the strong and weak uses of JSManagedValue in the context of an
3256         onclick handler for an Objective-C object inserted into a JSContext.
3257         (-[TextXYZ setWeakOnclick:]):
3258         (-[TextXYZ setOnclick:]):
3259         (-[TextXYZ weakOnclick]):
3260         (-[TextXYZ onclick]):
3261         (-[TextXYZ click]):
3262         * CMakeLists.txt: Various build system additions.
3263         * GNUmakefile.list.am:
3264         * JavaScriptCore.gypi:
3265         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
3266         * JavaScriptCore.xcodeproj/project.pbxproj:
3267         * runtime/JSGlobalObject.cpp: Added the new canonical Structure for the JSAPIWrapperObject class.
3268         (JSC::JSGlobalObject::reset):
3269         (JSC):
3270         (JSC::JSGlobalObject::visitChildren):
3271         * runtime/JSGlobalObject.h:
3272         (JSGlobalObject):
3273         (JSC::JSGlobalObject::objcWrapperObjectStructure):
3274
3275 2013-03-06  Filip Pizlo  <fpizlo@apple.com>
3276
3277         ConvertThis should be turned into Identity based on predictions in Fixup, rather than based on proofs in ConstantFolding
3278         https://bugs.webkit.org/show_bug.cgi?id=111674
3279
3280         Reviewed by Oliver Hunt.
3281
3282         This gets rid of the speculated forms of ConvertThis in the backend, and has Fixup
3283         convert them to either Identity(Object:@child) if the child is predicted object, or
3284         Phantom(Other:@child) ; WeakJSConstant(global this object) if it's predicted Other.
3285
3286         The goal of this is to ensure that the optimization fixpoint doesn't create
3287         Identity's, since doing so requires a rerun of CSE. So far this isn't a speed-up
3288         but I'm hoping this will be a step towards reducing the need to rerun the fixpoint
3289         so as to ultimately reduce compile times.
3290
3291         * dfg/DFGAbstractState.cpp:
3292         (JSC::DFG::AbstractState::executeEffects):
3293         * dfg/DFGAssemblyHelpers.h:
3294         (AssemblyHelpers):
3295         * dfg/DFGConstantFoldingPhase.cpp:
3296         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3297         * dfg/DFGFixupPhase.cpp:
3298         (JSC::DFG::FixupPhase::fixupNode):
3299         (FixupPhase):
3300         (JSC::DFG::FixupPhase::observeUseKindOnNode):
3301         (JSC::DFG::FixupPhase::setUseKindAndUnboxIfProfitable):
3302         * dfg/DFGGraph.h:
3303         (JSC::DFG::Graph::globalThisObjectFor):
3304         (Graph):
3305         * dfg/DFGNode.h:
3306         (Node):
3307         (JSC::DFG::Node::convertToIdentity):
3308         (JSC::DFG::Node::convertToWeakConstant):
3309         * dfg/DFGSpeculativeJIT32_64.cpp:
3310         (JSC::DFG::SpeculativeJIT::compile):
3311         * dfg/DFGSpeculativeJIT64.cpp:
3312         (JSC::DFG::SpeculativeJIT::compile):
3313
3314 2013-03-07  Peter Gal  <galpeter@inf.u-szeged.hu>
3315
3316         Children method in LLINT AST Not class should return [@child]
3317         https://bugs.webkit.org/show_bug.cgi?id=90740
3318
3319         Reviewed by Filip Pizlo.
3320
3321         * offlineasm/ast.rb: Fixed the return value of the children method in the Not AST class.
3322
3323 2013-03-05  Oliver Hunt  <oliver@apple.com>
3324
3325         Bring back eager resolution of function scoped variables
3326         https://bugs.webkit.org/show_bug.cgi?id=111497
3327
3328         Reviewed by Geoffrey Garen.
3329
3330         This reverts the get/put_scoped_var part of the great non-local
3331         variable resolution refactoring.  This still leaves all the lazy
3332         variable resolution logic as it's necessary for global property
3333         resolution, and i don't want to make the patch bigger than it
3334         already is.
3335
3336         * bytecode/CodeBlock.cpp:
3337         (JSC::CodeBlock::dumpBytecode):
3338         (JSC::CodeBlock::CodeBlock):
3339         * bytecode/CodeBlock.h:
3340         (CodeBlock):
3341         * bytecode/Opcode.h:
3342         (JSC):
3343         (JSC::padOpcodeName):
3344         * bytecode/UnlinkedCodeBlock.cpp:
3345         (JSC::generateFunctionCodeBlock):
3346         (JSC::UnlinkedFunctionExecutable::codeBlockFor):
3347         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3348         * bytecode/UnlinkedCodeBlock.h:
3349         (JSC):
3350         (UnlinkedFunctionExecutable):
3351         (UnlinkedCodeBlock):
3352         (JSC::UnlinkedCodeBlock::usesGlobalObject):
3353         (JSC::UnlinkedCodeBlock::setGlobalObjectRegister):
3354         (JSC::UnlinkedCodeBlock::globalObjectRegister):
3355         * bytecompiler/BytecodeGenerator.cpp:
3356         (JSC::ResolveResult::checkValidity):
3357         (JSC::BytecodeGenerator::BytecodeGenerator):
3358         (JSC::BytecodeGenerator::emitLoadGlobalObject):
3359         (JSC):
3360         (JSC::BytecodeGenerator::resolve):
3361         (JSC::BytecodeGenerator::resolveConstDecl):
3362         (JSC::BytecodeGenerator::emitResolve):
3363         (JSC::BytecodeGenerator::emitResolveBase):
3364         (JSC::BytecodeGenerator::emitResolveBaseForPut):
3365         (JSC::BytecodeGenerator::emitResolveWithBaseForPut):
3366         (JSC::BytecodeGenerator::emitResolveWithThis):
3367         (JSC::BytecodeGenerator::emitGetStaticVar):
3368         (JSC::BytecodeGenerator::emitPutStaticVar):
3369         * bytecompiler/BytecodeGenerator.h:
3370         (JSC::ResolveResult::lexicalResolve):
3371         (JSC::ResolveResult::isStatic):
3372         (JSC::ResolveResult::depth):
3373         (JSC::ResolveResult::index):
3374         (ResolveResult):
3375         (JSC::ResolveResult::ResolveResult):
3376         (BytecodeGenerator):
3377         * bytecompiler/NodesCodegen.cpp:
3378         (JSC::ResolveNode::isPure):
3379         (JSC::FunctionCallResolveNode::emitBytecode):
3380         (JSC::PostfixNode::emitResolve):
3381         (JSC::TypeOfResolveNode::emitBytecode):
3382         (JSC::PrefixNode::emitResolve):
3383         (JSC::ReadModifyResolveNode::emitBytecode):
3384         (JSC::AssignResolveNode::emitBytecode):
3385         (JSC::ConstDeclNode::emitCodeSingle):
3386         * dfg/DFGByteCodeParser.cpp:
3387         (JSC::DFG::ByteCodeParser::parseBlock):
3388         * dfg/DFGCapabilities.cpp:
3389         (JSC::DFG::debugFail):
3390         * dfg/DFGCapabilities.h:
3391         (JSC::DFG::canCompileOpcode):
3392         (JSC::DFG::canInlineOpcode):
3393         * jit/JIT.cpp:
3394         (JSC::JIT::privateCompileMainPass):
3395         * jit/JIT.h:
3396         (JIT):
3397         * jit/JITPropertyAccess.cpp:
3398         (JSC::JIT::emit_op_get_scoped_var):
3399         (JSC):
3400         (JSC::JIT::emit_op_put_scoped_var):
3401         * jit/JITPropertyAccess32_64.cpp:
3402         (JSC::JIT::emit_op_get_scoped_var):
3403         (JSC):
3404         (JSC::JIT::emit_op_put_scoped_var):
3405         * llint/LowLevelInterpreter32_64.asm:
3406         * llint/LowLevelInterpreter64.asm:
3407         * runtime/CodeCache.cpp:
3408         (JSC::CodeCache::getCodeBlock):
3409         (JSC::CodeCache::getProgramCodeBlock):
3410         (JSC::CodeCache::getEvalCodeBlock):
3411         * runtime/CodeCache.h:
3412         (JSC):
3413         (CodeCache):
3414         * runtime/Executable.cpp:
3415         (JSC::EvalExecutable::compileInternal):
3416         (JSC::FunctionExecutable::produceCodeBlockFor):
3417         * runtime/JSGlobalObject.cpp:
3418         (JSC::JSGlobalObject::createEvalCodeBlock):
3419         * runtime/JSGlobalObject.h:
3420         (JSGlobalObject):
3421         * runtime/Options.cpp:
3422         (JSC::Options::initialize):
3423
3424 2013-03-06  Filip Pizlo  <fpizlo@apple.com>
3425
3426         Unreviewed, roll out http://trac.webkit.org/changeset/144989
3427
3428         I think we want the assertion that I removed.
3429
3430         * dfg/DFGAbstractState.cpp:
3431         (JSC::DFG::AbstractState::merge):
3432         (JSC::DFG::AbstractState::mergeVariableBetweenBlocks):
3433         * dfg/DFGAbstractState.h:
3434         (AbstractState):
3435
3436 2013-03-06  Filip Pizlo  <fpizlo@apple.com>
3437
3438         DFG::AbstractState::merge() is still more complicated than it needs to be
3439         https://bugs.webkit.org/show_bug.cgi?id=111619
3440
3441         Reviewed by Mark Hahnenberg.
3442
3443         This method is the one place where we still do some minimal amount of liveness pruning, but the style with
3444         which it is written is awkward, and it makes an assertion about variablesAtTail that will be invalidated
3445         by https://bugs.webkit.org/show_bug.cgi?id=111539.
3446
3447         * dfg/DFGAbstractState.cpp:
3448         (JSC::DFG::AbstractState::merge):
3449         (JSC::DFG::AbstractState::mergeVariableBetweenBlocks):
3450         * dfg/DFGAbstractState.h:
3451         (AbstractState):
3452
3453 2013-03-06  Filip Pizlo  <fpizlo@apple.com>
3454
3455         DFG should not run full CSE after the optimization fixpoint, since it really just wants store elimination
3456         https://bugs.webkit.org/show_bug.cgi?id=111536
3457
3458         Reviewed by Oliver Hunt and Mark Hahnenberg.
3459
3460         The fixpoint will do aggressive load elimination and pure CSE. There's no need to do it after the fixpoint.
3461         On the other hand, the fixpoint does not profit from doing store elimination (except for SetLocal/Flush).
3462         Previously we had CSE do both, and had it avoid doing some store elimination during the fixpoint by querying
3463         the fixpoint state. This changes CSE to be templated on mode - either NormalCSE or StoreElimination - so
3464         that we explicitly put it into one of those modes depending on where we call it from. The goal is to reduce
3465         time spent doing load elimination after the fixpoint, since that is just wasted cycles.
3466
3467         * dfg/DFGCSEPhase.cpp:
3468         (JSC::DFG::CSEPhase::CSEPhase):
3469         (JSC::DFG::CSEPhase::run):
3470         (JSC::DFG::CSEPhase::performNodeCSE):
3471         (JSC::DFG::CSEPhase::performBlockCSE):
3472         (JSC::DFG::performCSE):
3473         (DFG):
3474         (JSC::DFG::performStoreElimination):
3475         * dfg/DFGCSEPhase.h:
3476         (DFG):
3477         * dfg/DFGDriver.cpp:
3478         (JSC::DFG::compile):
3479
3480 2013-03-06  Andreas Kling  <akling@apple.com>
3481
3482         Pack Structure members better.
3483         <http://webkit.org/b/111593>
3484         <rdar://problem/13359200>
3485
3486         Reviewed by Mark Hahnenberg.
3487
3488         Shrink Structure by 8 bytes (now at 104 bytes) on 64-bit by packing the members better.
3489
3490         * runtime/Structure.cpp:
3491         (JSC::Structure::Structure):
3492         * runtime/Structure.h:
3493         (Structure):
3494
3495 2013-03-06  Andreas Kling  <akling@apple.com>
3496
3497         Unreviewed, fix Windows build after r144910.
3498
3499         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
3500
3501 2013-03-05  Filip Pizlo  <fpizlo@apple.com>
3502
3503         DFG should not check if nodes are shouldGenerate prior to DCE
3504         https://bugs.webkit.org/show_bug.cgi?id=111520
3505
3506         Reviewed by Geoffrey Garen.
3507
3508         All nodes are live before DCE. We don't need to check that they aren't, because they
3509         definitely will be.
3510
3511         * dfg/DFGArgumentsSimplificationPhase.cpp:
3512         (JSC::DFG::ArgumentsSimplificationPhase::run):
3513         * dfg/DFGCFAPhase.cpp:
3514         (JSC::DFG::CFAPhase::performBlockCFA):
3515         * dfg/DFGCFGSimplificationPhase.cpp:
3516         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
3517         * dfg/DFGCSEPhase.cpp:
3518         (JSC::DFG::CSEPhase::pureCSE):
3519         (JSC::DFG::CSEPhase::int32ToDoubleCSE):
3520         (JSC::DFG::CSEPhase::constantCSE):
3521         (JSC::DFG::CSEPhase::weakConstantCSE):
3522         (JSC::DFG::CSEPhase::getCalleeLoadElimination):
3523         (JSC::DFG::CSEPhase::getArrayLengthElimination):
3524         (JSC::DFG::CSEPhase::globalVarLoadElimination):
3525         (JSC::DFG::CSEPhase::scopedVarLoadElimination):
3526         (JSC::DFG::CSEPhase::globalVarWatchpointElimination):
3527         (JSC::DFG::CSEPhase::globalVarStoreElimination):
3528         (JSC::DFG::CSEPhase::scopedVarStoreElimination):
3529         (JSC::DFG::CSEPhase::getByValLoadElimination):
3530         (JSC::DFG::CSEPhase::checkStructureElimination):
3531         (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
3532         (JSC::DFG::CSEPhase::putStructureStoreElimination):
3533         (JSC::DFG::CSEPhase::getByOffsetLoadElimination):
3534         (JSC::DFG::CSEPhase::putByOffsetStoreElimination):
3535         (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
3536         (JSC::DFG::CSEPhase::checkArrayElimination):
3537         (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
3538         (JSC::DFG::CSEPhase::getMyScopeLoadElimination):
3539         (JSC::DFG::CSEPhase::getLocalLoadElimination):
3540         (JSC::DFG::CSEPhase::setLocalStoreElimination):
3541         (JSC::DFG::CSEPhase::performNodeCSE):
3542         * dfg/DFGFixupPhase.cpp:
3543         (JSC::DFG::FixupPhase::fixupNode):
3544         (JSC::DFG::FixupPhase::fixupSetLocalsInBlock):
3545         * dfg/DFGPredictionPropagationPhase.cpp:
3546         (JSC::DFG::PredictionPropagationPhase::propagate):
3547         * dfg/DFGStructureCheckHoistingPhase.cpp:
3548         (JSC::DFG::StructureCheckHoistingPhase::run):
3549
3550 2013-03-06  Csaba Osztrogonác  <ossy@webkit.org>
3551
3552         Fix unused parameter warnings in ARM assembler
3553         https://bugs.webkit.org/show_bug.cgi?id=111433
3554
3555         Reviewed by Kentaro Hara.
3556
3557         * assembler/ARMAssembler.h: Remove unreachable revertJump() after r143346.
3558         * assembler/MacroAssemblerARM.h:
3559         (JSC::MacroAssemblerARM::moveIntsToDouble): Remove unused scratch parameter instead of UNUSED_PARAM.
3560         (JSC::MacroAssemblerARM::branchConvertDoubleToInt32): Remove unused fpTemp parameter.
3561         (JSC::MacroAssemblerARM::revertJumpReplacementToPatchableBranchPtrWithPatch): Remove unused parameters.
3562
3563 2013-03-06  Andreas Kling  <akling@apple.com>
3564
3565         Unused Structure property tables waste 14MB on Membuster.
3566         <http://webkit.org/b/110854>
3567         <rdar://problem/13292104>
3568
3569         Reviewed by Geoffrey Garen.
3570
3571         Turn PropertyTable into a GC object and have Structure drop unpinned tables when marking.
3572         14 MB progression on Membuster3.
3573
3574         This time it should stick; I've been through all the tests with COLLECT_ON_EVERY_ALLOCATION.
3575         The issue with the last version was that Structure::m_offset could be used uninitialized
3576         when re-materializing a previously GC'd property table, causing some sanity checks to fail.
3577
3578         * CMakeLists.txt:
3579         * GNUmakefile.list.am:
3580         * JavaScriptCore.gypi:
3581         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3582         * JavaScriptCore.xcodeproj/project.pbxproj:
3583         * Target.pri:
3584
3585             Added PropertyTable.cpp.
3586
3587         * runtime/PropertyTable.cpp: Added.
3588         (JSC::PropertyTable::create):
3589         (JSC::PropertyTable::clone):
3590         (JSC::PropertyTable::PropertyTable):
3591         (JSC::PropertyTable::destroy):
3592         (JSC::PropertyTable::~PropertyTable):
3593         (JSC::PropertyTable::visitChildren):
3594
3595             Moved marking of property table values here from Structure::visitChildren().
3596
3597         * runtime/WriteBarrier.h:
3598         (JSC::WriteBarrierBase::get):
3599
3600             Move m_cell to a local before using it multiple times. This avoids a multiple-access race when
3601             Structure::checkOffsetConsistency() is used in assertions on the main thread while a marking thread
3602             zaps the property table.
3603
3604         * runtime/Structure.h:
3605         (JSC::Structure::materializePropertyMapIfNecessary):
3606         (JSC::Structure::materializePropertyMapIfNecessaryForPinning):
3607         * runtime/StructureInlines.h:
3608         (JSC::Structure::propertyTable):
3609
3610             Added a getter for the Structure's PropertyTable that ASSERTs GC currently isn't active.
3611             Because GC can zap an unpinned property table at any time, it's not entirely safe to access it.
3612             Renamed the variable itself to m_propertyTableUnsafe to force call sites into explaining themselves.
3613
3614         (JSC::Structure::putWillGrowOutOfLineStorage):
3615         (JSC::Structure::checkOffsetConsistency):
3616
3617             Moved these out of Structure.h to break header dependency cycle between Structure/PropertyTable.
3618
3619         * runtime/Structure.cpp:
3620         (JSC::Structure::visitChildren):
3621
3622             Null out m_propertyTable if the table is unpinned. This'll cause the table to get GC'd.
3623
3624         (JSC::Structure::takePropertyTableOrCloneIfPinned):
3625
3626             Added for setting up the property table in a new transition, this code is now shared between
3627             addPropertyTransition() and nonPropertyTransition().
3628
3629         * runtime/JSGlobalData.h:
3630         * runtime/JSGlobalData.cpp:
3631         (JSC::JSGlobalData::JSGlobalData):
3632
3633             Add a global propertyTableStructure.
3634
3635         * runtime/PropertyMapHashTable.h:
3636         (PropertyTable):
3637         (JSC::PropertyTable::createStructure):
3638         (JSC::PropertyTable::copy):
3639
3640             Make PropertyTable a GC object.
3641
3642         * runtime/Structure.cpp:
3643         (JSC::Structure::dumpStatistics):
3644         (JSC::Structure::materializePropertyMap):
3645         (JSC::Structure::despecifyDictionaryFunction):
3646         (JSC::Structure::addPropertyTransition):
3647         (JSC::Structure::changePrototypeTransition):
3648         (JSC::Structure::despecifyFunctionTransition):
3649         (JSC::Structure::attributeChangeTransition):
3650         (JSC::Structure::toDictionaryTransition):
3651         (JSC::Structure::sealTransition):
3652         (JSC::Structure::freezeTransition):
3653         (JSC::Structure::preventExtensionsTransition):
3654         (JSC::Structure::nonPropertyTransition):
3655         (JSC::Structure::isSealed):
3656         (JSC::Structure::isFrozen):
3657         (JSC::Structure::flattenDictionaryStructure):
3658         (JSC::Structure::pin):
3659         (JSC::Structure::copyPropertyTable):
3660         (JSC::Structure::copyPropertyTableForPinning):
3661         (JSC::Structure::get):
3662         (JSC::Structure::despecifyFunction):
3663         (JSC::Structure::despecifyAllFunctions):
3664         (JSC::Structure::putSpecificValue):
3665         (JSC::Structure::remove):
3666         (JSC::Structure::createPropertyMap):
3667         (JSC::Structure::getPropertyNamesFromStructure):
3668         (JSC::Structure::checkConsistency):
3669
3670 2013-03-05  Filip Pizlo  <fpizlo@apple.com>
3671
3672         Get rid of the invert argument to SpeculativeJIT::jumpSlowForUnwantedArrayMode
3673         https://bugs.webkit.org/show_bug.cgi?id=105624
3674
3675         Reviewed by Oliver Hunt.
3676
3677         All callers pass invert = false, which is the default value of the argument. So, get
3678         rid of the argument and fold away all code that checks it.
3679
3680         * dfg/DFGSpeculativeJIT.cpp:
3681         (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
3682         * dfg/DFGSpeculativeJIT.h:
3683         (SpeculativeJIT):
3684
3685 2013-03-05  Filip Pizlo  <fpizlo@apple.com>
3686
3687         Unreviewed, fix an incorrect comment. The comment was a holdover from a work-in-progress version of this code.
3688
3689         * dfg/DFGDCEPhase.cpp:
3690         (JSC::DFG::DCEPhase::run):
3691
3692 2013-03-04  Filip Pizlo  <fpizlo@apple.com>
3693
3694         DFG DCE might eliminate checks unsoundly
3695         https://bugs.webkit.org/show_bug.cgi?id=109389
3696
3697         Reviewed by Oliver Hunt.
3698
3699         This gets rid of all eager reference counting, and does all dead code elimination
3700         in one phase - the DCEPhase. This phase also sets up the node reference counts,
3701         which are then used not just for DCE but also register allocation and stack slot
3702         allocation.
3703
3704         Doing this required a number of surgical changes in places that previously relied
3705         on always having liveness information. For example, the structure check hoisting
3706         phase must now consult whether a VariableAccessData is profitable for unboxing to
3707         make sure that it doesn't try to do hoisting on set SetLocals. The arguments
3708         simplification phase employs its own light-weight liveness analysis. Both phases
3709         previously just used reference counts.
3710
3711         The largest change is that now, dead nodes get turned into Phantoms. Those
3712         Phantoms will retain those child edges that are not proven. This ensures that any
3713         type checks performed by a dead node remain even after the node is killed. On the
3714         other hand, this Phantom conversion means that we need special handling for
3715         SetLocal. I decided to make the four forms of SetLocal explicit:
3716
3717         MovHint(@a, rK): Just indicates that node @a contains the value that would have
3718              now been placed into virtual register rK. Does not actually cause @a to be
3719              stored into rK. This would have previously been a dead SetLocal with @a
3720              being live. MovHints are always dead.
3721
3722         ZombieHint(rK): Indicates that at this point, register rK will contain a dead
3723              value and OSR should put Undefined into it. This would have previously been
3724              a dead SetLocal with @a being dead also. ZombieHints are always dead.
3725
3726         MovHintAndCheck(@a, rK): Identical to MovHint except @a is also type checked,
3727              according to whatever UseKind the edge to @a has. The type check is always a
3728              forward exit. MovHintAndChecks are always live, since they are
3729              NodeMustGenerate. Previously this would have been a dead SetLocal with a
3730              live @a, and the check would have disappeared. This is one of the bugs that
3731              this patch solves.
3732
3733         SetLocal(@a, rK): This still does exactly what it does now, if the SetLocal is
3734              live.
3735
3736         Basically this patch makes it so that dead SetLocals eventually decay to MovHint,
3737         ZombieHint, or MovHintAndCheck depending on the situation. If the child @a is
3738         also dead, then you get a ZombieHint. If the child @a is live but the SetLocal
3739         has a type check and @a's type hasn't been proven to have that type then you get
3740         a MovHintAndCheck. Otherwise you get a MovHint.
3741
3742         This is performance neutral.
3743
3744         * CMakeLists.txt:
3745         * GNUmakefile.list.am:
3746         * JavaScriptCore.xcodeproj/project.pbxproj:
3747         * Target.pri:
3748         * dfg/DFGAbstractState.cpp:
3749         (JSC::DFG::AbstractState::executeEffects):
3750         (JSC::DFG::AbstractState::mergeStateAtTail):
3751         * dfg/DFGArgumentsSimplificationPhase.cpp:
3752         (JSC::DFG::ArgumentsSimplificationPhase::run):
3753         (ArgumentsSimplificationPhase):
3754         (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
3755         * dfg/DFGBasicBlock.h:
3756         (BasicBlock):
3757         * dfg/DFGBasicBlockInlines.h:
3758         (DFG):
3759         * dfg/DFGByteCodeParser.cpp:
3760         (JSC::DFG::ByteCodeParser::addToGraph):
3761         (JSC::DFG::ByteCodeParser::insertPhiNode):
3762         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
3763         * dfg/DFGCFAPhase.cpp:
3764         (JSC::DFG::CFAPhase::run):
3765         * dfg/DFGCFGSimplificationPhase.cpp:
3766         (JSC::DFG::CFGSimplificationPhase::run):
3767         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
3768         * dfg/DFGCPSRethreadingPhase.cpp:
3769         (JSC::DFG::CPSRethreadingPhase::run):
3770         (JSC::DFG::CPSRethreadingPhase::addPhiSilently):
3771         * dfg/DFGCSEPhase.cpp:
3772         (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
3773         (JSC::DFG::CSEPhase::setReplacement):
3774         (JSC::DFG::CSEPhase::performNodeCSE):
3775         * dfg/DFGCommon.cpp:
3776         (WTF::printInternal):
3777         (WTF):
3778         * dfg/DFGCommon.h:
3779         (WTF):
3780         * dfg/DFGConstantFoldingPhase.cpp:
3781         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3782         (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
3783         (JSC::DFG::ConstantFoldingPhase::paintUnreachableCode):
3784         * dfg/DFGDCEPhase.cpp: Added.
3785         (DFG):
3786         (DCEPhase):
3787         (JSC::DFG::DCEPhase::DCEPhase):
3788         (JSC::DFG::DCEPhase::run):
3789         (JSC::DFG::DCEPhase::findTypeCheckRoot):
3790         (JSC::DFG::DCEPhase::countEdge):
3791         (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
3792         (JSC::DFG::performDCE):
3793         * dfg/DFGDCEPhase.h: Added.
3794         (DFG):
3795         * dfg/DFGDriver.cpp:
3796         (JSC::DFG::compile):
3797         * dfg/DFGFixupPhase.cpp:
3798         (JSC::DFG::FixupPhase::fixupNode):
3799         (JSC::DFG::FixupPhase::checkArray):
3800         (JSC::DFG::FixupPhase::blessArrayOperation):
3801         (JSC::DFG::FixupPhase::fixIntEdge):
3802         (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
3803         (JSC::DFG::FixupPhase::truncateConstantToInt32):
3804         * dfg/DFGGraph.cpp:
3805         (JSC::DFG::Graph::Graph):
3806         (JSC::DFG::Graph::dump):
3807         (DFG):
3808         * dfg/DFGGraph.h:
3809         (JSC::DFG::Graph::changeChild):
3810         (JSC::DFG::Graph::changeEdge):
3811         (JSC::DFG::Graph::compareAndSwap):
3812         (JSC::DFG::Graph::clearAndDerefChild):
3813         (JSC::DFG::Graph::performSubstitution):
3814         (JSC::DFG::Graph::performSubstitutionForEdge):
3815         (Graph):
3816         (JSC::DFG::Graph::substitute):
3817         * dfg/DFGInsertionSet.h:
3818         (InsertionSet):
3819         * dfg/DFGNode.h:
3820         (JSC::DFG::Node::Node):
3821         (JSC::DFG::Node::convertToConstant):
3822         (JSC::DFG::Node::convertToGetLocalUnlinked):
3823         (JSC::DFG::Node::containsMovHint):
3824         (Node):
3825         (JSC::DFG::Node::hasVariableAccessData):
3826         (JSC::DFG::Node::willHaveCodeGenOrOSR):
3827         * dfg/DFGNodeType.h:
3828         (DFG):
3829         * dfg/DFGPredictionPropagationPhase.cpp:
3830         (JSC::DFG::PredictionPropagationPhase::propagate):
3831         * dfg/DFGSpeculativeJIT.cpp:
3832         (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
3833         (JSC::DFG::SpeculativeJIT::compileMovHint):
3834         (JSC::DFG::SpeculativeJIT::compileMovHintAndCheck):
3835         (DFG):
3836         (JSC::DFG::SpeculativeJIT::compileInlineStart):
3837         (JSC::DFG::SpeculativeJIT::compile):
3838         * dfg/DFGSpeculativeJIT.h:
3839         (SpeculativeJIT):
3840         * dfg/DFGSpeculativeJIT32_64.cpp:
3841         (JSC::DFG::SpeculativeJIT::compile):
3842         * dfg/DFGSpeculativeJIT64.cpp:
3843         (JSC::DFG::SpeculativeJIT::compile):
3844         * dfg/DFGStructureCheckHoistingPhase.cpp:
3845         (JSC::DFG::StructureCheckHoistingPhase::run):
3846         (JSC::DFG::StructureCheckHoistingPhase::shouldConsiderForHoisting):
3847         (StructureCheckHoistingPhase):
3848         * dfg/DFGValidate.cpp:
3849         (JSC::DFG::Validate::validate):
3850
3851 2013-03-05  Mark Hahnenberg  <mhahnenberg@apple.com>
3852
3853         Objective-C API: JSValue should implement init and return nil in exceptional cases
3854         https://bugs.webkit.org/show_bug.cgi?id=111487
3855
3856         Reviewed by Darin Adler.
3857
3858         * API/JSValue.mm:
3859         (-[JSValue init]): We return nil here because there is no way to get the instance into a coherent state
3860         without a JSContext.
3861         (-[JSValue initWithValue:inContext:]): Similarly, we should also return nil here if either of the arguments is 0.
3862
3863 2013-03-05  Sheriff Bot  <webkit.review.bot@gmail.com>
3864
3865         Unreviewed, rolling out r144708.
3866         http://trac.webkit.org/changeset/144708
3867         https://bugs.webkit.org/show_bug.cgi?id=111447
3868
3869         random assertion crashes in inspector tests on qt+mac bots
3870         (Requested by kling on #webkit).
3871
3872         * CMakeLists.txt:
3873         * GNUmakefile.list.am:
3874         * JavaScriptCore.gypi:
3875         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3876         * JavaScriptCore.xcodeproj/project.pbxproj:
3877         * Target.pri:
3878         * runtime/JSGlobalData.cpp:
3879         (JSC::JSGlobalData::JSGlobalData):
3880         * runtime/JSGlobalData.h:
3881         (JSGlobalData):
3882         * runtime/PropertyMapHashTable.h:
3883         (PropertyTable):
3884         (JSC::PropertyTable::PropertyTable):
3885         (JSC):
3886         (JSC::PropertyTable::~PropertyTable):
3887         (JSC::PropertyTable::copy):
3888         * runtime/PropertyTable.cpp: Removed.
3889         * runtime/Structure.cpp:
3890         (JSC::Structure::dumpStatistics):
3891         (JSC::Structure::materializePropertyMap):
3892         (JSC::Structure::despecifyDictionaryFunction):
3893         (JSC::Structure::addPropertyTransition):
3894         (JSC::Structure::changePrototypeTransition):
3895         (JSC::Structure::despecifyFunctionTransition):
3896         (JSC::Structure::attributeChangeTransition):
3897         (JSC::Structure::toDictionaryTransition):
3898         (JSC::Structure::sealTransition):
3899         (JSC::Structure::freezeTransition):
3900         (JSC::Structure::preventExtensionsTransition):
3901         (JSC::Structure::nonPropertyTransition):
3902         (JSC::Structure::isSealed):
3903         (JSC::Structure::isFrozen):
3904         (JSC::Structure::flattenDictionaryStructure):
3905         (JSC::Structure::pin):
3906         (JSC::Structure::copyPropertyTable):
3907         (JSC::Structure::copyPropertyTableForPinning):
3908         (JSC::Structure::get):
3909         (JSC::Structure::despecifyFunction):
3910         (JSC::Structure::despecifyAllFunctions):
3911         (JSC::Structure::putSpecificValue):
3912         (JSC::Structure::remove):
3913         (JSC::Structure::createPropertyMap):
3914         (JSC::Structure::getPropertyNamesFromStructure):
3915         (JSC::Structure::visitChildren):
3916         (JSC::Structure::checkConsistency):
3917         * runtime/Structure.h:
3918         (JSC):
3919         (JSC::Structure::putWillGrowOutOfLineStorage):
3920         (JSC::Structure::materializePropertyMapIfNecessary):
3921         (JSC::Structure::materializePropertyMapIfNecessaryForPinning):
3922         (JSC::Structure::checkOffsetConsistency):
3923         (Structure):
3924         * runtime/StructureInlines.h:
3925         (JSC::Structure::get):
3926         * runtime/WriteBarrier.h:
3927         (JSC::WriteBarrierBase::get):
3928
3929 2013-03-05  David Kilzer  <ddkilzer@apple.com>
3930
3931         BUILD FIX (r144698): Only enable SPEECH_SYNTHESIS for Mac
3932         <http://webkit.org/b/106742>
3933
3934         Fixes the following build failures:
3935
3936             Undefined symbols for architecture i386:
3937               "__ZTVN7WebCore25PlatformSpeechSynthesizerE", referenced from:
3938                   __ZN7WebCore25PlatformSpeechSynthesizerC2EPNS_31PlatformSpeechSynthesizerClientE in PlatformSpeechSynthesizer.o
3939               NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
3940               "__ZN7WebCore25PlatformSpeechSynthesizer19initializeVoiceListEv", referenced from:
3941                   __ZN7WebCore25PlatformSpeechSynthesizerC2EPNS_31PlatformSpeechSynthesizerClientE in PlatformSpeechSynthesizer.o
3942        &nb