ChangeLog 233 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
2012-11-04  Filip Pizlo  <fpizlo@apple.com>

        Reduce the verbosity of referring to QNaN in JavaScriptCore
        https://bugs.webkit.org/show_bug.cgi?id=101174

        Reviewed by Geoffrey Garen.

        Introduces a #define QNaN in JSValue.h, and replaces all previous uses of
        std::numeric_limits<double>::quiet_NaN() with QNaN.

        * API/JSValueRef.cpp:
        (JSValueMakeNumber):
        (JSValueToNumber):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        * runtime/CachedTranscendentalFunction.h:
        (JSC::CachedTranscendentalFunction::initialize):
        * runtime/DateConstructor.cpp:
        (JSC::constructDate):
        * runtime/DateInstanceCache.h:
        (JSC::DateInstanceData::DateInstanceData):
        (JSC::DateInstanceCache::reset):
        * runtime/ExceptionHelpers.cpp:
        (JSC::InterruptedExecutionError::defaultValue):
        (JSC::TerminatedExecutionError::defaultValue):
        * runtime/JSCell.h:
        (JSC::JSValue::getPrimitiveNumber):
        * runtime/JSDateMath.cpp:
        (JSC::parseDateFromNullTerminatedCharacters):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        (JSC::JSGlobalData::resetDateCache):
        * runtime/JSGlobalObjectFunctions.cpp:
        (JSC::parseInt):
        (JSC::jsStrDecimalLiteral):
        (JSC::toDouble):
        (JSC::jsToNumber):
        (JSC::parseFloat):
        * runtime/JSValue.cpp:
        (JSC::JSValue::toNumberSlowCase):
        * runtime/JSValue.h:
        (JSC):
        * runtime/JSValueInlineMethods.h:
        (JSC::jsNaN):
        * runtime/MathObject.cpp:
        (JSC::mathProtoFuncMax):
        (JSC::mathProtoFuncMin):

51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
2012-11-03  Filip Pizlo  <fpizlo@apple.com>

        Baseline JIT should use structure watchpoints whenever possible
        https://bugs.webkit.org/show_bug.cgi?id=101146

        Reviewed by Sam Weinig.

        No speed-up yet except on toy programs. I think that it will start to show
        speed-ups with https://bugs.webkit.org/show_bug.cgi?id=101147, which this is
        a step towards.

        * jit/JIT.h:
        (JIT):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):
        (JSC::JIT::addStructureTransitionCheck):
        (JSC):
        (JSC::JIT::testPrototype):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::privateCompilePutByIdTransition):
        (JSC::JIT::privateCompileGetByIdProto):
        (JSC::JIT::privateCompileGetByIdProtoList):
        (JSC::JIT::privateCompileGetByIdChainList):
        (JSC::JIT::privateCompileGetByIdChain):

80 81 82 83 84 85 86 87 88 89 90 91 92 93 94
2012-11-04  Csaba Osztrogonác  <ossy@webkit.org>

        [Qt] udis86_itab.c is always regenerated
        https://bugs.webkit.org/show_bug.cgi?id=100756

        Reviewed by Simon Hausmann.

        * DerivedSources.pri: Generate sources to the generated directory.
        * disassembler/udis86/differences.txt:
        * disassembler/udis86/itab.py: Add --outputDir option.
        (UdItabGenerator.__init__):
        (genItabH):
        (genItabC):
        (main):

95 96 97 98 99 100 101 102 103
2012-11-02  Filip Pizlo  <fpizlo@apple.com>

        LLInt 32-bit put_by_val ArrayStorage case should use the right register (t3, not t2) for the index in the publicLength updating path
        https://bugs.webkit.org/show_bug.cgi?id=101118

        Reviewed by Gavin Barraclough.

        * llint/LowLevelInterpreter32_64.asm:

104 105 106 107 108 109 110 111 112 113 114 115 116 117
2012-11-02  Filip Pizlo  <fpizlo@apple.com>

        DFG::Node::converToStructureTransitionWatchpoint should take kindly to ArrayifyToStructure
        https://bugs.webkit.org/show_bug.cgi?id=101117

        Reviewed by Gavin Barraclough.

        We have logic to convert ArrayifyToStructure to StructureTransitionWatchpoint, which is awesome, except
        that previously convertToStructureTransitionWatchpoint was (a) asserting that it never saw an
        ArrayifyToStructure and (b) would incorrectly create a ForwardStructureTransitionWatchpoint if it did.

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

118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133
2012-11-02  Filip Pizlo  <fpizlo@apple.com>

        DFG::SpeculativeJIT::typedArrayDescriptor should use the Float64Array descriptor for Float64Arrays
        https://bugs.webkit.org/show_bug.cgi?id=101114

        Reviewed by Gavin Barraclough.

        As in https://bugs.webkit.org/show_bug.cgi?id=101112, this was only wrong when Float64Array descriptors
        hadn't been initialized yet. That happens rarely, but when it does happen, we would crash.
        
        This would also become much more wrong if we ever put type size info (num bytes, etc) in the descriptor
        and used that directly. So it's good to fix it.

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

134 135 136 137 138 139 140 141 142 143 144 145 146
2012-11-02  Filip Pizlo  <fpizlo@apple.com>

        JIT::privateCompileGetByVal should use the uint8ClampedArrayDescriptor for compiling accesses to Uint8ClampedArrays
        https://bugs.webkit.org/show_bug.cgi?id=101112

        Reviewed by Gavin Barraclough.

        The only reason why the code was wrong to use uint8ArrayDescriptor instead is that if we're just using
        Uint8ClampedArrays then the descriptor for Uint8Array may not have been initialized.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompileGetByVal):

147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193
2012-11-02  Mark Hahnenberg  <mhahnenberg@apple.com>

        MarkedBlocks should use something other than the mark bits to indicate liveness for newly allocated objects
        https://bugs.webkit.org/show_bug.cgi?id=100877

        Reviewed by Filip Pizlo.

        Currently when we canonicalize cell liveness data in MarkedBlocks, we set the mark bit for every cell in the 
        block except for those in the free list. This allows us to consider objects that were allocated since the 
        previous collection to be considered live until they have a chance to be properly marked by the collector.

        If we want to use the mark bits to signify other types of information, e.g. using sticky mark bits for generational 
        collection, we will have to keep track of newly allocated objects in a different fashion when we canonicalize cell liveness.

        One method would be to allocate a separate set of bits while canonicalizing liveness data. These bits would 
        track the newly allocated objects in the block separately from those objects who had already been marked. We would 
        then check these bits, along with the mark bits, when determining liveness. 

        * heap/Heap.h:
        (Heap):
        (JSC::Heap::isLive): We now check for the presence of the newlyAllocated Bitmap.
        (JSC):
        * heap/MarkedBlock.cpp:
        (JSC::MarkedBlock::specializedSweep): We clear the newlyAllocated Bitmap if we're creating a free list. This 
        will happen if we canonicalize liveness data for some other reason than collection (e.g. forEachCell) and 
        then start allocating again.
        (JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor): 
        (SetNewlyAllocatedFunctor):
        (JSC::SetNewlyAllocatedFunctor::operator()): We set the newlyAllocated bits for all the objects 
        that aren't already marked. We undo the bits for the objects in the free list later in canonicalizeCellLivenessData.
        (JSC::MarkedBlock::canonicalizeCellLivenessData): We should never have a FreeListed block with a newlyAllocated Bitmap.
        We allocate the new Bitmap, set the bits for all the objects that aren't already marked, and then unset all of the 
        bits for the items currently in the FreeList.
        * heap/MarkedBlock.h:
        (JSC::MarkedBlock::clearMarks): We clear the newlyAllocated bitmap if it exists because at this point we don't need it
        any more.
        (JSC::MarkedBlock::isEmpty): If we have some objects that are newlyAllocated, we are not empty.
        (JSC::MarkedBlock::isNewlyAllocated): 
        (JSC):
        (JSC::MarkedBlock::setNewlyAllocated):
        (JSC::MarkedBlock::clearNewlyAllocated):
        (JSC::MarkedBlock::isLive): We now check the newlyAllocated Bitmap, if it exists, when determining liveness of a cell in 
        a block that is Marked.
        * heap/WeakBlock.cpp:
        (JSC::WeakBlock::visit): We need to make sure we don't finalize objects that are in the newlyAllocated Bitmap.
        (JSC::WeakBlock::reap): Ditto.

194 195 196 197 198 199 200 201 202 203 204 205
2012-11-02  Filip Pizlo  <fpizlo@apple.com>

        JIT::privateCompileGetByVal should use MacroAssemblerCodePtr::createFromExecutableAddress like JIT::privateCompilePutByVal
        https://bugs.webkit.org/show_bug.cgi?id=101109

        Reviewed by Gavin Barraclough.

        This fixes crashes on ARMv7 resulting from the return address already being tagged with the THUMB2 bit.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::privateCompileGetByVal):

206 207 208 209 210 211 212 213 214 215 216
2012-11-02  Simon Fraser  <simon.fraser@apple.com>

        Enable SUBPIXEL_LAYOUT on Mac
        https://bugs.webkit.org/show_bug.cgi?id=101076

        Reviewed by Dave Hyatt.

        Define ENABLE_SUBPIXEL_LAYOUT and include it in FEATURE_DEFINES.

        * Configurations/FeatureDefines.xcconfig:

217 218 219 220 221 222 223 224 225 226 227 228 229 230 231
2012-11-02  Michael Saboff  <msaboff@apple.com>

        RegExp.prototype.toString Should Produce an 8 bit JSString if possible.
        https://bugs.webkit.org/show_bug.cgi?id=101003

        Reviewed by Geoffrey Garen.

        Took the logic of regExpObjectSource() and created two templated helpers that uses the
        source character type when appending to the StringBuilder.

        * runtime/RegExpObject.cpp:
        (JSC::appendLineTerminatorEscape): Checks line terminate type to come up with escaped version.
        (JSC::regExpObjectSourceInternal): Templated version of original.
        (JSC::regExpObjectSource): Wrapper function.

232 233 234 235 236 237 238 239 240
2012-11-02  Adam Barth  <abarth@webkit.org>

        ENABLE(UNDO_MANAGER) is disabled everywhere and is not under active development
        https://bugs.webkit.org/show_bug.cgi?id=100711

        Reviewed by Eric Seidel.

        * Configurations/FeatureDefines.xcconfig:

241 242 243 244 245 246 247 248 249 250 251 252 253 254 255
2012-11-02  Simon Hausmann  <simon.hausmann@digia.com>

        [Qt] Fix build on Windows when Qt is configured with -release
        https://bugs.webkit.org/show_bug.cgi?id=101041

        Reviewed by Jocelyn Turcotte.

        When Qt is configured with -debug or -release, the release/debug build of for example
        QtCore is not available by default. For LLIntExtractor we always need to build debug
        _and_ release versions, but we do not actually need any Qt libraries nor qtmain(d).lib.
        Therefore we can disable all these features but need to keep $$QT.core.includes in the
        INCLUDEPATH for some defines from qglobal.h.

        * LLIntOffsetsExtractor.pro:

256 257 258 259 260 261 262 263 264 265 266
2012-11-01  Mark Lam  <mark.lam@apple.com>

        A llint workaround for a toolchain issue.
        https://bugs.webkit.org/show_bug.cgi?id=101012.

        Reviewed by Michael Saboff.

        * llint/LowLevelInterpreter.asm:
          - use a local label to workaround the toolchain issue with undeclared
            global labels.

267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285
2012-11-01  Oliver Hunt  <oliver@apple.com>

        Remove GlobalObject constant register that is typically unused
        https://bugs.webkit.org/show_bug.cgi?id=101005

        Reviewed by Geoffrey Garen.

        The GlobalObject constant register is frequently allocated even when it
        is not used, it is also getting in the way of some other optimisations.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::CodeBlock):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::BytecodeGenerator):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseResolveOperations):

286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321
2012-10-31  Filip Pizlo  <fpizlo@apple.com>

        DFG optimized string access code should be enabled
        https://bugs.webkit.org/show_bug.cgi?id=100825

        Reviewed by Oliver Hunt.

        - Removes prediction checks from the parser.
        
        - Fixes the handling of array mode refinement for strings. I.e. we don't do
          any refinement - we already know it's going to be a string. We could
          revisit this in the future, but for now the DFG lacks the ability to
          handle any array modes other than Array::String for string intrinsics, so
          this is as good as it gets.
        
        - Removes uses of isBlahSpeculation for checking if a mode is already
          checked. isBlahSpeculation implicitly checks if the SpeculatedType is not
          BOTTOM ("empty"), which breaks for checking if a mode is already checked
          since a mode may already be "checked" in the sense that we've proven that
          the code is unreachable.
        
        ~1% speed-up on V8v7, mostly from a speed-up on crypto, which uses string
        intrinsics in one of the hot functions.

        * bytecode/SpeculatedType.h:
        (JSC::speculationChecked):
        (JSC):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::alreadyChecked):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileGetCharCodeAt):

322 323 324 325 326 327 328 329 330 331 332 333 334 335 336
2012-10-31  Filip Pizlo  <fpizlo@apple.com>

        Sparse array size threshold should be increased to 100000
        https://bugs.webkit.org/show_bug.cgi?id=100827

        Reviewed by Oliver Hunt.

        This enables the use of contiguous arrays in programs that previously
        couldn't use them. And I so far can't see any examples of this being
        a downside. To the extent that there is a downside, it ought to be
        addressed by GC: https://bugs.webkit.org/show_bug.cgi?id=100828

        * runtime/ArrayConventions.h:
        (JSC):

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
2012-10-31  Mark Lam  <mark.lam@apple.com>

        C++ llint 64-bit backend needs to zero extend results of int32 operations.
        https://bugs.webkit.org/show_bug.cgi?id=100899.

        Reviewed by Filip Pizlo.

        llint asm instructions ending in "i" for a 64-bit machine expects the
        high 32-bit of registers to be zero'ed out when a 32-bit instruction
        writes into a register. Fixed the C++ llint to honor this.

        Fixed the index register used in BaseIndex addressing to be of size
        intptr_t as expected.

        Updated CLoopRegister to handle different endiannesss configurations.

        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoopRegister::clearHighWord):
          - new method to clear the high 32-bit of a 64-bit register.
            It's a no-op for the 32-bit build. 
        (CLoopRegister):
          - CLoopRegister now takes care of packing and byte endianness order.
        (JSC::CLoop::execute): - Added an assert.
        * offlineasm/cloop.rb:
          - Add calls to clearHighWord() wherever needed.

363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396
2012-10-31  Mark Lam  <mark.lam@apple.com>

        A JSC printf (support for %J+s and %b).
        https://bugs.webkit.org/show_bug.cgi?id=100566.

        Reviewed by Michael Saboff.

        Added VMInspector::printf(), fprintf(), sprintf(), and snprintf().
        - %b prints ints as boolean TRUE (non-zero) or FALSE (zero).
        - %Js prints a WTF::String* like a %s prints a char*.
          Also works for 16bit WTF::Strings (prints wchar_t* using %S).
        - '+' is a modifier meaning 'use verbose mode', and %J+s is an example
          of its use.

        * JavaScriptCore.xcodeproj/project.pbxproj:
        * interpreter/VMInspector.cpp:
        (FormatPrinter):
        (JSC::FormatPrinter::~FormatPrinter):
        (JSC::FormatPrinter::print):
        (JSC::FormatPrinter::printArg):
        (JSC::FormatPrinter::printWTFString):
        (JSC::FileFormatPrinter::FileFormatPrinter):
        (JSC::FileFormatPrinter::printArg):
        (JSC::StringFormatPrinter::StringFormatPrinter):
        (JSC::StringFormatPrinter::printArg):
        (JSC::StringNFormatPrinter::StringNFormatPrinter):
        (JSC::StringNFormatPrinter::printArg):
        (JSC::VMInspector::fprintf):
        (JSC::VMInspector::printf):
        (JSC::VMInspector::sprintf):
        (JSC::VMInspector::snprintf):
        * interpreter/VMInspector.h:
        (VMInspector):

397 398 399 400 401 402 403 404 405 406 407
2012-10-31  Mark Lam  <mark.lam@apple.com>

        64-bit llint PC offset can be negative: using an unsigned shift is a bug.
        https://bugs.webkit.org/show_bug.cgi?id=100896.

        Reviewed by Filip Pizlo.

        Fixed the PC offset divisions in the 64-bit llint asm to use rshift instead of urshift.

        * llint/LowLevelInterpreter64.asm:

408 409 410 411 412 413 414 415 416 417 418 419
2012-10-30  Yuqiang Xian  <yuqiang.xian@intel.com>

        glsl-function-atan.html WebGL conformance test fails after https://bugs.webkit.org/show_bug.cgi?id=99154
        https://bugs.webkit.org/show_bug.cgi?id=100789

        Reviewed by Filip Pizlo.

        We accidently missed a bitwise double to int64 conversion.

        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::silentFill):

420 421 422 423 424 425 426 427 428 429 430 431 432 433
2012-10-30  Joseph Pecoraro  <pecoraro@apple.com>

        [Mac] Sync up FeatureDefine Configuration Files
        https://bugs.webkit.org/show_bug.cgi?id=100171

        Reviewed by David Kilzer.

        Follow up to better coordinate with iOS feature defines. Make:

          - ENABLE_FILTERS always on
          - ENABLE_INPUT_* iphonesimulator values point to the iphoneos values

        * Configurations/FeatureDefines.xcconfig:

434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451
2012-10-30  Joseph Pecoraro  <pecoraro@apple.com>

        [Mac] Sync up FeatureDefine Configuration Files
        https://bugs.webkit.org/show_bug.cgi?id=100171

        Reviewed by David Kilzer.

        Ensure an identical FeatureDefine files across all projects. Changes:

          - ENABLE_CSS_BOX_DECORATION_BREAK should be in all
          - ENABLE_PDFKIT_PLUGIN should be in all
          - ENABLE_RESOLUTION_MEDIA_QUERY should be in all
          - ENABLE_ENCRYPTED_MEDIA should be in all
          - ENABLE_HIDDEN_PAGE_DOM_TIMER_THROTTLING with corrected value
          - Some alphabetical ordering cleanup

        * Configurations/FeatureDefines.xcconfig:

452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468
2012-10-30  Mark Hahnenberg  <mhahnenberg@apple.com>

        Arrays can change IndexingType in the middle of sorting
        https://bugs.webkit.org/show_bug.cgi?id=100773

        Reviewed by Filip Pizlo.

        Instead of giving up, we just fetch the appropriate vector based on the current 
        IndexingType of the array.

        * runtime/JSArray.cpp:
        (JSC::JSArray::sortVector):
        * runtime/JSObject.h:
        (JSObject):
        (JSC::JSObject::currentIndexingData):
        (JSC::JSObject::currentRelevantLength):

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
2012-10-29  Anders Carlsson  <andersca@apple.com>

        Build WebKit as C++11 on Mac
        https://bugs.webkit.org/show_bug.cgi?id=100720

        Reviewed by Daniel Bates.

        * Configurations/Base.xcconfig:
        Add CLANG_CXX_LANGUAGE_STANDARD=gnu++0x.

        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::generate):
        (JSC::BytecodeGenerator::pushFinallyContext):
        (JSC::BytecodeGenerator::beginSwitch):
        * llint/LLIntOffsetsExtractor.cpp:
        * runtime/Identifier.cpp:
        (JSC::Identifier::add8):
        * runtime/Identifier.h:
        (JSC::Identifier::add):
        * runtime/JSONObject.cpp:
        (JSC::appendStringToStringBuilder):
        * runtime/StringPrototype.cpp:
        (JSC::replaceUsingStringSearch):
        Add static_casts to prevent implicit type conversions in non-constant initializer lists.

494 495 496 497 498 499 500 501 502 503
2012-10-28  Mark Rowe  <mrowe@apple.com>

        Simplify Xcode configuration settings that used to vary between OS versions.

        Reviewed by Dan Bernstein.

        * Configurations/Base.xcconfig:
        * Configurations/DebugRelease.xcconfig:
        * Configurations/JavaScriptCore.xcconfig:

504 505 506 507 508 509 510 511 512 513 514 515
2012-10-28  Mark Rowe  <mrowe@apple.com>

        Remove references to unsupported OS and Xcode versions.

        Reviewed by Anders Carlsson.

        * Configurations/Base.xcconfig:
        * Configurations/CompilerVersion.xcconfig: Removed.
        * Configurations/DebugRelease.xcconfig:
        * Configurations/Version.xcconfig:
        * JavaScriptCore.xcodeproj/project.pbxproj:

516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534
2012-10-29  Michael Saboff  <msaboff@apple.com>

        Non-special escape character sequences cause JSC::Lexer::parseString to create 16 bit strings
        https://bugs.webkit.org/show_bug.cgi?id=100576

        Reviewed by Darin Adler.

        Changed singleEscape() processing to be based on a lookup of a static table.  The table
        covers ASCII characters SPACE through DEL.  If a character can be a single character escape,
        then the table provides the non-zero result of that escape.  Updated the result of
        singleEscape to be an LChar to make the table as small as possible.
        Added a new test fast/js/normal-character-escapes-in-string-literals.html to validated
        the behavior.

        * parser/Lexer.cpp:
        (JSC::singleEscape):
        (JSC::Lexer::parseString):
        (JSC::Lexer::parseStringSlowCase):

535 536 537 538 539 540 541 542 543
2012-10-29  Enrica Casucci  <enrica@apple.com>

        Add ENABLE_USERSELECT_ALL feature flag.
        https://bugs.webkit.org/show_bug.cgi?id=100559

        Reviewed by Eric Seidel.

        * Configurations/FeatureDefines.xcconfig:

544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 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 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651
2012-10-28  Filip Pizlo  <fpizlo@apple.com>

        DFG should be able to emit effectful structure checks
        https://bugs.webkit.org/show_bug.cgi?id=99260

        Reviewed by Oliver Hunt.

        This change allows us to find out if an array access that has gone polymorphic
        is operating over known structures - i.e. the primordial array structures of the
        global object that the code block containing the array access belongs to. We
        term this state "OriginalArray" for short. The fact that the access has gone
        polymorphic means that the array profile will not be able to report the set of
        structures it had seen - but if it can tell us that all of the structures were
        primordial then it just so happens that we can deduce what the structure set
        would have been by just querying the code block's global object. This allows us
        to emit an ArrayifyToStructure instead of an Arrayify if we find that we need to
        do conversions. The fast path of an ArrayifyToStructure is exactly like the fast
        path of a CheckStructure and is mostly subject to the same optimizations. It
        also burns one fewer registers.
        
        Essentially the notion of OriginalArray is a super cheap way of getting the
        array profile to tell us a structure set instead of a singleton structure.
        Currently, the array profile can only tell us the structure seen at an array
        access if there was exactly one structure. If there were multiple structures, it
        won't tell us anything other than the array modes and other auxiliary profiling
        data (whether there were stores to holes, for example). With OriginalArray, we
        cheaply get a structure set if all of the structures were primordial for the
        code block's global object, since in that case the array mode set (ArrayModes)
        can directly tell us the structure set. In the future, we might consider adding
        complete structure sets to the array profiles, but I suspect that we would hit
        diminishing returns if we did so - it would only help if we have array accesses
        that are both polymorphic and are cross-global-object accesses (rare) or if the
        arrays had named properties or other structure transitions that are unrelated to
        indexing type (also rare).
        
        This also does away with Arrayify (and the new ArrayifyToStructure) returning
        the butterfly pointer. This turns out to be faster and easier to CSE.
        
        And, this also changes constant folding to be able to eliminate CheckStructure,
        ForwardCheckStructure, and ArrayifyToStructure in addition to being able to
        transform them into structure transition watchpoints. This is great for
        ArrayifyToStructure because then CSE and CFA know that there is no side effect.
        Converting CheckStructure and ForwardCheckStructure to also behave this way is
        just a matter of elegance.
        
        This has no performance impact right now. It's intended to alleviate some of the
        regressions seen in the early implementation of
        https://bugs.webkit.org/show_bug.cgi?id=98606.

        * bytecode/ArrayProfile.cpp:
        (JSC::ArrayProfile::computeUpdatedPrediction):
        * bytecode/ArrayProfile.h:
        (JSC):
        (JSC::ArrayProfile::ArrayProfile):
        (ArrayProfile):
        (JSC::ArrayProfile::usesOriginalArrayStructures):
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        (JSC::DFG::ArrayMode::alreadyChecked):
        (JSC::DFG::arrayClassToString):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::ArrayMode::withProfile):
        (JSC::DFG::ArrayMode::isJSArray):
        (ArrayMode):
        (JSC::DFG::ArrayMode::isJSArrayWithOriginalStructure):
        (JSC::DFG::ArrayMode::supportsLength):
        (JSC::DFG::ArrayMode::arrayModesWithIndexingShape):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::checkStructureElimination):
        (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
        (JSC::DFG::CSEPhase::getPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::checkArrayElimination):
        (JSC::DFG::CSEPhase::getScopeRegistersLoadElimination):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::checkArray):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasStructure):
        (JSC::DFG::Node::hasArrayMode):
        (JSC::DFG::Node::arrayMode):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
        (JSC::DFG::SpeculativeJIT::arrayify):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/JSGlobalObject.h:
        (JSC::JSGlobalObject::isOriginalArrayStructure):
        * runtime/Structure.cpp:
        (JSC::Structure::nonPropertyTransition):

652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668
2012-10-28  Filip Pizlo  <fpizlo@apple.com>

        There should not be blind spots in array length array profiling
        https://bugs.webkit.org/show_bug.cgi?id=100620

        Reviewed by Oliver Hunt.

        I don't think this has any performance impact. But it's good to not have random
        programs occasionally emit a GetById for array length accesses.

        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::privateCompilePatchGetArrayLength):
        * jit/JITPropertyAccess32_64.cpp:
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::privateCompilePatchGetArrayLength):

669 670 671 672 673 674 675 676 677 678 679 680 681
2012-10-28  Filip Pizlo  <fpizlo@apple.com>

        Unreviewed, make always-true enum-to-int comparisons use casts.

        * dfg/DFGFPRInfo.h:
        (JSC::DFG::FPRInfo::debugName):
        * dfg/DFGGPRInfo.h:
        (JSC::DFG::JSValueSource::tagGPR):
        (JSC::DFG::GPRInfo::toIndex):
        (JSC::DFG::GPRInfo::debugName):
        * runtime/JSTypeInfo.h:
        (JSC::TypeInfo::TypeInfo):

682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699
2012-10-27  Filip Pizlo  <fpizlo@apple.com>

        OSR exit compilation should defend against argument recoveries from code blocks that are no longer on the inline stack
        https://bugs.webkit.org/show_bug.cgi?id=100601

        Reviewed by Oliver Hunt.

        This happened to me while I was fixing bugs for https://bugs.webkit.org/show_bug.cgi?id=100599.
        I'm not sure how to reproduce this.

        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::baselineCodeBlockFor):
        (AssemblyHelpers):
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):

700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 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 760 761 762 763 764 765 766 767 768 769 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 798 799 800 801
2012-10-27  Filip Pizlo  <fpizlo@apple.com>

        DFG::Array::Mode needs to be cleaned up
        https://bugs.webkit.org/show_bug.cgi?id=100599

        Reviewed by Oliver Hunt.

        Turn the previous massive Array::Mode enum into a class that contains four
        fields, the type, whether it's a JSArray, the level of speculation, and the
        kind of conversion to perform.
        
        No performance or behavioral change.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::run):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::fromObserved):
        (JSC::DFG::ArrayMode::refine):
        (JSC::DFG::ArrayMode::alreadyChecked):
        (JSC::DFG::arrayTypeToString):
        (JSC::DFG::arrayClassToString):
        (DFG):
        (JSC::DFG::arraySpeculationToString):
        (JSC::DFG::arrayConversionToString):
        (JSC::DFG::ArrayMode::toString):
        * dfg/DFGArrayMode.h:
        (DFG):
        (ArrayMode):
        (JSC::DFG::ArrayMode::ArrayMode):
        (JSC::DFG::ArrayMode::type):
        (JSC::DFG::ArrayMode::arrayClass):
        (JSC::DFG::ArrayMode::speculation):
        (JSC::DFG::ArrayMode::conversion):
        (JSC::DFG::ArrayMode::asWord):
        (JSC::DFG::ArrayMode::fromWord):
        (JSC::DFG::ArrayMode::withSpeculation):
        (JSC::DFG::ArrayMode::usesButterfly):
        (JSC::DFG::ArrayMode::isJSArray):
        (JSC::DFG::ArrayMode::isInBounds):
        (JSC::DFG::ArrayMode::mayStoreToHole):
        (JSC::DFG::ArrayMode::isOutOfBounds):
        (JSC::DFG::ArrayMode::isSlowPut):
        (JSC::DFG::ArrayMode::canCSEStorage):
        (JSC::DFG::ArrayMode::lengthNeedsStorage):
        (JSC::DFG::ArrayMode::modeForPut):
        (JSC::DFG::ArrayMode::isSpecific):
        (JSC::DFG::ArrayMode::supportsLength):
        (JSC::DFG::ArrayMode::benefitsFromStructureCheck):
        (JSC::DFG::ArrayMode::doesConversion):
        (JSC::DFG::ArrayMode::arrayModesThatPassFiltering):
        (JSC::DFG::ArrayMode::operator==):
        (JSC::DFG::ArrayMode::operator!=):
        (JSC::DFG::ArrayMode::arrayModesWithIndexingShape):
        (JSC::DFG::canCSEStorage):
        (JSC::DFG::lengthNeedsStorage):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::getArrayMode):
        (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
        (JSC::DFG::ByteCodeParser::handleIntrinsic):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::getArrayLengthElimination):
        (JSC::DFG::CSEPhase::checkArrayElimination):
        (JSC::DFG::CSEPhase::getIndexedPropertyStorageLoadElimination):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::checkArray):
        (JSC::DFG::FixupPhase::blessArrayOperation):
        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGGraph.h:
        (JSC::DFG::Graph::byValIsPure):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::arrayMode):
        (JSC::DFG::Node::setArrayMode):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::typedArrayDescriptor):
        (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::arrayify):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
        (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
        (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
        (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::putByValWillNeedExtraRegister):
        (SpeculativeJIT):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819
2012-10-27  Dan Bernstein  <mitz@apple.com>

        REAL_PLATFORM_NAME build setting is no longer needed
        https://bugs.webkit.org/show_bug.cgi?id=100587

        Reviewed by Mark Rowe.

        Removed the definition of REAL_PLATFORM_NAME and replaced references to it with references
        to PLATFORM_NAME.

        * Configurations/Base.xcconfig:
        * Configurations/CompilerVersion.xcconfig:
        * Configurations/DebugRelease.xcconfig:
        * Configurations/FeatureDefines.xcconfig:
        * Configurations/JSC.xcconfig:
        * Configurations/JavaScriptCore.xcconfig:
        * Configurations/ToolExecutable.xcconfig:

820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853
2012-10-25  Filip Pizlo  <fpizlo@apple.com>

        Forward OSR calculation is wrong in the presence of multiple SetLocals, or a mix of SetLocals and Phantoms
        https://bugs.webkit.org/show_bug.cgi?id=100461

        Reviewed by Oliver Hunt and Gavin Barraclough.

        This does a couple of things. First, it removes the part of the change in r131822 that made the forward
        OSR exit calculator capable of handling multiple SetLocals. That change was wrong, because it would
        blindly assume that all SetLocals had the same ValueRecovery, and would ignore the possibility that if
        there is no value recovery then a ForwardCheckStructure on the first SetLocal would not know how to
        recover the state associated with the second SetLocal. Then, it introduces the invariant that any bytecode
        op that decomposes into multiple SetLocals must first emit dead SetLocals as hints and then emit a second
        set of SetLocals to actually do the setting of the locals. This means that if a ForwardCheckStructure (or
        any other hoisted forward speculation) is inserted, it will always be inserted on the second set of
        SetLocals (since hoisting only touches the live ones), at which point OSR will already know about the
        mov hints implied by the first set of (dead) SetLocals. This gives us the behavior we wanted, namely, that
        a ForwardCheckStructure applied to a variant set by a resolve_with_base-like operation can correctly do a
        forward exit while also ensuring that prior to exiting we set the appropriate locals.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):

854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888
2012-10-26  Simon Hausmann  <simon.hausmann@digia.com>

        [Qt] Fix the LLInt build on Windows
        https://bugs.webkit.org/show_bug.cgi?id=97648

        Reviewed by Tor Arne Vestbø.

        The main change for the port on Windows is changing the way offsets are extracted
        and the LLIntAssembly.h is generated to accomodate release and debug configurations.

        Firstly the LLIntOffsetsExtractor binary is now built as-is (no DESTDIR set) and
        placed into debug\LLIntOffsetsExtractor.exe and release\LLIntOffsetsExtractor.exe
        on Windows debug_and_release builds. On other patforms it remainds in the regular
        out directory.

        Secondly the LLIntAssembly.h files must be different for different build types,
        so the LLIntAssembly.h generator in DerivedSources.pri operates no on the extractor
        binary files as input. Using a simple exists() check we verify the presence of either
        a regular, a debug\LLIntOffsetsExtractor and a release\LLIntOffsetsExtractor binary
        and process all of them. The resulting assembly files consequently end up in
        generated\debug\LLIntAssembly.h and generated\release\LLIntAssembly.h.

        In Target.pri we have to also make sure that those directories are in the include
        path according to the release or debug configuration.

        Lastly a small tweak - swapping WTF.pri and JSC.pri inclusions - in the
        LLIntOffsetsExtractor build was needed to make sure that we include
        JavaScriptCore/config.h instead of WTF/config.h, required to fix the
        build issues originally pasted in bug #97648.

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

889 890 891 892 893 894 895 896 897 898 899 900 901 902
2012-10-26  Gabor Ballabas  <gaborb@inf.u-szeged.hu>

        [Qt] Enable JSC's disassembler on x86, x86_64 Linux
        https://bugs.webkit.org/show_bug.cgi?id=100386

        Reviewed by Simon Hausmann.

        It works fine on Linux x86, x86_64 just needs to be enabled in the
        QtWebKit build system.

        * DerivedSources.pri:
        * JavaScriptCore.pri:
        * Target.pri:

903 904 905 906 907 908 909 910 911
2012-10-26  Thiago Marcos P. Santos  <thiago.santos@intel.com>

        Add feature flags for CSS Device Adaptation
        https://bugs.webkit.org/show_bug.cgi?id=95960

        Reviewed by Kenneth Rohde Christiansen.

        * Configurations/FeatureDefines.xcconfig:

912 913 914 915 916 917 918 919 920 921 922 923 924
2012-10-26  Simon Hausmann  <simon.hausmann@digia.com>

        [WIN] Make LLInt offsets extractor work on Windows
        https://bugs.webkit.org/show_bug.cgi?id=100369

        Reviewed by Kenneth Rohde Christiansen.

        Open the input file explicitly in binary mode to prevent ruby/Windows from thinking that
        it's a text mode file that needs even new line conversions. The binary mode parameter is
        ignored on other platforms.

        * offlineasm/offsets.rb:

925 926 927 928 929 930 931 932 933 934 935 936 937
2012-10-25  Michael Saboff  <msaboff@apple.com>

        SymbolTableIndexHashTraits::needsDestruction should be set to true
        https://bugs.webkit.org/show_bug.cgi?id=100437

        Reviewed by Mark Hahnenberg.

        For correctness, set SymbolTableIndexHashTraits::needsDestruction to true since SymbolTableEntry's do
        need to have their destructor called due to the possibility of rare data.

        * runtime/SymbolTable.h:
        (SymbolTableIndexHashTraits):

938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961
2012-10-25  Filip Pizlo  <fpizlo@apple.com>

        DFG Arrayify elimination should replace it with GetButterfly rather than Phantom
        https://bugs.webkit.org/show_bug.cgi?id=100441

        Reviewed by Oliver Hunt and Gavin Barraclough.

        Made array profiler's to-string helper behave correctly.
        
        Made Arrayify elimination do the right thing (convert to GetButterfly).
        
        Made CFA's interference analysis track clobbered array modes correctly, mostly by
        simplifying the machinery.

        * bytecode/ArrayProfile.cpp:
        (JSC::arrayModesToString):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::clobberArrayModes):
        (AbstractValue):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):

962 963 964 965 966 967 968 969 970 971 972 973 974
2012-10-25  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r131793-r131826): Crash going to wikifonia.org
        https://bugs.webkit.org/show_bug.cgi?id=100281

        Reviewed by Oliver Hunt.

        Restore something that got lost in the resolve refactoring: the ability to give up on life if
        we see a resolve of 'arguments'.

        * runtime/JSScope.cpp:
        (JSC::JSScope::resolveContainingScopeInternal):

975 976 977 978 979 980 981 982 983 984 985
2012-10-25  Dominik Röttsches  <dominik.rottsches@intel.com>

        Conditionalize XHR timeout support
        https://bugs.webkit.org/show_bug.cgi?id=100356

        Reviewed by Adam Barth.

        Adding XHR_TIMEOUT feature to conditionalize this on ports without network backend support.

        * Configurations/FeatureDefines.xcconfig:

986 987 988 989 990 991 992 993 994 995 996 997
2012-10-25  Michael Saboff  <msaboff@apple.com>

        REGRESSION (r131836): failures in list styles tests on EFL, GTK
        https://bugs.webkit.org/show_bug.cgi?id=99824

        Reviewed by Oliver Hunt.

        Saved start of string since it is modified by call convertUTF8ToUTF16().

        * API/JSStringRef.cpp:
        (JSStringCreateWithUTF8CString):

998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016
2012-10-24  Filip Pizlo  <fpizlo@apple.com>

        DFG NewArrayBuffer node should keep its data in a structure on the side to free up one of the opInfos
        https://bugs.webkit.org/show_bug.cgi?id=100328

        Reviewed by Oliver Hunt.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGGraph.h:
        (Graph):
        * dfg/DFGNode.h:
        (NewArrayBufferData):
        (DFG):
        (JSC::DFG::Node::newArrayBufferData):
        (Node):
        (JSC::DFG::Node::startConstant):
        (JSC::DFG::Node::numConstants):

1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032
2012-10-25  Mark Lam  <mark.lam@apple.com>

        Update the C++ llint to work with the latest op_resolve... changes.
        https://bugs.webkit.org/show_bug.cgi?id=100345.

        Reviewed by Oliver Hunt.

        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        - emit opcode name as label when not using COMPUTED_GOTOs. The new op_resolve
          opcodes have jumps to these labels.
        - declare all opcode labels as UNUSED_LABEL()s to keep the compiler happy
          for opcodes that are not referenced by anyone.
        * offlineasm/asm.rb:
        - strip llint_ prefix from opcode names used as labels.

1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054
2012-10-24  Yuqiang Xian  <yuqiang.xian@intel.com>

        Refactor LLInt64 to distinguish the pointer operations from the 64-bit integer operations
        https://bugs.webkit.org/show_bug.cgi?id=100321

        Reviewed by Filip Pizlo.

        We have refactored the MacroAssembler and JIT compilers to distinguish
        the pointer operations from the 64-bit integer operations (see bug #99154).
        Now we want to do the similar work for LLInt, and the goal is same as
        the one mentioned in 99154.

        This is the first part of the modification: in the offline assembler,
        adding the support of the "<foo>q" instructions which will be used for
        64-bit integer operations.

        * llint/LowLevelInterpreter.cpp:
        (JSC::CLoop::execute):
        * offlineasm/cloop.rb:
        * offlineasm/instructions.rb:
        * offlineasm/x86.rb:

1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073
2012-10-24  Filip Pizlo  <fpizlo@apple.com>

        DFG compileBlahBlahByVal methods for Contiguous and ArrayStorage have only one caller and should be removed
        https://bugs.webkit.org/show_bug.cgi?id=100311

        Reviewed by Mark Hahnenberg.

        Just trying to simplify things before I make them more complicated again.

        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (DFG):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (DFG):
        (JSC::DFG::SpeculativeJIT::compile):

1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090
2012-10-23  Andreas Kling  <kling@webkit.org>

        CodeBlock: Give m_putToBaseOperations an inline capacity.
        <http://webkit.org/b/100190>
        <rdar://problem/12562466>

        Reviewed by Oliver Hunt.

        Since the CodeBlock constructor always inserts a single PutToBaseOperation, but there's no
        guarantee that more will follow, give the m_putToBaseOperations vector an inline capacity of 1.
        There are 4009 of these Vectors on Membuster3, and only 126 of them have more than a single entry.

        This change yields a 1.90MB reduction in memory usage.

        * bytecode/CodeBlock.h:
        (CodeBlock):

1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106
2012-10-23  Christophe Dumez  <christophe.dumez@intel.com>

        Regression(r132143): Assertion hit in JSC::Interpreter::StackPolicy::StackPolicy(JSC::Interpreter&, const WTF::StackBounds&)
        https://bugs.webkit.org/show_bug.cgi?id=100109

        Reviewed by Oliver Hunt.

        Fix possible integer overflow in StackPolicy constructor by
        using size_t type instead of int for stack sizes. The value
        returned by StackBounds::size() is of type size_t but was
        assigned to an int, which may overflow.

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

1107 1108 1109 1110 1111 1112
2012-10-23  Carlos Garcia Campos  <cgarcia@igalia.com>

        Unreviewed. Fix make distcheck.

        * GNUmakefile.list.am: Add missing header file.

1113 1114 1115 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
2012-10-23  Mark Lam  <mark.lam@apple.com>

        Make topCallFrame reliable.
        https://bugs.webkit.org/show_bug.cgi?id=98928.

        Reviewed by Geoffrey Garen.

        - VM entry points and the GC now uses topCallFrame.
        - The callerFrame value in CallFrames are now always the previous
          frame on the stack, except for the first frame which has a
          callerFrame of 0 (not counting the HostCallFrameFlag).
          Hence, we can now traverse every frame on the stack all the way
          back to the first frame.
        - GlobalExec's will no longer be used as the callerFrame values in
          call frames.
        - Added fences and traps for debugging the JSStack in debug builds.

        * bytecode/SamplingTool.h:
        (SamplingTool):
        (JSC::SamplingTool::CallRecord::CallRecord):
        * dfg/DFGOperations.cpp:
        - Fixed 2 DFG helper functions to flush topCallFrame as expected.
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::prepareForExternalCall):
        * interpreter/CallFrame.h:
        (JSC::ExecState::callerFrameNoFlags):
        (ExecState):
        (JSC::ExecState::argIndexForRegister):
        (JSC::ExecState::getArgumentUnsafe):
        * interpreter/CallFrameClosure.h:
        (CallFrameClosure):
        * interpreter/Interpreter.cpp:
        (JSC):
        (JSC::eval):
        (JSC::Interpreter::Interpreter):
        (JSC::Interpreter::throwException):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        (JSC::Interpreter::endRepeatCall):
        * interpreter/Interpreter.h:
        (JSC):
        (Interpreter):
        * interpreter/JSStack.cpp:
        (JSC::JSStack::JSStack):
        (JSC::JSStack::gatherConservativeRoots):
        (JSC::JSStack::disableErrorStackReserve):
        * interpreter/JSStack.h:
        (JSC):
        (JSStack):
        (JSC::JSStack::installFence):
        (JSC::JSStack::validateFence):
        (JSC::JSStack::installTrapsAfterFrame):
        * interpreter/JSStackInlines.h: Added.
        (JSC):
        (JSC::JSStack::getTopOfFrame):
        (JSC::JSStack::getTopOfStack):
        (JSC::JSStack::getStartOfFrame):
        (JSC::JSStack::pushFrame):
        (JSC::JSStack::popFrame):
        (JSC::JSStack::generateFenceValue):
        (JSC::JSStack::installFence):
        (JSC::JSStack::validateFence):
        (JSC::JSStack::installTrapsAfterFrame):
        * jit/JITStubs.cpp:
        (JSC::jitCompileFor):
        (JSC::lazyLinkFor):
        - Set frame->codeBlock to 0 for both the above because they are called
          with partially intitialized frames (cb uninitialized), but may
          trigger a GC.
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):

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 1219 1220
2012-10-22  Filip Pizlo  <fpizlo@apple.com>

        DFG::Array::Undecided should be called DFG::Array::SelectUsingPredictions
        https://bugs.webkit.org/show_bug.cgi?id=100052

        Reviewed by Oliver Hunt.

        No functional change, just renaming. It's a clearer name that more accurately
        reflects the meaning, and it eliminates the namespace confusion that will happen
        with the Undecided indexing type in https://bugs.webkit.org/show_bug.cgi?id=98606

        * 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):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::blessArrayOperation):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::arrayify):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

1221 1222 1223 1224 1225 1226 1227 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 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295
2012-10-22  Mark Lam  <mark.lam@apple.com>

        Change stack recursion checks to be based on stack availability.
        https://bugs.webkit.org/show_bug.cgi?id=99872.

        Reviewed by Filip Pizlo and Geoffrey Garen.

        - Remove m_reentryDepth, ThreadStackType which are now obsolete.
        - Replaced the reentryDepth checks with a StackBounds check.
        - Added the Interpreter::StackPolicy class to compute a reasonable
          stack capacity requirement given the native stack that the
          interpreter is executing on at that time.
        - Reserved an amount of JSStack space for the use of error handling
          and enable its use (using Interpreter::ErrorHandlingMode) when
          we're about to throw or report an exception.
        - Interpreter::StackPolicy also allows more native stack space
          to be used when in ErrorHandlingMode. This is needed in the case
          of native stack overflows.
        - Fixed the parser so that it throws a StackOverflowError instead of
          a SyntaxError when it encounters a stack overflow.

        * API/JSContextRef.cpp:
        (JSContextGroupCreate):
        (JSGlobalContextCreateInGroup):
        * JavaScriptCore.order:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::ErrorHandlingMode::ErrorHandlingMode):
        (JSC):
        (JSC::Interpreter::ErrorHandlingMode::~ErrorHandlingMode):
        (JSC::Interpreter::StackPolicy::StackPolicy):
        (JSC::Interpreter::Interpreter):
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * interpreter/Interpreter.h:
        (JSC):
        (Interpreter):
        (ErrorHandlingMode):
        (StackPolicy):
        (JSC::Interpreter::StackPolicy::requiredCapacity):
        * interpreter/JSStack.cpp:
        (JSC):
        (JSC::JSStack::JSStack):
        (JSC::JSStack::growSlowCase):
        (JSC::JSStack::enableErrorStackReserve):
        (JSC::JSStack::disableErrorStackReserve):
        * interpreter/JSStack.h:
        (JSStack):
        (JSC::JSStack::reservationEnd):
        (JSC):
        * jsc.cpp:
        (jscmain):
        * parser/Parser.cpp:
        (JSC::::Parser):
        * parser/Parser.h:
        (Parser):
        (JSC::::parse):
        * runtime/ExceptionHelpers.cpp:
        (JSC::throwStackOverflowError):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        (JSC::JSGlobalData::createContextGroup):
        (JSC::JSGlobalData::create):
        (JSC::JSGlobalData::createLeaked):
        (JSC::JSGlobalData::sharedInstance):
        * runtime/JSGlobalData.h:
        (JSC):
        (JSGlobalData):
        * runtime/StringRecursionChecker.h:
        (JSC::StringRecursionChecker::performCheck):
        * testRegExp.cpp:
        (realMain):

1296 1297 1298 1299 1300 1301
2012-10-20  Martin Robinson  <mrobinson@igalia.com>

        Fix 'make dist' for the GTK+ port

        * GNUmakefile.list.am: Add missing files to the source list.

1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313
2012-10-21  Raphael Kubo da Costa  <raphael.kubo.da.costa@intel.com>

        [CMake][JSC] Depend on risc.rb to decide when to run the LLInt scripts.
        https://bugs.webkit.org/show_bug.cgi?id=99917

        Reviewed by Geoffrey Garen.

        Depend on the newly-added risc.rb to make sure we always run the
        LLInt scripts when one of them changes.

        * CMakeLists.txt:

1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331
2012-10-20  Filip Pizlo  <fpizlo@apple.com>

        LLInt backends of non-ARM RISC platforms should be able to share code with the existing ARMv7 backend
        https://bugs.webkit.org/show_bug.cgi?id=99745

        Reviewed by Geoffrey Garen.

        This moves all of the things in armv7.rb that I thought are generally useful out
        into risc.rb. It also separates some phases (branch ops is separated into one
        phase that does sensible things, and another that does things that are painfully
        ARM-specific), and removes ARM assumptions from others by using a callback to
        drive exactly what lowering must happen. The goal here is to minimize the future
        maintenance burden of LLInt by ensuring that the various platforms share as much
        lowering code as possible.

        * offlineasm/armv7.rb:
        * offlineasm/risc.rb: Added.

1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 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
2012-10-19  Filip Pizlo  <fpizlo@apple.com>

        DFG should have some facility for recognizing redundant CheckArrays and Arrayifies
        https://bugs.webkit.org/show_bug.cgi?id=99287

        Reviewed by Mark Hahnenberg.

        Adds reasoning about indexing type sets (i.e. ArrayModes) to AbstractValue, which
        then enables us to fold away CheckArray's and Arrayify's that are redundant.

        * bytecode/ArrayProfile.cpp:
        (JSC::arrayModesToString):
        (JSC):
        * bytecode/ArrayProfile.h:
        (JSC):
        (JSC::mergeArrayModes):
        (JSC::arrayModesAlreadyChecked):
        * bytecode/StructureSet.h:
        (JSC::StructureSet::arrayModesFromStructures):
        (StructureSet):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGAbstractValue.h:
        (JSC::DFG::AbstractValue::AbstractValue):
        (JSC::DFG::AbstractValue::clear):
        (JSC::DFG::AbstractValue::isClear):
        (JSC::DFG::AbstractValue::makeTop):
        (JSC::DFG::AbstractValue::clobberStructures):
        (AbstractValue):
        (JSC::DFG::AbstractValue::setMostSpecific):
        (JSC::DFG::AbstractValue::set):
        (JSC::DFG::AbstractValue::operator==):
        (JSC::DFG::AbstractValue::merge):
        (JSC::DFG::AbstractValue::filter):
        (JSC::DFG::AbstractValue::filterArrayModes):
        (JSC::DFG::AbstractValue::validate):
        (JSC::DFG::AbstractValue::checkConsistency):
        (JSC::DFG::AbstractValue::dump):
        (JSC::DFG::AbstractValue::clobberArrayModes):
        (JSC::DFG::AbstractValue::clobberArrayModesSlow):
        (JSC::DFG::AbstractValue::setFuturePossibleStructure):
        (JSC::DFG::AbstractValue::filterFuturePossibleStructure):
        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::modeAlreadyChecked):
        * dfg/DFGArrayMode.h:
        (JSC::DFG::arrayModesFor):
        (DFG):
        * dfg/DFGConstantFoldingPhase.cpp:
        (JSC::DFG::ConstantFoldingPhase::foldConstants):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::arrayify):

1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404
2012-10-19  Filip Pizlo  <fpizlo@apple.com>

        Baseline JIT should not inline array allocations, to make them easier to instrument
        https://bugs.webkit.org/show_bug.cgi?id=99905

        Reviewed by Mark Hahnenberg.

        This will make it easier to instrument array allocations for the purposes of profiling.
        It also allows us to kill off a bunch of code. And, this doesn't appear to hurt
        performance at all. That's expected because these days any hot allocation will end up
        in the DFG JIT, which does inline these allocations.

        * jit/JIT.cpp:
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        (JIT):
        * jit/JITInlineMethods.h:
        (JSC):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::emit_op_new_array):

1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423
2012-10-19  Oliver Hunt  <oliver@apple.com>

        Fix some of the regression cause by the non-local variable reworking
        https://bugs.webkit.org/show_bug.cgi?id=99896

        Reviewed by Filip Pizlo.

        The non0local variable reworking led to some of the optimisations performed by
        the bytecode generator being dropped.  This in turn put more pressure on the DFG
        optimisations.  This exposed a short coming in our double speculation propogation.
        Now we try to distinguish between places where we should SpecDoubleReal vs generic
        SpecDouble.

        * dfg/DFGPredictionPropagationPhase.cpp:
        (PredictionPropagationPhase):
        (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPrediction):
        (JSC::DFG::PredictionPropagationPhase::speculatedDoubleTypeForPredictions):
        (JSC::DFG::PredictionPropagationPhase::propagate):

1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442
2012-10-19  Michael Saboff  <msaboff@apple.com>

        Lexer should create 8 bit Identifiers for RegularExpressions and ASCII identifiers
        https://bugs.webkit.org/show_bug.cgi?id=99855

        Reviewed by Filip Pizlo.

        Added makeIdentifier helpers that will always make an 8 bit Identifier or make an
        Identifier that is the same size as the template parameter.  Used the first in the fast
        path when looking for a JS identifier and the second when scanning regular expressions.

        * parser/Lexer.cpp:
        (JSC::::scanRegExp):
        * parser/Lexer.h:
        (Lexer):
        (JSC::::makeIdentifierSameType):
        (JSC::::makeLCharIdentifier):
        (JSC::::lexExpectIdentifier):

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-10-19  Mark Lam  <mark.lam@apple.com>

        Added WTF::StackStats mechanism.
        https://bugs.webkit.org/show_bug.cgi?id=99805.

        Reviewed by Geoffrey Garen.

        Added StackStats checkpoints and probes.

        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitNode):
        (JSC::BytecodeGenerator::emitNodeInConditionContext):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::append):
        (JSC::visitChildren):
        (JSC::SlotVisitor::donateKnownParallel):
        (JSC::SlotVisitor::drain):
        (JSC::SlotVisitor::drainFromShared):
        (JSC::SlotVisitor::mergeOpaqueRoots):
        (JSC::SlotVisitor::internalAppend):
        (JSC::SlotVisitor::harvestWeakReferences):
        (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::execute):
        (JSC::Interpreter::executeCall):
        (JSC::Interpreter::executeConstruct):
        (JSC::Interpreter::prepareForRepeatCall):
        * parser/Parser.h:
        (JSC::Parser::canRecurse):
        * runtime/StringRecursionChecker.h:
        (StringRecursionChecker):

1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485
2012-10-19  Oliver Hunt  <oliver@apple.com>

        REGRESSION(r131822): It made 500+ tests crash on 32 bit platforms
        https://bugs.webkit.org/show_bug.cgi?id=99814

        Reviewed by Filip Pizlo.

        Call the correct macro in 32bit. 

        * llint/LowLevelInterpreter.asm:

1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497
2012-10-19  Dongwoo Joshua Im  <dw.im@samsung.com>

        Rename ENABLE_CSS3_TEXT_DECORATION to ENABLE_CSS3_TEXT
        https://bugs.webkit.org/show_bug.cgi?id=99804

        Reviewed by Julien Chaffraix.

        CSS3 text related properties will be implemented under this flag,
        including text decoration, text-align-last, and text-justify.

        * Configurations/FeatureDefines.xcconfig:

andersca@apple.com's avatar
andersca@apple.com committed
1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516
2012-10-18  Anders Carlsson  <andersca@apple.com>

        Clean up RegExpKey
        https://bugs.webkit.org/show_bug.cgi?id=99798

        Reviewed by Darin Adler.

        RegExpHash doesn't need to be a class template specialization when the class template is specialized
        for JSC::RegExpKey only. Make it a nested class of RegExp instead. Also, make operator== a friend function
        so Hash::equal can see it.

        * runtime/RegExpKey.h:
        (JSC::RegExpKey::RegExpKey):
        (JSC::RegExpKey::operator==):
        (RegExpKey):
        (JSC::RegExpKey::Hash::hash):
        (JSC::RegExpKey::Hash::equal):
        (Hash):

1517 1518 1519 1520 1521 1522 1523 1524 1525
2012-10-19  Mark Lam  <mark.lam@apple.com>

        Bot greening: Follow up to r131877 to fix the Windows build.
        https://bugs.webkit.org/show_bug.cgi?id=99739.

        Not reviewed.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

1526 1527 1528 1529 1530 1531 1532 1533 1534
2012-10-19  Mark Lam  <mark.lam@apple.com>

        Bot greening: Attempt to fix broken Window build after r131836.
        https://bugs.webkit.org/show_bug.cgi?id=99739.

        Not reviewed.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

1535 1536 1537 1538 1539 1540 1541 1542 1543
2012-10-19  Yuqiang Xian  <yuqiang.xian@intel.com>

        Unreviewed fix after r131868.

        On JSVALUE64 platforms, JSValue constants can be Imm64 instead of ImmPtr for JIT compilers.

        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):

1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 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
2012-10-18  Filip Pizlo  <fpizlo@apple.com>

        Baseline array profiling should be less accurate, and DFG OSR exit should update array profiles on CheckArray and CheckStructure failure
        https://bugs.webkit.org/show_bug.cgi?id=99261

        Reviewed by Oliver Hunt.

        This makes array profiling stochastic, like value profiling. The point is to avoid
        noticing one-off indexing types that we'll never see again, but instead to:
        
        Notice the big ones: We want the DFG to compile based on the things that happen with
        high probability. So, this change makes array profiling do like value profiling and
        only notice a random subsampling of indexing types that flowed through an array
        access. Prior to this patch array profiles noticed all indexing types and weighted
        them identically.
        
        Bias the recent: Often an array access will see awkward indexing types during the
        first handful of executions because of artifacts of program startup. So, we want to
        bias towards the indexing types that we saw most recently. With this change, array
        profiling does like value profiling and usually tells use a random sampling that
        is biased to what happened recently.
        
        Have a backup plan: The above two things don't work by themselves because our
        randomness is not that random (nor do we care enough to make it more random), and
        because some procedures will have a <1/10 probability event that we must handle
        without bailing because it dominates a hot loop. So, like value profiling, this
        patch makes array profiling use OSR exits to tell us why we are bailing out, so
        that we don't make the same mistake again in the future.
        
        This change also makes the way that the 32-bit OSR exit compiler snatches scratch
        registers more uniform. We don't need a scratch buffer when we can push and pop.

        * bytecode/DFGExitProfile.h:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArray):
        (JSC::DFG::SpeculativeJIT::arrayify):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * jit/JITInlineMethods.h:
        (JSC::JIT::emitArrayProfilingSite):
        * llint/LowLevelInterpreter.asm:

1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602
2012-10-18  Yuqiang Xian  <yuqiang.xian@intel.com>

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

        Reviewed by Csaba Osztrogonác.

        * dfg/DFGCCallHelpers.h:
        (CCallHelpers):
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):

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 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 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
2012-10-18  Yuqiang Xian  <yuqiang.xian@intel.com>

        Refactor MacroAssembler interfaces to differentiate the pointer operands from the 64-bit integer operands
        https://bugs.webkit.org/show_bug.cgi?id=99154

        Reviewed by Gavin Barraclough.

        In current JavaScriptCore implementation for JSVALUE64 platform (i.e.,
        the X64 platform), we assume that the JSValue size is same to the
        pointer size, and thus EncodedJSValue is simply type defined as a
        "void*". In the JIT compiler, we also take this assumption and invoke
        the same macro assembler interfaces for both JSValue and pointer
        operands. We need to differentiate the operations on pointers from the
        operations on JSValues, and let them invoking different macro
        assembler interfaces. For example, we now use the interface of
        "loadPtr" to load either a pointer or a JSValue, and we need to switch
        to using "loadPtr" to load a pointer and some new "load64" interface
        to load a JSValue. This would help us supporting other JSVALUE64
        platforms where pointer size is not necessarily 64-bits, for example
        x32 (bug #99153).

        The major modification I made is to introduce the "*64" interfaces in
        the MacroAssembler for those operations on JSValues, keep the "*Ptr"
        interfaces for those operations on real pointers, and go through all
        the JIT compiler code to correct the usage.

        This is the second part of the work, i.e, to correct the usage of the
        new MacroAssembler interfaces in the JIT compilers, which also means
        that now EncodedJSValue is defined as a 64-bit integer, and the "*64"
        interfaces are used for it.

        * assembler/MacroAssembler.h: JSValue immediates should be in Imm64 instead of ImmPtr.
        (MacroAssembler):
        (JSC::MacroAssembler::shouldBlind):
        * dfg/DFGAssemblyHelpers.cpp: Correct the JIT compilers usage of the new interfaces.
        (JSC::DFG::AssemblyHelpers::jitAssertIsInt32):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSInt32):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSNumber):
        (JSC::DFG::AssemblyHelpers::jitAssertIsJSDouble):
        (JSC::DFG::AssemblyHelpers::jitAssertIsCell):
        * dfg/DFGAssemblyHelpers.h:
        (JSC::DFG::AssemblyHelpers::emitPutToCallFrameHeader):
        (JSC::DFG::AssemblyHelpers::branchIfNotCell):
        (JSC::DFG::AssemblyHelpers::debugCall):
        (JSC::DFG::AssemblyHelpers::boxDouble):
        (JSC::DFG::AssemblyHelpers::unboxDouble):
        (JSC::DFG::AssemblyHelpers::emitExceptionCheck):
        * dfg/DFGCCallHelpers.h:
        (JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
        (CCallHelpers):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::generateProtoChainAccessStub):
        (JSC::DFG::tryCacheGetByID):
        (JSC::DFG::tryBuildGetByIDList):
        (JSC::DFG::emitPutReplaceStub):
        (JSC::DFG::emitPutTransitionStub):
        * dfg/DFGScratchRegisterAllocator.h:
        (JSC::DFG::ScratchRegisterAllocator::preserveUsedRegistersToScratchBuffer):
        (JSC::DFG::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBuffer):
        * dfg/DFGSilentRegisterSavePlan.h:
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
        (JSC::DFG::SpeculativeJIT::compileValueToInt32):
        (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
        (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
        (JSC::DFG::SpeculativeJIT::compileInstanceOf):
        (JSC::DFG::SpeculativeJIT::compileStrictEqForConstant):
        (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
        * dfg/DFGSpeculativeJIT.h:
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::silentSavePlanForGPR):
        (JSC::DFG::SpeculativeJIT::silentSpill):
        (JSC::DFG::SpeculativeJIT::silentFill):
        (JSC::DFG::SpeculativeJIT::spill):
        (JSC::DFG::SpeculativeJIT::valueOfJSConstantAsImm64):
        (JSC::DFG::SpeculativeJIT::callOperation):
        (JSC::DFG::SpeculativeJIT::branch64):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::fillInteger):
        (JSC::DFG::SpeculativeJIT::fillDouble):
        (JSC::DFG::SpeculativeJIT::fillJSValue):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToNumber):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeValueToInt32):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeUInt32ToNumber):
        (JSC::DFG::SpeculativeJIT::cachedGetById):
        (JSC::DFG::SpeculativeJIT::cachedPutById):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
        (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
        (JSC::DFG::SpeculativeJIT::emitCall):
        (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
        (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
        (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
        (JSC::DFG::SpeculativeJIT::convertToDouble):
        (JSC::DFG::SpeculativeJIT::compileObjectEquality):
        (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
        (JSC::DFG::SpeculativeJIT::compileDoubleCompare):
        (JSC::DFG::SpeculativeJIT::compileNonStringCellOrOtherLogicalNot):
        (JSC::DFG::SpeculativeJIT::compileLogicalNot):
        (JSC::DFG::SpeculativeJIT::emitNonStringCellOrOtherBranch):
        (JSC::DFG::SpeculativeJIT::emitBranch):
        (JSC::DFG::SpeculativeJIT::compileContiguousGetByVal):
        (JSC::DFG::SpeculativeJIT::compileArrayStorageGetByVal):
        (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
        (JSC::DFG::SpeculativeJIT::compileArrayStoragePutByVal):
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGThunks.cpp:
        (JSC::DFG::osrExitGenerationThunkGenerator):
        (JSC::DFG::throwExceptionFromCallSlowPathGenerator):
        (JSC::DFG::slowPathFor):
        (JSC::DFG::virtualForThunkGenerator):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::dumpRegisters):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompile):
        * jit/JIT.h:
        (JIT):
        * jit/JITArithmetic.cpp:
        (JSC::JIT::emit_op_negate):
        (JSC::JIT::emitSlow_op_negate):
        (JSC::JIT::emit_op_rshift):
        (JSC::JIT::emitSlow_op_urshift):
        (JSC::JIT::emit_compareAndJumpSlow):
        (JSC::JIT::emit_op_bitand):
        (JSC::JIT::compileBinaryArithOpSlowCase):
        (JSC::JIT::emit_op_div):
        * jit/JITCall.cpp:
        (JSC::JIT::compileLoadVarargs):
        (JSC::JIT::compileCallEval):
        (JSC::JIT::compileCallEvalSlowCase):
        (JSC::JIT::compileOpCall):
        * jit/JITInlineMethods.h: Have some clean-up work as well.
        (JSC):
        (JSC::JIT::emitPutCellToCallFrameHeader):
        (JSC::JIT::emitPutIntToCallFrameHeader):
        (JSC::JIT::emitPutToCallFrameHeader):
        (JSC::JIT::emitGetFromCallFrameHeader32):
        (JSC::JIT::emitGetFromCallFrameHeader64):
        (JSC::JIT::emitAllocateJSArray):
        (JSC::JIT::emitValueProfilingSite):
        (JSC::JIT::emitGetJITStubArg):
        (JSC::JIT::emitGetVirtualRegister):
        (JSC::JIT::emitPutVirtualRegister):
        (JSC::JIT::emitInitRegister):
        (JSC::JIT::emitJumpIfJSCell):
        (JSC::JIT::emitJumpIfBothJSCells):
        (JSC::JIT::emitJumpIfNotJSCell):
        (JSC::JIT::emitLoadInt32ToDouble):
        (JSC::JIT::emitJumpIfImmediateInteger):
        (JSC::JIT::emitJumpIfNotImmediateInteger):
        (JSC::JIT::emitJumpIfNotImmediateIntegers):
        (JSC::JIT::emitFastArithReTagImmediate):
        (JSC::JIT::emitFastArithIntToImmNoCheck):
        * jit/JITOpcodes.cpp:
        (JSC::JIT::privateCompileCTINativeCall):
        (JSC::JIT::emit_op_mov):
        (JSC::JIT::emit_op_instanceof):
        (JSC::JIT::emit_op_is_undefined):
        (JSC::JIT::emit_op_is_boolean):
        (JSC::JIT::emit_op_is_number):
        (JSC::JIT::emit_op_tear_off_activation):
        (JSC::JIT::emit_op_not):
        (JSC::JIT::emit_op_jfalse):
        (JSC::JIT::emit_op_jeq_null):
        (JSC::JIT::emit_op_jneq_null):
        (JSC::JIT::emit_op_jtrue):
        (JSC::JIT::emit_op_bitxor):
        (JSC::JIT::emit_op_bitor):
        (JSC::JIT::emit_op_get_pnames):
        (JSC::JIT::emit_op_next_pname):
        (JSC::JIT::compileOpStrictEq):
        (JSC::JIT::emit_op_catch):
        (JSC::JIT::emit_op_throw_reference_error):
        (JSC::JIT::emit_op_eq_null):
        (JSC::JIT::emit_op_neq_null):
        (JSC::JIT::emit_op_create_activation):
        (JSC::JIT::emit_op_create_arguments):
        (JSC::JIT::emit_op_init_lazy_reg):
        (JSC::JIT::emitSlow_op_convert_this):
        (JSC::JIT::emitSlow_op_not):
        (JSC::JIT::emit_op_get_argument_by_val):
        (JSC::JIT::emit_op_put_to_base):
        (JSC::JIT::emit_resolve_operations):
        * jit/JITPropertyAccess.cpp:
        (JSC::JIT::emit_op_get_by_val):
        (JSC::JIT::emitContiguousGetByVal):
        (JSC::JIT::emitArrayStorageGetByVal):
        (JSC::JIT::emitSlow_op_get_by_val):
        (JSC::JIT::compileGetDirectOffset):
        (JSC::JIT::emit_op_get_by_pname):
        (JSC::JIT::emitContiguousPutByVal):
        (JSC::JIT::emitArrayStoragePutByVal):
        (JSC::JIT::compileGetByIdHotPath):
        (JSC::JIT::emit_op_put_by_id):
        (JSC::JIT::compilePutDirectOffset):
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::emit_op_init_global_const_check):
        (JSC::JIT::emitIntTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayGetByVal):
        (JSC::JIT::emitFloatTypedArrayPutByVal):
        * jit/JITStubCall.h:
        (JITStubCall):
        (JSC::JITStubCall::JITStubCall):
        (JSC::JITStubCall::addArgument):
        (JSC::JITStubCall::call):
        (JSC::JITStubCall::callWithValueProfiling):
        * jit/JSInterfaceJIT.h:
        (JSC::JSInterfaceJIT::emitJumpIfImmediateNumber):
        (JSC::JSInterfaceJIT::emitJumpIfNotImmediateNumber):
        (JSC::JSInterfaceJIT::emitLoadJSCell):
        (JSC::JSInterfaceJIT::emitLoadInt32):
        (JSC::JSInterfaceJIT::emitLoadDouble):
        * jit/SpecializedThunkJIT.h:
        (JSC::SpecializedThunkJIT::returnDouble):
        (JSC::SpecializedThunkJIT::tagReturnAsInt32):
        * runtime/JSValue.cpp:
        (JSC::JSValue::description):
        * runtime/JSValue.h: Define JSVALUE64 EncodedJSValue as int64_t, which is also unified with JSVALUE32_64.
        (JSC):
        * runtime/JSValueInlineMethods.h: New implementation of some JSValue methods to make them more conformant
        with the new rule that "JSValue is a 64-bit integer rather than a pointer" for JSVALUE64 platforms.
        (JSC):
        (JSC::JSValue::JSValue):
        (JSC::JSValue::operator bool):
        (JSC::JSValue::operator==):
        (JSC::JSValue::operator!=):
        (JSC::reinterpretDoubleToInt64):
        (JSC::reinterpretInt64ToDouble):
        (JSC::JSValue::asDouble):

1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859
2012-10-18  Michael Saboff  <msaboff@apple.com>

        convertUTF8ToUTF16() Should Check for ASCII Input
        ihttps://bugs.webkit.org/show_bug.cgi?id=99739

        Reviewed by Geoffrey Garen.

        Using the updated convertUTF8ToUTF16() , we can determine if is makes more sense to 
        create a string using the 8 bit source.  Added a new OpaqueJSString::create(LChar*, unsigned).
        Had to add a cast n JSStringCreateWithCFString to differentiate which create() to call.

        * API/JSStringRef.cpp:
        (JSStringCreateWithUTF8CString):
        * API/JSStringRefCF.cpp:
        (JSStringCreateWithCFString):
        * API/OpaqueJSString.h:
        (OpaqueJSString::create):
        (OpaqueJSString):
        (OpaqueJSString::OpaqueJSString):

oliver@apple.com's avatar
oliver@apple.com committed
1860 1861 1862 1863 1864 1865 1866 1867
2012-10-18  Oliver Hunt  <oliver@apple.com>

        Unbreak jsc tests.  Last minute "clever"-ness is clearly just not
        a good plan.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):

1868
2012-10-18  Oliver Hunt  <oliver@apple.com>
1869

1870 1871
        Bytecode should not have responsibility for determining how to perform non-local resolves
        https://bugs.webkit.org/show_bug.cgi?id=99349
1872

1873
        Reviewed by Gavin Barraclough.
1874

1875 1876 1877
        This patch removes lexical analysis from the bytecode generation.  This allows
        us to delay lookup of a non-local variables until the lookup is actually necessary,
        and simplifies a lot of the resolve logic in BytecodeGenerator.
1878

1879 1880 1881
        Once a lookup is performed we cache the lookup information in a set of out-of-line
        buffers in CodeBlock.  This allows subsequent lookups to avoid unnecessary hashing,
        etc, and allows the respective JITs to recreated optimal lookup code.
1882

1883 1884 1885 1886 1887 1888
        This is currently still a performance regression in LLInt, but most of the remaining
        regression is caused by a lot of indirection that I'll remove in future work, as well
        as some work necessary to allow LLInt to perform in line instruction repatching.
        We will also want to improve the behaviour of the baseline JIT for some of the lookup
        operations, however this patch was getting quite large already so I'm landing it now
        that we've reached the bar of "performance-neutral".
1889

1890
        Basic browsing seems to work.
1891

1892 1893 1894 1895 1896 1897 1898
        * GNUmakefile.list.am:
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::printStructures):
        (JSC::CodeBlock::dump):
        (JSC::CodeBlock::CodeBlock):
        (JSC::CodeBlock::visitStructures):
1899
        (JSC):
1900 1901 1902
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC::CodeBlock::shrinkToFit):
        * bytecode/CodeBlock.h:
1903 1904
        (JSC::CodeBlock::addResolve):
        (JSC::CodeBlock::addPutToBase):
1905
        (CodeBlock):
1906 1907 1908 1909 1910 1911 1912
        (JSC::CodeBlock::resolveOperations):
        (JSC::CodeBlock::putToBaseOperation):
        (JSC::CodeBlock::numberOfResolveOperations):
        (JSC::CodeBlock::numberOfPutToBaseOperations):
        (JSC::CodeBlock::addPropertyAccessInstruction):
        (JSC::CodeBlock::globalObjectConstant):
        (JSC::CodeBlock::setGlobalObjectConstant):
1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931
        * bytecode/Opcode.h:
        (JSC):
        (JSC::padOpcodeName):
        * bytecode/ResolveGlobalStatus.cpp:
        (JSC::computeForStructure):
        (JSC::ResolveGlobalStatus::computeFor):
        * bytecode/ResolveGlobalStatus.h:
        (JSC):
        (ResolveGlobalStatus):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::ResolveResult::checkValidity):
        (JSC):
        (JSC::BytecodeGenerator::BytecodeGenerator):
        (JSC::BytecodeGenerator::resolve):
        (JSC::BytecodeGenerator::resolveConstDecl):
        (JSC::BytecodeGenerator::shouldAvoidResolveGlobal):
        (JSC::BytecodeGenerator::emitResolve):
        (JSC::BytecodeGenerator::emitResolveBase):
        (JSC::BytecodeGenerator::emitResolveBaseForPut):
1932
        (JSC::BytecodeGenerator::emitResolveWithBaseForPut):
1933
        (JSC::BytecodeGenerator::emitResolveWithThis):
1934
        (JSC::BytecodeGenerator::emitGetLocalVar):
1935
        (JSC::BytecodeGenerator::emitInitGlobalConst):
1936
        (JSC::BytecodeGenerator::emitPutToBase):
1937 1938 1939 1940 1941
        * bytecompiler/BytecodeGenerator.h:
        (JSC::ResolveResult::registerResolve):
        (JSC::ResolveResult::dynamicResolve):
        (ResolveResult):
        (JSC::ResolveResult::ResolveResult):
1942 1943 1944 1945 1946 1947
        (JSC):
        (NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::~NonlocalResolveInfo):
        (JSC::NonlocalResolveInfo::resolved):
        (JSC::NonlocalResolveInfo::put):
1948
        (BytecodeGenerator):
1949 1950 1951 1952 1953 1954
        (JSC::BytecodeGenerator::getResolveOperations):
        (JSC::BytecodeGenerator::getResolveWithThisOperations):
        (JSC::BytecodeGenerator::getResolveBaseOperations):
        (JSC::BytecodeGenerator::getResolveBaseForPutOperations):
        (JSC::BytecodeGenerator::getResolveWithBaseForPutOperations):
        (JSC::BytecodeGenerator::getPutToBaseOperation):
1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ResolveNode::isPure):
        (JSC::FunctionCallResolveNode::emitBytecode):
        (JSC::PostfixNode::emitResolve):
        (JSC::PrefixNode::emitResolve):
        (JSC::ReadModifyResolveNode::emitBytecode):
        (JSC::AssignResolveNode::emitBytecode):
        (JSC::ConstDeclNode::emitCodeSingle):
        (JSC::ForInNode::emitBytecode):
        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::execute):
        * dfg/DFGByteCodeParser.cpp:
        (ByteCodeParser):
        (InlineStackEntry):
        (JSC::DFG::ByteCodeParser::handleGetByOffset):
1970 1971
        (DFG):
        (JSC::DFG::ByteCodeParser::parseResolveOperations):
1972 1973 1974
        (JSC::DFG::ByteCodeParser::parseBlock):
        (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
        * dfg/DFGCapabilities.h:
1975
        (JSC::DFG::canInlineResolveOperations):
1976 1977 1978 1979 1980
        (DFG):
        (JSC::DFG::canCompileOpcode):
        (JSC::DFG::canInlineOpcode):
        * dfg/DFGGraph.h:
        (ResolveGlobalData):
1981
        (ResolveOperationData):
1982
        (DFG):
1983
        (PutToBaseOperationData):
1984 1985 1986
        (Graph):
        * dfg/DFGNode.h:
        (JSC::DFG::Node::hasIdentifier):
1987 1988
        (JSC::DFG::Node::resolveOperationsDataIndex):
        (Node):
1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::OSRExit):
        * dfg/DFGOSRExit.h:
        (OSRExit):
        * dfg/DFGOSRExitCompiler.cpp:
        * dfg/DFGOSRExitCompiler32_64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOSRExitCompiler64.cpp:
        (JSC::DFG::OSRExitCompiler::compileExit):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGRepatch.cpp:
        (JSC::DFG::tryCacheGetByID):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
        * dfg/DFGSpeculativeJIT.h:
2009 2010 2011
        (JSC::DFG::SpeculativeJIT::resolveOperations):
        (SpeculativeJIT):
        (JSC::DFG::SpeculativeJIT::putToBaseOperation):
2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
        (JSC::DFG::SpeculativeJIT::callOperation):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGStructureCheckHoistingPhase.cpp:
        (JSC::DFG::StructureCheckHoistingPhase::run):
        * jit/JIT.cpp:
        (JSC::JIT::privateCompileMainPass):
        (JSC::JIT::privateCompileSlowCases):
        * jit/JIT.h:
        (JIT):
        * jit/JITOpcodes.cpp:
2025
        (JSC::JIT::emit_op_put_to_base):
2026
        (JSC):
2027 2028 2029 2030
        (JSC::JIT::emit_resolve_operations):
        (JSC::JIT::emitSlow_link_resolve_operations):
        (JSC::JIT::emit_op_resolve):
        (JSC::JIT::emitSlow_op_resolve):
2031
        (JSC::JIT::emit_op_resolve_base):
2032
        (JSC::JIT::emitSlow_op_resolve_base):
2033
        (JSC::JIT::emit_op_resolve_with_base):
2034
        (JSC::JIT::emitSlow_op_resolve_with_base):
2035
        (JSC::JIT::emit_op_resolve_with_this):
2036 2037
        (JSC::JIT::emitSlow_op_resolve_with_this):
        (JSC::JIT::emitSlow_op_put_to_base):
2038
        * jit/JITOpcodes32_64.cpp:
2039
        (JSC::JIT::emit_op_put_to_base):
2040 2041
        (JSC):
        * jit/JITPropertyAccess.cpp:
2042 2043 2044
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::emit_op_init_global_const_check):
        (JSC::JIT::emitSlow_op_init_global_const_check):
2045
        * jit/JITPropertyAccess32_64.cpp:
2046 2047 2048
        (JSC::JIT::emit_op_init_global_const):
        (JSC::JIT::emit_op_init_global_const_check):
        (JSC::JIT::emitSlow_op_init_global_const_check):
2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        (JSC):
        * jit/JITStubs.h:
        * llint/LLIntSlowPaths.cpp:
        (LLInt):
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * llint/LLIntSlowPaths.h:
        (LLInt):
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * llint/LowLevelInterpreter64.asm:
        * runtime/JSScope.cpp:
2062 2063 2064 2065 2066 2067 2068 2069 2070 2071
        (JSC::LookupResult::base):
        (JSC::LookupResult::value):
        (JSC::LookupResult::setBase):
        (JSC::LookupResult::setValue):
        (LookupResult):
        (JSC):
        (JSC::setPutPropertyAccessOffset):
        (JSC::executeResolveOperations):
        (JSC::JSScope::resolveContainingScopeInternal):
        (JSC::JSScope::resolveContainingScope):
2072 2073 2074 2075
        (JSC::JSScope::resolve):
        (JSC::JSScope::resolveBase):
        (JSC::JSScope::resolveWithBase):
        (JSC::JSScope::resolveWithThis):
2076 2077
        (JSC::JSScope::resolvePut):
        (JSC::JSScope::resolveGlobal):
2078 2079 2080
        * runtime/JSScope.h:
        (JSScope):
        * runtime/JSVariableObject.cpp:
2081
        (JSC):
2082
        * runtime/JSVariableObject.h:
2083
        (JSVariableObject):
2084
        * runtime/Structure.h:
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 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
        (JSC::Structure::propertyAccessesAreCacheable):
        (Structure):

2012-10-18  Mark Hahnenberg  <mhahnenberg@apple.com>

        Live oversize copied blocks should count toward overall heap fragmentation
        https://bugs.webkit.org/show_bug.cgi?id=99548

        Reviewed by Filip Pizlo.

        The CopiedSpace uses overall heap fragmentation to determine whether or not it should do any copying. 
        Currently it doesn't include live oversize CopiedBlocks in the calculation, but it should. We should 
        treat them as 100% utilized, since running a copying phase won't be able to free/compact any of their 
        memory. We can also free any dead oversize CopiedBlocks while we're iterating over them, rather than 
        iterating over them again at the end of the copying phase.

        * heap/CopiedSpace.cpp:
        (JSC::CopiedSpace::doneFillingBlock):
        (JSC::CopiedSpace::startedCopying):
        (JSC::CopiedSpace::doneCopying): Also removed a branch when iterating over from-space at the end of 
        copying. Since we eagerly recycle blocks as soon as they're fully evacuated, we should see no
        unpinned blocks in from-space at the end of copying.
        * heap/CopiedSpaceInlineMethods.h:
        (JSC::CopiedSpace::recycleBorrowedBlock):
        * heap/CopyVisitorInlineMethods.h:
        (JSC::CopyVisitor::checkIfShouldCopy):

2012-10-18  Roger Fong  <roger_fong@apple.com>

        Unreviewed. Build fix after r131701 and r131777.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.def:

2012-10-18  Mark Hahnenberg  <mhahnenberg@apple.com>

        Race condition between GCThread and main thread during copying phase
        https://bugs.webkit.org/show_bug.cgi?id=99641

        Reviewed by Filip Pizlo.

        When a GCThread returns from copyFromShared(), it then calls doneCopying(), which returns 
        its borrowed CopiedBlock to the CopiedSpace. This final block allows the CopiedSpace to 
        continue and finish the cleanup of the copying phase. However, the GCThread can loop back 
        around, see that m_currentPhase is still "Copy", and try to go through the copying phase again. 
        This can cause all sorts of issues. To fix this, we should add a cyclic barrier to GCThread::waitForNextPhase().

        * heap/GCThread.cpp:
        (JSC::GCThread::waitForNextPhase): All GCThreads will wait when they finish one iteration until the main thread 
        notifies them to move down to the second while loop, where they wait for the next GCPhase to start. They also 
        decrement the m_numberOfActiveGCThreads counter as they begin to wait for the next phase and increment it as 
        they enter the next phase. This allows the main thread to wait in endCurrentPhase() until all the threads have 
        finished the current phase and are waiting on the next phase to begin. Without the counter, there would be 
        no way to ensure that every thread was available for each GCPhase.
        (JSC::GCThread::gcThreadMain): We now use the m_phaseLock to synchronize with the main thread when we're being created.
        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData): As we create each GCThread, we increment the m_numberOfActiveGCThreads
        counter. When we are done creating the threads, we wait until they're all waiting for the next GCPhase. This prevents 
        us from leaving some GCThreads behind during the first GCPhase, which could hurt us on our very short-running 
        benchmarks (e.g. SunSpider).
        (JSC::GCThreadSharedData::~GCThreadSharedData):
        (JSC::GCThreadSharedData::startNextPhase): We atomically swap the two flags, m_gcThreadsShouldWait and m_currentPhase, 
        so that if the threads finish very quickly, they will wait until the main thread is ready to end the current phase.
        (JSC::GCThreadSharedData::endCurrentPhase): Here atomically we swap the two flags again to allow the threads to 
        advance to waiting on the next GCPhase. We wait until all of the GCThreads have settled into the second wait loop
        before allowing the main thread to continue. This prevents us from leaving one of the GCThreads stuck in the first 
        wait loop if we were to call startNextPhase() before it had time to wake up and move on to the second wait loop.
        (JSC):
        (JSC::GCThreadSharedData::didStartMarking): We now use startNextPhase() to properly swap the flags.
        (JSC::GCThreadSharedData::didFinishMarking): Ditto for endCurrentPhase().
        (JSC::GCThreadSharedData::didStartCopying): Ditto.
        (JSC::GCThreadSharedData::didFinishCopying): Ditto.
        * heap/GCThreadSharedData.h:
        (GCThreadSharedData):
        * heap/Heap.cpp: 
        (JSC::Heap::copyBackingStores): No reason to use the extra reference.

2012-10-18  Pablo Flouret  <pablof@motorola.com>

        Implement css3-conditional's @supports rule
        https://bugs.webkit.org/show_bug.cgi?id=86146

        Reviewed by Antti Koivisto.

        * Configurations/FeatureDefines.xcconfig:
            Add an ENABLE_CSS3_CONDITIONAL_RULES flag.

2012-10-18  Michael Saboff  <msaboff@apple.com>

        Make conversion between JSStringRef and WKStringRef work without character size conversions
        https://bugs.webkit.org/show_bug.cgi?id=99727

        Reviewed by Anders Carlsson.

        Export the string() method for use in WebKit.

        * API/OpaqueJSString.h:
        (OpaqueJSString::string):

2012-10-18  Raphael Kubo da Costa  <raphael.kubo.da.costa@intel.com>

        [CMake] Avoid unnecessarily running the LLInt generation commands.
        https://bugs.webkit.org/show_bug.cgi?id=99708

        Reviewed by Rob Buis.

        As described in the comments in the change itself, in some cases
        the Ruby generation scripts used when LLInt is on would each be
        run twice in every build even if nothing had changed.

        Fix that by not setting the OBJECT_DEPENDS property of some source
        files to depend on the generated headers; instead, they are now
        just part of the final binaries/libraries which use them.

        * CMakeLists.txt:

2012-10-17  Zoltan Horvath  <zoltan@webkit.org>

        Remove the JSHeap memory measurement of the PageLoad performacetests since it creates bogus JSGlobalDatas
        https://bugs.webkit.org/show_bug.cgi?id=99609 

        Reviewed by Ryosuke Niwa.

        Remove the implementation since it creates bogus JSGlobalDatas in the layout tests.

        * heap/HeapStatistics.cpp:
        (JSC):
        * heap/HeapStatistics.h:
        (HeapStatistics):

2012-10-17  Sam Weinig  <sam@webkit.org>

        Attempt to fix the build.

        * bytecode/GlobalResolveInfo.h: Copied from bytecode/GlobalResolveInfo.h.
2219

2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237
2012-10-17  Filip Pizlo  <fpizlo@apple.com>

        REGRESSION (r130826 or r130828): Twitter top bar is dysfunctional
        https://bugs.webkit.org/show_bug.cgi?id=99577
        <rdar://problem/12518883>

        Reviewed by Mark Hahnenberg.

        It turns out that it's a good idea to maintain the invariants of your object model, such as that
        elements past publicLength should have the hole value.

        * dfg/DFGGraph.cpp:
        (JSC::DFG::Graph::dump):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):

andersca@apple.com's avatar
andersca@apple.com committed
2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253
2012-10-17  Anders Carlsson  <andersca@apple.com>

        Clean up Vector.h
        https://bugs.webkit.org/show_bug.cgi?id=99622

        Reviewed by Benjamin Poulain.

        Fix fallout from removing std::max and std::min using declarations.

        * runtime/StringPrototype.cpp:
        (JSC::jsSpliceSubstrings):
        (JSC::jsSpliceSubstringsWithSeparators):
        (JSC::stringProtoFuncIndexOf):
        * yarr/YarrPattern.cpp:
        (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets):

2254 2255 2256 2257 2258 2259 2260 2261