2016-08-29  Babak Shafiei  <bshafiei@apple.com>

        Merge r204572.

    2016-08-17  Geoffrey Garen  <ggaren@apple.com>

            Fixed a potential bug in MarkedArgumentBuffer.
            https://bugs.webkit.org/show_bug.cgi?id=160948
            <rdar://problem/27889416>

            Reviewed by Oliver Hunt.

            I haven't been able to produce an observable test case after some trying.

            * runtime/ArgList.cpp:
            (JSC::MarkedArgumentBuffer::addMarkSet): New helper function -- I broke
            this out from existing code for clarity, but the behavior is the same.

            (JSC::MarkedArgumentBuffer::expandCapacity): Ditto.

            (JSC::MarkedArgumentBuffer::slowAppend): Always addMarkSet() on the slow
            path. This is faster than the old linear scan, and I think it might
            avoid cases the old scan could miss.

            * runtime/ArgList.h:
            (JSC::MarkedArgumentBuffer::append): Account for the case where someone
            has called clear() or removeLast().

            (JSC::MarkedArgumentBuffer::mallocBase): No behavior change -- but it's
            clearer to test the buffers directly instead of inferring what they
            might be based on capacity.

2016-05-12  Babak Shafiei  <bshafiei@apple.com>

        Merge patch for r200387.

    2016-05-03  Michael Saboff  <msaboff@apple.com>

            Crash: Array.prototype.slice() and .splice() can call fastSlice() after an array is truncated
            https://bugs.webkit.org/show_bug.cgi?id=157322

            Reviewed by Filip Pizlo.

            Check to see if the source array has changed length before calling fastSlice().
            If it has, take the slow path.

            * runtime/ArrayPrototype.cpp:
            (JSC::arrayProtoFuncSlice):
            (JSC::arrayProtoFuncSplice):
            * tests/stress/regress-157322.js: New test.

2016-05-11  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r199277. rdar://problem/26228546

    2016-04-09  Saam barati  <sbarati@apple.com>

            Allocation sinking SSA Defs are allowed to have replacements
            https://bugs.webkit.org/show_bug.cgi?id=156444

            Reviewed by Filip Pizlo.

            Consider the following program and the annotations that explain why
            the SSA defs we create in allocation sinking can have replacements.

            function foo(a1) {
                let o1 = {x: 20, y: 50};
                let o2 = {y: 40, o1: o1};
                let o3 = {};

                // We're Defing a new variable here, call it o3_field.
                // o3_field is defing the value that is the result of
                // a GetByOffset that gets eliminated through allocation sinking.
                o3.field = o1.y;

                dontCSE();

                // This control flow is here to not allow the phase to consult
                // its local SSA mapping (which properly handles replacements)
                // for the value of o3_field.
                if (a1) {
                    a1 = true;
                } else {
                    a1 = false;
                }

                // Here, we ask for the reaching def of o3_field, and assert
                // it doesn't have a replacement. It does have a replacement
                // though. The original Def was the GetByOffset. We replaced
                // that GetByOffset with the value of the o1_y variable.
                let value = o3.field;
                assert(value === 50);
            }

            * dfg/DFGObjectAllocationSinkingPhase.cpp:
            * tests/stress/allocation-sinking-defs-may-have-replacements.js: Added.
            (dontCSE):
            (assert):
            (foo):

2016-05-11  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r196524. rdar://problem/26228552

    2016-02-12  Filip Pizlo  <fpizlo@apple.com>

            JSObject::putByIndexBeyondVectorLengthWithoutAttributes needs to go to the sparse map based on MAX_STORAGE_VECTOR_INDEX
            https://bugs.webkit.org/show_bug.cgi?id=154201
            rdar://problem/24291387

            Reviewed by Saam Barati.

            I decided against adding a test for this, because it runs for a very long time.

            * runtime/JSObject.cpp:
            (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): Fix the bug.
            * runtime/StringPrototype.cpp:
            (JSC::stringProtoFuncSplit): Fix a related bug: if this code creates an array that would have
                hit the above bug, then it would probably manifest as a spin or as swapping.

2016-03-24  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r198592. rdar://problem/25332806

    2016-03-23  Michael Saboff  <msaboff@apple.com>

            JavaScriptCore ArrayPrototype::join shouldn't cache butterfly when it makes effectful calls
            https://bugs.webkit.org/show_bug.cgi?id=155776

            Reviewed by Saam Barati.

            Array.join ends up calling toString, possibly on some object.  Since these calls
            could be effectful and could change the array itself, we can't hold the butterfly
            pointer while making effectful calls.  Changed the code to fall back to the general
            case when an effectful toString() call might be made.

            * runtime/ArrayPrototype.cpp:
            (JSC::join):
            * runtime/JSStringJoiner.h:
            (JSC::JSStringJoiner::appendWithoutSideEffects): New helper that doesn't make effectful
            toString() calls.
            (JSC::JSStringJoiner::append): Built upon appendWithoutSideEffects.

2015-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>

        Iterator loops over key twice after delete
        https://bugs.webkit.org/show_bug.cgi?id=149811

        Reviewed by Geoffrey Garen.

        When an object is the dictionary mode, JSPropertyNameEnumerator collects property names through generic property name enumeration `getPropertyNames`.
        The result vector contains indexed property names. But in this case, `publicLength()` may not be 0.
        So without disabling indexed names enumeration phase explicitly, JSPropertyNameEnumerator produces indexed property names twice.
        One in indexed name enumeration phase, and another in generic property name enumeration phase.
        This patch disables indexed names enumeration by setting `indexedLength` to 0 when collecting names through generic property name enumeration.

        * runtime/JSPropertyNameEnumerator.h:
        (JSC::propertyNameEnumerator):
        * tests/stress/property-name-enumerator-should-not-look-into-indexed-values-when-it-is-a-dictionary.js: Added.
        (shouldBe):
        (col2.of.Reflect.enumerate):

2015-10-02  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r189460. rdar://problem/22802036

    2015-09-06  Mark Lam  <mark.lam@apple.com>

            Gardening: fix broken Windows build after r189454.

            Not reviewed.

            * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
            * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:

2015-09-03  Babak Shafiei  <bshafiei@apple.com>

        Merge r189046.

    2015-08-27  Basile Clement  <basile_clement@apple.com>

            REGRESSION(r184779): Possible read-after-free in JavaScriptCore/dfg/DFGClobberize.h
            https://bugs.webkit.org/show_bug.cgi?id=148411

            Reviewed by Geoffrey Garen and Filip Pizlo.

            * dfg/DFGClobberize.h:
            (JSC::DFG::clobberize):

2015-09-03  Babak Shafiei  <bshafiei@apple.com>

        Merge r188311.

    2015-08-11  Alexey Proskuryakov  <ap@apple.com>

            Make ASan build not depend on asan.xcconfig
            https://bugs.webkit.org/show_bug.cgi?id=147840
            rdar://problem/21093702

            Reviewed by Daniel Bates.

            * dfg/DFGOSREntry.cpp:
            (JSC::DFG::OSREntryData::dump):
            (JSC::DFG::prepareOSREntry):
            * ftl/FTLOSREntry.cpp:
            (JSC::FTL::prepareOSREntry):
            * heap/ConservativeRoots.cpp:
            (JSC::ConservativeRoots::genericAddPointer):
            (JSC::ConservativeRoots::genericAddSpan):
            * heap/MachineStackMarker.cpp:
            (JSC::MachineThreads::removeThreadIfFound):
            (JSC::MachineThreads::gatherFromCurrentThread):
            (JSC::MachineThreads::Thread::captureStack):
            (JSC::copyMemory):
            * interpreter/Register.h:
            (JSC::Register::operator=):
            (JSC::Register::asanUnsafeJSValue):
            (JSC::Register::jsValue):

2015-09-03  Babak Shafiei  <bshafiei@apple.com>

        Merge r188067.

    2015-08-06  Filip Pizlo  <fpizlo@apple.com>

            Structures used for tryGetConstantProperty() should be registered first
            https://bugs.webkit.org/show_bug.cgi?id=147750

            Reviewed by Saam Barati and Michael Saboff.

            * dfg/DFGGraph.cpp:
            (JSC::DFG::Graph::tryGetConstantProperty): Add an assertion to that effect. This should catch the bug sooner.
            * dfg/DFGGraph.h:
            (JSC::DFG::Graph::addStructureSet): Register structures when we make a structure set. That ensures that we won't call tryGetConstantProperty() on a structure that hasn't been registered yet.
            * dfg/DFGStructureRegistrationPhase.cpp:
            (JSC::DFG::StructureRegistrationPhase::run): Don't register structure sets here anymore. Registering them before we get here means there is no chance of the code being DCE'd before the structures get registered. It also enables the tryGetConstantProperty() assertion, since that code runs before StructureRegisterationPhase.
            (JSC::DFG::StructureRegistrationPhase::registerStructures):
            (JSC::DFG::StructureRegistrationPhase::registerStructure):
            (JSC::DFG::StructureRegistrationPhase::assertAreRegistered):
            (JSC::DFG::StructureRegistrationPhase::assertIsRegistered):
            (JSC::DFG::performStructureRegistration):

2015-08-27  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r189012. rdar://problem/22084478

    2015-08-26  Saam barati  <sbarati@apple.com>

            MarkedBlock::allocateBlock will have the wrong allocation size when (sizeof(MarkedBlock) + bytes) is divisible by WTF::pageSize()
            https://bugs.webkit.org/show_bug.cgi?id=148500

            Reviewed by Mark Lam.

            Consider the following scenario:
            - On OS X, WTF::pageSize() is 4*1024 bytes.
            - JSEnvironmentRecord::allocationSizeForScopeSize(6621) == 53000
            - sizeof(MarkedBlock) == 248
            - (248 + 53000) is a multiple of 4*1024.
            - (248 + 53000)/(4*1024) == 13

            We will allocate a chunk of memory of size 53248 bytes that looks like this:
            0            248       256                       53248       53256
            [Marked Block | 8 bytes |  payload     ......      ]  8 bytes  |
                                    ^                                      ^
                               Our Environment record starts here.         ^
                                                                           ^
                                                                     Our last JSValue in the environment record will go from byte 53248 to 53256. But, we don't own this memory.

            We need to ensure that we round up sizeof(MarkedBlock) to an
            atomSize boundary. We need to do this because the first atom
            inside the MarkedBlock will start at the rounded up multiple
            of atomSize past MarkedBlock. If we end up with an allocation
            that is perfectly aligned to the page size, then we will be short
            8 bytes (in the current implementation where atomSize is 16 bytes,
            and MarkedBlock is 248 bytes).

            * heap/MarkedAllocator.cpp:
            (JSC::MarkedAllocator::allocateBlock):
            * tests/stress/heap-allocator-allocates-incorrect-size-for-activation.js: Added.
            (use):
            (makeFunction):

2015-07-31  Lucas Forschler  <lforschler@apple.com>

        Merge r187579

    2015-07-29  Filip Pizlo  <fpizlo@apple.com>

            DFG::ArgumentsEliminationPhase should emit a PutStack for all of the GetStacks that the ByteCodeParser emitted
            https://bugs.webkit.org/show_bug.cgi?id=147433
            rdar://problem/21668986

            Reviewed by Mark Lam.

            Ideally, the ByteCodeParser would only emit SetArgument nodes for named arguments.  But
            currently that's not what it does - it emits a SetArgument for every argument that a varargs
            call may pass.  Each SetArgument gets turned into a GetStack.  This means that if
            ArgumentsEliminationPhase optimizes away PutStacks for those varargs arguments that didn't
            get passed or used, we get degenerate IR where we have a GetStack of something that didn't
            have a PutStack.

            This fixes the bug by removing the code to optimize away PutStacks in
            ArgumentsEliminationPhase.

            * dfg/DFGArgumentsEliminationPhase.cpp:
            * tests/stress/varargs-inlining-underflow.js: Added.
            (baz):
            (bar):
            (foo):

2015-07-24  Matthew Hanson  <matthew_hanson@apple.com>

        Merge r187139. rdar://problem/21847618

    2015-07-21  Filip Pizlo  <fpizlo@apple.com>

            Unreviewed, fix a lot of tests. Need to initialize WTF threading sooner.

            * jsc.cpp:
            (main):

2015-07-23  Lucas Forschler  <lforschler@apple.com>

        Merge r187125

    2015-07-21  Filip Pizlo  <fpizlo@apple.com>

            Fixed VM pool allocation should have a reserve for allocations that cannot fail
            https://bugs.webkit.org/show_bug.cgi?id=147154
            rdar://problem/21847618

            Reviewed by Geoffrey Garen.

            This adds the notion of a JIT pool reserve fraction. Some fraction, currently 1/4, of
            the JIT pool is reserved for allocations that cannot fail. It makes sense to make this
            a fraction rather than a constant because each allocation that can fail may cause some
            number of allocations that cannot fail (for example, the OSR exit thunks that we
            compile when we exit from some CodeBlock cannot fail).

            I've tested this by adding a test mode where we artificially limit the JIT pool size.
            Prior to the fix, we had >20 failures. Now we have none.

            * heap/GCLogging.cpp:
            (WTF::printInternal): I needed a dump method on Options members when debugging this.
            * heap/GCLogging.h:
            * jit/ExecutableAllocator.h: Raise the ARM64 limit to 32MB because 16MB is cutting it too close.
            * jit/ExecutableAllocatorFixedVMPool.cpp:
            (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Add the ability to artificially limit JIT pool size for testing.
            (JSC::ExecutableAllocator::memoryPressureMultiplier): Implement the reserve when computing memory pressure for JIT tier-up heuristics.
            (JSC::ExecutableAllocator::allocate): Implement the reserve when allocating can-fail things.
            * jsc.cpp: Rewire some options parsing so that CommandLine happens before we create the JIT pool.
            (main):
            (CommandLine::parseArguments):
            (jscmain):
            * runtime/Options.cpp: 
            (JSC::OptionRange::dump): I needed a dump method on Options members when debugging this.
            (JSC::Options::initialize): This can now be called more than once.
            * runtime/Options.h:

== Rolled over to ChangeLog-2015-07-23 ==
