ChangeLog 827 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11
2012-10-02  Michael Saboff  <msaboff@apple.com>

        Comment additions after r130109 

        Rubber stamped by Geoffrey Garen.

        Updated comments to how array storage works.

        * runtime/ArrayStorage.h:
        * runtime/JSArray.cpp:

12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
2012-10-01  Mark Hahnenberg  <mhahnenberg@apple.com>

        Block freeing thread should sleep indefinitely when there's no work to do
        https://bugs.webkit.org/show_bug.cgi?id=98084

        Reviewed by Geoffrey Garen.

        Currently the block freeing thread wakes up once a second to check if there are any blocks 
        for it to release back to the OS. This is wasteful. We should change it to sleep when it 
        realizes there are no more blocks to free. Any thread that returns a block to the BlockAllocator 
        should then notify the block freeing thread that there is more work to do now.

        * heap/BlockAllocator.cpp:
        (JSC::BlockAllocator::BlockAllocator):
        (JSC::BlockAllocator::blockFreeingThreadMain):
        * heap/BlockAllocator.h:
        (BlockAllocator):
        (JSC::BlockAllocator::deallocate):

31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
2012-10-01  Michael Saboff  <msaboff@apple.com>

        JSArray::unshiftCountSlowCase needs to clear array slots when adding space to end of array
        https://bugs.webkit.org/show_bug.cgi?id=98101

        Reviewed by Filip Pizlo.

        Cleared new array entries when adding to end due to shifting contents to lower memory.  Also
        checnaged the order of moving array contents and metadata in the shift left case to avoid
        clobbering the metadata with array contents.  Optimized the to only make a memmove if the
        count is non-zero.

        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::unshiftCount):

47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70
2012-10-01  Filip Pizlo  <fpizlo@apple.com>

        Address a FIXME in JSArray::sort
        https://bugs.webkit.org/show_bug.cgi?id=98080
        <rdar://problem/12407844>

        Reviewed by Oliver Hunt.

        Get rid of fast sorting of sparse maps. I don't know that it's broken but I do know that we don't
        have coverage for it. Then also address the FIXME in JSArray::sort regarding side-effecting
        compare functions.

        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSort):
        * runtime/JSArray.cpp:
        (JSC::JSArray::sortNumeric):
        (JSC::JSArray::sort):
        (JSC::JSArray::compactForSorting):
        * runtime/JSArray.h:
        (JSArray):
        * runtime/JSObject.h:
        (JSC::JSObject::hasSparseMap):
        (JSObject):

71 72 73 74 75 76 77 78 79 80 81 82
2012-10-01  Jonathan Liu  <net147@gmail.com>

        Remove unused sys/mman.h include
        https://bugs.webkit.org/show_bug.cgi?id=97995

        Reviewed by Kentaro Hara.

        The sys/mman.h is not used and removing it improves portability as not
        all systems have sys/mman.h.

        * jit/ExecutableAllocatorFixedVMPool.cpp:

83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102
2012-09-28  Filip Pizlo  <fpizlo@apple.com>

        ASSERTION in m_graph[tailNodeIndex].op() == Flush || m_graph[tailNodeIndex].op() == SetLocal on plus.google.com
        https://bugs.webkit.org/show_bug.cgi?id=97656

        Reviewed by Mark Hahnenberg.

        There were two bugs here:
        
        1) In case of multiple GetLocals to the same captured variable, the bytecode parser would linke the first,
           rather than the last, of the GetLocals into the vars-at-tail table.
        
        2) The constant folding phase was asserting that any GetLocal it eliminates must be linked into the
           vars-at-tail table, when for captured variables only the last of those should be.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getLocal):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):

103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119
2012-09-28  Filip Pizlo  <fpizlo@apple.com>

        DFGStructureHoistingPhase SetLocal assumes StructureTransitionWatchpoint has a structure set
        https://bugs.webkit.org/show_bug.cgi?id=97810

        Reviewed by Mark Hahnenberg.

        No tests because this can't happen in ToT: the structure check hoisting phase runs before any
        CFA or folding, so the only StructureTransitionWatchpoints it will see are the ones inserted
        by the parser. But the parser will only insert StructureTransitinWatchpoints on constants, which
        will not be subject to SetLocals.
        
        Still, it would be good to fix this in case things changed.

        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):

120 121 122 123 124 125 126 127 128 129 130
2012-09-27  Mark Lam  <mark.lam@apple.com>

        Put initializeHostCallReturnValue() behind #if ENABLE(JIT).
        Fixes non JIT builds.
        https://bugs.webkit.org/show_bug.cgi?id=97838.

        Reviewed by John Sullivan.

        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):

131 132 133 134 135 136 137 138 139 140 141 142 143
2012-09-27  Mark Lam  <mark.lam@apple.com>

        Fixed CallFrameClosure::resetCallFrame() to use the valid
        range of argument index values.
        https://bugs.webkit.org/show_bug.cgi?id=97836.

        Reviewed by Gavin Barraclough.

        * interpreter/CallFrame.h:
        (ExecState):
        * interpreter/CallFrameClosure.h:
        (JSC::CallFrameClosure::resetCallFrame):

144 145 146 147 148 149 150 151 152 153 154 155 156
2012-09-27  Patrick Gansterer  <paroga@webkit.org>

        Fix usage of COMPILER() macros
        https://bugs.webkit.org/show_bug.cgi?id=97642

        Reviewed by Geoffrey Garen.

        Add COMPILER(GCC) around compiler specific code and remove it from generic code.
        This allows us to implement the DFG code for other compilers to in a next step.

        * dfg/DFGOperations.cpp:
        * jit/HostCallReturnValue.h:

157 158 159 160 161 162 163 164 165 166 167 168 169
2012-09-27  Andreas Kling  <kling@webkit.org>

        3.20MB below FunctionParameters::create() on Membuster3.
        <http://webkit.org/b/97730>

        Reviewed by Anders Carlsson.

        Figure out the exact space needed for parameter identifiers and use reserveInitialCapacity().
        Reduces memory consumption on Membuster3 by ~1.60 MB.

        * parser/Nodes.cpp:
        (JSC::FunctionParameters::FunctionParameters):

170 171 172 173 174 175 176 177 178 179 180 181
2012-09-27  Csaba Osztrogonác  <ossy@webkit.org>, Tor Arne Vestbø  <vestbo@webkit.org>

        [Qt] Enable the LLInt on Linux
        https://bugs.webkit.org/show_bug.cgi?id=95749

        Reviewed by Simon Hausmann.

        * DerivedSources.pri:
        * JavaScriptCore.pro:
        * LLIntOffsetsExtractor.pro: Added.
        * Target.pri:

182 183 184 185 186 187 188
2012-09-27  Patrick Gansterer  <paroga@webkit.org>

        [CMake] Fix build with static JavaScriptCore library

        * shell/CMakeLists.txt: Define STATICALLY_LINKED_WITH_JavaScriptCore if
                                JavaScriptCore_LIBRARY_TYPE is set to STATIC.

189 190 191 192 193 194 195 196 197 198 199 200 201 202 203
2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        Proxy the global this in JSC
        https://bugs.webkit.org/show_bug.cgi?id=97734

        Reviewed by Filip Pizlo.

        Eeep – fix a bug - was leaving the global this proxy's structure's globalObject as 0,
        and setting the proxy's prototype as the global object, rather than its prototype.

        * jsc.cpp:
        (GlobalObject::create):
        * runtime/JSProxy.h:
        (JSC::JSProxy::createStructure):

204 205 206 207 208 209
2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        Speculative Windows build fix.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

210 211 212 213 214 215
2012-09-26  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, 32-bit build fix.

        * llint/LowLevelInterpreter32_64.asm:

216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260
2012-09-26  Filip Pizlo  <fpizlo@apple.com>

        jneq_ptr shouldn't have a pointer
        https://bugs.webkit.org/show_bug.cgi?id=97739

        Reviewed by Oliver Hunt.

        Slamming pointers directly into bytecode is sometimes cool, but in this case it's
        unwieldy and confusing. Switched the instruction to use an enum instead. This has
        zero effect on code gen behavior in the JITs. In the LLInt, there is now more
        indirection, but that doesn't affect benchmarks.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        (Instruction):
        * bytecode/SpecialPointer.cpp: Added.
        (JSC):
        (JSC::actualPointerFor):
        * bytecode/SpecialPointer.h: Added.
        (JSC):
        (JSC::pointerIsFunction):
        (JSC::pointerIsCell):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
        (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_jneq_ptr):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_jneq_ptr):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::actualPointerFor):

261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277
2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        REGRESSION (r129456): http/tests/security/xss-eval.html is failing on JSC platforms
        https://bugs.webkit.org/show_bug.cgi?id=97529

        Reviewed by Filip Pizlo.

        A recent patch changed JSC's EvalError behaviour; bring this more into line with other browsers.

        JSC currently throws an EvalError if you try to call eval with a this object that doesn't
        match the given eval function. This does not match other browsers, which generally just
        ignore the this value that was passed, and eval the string in the eval function's environment.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
            - Remove EvalError, ignore passed this value.

278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300
2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        Proxy the global this in JSC
        https://bugs.webkit.org/show_bug.cgi?id=97734

        Reviewed by Oliver Hunt.

        Having jsc diverge from WebCore here is not beneficial; it potentially masks bugs and/or performance
        problems from command line testing.

        * jsc.cpp:
        (GlobalObject::create):
            - Create a this value proxy for the global object.
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
            - Make setGlobalThis protected.
        * runtime/JSProxy.h:
        (JSC::JSProxy::create):
        (JSC::JSProxy::target):
        (JSC::JSProxy::finishCreation):
        (JSProxy):
            - Allow proxy target to be a JSObject, add target to create method.

301 302 303 304 305 306
2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        Speculative Windows build fix.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

307 308 309 310 311 312 313 314 315 316 317 318 319 320
2012-09-26  Filip Pizlo  <fpizlo@apple.com>

        JSObject::ensureArrayStorage() ignores the possibility that extensions have been prevented
        https://bugs.webkit.org/show_bug.cgi?id=97719

        Reviewed by Gavin Barraclough.

        * runtime/JSObject.cpp:
        (JSC::JSObject::ensureArrayStorageSlow):
        (JSC):
        * runtime/JSObject.h:
        (JSC::JSObject::ensureArrayStorage):
        (JSObject):

321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381
2012-09-26  Gavin Barraclough  <barraclough@apple.com>

        Generalize JSGlobalThis as JSProxy
        https://bugs.webkit.org/show_bug.cgi?id=97716

        Reviewed by Oliver Hunt.

        Generalize JSGlobalThis as JSProxy and move proxying functionality up from the window shell into JSProxy.

        * CMakeLists.txt:
        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * Target.pri:
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::toThisObject):
            - Hoist toThisObject from WebCore.
        (JSC):
        * runtime/JSGlobalObject.h:
            - removed include.
        (JSC::JSGlobalObject::finishCreation):
            - JSGlobalThis -> JSObject
        (JSGlobalObject):
            - Hoist toThisObject from WebCore.
        * runtime/JSGlobalThis.cpp: Removed.
        * runtime/JSGlobalThis.h: Removed.
        * runtime/JSObject.cpp:
            - removed include.
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::isProxy):
            - isGlobalThis -> isProxy
            - GlobalThisType -> ProxyType
        * runtime/JSProxy.cpp: Copied from Source/JavaScriptCore/runtime/JSGlobalThis.cpp.
        (JSC):
        (JSC::JSProxy::visitChildren):
        (JSC::JSProxy::setTarget):
        (JSC::JSProxy::className):
        (JSC::JSProxy::getOwnPropertySlot):
        (JSC::JSProxy::getOwnPropertySlotByIndex):
        (JSC::JSProxy::getOwnPropertyDescriptor):
        (JSC::JSProxy::put):
        (JSC::JSProxy::putByIndex):
        (JSC::JSProxy::putDirectVirtual):
        (JSC::JSProxy::defineOwnProperty):
        (JSC::JSProxy::deleteProperty):
        (JSC::JSProxy::deletePropertyByIndex):
        (JSC::JSProxy::getPropertyNames):
        (JSC::JSProxy::getOwnPropertyNames):
            - Class cretaed from JSGlobalThis, JSDOMWindowShell.
        * runtime/JSProxy.h: Copied from Source/JavaScriptCore/runtime/JSGlobalThis.h.
        (JSC::JSProxy::create):
        (JSC::JSProxy::createStructure):
        (JSProxy):
        (JSC::JSProxy::target):
        (JSC::JSProxy::JSProxy):
            - Class cretaed from JSGlobalThis, JSDOMWindowShell.
        * runtime/JSType.h:
            - GlobalThisType -> ProxyType

382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404
2012-09-26  Michael Saboff  <msaboff@apple.com>

        Add ability for JSArray::unshiftCount to unshift in middle of an array
        https://bugs.webkit.org/show_bug.cgi?id=97691

        Reviewed by Filip Pizlo.

        Changed JSArray::unshiftCount and unshiftCountSlowCase to handle unshifting from the middle of an
        array.  Depending on where the unshift point is, either the front part of the array will be moved
        "left" or the back part will be moved right.  Given that unshiftCount only works on contiguous
        arrays it is safe to use memmove for the moves.

        This change is worth 25% performance improvement on pdfjs.  It doesn't seem to have any impact on
        any other benchmarks.

        * runtime/ArrayPrototype.cpp:
        (JSC::unshift):
        * runtime/JSArray.cpp:
        (JSC::JSArray::unshiftCountSlowCase):
        (JSC::JSArray::unshiftCount):
        * runtime/JSArray.h:
        (JSArray):

405 406 407 408 409 410 411 412 413 414 415 416
2012-09-26  Sheriff Bot  <webkit.review.bot@gmail.com>

        Unreviewed, rolling out r129592.
        http://trac.webkit.org/changeset/129592
        https://bugs.webkit.org/show_bug.cgi?id=97670

        Failures in Chromium security tests (Requested by schenney on
        #webkit).

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):

417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433
2012-09-25  Gavin Barraclough  <barraclough@apple.com>

        REGRESSION (r129456): http/tests/security/xss-eval.html is failing on JSC platforms
        https://bugs.webkit.org/show_bug.cgi?id=97529

        Reviewed by Filip Pizlo.

        A recent patch changed JSC's EvalError behaviour; bring this more into line with other browsers.

        JSC currently throws an EvalError if you try to call eval with a this object that doesn't
        match the given eval function. This does not match other browsers, which generally just
        ignore the this value that was passed, and eval the string in the eval function's environment.

        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
            - Remove EvalError, ignore passed this value.

434 435 436 437 438 439 440 441 442 443 444 445 446 447
2012-09-25  Filip Pizlo  <fpizlo@apple.com>

        DFG ArrayPush, ArrayPop don't handle clobbering or having a bad time correctly
        https://bugs.webkit.org/show_bug.cgi?id=97535

        Reviewed by Oliver Hunt.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):

448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502
2012-09-25  Geoffrey Garen  <ggaren@apple.com>

        JSC should dump object size inference statistics
        https://bugs.webkit.org/show_bug.cgi?id=97618

        Reviewed by Filip Pizlo.

        Added an option to dump object size inference statistics.

        To see statistics on live objects:

            jsc --showHeapStatistics=1

        To see cumulative statistics on all objects ever allocated:

            jsc --showHeapStatistics=1 --objectsAreImmortal=1

            (This is useful for showing GC churn caused by over-allocation.)

        To support this second mode, I refactored Zombies to separate out their
        immortality feature so I could reuse it.

        * heap/Heap.cpp:
        (JSC::MarkObject): Helper for making things immortal. We have to checked
        for being zapped because blocks start out in this state.

        (JSC::StorageStatistics): Gather statistics by walking the heap. Ignore
        arrays and hash tables for now because they're not our focus. (We'll
        remove these exceptions in future.)

        (JSC::Heap::collect): Moved zombify to the end so it wouldn't interfere
        with statistics gathering.

        (JSC::Heap::showStatistics):
        (JSC::Heap::markAllObjects): Factored out helper, so statistics could
        take advantage of immortal objects.

        (Zombify): Don't mark immortal objects -- that's another class's job now.

        (JSC::Zombify::operator()):
        (JSC::Heap::zombifyDeadObjects): Take advantage of forEachDeadCell instead
        of rolling our own.

        * heap/Heap.h:
        (Heap):
        * heap/MarkedSpace.h:
        (MarkedSpace):
        (JSC::MarkedSpace::forEachDeadCell): Added, so clients don't have to do
        the iteration logic themselves.

        * runtime/Options.cpp:
        (JSC::Options::initialize):
        * runtime/Options.h: New options, listed above. Make sure to initialize
        based on environment variable first, so we can override with specific settings.

503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518
2012-09-25  Filip Pizlo  <fpizlo@apple.com>

        We shouldn't use the optimized versions of shift/unshift if the user is doing crazy things to the array
        https://bugs.webkit.org/show_bug.cgi?id=97603
        <rdar://problem/12370864>

        Reviewed by Gavin Barraclough.

        You changed the length behind our backs? No optimizations for you then!

        * runtime/ArrayPrototype.cpp:
        (JSC::shift):
        (JSC::unshift):
        * runtime/JSArray.cpp:
        (JSC::JSArray::shiftCount):

519 520 521 522 523 524 525 526 527 528 529 530 531 532 533
2012-09-25  Filip Pizlo  <fpizlo@apple.com>

        JSC bindings appear to sometimes ignore the possibility of arrays being in sparse mode
        https://bugs.webkit.org/show_bug.cgi?id=95610

        Reviewed by Oliver Hunt.

        Add better support for quickly accessing the indexed storage from bindings.

        * runtime/JSObject.h:
        (JSC::JSObject::tryGetIndexQuickly):
        (JSObject):
        (JSC::JSObject::getDirectIndex):
        (JSC::JSObject::getIndex):

534 535 536 537 538 539 540 541 542 543 544 545 546 547
2012-09-25  Filip Pizlo  <fpizlo@apple.com>

        Structure check hoisting phase doesn't know about the side-effecting nature of Arrayify
        https://bugs.webkit.org/show_bug.cgi?id=97537

        Reviewed by Mark Hahnenberg.

        No tests because if we use Arrayify then we also use PutByVal(BlankToXYZ), and the latter is
        already known to be side-effecting. So this bug shouldn't have had any symptoms, as far as I
        can tell.

        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):

548 549 550 551 552 553 554 555 556 557 558
2012-09-25  Gavin Barraclough  <barraclough@apple.com>

        Regression: put beyond vector length prefers prototype setters to sparse properties
        https://bugs.webkit.org/show_bug.cgi?id=97593

        Reviewed by Geoff Garen & Filip Pizlo.

        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndexBeyondVectorLength):
            - Check for self properties in the sparse map - if present, don't examine the protochain.

559 560 561 562 563 564 565 566 567 568 569 570 571 572
2012-09-24  Gavin Barraclough  <barraclough@apple.com>

        https://bugs.webkit.org/show_bug.cgi?id=97530
        Regression, freeze applied to numeric properties of non-array objects

        Reviewed by Filip Pizlo.

        Object.freeze has a fast implementation in JSObject, but this hasn't been updated to take into account numeric properties in butterflies.
        For now, just fall back to the generic implementation if the object has numeric properties.

        * runtime/ObjectConstructor.cpp:
        (JSC::objectConstructorFreeze):
            - fallback if the object has a non-zero indexed property vector length.

573 574 575 576 577 578 579 580 581 582 583 584 585 586 587
2012-09-24  Gavin Barraclough  <barraclough@apple.com>

        Bug in numeric accessors on global environment
        https://bugs.webkit.org/show_bug.cgi?id=97526

        Reviewed by Geoff Garen.

        I've hit this assert in test262 in browser, but haven't yet worked out how to repro in a test case :-/
        The sparsemap is failing to map back from the global object to the window shell.
        A test case would need to resolve a numeric property name against the global environment.

        (JSC::SparseArrayEntry::get):
        (JSC::SparseArrayEntry::put):
            - Add missing toThisObject calls.

588 589 590 591 592 593 594 595 596 597 598 599 600 601
2012-09-24  Filip Pizlo  <fpizlo@apple.com>

        SerializedScriptValue isn't aware of indexed storage, but should be
        https://bugs.webkit.org/show_bug.cgi?id=97515
        <rdar://problem/12361874>

        Reviewed by Sam Weinig.

        Export a method that WebCore now uses.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * runtime/JSObject.h:
        (JSObject):

602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632
2012-09-24  Gavin Barraclough  <barraclough@apple.com>

        Remove JSObject::unwrappedGlobalObject(), JSObject::unwrappedObject()
        https://bugs.webkit.org/show_bug.cgi?id=97519

        Reviewed by Geoff Garen.

        unwrappedGlobalObject() was only needed because globalObject() doesn't always return a helpful result -
        specifically for WebCore's window shell the structure's globalObject is set to null. We can fix this by
        simply keeping the structure up to date as the window navigates, obviating the need for this function.

        The only other use of unwrappedObject() came from globalFuncEval(), and this can be trivially removed
        by flipping the way we perform this globalObject check (which we may also be able to remove!) - instead
        of getting the globalObject from the provided this value & comparing to the expected globalObject, we
        can get the this value from the expected globalObject, and compare to that provided.

        * runtime/JSGlobalObject.cpp:
            - Call globalObject() instead of unwrappedGlobalObject().
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::globalFuncEval):
            - Changed to compare this object values, instead of globalObjects -
              this means we only need to be able to map globalObject -> this,
              and not vice versa.
        * runtime/JSObject.cpp:
        (JSC::JSObject::allowsAccessFrom):
        (JSC::JSObject::createInheritorID):
            - Call globalObject() instead of unwrappedGlobalObject().
        * runtime/JSObject.h:
        (JSObject):
            - Removed unwrappedGlobalObject(), unwrappedObject().

633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695
2012-09-24  Mark Lam  <mark.lam@apple.com>

        Deleting the classic interpreter and cleaning up some build options.
        https://bugs.webkit.org/show_bug.cgi?id=96969.

        Reviewed by Geoffrey Garen.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::stronglyVisitStrongReferences):
        (JSC):
        * bytecode/Instruction.h:
        (JSC::Instruction::Instruction):
        * interpreter/AbstractPC.cpp:
        (JSC::AbstractPC::AbstractPC):
        * interpreter/AbstractPC.h:
        (AbstractPC):
        * interpreter/CallFrame.h:
        (ExecState):
        * interpreter/Interpreter.cpp:
        (JSC):
        (JSC::Interpreter::Interpreter):
        (JSC::Interpreter::~Interpreter):
        (JSC::Interpreter::initialize):
        (JSC::Interpreter::isOpcode):
        (JSC::Interpreter::unwindCallFrame):
        (JSC::getLineNumberForCallFrame):
        (JSC::getCallerInfo):
        (JSC::getSourceURLFromCallFrame):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::retrieveArgumentsFromVMCode):
        (JSC::Interpreter::retrieveCallerFromVMCode):
        (JSC::Interpreter::retrieveLastCaller):
        * interpreter/Interpreter.h:
        (JSC::Interpreter::getOpcodeID):
        (Interpreter):
        * jit/ExecutableAllocatorFixedVMPool.cpp:
        (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator):
        * offlineasm/asm.rb:
        * offlineasm/offsets.rb:
        * runtime/Executable.cpp:
        (JSC::EvalExecutable::compileInternal):
        (JSC::ProgramExecutable::compileInternal):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::compileForConstructInternal):
        * runtime/Executable.h:
        (JSC::NativeExecutable::create):
        (NativeExecutable):
        (JSC::NativeExecutable::finishCreation):
        * runtime/JSGlobalData.cpp:
        (JSC):
        (JSC::JSGlobalData::JSGlobalData):
        (JSC::JSGlobalData::getHostFunction):
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        (JSC::JSGlobalData::canUseJIT):
        (JSC::JSGlobalData::canUseRegExpJIT):
        * runtime/Options.cpp:
        (JSC::Options::initialize):

696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711
2012-09-24  Filip Pizlo  <fpizlo@apple.com>

        Nested try/finally should not confuse the finally unpopper in BytecodeGenerator::emitComplexJumpScopes
        https://bugs.webkit.org/show_bug.cgi?id=97508
        <rdar://problem/12361132>

        Reviewed by Sam Weinig.

        We're reusing some vector for multiple iterations of a loop, but we were forgetting to clear its
        contents from one iteration to the next. Hence if you did multiple iterations of finally unpopping
        (like in a nested try/finally and a jump out of both of them) then you'd get a corrupted try
        context stack afterwards.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitComplexJumpScopes):

712 713 714 715 716 717 718 719 720 721 722
2012-09-24  Filip Pizlo  <fpizlo@apple.com>

        ValueToInt32 bool case does bad things to registers
        https://bugs.webkit.org/show_bug.cgi?id=97505
        <rdar://problem/12356331>

        Reviewed by Mark Hahnenberg.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):

723 724 725 726 727 728 729 730 731 732 733
2012-09-24  Mark Lam  <mark.lam@apple.com>

        Add cloopDo instruction for debugging the llint C++ backend.
        https://bugs.webkit.org/show_bug.cgi?id=97502.

        Reviewed by Geoffrey Garen.

        * offlineasm/cloop.rb:
        * offlineasm/instructions.rb:
        * offlineasm/parser.rb:

734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759
2012-09-24  Filip Pizlo  <fpizlo@apple.com>

        JSArray::putByIndex asserts with readonly property on prototype
        https://bugs.webkit.org/show_bug.cgi?id=97435
        <rdar://problem/12357084>

        Reviewed by Geoffrey Garen.

        Boy, there were some problems:
        
        - putDirectIndex() should know that it can set the index quickly even if it's a hole and we're
          in SlowPut mode, since that's the whole point of PutDirect.
        
        - We should have a fast path for putByIndex().
        
        - The LiteralParser should not use push(), since that may throw if we're having a bad time.

        * interpreter/Interpreter.cpp:
        (JSC::eval):
        * runtime/JSObject.h:
        (JSC::JSObject::putByIndexInline):
        (JSObject):
        (JSC::JSObject::putDirectIndex):
        * runtime/LiteralParser.cpp:
        (JSC::::parse):

760 761 762 763 764 765 766 767 768 769
2012-09-24  Mark Lam  <mark.lam@apple.com>

        Added a missing "if VALUE_PROFILER" around an access to ArrayProfile record.
        https://bugs.webkit.org/show_bug.cgi?id=97496.

        Reviewed by Filip Pizlo.

        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797
2012-09-24  Geoffrey Garen  <ggaren@apple.com>

        Inlined activation tear-off in the DFG
        https://bugs.webkit.org/show_bug.cgi?id=97487

        Reviewed by Filip Pizlo.

        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h: Activation tear-off is always inlined now, so I
        removed its out-of-line implementation.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Inlined the variable copy and update
        of JSVariableObject::m_registers. This usually turns into < 10 instructions,
        which is close to pure win as compared to the operation function call.

        * runtime/JSActivation.h:
        (JSActivation):
        (JSC::JSActivation::registersOffset):
        (JSC::JSActivation::tearOff):
        (JSC::JSActivation::isTornOff):
        (JSC):
        (JSC::JSActivation::storageOffset):
        (JSC::JSActivation::storage): Tiny bit of refactoring so the JIT can
        share the pointer math helper functions we use internally.

798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818
2012-09-24  Balazs Kilvady  <kilvadyb@homejinni.com>

        MIPS: store8 functions added to MacroAssembler.

        MIPS store8 functions
        https://bugs.webkit.org/show_bug.cgi?id=97243

        Reviewed by Oliver Hunt.

        Add MIPS store8 functions.

        * assembler/MIPSAssembler.h:
        (JSC::MIPSAssembler::lhu): New function.
        (MIPSAssembler):
        (JSC::MIPSAssembler::sb): New function.
        (JSC::MIPSAssembler::sh): New function.
        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::store8): New function.
        (MacroAssemblerMIPS):
        (JSC::MacroAssemblerMIPS::store16): New function.

819 820 821 822 823 824 825 826 827 828 829 830 831 832 833
2012-09-23  Geoffrey Garen  <ggaren@apple.com>

        PutScopedVar should not be marked as clobbering the world
        https://bugs.webkit.org/show_bug.cgi?id=97416

        Reviewed by Filip Pizlo.

        No performance change.

        PutScopedVar doesn't have arbitrary side-effects, so it shouldn't be marked
        as such.

        * dfg/DFGNodeType.h:
        (DFG):

834 835 836 837 838 839 840 841 842
2012-09-23  Geoffrey Garen  <ggaren@apple.com>

        I accidentally the whole 32-bit :(.

        Unbreak the DFG in 32-bit with the 32-bit path I forgot in my last patch.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862
2012-09-23  Byungwoo Lee  <bw80.lee@gmail.com>

        Fix build warnings : -Wunused-parameter, -Wparentheses, -Wuninitialized.
        https://bugs.webkit.org/show_bug.cgi?id=97306

        Reviewed by Benjamin Poulain.

        Fix build warning about -Wunused-parameter on MachineStackMarker.cpp,
        LLIntSlowPaths.cpp, DatePrototype.cpp, Options.cpp by using
        UNUSED_PARAM() macro or remove parameter name.

        * heap/MachineStackMarker.cpp:
        (JSC::pthreadSignalHandlerSuspendResume):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::entryOSR):
        * runtime/DatePrototype.cpp:
        (JSC::formatLocaleDate):
        * runtime/Options.cpp:
        (JSC::computeNumberOfGCMarkers):

863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878
2012-09-23  Gavin Barraclough  <barraclough@apple.com>

        Sorting a non-array creates propreties (spec-violation)
        https://bugs.webkit.org/show_bug.cgi?id=25477

        Reviewed by Oliver Hunt.

        We're just calling get() to get properties, which is converting missing properties to
        undefined. Hole values should be retained, and moved to the end of the array.

        * runtime/ArrayPrototype.cpp:
        (JSC::getOrHole):
            - Helper function, returns JSValue() instead of undefined for missing properties.
        (JSC::arrayProtoFuncSort):
            - Implemented per 15.4.4.11, see comments above.

879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926
2012-09-23  Geoffrey Garen  <ggaren@apple.com>

        CSE for access to closure variables (get_/put_scoped_var)
        https://bugs.webkit.org/show_bug.cgi?id=97414

        Reviewed by Oliver Hunt.

        I separated loading a scope from loading its storage pointer, so we can
        CSE the storage pointer load. Then, I copied the global var CSE and adjusted
        it for closure vars.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute): Renamed GetScopeChain => GetScope to
        reflect renames from a few weeks ago.

        Added a case for the storage pointer load, similar to object storage pointer load.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): Added an independent node for
        the storage pointer.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::scopedVarLoadElimination):
        (CSEPhase):
        (JSC::DFG::CSEPhase::scopedVarStoreElimination):
        (JSC::DFG::CSEPhase::getScopeLoadElimination):
        (JSC::DFG::CSEPhase::getScopeRegistersLoadElimination):
        (JSC::DFG::CSEPhase::setLocalStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE): Copied globalVarLoad/StoreElimination
        and adapted the same logic to closure vars.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasScopeChainDepth):
        (JSC::DFG::Node::scope):
        (Node):
        * dfg/DFGNodeType.h:
        (DFG): GetScopedVar and GetGlobalVar are no longer MustGenerate. I'm not
        sure why they ever were. But these are simple load operations so, if they're
        unused, they're truly dead.

        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Updated for renames and split-out
        node for getting the storage pointer.

927 928 929 930 931 932 933
2012-09-21  Geoffrey Garen  <ggaren@apple.com>

        Unreviewed, rolled out a line I committed by accident.

        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):

934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035
2012-09-21  Geoffrey Garen  <ggaren@apple.com>

        Optimized closures that capture arguments
        https://bugs.webkit.org/show_bug.cgi?id=97358

        Reviewed by Oliver Hunt.

        Previously, the activation object was responsible for capturing all
        arguments in a way that was convenient for the arguments object. Now,
        we move all captured variables into a contiguous region in the stack,
        allocate an activation for exactly that size, and make the arguments
        object responsible for knowing all the places to which arguments could
        have moved.

        This seems like the right tradeoff because

            (a) Closures are common and long-lived, so we want them to be small.

            (b) Our primary strategy for optimizing the arguments object is to make
            it go away. If you're allocating arguments objects, you're already having
            a bad time.

            (c) It's common to use either the arguments object or named argument
            closure, but not both.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::argumentsRegister):
        (JSC::CodeBlock::activationRegister):
        (JSC::CodeBlock::isCaptured):
        (JSC::CodeBlock::argumentIndexAfterCapture): m_numCapturedVars is gone
        now -- we have an explicit range instead.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Move captured arguments
        into the captured region of local variables for space efficiency. Record
        precise data about where they moved for the sake of the arguments object.

        Some of this data was previously wrong, but it didn't cause any problems
        because the arguments weren't actually moving.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::flushArgumentsAndCapturedVariables): Don't
        assume that captured vars are in any particular location -- always ask
        the CodeBlock. This is better encapsulation.

        (JSC::DFG::ByteCodeParser::parseCodeBlock):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): I rename things sometimes.

        * runtime/Arguments.cpp:
        (JSC::Arguments::tearOff): Account for a particularly nasty edge case.

        (JSC::Arguments::didTearOffActivation): Don't allocate our slow arguments
        data on tear-off. We need to allocate it eagerly instead, since we need
        to know about displaced, captured arguments during access before tear-off.

        * runtime/Arguments.h:
        (JSC::Arguments::allocateSlowArguments):
        (JSC::Arguments::argument): Tell our slow arguments array where all arguments
        are, even if they are not captured. This simplifies some things, so we don't
        have to account explicitly for the full matrix of (not torn off, torn off)
        * (captured, not captured).

        (JSC::Arguments::finishCreation): Allocate our slow arguments array eagerly
        because we need to know about displaced, captured arguments during access
        before tear-off.

        * runtime/Executable.cpp:
        (JSC::FunctionExecutable::FunctionExecutable):
        (JSC::FunctionExecutable::compileForCallInternal):
        (JSC::FunctionExecutable::compileForConstructInternal):
        * runtime/Executable.h:
        (JSC::FunctionExecutable::parameterCount):
        (FunctionExecutable):
        * runtime/JSActivation.cpp:
        (JSC::JSActivation::visitChildren):
        * runtime/JSActivation.h:
        (JSActivation):
        (JSC::JSActivation::create):
        (JSC::JSActivation::JSActivation):
        (JSC::JSActivation::registerOffset):
        (JSC::JSActivation::tearOff):
        (JSC::JSActivation::allocationSize):
        (JSC::JSActivation::isValid): This is really the point of the patch. All
        the pointer math in Activations basically boils away, since we always
        copy a contiguous region of captured variables now.

        * runtime/SymbolTable.h:
        (JSC::SlowArgument::SlowArgument):
        (SlowArgument):
        (SharedSymbolTable):
        (JSC::SharedSymbolTable::captureCount):
        (JSC::SharedSymbolTable::SharedSymbolTable): AllOfTheThings capture mode
        is gone now -- that's the point of the patch. indexIfCaptured gets renamed
        to index because we always have an index, even if not captured. (The only
        time when the index is meaningless is when we're Deleted.)

1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047
2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Eeeep - broke early boyer in bug#97382
        https://bugs.webkit.org/show_bug.cgi?id=97383

        Rubber stamped by Sam Weinig.

        missed a child3 -> child2!

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):

1048 1049 1050 1051 1052 1053
2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Unreviewed windows build fix.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068
2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Pedantic test in Mozilla's JavaScript test suite fails. function-001.js function-001-n.js
        https://bugs.webkit.org/show_bug.cgi?id=27219

        Reviewed by Sam Weinig.

        These tests are just wrong.
        See ECMA 262 A.5, FunctionDelcaration does not require a semicolon.

        * tests/mozilla/expected.html:
        * tests/mozilla/js1_2/function/function-001-n.js:
        * tests/mozilla/js1_3/Script/function-001-n.js:
        * tests/mozilla/js1_3/regress/function-001-n.js:

1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109
2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Remove redundant argument to op_instanceof
        https://bugs.webkit.org/show_bug.cgi?id=97382

        Reviewed by Geoff Garen.

        No longer needed after my last change.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitInstanceOf):
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::InstanceOfNode::emitBytecode):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::privateExecute):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

1110 1111 1112 1113 1114 1115
2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Unreviewed windows build fix.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218
2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        instanceof should not get the prototype for non-default HasInstance
        https://bugs.webkit.org/show_bug.cgi?id=68656

        Reviewed by Oliver Hunt.

        Instanceof is currently implemented as a sequance of three opcodes:
            check_has_instance
            get_by_id(prototype)
            op_instanceof
        There are three interesting types of base value that instanceof can be applied to:
            (A) Objects supporting default instanceof behaviour (functions, other than those created with bind)
            (B) Objects overriding the default instancecof behaviour with a custom one (API objects, bound functions)
            (C) Values that do not respond to the [[HasInstance]] trap.
        Currently check_has_instance handles case (C), leaving the op_instanceof opcode to handle (A) & (B). There are
        two problems with this apporach. Firstly, this is suboptimal for case (A), since we have to check for
        hasInstance support twice (once in check_has_instance, then for default behaviour in op_instanceof). Secondly,
        this means that in cases (B) we also perform the get_by_id, which is both suboptimal and an observable spec
        violation.

        The fix here is to move handing of non-default instanceof (cases (B)) to the check_has_instance op, leaving
        op_instanceof to handle only cases (A).

        * API/JSCallbackObject.h:
        (JSCallbackObject):
        * API/JSCallbackObjectFunctions.h:
        (JSC::::customHasInstance):
        * API/JSValueRef.cpp:
        (JSValueIsInstanceOfConstructor):
            - renamed hasInstance to customHasInstance
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dump):
            - added additional parameters to check_has_instance opcode
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
            - added additional parameters to check_has_instance opcode
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitCheckHasInstance):
            - added additional parameters to check_has_instance opcode
        * bytecompiler/BytecodeGenerator.h:
        (BytecodeGenerator):
            - added additional parameters to check_has_instance opcode
        * bytecompiler/NodesCodegen.cpp:
        (JSC::InstanceOfNode::emitBytecode):
            - added additional parameters to check_has_instance opcode
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
            - added additional parameters to check_has_instance opcode
        * interpreter/Interpreter.cpp:
        (JSC::isInvalidParamForIn):
        (JSC::Interpreter::privateExecute):
            - Add handling for non-default instanceof to op_check_has_instance
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitArrayProfilingSiteForBytecodeIndex):
            - Fixed no-LLInt no_DFG build
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_check_has_instance):
        (JSC::JIT::emitSlow_op_check_has_instance):
            - check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance.
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
            - no need to check for ImplementsDefaultHasInstance.
        * jit/JITOpcodes32_64.cpp:
        (JSC::JIT::emit_op_check_has_instance):
        (JSC::JIT::emitSlow_op_check_has_instance):
            - check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance.
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emitSlow_op_instanceof):
            - no need to check for ImplementsDefaultHasInstance.
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * jit/JITStubs.h:
            - Add handling for non-default instanceof to op_check_has_instance
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
            - move check for ImplementsDefaultHasInstance, handle additional arguments to op_check_has_instance.
        * runtime/ClassInfo.h:
        (MethodTable):
        (JSC):
            - renamed hasInstance to customHasInstance
        * runtime/CommonSlowPaths.h:
        (CommonSlowPaths):
            - removed opInstanceOfSlow (this was whittled down to one function call!)
        * runtime/JSBoundFunction.cpp:
        (JSC::JSBoundFunction::customHasInstance):
        * runtime/JSBoundFunction.h:
        (JSBoundFunction):
            - renamed hasInstance to customHasInstance, reimplemented.
        * runtime/JSCell.cpp:
        (JSC::JSCell::customHasInstance):
        * runtime/JSCell.h:
        (JSCell):
        * runtime/JSObject.cpp:
        (JSC::JSObject::hasInstance):
        (JSC):
        (JSC::JSObject::defaultHasInstance):
        * runtime/JSObject.h:
        (JSObject):

fpizlo@apple.com's avatar
fpizlo@apple.com committed
1219 1220 1221 1222 1223 1224 1225 1226 1227
2012-09-21  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix ARM build.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::store8):
        (MacroAssemblerARMv7):
        * offlineasm/armv7.rb:

1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252
2012-09-21  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r128400): Opening Google Web Fonts page hangs or crashes
        https://bugs.webkit.org/show_bug.cgi?id=97328

        Reviewed by Mark Hahnenberg.

        It's a bad idea to emit stub code that reallocates property storage when we're in indexed
        storage mode. DFGRepatch.cpp knew this and had the appropriate check in one of the places,
        but it didn't have it in all of the places.
        
        This change also adds some more handy disassembly support, which I used to find the bug.

        * assembler/LinkBuffer.h:
        (JSC):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::emitPutReplaceStub):
        (JSC::DFG::emitPutTransitionStub):
        (JSC::DFG::tryCachePutByID):
        * jit/JITStubRoutine.h:
        (JSC):

1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267
2012-09-21  Filip Pizlo  <fpizlo@apple.com>

        DFG CSE assumes that a holy PutByVal does not interfere with GetArrayLength, when it clearly does
        https://bugs.webkit.org/show_bug.cgi?id=97373

        Reviewed by Mark Hahnenberg.

        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::pureCSE):
        (JSC::DFG::CSEPhase::getArrayLengthElimination):
        (JSC::DFG::CSEPhase::putStructureStoreElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGGraph.h:
        (Graph):

1268 1269 1270 1271 1272 1273 1274 1275 1276
2012-09-21  Chris Rogers  <crogers@google.com>

        Add Web Audio support for deprecated/legacy APIs
        https://bugs.webkit.org/show_bug.cgi?id=97050

        Reviewed by Eric Carlson.

        * Configurations/FeatureDefines.xcconfig:

1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289
2012-09-21  Gavin Barraclough  <barraclough@apple.com>

        Global Math object should be configurable but isn't
        https://bugs.webkit.org/show_bug.cgi?id=55343

        Reviewed by Oliver Hunt.

        This has no performance impact.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
            - Make 'Math' a regular property.

1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302
2012-09-21  Chao-ying Fu  <fu@mips.com>

        Add MIPS or32 function
        https://bugs.webkit.org/show_bug.cgi?id=97157

        Reviewed by Gavin Barraclough.

        Add a missing or32 function.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::or32): New function.
        (MacroAssemblerMIPS):

1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343
2012-09-20  Filip Pizlo  <fpizlo@apple.com>

        CHECK_ARRAY_CONSISTENCY isn't being used or tested, so we should remove it
        https://bugs.webkit.org/show_bug.cgi?id=97260

        Rubber stamped by Geoffrey Garen.
        
        Supporting it will become difficult as we add more indexing types. It makes more
        sense to kill, especially since we don't appear to use it or test it, ever.

        * runtime/ArrayConventions.h:
        (JSC):
        * runtime/ArrayPrototype.cpp:
        (JSC::arrayProtoFuncSplice):
        * runtime/ArrayStorage.h:
        (JSC::ArrayStorage::copyHeaderFromDuringGC):
        (ArrayStorage):
        * runtime/FunctionPrototype.cpp:
        (JSC::functionProtoFuncBind):
        * runtime/JSArray.cpp:
        (JSC::createArrayButterflyInDictionaryIndexingMode):
        (JSC::JSArray::setLength):
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::sortNumeric):
        (JSC::JSArray::sort):
        (JSC::JSArray::compactForSorting):
        * runtime/JSArray.h:
        (JSArray):
        (JSC::createArrayButterfly):
        (JSC::JSArray::tryCreateUninitialized):
        (JSC::constructArray):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC):
        * runtime/JSObject.h:
        (JSC::JSObject::initializeIndex):
        (JSObject):

1344 1345 1346 1347 1348 1349 1350 1351 1352
2012-09-20  Mark Lam  <mark.lam@apple.com>

        Fixed a missing semicolon in the C++ llint backend.
        https://bugs.webkit.org/show_bug.cgi?id=97252.

        Reviewed by Geoff Garen.

        * offlineasm/cloop.rb:

1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410
2012-09-20  Geoffrey Garen  <ggaren@apple.com>

        Refactored the interpreter and JIT so they don't dictate closure layout
        https://bugs.webkit.org/show_bug.cgi?id=97221

        Reviewed by Oliver Hunt.

        Capture may change the location of an argument for space efficiency. This
        patch removes static assumptions about argument location from the interpreter
        and JIT.

        * bytecode/CodeBlock.h:
        (JSC::CodeBlock::argumentIndexAfterCapture):
        (JSC::ExecState::argumentAfterCapture): Factored out a helper function
        so the compiler could share this logic.

        * bytecompiler/NodesCodegen.cpp:
        (JSC::BracketAccessorNode::emitBytecode): Don't emit optimized bracket
        access on arguments if a parameter has been captured by name. This case is
        rare and, where I've seen it in the wild, the optimization mostly failed
        anyway due to arguments escape, so I didn't feel like writing and testing
        five copies of the code that would handle it in the baseline engines.

        The DFG can still synthesize this optimization even if we don't emit the
        optimized bytecode for it.

        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::symbolTableFor):
        (AssemblyHelpers): Use the right helper function to account for the fact
        that a parameter may have been captured by name and moved.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock): ASSERT that we haven't inlined
        a .apply on captured arguments. Once we do start inlining such things,
        we'll need to do a little bit of math here to get them right.

        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Added support for bracket access on
        an arguments object where arguments have also been captured by name. We
        load the true index of the argument from a side vector. Arguments elision
        is very powerful in the DFG, so I wanted to keep it working, even in this
        rare case.

        * interpreter/Interpreter.cpp:
        (JSC::loadVarargs): Use the right helper function to account for the fact
        that a parameter may have been captured by name and moved.

        * jit/JITCall.cpp:
        (JSC::JIT::compileLoadVarargs):
        * jit/JITCall32_64.cpp:
        (JSC::JIT::compileLoadVarargs): Don't use the inline copy loop if some
        of our arguments have moved, since it would copy stale values. (We still
        optimize the actual call, and elide the arguments object.)

1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423
2012-09-20  Gabor Rapcsanyi  <rgabor@webkit.org>

        [Qt] r129045 broke the ARM build
        https://bugs.webkit.org/show_bug.cgi?id=97195

        Reviewed by Zoltan Herczeg.

        Implementing missing store8 function.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::store8):
        (MacroAssemblerARM):

1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474
2012-09-19  Geoffrey Garen  <ggaren@apple.com>

        OSR exit sometimes neglects to create the arguments object
        https://bugs.webkit.org/show_bug.cgi?id=97162

        Reviewed by Filip Pizlo.

        No performance change.

        I don't know of any case where this is a real problem in TOT, but it
        will become a problem if we start compiling eval, with, or catch, and/or
        sometimes stop doing arguments optimizations in the bytecode.

        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run): Account for a
        CreateArguments that has transformed into PhantomArguments. We used to
        clear our reference to the CreateArguments node, but now we hold onto it, 
        so we need to account for it transforming.

        Don't replace a SetLocal(CreateArguments) with a SetLocal(JSValue())
        because that doesn't leave enough information behind for OSR exit to do
        the right thing. Instead, maintain our reference to CreateArguments, and
        rely on CreateArguments transforming into PhantomArguments after
        optimization. SetLocal(PhantomArguments) is efficient, and it's a marker
        for OSR exit to create the arguments object.

        Don't ASSERT that all PhantomArguments are unreferenced because we now
        leave them in the graph as SetLocal(PhantomArguments), and that's harmless.

        * dfg/DFGArgumentsSimplificationPhase.h:
        (NullableHashTraits):
        (JSC::DFG::NullableHashTraits::emptyValue): Export our special hash table
        for inline call frames so the OSR exit compiler can use it.

        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit): Don't load the 'arguments'
        register to decide if we need to create the arguments object. Optimization
        may have eliminated the initializing store to this register, in which
        case we'll load garbage. Instead, use the global knowledge that all call
        frames that optimized out 'arguments' now need to create it, and use a hash
        table to make sure we do so only once per call frame.

        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): SetLocal(PhantomArguments) is unique
        because we haven't just changed a value's format or elided a load or store;
        instead, we've replaced an object with JSValue(). We could try to account
        for this in a general way, but for now it's a special-case optimization,
        so we give it a specific OSR hint instead.

1475 1476 1477 1478 1479 1480 1481 1482 1483 1484
2012-09-19  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r128802): It made some JS tests crash
        https://bugs.webkit.org/show_bug.cgi?id=97001

        Reviewed by Mark Hahnenberg.

        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::visitChildren):

1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511
2012-09-19  Filip Pizlo  <fpizlo@apple.com>

        DFG should not assume that a ByVal access is generic just because it was unprofiled
        https://bugs.webkit.org/show_bug.cgi?id=97088

        Reviewed by Geoffrey Garen.
        
        We were not disambiguating between "Undecided" in the sense that the array profile
        has no useful information versus "Undecided" in the sense that the array profile
        knows that the access has not executed. That's an important distinction, since
        the former form of "Undecided" means that we should consult value profiling, while
        the latter means that we should force exit unless the value profiling indicates
        that the access must be generic (base is not cell or property is not int).

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (JSC::DFG::refineArrayMode):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::canCSEStorage):
        (JSC::DFG::modeIsSpecific):
        (JSC::DFG::modeSupportsLength):
        (JSC::DFG::benefitsFromStructureCheck):

1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562
2012-09-19  Filip Pizlo  <fpizlo@apple.com>

        DFG should not emit PutByVal hole case unless it has to
        https://bugs.webkit.org/show_bug.cgi?id=97080

        Reviewed by Geoffrey Garen.

        This causes us to generate less code for typical PutByVal's. But if profiling tells us
        that the hole case is being hit, we generate the same code as we would have generated
        before. This seems like a slight speed-up across the board.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::store8):
        (MacroAssemblerARMv7):
        * assembler/MacroAssemblerX86.h:
        (MacroAssemblerX86):
        (JSC::MacroAssemblerX86::store8):
        * assembler/MacroAssemblerX86_64.h:
        (MacroAssemblerX86_64):
        (JSC::MacroAssemblerX86_64::store8):
        * assembler/X86Assembler.h:
        (X86Assembler):
        (JSC::X86Assembler::movb_i8m):
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::ArrayProfile):
        (JSC::ArrayProfile::addressOfMayStoreToHole):
        (JSC::ArrayProfile::mayStoreToHole):
        (ArrayProfile):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (JSC::DFG::mayStoreToHole):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.h:
        (JIT):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitArrayProfileStoreToHoleSpecialCase):
        (JSC):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_put_by_val):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_put_by_val):
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639
2012-09-18  Filip Pizlo  <fpizlo@apple.com>

        DFG should not call out to C++ every time that it tries to put to an object that doesn't yet have array storage
        https://bugs.webkit.org/show_bug.cgi?id=96983

        Reviewed by Oliver Hunt.

        Introduce more polymorphism into the DFG's array mode support. Use that to
        introduce the notion of effectul array modes, where the check for the mode
        will perform actions necessary to ensure that we have the mode we want, if
        the object is not already in that mode. Also added profiling support for
        checking if an object is of a type that would not allow us to create array
        storage (like a typed array or a string for example).
        
        This is a ~2x speed-up on loops that transform an object that did not have
        indexed storage into one that does.

        * JSCTypedArrayStubs.h:
        (JSC):
        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::ArrayProfile):
        (JSC::ArrayProfile::mayInterceptIndexedAccesses):
        (ArrayProfile):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (DFG):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (JSC::DFG::modeUsesButterfly):
        (JSC::DFG::isSlowPutAccess):
        (JSC::DFG::benefitsFromStructureCheck):
        (JSC::DFG::isEffectful):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasArrayMode):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::arrayify):
        (DFG):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/Arguments.h:
        (Arguments):
        * runtime/JSNotAnObject.h:
        (JSNotAnObject):
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::ensureArrayStorage):
        * runtime/JSString.h:
        (JSC::JSString::createStructure):

1640 1641 1642 1643 1644 1645 1646 1647 1648 1649
2012-09-18  Filip Pizlo  <fpizlo@apple.com>

        Include PhantomArguments in DFGDisassembly
        https://bugs.webkit.org/show_bug.cgi?id=97043

        Reviewed by Geoffrey Garen.

        * dfg/DFGNode.h:
        (JSC::DFG::Node::willHaveCodeGenOrOSR):

1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662
2012-09-18  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION(r128802): It made some JS tests crash
        https://bugs.webkit.org/show_bug.cgi?id=97001

        Reviewed by Mark Hahnenberg.

        IndexingHeaderInlineMethods was incorrectly assuming that if the HasArrayStorage bit is clear, then that means that indexing payload capacity is zero.

        * runtime/IndexingHeaderInlineMethods.h:
        (JSC::IndexingHeader::preCapacity):
        (JSC::IndexingHeader::indexingPayloadSizeInBytes):

1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673
2012-09-18  Mark Hahnenberg  <mhahnenberg@apple.com>

        Use WTF::HasTrivialDestructor instead of compiler-specific versions in JSC::NeedsDestructor
        https://bugs.webkit.org/show_bug.cgi?id=96980

        Reviewed by Benjamin Poulain.

        * runtime/JSCell.h:
        (JSC):
        (NeedsDestructor):

1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684
2012-09-18  Filip Pizlo  <fpizlo@apple.com>

        DFGOperations doesn't use NativeCallFrameTracer in enough places
        https://bugs.webkit.org/show_bug.cgi?id=96987

        Reviewed by Mark Hahnenberg.

        Anything that can GC should use it.

        * dfg/DFGOperations.cpp:

1685 1686 1687 1688 1689 1690 1691 1692
2012-09-18  Mark Lam  <mark.lam@apple.com>

        Not reviewed. Attempt at greening the WinCairo bot. Touching
        LowLevelInterpreter.asm to trigger a rebuild of LLIntDesiredOffsets.
        https://bugs.webkit.org/show_bug.cgi?id=96992.

        * llint/LowLevelInterpreter.asm:

1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705
2012-09-18  Peter Gal  <galpeter@inf.u-szeged.hu>

        [Qt] REGRESSION(r128790): It broke the ARM build
        https://bugs.webkit.org/show_bug.cgi?id=96968

        Reviewed by Filip Pizlo.

        Implement the missing or32 method in the MacroAssemblerARM.h.

        * assembler/MacroAssemblerARM.h:
        (JSC::MacroAssemblerARM::or32):
        (MacroAssemblerARM):

mark.lam@apple.com's avatar
mark.lam@apple.com committed
1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728
2012-09-18  Mark Lam  <mark.lam@apple.com>

        Fix for WinCairo builds.
        https://bugs.webkit.org/show_bug.cgi?id=96992.

        Reviewed by Filip Pizlo.

        Adding additional vcproj build targets in LLIntDesiredOffsets.vcproj,
        LLIntOffsetsExtractor.vcproj, and LLIntAssembly.vcproj to match those
        in jsc.vcproj.

        * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj:
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj:
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj:
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Added property svn:eol-style.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Added property svn:eol-style.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugAll.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebugCairoCFLite.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Added property svn:eol-style.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleaseCairoCFLite.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorReleasePGO.vsprops: Added.

1729 1730 1731 1732 1733 1734 1735
2012-09-18  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix sloppy English in comment.

        * runtime/JSGlobalObject.cpp:
        (JSC):

1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883
2012-09-17  Csaba Osztrogonác  <ossy@webkit.org>

        Unreviewed, rolling out r128826 and r128813.

        * API/JSCallbackConstructor.cpp:
        (JSC):
        (JSC::JSCallbackConstructor::JSCallbackConstructor):
        * API/JSCallbackConstructor.h:
        (JSCallbackConstructor):
        * API/JSCallbackObject.cpp:
        (JSC):
        (JSC::::createStructure):
        * API/JSCallbackObject.h:
        (JSC::JSCallbackObject::create):
        (JSCallbackObject):
        * API/JSClassRef.cpp:
        (OpaqueJSClass::prototype):
        * API/JSObjectRef.cpp:
        (JSObjectMake):
        (JSObjectGetPrivate):
        (JSObjectSetPrivate):
        (JSObjectGetPrivateProperty):
        (JSObjectSetPrivateProperty):
        (JSObjectDeletePrivateProperty):
        * API/JSValueRef.cpp:
        (JSValueIsObjectOfClass):
        * API/JSWeakObjectMapRefPrivate.cpp:
        * GNUmakefile.list.am:
        * JSCTypedArrayStubs.h:
        (JSC):
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject):
        * heap/Heap.cpp:
        (JSC::Heap::isSafeToSweepStructures):
        (JSC):
        * heap/Heap.h:
        (JSC::Heap::allocatorForObjectWithDestructor):
        (Heap):
        (JSC::Heap::allocateWithDestructor):
        (JSC::Heap::allocateStructure):
        (JSC):
        * heap/IncrementalSweeper.cpp:
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::sweepNextBlock):
        (JSC::IncrementalSweeper::startSweeping):
        (JSC::IncrementalSweeper::willFinishSweeping):
        (JSC::IncrementalSweeper::structuresCanBeSwept):
        (JSC):
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp:
        (JSC::MarkedAllocator::tryAllocateHelper):
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::cellsNeedDestruction):
        (JSC::MarkedAllocator::onlyContainsStructures):
        (MarkedAllocator):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::init):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC):
        (JSC::MarkedBlock::specializedSweep):
        (JSC::MarkedBlock::sweep):
        (JSC::MarkedBlock::sweepHelper):
        * heap/MarkedBlock.h:
        (JSC):
        (MarkedBlock):
        (JSC::MarkedBlock::cellsNeedDestruction):
        (JSC::MarkedBlock::onlyContainsStructures):
        * heap/MarkedSpace.cpp:
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::canonicalizeCellLivenessData):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        * heap/MarkedSpace.h:
        (MarkedSpace):
        (Subspace):
        (JSC::MarkedSpace::allocatorFor):
        (JSC::MarkedSpace::destructorAllocatorFor):
        (JSC::MarkedSpace::allocateWithDestructor):
        (JSC::MarkedSpace::allocateStructure):
        (JSC::MarkedSpace::forEachBlock):
        * heap/SlotVisitor.cpp:
        * jit/JIT.h:
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        (JSC::JIT::emitAllocateJSFinalObject):
        (JSC::JIT::emitAllocateJSArray):
        * jsc.cpp:
        (GlobalObject::create):
        * runtime/Arguments.cpp:
        (JSC):
        * runtime/Arguments.h:
        (Arguments):
        (JSC::Arguments::Arguments):
        * runtime/ErrorPrototype.cpp:
        (JSC):
        * runtime/Executable.h:
        * runtime/InternalFunction.cpp:
        (JSC):
        (JSC::InternalFunction::InternalFunction):
        * runtime/InternalFunction.h:
        (InternalFunction):
        * runtime/JSCell.h:
        (JSC):
        (JSC::allocateCell):
        * runtime/JSDestructibleObject.h: Removed.
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::reset):
        (JSC):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::createRareDataIfNeeded):
        (JSC::JSGlobalObject::create):
        * runtime/JSGlobalThis.h:
        (JSGlobalThis):
        (JSC::JSGlobalThis::JSGlobalThis):
        * runtime/JSPropertyNameIterator.h:
        * runtime/JSScope.cpp:
        (JSC):
        * runtime/JSString.h:
        (JSC):
        * runtime/JSWrapperObject.h:
        (JSWrapperObject):
        (JSC::JSWrapperObject::JSWrapperObject):
        * runtime/MathObject.cpp:
        (JSC):
        * runtime/NameInstance.h:
        (NameInstance):
        * runtime/RegExp.h:
        * runtime/RegExpObject.cpp:
        (JSC):
        * runtime/SparseArrayValueMap.h:
        * runtime/Structure.h:
        (JSC::Structure):
        (JSC::JSCell::classInfo):
        (JSC):
        * runtime/StructureChain.h:
        * runtime/SymbolTable.h:
        * testRegExp.cpp:
        (GlobalObject::create):

1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979
2012-09-17  Geoffrey Garen  <ggaren@apple.com>

        Refactored the arguments object so it doesn't dictate closure layout
        https://bugs.webkit.org/show_bug.cgi?id=96955

        Reviewed by Oliver Hunt.

        * bytecode/CodeBlock.h:
        (JSC::ExecState::argumentAfterCapture): Helper function for accessing an
        argument that has been moved for capture.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator): Generate metadata for arguments
        that are captured. We don't move any arguments yet, but we do use this
        metadata to tell the arguments object if an argument is stored in the
        activation.

        * dfg/DFGOperations.cpp:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile): Updated for the arguments object not
        malloc'ing a separate backing store, and for a rename from deletedArguments
        to slowArguments.

        * interpreter/CallFrame.h:
        (ExecState):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::unwindCallFrame):
        (JSC::Interpreter::privateExecute):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL): Updated for small interface changes.

        * runtime/Arguments.cpp:
        (JSC::Arguments::visitChildren):
        (JSC::Arguments::copyToArguments):
        (JSC::Arguments::fillArgList):
        (JSC::Arguments::getOwnPropertySlotByIndex):
        (JSC::Arguments::createStrictModeCallerIfNecessary):
        (JSC::Arguments::createStrictModeCalleeIfNecessary):
        (JSC::Arguments::getOwnPropertySlot):
        (JSC::Arguments::getOwnPropertyDescriptor):
        (JSC::Arguments::getOwnPropertyNames):
        (JSC::Arguments::putByIndex):
        (JSC::Arguments::put):
        (JSC::Arguments::deletePropertyByIndex):
        (JSC::Arguments::deleteProperty):
        (JSC::Arguments::defineOwnProperty):
        (JSC::Arguments::tearOff): Moved all data inline into the object, for speed,
        and refactored all internal argument accesses to use helper functions, so
        we can change the implementation without changing lots of code.

        (JSC::Arguments::didTearOffActivation): This function needs to account
        for arguments that were moved by the activation object. We do this accounting
        through a side vector that tells us where our arguments will be in the
        activation.

        (JSC::Arguments::tearOffForInlineCallFrame):
        * runtime/Arguments.h:
        (Arguments):
        (JSC::Arguments::length):
        (JSC::Arguments::isTornOff):
        (JSC::Arguments::Arguments):
        (JSC::Arguments::allocateSlowArguments):
        (JSC::Arguments::tryDeleteArgument):
        (JSC::Arguments::trySetArgument):
        (JSC::Arguments::tryGetArgument):
        (JSC::Arguments::isDeletedArgument):
        (JSC::Arguments::isArgument):
        (JSC::Arguments::argument):
        (JSC::Arguments::finishCreation):

        * runtime/JSActivation.h:
        (JSC::JSActivation::create):
        (JSActivation):
        (JSC::JSActivation::captureStart):
        (JSC::JSActivation::storageSize):
        (JSC::JSActivation::registerOffset):
        (JSC::JSActivation::isValid): The activation object is no longer responsible
        for copying extra arguments provided by the caller. The argumnents object
        does this instead. This means we can allocate and initialize an activation
        without worrying about the call frame's argument count.

        * runtime/SymbolTable.h:
        (JSC::SlowArgument::SlowArgument):
        (SlowArgument):
        (JSC):
        (JSC::SharedSymbolTable::parameterCount):
        (SharedSymbolTable):
        (JSC::SharedSymbolTable::slowArguments):
        (JSC::SharedSymbolTable::setSlowArguments): Added data structures to back
        the algorithms above.

1980 1981 1982 1983 1984 1985 1986 1987 1988 1989
2012-09-17  Filip Pizlo  <fpizlo@apple.com>

        32-bit LLInt get_by_val does vector length checks incorrectly
        https://bugs.webkit.org/show_bug.cgi?id=96893
        <rdar://problem/12311678>

        Reviewed by Mark Hahnenberg.

        * llint/LowLevelInterpreter32_64.asm:

1990 1991 1992 1993 1994 1995 1996 1997 1998 1999
2012-09-17  Filip Pizlo  <fpizlo@apple.com>

        We don't have a bad enough time if an object's prototype chain crosses global objects
        https://bugs.webkit.org/show_bug.cgi?id=96962

        Reviewed by Geoffrey Garen.

        * runtime/JSGlobalObject.cpp:
        (JSC):

2000 2001 2002 2003 2004 2005 2006
2012-09-17  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, fix a broken assertion in offlineasm.

        * offlineasm/armv7.rb:
        * offlineasm/backends.rb:

2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184
2012-09-16  Mark Hahnenberg  <mhahnenberg@apple.com>

        Delayed structure sweep can leak structures without bound
        https://bugs.webkit.org/show_bug.cgi?id=96546

        Reviewed by Gavin Barraclough.

        This patch gets rid of the separate Structure allocator in the MarkedSpace and adds two new destructor-only
        allocators. We now have separate allocators for our three types of objects: those objects with no destructors,
        those objects with destructors and with immortal structures, and those objects with destructors that don't have 
        immortal structures. All of the objects of the third type (destructors without immortal structures) now 
        inherit from a new class named JSDestructibleObject (which in turn is a subclass of JSNonFinalObject), which stores 
        the ClassInfo for these classes at a fixed offset for safe retrieval during sweeping/destruction.

        * API/JSCallbackConstructor.cpp: Use JSDestructibleObject for JSCallbackConstructor.
        (JSC):
        (JSC::JSCallbackConstructor::JSCallbackConstructor):
        * API/JSCallbackConstructor.h:
        (JSCallbackConstructor):
        * API/JSCallbackObject.cpp: Inherit from JSDestructibleObject for normal JSCallbackObjects and use a finalizer for 
        JSCallbackObject<JSGlobalObject>, since JSGlobalObject also uses a finalizer.
        (JSC):
        (JSC::::create): We need to move the create function for JSCallbackObject<JSGlobalObject> out of line so we can add 
        the finalizer for it. We don't want to add the finalizer is something like finishCreation in case somebody decides 
        to subclass this. We use this same technique for many other subclasses of JSGlobalObject.
        (JSC::::createStructure):
        * API/JSCallbackObject.h:
        (JSCallbackObject):
        (JSC):
        * API/JSClassRef.cpp: Change all the JSCallbackObject<JSNonFinalObject> to use JSDestructibleObject instead.
        (OpaqueJSClass::prototype):
        * API/JSObjectRef.cpp: Ditto.
        (JSObjectMake):
        (JSObjectGetPrivate):
        (JSObjectSetPrivate):
        (JSObjectGetPrivateProperty):
        (JSObjectSetPrivateProperty):
        (JSObjectDeletePrivateProperty):
        * API/JSValueRef.cpp: Ditto.
        (JSValueIsObjectOfClass):
        * API/JSWeakObjectMapRefPrivate.cpp: Ditto.
        * JSCTypedArrayStubs.h:
        (JSC):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * dfg/DFGSpeculativeJIT.h: Use the proper allocator type when doing inline allocation in the DFG.
        (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject):
        (JSC::DFG::SpeculativeJIT::emitAllocateJSFinalObject):
        * heap/Heap.cpp:
        (JSC):
        * heap/Heap.h: Add accessors for the various types of allocators now. Also remove the isSafeToSweepStructures function 
        since it's always safe to sweep Structures now.
        (JSC::Heap::allocatorForObjectWithNormalDestructor): 
        (JSC::Heap::allocatorForObjectWithImmortalStructureDestructor):
        (Heap):
        (JSC::Heap::allocateWithNormalDestructor):
        (JSC):
        (JSC::Heap::allocateWithImmortalStructureDestructor):
        * heap/IncrementalSweeper.cpp: Remove all the logic to detect when it's safe to sweep Structures from the 
        IncrementalSweeper since it's always safe to sweep Structures now.
        (JSC::IncrementalSweeper::IncrementalSweeper):
        (JSC::IncrementalSweeper::sweepNextBlock):
        (JSC::IncrementalSweeper::startSweeping):
        (JSC::IncrementalSweeper::willFinishSweeping):
        (JSC):
        * heap/IncrementalSweeper.h:
        (IncrementalSweeper):
        * heap/MarkedAllocator.cpp: Remove the logic that was preventing us from sweeping Structures if it wasn't safe. Add 
        tracking of the specific destructor type of allocator. 
        (JSC::MarkedAllocator::tryAllocateHelper):
        (JSC::MarkedAllocator::allocateBlock):
        * heap/MarkedAllocator.h:
        (JSC::MarkedAllocator::destructorType):
        (MarkedAllocator):
        (JSC::MarkedAllocator::MarkedAllocator):
        (JSC::MarkedAllocator::init):
        * heap/MarkedBlock.cpp: Add all the destructor type stuff to MarkedBlocks so that we do the right thing when sweeping. 
        We also use the stored destructor type to determine the right thing to do in all JSCell::classInfo() calls.
        (JSC::MarkedBlock::create):
        (JSC::MarkedBlock::MarkedBlock):
        (JSC):
        (JSC::MarkedBlock::specializedSweep):
        (JSC::MarkedBlock::sweep):
        (JSC::MarkedBlock::sweepHelper):
        * heap/MarkedBlock.h:
        (JSC):
        (JSC::MarkedBlock::allocator):
        (JSC::MarkedBlock::destructorType):
        * heap/MarkedSpace.cpp: Add the new destructor allocators to MarkedSpace.
        (JSC::MarkedSpace::MarkedSpace):
        (JSC::MarkedSpace::resetAllocators):
        (JSC::MarkedSpace::canonicalizeCellLivenessData):
        (JSC::MarkedSpace::isPagedOut):
        (JSC::MarkedSpace::freeBlock):
        * heap/MarkedSpace.h:
        (MarkedSpace):
        (JSC::MarkedSpace::immortalStructureDestructorAllocatorFor):
        (JSC::MarkedSpace::normalDestructorAllocatorFor):
        (JSC::MarkedSpace::allocateWithImmortalStructureDestructor):
        (JSC::MarkedSpace::allocateWithNormalDestructor):
        (JSC::MarkedSpace::forEachBlock):
        * heap/SlotVisitor.cpp: Add include because the symbol was needed in an inlined function.
        * jit/JIT.h: Make sure we use the correct allocator when doing inline allocations in the baseline JIT.
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateBasicJSObject):
        (JSC::JIT::emitAllocateJSFinalObject):
        (JSC::JIT::emitAllocateJSArray):
        * jsc.cpp: 
        (GlobalObject::create): Add finalizer here since JSGlobalObject needs to use a finalizer instead of inheriting from 
        JSDestructibleObject.
        * runtime/Arguments.cpp: Inherit from JSDestructibleObject.
        (JSC):
        * runtime/Arguments.h:
        (Arguments):
        (JSC::Arguments::Arguments):
        * runtime/ErrorPrototype.cpp: Added an assert to make sure we have a trivial destructor.
        (JSC):
        * runtime/Executable.h: Indicate that all of the Executable* classes have immortal Structures.
        (JSC):
        * runtime/InternalFunction.cpp: Inherit from JSDestructibleObject.
        (JSC):
        (JSC::InternalFunction::InternalFunction):
        * runtime/InternalFunction.h:
        (InternalFunction):
        * runtime/JSCell.h: Added the NEEDS_DESTRUCTOR  macro to make it easier for classes to indicate that instead of being 
        allocated in a destructor MarkedAllocator that they will handle their destruction themselves through the 
        use of a finalizer.
        (JSC):
        (HasImmortalStructure): New template to help us determine at compile-time if a particular class 
        should be allocated in the immortal structure MarkedAllocator. The default value is false. In order 
        to be allocated in the immortal structure allocator, classes must specialize this template. Also added 
        a macro to make it easier for classes to specialize the template.
        (JSC::allocateCell): Use the appropriate allocator depending on the destructor type.
        * runtime/JSDestructibleObject.h: Added. New class that stores the ClassInfo of any subclass so that it can be 
        accessed safely when the object is being destroyed.
        (JSC):
        (JSDestructibleObject):
        (JSC::JSDestructibleObject::classInfo):
        (JSC::JSDestructibleObject::JSDestructibleObject):
        (JSC::JSCell::classInfo): Checks the current MarkedBlock to see where it should get the ClassInfo from so that it's always safe.
        * runtime/JSGlobalObject.cpp: JSGlobalObject now uses a finalizer instead of a destructor so that it can avoid forcing all 
        of its relatives in the inheritance hierarchy (e.g. JSScope) to use destructors as well.
        (JSC::JSGlobalObject::reset):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::createRareDataIfNeeded): Since we always create a finalizer now, we don't have to worry about adding one 
        for the m_rareData field when it's created.
        (JSC::JSGlobalObject::create):
        (JSC):
        * runtime/JSGlobalThis.h: Inherit from JSDestructibleObject.
        (JSGlobalThis):
        (JSC::JSGlobalThis::JSGlobalThis):
        * runtime/JSPropertyNameIterator.h: Has an immortal Structure.
        (JSC):
        * runtime/JSScope.cpp:
        (JSC):
        * runtime/JSString.h: Has an immortal Structure.
        (JSC):
        * runtime/JSWrapperObject.h: Inherit from JSDestructibleObject.
        (JSWrapperObject):
        (JSC::JSWrapperObject::JSWrapperObject):
        * runtime/MathObject.cpp: Cleaning up some of the inheritance stuff.
        (JSC):
        * runtime/NameInstance.h: Inherit from JSDestructibleObject.
        (NameInstance):
        * runtime/RegExp.h: Has immortal Structure.
        (JSC):
        * runtime/RegExpObject.cpp: Inheritance cleanup.
        (JSC):
        * runtime/SparseArrayValueMap.h: Has immortal Structure.
        (JSC):
        * runtime/Structure.h: Has immortal Structure.
        (JSC):
        * runtime/StructureChain.h: Ditto.
        (JSC):
        * runtime/SymbolTable.h: Ditto.
        (SharedSymbolTable):
        (JSC):

2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370
2012-09-17  Filip Pizlo  <fpizlo@apple.com>

        If a prototype has indexed setters and its instances have indexed storage, then all put_by_val's should have a bad time
        https://bugs.webkit.org/show_bug.cgi?id=96596

        Reviewed by Gavin Barraclough.

        Added comprehensive support for accessors and read-only indexed properties on the
        prototype chain. This is done without any performance regression on benchmarks that
        we're aware of, by having the entire VM's strategy with respect to arrays tilted
        heavily in favor of:
        
        - The prototype chain of JSArrays never having any accessors or read-only indexed
          properties. If that changes, you're going to have a bad time.
        
        - Prototypes of non-JSArray objects either having no indexed accessors or read-only
          indexed properties, or, having those indexed accessor thingies inserted before
          any instance object (i.e. object with that prototype as its prototype) is created.
          If you add indexed accessors or read-only indexed properties to an object that is
          already used as a prototype, you're going to have a bad time.
        
        See below for the exact definition of having a bad time.
        
        Put another way, "fair" uses of indexed accessors and read-only indexed properties
        are:
        
        - Put indexed accessors and read-only indexed properties on an object that is never
          used as a prototype. This will slow down accesses to that object, but will not
          have any effect on any other object.
        
        - Put those indexed accessor thingies on an object before it is used as a prototype
          and then start instantiating objects that claim that object as their prototype.
          This will slightly slow down indexed stores to the instance objects, and greatly
          slow down all indexed accesses to the prototype, but will have no other effect.
        
        In short, "fair" uses only affect the object itself and any instance objects. But
        if you start using indexed accessors in more eclectic ways, you're going to have
        a bad time.
        
        Specifically, if an object that may be used as a prototype has an indexed accessor
        added, the VM performs a whole-heap scan to find all objects that belong to the
        same global object as the prototype you modified. If any of those objects has
        indexed storage, their indexed storage is put into slow-put mode, just as if their
        prototype chain had indexed accessors. This will happen even for objects that do
        not currently have indexed accessors in their prototype chain. As well, all JSArray
        allocations are caused to create arrays with slow-put storage, and all future
        allocations of indexed storage for non-JSArray objects are also flipped to slow-put
        mode. Note there are two aspects to having a bad time: (i) the whole-heap scan and
        (ii) the poisoning of all indexed storage in the entire global object. (i) is
        necessary for correctness. If we detect that an object that may be used as a
        prototype has had an indexed accessor or indexed read-only property inserted into
        it, then we need to ensure that henceforth all instances of that object inspect
        the prototype chain whenever an indexed hole is stored to. But by default, indexed
        stores do no such checking because doing so would be unnecessarily slow. So, we must
        find all instances of the affected object and flip them into a different array
        storage mode that omits all hole optimizations. Since prototypes never keep a list
        of instance objects, the only way to find those objects is a whole-heap scan. But
        (i) alone would be a potential disaster, if a program frequently allocated an
        object without indexed accessors, then allocated a bunch of objects that used that
        one as their prototype, and then added indexed accessors to the prototype. So, to
        prevent massive heap scan storms in such awkward programs, having a bad time also
        implies (ii): henceforth *all* objects belonging to that global object will use
        slow put indexed storage, so that we don't ever have to scan the heap again. Note
        that here we are using the global object as just an approximation of a program
        module; it may be worth investigating in the future if other approximations can be
        used instead.

        * bytecode/ArrayProfile.h:
        (JSC):
        (JSC::arrayModeFromStructure):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::fromObserved):
        (JSC::DFG::modeAlreadyChecked):
        (JSC::DFG::modeToString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (JSC::DFG::isSlowPutAccess):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JIT.h:
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitAllocateJSArray):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_array):
        * runtime/ArrayPrototype.cpp:
        (JSC::ArrayPrototype::finishCreation):
        (JSC::arrayProtoFuncSort):
        * runtime/IndexingType.h:
        (JSC):
        (JSC::hasIndexedProperties):
        (JSC::hasIndexingHeader):
        (JSC::hasArrayStorage):
        (JSC::shouldUseSlowPut):
        * runtime/JSArray.cpp:
        (JSC::JSArray::pop):
        (JSC::JSArray::push):
        (JSC::JSArray::fillArgList):
        (JSC::JSArray::copyToArguments):
        * runtime/JSArray.h:
        (JSC::JSArray::createStructure):
        * runtime/JSGlobalObject.cpp:
        (JSC::JSGlobalObject::JSGlobalObject):
        (JSC::JSGlobalObject::reset):
        (JSC):
        (JSC::JSGlobalObject::haveABadTime):
        * runtime/JSGlobalObject.h:
        (JSGlobalObject):
        (JSC::JSGlobalObject::addressOfArrayStructure):
        (JSC::JSGlobalObject::havingABadTimeWatchpoint):
        (JSC::JSGlobalObject::isHavingABadTime):
        * runtime/JSObject.cpp:
        (JSC::JSObject::visitButterfly):
        (JSC::JSObject::getOwnPropertySlotByIndex):
        (JSC::JSObject::put):
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::enterDictionaryIndexingMode):
        (JSC::JSObject::notifyPresenceOfIndexedAccessors):
        (JSC):
        (JSC::JSObject::createArrayStorage):
        (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
        (JSC::JSObject::switchToSlowPutArrayStorage):
        (JSC::JSObject::setPrototype):
        (JSC::JSObject::resetInheritorID):
        (JSC::JSObject::inheritorID):
        (JSC::JSObject::allowsAccessFrom):
        (JSC::JSObject::deletePropertyByIndex):
        (JSC::JSObject::getOwnPropertyNames):
        (JSC::JSObject::unwrappedGlobalObject):
        (JSC::JSObject::notifyUsedAsPrototype):
        (JSC::JSObject::createInheritorID):
        (JSC::JSObject::defineOwnIndexedProperty):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
        (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
        (JSC::JSObject::putByIndexBeyondVectorLength):
        (JSC::JSObject::putDirectIndexBeyondVectorLength):
        (JSC::JSObject::getNewVectorLength):
        (JSC::JSObject::getOwnPropertyDescriptor):
        * runtime/JSObject.h:
        (JSC::JSObject::mayBeUsedAsPrototype):
        (JSObject):
        (JSC::JSObject::mayInterceptIndexedAccesses):
        (JSC::JSObject::getArrayLength):
        (JSC::JSObject::getVectorLength):
        (JSC::JSObject::canGetIndexQuickly):
        (JSC::JSObject::getIndexQuickly):
        (JSC::JSObject::canSetIndexQuickly):
        (JSC::JSObject::setIndexQuickly):
        (JSC::JSObject::initializeIndex):
        (JSC::JSObject::completeInitialization):
        (JSC::JSObject::inSparseIndexingMode):
        (JSC::JSObject::arrayStorage):
        (JSC::JSObject::arrayStorageOrNull):
        (JSC::JSObject::ensureArrayStorage):
        (JSC):
        (JSC::JSValue::putByIndex):
        * runtime/JSValue.cpp:
        (JSC::JSValue::putToPrimitive):
        (JSC::JSValue::putToPrimitiveByIndex):
        (JSC):
        * runtime/JSValue.h:
        (JSValue):
        * runtime/ObjectPrototype.cpp:
        (JSC::ObjectPrototype::finishCreation):
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayEntry::put):
        (JSC):
        * runtime/SparseArrayValueMap.h:
        (JSC):
        (SparseArrayEntry):
        * runtime/Structure.cpp:
        (JSC::Structure::anyObjectInChainMayInterceptIndexedAccesses):
        (JSC):
        (JSC::Structure::suggestedIndexingTransition):
        * runtime/Structure.h:
        (Structure):
        (JSC::Structure::mayInterceptIndexedAccesses):
        * runtime/StructureTransitionTable.h:
        (JSC::newIndexingType):

2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419
2012-09-17  Filip Pizlo  <fpizlo@apple.com>

        Array profiling has convergence issues
        https://bugs.webkit.org/show_bug.cgi?id=96891

        Reviewed by Gavin Barraclough.

        Now each array profiling site merges in the indexing type it observed into
        the m_observedArrayModes bitset. The ArrayProfile also uses this to detect
        cases where the structure must have gone polymorphic (if the bitset is
        polymorphic then the structure must be). This achieves something like the
        best of both worlds: on the one hand, we get a probabilistic structure that
        we can use to optimize the monomorphic structure case, but on the other hand,
        we get an accurate view of the set of types that were encountered.

        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::or32):
        (MacroAssemblerARMv7):
        * assembler/MacroAssemblerX86.h:
        (JSC::MacroAssemblerX86::or32):
        (MacroAssemblerX86):
        * assembler/MacroAssemblerX86_64.h:
        (JSC::MacroAssemblerX86_64::or32):
        (MacroAssemblerX86_64):
        * assembler/X86Assembler.h:
        (X86Assembler):
        (JSC::X86Assembler::orl_rm):
        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        * bytecode/ArrayProfile.h:
        (JSC::ArrayProfile::addressOfArrayModes):
        (JSC::ArrayProfile::structureIsPolymorphic):
        * jit/JIT.h:
        (JIT):
        * jit/JITInlineMethods.h:
        (JSC):
        (JSC::JIT::emitArrayProfilingSite):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emit_op_put_by_val):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:

2420 2421 2422 2423 2424 2425 2426 2427 2428
2012-09-17  Mark Lam  <mark.lam@apple.com>

        Not reviewed. Added svn:eol-style native to unbreak some build bots.
        https://bugs.webkit.org/show_bug.cgi?id=96175.

        * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Added property svn:eol-style.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Added property svn:eol-style.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Added property svn:eol-style.

2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455
2012-09-16  Mark Lam  <mark.lam@apple.com>

        Added MSVC project changes to enable building the llint.
        https://bugs.webkit.org/show_bug.cgi?id=96175.

        Reviewed by Geoff Garen.

        This only adds the ability to build the llint, but currently, only the
        C++ backend is supported. By default, the Windows port will remain
        running with the baseline JIT.  The llint will not be enabled.

        * JavaScriptCore.vcproj/JavaScriptCore.sln:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.vcproj/LLIntAssembly: Added.
        * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.make: Added.
        * JavaScriptCore.vcproj/LLIntAssembly/LLIntAssembly.vcproj: Added.
        * JavaScriptCore.vcproj/LLIntAssembly/build-LLIntAssembly.sh: Added.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets: Added.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Added.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/LLIntDesiredOffsets.vcproj: Added.
        * JavaScriptCore.vcproj/LLIntDesiredOffsets/build-LLIntDesiredOffsets.sh: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcproj: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.vsprops: Added.
        * JavaScriptCore.vcproj/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.vsprops: Added.

2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475
2012-09-16  Filip Pizlo  <fpizlo@apple.com>

        JSObject.cpp and JSArray.cpp have inconsistent tests for the invalid array index case
        https://bugs.webkit.org/show_bug.cgi?id=96878

        Reviewed by Sam Weinig.

        Removed the uses of UNLIKELY() because I don't believe they are buying us anything,
        since we're already on the slow path. Also found other places where we're testing for
        the invalid array index case using unusual predicates rather than just using
        MAX_ARRAY_INDEX. With this change, I believe that all of our tests for invalid
        array indices (i.e. indices that should be treated as non-indexed properties)
        uniformly use MAX_ARRAY_INDEX and PropertyName::NotAnIndex.

        * runtime/JSArray.cpp:
        (JSC::JSArray::push):
        * runtime/JSObject.cpp:
        (JSC::JSObject::putByIndex):
        (JSC::JSObject::defineOwnIndexedProperty):

2476 2477 2478 2479 2480 2481 2482 2483 2484 2485
2012-09-15  Filip Pizlo  <fpizlo@apple.com>

        Following the Butterfly refactoring, the comment for lastArraySize was not updated
        https://bugs.webkit.org/show_bug.cgi?id=96877

        Reviewed by Sam Weinig.

        * runtime/JSObject.cpp:
        (JSC):

2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507
2012-09-15  Mark Lam  <mark.lam@apple.com>

        Fixed JSLock to use the platform abstraction for Mutex instead of
        depending on pthreads.
        https://bugs.webkit.org/show_bug.cgi?id=96858.

        Reviewed by Filip Pizlo.

        This fixes a synchronization problem on the Windows port and makes
        it more reliable when running the layout tests.

        * runtime/InitializeThreading.cpp:
        (JSC::initializeThreadingOnce):
        * runtime/JSLock.cpp:
        (JSC):
        (JSC::GlobalJSLock::GlobalJSLock):
        (JSC::GlobalJSLock::~GlobalJSLock):
        (JSC::GlobalJSLock::initialize):
        * runtime/JSLock.h:
        (GlobalJSLock):
        (JSLock):

2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542
2012-09-15  Filip Pizlo  <fpizlo@apple.com>

        Structure check hoisting fails to consider the possibility of conflicting checks on the source of the first assignment to the hoisted variable
        https://bugs.webkit.org/show_bug.cgi?id=96872

        Reviewed by Oliver Hunt.

        This does a few related things:
        
        - It turns off the use of ForceOSRExit for sure-to-fail CheckStructures, because
          I noticed that this would sometimes happen for a ForwardCheckStructure. The
          problem is that ForceOSRExit exits backwards, not forwards. Since the code that
          led to those ForceOSRExit's being inserted was written out of paranoia rather
          than need, I removed it. Specifically, I removed the m_isValid = false code
          for CheckStructure/StructureTransitionWatchpoint in AbstractState.
        
        - If a structure check causes a structure set to go empty, we don't want a
          PutStructure to revive the set. It should instead be smart enough to realize 
          that an empty set implies that the code can't execute. This was the only "bug"
          that the use of m_isValid = false was preventing.
        
        - Finally, the main change: structure check hoisting looks at the source of the
          SetLocals on structure-check-hoistable variables and ensures that the source
          is not checked with a conflicting structure. This is O(n^2) but it does not
          show up at all in performance tests.
        
        The first two parts of this change were auxiliary bugs that were revealed by
        the structure check hoister doing bad things.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::initialize):
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):

2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574
2012-09-14  Filip Pizlo  <fpizlo@apple.com>

        All of the things in SparseArrayValueMap should be out-of-line
        https://bugs.webkit.org/show_bug.cgi?id=96854

        Reviewed by Andy Estes.

        Those inline methods were buying us nothing.

        * GNUmakefile.list.am:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * runtime/JSArray.cpp:
        * runtime/JSGlobalData.cpp:
        * runtime/JSObject.cpp:
        * runtime/RegExpMatchesArray.cpp:
        * runtime/SparseArrayValueMap.cpp:
        (JSC::SparseArrayValueMap::SparseArrayValueMap):
        (JSC):
        (JSC::SparseArrayValueMap::~SparseArrayValueMap):
        (JSC::SparseArrayValueMap::finishCreation):
        (JSC::SparseArrayValueMap::create):
        (JSC::SparseArrayValueMap::destroy):
        (JSC::SparseArrayValueMap::createStructure):
        (JSC::SparseArrayValueMap::add):
        (JSC::SparseArrayValueMap::putEntry):
        (JSC::SparseArrayValueMap::putDirect):
        (JSC::SparseArrayEntry::get):
        (JSC::SparseArrayEntry::getNonSparseMode):
        (JSC::SparseArrayValueMap::visitChildren):
        * runtime/SparseArrayValueMapInlineMethods.h: Removed.

2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587