Bug 149338 – [ES6] "super" and "this" should be lexically bound inside an arrow function and should live in a JSLexicalEnvironment

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Joseph Pecoraro]

* SUMMARY
Arrow Function before super() causes TDZ, should it?

You get a non-obvious TDZ runtime ReferenceError when you create an arrow function before calling super() in a subclass.

* TEST
<script>
class Parent { }
class Subclass extends Parent {
    constructor() {
        let x = () => {}; // TDZ because of capturing "this"
        super();
    }
}
console.log(new Subclass);
</script>

* PRODUCES
[Error] ReferenceError: Cannot access uninitialized variable.
	Subclass
	(anonymous function)

[Joseph Pecoraro]

>     constructor() {
>         let x = () => {}; // TDZ because of capturing "this"
>         super();
>     }

I should clarify that the comment is my assumption. But I don't know what else could be causing the issue =)

I don't think this should trigger a TDZ. Even if `x` was evaluated `x()` I don't think it should be an issue as long as it doesn't actually reference `this`.

[GSkachkov]

Yes, this is error message caused because of TDZ check before super() call. Now it always captures 'this' without checking if it is used and whether or not

[Saam Barati]

I think we can be smart and not do anything if the "this"
isn't used in the arrow function. But after speaking with Joe, 
I believe it should never throw on construction. The "this"
should be under TDZ, which means it should be only dependent on
time and not location in code. So, as long as super() is invoked
before a "this" is evaluated inside the arrow function, we should
be okay. For example, this is ok:

class C {
    constructor() {
        let x = () => (false ? this : 20);
        x();
        super();
    }
}

[Filip Pizlo]

(In reply to comment #3)
> I think we can be smart and not do anything if the "this"
> isn't used in the arrow function. But after speaking with Joe, 
> I believe it should never throw on construction. The "this"
> should be under TDZ, which means it should be only dependent on
> time and not location in code. So, as long as super() is invoked
> before a "this" is evaluated inside the arrow function, we should
> be okay. For example, this is ok:
> 
> class C {
>     constructor() {
>         let x = () => (false ? this : 20);
>         x();
>         super();
>     }
> }

And also things like this should work:

class C {
    constructor() {
        let p = false;
        let x = () => (p ? this : 20);
        x(); // returns 20
        super();
        p = true;
        x(); // returns 'this'
    }
}

This should return without throwing.

[GSkachkov]

Created attachment 262329 [details]
Patch

Draft version of the patch, just to check if way to implement is correct

[GSkachkov]

Comment on attachment 262329 [details]
Patch

I've prepared new patch with merged op_codes and correct TDZ check of 'this'. I'll clear it little bit and upload tomorrow.

[GSkachkov]

Created attachment 262397 [details]
Patch

Updated draft version of the patch

[Saam Barati]

Comment on attachment 262397 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=262397&action=review

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:485
> +            RefPtr<RegisterID> parentScope = m_lexicalEnvironmentRegister

We have a byte code variable m_topMostScope that does what you're doing here, but I think this logic is wrong.
Consider this program:
constructor() {
    if (c) {
         let x = 20;
         function captureX() { }
         if (c) {
            let x = 20;
            function captureX() { return x; }
            let arr = (blah) => blah;
         }
    }
}

The "arr" won't be created with the parent scope that contains the "this".

I think you just want a resolveScope followed by a getFromScope.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2949
> +        emitPutToScope(scopeRegister(), thisVar, thisRegister(), ThrowIfNotFound, NotInitialization);

I think special casing "this" as a new thing both in terms of a resolve type
and in terms of a variable on JSScope is the wrong way to go about implementing this feature.

Here is one suggestion on how to solve this differently:
Anytime a function has an arrow function nested inside of it,
the parent function should create a lexical environment. Once this parent
function also creates the "this" variable, it should place it inside
the lexical environment it created. (This solves the problem in this code which keeps putting
the "this" into the activation every time an arrow function is created
even if "this" hasn't changed). Any time you make a call to super()
and you have a nested arrow function, you update the "this" inside
the lexical environment. Child functions that read from "this" can
just do so the normal way: resolveScope() then getFromScope().

The parent function that has the "this" inside the lexical environment
should just do what it normally does for lexical environments. The "this"
identifier should have a slot inside the symbol table, etc. I think this
would take away almost all this special case code for "this". Then, the "thisNode",
when inside an arrow function, should be smart and load the "this" from
the lexical environment using resolveScope() then getFromScope(). I believe
this suggested solution will cause "this" inside an environment to just work
for the most part.

> Source/JavaScriptCore/jit/JITOperations.cpp:1995
> +    if (getPutInfo.resolveType() == LexicallyBoundVar) {

I think special casing this is wrong. We should just be able to put the "this" identifier into an environment and have this code work.

[GSkachkov]

Created attachment 262435 [details]
Patch

Updated draft version of the patch. Implemented in function context. (EvalNode & ProgramNode is not implemented). Version #3

[WebKit Commit Bot]

Attachment 262435 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/jit/JITOperations.cpp:1951:  One space before end of line comments  [whitespace/comments] [5]
ERROR: Source/JavaScriptCore/jit/JITOperations.cpp:1951:  Should have a space between // and comment  [whitespace/comments] [4]
ERROR: Source/JavaScriptCore/jit/JITOperations.cpp:2020:  Should have a space between // and comment  [whitespace/comments] [4]
ERROR: Source/JavaScriptCore/jit/JITOperations.cpp:2020:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/jit/JITOperations.cpp:2022:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/jit/JITOperations.cpp:2023:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 6 in 23 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[GSkachkov]

Comment on attachment 262397 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=262397&action=review

I've uploaded new patch. It is as previous just Draft, but it look more 'mature' for me. Patch covers only 'Function' case in BytecodeGenerator, because creating of lexical_env already implemented in it. If new patch more or less ok in approach to store 'this' I'll try to implement  lexical_env for 'Program' & 'Eval' case

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:485
>> +            RefPtr<RegisterID> parentScope = m_lexicalEnvironmentRegister
> 
> We have a byte code variable m_topMostScope that does what you're doing here, but I think this logic is wrong.
> Consider this program:
> constructor() {
>     if (c) {
>          let x = 20;
>          function captureX() { }
>          if (c) {
>             let x = 20;
>             function captureX() { return x; }
>             let arr = (blah) => blah;
>          }
>     }
> }
> 
> The "arr" won't be created with the parent scope that contains the "this".
> 
> I think you just want a resolveScope followed by a getFromScope.

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2949
>> +        emitPutToScope(scopeRegister(), thisVar, thisRegister(), ThrowIfNotFound, NotInitialization);
> 
> I think special casing "this" as a new thing both in terms of a resolve type
> and in terms of a variable on JSScope is the wrong way to go about implementing this feature.
> 
> Here is one suggestion on how to solve this differently:
> Anytime a function has an arrow function nested inside of it,
> the parent function should create a lexical environment. Once this parent
> function also creates the "this" variable, it should place it inside
> the lexical environment it created. (This solves the problem in this code which keeps putting
> the "this" into the activation every time an arrow function is created
> even if "this" hasn't changed). Any time you make a call to super()
> and you have a nested arrow function, you update the "this" inside
> the lexical environment. Child functions that read from "this" can
> just do so the normal way: resolveScope() then getFromScope().
> 
> The parent function that has the "this" inside the lexical environment
> should just do what it normally does for lexical environments. The "this"
> identifier should have a slot inside the symbol table, etc. I think this
> would take away almost all this special case code for "this". Then, the "thisNode",
> when inside an arrow function, should be smart and load the "this" from
> the lexical environment using resolveScope() then getFromScope(). I believe
> this suggested solution will cause "this" inside an environment to just work
> for the most part.

Done. New patch is smaller than previous :-)

[Build Bot]

Comment on attachment 262435 [details]
Patch

Attachment 262435 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/246794

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 262441 [details]
Archive of layout-test-results from ews102 for mac-mavericks

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102  Port: mac-mavericks  Platform: Mac OS X 10.9.5

[Build Bot]

Comment on attachment 262435 [details]
Patch

Attachment 262435 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/246808

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 262442 [details]
Archive of layout-test-results from ews106 for mac-mavericks-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106  Port: mac-mavericks-wk2  Platform: Mac OS X 10.9.5

[GSkachkov]

Created attachment 262540 [details]
Patch

Updated draft version of the patch. Version #4

[Saam Barati]

Comment on attachment 262540 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=262540&action=review

This patch is much better than before, but I think there are a few things that still need to be done to make it cleaner and correct.

> Source/JavaScriptCore/bytecode/CodeBlock.cpp:1663
> +    , m_needsActivation(unlinkedCodeBlock->hasActivationRegister() && (unlinkedCodeBlock->codeType() == FunctionCode || unlinkedCodeBlock->codeType() == GlobalCode || unlinkedCodeBlock->codeType() == EvalCode) )

Why is this needed?

> Source/JavaScriptCore/bytecode/CodeBlock.h:350
> +    void setNeedActivation(bool value)

this is unused.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:170
> +    if (programNode->usesArrowFunction())

Should this be "if (programNode->usesArrowFunction() || usesEval())"?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:485
> +        if (functionNode->usesThis() || codeBlock->usesEval() || functionNode->usesArrowFunction()) {

I think we need to emitResolveScoe then emitGetFromScope for every "this" node, right?
Just doing it once I think is not sufficient. Consider:
class C {
    constructor() {
         let f = (c) => c ? this : {};
         f(false);
         super();
         f(true);
    }
}

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:490
>      }

I think you should add a line of code here that calls "emitUpdateScopeIfNeeded()"
Currently, you emit code for "emitUpdateScopeIfNeeded()" on each arrow function that's emitted.
This is excessive. If you simply call "emitUpdateScopeIfNeeded()" here and anytime you call super(),
we should always have the latest "this" value.

Also, I think you probably need to call "initializeEmptyVarLexicalEnvironment()" somewhere
inside this function to be consistent with ProgramNode/EvalNode.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:540
> +        initializeEmptyVarLexicalEnvironment(vm);

(I have a note on this function below. I think it can be nicer).

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:541
> +    else

This shouldn't be in an else clause. It should happen regardless of the above condition.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:788
> +void BytecodeGenerator::initializeEmptyVarLexicalEnvironment(VM& vm)

I think we can do this in a better way. We can write this purely in terms of pushLexicalScopeInternal().
The reason is that pushLexicalScopeInternal does necessary bookkeeping for handling
scopes, etc (especially important within try/catch).

If you look at initializeDefaultParameterValuesAndSetupFunctionScopeStack() it interfaces with this function.
I think something like this would work:

```
        VariableEnvironment environment;
        auto addResult = environment.add(thisIdentifier);
        addResult.iterator->value.setIsCaptured();
        pushLexicalScopeInternal(environment, false, nullptr, TDZRequirement::(Whatever it doesn't matter), ScopeType::LetConstScope, ScopeRegisterType::Block);
```
Note that this works because the ::variable() function explicitly looks for the "this" identifier and
therefore we won't ever search the scope stack for "this".

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2937
> +void BytecodeGenerator::emitUpdateScopeIfNeed()

Lets call this "emitPutThisToScopeIfNeeded" or something along those lines.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2942
> +        emitPutToScope(scopeRegister(), thisVar, thisRegister(), DoNotThrowIfNotFoundAndReturnEmpty, NotInitialization);

I don't like the idea of adding new resolve modes like "DoNotThrowIfNotFoundAndReturnEmpty".
Why would we ever not find "this"?
We should always find it.
We should make this guarantee by making sure every function places "this" into the lexical environment if needed.

[GSkachkov]

Comment on attachment 262540 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=262540&action=review

Thanks for the review!
Now I'm running the tests in debug mode. 
After success I'll upload the patch. I hope that it will be happened today :-)

>> Source/JavaScriptCore/bytecode/CodeBlock.cpp:1663
>> +    , m_needsActivation(unlinkedCodeBlock->hasActivationRegister() && (unlinkedCodeBlock->codeType() == FunctionCode || unlinkedCodeBlock->codeType() == GlobalCode || unlinkedCodeBlock->codeType() == EvalCode) )
> 
> Why is this needed?

It allow to avoid  ASSERT error in method needsActivation for Eval and Program case. As I understand we create lexical scope for them so we need activate it. 
See assert ASSERT(m_lexicalEnvironmentRegister.isValid() == m_needsActivation);

>> Source/JavaScriptCore/bytecode/CodeBlock.h:350
>> +    void setNeedActivation(bool value)
> 
> this is unused.

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:170
>> +    if (programNode->usesArrowFunction())
> 
> Should this be "if (programNode->usesArrowFunction() || usesEval())"?

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:485
>> +        if (functionNode->usesThis() || codeBlock->usesEval() || functionNode->usesArrowFunction()) {
> 
> I think we need to emitResolveScoe then emitGetFromScope for every "this" node, right?
> Just doing it once I think is not sufficient. Consider:
> class C {
>     constructor() {
>          let f = (c) => c ? this : {};
>          f(false);
>          super();
>          f(true);
>     }
> }

Hmm, it seems that I don't understand clearly what does this methods. Your examples very close to scripts that I use to test TDZ in 'super()', see tests with name arrowfunction-tdz-1.js.
How I understand this code. Each time when arrow function is invoked, before run body of function it loads 'this' value to thisRegister. So if I this value is changed by parent function by 'super()', we get from scope of arrow function new 'this' value, because 'this' in lexical_scope will be updated by emitUpdateScopeIfNeed method that we call just after calling 'super()' see change in Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp line 730.

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:490
>>      }
> 
> I think you should add a line of code here that calls "emitUpdateScopeIfNeeded()"
> Currently, you emit code for "emitUpdateScopeIfNeeded()" on each arrow function that's emitted.
> This is excessive. If you simply call "emitUpdateScopeIfNeeded()" here and anytime you call super(),
> we should always have the latest "this" value.
> 
> Also, I think you probably need to call "initializeEmptyVarLexicalEnvironment()" somewhere
> inside this function to be consistent with ProgramNode/EvalNode.

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:541
>> +    else
> 
> This shouldn't be in an else clause. It should happen regardless of the above condition.

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:788
>> +void BytecodeGenerator::initializeEmptyVarLexicalEnvironment(VM& vm)
> 
> I think we can do this in a better way. We can write this purely in terms of pushLexicalScopeInternal().
> The reason is that pushLexicalScopeInternal does necessary bookkeeping for handling
> scopes, etc (especially important within try/catch).
> 
> If you look at initializeDefaultParameterValuesAndSetupFunctionScopeStack() it interfaces with this function.
> I think something like this would work:
> 
> ```
>         VariableEnvironment environment;
>         auto addResult = environment.add(thisIdentifier);
>         addResult.iterator->value.setIsCaptured();
>         pushLexicalScopeInternal(environment, false, nullptr, TDZRequirement::(Whatever it doesn't matter), ScopeType::LetConstScope, ScopeRegisterType::Block);
> ```
> Note that this works because the ::variable() function explicitly looks for the "this" identifier and
> therefore we won't ever search the scope stack for "this".

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2937
>> +void BytecodeGenerator::emitUpdateScopeIfNeed()
> 
> Lets call this "emitPutThisToScopeIfNeeded" or something along those lines.

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2942
>> +        emitPutToScope(scopeRegister(), thisVar, thisRegister(), DoNotThrowIfNotFoundAndReturnEmpty, NotInitialization);
> 
> I don't like the idea of adding new resolve modes like "DoNotThrowIfNotFoundAndReturnEmpty".
> Why would we ever not find "this"?
> We should always find it.
> We should make this guarantee by making sure every function places "this" into the lexical environment if needed.

In case if we put 'this' inside of the constructor before 'super()' without flag we will receive ASSERT error. If we will try to get 'this' inside of arrow function that invokes before 'super()'  we will receive undefined and miss the TDZ error.
So that why  I made changes in  JITOperation.cpp operationGetFromScope/operationPutToScope

[GSkachkov]

Created attachment 263614 [details]
Patch

Draft version, without style fixing and some of the tests

[Saam Barati]

Comment on attachment 263614 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=263614&action=review

Overall, I like this approach. There are some details that need fixing. I've commented below.

> Source/JavaScriptCore/bytecode/CodeBlock.cpp:1658
> +    , m_scopeForThisRegister(unlinkedCodeBlock->scopeForThisRegister())

not used.

> Source/JavaScriptCore/bytecode/CodeBlock.cpp:1660
> +    , m_needsActivation(unlinkedCodeBlock->hasActivationRegister() && (unlinkedCodeBlock->codeType() == FunctionCode || unlinkedCodeBlock->codeType() == GlobalCode || unlinkedCodeBlock->codeType() == EvalCode) )

Why is this change needed?

> Source/JavaScriptCore/bytecode/CodeBlock.h:349
> +    VirtualRegister scopeForThisRegister()

It doesn't look like this is used. And this also seems weird and unnecessary, we should be able to accomplish whatever this can without caching the scope.

> Source/JavaScriptCore/bytecode/UnlinkedCodeBlock.h:121
> +    bool isDerivedContext() const { return m_isDerivedContext;}
> +    bool isArrowFunctionContext() const { return m_isArrowFunctionContext;}

style: ";}" => "; }"

> Source/JavaScriptCore/bytecode/UnlinkedFunctionExecutable.h:163
> +    unsigned m_isDerivedContext: 1;

What exactly does m_isDerivedContext mean?
Does it strictly mean I'm inheriting "this/super/new.target/arguments" from my parent context?
If so, maybe a better name is m_isInheritedLexicalEnvironment.
If not, what does it mean?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:488
> +        if (functionNode->usesThis() || m_isDerivedContext) {

When is an arrow function ever not an "m_isDerivedContext"?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:492
> +                emitGetThisFromArrowFunctionLexicalEnvironment();

Is this needed here?
Doesn't each "this" AST node call this function? Maybe it's needed for other things that assume m_thisRegister contains the correct value?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:493
> +                emitGetNewTargeFromArrowFunctionLexicalEnvironment();

why does this depend on "usesThis()"? I think this should happen regardless.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1883
> +Variable BytecodeGenerator::variable(const Identifier& property, bool isLocal)

naming nit: "isLocal" => "isLocalThis"

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1950
> +Variable BytecodeGenerator::createThisVariable()

I would name this to: "createScopedThisVariable"

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1955
> +Variable BytecodeGenerator::createVariableFromStack(Identifier varIdentifier)

This seems very wrong to me. Why would this always be in the top-most scope on the stack? I don't think that's true.
We already know what lexicalEnvironmentRegister holds the scoped "this", we should use that to construct our
own "this" variable. I would remove this function entirely and do the logic in the function above.

Maybe one way to create the proper scoped "this" variable is to just implement your own walking
of the m_symbolTableStack. We know for sure that it must be in there, so we should just assert
that we always find it. That way we ensure any callers of this function only call it if the "this"
is indeed on the scope stack.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3919
> +void BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment()

nit: I think a better name for this is "emitResolveArrowFunctionContextLexicalEnvironment".
Also, I think this only ever has to happen once. It should always resolve to the same scope.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3920
> +{

It's probably good form to assert that we're an arrow function in this function.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:492
> +        void emitLoadArrowFunctionLexicalEnvironment();

I think you can make this private (if it's not already) and only have it be called from emitGetThisFromArrowFunctionLexicalEnvironment

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:683
> +        template<typename LookUpVarKindFunctor>
> +        bool instantiateLexicalVariables2(const VariableEnvironment&, SymbolTable*, ScopeRegisterType, LookUpVarKindFunctor);

debugging code?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:789
> +        void initializeEmptyVarLexicalEnvironmentIfNeeded(SymbolTable* = nullptr);

I think this needs a better name, something like:
"initializeLexicalEnvironmentContextForArrowFunctions"

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:831
> +        RegisterID* m_arrowFunctionlexicalEnvRegister { nullptr };

This is a very weird member variable. It means two different things depending on what context we're generating code in.
I think it'd be clearer to separate this out into two different member variables.
One member variable should represent the environment that this gets assigned to in "initializeEmptyVarLexicalEnvironmentIfNeeded()" (or whatever you rename it to).
The other member variable should represent the result of "emitLoadArrowFunctionEnvironment"

Even though these things are similar because they're the environment registers that hold "this"/"new.target"/etc,
they're not exactly equal because we decide to create one, and we resolve to the other. I think separating them
is cleaner. It only costs us an extra pointer in memory which is fine inside the BytecodeGenerator.

[GSkachkov]

Comment on attachment 263614 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=263614&action=review

Thanks for the review! I'll hope to land the patch tomorrow

>> Source/JavaScriptCore/bytecode/UnlinkedFunctionExecutable.h:163
>> +    unsigned m_isDerivedContext: 1;
> 
> What exactly does m_isDerivedContext mean?
> Does it strictly mean I'm inheriting "this/super/new.target/arguments" from my parent context?
> If so, maybe a better name is m_isInheritedLexicalEnvironment.
> If not, what does it mean?

It means: arrow function was created in constructor of class that has parent (constructorKind() == ConstructorKind::Derived). So in such arrow function we can invoke super and we need put 'this' to arrow function lexical scope after invoking 'super'  and etc.

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:492
>> +                emitGetThisFromArrowFunctionLexicalEnvironment();
> 
> Is this needed here?
> Doesn't each "this" AST node call this function? Maybe it's needed for other things that assume m_thisRegister contains the correct value?

We call this function in 'this' AST node only when we in constructor that contains arrow function, and there is possibility that 'this' is created by 'super()' in arrow function. In current place we load bound value to m_thisRegister only at start of arrow function if 'this' is used in body of current function.

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:493
>> +                emitGetNewTargeFromArrowFunctionLexicalEnvironment();
> 
> why does this depend on "usesThis()"? I think this should happen regardless.

I'll fix

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1955
>> +Variable BytecodeGenerator::createVariableFromStack(Identifier varIdentifier)
> 
> This seems very wrong to me. Why would this always be in the top-most scope on the stack? I don't think that's true.
> We already know what lexicalEnvironmentRegister holds the scoped "this", we should use that to construct our
> own "this" variable. I would remove this function entirely and do the logic in the function above.
> 
> Maybe one way to create the proper scoped "this" variable is to just implement your own walking
> of the m_symbolTableStack. We know for sure that it must be in there, so we should just assert
> that we always find it. That way we ensure any callers of this function only call it if the "this"
> is indeed on the scope stack.

I double checked and I see now that this function is unnecessary. It is covered by variable() function.

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3919
>> +void BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment()
> 
> nit: I think a better name for this is "emitResolveArrowFunctionContextLexicalEnvironment".
> Also, I think this only ever has to happen once. It should always resolve to the same scope.

OK. Will do, but can we avoid using 'Context' word? Name so long

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3920
>> +{
> 
> It's probably good form to assert that we're an arrow function in this function.

For now I'm calling this function in following cases
1) In arrow function
2) In 'eval' in case if 'eval' is called inside of arrow function
3) In constructor during access to 'this', because arrow function can put 'this' back.

So assert has to be ASSERT(m_codeBlock.isArrowFunction() || m_codeBlock.isArrowFunctionContext() || constructorKind() == ConstructorKind::Derived); is it OK?

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:683
>> +        bool instantiateLexicalVariables2(const VariableEnvironment&, SymbolTable*, ScopeRegisterType, LookUpVarKindFunctor);
> 
> debugging code?

removed

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:831
>> +        RegisterID* m_arrowFunctionlexicalEnvRegister { nullptr };
> 
> This is a very weird member variable. It means two different things depending on what context we're generating code in.
> I think it'd be clearer to separate this out into two different member variables.
> One member variable should represent the environment that this gets assigned to in "initializeEmptyVarLexicalEnvironmentIfNeeded()" (or whatever you rename it to).
> The other member variable should represent the result of "emitLoadArrowFunctionEnvironment"
> 
> Even though these things are similar because they're the environment registers that hold "this"/"new.target"/etc,
> they're not exactly equal because we decide to create one, and we resolve to the other. I think separating them
> is cleaner. It only costs us an extra pointer in memory which is fine inside the BytecodeGenerator.

OK. I'll separate cases.

[GSkachkov]

Created attachment 263939 [details]
Patch

Full version

[Build Bot]

Comment on attachment 263939 [details]
Patch

Attachment 263939 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/328479

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 263943 [details]
Archive of layout-test-results from ews100 for mac-mavericks

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-mavericks  Platform: Mac OS X 10.9.5

[Build Bot]

Comment on attachment 263939 [details]
Patch

Attachment 263939 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/328493

New failing tests:
fast/media/mq-any-hover-styling.html
fast/events/mutation-during-replace-child-2.html
accessibility/scroll-to-global-point-main-window.html
js/tostring-exception-in-property-access.html
fast/dom/HTMLProgressElement/progress-clone.html
fast/events/mutation-during-replace-child.html
accessibility/scroll-to-global-point-iframe-nested.html
fast/dom/html-link-element-activation-behavior-url-is-null.html
fast/css/link-media-attr.html
fast/dom/HTMLElement/translate.html
fast/dom/Window/dispatchEvent.html
accessibility/scroll-to-make-visible-nested.html
fast/dom/adopt-node-prevented.html
fast/media/mq-any-pointer-styling.html
fast/events/event-propagation-in-detached-tree.html
fast/media/mq-hover-styling.html
fast/dom/HTMLElement/spellcheck.html
accessibility/scroll-to-global-point-iframe.html
fast/media/mq-pointer-styling.html
accessibility/scroll-to-global-point-nested.html
fast/dom/HTMLMeterElement/meter-clone.html
fast/selectors/querySelector-pseudo-element-inside-functional-pseudo-class-any.html
fast/selectors/querySelector-pseudo-element.html

[Build Bot]

Created attachment 263944 [details]
Archive of layout-test-results from ews105 for mac-mavericks-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105  Port: mac-mavericks-wk2  Platform: Mac OS X 10.9.5

[Build Bot]

Comment on attachment 263939 [details]
Patch

Attachment 263939 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/328490

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 263945 [details]
Archive of layout-test-results from ews112 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Created attachment 264008 [details]
Patch

Added small fixes

[GSkachkov]

Created attachment 264012 [details]
Patch

Fix build

[Build Bot]

Comment on attachment 264012 [details]
Patch

Attachment 264012 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/336539

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 264017 [details]
Archive of layout-test-results from ews103 for mac-mavericks

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-mavericks  Platform: Mac OS X 10.9.5

[Build Bot]

Comment on attachment 264012 [details]
Patch

Attachment 264012 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/336543

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 264018 [details]
Archive of layout-test-results from ews113 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews113  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 264012 [details]
Patch

Attachment 264012 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/336552

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 264019 [details]
Archive of layout-test-results from ews107 for mac-mavericks-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-mavericks-wk2  Platform: Mac OS X 10.9.5

[GSkachkov]

Created attachment 264022 [details]
Patch

Fix tests

[Build Bot]

Comment on attachment 264022 [details]
Patch

Attachment 264022 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/337027

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 264023 [details]
Archive of layout-test-results from ews102 for mac-mavericks

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102  Port: mac-mavericks  Platform: Mac OS X 10.9.5

[Build Bot]

Comment on attachment 264022 [details]
Patch

Attachment 264022 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/337026

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 264024 [details]
Archive of layout-test-results from ews113 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews113  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 264022 [details]
Patch

Attachment 264022 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/337047

New failing tests:
fast/media/mq-any-hover-styling.html
fast/events/mutation-during-replace-child-2.html
accessibility/scroll-to-global-point-main-window.html
js/tostring-exception-in-property-access.html
fast/dom/HTMLProgressElement/progress-clone.html
fast/events/mutation-during-replace-child.html
accessibility/scroll-to-global-point-iframe-nested.html
fast/dom/html-link-element-activation-behavior-url-is-null.html
fast/css/link-media-attr.html
fast/dom/HTMLElement/translate.html
fast/dom/Window/dispatchEvent.html
accessibility/scroll-to-make-visible-nested.html
fast/dom/adopt-node-prevented.html
fast/media/mq-any-pointer-styling.html
fast/events/event-propagation-in-detached-tree.html
fast/media/mq-hover-styling.html
fast/dom/HTMLElement/spellcheck.html
accessibility/scroll-to-global-point-iframe.html
fast/media/mq-pointer-styling.html
accessibility/scroll-to-global-point-nested.html
fast/dom/HTMLMeterElement/meter-clone.html
fast/selectors/querySelector-pseudo-element-inside-functional-pseudo-class-any.html
fast/selectors/querySelector-pseudo-element.html

[Build Bot]

Created attachment 264025 [details]
Archive of layout-test-results from ews107 for mac-mavericks-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-mavericks-wk2  Platform: Mac OS X 10.9.5

[Saam Barati]

Comment on attachment 264022 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=264022&action=review

this is looking better and better. Some comments:

> Source/JavaScriptCore/bytecode/UnlinkedFunctionExecutable.h:163
> +    unsigned m_isDerivedConstructorContext: 1;

style: "m_isDerivedConstructorContext:" => "m_isDerivedConstructorContext :"

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:807
> +void BytecodeGenerator::initializeEmptyVarLexicalEnvironmentIfNeeded(SymbolTable* systemTable)

"systemTable" => "symbolTable"
I also don't like the name "initializeEmptyVarLexicalEnvironmentIfNeeded". It doesn't really mean what you're doing here.
I think a better name would be something along the lines of: "initializeArrowFunctionContextScopeIfNeeded".

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:819
> +            systemTable->set(propertyNames().thisIdentifier.impl(), SymbolTableEntry(VarOffset(offset)));

It's worth asserting here that "this" identifier is not in the symbol table already.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:821
> +            if (m_codeType == FunctionCode) {

Aren't there more specific situations where we need this? Like if we're in a derived constructor context?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:849
> +    m_arrowFunctionVarLexicalEnvRegister = emitMove(newRegister(), m_scopeRegister);

I think you want "newBlockScopeVariable" instead of "newRegister"

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2981
> +void BytecodeGenerator::emitUpdateScopeIfNeeded()

I think a better name for this would be something like:
"emitUpdateArrowFunctionContextScope".
This names seems to general. It would be good to pin it down to being arrowfunction-related.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2996
> +void BytecodeGenerator::emitPutThisToScope()

Again, I would signify in the name that this is related to arrow functions.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3897
> +void BytecodeGenerator::emitGetNewTargeFromArrowFunctionLexicalEnvironment()

typo: "emitGetNewTarge..." => "emitGetNewTarget..."

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:827
> +        RegisterID* m_arrowFunctionVarLexicalEnvRegister { nullptr };

nit: I would call this something like: "m_arrowFunctionContextLexicalEnvironmentRegister".
I think "var" is the wrong word here.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:828
> +        RegisterID* m_arrowFunctionResolvedLexicalEnvRegister { nullptr };

style: I would spell out "Environment" in this name, even though it's verbose.

> Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp:699
> +// We need try to load 'this' before call eval, because it can created by 'super' in some of the arrow function

style: Indent this.
Also, I'm a bit confused about this. Do we get the current function's "this" when making a function call?

> Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp:738
> +                && (generator.usesArrowFunction() || generator.usesEval())))

style: I'd move this to the above line.
WebKit style says that this should be 4 spaces from the indentation of the "if", which would look bad here. I would just move it one line up.

[GSkachkov]

Comment on attachment 264022 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=264022&action=review

>> Source/JavaScriptCore/bytecode/UnlinkedFunctionExecutable.h:163
>> +    unsigned m_isDerivedConstructorContext: 1;
> 
> style: "m_isDerivedConstructorContext:" => "m_isDerivedConstructorContext :"

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:807
>> +void BytecodeGenerator::initializeEmptyVarLexicalEnvironmentIfNeeded(SymbolTable* systemTable)
> 
> "systemTable" => "symbolTable"
> I also don't like the name "initializeEmptyVarLexicalEnvironmentIfNeeded". It doesn't really mean what you're doing here.
> I think a better name would be something along the lines of: "initializeArrowFunctionContextScopeIfNeeded".

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:821
>> +            if (m_codeType == FunctionCode) {
> 
> Aren't there more specific situations where we need this? Like if we're in a derived constructor context?

I've decided to include into this patch the implementation of lexically binding of new.target for all cases, because it is required small changes in comparison to patch without it( current condition + condition to load new.target into function context + tests)  
new.target is always exist for function and lexically bound to the arrow function

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:849
>> +    m_arrowFunctionVarLexicalEnvRegister = emitMove(newRegister(), m_scopeRegister);
> 
> I think you want "newBlockScopeVariable" instead of "newRegister"

fixed

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2981
>> +void BytecodeGenerator::emitUpdateScopeIfNeeded()
> 
> I think a better name for this would be something like:
> "emitUpdateArrowFunctionContextScope".
> This names seems to general. It would be good to pin it down to being arrowfunction-related.

OK. I think  emitUpdateVariablesInArrowFunctionContextScope will be better, because we change values of the variables in arrow function scope?

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2996
>> +void BytecodeGenerator::emitPutThisToScope()
> 
> Again, I would signify in the name that this is related to arrow functions.

Renamed to emitPutThisToArrowFunctionContextScope

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3897
>> +void BytecodeGenerator::emitGetNewTargeFromArrowFunctionLexicalEnvironment()
> 
> typo: "emitGetNewTarge..." => "emitGetNewTarget..."

fixed

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:827
>> +        RegisterID* m_arrowFunctionVarLexicalEnvRegister { nullptr };
> 
> nit: I would call this something like: "m_arrowFunctionContextLexicalEnvironmentRegister".
> I think "var" is the wrong word here.

renamed

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:828
>> +        RegisterID* m_arrowFunctionResolvedLexicalEnvRegister { nullptr };
> 
> style: I would spell out "Environment" in this name, even though it's verbose.

Done

>> Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp:699
>> +// We need try to load 'this' before call eval, because it can created by 'super' in some of the arrow function
> 
> style: Indent this.
> Also, I'm a bit confused about this. Do we get the current function's "this" when making a function call?

I think it has to rewritten -> // We need try to load 'this' before call eval in constructor, because 'this' can created by 'super' in some of the arrow function
It is necessary to cover following case :
     var A = class A {
       constructor () { this.id = 'A'; }
     }
    
     var B = class B extend A {
        constructor () {
           var arrow = () => super();
           arrow();
           eval("this.id = 'B'");
        }
     }
    new B();

>> Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp:738
>> +                && (generator.usesArrowFunction() || generator.usesEval())))
> 
> style: I'd move this to the above line.
> WebKit style says that this should be 4 spaces from the indentation of the "if", which would look bad here. I would just move it one line up.

I've changed, now it has two variable and condition in one line:
    bool isConstructorKindDerived = generator.constructorKind() == ConstructorKind::Derived;
    bool usesArrowFunctionOrEval  = generator.usesArrowFunction() || generator.usesEval();
    if (generator.isDerivedConstructorContext() || (isConstructorKindDerived && usesArrowFunctionOrEval))

[GSkachkov]

Created attachment 264056 [details]
Patch

Fixed comments

[Build Bot]

Comment on attachment 264056 [details]
Patch

Attachment 264056 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/341001

New failing tests:
inspector/heap/gc.html

[Build Bot]

Created attachment 264069 [details]
Archive of layout-test-results from ews114 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Created attachment 264078 [details]
Patch

Tiny fixes

[Saam Barati]

Comment on attachment 264078 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=264078&action=review

Patch looks mostly good. Just have some comments regarding some tricky problems with the implementation for some edge cases.

> Source/JavaScriptCore/ChangeLog:9
> +        'this' is stored inside of the lexical environment of the function. To store and load are used 

nit: "are used" => "we use"

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:849
> +    m_arrowFunctionContextLexicalEnvironmentRegister = emitMove(newBlockScopeVariable(), m_scopeRegister);

I was wrong about advising you on this earlier.
I forgot that pushLexicalScopeInternal already creates a variable for us.
Because you have captured variables, we will create a block scoped variable for
the scope. 
So all you have to do is this:
m_arrowFunctionContextLexcialEnvironmentRegister = m_symbolTableStack.last().m_scope.
Feel free to add asserts around the pushLexicalScopeInternal call to make sure it actually adds exactly one item to the symbol table stack.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2989
> +        if (m_codeType == FunctionCode)  {

I realized we don't need this.
We should only need to do this once per function.
If you look how new_target is materialized now, it happens
before we create a "this". So I think it'd be wrong to update
this value over time. It should just happen once at the very beginning of the program.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3881
> +{

There are a few interesting things to consider here that seem like they are problems.
1) consider the problem of using the literal string "__proto__":
class A extends B {
    let arr1 = () => {
        let __proto__ = "blah";
        let arr2 = () => super();
        arr2();
    }
}
This strategy worked with "this" because no variable can be named "this". But variables can be named "__proto__"

2) what happens when __proto__ is overwritten (I'm not really sure if this is a problem or what's supposed to happen with respect to the specification, but it's probably worth looking into).
class A extends B {
    let arr1 = () => { ... }
    A.__proto__ = null;
    arr1();
}
I wonder what happens just in normal classes with this.

3) If we're storing values in m_calleeRegister, maybe we're doing this wrong. I think this might break stack traces because it will look like an arrow functions parent frame is displayed twice on a stack trace if an error is thrown.
It's worth considering this problem.

For all problems above, if they really are problems, we should have tests for them, too.

[GSkachkov]

Created attachment 264596 [details]
Patch

Fix comments

[GSkachkov]

Created attachment 264598 [details]
Patch

Tiny fixes

[GSkachkov]

Comment on attachment 264078 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=264078&action=review

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:849
>> +    m_arrowFunctionContextLexicalEnvironmentRegister = emitMove(newBlockScopeVariable(), m_scopeRegister);
> 
> I was wrong about advising you on this earlier.
> I forgot that pushLexicalScopeInternal already creates a variable for us.
> Because you have captured variables, we will create a block scoped variable for
> the scope. 
> So all you have to do is this:
> m_arrowFunctionContextLexcialEnvironmentRegister = m_symbolTableStack.last().m_scope.
> Feel free to add asserts around the pushLexicalScopeInternal call to make sure it actually adds exactly one item to the symbol table stack.

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2989
>> +        if (m_codeType == FunctionCode)  {
> 
> I realized we don't need this.
> We should only need to do this once per function.
> If you look how new_target is materialized now, it happens
> before we create a "this". So I think it'd be wrong to update
> this value over time. It should just happen once at the very beginning of the program.

I've split this into two methods

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3881
>> +{
> 
> There are a few interesting things to consider here that seem like they are problems.
> 1) consider the problem of using the literal string "__proto__":
> class A extends B {
>     let arr1 = () => {
>         let __proto__ = "blah";
>         let arr2 = () => super();
>         arr2();
>     }
> }
> This strategy worked with "this" because no variable can be named "this". But variables can be named "__proto__"
> 
> 2) what happens when __proto__ is overwritten (I'm not really sure if this is a problem or what's supposed to happen with respect to the specification, but it's probably worth looking into).
> class A extends B {
>     let arr1 = () => { ... }
>     A.__proto__ = null;
>     arr1();
> }
> I wonder what happens just in normal classes with this.
> 
> 3) If we're storing values in m_calleeRegister, maybe we're doing this wrong. I think this might break stack traces because it will look like an arrow functions parent frame is displayed twice on a stack trace if an error is thrown.
> It's worth considering this problem.
> 
> For all problems above, if they really are problems, we should have tests for them, too.

Added additional tests to arrowfunction-lexical-bind-supercall-2.js module for cases that you mention.
Stack trace looks correct
for instance for following code:
var errorStack;

var ParentClass = class ParentClass {
  constructor() {
    try {
      this.idValue = 'testValue';
      throw new Error('Error');
    } catch (e) {
      errorStack  = e.stack;
    }
  }
};

var ChildClass = class ChildClass extends ParentClass {
  constructor () {
    var arrowInChildConstructor = () => {
      var nestedArrow = () => {
        super();
      }
      nestedArrow();
    };
    arrowInChildConstructor();
  }
};


Stack trace is:
ParentClass@test_class_14.js:9:22
nestedArrow@test_class_14.js:20:14
arrowInChildConstructor@test_class_14.js:23:18
ChildClass@test_class_14.js:26:28
global code@test_class_14.js:31:25

[Build Bot]

Comment on attachment 264598 [details]
Patch

Attachment 264598 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/372949

New failing tests:
inspector/heap/garbageCollected.html

[Build Bot]

Created attachment 264606 [details]
Archive of layout-test-results from ews101 for mac-mavericks

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-mavericks  Platform: Mac OS X 10.9.5

[Build Bot]

Comment on attachment 264598 [details]
Patch

Attachment 264598 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/372957

New failing tests:
inspector/protocol/backend-dispatcher-malformed-message-errors.html

[Build Bot]

Created attachment 264607 [details]
Archive of layout-test-results from ews107 for mac-mavericks-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-mavericks-wk2  Platform: Mac OS X 10.9.5

[GSkachkov]

Created attachment 264612 [details]
Patch

Updated test

[Build Bot]

Comment on attachment 264612 [details]
Patch

Attachment 264612 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/373340

New failing tests:
inspector/heap/garbageCollected.html

[Build Bot]

Created attachment 264622 [details]
Archive of layout-test-results from ews112 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Created attachment 264685 [details]
Patch

Updated test

[Saam Barati]

Comment on attachment 264685 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=264685&action=review

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:831
> +        auto addTarget = environment.add(propertyNames().target);

This should be the private name as well, right?

It might be good to have tests that this code
would fail using the public identifier.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:837
> +        auto protoObject = environment.add(propertyNames().underscoreProtoScopeLocalPrivateName);

Instead of "underscoreProtoScopeLocalPrivateName" we can maybe give this a more descriptive name.
This is just the current class we're in super class, right?
like:
class A extends B { constructor() { let arr = () => { ... }  }
this will be "B", right?
Maybe we can just name this using some form of "super class", then?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3843
> +        // 'this' can be uninitialized in constructor of derived class so we resolve with underscoreProtoScope variable that stored in arrow function lexical environment in of such cases

Even though this is uninitialized, don't we always store it in the symbol table?
So if we read from the scope, we might get jsTDZValue(), but since we're just
resolving the scope, shouldn't "this" always resolve to the proper scope?

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3892
> +    emitPutToScope(isDerivedConstructorContext() ? emitResolveScope(nullptr, thisVar) : m_arrowFunctionContextLexicalEnvironmentRegister, thisVar, thisRegister(), DoNotThrowIfNotFound, NotInitialization);

Why can't we always use "m_arrowFunctionContextLexicalEnvironmentRegister" here?
We could always call "emitLoadArrowFunctionContextScope()", too, just to make sure we've resolved to it.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:296
> +        Variable variable(const Identifier&, bool = true);

I think an "enum class" would be better than bool here, that way all call sites of variable() are more descriptive.
maybe: "enum class ThisResolutionType { Local, Scoped };"
or something like that.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:828
> +        RefPtr<RegisterID> m_arrowFunctionResolvedLexicalEnvRegister { nullptr };

I would make "env" to "environment" here, or maybe rename to something shorter like:
"m_resolvedArrowFunctionScopeContext"

> Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp:-1024
> -                exactRead = ArrowFunctionBoundThisPLoc;

I think we should remove the definition and other code that looks at "ArrowFunctionBoundThisPLoc" since it's no longer used.

[GSkachkov]

Created attachment 264949 [details]
Patch

Fixed comments

[Build Bot]

Comment on attachment 264949 [details]
Patch

Attachment 264949 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/393385

New failing tests:
inspector/heap/gc.html

[Build Bot]

Created attachment 264970 [details]
Archive of layout-test-results from ews115 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Created attachment 264998 [details]
Patch

Reload to fix tests

[GSkachkov]

Created attachment 264999 [details]
Patch

After rebase

[Build Bot]

Comment on attachment 264999 [details]
Patch

Attachment 264999 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/395832

New failing tests:
http/tests/inspector/dom/disconnect-dom-tree-after-main-frame-navigation.html
inspector/heap/gc.html

[Build Bot]

Created attachment 265000 [details]
Archive of layout-test-results from ews116 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews116  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Comment on attachment 264685 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=264685&action=review

I've uploaded  new patch.  Something wrong with mac-debug tests . They are always fails  with different errors.

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:831
>> +        auto addTarget = environment.add(propertyNames().target);
> 
> This should be the private name as well, right?
> 
> It might be good to have tests that this code
> would fail using the public identifier.

I've added tests to check if variable visible in scope

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:837
>> +        auto protoObject = environment.add(propertyNames().underscoreProtoScopeLocalPrivateName);
> 
> Instead of "underscoreProtoScopeLocalPrivateName" we can maybe give this a more descriptive name.
> This is just the current class we're in super class, right?
> like:
> class A extends B { constructor() { let arr = () => { ... }  }
> this will be "B", right?
> Maybe we can just name this using some form of "super class", then?

Renamed to superClassScope

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3843
>> +        // 'this' can be uninitialized in constructor of derived class so we resolve with underscoreProtoScope variable that stored in arrow function lexical environment in of such cases
> 
> Even though this is uninitialized, don't we always store it in the symbol table?
> So if we read from the scope, we might get jsTDZValue(), but since we're just
> resolving the scope, shouldn't "this" always resolve to the proper scope?

Fixed

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3892
>> +    emitPutToScope(isDerivedConstructorContext() ? emitResolveScope(nullptr, thisVar) : m_arrowFunctionContextLexicalEnvironmentRegister, thisVar, thisRegister(), DoNotThrowIfNotFound, NotInitialization);
> 
> Why can't we always use "m_arrowFunctionContextLexicalEnvironmentRegister" here?
> We could always call "emitLoadArrowFunctionContextScope()", too, just to make sure we've resolved to it.

Done.

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:296
>> +        Variable variable(const Identifier&, bool = true);
> 
> I think an "enum class" would be better than bool here, that way all call sites of variable() are more descriptive.
> maybe: "enum class ThisResolutionType { Local, Scoped };"
> or something like that.

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:828
>> +        RefPtr<RegisterID> m_arrowFunctionResolvedLexicalEnvRegister { nullptr };
> 
> I would make "env" to "environment" here, or maybe rename to something shorter like:
> "m_resolvedArrowFunctionScopeContext"

Done

>> Source/JavaScriptCore/dfg/DFGObjectAllocationSinkingPhase.cpp:-1024
>> -                exactRead = ArrowFunctionBoundThisPLoc;
> 
> I think we should remove the definition and other code that looks at "ArrowFunctionBoundThisPLoc" since it's no longer used.

Removed

[GSkachkov]

Created attachment 265001 [details]
Patch

Rerun tests

[Saam Barati]

Comment on attachment 265001 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=265001&action=review

This patch is just about done. It's in really good shape. I just have a few final comments and then I think it's ready to land.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:833
> +    addResult.iterator->value.setIsConst();

Why is "this" modeled as a "const" variable?
I think it's better to just model them as normal variables because
we write to them more than once. Modeling them as
"const" will probably make the put_to_scope code fail when
it goes down the slow path. Unless we always make sure the put_to_scope
passes in the Initialize flag.

It's worth having tests to ensure the code works going
down the slow path. One way to write such a test is to
make the eval var injection watchpoint fire. I think something like this should make
the "this"/"new.target" go down the slow path (you should verify):
```
class C {
    constructor() {
        eval("var x = 20");
        super();
        let f = () => this;
    }
}
```

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3863
> +

nit: only one newline is needed.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3876
> +    emitPutToScope(m_arrowFunctionContextLexicalEnvironmentRegister, newTargetVar, newTarget(), DoNotThrowIfNotFound, NotInitialization);

This should be "Initialization". As I commented above, I think this code would fail if it went down the slow path. We should ensure it works going down the slow path of put_to_scope.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3885
> +        emitPutToScope(m_arrowFunctionContextLexicalEnvironmentRegister, protoScope, &m_calleeRegister, DoNotThrowIfNotFound, NotInitialization);

Ditto: should be "Initialization".
Also, I was totally wrong about naming this "super...", this is really the derived constructor that we're storing in the environemnt
and then later loading __proto__ on. We should name it like "derivedConstructorPrivateName" or "derivedClassPrivateName". Sorry about that.
I had thought we were eagerly storing the __proto__ of the derived constructor.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3894
> +    emitPutToScope(isDerivedConstructorContext() ? emitResolveScope(nullptr, thisVar) : m_arrowFunctionContextLexicalEnvironmentRegister, thisVar, thisRegister(), DoNotThrowIfNotFound, NotInitialization);

I think it's arguable whether or not this should be "Initialization" or "NotInitialization". I'd say it should be "Initialization" even though it may execute more than once.
Either way, I think the "this" variable probably shouldn't be marked as being like "const".

Also, we don't want to have more than one op_resolve_scope here because it will always resolve to the same thing. I'm not sure if this code
will run more than once unless we call "super()" more than once in a constructor. This seems really unlikely in real code (but I think it's legal in ES6 to do so),
so it's cleaner to ensure we never emit op_resolve_scope unnecessarily by doing something like this:

if (isDerivedConstructorContext())
    emitLoadArrowFunctionLexicalEnvironment()
emitPutToScope(isDerivedConstructorContext() ? m_resolvedArrowFunctionScopeContextRegister.get() : m_arrowFunctionContextLexicalEnvironmentRegister, thisVar, thisRegister(), DoNotThrowIfNotFound, Initialization);

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:830
> +        RefPtr<RegisterID> m_resolvedArrowFunctionScopeContextRegister { nullptr };

you don't need the nullptr initializer here, RefPtrs are by default initialized to null.

> Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp:3003
> +        bool usesArrowOrEval = generator.usesArrowFunction() || generator.usesEval();

There are a lot of places where you do usesArrow() || usesEval(), I wonder if it's worth giving this
condition a more descriptive name in the various bytecodegenerator constructors.
Maybe like "m_needsToUpdateArrowFunctionContext(generator.usesArrowFunction() || generator.usesEval())"
Just a thought, I'm also okay with having this condition tested at all the interesting places.

> Source/JavaScriptCore/runtime/Executable.h:348
> +    bool isArrowFunctionContext() const { return m_isArrowFunctionContext; }

Could we get rid of these properties (not these methods) and just ask the unlinked code block for this data or get at it through CodeFeatures?

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-newtarget.js:1
> +var testCase = function (actual, expected, message) {

style: Let's make this file 4-space indented throughout

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-newtarget.js:13
> +for (var i=0; i<10000; i++) {

I think we can get away w/ 1000 iterations for all the loops in this test.
10000 seems overkill.

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-newtarget.js:27
> +        passed = new.target === B;

Shouldn't this be '&=' and the below just be "=" since below "passed &= new.target === B" is executed first?

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-newtarget.js:50
> +      passed &= new.target === B;

Why would this be "B"?

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-newtarget.js:75
> +

I take my previous comment back, I don't think we really need a test for this, it's just confusing.

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-1.js:1
> +var testCase = function (actual, expected, message) {

style: You should make all your test files have a consistent 4-space indent.

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-1.js:16
> +  constructor (inArrowFuction, inConstructor, repeatInArrowFunction) {

"repeatInArrowFunction" is unused, maybe remove it or were you planning on calling super() twice?

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-1.js:35
> +for (var i=0; i < 10000; i++) {

I think 1000 iterations is also good for tests in this file.

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-2.js:17
> +    var arrow = () => () => () => {

👍

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-2.js:34
> +for (var i=0; i < 10000; i++) {

1000 iterations is probably good for this file too.

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-2.js:39
> +var testException = function (value1, value2, value3, index) {

value3 is unused.
I would make this function take only the index parameter
because value1 and value2 are always false. It's easier
to just pass in "false" yourself

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-2.js:95
> +        E.__proto__ = function () {};

Might be worth having a test that sets __proto__ to "null" and make sure that we throw an error.

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-3.js:31
> +for (var i=0; i < 10000; i++) {

I think all your tests can just be 1000 iterations.

> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-3.js:35
> +// Fixme: Failed test with 'Segmentation fault: 11' error in release mode in 6 cases from 14. List of failed case:

Is this fixed?

[Saam Barati]

I renamed the bug to better indicate what the patch is doing.

How is performance on this bug? Can you run the perf tests
just to make sure we haven't regressed on things non-arrow function related.
We may have regressed slightly on some arrow-function tests, but that's expected. Also, this will get better once you implement some basic static analysis for "this" usage so we don't store "this" in the environment unless we really need to.

[GSkachkov]

(In reply to comment #73)
> I renamed the bug to better indicate what the patch is doing.
> 
> How is performance on this bug? Can you run the perf tests
> just to make sure we haven't regressed on things non-arrow function related.
> We may have regressed slightly on some arrow-function tests, but that's
> expected. Also, this will get better once you implement some basic static
> analysis for "this" usage so we don't store "this" in the environment unless
> we really need to.

Thanks for the review, hope I soon land patch with fixes. I'll provide the perf test result with patch

[GSkachkov]

Created attachment 265179 [details]
Test performance result

[GSkachkov]

(In reply to comment #73)
> I renamed the bug to better indicate what the patch is doing.
> 
> How is performance on this bug? Can you run the perf tests
> just to make sure we haven't regressed on things non-arrow function related.
> We may have regressed slightly on some arrow-function tests, but that's
> expected. Also, this will get better once you implement some basic static
> analysis for "this" usage so we don't store "this" in the environment unless
> we really need to.

See result by link https://bugs.webkit.org/attachment.cgi?id=265179, Results are neutral except following tests:
arrowfunction-call                                95.9133+-5.5082     !    338.3422+-14.9020       ! definitely 3.5276x slower

and small performance degradation:
 function-with-eval                               708.1514+-8.0792     !    748.3060+-10.7312       ! definitely 1.0567x slower
is-object-or-null-tricky-internal-function   
                                                     59.8600+-1.4660     !     74.9355+-10.1182       ! definitely 1.2518x slower
setter                                            50.4615+-2.1227     !     64.9183+-12.1934       ! definitely 1.2865x slower

[Saam Barati]

(In reply to comment #76)
> (In reply to comment #73)
> > I renamed the bug to better indicate what the patch is doing.
> > 
> > How is performance on this bug? Can you run the perf tests
> > just to make sure we haven't regressed on things non-arrow function related.
> > We may have regressed slightly on some arrow-function tests, but that's
> > expected. Also, this will get better once you implement some basic static
> > analysis for "this" usage so we don't store "this" in the environment unless
> > we really need to.
> 
> See result by link https://bugs.webkit.org/attachment.cgi?id=265179, Results
> are neutral except following tests:
> arrowfunction-call                                95.9133+-5.5082     !   
> 338.3422+-14.9020       ! definitely 3.5276x slower
> 
> and small performance degradation:
>  function-with-eval                               708.1514+-8.0792     !   
> 748.3060+-10.7312       ! definitely 1.0567x slower
> is-object-or-null-tricky-internal-function   
>                                                      59.8600+-1.4660     !  
> 74.9355+-10.1182       ! definitely 1.2518x slower
> setter                                            50.4615+-2.1227     !    
> 64.9183+-12.1934       ! definitely 1.2865x slower

These are expected.
Eval is slower b/c we must be pessimistic and assume that it could have an arrow function.
The arrowfunction-call is a tiny micro-benchmark. It will get back to normal speed once you implement the patch that statically analyzes an arrow function to see if it really needs the lexical environment created for it.

[Saam Barati]

What happens when we call super once we've exited the constructor function?
Is there anything in the spec on this? Does is mutate "this"?

Like:
```
class C extends B {
    constructor() {
        this.weird = () => super();
        super();
    }
    foo() { 
        this.weird();
    }
}

(new C).foo();
```

[GSkachkov]

(In reply to comment #78)
> What happens when we call super once we've exited the constructor function?
> Is there anything in the spec on this? Does is mutate "this"?
> 
> Like:
> ```
> class C extends B {
>     constructor() {
>         this.weird = () => super();
>         super();
>     }
>     foo() { 
>         this.weird();
>     }
> }
> 
> (new C).foo();
> ```

I've not checked this case, but I'm sure that we can't run super() twice in constructor, second call should lead to RuntimeException. See tred on es6-discuss https://esdiscuss.org/topic/duplicate-super-call-behaviour. 
But this behavior is not related to the arrow function.

[Saam Barati]

(In reply to comment #79)
> (In reply to comment #78)
> > What happens when we call super once we've exited the constructor function?
> > Is there anything in the spec on this? Does is mutate "this"?
> > 
> > Like:
> > ```
> > class C extends B {
> >     constructor() {
> >         this.weird = () => super();
> >         super();
> >     }
> >     foo() { 
> >         this.weird();
> >     }
> > }
> > 
> > (new C).foo();
> > ```
> 
> I've not checked this case, but I'm sure that we can't run super() twice in
> constructor, second call should lead to RuntimeException. See tred on
> es6-discuss https://esdiscuss.org/topic/duplicate-super-call-behaviour. 
> But this behavior is not related to the arrow function.
Interesting. We currently don't throw on a second call to super().
That's bad, we should file a bug.

[Saam Barati]

(In reply to comment #80)
> (In reply to comment #79)
> > (In reply to comment #78)
> > > What happens when we call super once we've exited the constructor function?
> > > Is there anything in the spec on this? Does is mutate "this"?
> > > 
> > > Like:
> > > ```
> > > class C extends B {
> > >     constructor() {
> > >         this.weird = () => super();
> > >         super();
> > >     }
> > >     foo() { 
> > >         this.weird();
> > >     }
> > > }
> > > 
> > > (new C).foo();
> > > ```
> > 
> > I've not checked this case, but I'm sure that we can't run super() twice in
> > constructor, second call should lead to RuntimeException. See tred on
> > es6-discuss https://esdiscuss.org/topic/duplicate-super-call-behaviour. 
> > But this behavior is not related to the arrow function.
> Interesting. We currently don't throw on a second call to super().
> That's bad, we should file a bug.
I created this bug for this problem:
https://bugs.webkit.org/show_bug.cgi?id=151113

[GSkachkov]

Created attachment 265230 [details]
Patch

New patch

[GSkachkov]

Created attachment 265287 [details]
Patch

Fix all comments

[GSkachkov]

Created attachment 265289 [details]
Patch

Fix build

[GSkachkov]

Created attachment 265294 [details]
Patch

Fix build

[Build Bot]

Comment on attachment 265294 [details]
Patch

Attachment 265294 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/415481

New failing tests:
inspector/console/messagesCleared.html

[Build Bot]

Created attachment 265303 [details]
Archive of layout-test-results from ews100 for mac-mavericks

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-mavericks  Platform: Mac OS X 10.9.5

[Build Bot]

Comment on attachment 265294 [details]
Patch

Attachment 265294 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/415487

New failing tests:
inspector/heap/garbageCollected.html

[Build Bot]

Created attachment 265305 [details]
Archive of layout-test-results from ews116 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews116  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Comment on attachment 265001 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=265001&action=review

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:833
>> +    addResult.iterator->value.setIsConst();
> 
> Why is "this" modeled as a "const" variable?
> I think it's better to just model them as normal variables because
> we write to them more than once. Modeling them as
> "const" will probably make the put_to_scope code fail when
> it goes down the slow path. Unless we always make sure the put_to_scope
> passes in the Initialize flag.
> 
> It's worth having tests to ensure the code works going
> down the slow path. One way to write such a test is to
> make the eval var injection watchpoint fire. I think something like this should make
> the "this"/"new.target" go down the slow path (you should verify):
> ```
> class C {
>     constructor() {
>         eval("var x = 20");
>         super();
>         let f = () => this;
>     }
> }
> ```

I've changed to 'let' variable type. I've added  one test case to cover going down the slow path.

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3863
>> +
> 
> nit: only one newline is needed.

Removed

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3876
>> +    emitPutToScope(m_arrowFunctionContextLexicalEnvironmentRegister, newTargetVar, newTarget(), DoNotThrowIfNotFound, NotInitialization);
> 
> This should be "Initialization". As I commented above, I think this code would fail if it went down the slow path. We should ensure it works going down the slow path of put_to_scope.

Done

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3885
>> +        emitPutToScope(m_arrowFunctionContextLexicalEnvironmentRegister, protoScope, &m_calleeRegister, DoNotThrowIfNotFound, NotInitialization);
> 
> Ditto: should be "Initialization".
> Also, I was totally wrong about naming this "super...", this is really the derived constructor that we're storing in the environemnt
> and then later loading __proto__ on. We should name it like "derivedConstructorPrivateName" or "derivedClassPrivateName". Sorry about that.
> I had thought we were eagerly storing the __proto__ of the derived constructor.

NP. I've changed name to derivedConstructorPrivateName

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3894
>> +    emitPutToScope(isDerivedConstructorContext() ? emitResolveScope(nullptr, thisVar) : m_arrowFunctionContextLexicalEnvironmentRegister, thisVar, thisRegister(), DoNotThrowIfNotFound, NotInitialization);
> 
> I think it's arguable whether or not this should be "Initialization" or "NotInitialization". I'd say it should be "Initialization" even though it may execute more than once.
> Either way, I think the "this" variable probably shouldn't be marked as being like "const".
> 
> Also, we don't want to have more than one op_resolve_scope here because it will always resolve to the same thing. I'm not sure if this code
> will run more than once unless we call "super()" more than once in a constructor. This seems really unlikely in real code (but I think it's legal in ES6 to do so),
> so it's cleaner to ensure we never emit op_resolve_scope unnecessarily by doing something like this:
> 
> if (isDerivedConstructorContext())
>     emitLoadArrowFunctionLexicalEnvironment()
> emitPutToScope(isDerivedConstructorContext() ? m_resolvedArrowFunctionScopeContextRegister.get() : m_arrowFunctionContextLexicalEnvironmentRegister, thisVar, thisRegister(), DoNotThrowIfNotFound, Initialization);

Changed const to 'let', and used your snipped.
I'm sure that we can't run super()  twice in constructor, second call should lead to RuntimeException. See tred on es6-discuss https://esdiscuss.org/topic/duplicate-super-call-behaviour. 
But this behavior is not related to the arrow function.

>> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h:830
>> +        RefPtr<RegisterID> m_resolvedArrowFunctionScopeContextRegister { nullptr };
> 
> you don't need the nullptr initializer here, RefPtrs are by default initialized to null.

Done

>> Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp:3003
>> +        bool usesArrowOrEval = generator.usesArrowFunction() || generator.usesEval();
> 
> There are a lot of places where you do usesArrow() || usesEval(), I wonder if it's worth giving this
> condition a more descriptive name in the various bytecodegenerator constructors.
> Maybe like "m_needsToUpdateArrowFunctionContext(generator.usesArrowFunction() || generator.usesEval())"
> Just a thought, I'm also okay with having this condition tested at all the interesting places.

I've created property needsToUpdateArrowFunctionContext in generator, and now it is used in several placed

>> Source/JavaScriptCore/runtime/Executable.h:348
>> +    bool isArrowFunctionContext() const { return m_isArrowFunctionContext; }
> 
> Could we get rid of these properties (not these methods) and just ask the unlinked code block for this data or get at it through CodeFeatures?

I've added CodeFeature. To force it works I made  small 'trick'. Please take a look if it look ok.

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-newtarget.js:1
>> +var testCase = function (actual, expected, message) {
> 
> style: Let's make this file 4-space indented throughout

Done

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-newtarget.js:13
>> +for (var i=0; i<10000; i++) {
> 
> I think we can get away w/ 1000 iterations for all the loops in this test.
> 10000 seems overkill.

Done

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-newtarget.js:27
>> +        passed = new.target === B;
> 
> Shouldn't this be '&=' and the below just be "=" since below "passed &= new.target === B" is executed first?

Ohh, my fault.

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-newtarget.js:50
>> +      passed &= new.target === B;
> 
> Why would this be "B"?

Removed this condition

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-1.js:1
>> +var testCase = function (actual, expected, message) {
> 
> style: You should make all your test files have a consistent 4-space indent.

Done

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-1.js:16
>> +  constructor (inArrowFuction, inConstructor, repeatInArrowFunction) {
> 
> "repeatInArrowFunction" is unused, maybe remove it or were you planning on calling super() twice?

I've removed. I thought about this, but I'm going to call super() twice in another bug.

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-1.js:35
>> +for (var i=0; i < 10000; i++) {
> 
> I think 1000 iterations is also good for tests in this file.

done

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-2.js:34
>> +for (var i=0; i < 10000; i++) {
> 
> 1000 iterations is probably good for this file too.

done

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-2.js:39
>> +var testException = function (value1, value2, value3, index) {
> 
> value3 is unused.
> I would make this function take only the index parameter
> because value1 and value2 are always false. It's easier
> to just pass in "false" yourself

Done

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-2.js:95
>> +        E.__proto__ = function () {};
> 
> Might be worth having a test that sets __proto__ to "null" and make sure that we throw an error.

Added new tests

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-3.js:31
>> +for (var i=0; i < 10000; i++) {
> 
> I think all your tests can just be 1000 iterations.

Done

>> Source/JavaScriptCore/tests/stress/arrowfunction-lexical-bind-supercall-3.js:35
>> +// Fixme: Failed test with 'Segmentation fault: 11' error in release mode in 6 cases from 14. List of failed case:
> 
> Is this fixed?

Now it works, I'll rollback soon to check this error again.

[GSkachkov]

Created attachment 265309 [details]
Patch

Rerun tests

[Build Bot]

Comment on attachment 265309 [details]
Patch

Attachment 265309 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/416026

New failing tests:
inspector/heap/gc.html
inspector/heap/garbageCollected.html

[Build Bot]

Created attachment 265316 [details]
Archive of layout-test-results from ews116 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews116  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Created attachment 265368 [details]
Patch

Rerun tests #2

[Build Bot]

Comment on attachment 265368 [details]
Patch

Attachment 265368 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/418109

New failing tests:
inspector/heap/garbageCollected.html

[Build Bot]

Created attachment 265370 [details]
Archive of layout-test-results from ews100 for mac-mavericks

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-mavericks  Platform: Mac OS X 10.9.5

[GSkachkov]

Created attachment 265373 [details]
Patch

Rerun tests #3

[Build Bot]

Comment on attachment 265373 [details]
Patch

Attachment 265373 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/418482

New failing tests:
inspector/heap/gc.html

[Build Bot]

Created attachment 265375 [details]
Archive of layout-test-results from ews100 for mac-mavericks

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-mavericks  Platform: Mac OS X 10.9.5

[Build Bot]

Comment on attachment 265373 [details]
Patch

Attachment 265373 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/418492

New failing tests:
inspector/heap/gc.html

[Build Bot]

Created attachment 265378 [details]
Archive of layout-test-results from ews115 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Created attachment 265543 [details]
Patch

Rerun tests #5

[Build Bot]

Comment on attachment 265543 [details]
Patch

Attachment 265543 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/429217

New failing tests:
inspector/heap/garbageCollected.html

[Build Bot]

Created attachment 265544 [details]
Archive of layout-test-results from ews112 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Saam Barati]

Comment on attachment 265543 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=265543&action=review

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:846
> +        auto protoObject = environment.add(propertyNames().derivedConstructorPrivateName);

Nit: I would call this variable a different name after your renaming.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3857
> +    if (m_resolvedArrowFunctionScopeContextRegister == nullptr)

Style: I think it's official WebKit style to check "!m_resolved..." Instead of "m_resolved... == nullptr"

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:3863
> +void BytecodeGenerator::emitGetThisFromArrowFunctionLexicalEnvironment()

Style: I would call this "emitLoad..." Instead of "emitGet..."
And the same below

> Source/JavaScriptCore/runtime/Executable.cpp:137
> +    , m_features((isInStrictContext ? StrictModeFeature : 0) | (isInArrowFunctionContext ? ArrowFunctionContextFeature : 0))

This seems awkward, actually. I'm not sure why we just have
the features mean one thing here. I think it's probably better just
to have a separate property like you had before.

[GSkachkov]

Created attachment 265571 [details]
Patch

Fix comments

[Build Bot]

Comment on attachment 265571 [details]
Patch

Attachment 265571 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/436011

New failing tests:
inspector/heap/garbageCollected.html

[Build Bot]

Created attachment 265575 [details]
Archive of layout-test-results from ews115 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Created attachment 265623 [details]
Patch

Fix comments

[Build Bot]

Comment on attachment 265623 [details]
Patch

Attachment 265623 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/438963

New failing tests:
inspector/dom/hideHighlight.html
inspector/heap/gc.html

[Build Bot]

Created attachment 265643 [details]
Archive of layout-test-results from ews115 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Created attachment 265735 [details]
Patch

rerun test#1

[Build Bot]

Comment on attachment 265735 [details]
Patch

Attachment 265735 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/444472

New failing tests:
inspector/heap/gc.html

[Build Bot]

Created attachment 265737 [details]
Archive of layout-test-results from ews115 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Joseph Pecoraro]

Comment on attachment 265735 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=265735&action=review

Some drive by style comments.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:1884
> +    

Whitespace!

> Source/JavaScriptCore/runtime/CommonIdentifiers.h:333
> +    macro(newTargetLocal)\
> +    macro(derivedConstructor)\

Style: Seems the normal style is to have a space after the macro.

> Source/JavaScriptCore/runtime/Executable.h:398
> +    ScriptExecutable(Structure*, VM&, const SourceCode&, bool, bool, bool);

These bools are rather mysterious. When it is non-obvious the header should normally include the name. If someone only had the header they should understand what these bools mean!

> Source/JavaScriptCore/runtime/JSGlobalObject.h:664
> +    UnlinkedEvalCodeBlock* createEvalCodeBlock(CallFrame*, EvalExecutable*, ThisTDZMode, bool, const VariableEnvironment*);

Same, this bool should really have a name.

[GSkachkov]

Created attachment 265865 [details]
Patch

Small fixes

[WebKit Commit Bot]

Attachment 265865 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/runtime/Executable.h:398:  The parameter name "structure" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Executable.h:398:  The parameter name "vm" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/runtime/Executable.h:398:  The parameter name "source" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 3 in 50 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[GSkachkov]

Created attachment 265870 [details]
Patch

Fixes styles

[Build Bot]

Comment on attachment 265870 [details]
Patch

Attachment 265870 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/450885

New failing tests:
inspector/heap/gc.html

[Build Bot]

Created attachment 265881 [details]
Archive of layout-test-results from ews101 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Created attachment 265885 [details]
Patch

Trying to fix tests

[GSkachkov]

Created attachment 265903 [details]
Patch

New try for fix

[WebKit Commit Bot]

Attachment 265903 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:4547:  One line control clauses should not use braces.  [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:4549:  One line control clauses should not use braces.  [whitespace/braces] [4]
Total errors found: 2 in 53 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Build Bot]

Comment on attachment 265903 [details]
Patch

Attachment 265903 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/451622

New failing tests:
inspector/dom/highlightRect.html

[Build Bot]

Created attachment 265911 [details]
Archive of layout-test-results from ews100 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 265903 [details]
Patch

Attachment 265903 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/451842

New failing tests:
inspector/dom/highlightNode.html

[Build Bot]

Created attachment 265917 [details]
Archive of layout-test-results from ews117 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[GSkachkov]

Comment on attachment 265903 [details]
Patch

I've managed to repeat failed test on my local pc with Tools/Scripts/run-webkit-tests --debug inspector/heap --iterations=20, then VM was running. 
I'll try to find what is wrong with my patch

[GSkachkov]

Created attachment 266215 [details]
Patch

Fix layout tests

[GSkachkov]

Created attachment 266216 [details]
Patch

Rebase

[Saam Barati]

Comment on attachment 266216 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=266216&action=review

> Source/JavaScriptCore/bytecode/UnlinkedFunctionExecutable.h:132
> +    UnlinkedFunctionExecutable(VM*, Structure*, const SourceCode&, RefPtr<SourceProvider>&& sourceOverride, FunctionMetadataNode*, UnlinkedFunctionKind, ConstructAbility, VariableEnvironment&, bool);

Style: Can we name this bool in a follow up patch.

> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2590
> +        instructions().append(0);

Lets remove this argument in a follow up patch

> Source/JavaScriptCore/runtime/Executable.h:463
> +    EvalExecutable(ExecState*, const SourceCode&, bool, bool, bool);

style: Lets name these bools in a follow up patch.

[WebKit Commit Bot]

Comment on attachment 266216 [details]
Patch

Rejecting attachment 266216 [details] from commit-queue.

[e-mail] does not have committer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/contributors.json.

- If you do not have committer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags.

- If you have committer rights please correct the error in Tools/Scripts/webkitpy/common/config/contributors.json by adding yourself to the file (no review needed).  The commit-queue restarts itself every 2 hours.  After restart the commit-queue will correctly respect your committer rights.

[WebKit Commit Bot]

Comment on attachment 266216 [details]
Patch

Rejecting attachment 266216 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'apply-attachment', '--no-update', '--non-interactive', 266216, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
 succeeded at 1 with fuzz 3.
patching file LayoutTests/js/arrowfunction-supercall-expected.txt
patching file LayoutTests/js/arrowfunction-supercall.html
patching file LayoutTests/js/arrowfunction-tdz-expected.txt
patching file LayoutTests/js/script-tests/arrowfunction-supercall.js
patching file LayoutTests/js/script-tests/arrowfunction-tdz.js

Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force', '--reviewer', u'Saam Barati']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Full output: http://webkit-queues.webkit.org/results/498683

[GSkachkov]

Created attachment 266339 [details]
Patch

Rebase to fix build

[WebKit Commit Bot]

Comment on attachment 266339 [details]
Patch

Clearing flags on attachment: 266339

Committed r192876: <http://trac.webkit.org/changeset/192876>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Carlos Garcia Campos]

It seems this broke a lot of JSC tests in GTK+ and EFL platforms, and Apple Yosemite as well. Also many layout tests time out for EFL and GTK too.

[Carlos Garcia Campos]

Reverted r192876 for reason:

It broke a lot of JSC and layout tests for GTK and EFL

Committed r192882: <http://trac.webkit.org/changeset/192882>

[Carlos Garcia Campos]

(In reply to comment #138)
> Reverted r192876 for reason:
> 
> It broke a lot of JSC and layout tests for GTK and EFL
> 
> Committed r192882: <http://trac.webkit.org/changeset/192882>

I rolled it out after talking to GSkachkov on IRC

[GSkachkov]

Created attachment 266723 [details]
Patch

Fix GTK+ & rebase

[GSkachkov]

Created attachment 266724 [details]
Patch

Fix build. Remove unused property

[GSkachkov]

Comment on attachment 266724 [details]
Patch

1. Fixed bug in GTK+
2. Merged with changes that are related to the ES6 Generators. Possible some need some refactoring to use reuse properties created for ES6 Generators. I would prefer make this refactoring in separate patch.
3. Can't check results of tests in mac-debug build bot, because tests fails before this patch.

[WebKit Commit Bot]

Comment on attachment 266724 [details]
Patch

Clearing flags on attachment: 266724

Committed r193584: <http://trac.webkit.org/changeset/193584>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[WebKit Commit Bot]

Re-opened since this is blocked by bug 151929

[David Kilzer (:ddkilzer)]

(In reply to comment #145)
> Re-opened since this is blocked by bug 151929

Rolled out in r193606: <http://trac.webkit.org/changeset/193606>

[GSkachkov]

Created attachment 266850 [details]
Patch

Fix uses-after-free crashes

[Saam Barati]

Comment on attachment 266850 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=266850&action=review

> Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:4572
> +            if (opcodeID == op_new_func_exp) {
> +                // Curly braces are necessary
> +                NEXT_OPCODE(op_new_func_exp);
> +            } else {
> +                // Curly braces are necessary
> +                NEXT_OPCODE(op_new_arrow_func_exp);
> +            }

Why not just "NEXT_OPCODE(opcodeID)" ?

> Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:2288
> +
> +

Revert this please.

> Source/JavaScriptCore/runtime/Executable.h:659
> +    // TODO:Think about avoid using isArrowFunction veriabl

Style: I don't think we need a variable.
WebKit style handles this is with a FIXME and not a TODO.
Also, the best FIXMEs are ones with bug numbers.
Anyways, I think for this patch this can just be removed.

[GSkachkov]

Created attachment 266905 [details]
Patch

Fix comments

[GSkachkov]

Comment on attachment 266850 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=266850&action=review

>> Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:4572
>> +            }
> 
> Why not just "NEXT_OPCODE(opcodeID)" ?

Hmm, I couldn't build without curly braces. I think because  NEXT_OPCODE is two line macros, and this leads to syntax error
#define NEXT_OPCODE(name) \
   m_currentIndex += OPCODE_LENGTH(name); \
   continue

>> Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:2288
>> +
> 
> Revert this please.

Done

>> Source/JavaScriptCore/runtime/Executable.h:659
>> +    // TODO:Think about avoid using isArrowFunction veriabl
> 
> Style: I don't think we need a variable.
> WebKit style handles this is with a FIXME and not a TODO.
> Also, the best FIXMEs are ones with bug numbers.
> Anyways, I think for this patch this can just be removed.

Removed

[WebKit Commit Bot]

Comment on attachment 266905 [details]
Patch

Clearing flags on attachment: 266905

Committed r193766: <http://trac.webkit.org/changeset/193766>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[GSkachkov]

*** Bug 148055 has been marked as a duplicate of this bug. ***

[Filip Pizlo]

Did anyone run performance tests on this?

[Saam Barati]

(In reply to comment #154)
> Did anyone run performance tests on this?

https://bugs.webkit.org/attachment.cgi?id=265179

[Filip Pizlo]

(In reply to comment #155)
> (In reply to comment #154)
> > Did anyone run performance tests on this?
> 
> https://bugs.webkit.org/attachment.cgi?id=265179

That's in debug mode.  Debug mode performance numbers are not meaningful.

We should make sure to do release mode performance testing of patches like this.

[Saam Barati]

(In reply to comment #156)
> (In reply to comment #155)
> > (In reply to comment #154)
> > > Did anyone run performance tests on this?
> > 
> > https://bugs.webkit.org/attachment.cgi?id=265179
> 
> That's in debug mode.  Debug mode performance numbers are not meaningful.
> 
> We should make sure to do release mode performance testing of patches like
> this.

I didn't run the tests so I don't know for sure but the results text result looks like a release build. What made you say it was Debug?

[Filip Pizlo]

(In reply to comment #157)
> (In reply to comment #156)
> > (In reply to comment #155)
> > > (In reply to comment #154)
> > > > Did anyone run performance tests on this?
> > > 
> > > https://bugs.webkit.org/attachment.cgi?id=265179
> > 
> > That's in debug mode.  Debug mode performance numbers are not meaningful.
> > 
> > We should make sure to do release mode performance testing of patches like
> > this.
> 
> I didn't run the tests so I don't know for sure but the results text result
> looks like a release build. What made you say it was Debug?

The performance is very bad in absolute terms.

I also just noticed that the performance numbers are super noisy.

Either way, someone needs to run independent performance numbers on this because these don't look right.

[Saam Barati]

(In reply to comment #158)
> (In reply to comment #157)
> > (In reply to comment #156)
> > > (In reply to comment #155)
> > > > (In reply to comment #154)
> > > > > Did anyone run performance tests on this?
> > > > 
> > > > https://bugs.webkit.org/attachment.cgi?id=265179
> > > 
> > > That's in debug mode.  Debug mode performance numbers are not meaningful.
> > > 
> > > We should make sure to do release mode performance testing of patches like
> > > this.
> > 
> > I didn't run the tests so I don't know for sure but the results text result
> > looks like a release build. What made you say it was Debug?
> 
> The performance is very bad in absolute terms.
> 
> I also just noticed that the performance numbers are super noisy.
> 
> Either way, someone needs to run independent performance numbers on this
> because these don't look right.

I'll run them tonight.

[Yusuke Suzuki]

(In reply to comment #159)
> (In reply to comment #158)
> > (In reply to comment #157)
> > > (In reply to comment #156)
> > > > (In reply to comment #155)
> > > > > (In reply to comment #154)
> > > > > > Did anyone run performance tests on this?
> > > > > 
> > > > > https://bugs.webkit.org/attachment.cgi?id=265179
> > > > 
> > > > That's in debug mode.  Debug mode performance numbers are not meaningful.
> > > > 
> > > > We should make sure to do release mode performance testing of patches like
> > > > this.
> > > 
> > > I didn't run the tests so I don't know for sure but the results text result
> > > looks like a release build. What made you say it was Debug?
> > 
> > The performance is very bad in absolute terms.
> > 
> > I also just noticed that the performance numbers are super noisy.
> > 
> > Either way, someone needs to run independent performance numbers on this
> > because these don't look right.
> 
> I'll run them tonight.

When measuring perf in Linux, I can see these noisy result.
On the other hand, when executing it in OSX with exactly the same run-jsc-benchmarks cmd,
I can get somewhat solid result. So usually I measure perf on OSX machine.
(In Linux, I ensured that cpu freq is fixed as "performance" mode, not "ondemand")
I guess that is due to FTL's system allocator... But anyway, retaking it in OSX is nice.

[Yusuke Suzuki]

Ah, but seems like that the original data is taken in OSX, so ignore me.

[Saam Barati]

Perf seems okay. A tad bit noisy on a few benchmarks though.

VMs tested:
"og" at /Users/saambarati/WK/Clean/WebKitBuild/Release/jsc (r193765)
"arrow" at /Users/saambarati/WK/ternary/WebKitBuild/Release/jsc (r193766)
    export JSC_useSamplingProfiler=1

Collected 8 samples per benchmark/VM, with 8 VM invocations per benchmark. Emitted a call to gc() between sample measurements.
Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime() function to get microsecond-level
timing. Reporting benchmark execution times with 95% confidence intervals in milliseconds.

                                                            og                      arrow                                       
SunSpider:
   3d-cube                                            5.5486+-0.3776     ?      6.1588+-1.4880        ? might be 1.1100x slower
   3d-morph                                           6.7723+-0.5524            6.5086+-0.1315          might be 1.0405x faster
   3d-raytrace                                        9.3464+-2.1256     ?     10.1861+-4.4079        ? might be 1.0898x slower
   access-binary-trees                                3.6955+-1.1855            3.4952+-0.9042          might be 1.0573x faster
   access-fannkuch                                    7.7849+-0.8594            7.7361+-1.0548        
   access-nbody                                       3.3492+-0.4328            3.1038+-0.2850          might be 1.0791x faster
   access-nsieve                                      3.8852+-0.1749     ?      4.1947+-0.6992        ? might be 1.0797x slower
   bitops-3bit-bits-in-byte                           1.7157+-0.2390     ?      2.4620+-1.6877        ? might be 1.4350x slower
   bitops-bits-in-byte                                4.7824+-0.3928            4.4350+-0.4019          might be 1.0783x faster
   bitops-bitwise-and                                 2.4158+-0.0954     ?      2.5887+-0.3844        ? might be 1.0716x slower
   bitops-nsieve-bits                                 3.8405+-0.5083     ?      4.1218+-0.5889        ? might be 1.0732x slower
   controlflow-recursive                              3.3475+-0.1065     ?      3.9525+-0.7372        ? might be 1.1807x slower
   crypto-aes                                         5.7680+-1.1998            5.5320+-1.2805          might be 1.0427x faster
   crypto-md5                                         3.6719+-0.4851     ?      4.3861+-0.9448        ? might be 1.1945x slower
   crypto-sha1                                        3.4907+-0.0351     !      3.9138+-0.3680        ! definitely 1.1212x slower
   date-format-tofte                                 10.4695+-0.3881     ?     11.5784+-0.8405        ? might be 1.1059x slower
   date-format-xparb                                  6.1061+-0.6993     ?      6.4102+-0.8086        ? might be 1.0498x slower
   math-cordic                                        4.6160+-0.9783     ?      4.8223+-0.9542        ? might be 1.0447x slower
   math-partial-sums                                  5.7780+-0.2839     ?      5.7858+-0.3766        ?
   math-spectral-norm                                 3.2014+-1.0684     ?      3.4571+-0.9249        ? might be 1.0798x slower
   regexp-dna                                         7.5759+-0.5813            7.0899+-0.1348          might be 1.0686x faster
   string-base64                                      5.3790+-0.4437     ?      6.0667+-0.8667        ? might be 1.1279x slower
   string-fasta                                       9.4520+-1.6485     ?      9.7833+-1.3737        ? might be 1.0351x slower
   string-tagcloud                                   10.2208+-0.6563     ?     11.7310+-2.2655        ? might be 1.1478x slower
   string-unpack-code                                24.7955+-2.5243     ?     28.7615+-2.5959        ? might be 1.1599x slower
   string-validate-input                              6.0537+-0.8694            5.9535+-0.6086          might be 1.0168x faster

   <arithmetic>                                       6.2716+-0.1802     ?      6.7006+-0.2872        ? might be 1.0684x slower

                                                            og                      arrow                                       
LongSpider:
   3d-cube                                          979.6206+-12.9415    ?    983.8770+-7.6640        ?
   3d-morph                                        1867.6507+-10.6847    ?   1875.8593+-19.7275       ?
   3d-raytrace                                      744.7828+-9.5260     ?    746.7947+-13.2296       ?
   access-binary-trees                             1078.2459+-7.6618         1067.1676+-5.1968          might be 1.0104x faster
   access-fannkuch                                  384.0465+-43.1038         363.1958+-6.3895          might be 1.0574x faster
   access-nbody                                     644.0381+-12.3405         641.1700+-5.2252        
   access-nsieve                                    560.9791+-1.9321     !    568.0314+-3.5764        ! definitely 1.0126x slower
   bitops-3bit-bits-in-byte                          42.2215+-2.1880     ?     43.2518+-1.5597        ? might be 1.0244x slower
   bitops-bits-in-byte                               96.4558+-3.5735     ?    100.8814+-11.8439       ? might be 1.0459x slower
   bitops-nsieve-bits                               586.9264+-5.7668     ?    587.7823+-9.1255        ?
   controlflow-recursive                            557.2467+-9.5031          554.5475+-7.7653        
   crypto-aes                                       676.6859+-4.8312          676.2295+-9.5004        
   crypto-md5                                       595.0514+-7.1109     ?    610.5173+-37.8467       ? might be 1.0260x slower
   crypto-sha1                                      878.2572+-164.2451        799.1692+-7.3824          might be 1.0990x faster
   date-format-tofte                                680.3575+-5.7515     ?    681.8051+-18.2792       ?
   date-format-xparb                                776.8523+-10.6451    ?    788.6069+-21.1484       ? might be 1.0151x slower
   hash-map                                         188.7241+-3.8994          185.0798+-3.9975          might be 1.0197x faster
   math-cordic                                      607.3768+-8.5754     ?    634.5539+-71.1293       ? might be 1.0447x slower
   math-partial-sums                                571.6515+-6.3154     ?    573.2576+-5.8824        ?
   math-spectral-norm                               691.9677+-6.7637          691.5540+-5.2446        
   string-base64                                    444.7595+-2.8129          443.5006+-4.6501        
   string-fasta                                     441.8869+-2.5853          439.5662+-3.7555        
   string-tagcloud                                  218.1470+-11.6746         212.4490+-2.7693          might be 1.0268x faster

   <geometric>                                      495.2857+-4.2478          494.6303+-5.8083          might be 1.0013x faster

                                                            og                      arrow                                       
V8Spider:
   crypto                                            94.2758+-4.1621     ?    104.4034+-17.8815       ? might be 1.1074x slower
   deltablue                                        128.1318+-5.5391     ?    129.8629+-6.9113        ? might be 1.0135x slower
   earley-boyer                                      80.5216+-7.3165           77.0105+-6.5667          might be 1.0456x faster
   raytrace                                          58.9718+-6.9031     ?     65.5312+-15.6587       ? might be 1.1112x slower
   regexp                                            77.8062+-2.4904           76.6958+-3.0017          might be 1.0145x faster
   richards                                          99.3256+-4.2371           98.5087+-4.0453        
   splay                                             63.6587+-4.3887           62.8673+-4.6837          might be 1.0126x faster

   <geometric>                                       83.2690+-2.4624     ?     84.5431+-3.2161        ? might be 1.0153x slower

                                                            og                      arrow                                       
Octane:
   encrypt                                           0.19165+-0.00365          0.19029+-0.00518       
   decrypt                                           3.58433+-0.03293    ?     3.63544+-0.04199       ? might be 1.0143x slower
   deltablue                                x2       0.16695+-0.00244          0.16506+-0.00160         might be 1.0115x faster
   earley                                            0.36065+-0.00174    ?     0.36209+-0.00160       ?
   boyer                                             5.51499+-0.06528    ?     6.00535+-1.25312       ? might be 1.0889x slower
   navier-stokes                            x2       6.01258+-0.07613          5.98522+-0.06443       
   raytrace                                 x2       1.06516+-0.01745    ?     1.06660+-0.01788       ?
   richards                                 x2       0.11028+-0.00195          0.10828+-0.00086         might be 1.0186x faster
   splay                                    x2       0.56531+-0.01233    ?     0.57407+-0.00983       ? might be 1.0155x slower
   regexp                                   x2      30.42811+-0.43184         30.41776+-0.23783       
   pdfjs                                    x2      45.86188+-0.91945    ?    46.39565+-0.54838       ? might be 1.0116x slower
   mandreel                                 x2      68.52068+-2.13330         66.67114+-1.02211         might be 1.0277x faster
   gbemu                                    x2      55.31618+-3.54668    ?    56.20139+-3.38554       ? might be 1.0160x slower
   closure                                           0.69902+-0.00645    ?     0.69985+-0.00592       ?
   jquery                                            9.31115+-0.09030          9.22842+-0.07755       
   box2d                                    x2      15.09213+-2.62887         14.65425+-1.70357         might be 1.0299x faster
   zlib                                     x2     477.69994+-12.42784       477.31493+-11.55819      
   typescript                               x2    1013.44379+-51.85526       997.60849+-14.86373        might be 1.0159x faster

   <geometric>                                       7.21930+-0.13280          7.20891+-0.06947         might be 1.0014x faster

                                                            og                      arrow                                       
Kraken:
   ai-astar                                          158.360+-20.191           148.433+-2.056           might be 1.0669x faster
   audio-beat-detection                               57.754+-3.308      ?      62.284+-12.044        ? might be 1.0784x slower
   audio-dft                                         145.212+-24.168           136.132+-2.022           might be 1.0667x faster
   audio-fft                                          42.185+-1.458      ?      44.726+-5.909         ? might be 1.0602x slower
   audio-oscillator                                   69.004+-2.002      ?      72.244+-2.573         ? might be 1.0469x slower
   imaging-darkroom                                   74.577+-2.839             72.167+-3.033           might be 1.0334x faster
   imaging-desaturate                                 71.886+-3.510      ?      72.630+-3.979         ? might be 1.0104x slower
   imaging-gaussian-blur                             104.800+-3.349            104.723+-2.226         
   json-parse-financial                               48.685+-5.054      ?      49.805+-4.713         ? might be 1.0230x slower
   json-stringify-tinderbox                           30.644+-3.016      ?      31.420+-4.706         ? might be 1.0253x slower
   stanford-crypto-aes                                56.982+-3.034             53.615+-2.909           might be 1.0628x faster
   stanford-crypto-ccm                                49.070+-5.787      ?      51.168+-7.458         ? might be 1.0427x slower
   stanford-crypto-pbkdf2                            127.559+-21.382           117.815+-3.032           might be 1.0827x faster
   stanford-crypto-sha256-iterative                   44.168+-0.875      ?      45.854+-1.524         ? might be 1.0382x slower

   <arithmetic>                                       77.206+-3.385             75.930+-1.844           might be 1.0168x faster

                                                            og                      arrow                                       
JSRegress:
   abc-forward-loop-equal                            37.2579+-2.3398           35.7465+-1.0912          might be 1.0423x faster
   abc-postfix-backward-loop                         38.4064+-6.7649           35.9295+-1.9088          might be 1.0689x faster
   abc-simple-backward-loop                          35.5298+-1.3557     ?     35.9082+-1.2656        ? might be 1.0107x slower
   abc-simple-forward-loop                           36.6216+-0.9619           36.4425+-3.9351        
   abc-skippy-loop                                   26.0396+-1.5759     ?     28.4593+-8.1786        ? might be 1.0929x slower
   abs-boolean                                        3.1456+-0.1699     ?      3.5277+-0.6378        ? might be 1.1215x slower
   adapt-to-double-divide                            20.5440+-3.4677           19.6534+-1.0639          might be 1.0453x faster
   aliased-arguments-getbyval                         1.4484+-0.1026     ?      1.7911+-0.5195        ? might be 1.2366x slower
   allocate-big-object                                3.4569+-0.7461     ?      3.5705+-1.3345        ? might be 1.0328x slower
   arguments-named-and-reflective                    17.0524+-8.7680           13.8434+-1.6635          might be 1.2318x faster
   arguments-out-of-bounds                           12.3063+-0.4771     ?     13.1274+-1.1189        ? might be 1.0667x slower
   arguments-strict-mode                             11.6178+-0.7198     ?     12.5719+-1.2735        ? might be 1.0821x slower
   arguments                                         10.2392+-0.5618            9.8727+-0.1396          might be 1.0371x faster
   arity-mismatch-inlining                            1.6434+-0.7833            1.2252+-0.0868          might be 1.3414x faster
   array-access-polymorphic-structure                 8.6277+-0.5405     ?      9.1590+-1.3513        ? might be 1.0616x slower
   array-nonarray-polymorhpic-access                 33.2805+-4.0321           31.0485+-2.7368          might be 1.0719x faster
   array-prototype-every                             93.0138+-4.0171     ?     94.7696+-3.6091        ? might be 1.0189x slower
   array-prototype-forEach                           94.0331+-4.6714     ?    105.6436+-25.6265       ? might be 1.1235x slower
   array-prototype-map                              101.9197+-4.8605     ?    103.0874+-3.1996        ? might be 1.0115x slower
   array-prototype-reduce                            90.3503+-4.7914     ?     95.9212+-7.7394        ? might be 1.0617x slower
   array-prototype-reduceRight                       97.0178+-8.0480           92.3733+-6.7306          might be 1.0503x faster
   array-prototype-some                              97.1310+-5.0248           96.4595+-3.0243        
   array-splice-contiguous                           28.6559+-1.9033           27.7673+-1.5342          might be 1.0320x faster
   array-with-double-add                              4.3314+-0.1927     ?      4.3662+-0.2464        ?
   array-with-double-increment                        4.5760+-0.7823            3.9757+-0.2593          might be 1.1510x faster
   array-with-double-mul-add                          6.6307+-1.2763            6.1796+-1.4461          might be 1.0730x faster
   array-with-double-sum                              4.2396+-0.6035            4.0898+-0.3208          might be 1.0366x faster
   array-with-int32-add-sub                           9.9673+-1.2296            9.2478+-1.9793          might be 1.0778x faster
   array-with-int32-or-double-sum                     4.3331+-0.4979     ?      4.4148+-0.6502        ? might be 1.0189x slower
   ArrayBuffer-DataView-alloc-large-long-lived   
                                                     39.2668+-2.8121     ?     40.1184+-2.6948        ? might be 1.0217x slower
   ArrayBuffer-DataView-alloc-long-lived             15.9205+-1.2869           15.4484+-1.2372          might be 1.0306x faster
   ArrayBuffer-Int32Array-byteOffset                  4.5631+-0.3146            4.2748+-0.1547          might be 1.0674x faster
   ArrayBuffer-Int8Array-alloc-large-long-lived   
                                                     39.9039+-2.2320           38.2159+-2.6773          might be 1.0442x faster
   ArrayBuffer-Int8Array-alloc-long-lived-buffer   
                                                     25.4290+-2.0875           24.6682+-1.5413          might be 1.0308x faster
   ArrayBuffer-Int8Array-alloc-long-lived            14.1549+-0.8256     ?     15.2833+-1.9873        ? might be 1.0797x slower
   ArrayBuffer-Int8Array-alloc                       13.2227+-1.2507           12.7815+-1.0694          might be 1.0345x faster
   asmjs_bool_bug                                     9.2168+-0.6827            9.1978+-0.5884        
   assign-custom-setter-polymorphic                   2.8987+-0.1680     ?      3.3512+-0.3783        ? might be 1.1561x slower
   assign-custom-setter                               4.0440+-0.2516     ?      4.3845+-0.7428        ? might be 1.0842x slower
   basic-set                                         13.3817+-1.4564           12.6051+-0.4201          might be 1.0616x faster
   big-int-mul                                        5.3145+-1.0886            5.0489+-1.2849          might be 1.0526x faster
   boolean-test                                       4.4485+-1.6660            3.4810+-0.1771          might be 1.2780x faster
   branch-fold                                        4.4475+-0.2387     ?      5.6894+-1.9361        ? might be 1.2792x slower
   branch-on-string-as-boolean                       20.7794+-1.5399           19.5341+-0.6242          might be 1.0638x faster
   by-val-generic                                     2.9631+-0.2916     ?      3.2131+-0.4442        ? might be 1.0844x slower
   call-spread-apply                                 43.6687+-2.8071     ?     44.6581+-3.4074        ? might be 1.0227x slower
   call-spread-call                                  33.0528+-2.5648     ?     34.2193+-2.9838        ? might be 1.0353x slower
   captured-assignments                               0.6949+-0.2564            0.5858+-0.0358          might be 1.1862x faster
   cast-int-to-double                                 7.1781+-1.3036            6.8158+-0.3286          might be 1.0532x faster
   cell-argument                                      7.4037+-0.8052     ?      7.4144+-0.8340        ?
   cfg-simplify                                       3.5155+-0.4068     ?      3.8013+-1.0554        ? might be 1.0813x slower
   chain-getter-access                               10.5173+-0.1356     ?     11.8623+-1.4680        ? might be 1.1279x slower
   cmpeq-obj-to-obj-other                            18.6098+-3.6358           16.4263+-2.2825          might be 1.1329x faster
   constant-test                                      6.4961+-0.8532     ?      6.6080+-0.4624        ? might be 1.0172x slower
   create-lots-of-functions                          13.5147+-1.4590           13.0828+-1.5589          might be 1.0330x faster
   cse-new-array-buffer                               3.3037+-0.6428            3.0935+-0.4439          might be 1.0679x faster
   cse-new-array                                      3.2596+-0.4567            3.1004+-0.3207          might be 1.0514x faster
   DataView-custom-properties                        43.7892+-2.7348     ?     44.6245+-2.8140        ? might be 1.0191x slower
   deconstructing-parameters-overridden-by-function   
                                                      0.6794+-0.1088            0.6239+-0.0776          might be 1.0890x faster
   delay-tear-off-arguments-strictmode               16.3296+-1.2392     ?     17.3647+-1.6716        ? might be 1.0634x slower
   deltablue-varargs                                240.0904+-21.3412         233.3723+-5.2693          might be 1.0288x faster
   destructuring-arguments                          196.9813+-4.8798          196.6165+-3.5080        
   destructuring-swap                                 6.6623+-0.4985     ?      7.8062+-2.6722        ? might be 1.1717x slower
   direct-arguments-getbyval                          1.6988+-0.5177            1.4304+-0.1834          might be 1.1876x faster
   div-boolean-double                                 6.3949+-0.6125            6.0061+-0.1330          might be 1.0647x faster
   div-boolean                                       10.0115+-1.6846            9.6446+-0.3696          might be 1.0380x faster
   double-get-by-val-out-of-bounds                    6.7544+-0.8453            6.7137+-0.9961        
   double-pollution-getbyval                          9.9826+-0.6310     ?     10.2161+-0.6550        ? might be 1.0234x slower
   double-pollution-putbyoffset                       4.5938+-0.4472     ?      4.8499+-0.7388        ? might be 1.0558x slower
   double-real-use                                   30.0794+-1.9350     ?     30.5691+-1.7329        ? might be 1.0163x slower
   double-to-int32-typed-array-no-inline              3.2495+-0.3063     ?      3.2968+-0.4816        ? might be 1.0146x slower
   double-to-int32-typed-array                        3.0900+-0.3486     ?      3.1309+-0.2677        ? might be 1.0132x slower
   double-to-uint32-typed-array-no-inline             3.6238+-0.4522            3.4441+-0.4179          might be 1.0522x faster
   double-to-uint32-typed-array                       3.7118+-0.8975            3.0998+-0.3114          might be 1.1975x faster
   elidable-new-object-dag                           45.8504+-2.7162           45.1216+-2.4527          might be 1.0162x faster
   elidable-new-object-roflcopter                    43.5858+-1.4398     ?     43.9602+-1.1385        ?
   elidable-new-object-then-call                     41.8176+-2.5375           41.5889+-3.0084        
   elidable-new-object-tree                          55.7389+-7.5940           53.8633+-4.7310          might be 1.0348x faster
   empty-string-plus-int                              7.2627+-1.4399            7.0235+-1.4734          might be 1.0341x faster
   emscripten-cube2hash                              43.2194+-6.3927           39.4663+-1.6437          might be 1.0951x faster
   exit-length-on-plain-object                       18.7541+-1.0626           18.3673+-0.5603          might be 1.0211x faster
   external-arguments-getbyval                        2.7480+-2.4020            1.8173+-0.4893          might be 1.5121x faster
   external-arguments-putbyval                        3.3431+-0.5308            3.3301+-0.7049        
   fixed-typed-array-storage-var-index                1.7029+-0.1506     ?      1.9047+-0.4691        ? might be 1.1185x slower
   fixed-typed-array-storage                          1.2867+-0.0313     ?      2.1949+-1.0326        ? might be 1.7058x slower
   Float32Array-matrix-mult                           5.2332+-0.4382            5.0654+-0.3022          might be 1.0331x faster
   Float32Array-to-Float64Array-set                  59.1094+-1.8590     ?     60.0805+-2.2669        ? might be 1.0164x slower
   Float64Array-alloc-long-lived                     84.8658+-4.4382     ?     91.3128+-13.4277       ? might be 1.0760x slower
   Float64Array-to-Int16Array-set                    75.3679+-3.0505     ?     78.6457+-12.8880       ? might be 1.0435x slower
   fold-double-to-int                                15.8759+-1.3497     ?     16.0391+-1.7076        ? might be 1.0103x slower
   fold-get-by-id-to-multi-get-by-offset-rare-int   
                                                     16.4219+-1.6391           16.3318+-3.9740        
   fold-get-by-id-to-multi-get-by-offset             15.3993+-2.4073     ?     17.4256+-3.3929        ? might be 1.1316x slower
   fold-multi-get-by-offset-to-get-by-offset   
                                                     13.5442+-2.9402     ?     15.0516+-1.8716        ? might be 1.1113x slower
   fold-multi-get-by-offset-to-poly-get-by-offset   
                                                     13.3754+-1.9016     ?     15.5807+-2.1758        ? might be 1.1649x slower
   fold-multi-put-by-offset-to-poly-put-by-offset   
                                                     16.3234+-2.2109           14.7454+-2.5984          might be 1.1070x faster
   fold-multi-put-by-offset-to-put-by-offset   
                                                     16.5553+-2.3376           14.1646+-1.1066          might be 1.1688x faster
   fold-multi-put-by-offset-to-replace-or-transition-put-by-offset   
                                                     16.0363+-1.9765     ?     17.7013+-4.4254        ? might be 1.1038x slower
   fold-put-by-id-to-multi-put-by-offset             17.2283+-1.5242     ?     17.2981+-3.6472        ?
   fold-put-structure                                13.7028+-2.9131     ?     14.5268+-0.9158        ? might be 1.0601x slower
   for-of-iterate-array-entries                      14.0406+-0.6858     ?     16.5756+-4.1127        ? might be 1.1805x slower
   for-of-iterate-array-keys                          5.3665+-1.3754            5.2263+-1.0263          might be 1.0268x faster
   for-of-iterate-array-values                        4.7393+-0.5649     ?      4.9382+-0.6473        ? might be 1.0420x slower
   fround                                            21.3670+-1.7628           21.2838+-1.1406        
   ftl-library-inlining-dataview                     69.2258+-3.0072     ?     75.7873+-7.4709        ? might be 1.0948x slower
   ftl-library-inlining                             104.1258+-17.0993          94.6728+-3.0155          might be 1.0998x faster
   function-dot-apply                                 2.9359+-0.4578            2.9344+-0.2188        
   function-test                                      3.4261+-0.4497            3.3767+-0.2988          might be 1.0147x faster
   function-with-eval                               101.8975+-3.0056     ?    107.6019+-3.0544        ? might be 1.0560x slower
   gcse-poly-get-less-obvious                        25.8231+-2.3331           25.7687+-1.5290        
   gcse-poly-get                                     28.8874+-1.7344           28.3009+-1.1950          might be 1.0207x faster
   gcse                                               4.9285+-0.9418            4.6151+-0.3336          might be 1.0679x faster
   get-by-id-bimorphic-check-structure-elimination-simple   
                                                      3.4864+-0.3799            3.4534+-0.2181        
   get-by-id-bimorphic-check-structure-elimination   
                                                      6.3324+-0.9037     ?      6.4219+-0.8451        ? might be 1.0141x slower
   get-by-id-chain-from-try-block                     3.5633+-0.6249            3.3322+-0.4275          might be 1.0693x faster
   get-by-id-check-structure-elimination              5.4746+-1.1774            5.3190+-0.7651          might be 1.0293x faster
   get-by-id-proto-or-self                           20.8489+-1.4950     ?     21.8380+-2.0444        ? might be 1.0474x slower
   get-by-id-quadmorphic-check-structure-elimination-simple   
                                                      4.3014+-0.8478            3.9215+-0.7883          might be 1.0969x faster
   get-by-id-self-or-proto                           20.5865+-1.9381     ?     20.8556+-1.7183        ? might be 1.0131x slower
   get-by-val-out-of-bounds                           6.3422+-0.7075     ?      6.5540+-0.4376        ? might be 1.0334x slower
   get_callee_monomorphic                             5.3254+-1.6598            5.0698+-1.7555          might be 1.0504x faster
   get_callee_polymorphic                             4.4986+-0.4603            3.9905+-0.2309          might be 1.1273x faster
   getter-no-activation                               6.0191+-0.6340     ?      6.4662+-0.9116        ? might be 1.0743x slower
   getter-prototype                                  10.2050+-0.3790     ?     10.5055+-1.0068        ? might be 1.0295x slower
   getter-richards                                  201.9159+-12.7781         197.1846+-3.1066          might be 1.0240x faster
   getter                                             9.5755+-1.1654            8.3142+-0.8070          might be 1.1517x faster
   global-var-const-infer-fire-from-opt               0.9047+-0.0348     ?      1.4013+-0.4646        ? might be 1.5489x slower
   global-var-const-infer                             0.8293+-0.0577     ?      0.8658+-0.0876        ? might be 1.0440x slower
   HashMap-put-get-iterate-keys                      49.9581+-9.3407           48.1003+-4.4557          might be 1.0386x faster
   HashMap-put-get-iterate                           51.8194+-2.7933           50.6197+-3.5713          might be 1.0237x faster
   HashMap-string-put-get-iterate                    38.2748+-1.9891     ?     42.6238+-3.8388        ? might be 1.1136x slower
   hoist-make-rope                                   12.5659+-0.8705     ?     12.6675+-1.6290        ?
   hoist-poly-check-structure-effectful-loop   
                                                      4.7118+-0.5956            4.6806+-0.5861        
   hoist-poly-check-structure                         3.9561+-0.4244     ?      4.2675+-0.7336        ? might be 1.0787x slower
   imul-double-only                                   9.9329+-1.7565            9.8946+-1.1923        
   imul-int-only                                     10.0328+-1.3524           10.0313+-1.0619        
   imul-mixed                                         8.0088+-0.6250     ?      8.4963+-1.2590        ? might be 1.0609x slower
   in-four-cases                                     24.7942+-2.2616     ?     28.0699+-4.7857        ? might be 1.1321x slower
   in-one-case-false                                 16.5529+-1.1108           15.4301+-1.6122          might be 1.0728x faster
   in-one-case-true                                  16.3685+-1.9449     ?     17.4533+-3.6025        ? might be 1.0663x slower
   in-two-cases                                      15.4241+-0.9138     ?     16.7668+-0.8443        ? might be 1.0870x slower
   indexed-properties-in-objects                      3.9228+-0.5768     ?      4.7503+-2.6804        ? might be 1.2109x slower
   infer-closure-const-then-mov-no-inline             7.0280+-1.3573            5.8040+-1.3924          might be 1.2109x faster
   infer-closure-const-then-mov                      21.5053+-3.3825           21.2701+-1.7546          might be 1.0111x faster
   infer-closure-const-then-put-to-scope-no-inline   
                                                     13.7957+-0.9999           12.8392+-0.5734          might be 1.0745x faster
   infer-closure-const-then-put-to-scope             27.0936+-0.7978           26.8879+-1.1094        
   infer-closure-const-then-reenter-no-inline   
                                                     59.3963+-7.4071           55.9055+-4.1013          might be 1.0624x faster
   infer-closure-const-then-reenter                  27.5713+-1.0826           27.4870+-1.0522        
   infer-constant-global-property                     4.1000+-0.2353     ?      4.3567+-0.9074        ? might be 1.0626x slower
   infer-constant-property                            3.3316+-0.3537     ?      3.8195+-0.9738        ? might be 1.1464x slower
   infer-one-time-closure-ten-vars                    9.6924+-0.7754            9.3388+-0.5829          might be 1.0379x faster
   infer-one-time-closure-two-vars                    9.0012+-0.9003     ?      9.5344+-0.7486        ? might be 1.0592x slower
   infer-one-time-closure                             9.4675+-1.3114            8.2992+-0.3492          might be 1.1408x faster
   infer-one-time-deep-closure                       13.3735+-0.5226     ?     13.6130+-1.8708        ? might be 1.0179x slower
   inline-arguments-access                            5.2063+-0.5288     ?      6.1911+-1.9950        ? might be 1.1891x slower
   inline-arguments-aliased-access                    5.4153+-0.9304            5.3040+-0.5668          might be 1.0210x faster
   inline-arguments-local-escape                      5.5848+-0.7107            5.5738+-0.5697        
   inline-get-scoped-var                              9.0743+-3.7312            6.1892+-0.5828          might be 1.4662x faster
   inlined-put-by-id-transition                      14.2269+-1.8896     ?     14.6714+-1.5965        ? might be 1.0312x slower
   int-or-other-abs-then-get-by-val                   6.5051+-1.0603     ?      6.8251+-1.1843        ? might be 1.0492x slower
   int-or-other-abs-zero-then-get-by-val             19.3748+-1.3415           18.6546+-0.9527          might be 1.0386x faster
   int-or-other-add-then-get-by-val                   6.1991+-1.2500            6.0734+-1.0100          might be 1.0207x faster
   int-or-other-add                                   6.8814+-0.4687     ?      7.1674+-1.5134        ? might be 1.0416x slower
   int-or-other-div-then-get-by-val                   5.5648+-0.9681            5.4134+-0.7751          might be 1.0280x faster
   int-or-other-max-then-get-by-val                   5.9802+-2.2235            5.0877+-0.9310          might be 1.1754x faster
   int-or-other-min-then-get-by-val                   4.8323+-0.8217     ?      5.4706+-1.1039        ? might be 1.1321x slower
   int-or-other-mod-then-get-by-val                   4.5843+-0.5839     ?      5.5934+-1.9680        ? might be 1.2201x slower
   int-or-other-mul-then-get-by-val                   4.8411+-1.1100     ?      5.4257+-2.3754        ? might be 1.1208x slower
   int-or-other-neg-then-get-by-val                   6.2528+-0.5724     ?      6.3528+-1.0423        ? might be 1.0160x slower
   int-or-other-neg-zero-then-get-by-val             19.3617+-0.5449     ?     19.4342+-2.1737        ?
   int-or-other-sub-then-get-by-val                   7.1858+-1.0083            6.8348+-1.6533          might be 1.0514x faster
   int-or-other-sub                                   4.4160+-0.8960     ?      5.6829+-1.7405        ? might be 1.2869x slower
   int-overflow-local                                 5.8922+-1.0411     ?      6.0024+-0.7940        ? might be 1.0187x slower
   Int16Array-alloc-long-lived                       60.6396+-1.9842     ?     62.9409+-3.1944        ? might be 1.0380x slower
   Int16Array-bubble-sort-with-byteLength            26.9279+-1.7888     ?     27.8375+-1.9868        ? might be 1.0338x slower
   Int16Array-bubble-sort                            26.7879+-2.4825     ?     27.2955+-4.0658        ? might be 1.0189x slower
   Int16Array-load-int-mul                            2.4442+-0.7363            2.3841+-0.9629          might be 1.0252x faster
   Int16Array-to-Int32Array-set                      54.7574+-2.4504     ?     55.6938+-3.4496        ? might be 1.0171x slower
   Int32Array-alloc-large                            13.7660+-0.9221     ?     15.5786+-2.3366        ? might be 1.1317x slower
   Int32Array-alloc-long-lived                       71.8069+-2.9273           71.1467+-1.1266        
   Int32Array-alloc                                   3.5486+-0.1001     ?      3.8785+-0.5284        ? might be 1.0930x slower
   Int32Array-Int8Array-view-alloc                    7.7768+-1.1584            7.0909+-0.2946          might be 1.0967x faster
   int52-spill                                        6.8822+-1.1863     ?      7.8849+-1.1672        ? might be 1.1457x slower
   Int8Array-alloc-long-lived                        54.7040+-3.2661     ?     55.7315+-3.9118        ? might be 1.0188x slower
   Int8Array-load-with-byteLength                     4.5692+-0.6880            4.3046+-0.4991          might be 1.0615x faster
   Int8Array-load                                     4.8325+-1.7270            4.0877+-0.1485          might be 1.1822x faster
   integer-divide                                    12.4633+-1.0606     ?     13.3499+-1.6024        ? might be 1.0711x slower
   integer-modulo                                     2.2004+-0.5812     ?      3.0005+-0.3615        ? might be 1.3636x slower
   is-boolean-fold-tricky                             4.5012+-0.2893     ?      4.5383+-0.3627        ?
   is-boolean-fold                                    3.6093+-0.3428            3.3966+-0.2772          might be 1.0626x faster
   is-function-fold-tricky-internal-function   
                                                     12.4520+-1.6358     ?     12.8837+-1.5570        ? might be 1.0347x slower
   is-function-fold-tricky                            5.8409+-1.5565            5.0497+-0.6861          might be 1.1567x faster
   is-function-fold                                   3.8815+-0.7866            3.5265+-0.4044          might be 1.1007x faster
   is-number-fold-tricky                              5.1023+-0.8659     ?      5.2931+-0.8870        ? might be 1.0374x slower
   is-number-fold                                     3.3299+-0.2084            3.2468+-0.1569          might be 1.0256x faster
   is-object-or-null-fold-functions                   3.6634+-0.8199            3.2487+-0.0762          might be 1.1276x faster
   is-object-or-null-fold-less-tricky                 5.2957+-0.6472     ?      5.3200+-0.6984        ?
   is-object-or-null-fold-tricky                      6.5538+-1.3269            6.4363+-1.2027          might be 1.0183x faster
   is-object-or-null-fold                             3.4477+-0.3634            3.4066+-0.2580          might be 1.0121x faster
   is-object-or-null-trickier-function                5.2358+-1.0067     ?      5.5409+-0.8448        ? might be 1.0583x slower
   is-object-or-null-trickier-internal-function   
                                                     13.9175+-3.5380           13.2418+-2.0966          might be 1.0510x faster
   is-object-or-null-tricky-function                  5.4054+-0.9216            5.2749+-0.7598          might be 1.0247x faster
   is-object-or-null-tricky-internal-function   
                                                     11.6495+-3.0602           10.7815+-1.8177          might be 1.0805x faster
   is-string-fold-tricky                              4.4926+-0.0891     ?      5.0273+-0.8342        ? might be 1.1190x slower
   is-string-fold                                     3.2773+-0.1458     ?      3.8502+-0.8579        ? might be 1.1748x slower
   is-undefined-fold-tricky                           5.0959+-1.6424            4.6981+-0.8968          might be 1.0847x faster
   is-undefined-fold                                  3.4615+-0.3501            3.4347+-0.2692        
   large-int-captured                                 5.5484+-0.7128     ?      6.7182+-1.5821        ? might be 1.2108x slower
   large-int-neg                                     17.2491+-1.2234     ?     18.0859+-1.8745        ? might be 1.0485x slower
   large-int                                         16.2925+-0.7841           15.8744+-1.0113          might be 1.0263x faster
   load-varargs-elimination                          26.5208+-4.9690           24.4740+-1.1209          might be 1.0836x faster
   logical-not-weird-types                            4.0546+-0.3700     ?      4.8073+-1.0364        ? might be 1.1856x slower
   logical-not                                        6.6178+-1.0384            6.5918+-0.8072        
   lots-of-fields                                    12.0117+-1.1511     ?     12.5003+-1.6432        ? might be 1.0407x slower
   make-indexed-storage                               3.6068+-0.1934     ?      4.0336+-0.8168        ? might be 1.1183x slower
   make-rope-cse                                      5.0674+-0.4251     ?      5.3017+-0.9595        ? might be 1.0462x slower
   marsaglia-larger-ints                             40.3790+-3.3904           37.7698+-1.7711          might be 1.0691x faster
   marsaglia-osr-entry                               25.6728+-1.6537     ?     26.2175+-1.4756        ? might be 1.0212x slower
   math-with-out-of-bounds-array-values              27.4670+-2.2391           25.4466+-1.5306          might be 1.0794x faster
   max-boolean                                        3.5387+-0.6257            3.1871+-0.1961          might be 1.1103x faster
   method-on-number                                  21.2495+-4.1046           19.5970+-1.3532          might be 1.0843x faster
   min-boolean                                        3.5667+-0.4092     ?      4.0263+-0.7557        ? might be 1.1288x slower
   minus-boolean-double                               3.7137+-0.1919            3.6678+-0.2161          might be 1.0125x faster
   minus-boolean                                      3.4976+-0.6851            3.2144+-0.4545          might be 1.0881x faster
   misc-strict-eq                                    34.6359+-1.6161     ?     36.2059+-3.3835        ? might be 1.0453x slower
   mod-boolean-double                                12.7856+-0.2986     ?     13.1305+-0.4317        ? might be 1.0270x slower
   mod-boolean                                        9.7702+-0.3897            9.5118+-0.2316          might be 1.0272x faster
   mul-boolean-double                                 4.1799+-0.1579     ?      4.3141+-0.4004        ? might be 1.0321x slower
   mul-boolean                                        5.0107+-3.6920            3.4553+-0.3305          might be 1.4502x faster
   neg-boolean                                        3.8375+-0.2435     ?      4.1198+-0.6790        ? might be 1.0736x slower
   negative-zero-divide                               0.4586+-0.0226     ?      0.4858+-0.0315        ? might be 1.0594x slower
   negative-zero-modulo                               0.5408+-0.1042            0.4666+-0.0500          might be 1.1590x faster
   negative-zero-negate                               0.4578+-0.0177     ?      0.5044+-0.1266        ? might be 1.1018x slower
   nested-function-parsing                           52.4802+-1.4949     ?     53.1787+-1.6923        ? might be 1.0133x slower
   new-array-buffer-dead                            119.3326+-5.0016          115.3158+-2.9104          might be 1.0348x faster
   new-array-buffer-push                              8.0227+-0.3564     ?      8.0550+-0.6948        ?
   new-array-dead                                    19.7980+-1.8895     ?     20.4668+-1.7634        ? might be 1.0338x slower
   new-array-push                                     6.3156+-1.0398     ?      6.6227+-1.7680        ? might be 1.0486x slower
   no-inline-constructor                             39.3162+-2.5647     ?     40.9858+-2.6176        ? might be 1.0425x slower
   number-test                                        3.3954+-0.0963     ?      4.0158+-0.9138        ? might be 1.1827x slower
   object-closure-call                                7.4893+-1.0145     ?      7.6503+-1.2372        ? might be 1.0215x slower
   object-test                                        3.5358+-0.3848            3.2967+-0.2672          might be 1.0725x faster
   obvious-sink-pathology-taken                     131.2562+-2.6446          131.0823+-2.9774        
   obvious-sink-pathology                            41.9166+-2.7490           37.8715+-2.3766          might be 1.1068x faster
   obviously-elidable-new-object                     41.5632+-9.6682           37.9131+-2.4700          might be 1.0963x faster
   plus-boolean-arith                                 3.1219+-0.2494     ?      3.5114+-0.5974        ? might be 1.1248x slower
   plus-boolean-double                                4.0791+-0.7021            3.9313+-0.5593          might be 1.0376x faster
   plus-boolean                                       3.1550+-0.1742     ?      3.2582+-0.4869        ? might be 1.0327x slower
   poly-chain-access-different-prototypes-simple   
                                                      3.6239+-0.5373            3.5352+-0.5711          might be 1.0251x faster
   poly-chain-access-different-prototypes             3.4258+-0.3624     ?      3.6167+-0.6555        ? might be 1.0557x slower
   poly-chain-access-simpler                          3.2759+-0.1953     ?      3.8593+-0.7411        ? might be 1.1781x slower
   poly-chain-access                                  3.6336+-0.6427            3.3856+-0.4205          might be 1.0733x faster
   poly-stricteq                                     65.7043+-2.8066           64.6046+-1.6136          might be 1.0170x faster
   polymorphic-array-call                             1.5191+-0.0781     ?      1.9288+-0.5096        ? might be 1.2697x slower
   polymorphic-get-by-id                              3.7117+-0.4279     ?      3.8253+-0.5602        ? might be 1.0306x slower
   polymorphic-put-by-id                             30.9391+-1.9131           28.9586+-1.0124          might be 1.0684x faster
   polymorphic-structure                             16.2760+-1.1001           15.0356+-0.6728          might be 1.0825x faster
   polyvariant-monomorphic-get-by-id                 11.9882+-3.0016           10.5973+-2.1037          might be 1.1312x faster
   proto-getter-access                               10.7909+-0.8131     ?     10.9121+-0.3497        ? might be 1.0112x slower
   put-by-id-replace-and-transition                  12.1792+-3.7843           10.0818+-1.0230          might be 1.2080x faster
   put-by-id-slightly-polymorphic                     3.6127+-0.6350     ?      3.6818+-0.5384        ? might be 1.0191x slower
   put-by-id                                         15.4365+-1.7110           14.8394+-0.8973          might be 1.0402x faster
   put-by-val-direct                                  0.4554+-0.0163     ?      0.5510+-0.1951        ? might be 1.2099x slower
   put-by-val-large-index-blank-indexing-type   
                                                      6.9276+-1.4780            6.2964+-0.2987          might be 1.1003x faster
   put-by-val-machine-int                             3.5801+-1.0090            3.5800+-1.0489        
   rare-osr-exit-on-local                            16.7810+-1.0061     ?     19.3292+-2.3701        ? might be 1.1518x slower
   register-pressure-from-osr                        19.9251+-1.1388     ?     20.5262+-1.8323        ? might be 1.0302x slower
   repeat-multi-get-by-offset                        24.6384+-1.3236     ?     25.5090+-1.3420        ? might be 1.0353x slower
   setter-prototype                                  10.1467+-0.7022     ?     10.6124+-0.9191        ? might be 1.0459x slower
   setter                                            10.3702+-2.4096            8.5017+-1.0099          might be 1.2198x faster
   simple-activation-demo                            31.6666+-1.5279           30.5257+-2.5322          might be 1.0374x faster
   simple-getter-access                              14.1857+-1.2871           13.9896+-1.0179          might be 1.0140x faster
   simple-poly-call-nested                           11.6313+-1.2572           11.4275+-0.9490          might be 1.0178x faster
   simple-poly-call                                   1.9476+-0.3178     ?      2.1544+-0.3415        ? might be 1.1061x slower
   sin-boolean                                       22.8802+-1.8671     ?     23.3559+-2.2800        ? might be 1.0208x slower
   singleton-scope                                   69.6582+-2.1552     ?     72.0809+-10.5902       ? might be 1.0348x slower
   sink-function                                     13.8252+-1.5340           13.3280+-0.6244          might be 1.0373x faster
   sink-huge-activation                              20.1568+-1.9793           20.0931+-2.8004        
   sinkable-new-object-dag                           71.8883+-4.2435           69.5264+-4.7627          might be 1.0340x faster
   sinkable-new-object-taken                         58.1786+-3.2766           53.0621+-2.3383          might be 1.0964x faster
   sinkable-new-object                               42.2274+-3.2275           41.4475+-3.2643          might be 1.0188x faster
   slow-array-profile-convergence                     3.2567+-0.2881     ?      3.2681+-0.6965        ?
   slow-convergence                                   3.1827+-0.3755            3.1164+-0.3555          might be 1.0213x faster
   slow-ternaries                                    22.2468+-3.1090           21.1529+-1.6497          might be 1.0517x faster
   sorting-benchmark                                 23.0539+-1.5801     ?     24.5531+-3.5066        ? might be 1.0650x slower
   sparse-conditional                                 2.0818+-0.6262            1.9067+-0.5387          might be 1.0919x faster
   splice-to-remove                                  15.0973+-0.8389     ?     15.3209+-1.1898        ? might be 1.0148x slower
   string-char-code-at                               16.2507+-1.0273     ?     18.0287+-3.5918        ? might be 1.1094x slower
   string-concat-object                               2.9637+-0.3589            2.8384+-0.2461          might be 1.0442x faster
   string-concat-pair-object                          2.9768+-0.6081            2.7581+-0.1019          might be 1.0793x faster
   string-concat-pair-simple                         12.2701+-0.6880     ?     12.7271+-1.7991        ? might be 1.0373x slower
   string-concat-simple                              13.4256+-1.8914           12.3635+-1.2296          might be 1.0859x faster
   string-cons-repeat                                 9.0182+-0.6097            8.7467+-0.9738          might be 1.0310x faster
   string-cons-tower                                  9.3907+-1.2447            9.3211+-0.7306        
   string-equality                                   22.0378+-2.5024     ?     22.5072+-1.5254        ? might be 1.0213x slower
   string-get-by-val-big-char                         9.0933+-0.6653     ?      9.5767+-1.6084        ? might be 1.0532x slower
   string-get-by-val-out-of-bounds-insane             3.7552+-0.2094     ?      4.2209+-0.6238        ? might be 1.1240x slower
   string-get-by-val-out-of-bounds                    5.9472+-1.1375            5.6396+-1.2327          might be 1.0546x faster
   string-get-by-val                                  4.2775+-0.8043            4.0179+-0.7219          might be 1.0646x faster
   string-hash                                        2.9662+-0.6404            2.5635+-0.2140          might be 1.1571x faster
   string-long-ident-equality                        18.5957+-1.2897           17.9845+-1.3679          might be 1.0340x faster
   string-out-of-bounds                              13.8291+-1.0544     ?     14.6154+-1.0221        ? might be 1.0569x slower
   string-repeat-arith                               30.5954+-0.8910     ?     31.8996+-1.6623        ? might be 1.0426x slower
   string-sub                                        40.4389+-0.9658           39.9894+-1.7412          might be 1.0112x faster
   string-test                                        3.5357+-0.3190            3.3853+-0.1459          might be 1.0444x faster
   string-var-equality                               34.6604+-1.1793           33.5125+-1.5620          might be 1.0343x faster
   structure-hoist-over-transitions                   3.3355+-0.5213            3.0807+-0.3825          might be 1.0827x faster
   substring-concat-weird                            46.1805+-1.6207     ?     46.3406+-2.7454        ?
   substring-concat                                  57.0645+-13.3429          53.4352+-6.9816          might be 1.0679x faster
   substring                                         57.6203+-2.0547           55.6892+-1.4337          might be 1.0347x faster
   switch-char-constant                               4.3092+-1.7710            3.1834+-0.1790          might be 1.3537x faster
   switch-char                                       11.0283+-1.4521           10.4748+-1.1642          might be 1.0528x faster
   switch-constant                                   10.9519+-2.2607            9.9019+-0.9154          might be 1.1060x faster
   switch-string-basic-big-var                       17.3214+-1.4664     ?     18.1223+-1.5923        ? might be 1.0462x slower
   switch-string-basic-big                           17.0872+-0.4456     ?     17.7165+-1.6952        ? might be 1.0368x slower
   switch-string-basic-var                           16.1556+-0.9378     ?     16.6256+-1.1177        ? might be 1.0291x slower
   switch-string-basic                               15.5796+-0.9208           15.3817+-1.1674          might be 1.0129x faster
   switch-string-big-length-tower-var                22.9624+-1.2374           22.5221+-1.6335          might be 1.0195x faster
   switch-string-length-tower-var                    19.2947+-4.4788           16.5537+-1.4153          might be 1.1656x faster
   switch-string-length-tower                        14.8631+-1.7186           14.1871+-0.8592          might be 1.0476x faster
   switch-string-short                               14.8657+-1.3236           13.8862+-0.5115          might be 1.0705x faster
   switch                                            15.0835+-2.3002     ?     15.5885+-2.1539        ? might be 1.0335x slower
   tear-off-arguments-simple                          4.5382+-1.0854            4.1415+-0.2787          might be 1.0958x faster
   tear-off-arguments                                 6.4166+-0.8333     ?      9.0220+-4.6615        ? might be 1.4060x slower
   temporal-structure                                14.8082+-1.6891           14.7939+-2.1990        
   to-int32-boolean                                  15.5916+-0.9812           15.2537+-0.5905          might be 1.0222x faster
   try-catch-get-by-val-cloned-arguments             11.9802+-0.8643     ?     13.0450+-1.5913        ? might be 1.0889x slower
   try-catch-get-by-val-direct-arguments              2.8929+-0.2201     ?      3.1169+-0.3813        ? might be 1.0775x slower
   try-catch-get-by-val-scoped-arguments              8.1305+-1.4487     ^      6.0885+-0.5280        ^ definitely 1.3354x faster
   typed-array-get-set-by-val-profiling              38.3729+-1.8562           37.6868+-2.7886          might be 1.0182x faster
   undefined-property-access                        266.0795+-5.2251     ?    270.9898+-12.9622       ? might be 1.0185x slower
   undefined-test                                     3.6747+-0.4429            3.5663+-0.3447          might be 1.0304x faster
   unprofiled-licm                                   11.1497+-0.5764     ?     11.6986+-1.6184        ? might be 1.0492x slower
   varargs-call                                      17.5866+-1.2784     ?     17.5916+-0.5779        ?
   varargs-construct-inline                          27.4853+-2.4368     ?     28.5149+-2.4999        ? might be 1.0375x slower
   varargs-construct                                 24.8192+-1.5740     ?     25.5864+-1.6675        ? might be 1.0309x slower
   varargs-inline                                    10.3187+-0.3045     ?     10.4608+-0.5664        ? might be 1.0138x slower
   varargs-strict-mode                               12.8903+-2.0868           11.3240+-0.5334          might be 1.1383x faster
   varargs                                           11.0105+-0.1867     ?     12.2509+-1.5407        ? might be 1.1127x slower
   weird-inlining-const-prop                          3.1506+-0.3918     ?      3.3766+-0.5321        ? might be 1.0717x slower

   <geometric>                                       10.3263+-0.0618     ?     10.3342+-0.0867        ? might be 1.0008x slower

                                                            og                      arrow                                       
Geomean of preferred means:
   <scaled-result>                                   33.7818+-0.5111     ?     34.1329+-0.3176        ? might be 1.0104x slower

[Filip Pizlo]

(In reply to comment #162)
> Perf seems okay. A tad bit noisy on a few benchmarks though.
> 
> VMs tested:
> "og" at /Users/saambarati/WK/Clean/WebKitBuild/Release/jsc (r193765)
> "arrow" at /Users/saambarati/WK/ternary/WebKitBuild/Release/jsc (r193766)
>     export JSC_useSamplingProfiler=1

Why are you turning on the sampling profiler?

Also, this doesn't do what you think.  This enables the sampling profiler in both "og" and "arrow" because environment variable settings are sticky.  If you really want to test enabling the sampling profiler, you should do JSC_useSamplingProfiler=0 for "ok".

> 
> Collected 8 samples per benchmark/VM, with 8 VM invocations per benchmark.
> Emitted a call to gc() between sample measurements.
> Used 1 benchmark iteration per VM invocation for warm-up. Used the
> jsc-specific preciseTime() function to get microsecond-level
> timing. Reporting benchmark execution times with 95% confidence intervals in
> milliseconds.
> 
>                                                             og              
> arrow                                       
> SunSpider:
>    3d-cube                                            5.5486+-0.3776     ?  
> 6.1588+-1.4880        ? might be 1.1100x slower
>    3d-morph                                           6.7723+-0.5524        
> 6.5086+-0.1315          might be 1.0405x faster
>    3d-raytrace                                        9.3464+-2.1256     ?  
> 10.1861+-4.4079        ? might be 1.0898x slower
>    access-binary-trees                                3.6955+-1.1855        
> 3.4952+-0.9042          might be 1.0573x faster
>    access-fannkuch                                    7.7849+-0.8594        
> 7.7361+-1.0548        
>    access-nbody                                       3.3492+-0.4328        
> 3.1038+-0.2850          might be 1.0791x faster
>    access-nsieve                                      3.8852+-0.1749     ?  
> 4.1947+-0.6992        ? might be 1.0797x slower
>    bitops-3bit-bits-in-byte                           1.7157+-0.2390     ?  
> 2.4620+-1.6877        ? might be 1.4350x slower
>    bitops-bits-in-byte                                4.7824+-0.3928        
> 4.4350+-0.4019          might be 1.0783x faster
>    bitops-bitwise-and                                 2.4158+-0.0954     ?  
> 2.5887+-0.3844        ? might be 1.0716x slower
>    bitops-nsieve-bits                                 3.8405+-0.5083     ?  
> 4.1218+-0.5889        ? might be 1.0732x slower
>    controlflow-recursive                              3.3475+-0.1065     ?  
> 3.9525+-0.7372        ? might be 1.1807x slower
>    crypto-aes                                         5.7680+-1.1998        
> 5.5320+-1.2805          might be 1.0427x faster
>    crypto-md5                                         3.6719+-0.4851     ?  
> 4.3861+-0.9448        ? might be 1.1945x slower
>    crypto-sha1                                        3.4907+-0.0351     !  
> 3.9138+-0.3680        ! definitely 1.1212x slower
>    date-format-tofte                                 10.4695+-0.3881     ?  
> 11.5784+-0.8405        ? might be 1.1059x slower
>    date-format-xparb                                  6.1061+-0.6993     ?  
> 6.4102+-0.8086        ? might be 1.0498x slower
>    math-cordic                                        4.6160+-0.9783     ?  
> 4.8223+-0.9542        ? might be 1.0447x slower
>    math-partial-sums                                  5.7780+-0.2839     ?  
> 5.7858+-0.3766        ?
>    math-spectral-norm                                 3.2014+-1.0684     ?  
> 3.4571+-0.9249        ? might be 1.0798x slower
>    regexp-dna                                         7.5759+-0.5813        
> 7.0899+-0.1348          might be 1.0686x faster
>    string-base64                                      5.3790+-0.4437     ?  
> 6.0667+-0.8667        ? might be 1.1279x slower
>    string-fasta                                       9.4520+-1.6485     ?  
> 9.7833+-1.3737        ? might be 1.0351x slower
>    string-tagcloud                                   10.2208+-0.6563     ?  
> 11.7310+-2.2655        ? might be 1.1478x slower
>    string-unpack-code                                24.7955+-2.5243     ?  
> 28.7615+-2.5959        ? might be 1.1599x slower
>    string-validate-input                              6.0537+-0.8694        
> 5.9535+-0.6086          might be 1.0168x faster
> 
>    <arithmetic>                                       6.2716+-0.1802     ?  
> 6.7006+-0.2872        ? might be 1.0684x slower

6% slower on SunSpider!  That's not ok.  If you can repro this in a second run then we should roll this out.

Also, you're seeing a tremendous amount of noise.

> 
>                                                             og              
> arrow                                       
> LongSpider:
>    3d-cube                                          979.6206+-12.9415    ?  
> 983.8770+-7.6640        ?
>    3d-morph                                        1867.6507+-10.6847    ?  
> 1875.8593+-19.7275       ?
>    3d-raytrace                                      744.7828+-9.5260     ?  
> 746.7947+-13.2296       ?
>    access-binary-trees                             1078.2459+-7.6618        
> 1067.1676+-5.1968          might be 1.0104x faster
>    access-fannkuch                                  384.0465+-43.1038       
> 363.1958+-6.3895          might be 1.0574x faster
>    access-nbody                                     644.0381+-12.3405       
> 641.1700+-5.2252        
>    access-nsieve                                    560.9791+-1.9321     !  
> 568.0314+-3.5764        ! definitely 1.0126x slower
>    bitops-3bit-bits-in-byte                          42.2215+-2.1880     ?  
> 43.2518+-1.5597        ? might be 1.0244x slower
>    bitops-bits-in-byte                               96.4558+-3.5735     ?  
> 100.8814+-11.8439       ? might be 1.0459x slower
>    bitops-nsieve-bits                               586.9264+-5.7668     ?  
> 587.7823+-9.1255        ?
>    controlflow-recursive                            557.2467+-9.5031        
> 554.5475+-7.7653        
>    crypto-aes                                       676.6859+-4.8312        
> 676.2295+-9.5004        
>    crypto-md5                                       595.0514+-7.1109     ?  
> 610.5173+-37.8467       ? might be 1.0260x slower
>    crypto-sha1                                      878.2572+-164.2451      
> 799.1692+-7.3824          might be 1.0990x faster
>    date-format-tofte                                680.3575+-5.7515     ?  
> 681.8051+-18.2792       ?
>    date-format-xparb                                776.8523+-10.6451    ?  
> 788.6069+-21.1484       ? might be 1.0151x slower
>    hash-map                                         188.7241+-3.8994        
> 185.0798+-3.9975          might be 1.0197x faster
>    math-cordic                                      607.3768+-8.5754     ?  
> 634.5539+-71.1293       ? might be 1.0447x slower
>    math-partial-sums                                571.6515+-6.3154     ?  
> 573.2576+-5.8824        ?
>    math-spectral-norm                               691.9677+-6.7637        
> 691.5540+-5.2446        
>    string-base64                                    444.7595+-2.8129        
> 443.5006+-4.6501        
>    string-fasta                                     441.8869+-2.5853        
> 439.5662+-3.7555        
>    string-tagcloud                                  218.1470+-11.6746       
> 212.4490+-2.7693          might be 1.0268x faster
> 
>    <geometric>                                      495.2857+-4.2478        
> 494.6303+-5.8083          might be 1.0013x faster
> 
>                                                             og              
> arrow                                       
> V8Spider:
>    crypto                                            94.2758+-4.1621     ?  
> 104.4034+-17.8815       ? might be 1.1074x slower
>    deltablue                                        128.1318+-5.5391     ?  
> 129.8629+-6.9113        ? might be 1.0135x slower
>    earley-boyer                                      80.5216+-7.3165        
> 77.0105+-6.5667          might be 1.0456x faster
>    raytrace                                          58.9718+-6.9031     ?  
> 65.5312+-15.6587       ? might be 1.1112x slower
>    regexp                                            77.8062+-2.4904        
> 76.6958+-3.0017          might be 1.0145x faster
>    richards                                          99.3256+-4.2371        
> 98.5087+-4.0453        
>    splay                                             63.6587+-4.3887        
> 62.8673+-4.6837          might be 1.0126x faster
> 
>    <geometric>                                       83.2690+-2.4624     ?  
> 84.5431+-3.2161        ? might be 1.0153x slower

V8Spider measures similar things to SunSpider.  It's noisy but it's interesting that this also sees a slow-down.

I never see noise on V8Spider runs.  Why is yours so noisy?

> 
>                                                             og              
> arrow                                       
> Octane:
>    encrypt                                           0.19165+-0.00365       
> 0.19029+-0.00518       
>    decrypt                                           3.58433+-0.03293    ?  
> 3.63544+-0.04199       ? might be 1.0143x slower
>    deltablue                                x2       0.16695+-0.00244       
> 0.16506+-0.00160         might be 1.0115x faster
>    earley                                            0.36065+-0.00174    ?  
> 0.36209+-0.00160       ?
>    boyer                                             5.51499+-0.06528    ?  
> 6.00535+-1.25312       ? might be 1.0889x slower
>    navier-stokes                            x2       6.01258+-0.07613       
> 5.98522+-0.06443       
>    raytrace                                 x2       1.06516+-0.01745    ?  
> 1.06660+-0.01788       ?
>    richards                                 x2       0.11028+-0.00195       
> 0.10828+-0.00086         might be 1.0186x faster
>    splay                                    x2       0.56531+-0.01233    ?  
> 0.57407+-0.00983       ? might be 1.0155x slower
>    regexp                                   x2      30.42811+-0.43184       
> 30.41776+-0.23783       
>    pdfjs                                    x2      45.86188+-0.91945    ?  
> 46.39565+-0.54838       ? might be 1.0116x slower
>    mandreel                                 x2      68.52068+-2.13330       
> 66.67114+-1.02211         might be 1.0277x faster
>    gbemu                                    x2      55.31618+-3.54668    ?  
> 56.20139+-3.38554       ? might be 1.0160x slower
>    closure                                           0.69902+-0.00645    ?  
> 0.69985+-0.00592       ?
>    jquery                                            9.31115+-0.09030       
> 9.22842+-0.07755       
>    box2d                                    x2      15.09213+-2.62887       
> 14.65425+-1.70357         might be 1.0299x faster
>    zlib                                     x2     477.69994+-12.42784      
> 477.31493+-11.55819      
>    typescript                               x2    1013.44379+-51.85526      
> 997.60849+-14.86373        might be 1.0159x faster
> 
>    <geometric>                                       7.21930+-0.13280       
> 7.20891+-0.06947         might be 1.0014x faster
> 
>                                                             og              
> arrow                                       
> Kraken:
>    ai-astar                                          158.360+-20.191        
> 148.433+-2.056           might be 1.0669x faster
>    audio-beat-detection                               57.754+-3.308      ?  
> 62.284+-12.044        ? might be 1.0784x slower
>    audio-dft                                         145.212+-24.168        
> 136.132+-2.022           might be 1.0667x faster
>    audio-fft                                          42.185+-1.458      ?  
> 44.726+-5.909         ? might be 1.0602x slower
>    audio-oscillator                                   69.004+-2.002      ?  
> 72.244+-2.573         ? might be 1.0469x slower
>    imaging-darkroom                                   74.577+-2.839         
> 72.167+-3.033           might be 1.0334x faster
>    imaging-desaturate                                 71.886+-3.510      ?  
> 72.630+-3.979         ? might be 1.0104x slower
>    imaging-gaussian-blur                             104.800+-3.349         
> 104.723+-2.226         
>    json-parse-financial                               48.685+-5.054      ?  
> 49.805+-4.713         ? might be 1.0230x slower
>    json-stringify-tinderbox                           30.644+-3.016      ?  
> 31.420+-4.706         ? might be 1.0253x slower
>    stanford-crypto-aes                                56.982+-3.034         
> 53.615+-2.909           might be 1.0628x faster
>    stanford-crypto-ccm                                49.070+-5.787      ?  
> 51.168+-7.458         ? might be 1.0427x slower
>    stanford-crypto-pbkdf2                            127.559+-21.382        
> 117.815+-3.032           might be 1.0827x faster
>    stanford-crypto-sha256-iterative                   44.168+-0.875      ?  
> 45.854+-1.524         ? might be 1.0382x slower
> 
>    <arithmetic>                                       77.206+-3.385         
> 75.930+-1.844           might be 1.0168x faster
> 
>                                                             og              
> arrow                                       
> JSRegress:
>    abc-forward-loop-equal                            37.2579+-2.3398        
> 35.7465+-1.0912          might be 1.0423x faster
>    abc-postfix-backward-loop                         38.4064+-6.7649        
> 35.9295+-1.9088          might be 1.0689x faster
>    abc-simple-backward-loop                          35.5298+-1.3557     ?  
> 35.9082+-1.2656        ? might be 1.0107x slower
>    abc-simple-forward-loop                           36.6216+-0.9619        
> 36.4425+-3.9351        
>    abc-skippy-loop                                   26.0396+-1.5759     ?  
> 28.4593+-8.1786        ? might be 1.0929x slower
>    abs-boolean                                        3.1456+-0.1699     ?  
> 3.5277+-0.6378        ? might be 1.1215x slower
>    adapt-to-double-divide                            20.5440+-3.4677        
> 19.6534+-1.0639          might be 1.0453x faster
>    aliased-arguments-getbyval                         1.4484+-0.1026     ?  
> 1.7911+-0.5195        ? might be 1.2366x slower
>    allocate-big-object                                3.4569+-0.7461     ?  
> 3.5705+-1.3345        ? might be 1.0328x slower
>    arguments-named-and-reflective                    17.0524+-8.7680        
> 13.8434+-1.6635          might be 1.2318x faster
>    arguments-out-of-bounds                           12.3063+-0.4771     ?  
> 13.1274+-1.1189        ? might be 1.0667x slower
>    arguments-strict-mode                             11.6178+-0.7198     ?  
> 12.5719+-1.2735        ? might be 1.0821x slower
>    arguments                                         10.2392+-0.5618        
> 9.8727+-0.1396          might be 1.0371x faster
>    arity-mismatch-inlining                            1.6434+-0.7833        
> 1.2252+-0.0868          might be 1.3414x faster
>    array-access-polymorphic-structure                 8.6277+-0.5405     ?  
> 9.1590+-1.3513        ? might be 1.0616x slower
>    array-nonarray-polymorhpic-access                 33.2805+-4.0321        
> 31.0485+-2.7368          might be 1.0719x faster
>    array-prototype-every                             93.0138+-4.0171     ?  
> 94.7696+-3.6091        ? might be 1.0189x slower
>    array-prototype-forEach                           94.0331+-4.6714     ?  
> 105.6436+-25.6265       ? might be 1.1235x slower
>    array-prototype-map                              101.9197+-4.8605     ?  
> 103.0874+-3.1996        ? might be 1.0115x slower
>    array-prototype-reduce                            90.3503+-4.7914     ?  
> 95.9212+-7.7394        ? might be 1.0617x slower
>    array-prototype-reduceRight                       97.0178+-8.0480        
> 92.3733+-6.7306          might be 1.0503x faster
>    array-prototype-some                              97.1310+-5.0248        
> 96.4595+-3.0243        
>    array-splice-contiguous                           28.6559+-1.9033        
> 27.7673+-1.5342          might be 1.0320x faster
>    array-with-double-add                              4.3314+-0.1927     ?  
> 4.3662+-0.2464        ?
>    array-with-double-increment                        4.5760+-0.7823        
> 3.9757+-0.2593          might be 1.1510x faster
>    array-with-double-mul-add                          6.6307+-1.2763        
> 6.1796+-1.4461          might be 1.0730x faster
>    array-with-double-sum                              4.2396+-0.6035        
> 4.0898+-0.3208          might be 1.0366x faster
>    array-with-int32-add-sub                           9.9673+-1.2296        
> 9.2478+-1.9793          might be 1.0778x faster
>    array-with-int32-or-double-sum                     4.3331+-0.4979     ?  
> 4.4148+-0.6502        ? might be 1.0189x slower
>    ArrayBuffer-DataView-alloc-large-long-lived   
>                                                      39.2668+-2.8121     ?  
> 40.1184+-2.6948        ? might be 1.0217x slower
>    ArrayBuffer-DataView-alloc-long-lived             15.9205+-1.2869        
> 15.4484+-1.2372          might be 1.0306x faster
>    ArrayBuffer-Int32Array-byteOffset                  4.5631+-0.3146        
> 4.2748+-0.1547          might be 1.0674x faster
>    ArrayBuffer-Int8Array-alloc-large-long-lived   
>                                                      39.9039+-2.2320        
> 38.2159+-2.6773          might be 1.0442x faster
>    ArrayBuffer-Int8Array-alloc-long-lived-buffer   
>                                                      25.4290+-2.0875        
> 24.6682+-1.5413          might be 1.0308x faster
>    ArrayBuffer-Int8Array-alloc-long-lived            14.1549+-0.8256     ?  
> 15.2833+-1.9873        ? might be 1.0797x slower
>    ArrayBuffer-Int8Array-alloc                       13.2227+-1.2507        
> 12.7815+-1.0694          might be 1.0345x faster
>    asmjs_bool_bug                                     9.2168+-0.6827        
> 9.1978+-0.5884        
>    assign-custom-setter-polymorphic                   2.8987+-0.1680     ?  
> 3.3512+-0.3783        ? might be 1.1561x slower
>    assign-custom-setter                               4.0440+-0.2516     ?  
> 4.3845+-0.7428        ? might be 1.0842x slower
>    basic-set                                         13.3817+-1.4564        
> 12.6051+-0.4201          might be 1.0616x faster
>    big-int-mul                                        5.3145+-1.0886        
> 5.0489+-1.2849          might be 1.0526x faster
>    boolean-test                                       4.4485+-1.6660        
> 3.4810+-0.1771          might be 1.2780x faster
>    branch-fold                                        4.4475+-0.2387     ?  
> 5.6894+-1.9361        ? might be 1.2792x slower
>    branch-on-string-as-boolean                       20.7794+-1.5399        
> 19.5341+-0.6242          might be 1.0638x faster
>    by-val-generic                                     2.9631+-0.2916     ?  
> 3.2131+-0.4442        ? might be 1.0844x slower
>    call-spread-apply                                 43.6687+-2.8071     ?  
> 44.6581+-3.4074        ? might be 1.0227x slower
>    call-spread-call                                  33.0528+-2.5648     ?  
> 34.2193+-2.9838        ? might be 1.0353x slower
>    captured-assignments                               0.6949+-0.2564        
> 0.5858+-0.0358          might be 1.1862x faster
>    cast-int-to-double                                 7.1781+-1.3036        
> 6.8158+-0.3286          might be 1.0532x faster
>    cell-argument                                      7.4037+-0.8052     ?  
> 7.4144+-0.8340        ?
>    cfg-simplify                                       3.5155+-0.4068     ?  
> 3.8013+-1.0554        ? might be 1.0813x slower
>    chain-getter-access                               10.5173+-0.1356     ?  
> 11.8623+-1.4680        ? might be 1.1279x slower
>    cmpeq-obj-to-obj-other                            18.6098+-3.6358        
> 16.4263+-2.2825          might be 1.1329x faster
>    constant-test                                      6.4961+-0.8532     ?  
> 6.6080+-0.4624        ? might be 1.0172x slower
>    create-lots-of-functions                          13.5147+-1.4590        
> 13.0828+-1.5589          might be 1.0330x faster
>    cse-new-array-buffer                               3.3037+-0.6428        
> 3.0935+-0.4439          might be 1.0679x faster
>    cse-new-array                                      3.2596+-0.4567        
> 3.1004+-0.3207          might be 1.0514x faster
>    DataView-custom-properties                        43.7892+-2.7348     ?  
> 44.6245+-2.8140        ? might be 1.0191x slower
>    deconstructing-parameters-overridden-by-function   
>                                                       0.6794+-0.1088        
> 0.6239+-0.0776          might be 1.0890x faster
>    delay-tear-off-arguments-strictmode               16.3296+-1.2392     ?  
> 17.3647+-1.6716        ? might be 1.0634x slower
>    deltablue-varargs                                240.0904+-21.3412       
> 233.3723+-5.2693          might be 1.0288x faster
>    destructuring-arguments                          196.9813+-4.8798        
> 196.6165+-3.5080        
>    destructuring-swap                                 6.6623+-0.4985     ?  
> 7.8062+-2.6722        ? might be 1.1717x slower
>    direct-arguments-getbyval                          1.6988+-0.5177        
> 1.4304+-0.1834          might be 1.1876x faster
>    div-boolean-double                                 6.3949+-0.6125        
> 6.0061+-0.1330          might be 1.0647x faster
>    div-boolean                                       10.0115+-1.6846        
> 9.6446+-0.3696          might be 1.0380x faster
>    double-get-by-val-out-of-bounds                    6.7544+-0.8453        
> 6.7137+-0.9961        
>    double-pollution-getbyval                          9.9826+-0.6310     ?  
> 10.2161+-0.6550        ? might be 1.0234x slower
>    double-pollution-putbyoffset                       4.5938+-0.4472     ?  
> 4.8499+-0.7388        ? might be 1.0558x slower
>    double-real-use                                   30.0794+-1.9350     ?  
> 30.5691+-1.7329        ? might be 1.0163x slower
>    double-to-int32-typed-array-no-inline              3.2495+-0.3063     ?  
> 3.2968+-0.4816        ? might be 1.0146x slower
>    double-to-int32-typed-array                        3.0900+-0.3486     ?  
> 3.1309+-0.2677        ? might be 1.0132x slower
>    double-to-uint32-typed-array-no-inline             3.6238+-0.4522        
> 3.4441+-0.4179          might be 1.0522x faster
>    double-to-uint32-typed-array                       3.7118+-0.8975        
> 3.0998+-0.3114          might be 1.1975x faster
>    elidable-new-object-dag                           45.8504+-2.7162        
> 45.1216+-2.4527          might be 1.0162x faster
>    elidable-new-object-roflcopter                    43.5858+-1.4398     ?  
> 43.9602+-1.1385        ?
>    elidable-new-object-then-call                     41.8176+-2.5375        
> 41.5889+-3.0084        
>    elidable-new-object-tree                          55.7389+-7.5940        
> 53.8633+-4.7310          might be 1.0348x faster
>    empty-string-plus-int                              7.2627+-1.4399        
> 7.0235+-1.4734          might be 1.0341x faster
>    emscripten-cube2hash                              43.2194+-6.3927        
> 39.4663+-1.6437          might be 1.0951x faster
>    exit-length-on-plain-object                       18.7541+-1.0626        
> 18.3673+-0.5603          might be 1.0211x faster
>    external-arguments-getbyval                        2.7480+-2.4020        
> 1.8173+-0.4893          might be 1.5121x faster
>    external-arguments-putbyval                        3.3431+-0.5308        
> 3.3301+-0.7049        
>    fixed-typed-array-storage-var-index                1.7029+-0.1506     ?  
> 1.9047+-0.4691        ? might be 1.1185x slower
>    fixed-typed-array-storage                          1.2867+-0.0313     ?  
> 2.1949+-1.0326        ? might be 1.7058x slower
>    Float32Array-matrix-mult                           5.2332+-0.4382        
> 5.0654+-0.3022          might be 1.0331x faster
>    Float32Array-to-Float64Array-set                  59.1094+-1.8590     ?  
> 60.0805+-2.2669        ? might be 1.0164x slower
>    Float64Array-alloc-long-lived                     84.8658+-4.4382     ?  
> 91.3128+-13.4277       ? might be 1.0760x slower
>    Float64Array-to-Int16Array-set                    75.3679+-3.0505     ?  
> 78.6457+-12.8880       ? might be 1.0435x slower
>    fold-double-to-int                                15.8759+-1.3497     ?  
> 16.0391+-1.7076        ? might be 1.0103x slower
>    fold-get-by-id-to-multi-get-by-offset-rare-int   
>                                                      16.4219+-1.6391        
> 16.3318+-3.9740        
>    fold-get-by-id-to-multi-get-by-offset             15.3993+-2.4073     ?  
> 17.4256+-3.3929        ? might be 1.1316x slower
>    fold-multi-get-by-offset-to-get-by-offset   
>                                                      13.5442+-2.9402     ?  
> 15.0516+-1.8716        ? might be 1.1113x slower
>    fold-multi-get-by-offset-to-poly-get-by-offset   
>                                                      13.3754+-1.9016     ?  
> 15.5807+-2.1758        ? might be 1.1649x slower
>    fold-multi-put-by-offset-to-poly-put-by-offset   
>                                                      16.3234+-2.2109        
> 14.7454+-2.5984          might be 1.1070x faster
>    fold-multi-put-by-offset-to-put-by-offset   
>                                                      16.5553+-2.3376        
> 14.1646+-1.1066          might be 1.1688x faster
>    fold-multi-put-by-offset-to-replace-or-transition-put-by-offset   
>                                                      16.0363+-1.9765     ?  
> 17.7013+-4.4254        ? might be 1.1038x slower
>    fold-put-by-id-to-multi-put-by-offset             17.2283+-1.5242     ?  
> 17.2981+-3.6472        ?
>    fold-put-structure                                13.7028+-2.9131     ?  
> 14.5268+-0.9158        ? might be 1.0601x slower
>    for-of-iterate-array-entries                      14.0406+-0.6858     ?  
> 16.5756+-4.1127        ? might be 1.1805x slower
>    for-of-iterate-array-keys                          5.3665+-1.3754        
> 5.2263+-1.0263          might be 1.0268x faster
>    for-of-iterate-array-values                        4.7393+-0.5649     ?  
> 4.9382+-0.6473        ? might be 1.0420x slower
>    fround                                            21.3670+-1.7628        
> 21.2838+-1.1406        
>    ftl-library-inlining-dataview                     69.2258+-3.0072     ?  
> 75.7873+-7.4709        ? might be 1.0948x slower
>    ftl-library-inlining                             104.1258+-17.0993       
> 94.6728+-3.0155          might be 1.0998x faster
>    function-dot-apply                                 2.9359+-0.4578        
> 2.9344+-0.2188        
>    function-test                                      3.4261+-0.4497        
> 3.3767+-0.2988          might be 1.0147x faster
>    function-with-eval                               101.8975+-3.0056     ?  
> 107.6019+-3.0544        ? might be 1.0560x slower
>    gcse-poly-get-less-obvious                        25.8231+-2.3331        
> 25.7687+-1.5290        
>    gcse-poly-get                                     28.8874+-1.7344        
> 28.3009+-1.1950          might be 1.0207x faster
>    gcse                                               4.9285+-0.9418        
> 4.6151+-0.3336          might be 1.0679x faster
>    get-by-id-bimorphic-check-structure-elimination-simple   
>                                                       3.4864+-0.3799        
> 3.4534+-0.2181        
>    get-by-id-bimorphic-check-structure-elimination   
>                                                       6.3324+-0.9037     ?  
> 6.4219+-0.8451        ? might be 1.0141x slower
>    get-by-id-chain-from-try-block                     3.5633+-0.6249        
> 3.3322+-0.4275          might be 1.0693x faster
>    get-by-id-check-structure-elimination              5.4746+-1.1774        
> 5.3190+-0.7651          might be 1.0293x faster
>    get-by-id-proto-or-self                           20.8489+-1.4950     ?  
> 21.8380+-2.0444        ? might be 1.0474x slower
>    get-by-id-quadmorphic-check-structure-elimination-simple   
>                                                       4.3014+-0.8478        
> 3.9215+-0.7883          might be 1.0969x faster
>    get-by-id-self-or-proto                           20.5865+-1.9381     ?  
> 20.8556+-1.7183        ? might be 1.0131x slower
>    get-by-val-out-of-bounds                           6.3422+-0.7075     ?  
> 6.5540+-0.4376        ? might be 1.0334x slower
>    get_callee_monomorphic                             5.3254+-1.6598        
> 5.0698+-1.7555          might be 1.0504x faster
>    get_callee_polymorphic                             4.4986+-0.4603        
> 3.9905+-0.2309          might be 1.1273x faster
>    getter-no-activation                               6.0191+-0.6340     ?  
> 6.4662+-0.9116        ? might be 1.0743x slower
>    getter-prototype                                  10.2050+-0.3790     ?  
> 10.5055+-1.0068        ? might be 1.0295x slower
>    getter-richards                                  201.9159+-12.7781       
> 197.1846+-3.1066          might be 1.0240x faster
>    getter                                             9.5755+-1.1654        
> 8.3142+-0.8070          might be 1.1517x faster
>    global-var-const-infer-fire-from-opt               0.9047+-0.0348     ?  
> 1.4013+-0.4646        ? might be 1.5489x slower
>    global-var-const-infer                             0.8293+-0.0577     ?  
> 0.8658+-0.0876        ? might be 1.0440x slower
>    HashMap-put-get-iterate-keys                      49.9581+-9.3407        
> 48.1003+-4.4557          might be 1.0386x faster
>    HashMap-put-get-iterate                           51.8194+-2.7933        
> 50.6197+-3.5713          might be 1.0237x faster
>    HashMap-string-put-get-iterate                    38.2748+-1.9891     ?  
> 42.6238+-3.8388        ? might be 1.1136x slower
>    hoist-make-rope                                   12.5659+-0.8705     ?  
> 12.6675+-1.6290        ?
>    hoist-poly-check-structure-effectful-loop   
>                                                       4.7118+-0.5956        
> 4.6806+-0.5861        
>    hoist-poly-check-structure                         3.9561+-0.4244     ?  
> 4.2675+-0.7336        ? might be 1.0787x slower
>    imul-double-only                                   9.9329+-1.7565        
> 9.8946+-1.1923        
>    imul-int-only                                     10.0328+-1.3524        
> 10.0313+-1.0619        
>    imul-mixed                                         8.0088+-0.6250     ?  
> 8.4963+-1.2590        ? might be 1.0609x slower
>    in-four-cases                                     24.7942+-2.2616     ?  
> 28.0699+-4.7857        ? might be 1.1321x slower
>    in-one-case-false                                 16.5529+-1.1108        
> 15.4301+-1.6122          might be 1.0728x faster
>    in-one-case-true                                  16.3685+-1.9449     ?  
> 17.4533+-3.6025        ? might be 1.0663x slower
>    in-two-cases                                      15.4241+-0.9138     ?  
> 16.7668+-0.8443        ? might be 1.0870x slower
>    indexed-properties-in-objects                      3.9228+-0.5768     ?  
> 4.7503+-2.6804        ? might be 1.2109x slower
>    infer-closure-const-then-mov-no-inline             7.0280+-1.3573        
> 5.8040+-1.3924          might be 1.2109x faster
>    infer-closure-const-then-mov                      21.5053+-3.3825        
> 21.2701+-1.7546          might be 1.0111x faster
>    infer-closure-const-then-put-to-scope-no-inline   
>                                                      13.7957+-0.9999        
> 12.8392+-0.5734          might be 1.0745x faster
>    infer-closure-const-then-put-to-scope             27.0936+-0.7978        
> 26.8879+-1.1094        
>    infer-closure-const-then-reenter-no-inline   
>                                                      59.3963+-7.4071        
> 55.9055+-4.1013          might be 1.0624x faster
>    infer-closure-const-then-reenter                  27.5713+-1.0826        
> 27.4870+-1.0522        
>    infer-constant-global-property                     4.1000+-0.2353     ?  
> 4.3567+-0.9074        ? might be 1.0626x slower
>    infer-constant-property                            3.3316+-0.3537     ?  
> 3.8195+-0.9738        ? might be 1.1464x slower
>    infer-one-time-closure-ten-vars                    9.6924+-0.7754        
> 9.3388+-0.5829          might be 1.0379x faster
>    infer-one-time-closure-two-vars                    9.0012+-0.9003     ?  
> 9.5344+-0.7486        ? might be 1.0592x slower
>    infer-one-time-closure                             9.4675+-1.3114        
> 8.2992+-0.3492          might be 1.1408x faster
>    infer-one-time-deep-closure                       13.3735+-0.5226     ?  
> 13.6130+-1.8708        ? might be 1.0179x slower
>    inline-arguments-access                            5.2063+-0.5288     ?  
> 6.1911+-1.9950        ? might be 1.1891x slower
>    inline-arguments-aliased-access                    5.4153+-0.9304        
> 5.3040+-0.5668          might be 1.0210x faster
>    inline-arguments-local-escape                      5.5848+-0.7107        
> 5.5738+-0.5697        
>    inline-get-scoped-var                              9.0743+-3.7312        
> 6.1892+-0.5828          might be 1.4662x faster
>    inlined-put-by-id-transition                      14.2269+-1.8896     ?  
> 14.6714+-1.5965        ? might be 1.0312x slower
>    int-or-other-abs-then-get-by-val                   6.5051+-1.0603     ?  
> 6.8251+-1.1843        ? might be 1.0492x slower
>    int-or-other-abs-zero-then-get-by-val             19.3748+-1.3415        
> 18.6546+-0.9527          might be 1.0386x faster
>    int-or-other-add-then-get-by-val                   6.1991+-1.2500        
> 6.0734+-1.0100          might be 1.0207x faster
>    int-or-other-add                                   6.8814+-0.4687     ?  
> 7.1674+-1.5134        ? might be 1.0416x slower
>    int-or-other-div-then-get-by-val                   5.5648+-0.9681        
> 5.4134+-0.7751          might be 1.0280x faster
>    int-or-other-max-then-get-by-val                   5.9802+-2.2235        
> 5.0877+-0.9310          might be 1.1754x faster
>    int-or-other-min-then-get-by-val                   4.8323+-0.8217     ?  
> 5.4706+-1.1039        ? might be 1.1321x slower
>    int-or-other-mod-then-get-by-val                   4.5843+-0.5839     ?  
> 5.5934+-1.9680        ? might be 1.2201x slower
>    int-or-other-mul-then-get-by-val                   4.8411+-1.1100     ?  
> 5.4257+-2.3754        ? might be 1.1208x slower
>    int-or-other-neg-then-get-by-val                   6.2528+-0.5724     ?  
> 6.3528+-1.0423        ? might be 1.0160x slower
>    int-or-other-neg-zero-then-get-by-val             19.3617+-0.5449     ?  
> 19.4342+-2.1737        ?
>    int-or-other-sub-then-get-by-val                   7.1858+-1.0083        
> 6.8348+-1.6533          might be 1.0514x faster
>    int-or-other-sub                                   4.4160+-0.8960     ?  
> 5.6829+-1.7405        ? might be 1.2869x slower
>    int-overflow-local                                 5.8922+-1.0411     ?  
> 6.0024+-0.7940        ? might be 1.0187x slower
>    Int16Array-alloc-long-lived                       60.6396+-1.9842     ?  
> 62.9409+-3.1944        ? might be 1.0380x slower
>    Int16Array-bubble-sort-with-byteLength            26.9279+-1.7888     ?  
> 27.8375+-1.9868        ? might be 1.0338x slower
>    Int16Array-bubble-sort                            26.7879+-2.4825     ?  
> 27.2955+-4.0658        ? might be 1.0189x slower
>    Int16Array-load-int-mul                            2.4442+-0.7363        
> 2.3841+-0.9629          might be 1.0252x faster
>    Int16Array-to-Int32Array-set                      54.7574+-2.4504     ?  
> 55.6938+-3.4496        ? might be 1.0171x slower
>    Int32Array-alloc-large                            13.7660+-0.9221     ?  
> 15.5786+-2.3366        ? might be 1.1317x slower
>    Int32Array-alloc-long-lived                       71.8069+-2.9273        
> 71.1467+-1.1266        
>    Int32Array-alloc                                   3.5486+-0.1001     ?  
> 3.8785+-0.5284        ? might be 1.0930x slower
>    Int32Array-Int8Array-view-alloc                    7.7768+-1.1584        
> 7.0909+-0.2946          might be 1.0967x faster
>    int52-spill                                        6.8822+-1.1863     ?  
> 7.8849+-1.1672        ? might be 1.1457x slower
>    Int8Array-alloc-long-lived                        54.7040+-3.2661     ?  
> 55.7315+-3.9118        ? might be 1.0188x slower
>    Int8Array-load-with-byteLength                     4.5692+-0.6880        
> 4.3046+-0.4991          might be 1.0615x faster
>    Int8Array-load                                     4.8325+-1.7270        
> 4.0877+-0.1485          might be 1.1822x faster
>    integer-divide                                    12.4633+-1.0606     ?  
> 13.3499+-1.6024        ? might be 1.0711x slower
>    integer-modulo                                     2.2004+-0.5812     ?  
> 3.0005+-0.3615        ? might be 1.3636x slower
>    is-boolean-fold-tricky                             4.5012+-0.2893     ?  
> 4.5383+-0.3627        ?
>    is-boolean-fold                                    3.6093+-0.3428        
> 3.3966+-0.2772          might be 1.0626x faster
>    is-function-fold-tricky-internal-function   
>                                                      12.4520+-1.6358     ?  
> 12.8837+-1.5570        ? might be 1.0347x slower
>    is-function-fold-tricky                            5.8409+-1.5565        
> 5.0497+-0.6861          might be 1.1567x faster
>    is-function-fold                                   3.8815+-0.7866        
> 3.5265+-0.4044          might be 1.1007x faster
>    is-number-fold-tricky                              5.1023+-0.8659     ?  
> 5.2931+-0.8870        ? might be 1.0374x slower
>    is-number-fold                                     3.3299+-0.2084        
> 3.2468+-0.1569          might be 1.0256x faster
>    is-object-or-null-fold-functions                   3.6634+-0.8199        
> 3.2487+-0.0762          might be 1.1276x faster
>    is-object-or-null-fold-less-tricky                 5.2957+-0.6472     ?  
> 5.3200+-0.6984        ?
>    is-object-or-null-fold-tricky                      6.5538+-1.3269        
> 6.4363+-1.2027          might be 1.0183x faster
>    is-object-or-null-fold                             3.4477+-0.3634        
> 3.4066+-0.2580          might be 1.0121x faster
>    is-object-or-null-trickier-function                5.2358+-1.0067     ?  
> 5.5409+-0.8448        ? might be 1.0583x slower
>    is-object-or-null-trickier-internal-function   
>                                                      13.9175+-3.5380        
> 13.2418+-2.0966          might be 1.0510x faster
>    is-object-or-null-tricky-function                  5.4054+-0.9216        
> 5.2749+-0.7598          might be 1.0247x faster
>    is-object-or-null-tricky-internal-function   
>                                                      11.6495+-3.0602        
> 10.7815+-1.8177          might be 1.0805x faster
>    is-string-fold-tricky                              4.4926+-0.0891     ?  
> 5.0273+-0.8342        ? might be 1.1190x slower
>    is-string-fold                                     3.2773+-0.1458     ?  
> 3.8502+-0.8579        ? might be 1.1748x slower
>    is-undefined-fold-tricky                           5.0959+-1.6424        
> 4.6981+-0.8968          might be 1.0847x faster
>    is-undefined-fold                                  3.4615+-0.3501        
> 3.4347+-0.2692        
>    large-int-captured                                 5.5484+-0.7128     ?  
> 6.7182+-1.5821        ? might be 1.2108x slower
>    large-int-neg                                     17.2491+-1.2234     ?  
> 18.0859+-1.8745        ? might be 1.0485x slower
>    large-int                                         16.2925+-0.7841        
> 15.8744+-1.0113          might be 1.0263x faster
>    load-varargs-elimination                          26.5208+-4.9690        
> 24.4740+-1.1209          might be 1.0836x faster
>    logical-not-weird-types                            4.0546+-0.3700     ?  
> 4.8073+-1.0364        ? might be 1.1856x slower
>    logical-not                                        6.6178+-1.0384        
> 6.5918+-0.8072        
>    lots-of-fields                                    12.0117+-1.1511     ?  
> 12.5003+-1.6432        ? might be 1.0407x slower
>    make-indexed-storage                               3.6068+-0.1934     ?  
> 4.0336+-0.8168        ? might be 1.1183x slower
>    make-rope-cse                                      5.0674+-0.4251     ?  
> 5.3017+-0.9595        ? might be 1.0462x slower
>    marsaglia-larger-ints                             40.3790+-3.3904        
> 37.7698+-1.7711          might be 1.0691x faster
>    marsaglia-osr-entry                               25.6728+-1.6537     ?  
> 26.2175+-1.4756        ? might be 1.0212x slower
>    math-with-out-of-bounds-array-values              27.4670+-2.2391        
> 25.4466+-1.5306          might be 1.0794x faster
>    max-boolean                                        3.5387+-0.6257        
> 3.1871+-0.1961          might be 1.1103x faster
>    method-on-number                                  21.2495+-4.1046        
> 19.5970+-1.3532          might be 1.0843x faster
>    min-boolean                                        3.5667+-0.4092     ?  
> 4.0263+-0.7557        ? might be 1.1288x slower
>    minus-boolean-double                               3.7137+-0.1919        
> 3.6678+-0.2161          might be 1.0125x faster
>    minus-boolean                                      3.4976+-0.6851        
> 3.2144+-0.4545          might be 1.0881x faster
>    misc-strict-eq                                    34.6359+-1.6161     ?  
> 36.2059+-3.3835        ? might be 1.0453x slower
>    mod-boolean-double                                12.7856+-0.2986     ?  
> 13.1305+-0.4317        ? might be 1.0270x slower
>    mod-boolean                                        9.7702+-0.3897        
> 9.5118+-0.2316          might be 1.0272x faster
>    mul-boolean-double                                 4.1799+-0.1579     ?  
> 4.3141+-0.4004        ? might be 1.0321x slower
>    mul-boolean                                        5.0107+-3.6920        
> 3.4553+-0.3305          might be 1.4502x faster
>    neg-boolean                                        3.8375+-0.2435     ?  
> 4.1198+-0.6790        ? might be 1.0736x slower
>    negative-zero-divide                               0.4586+-0.0226     ?  
> 0.4858+-0.0315        ? might be 1.0594x slower
>    negative-zero-modulo                               0.5408+-0.1042        
> 0.4666+-0.0500          might be 1.1590x faster
>    negative-zero-negate                               0.4578+-0.0177     ?  
> 0.5044+-0.1266        ? might be 1.1018x slower
>    nested-function-parsing                           52.4802+-1.4949     ?  
> 53.1787+-1.6923        ? might be 1.0133x slower
>    new-array-buffer-dead                            119.3326+-5.0016        
> 115.3158+-2.9104          might be 1.0348x faster
>    new-array-buffer-push                              8.0227+-0.3564     ?  
> 8.0550+-0.6948        ?
>    new-array-dead                                    19.7980+-1.8895     ?  
> 20.4668+-1.7634        ? might be 1.0338x slower
>    new-array-push                                     6.3156+-1.0398     ?  
> 6.6227+-1.7680        ? might be 1.0486x slower
>    no-inline-constructor                             39.3162+-2.5647     ?  
> 40.9858+-2.6176        ? might be 1.0425x slower
>    number-test                                        3.3954+-0.0963     ?  
> 4.0158+-0.9138        ? might be 1.1827x slower
>    object-closure-call                                7.4893+-1.0145     ?  
> 7.6503+-1.2372        ? might be 1.0215x slower
>    object-test                                        3.5358+-0.3848        
> 3.2967+-0.2672          might be 1.0725x faster
>    obvious-sink-pathology-taken                     131.2562+-2.6446        
> 131.0823+-2.9774        
>    obvious-sink-pathology                            41.9166+-2.7490        
> 37.8715+-2.3766          might be 1.1068x faster
>    obviously-elidable-new-object                     41.5632+-9.6682        
> 37.9131+-2.4700          might be 1.0963x faster
>    plus-boolean-arith                                 3.1219+-0.2494     ?  
> 3.5114+-0.5974        ? might be 1.1248x slower
>    plus-boolean-double                                4.0791+-0.7021        
> 3.9313+-0.5593          might be 1.0376x faster
>    plus-boolean                                       3.1550+-0.1742     ?  
> 3.2582+-0.4869        ? might be 1.0327x slower
>    poly-chain-access-different-prototypes-simple   
>                                                       3.6239+-0.5373        
> 3.5352+-0.5711          might be 1.0251x faster
>    poly-chain-access-different-prototypes             3.4258+-0.3624     ?  
> 3.6167+-0.6555        ? might be 1.0557x slower
>    poly-chain-access-simpler                          3.2759+-0.1953     ?  
> 3.8593+-0.7411        ? might be 1.1781x slower
>    poly-chain-access                                  3.6336+-0.6427        
> 3.3856+-0.4205          might be 1.0733x faster
>    poly-stricteq                                     65.7043+-2.8066        
> 64.6046+-1.6136          might be 1.0170x faster
>    polymorphic-array-call                             1.5191+-0.0781     ?  
> 1.9288+-0.5096        ? might be 1.2697x slower
>    polymorphic-get-by-id                              3.7117+-0.4279     ?  
> 3.8253+-0.5602        ? might be 1.0306x slower
>    polymorphic-put-by-id                             30.9391+-1.9131        
> 28.9586+-1.0124          might be 1.0684x faster
>    polymorphic-structure                             16.2760+-1.1001        
> 15.0356+-0.6728          might be 1.0825x faster
>    polyvariant-monomorphic-get-by-id                 11.9882+-3.0016        
> 10.5973+-2.1037          might be 1.1312x faster
>    proto-getter-access                               10.7909+-0.8131     ?  
> 10.9121+-0.3497        ? might be 1.0112x slower
>    put-by-id-replace-and-transition                  12.1792+-3.7843        
> 10.0818+-1.0230          might be 1.2080x faster
>    put-by-id-slightly-polymorphic                     3.6127+-0.6350     ?  
> 3.6818+-0.5384        ? might be 1.0191x slower
>    put-by-id                                         15.4365+-1.7110        
> 14.8394+-0.8973          might be 1.0402x faster
>    put-by-val-direct                                  0.4554+-0.0163     ?  
> 0.5510+-0.1951        ? might be 1.2099x slower
>    put-by-val-large-index-blank-indexing-type   
>                                                       6.9276+-1.4780        
> 6.2964+-0.2987          might be 1.1003x faster
>    put-by-val-machine-int                             3.5801+-1.0090        
> 3.5800+-1.0489        
>    rare-osr-exit-on-local                            16.7810+-1.0061     ?  
> 19.3292+-2.3701        ? might be 1.1518x slower
>    register-pressure-from-osr                        19.9251+-1.1388     ?  
> 20.5262+-1.8323        ? might be 1.0302x slower
>    repeat-multi-get-by-offset                        24.6384+-1.3236     ?  
> 25.5090+-1.3420        ? might be 1.0353x slower
>    setter-prototype                                  10.1467+-0.7022     ?  
> 10.6124+-0.9191        ? might be 1.0459x slower
>    setter                                            10.3702+-2.4096        
> 8.5017+-1.0099          might be 1.2198x faster
>    simple-activation-demo                            31.6666+-1.5279        
> 30.5257+-2.5322          might be 1.0374x faster
>    simple-getter-access                              14.1857+-1.2871        
> 13.9896+-1.0179          might be 1.0140x faster
>    simple-poly-call-nested                           11.6313+-1.2572        
> 11.4275+-0.9490          might be 1.0178x faster
>    simple-poly-call                                   1.9476+-0.3178     ?  
> 2.1544+-0.3415        ? might be 1.1061x slower
>    sin-boolean                                       22.8802+-1.8671     ?  
> 23.3559+-2.2800        ? might be 1.0208x slower
>    singleton-scope                                   69.6582+-2.1552     ?  
> 72.0809+-10.5902       ? might be 1.0348x slower
>    sink-function                                     13.8252+-1.5340        
> 13.3280+-0.6244          might be 1.0373x faster
>    sink-huge-activation                              20.1568+-1.9793        
> 20.0931+-2.8004        
>    sinkable-new-object-dag                           71.8883+-4.2435        
> 69.5264+-4.7627          might be 1.0340x faster
>    sinkable-new-object-taken                         58.1786+-3.2766        
> 53.0621+-2.3383          might be 1.0964x faster
>    sinkable-new-object                               42.2274+-3.2275        
> 41.4475+-3.2643          might be 1.0188x faster
>    slow-array-profile-convergence                     3.2567+-0.2881     ?  
> 3.2681+-0.6965        ?
>    slow-convergence                                   3.1827+-0.3755        
> 3.1164+-0.3555          might be 1.0213x faster
>    slow-ternaries                                    22.2468+-3.1090        
> 21.1529+-1.6497          might be 1.0517x faster
>    sorting-benchmark                                 23.0539+-1.5801     ?  
> 24.5531+-3.5066        ? might be 1.0650x slower
>    sparse-conditional                                 2.0818+-0.6262        
> 1.9067+-0.5387          might be 1.0919x faster
>    splice-to-remove                                  15.0973+-0.8389     ?  
> 15.3209+-1.1898        ? might be 1.0148x slower
>    string-char-code-at                               16.2507+-1.0273     ?  
> 18.0287+-3.5918        ? might be 1.1094x slower
>    string-concat-object                               2.9637+-0.3589        
> 2.8384+-0.2461          might be 1.0442x faster
>    string-concat-pair-object                          2.9768+-0.6081        
> 2.7581+-0.1019          might be 1.0793x faster
>    string-concat-pair-simple                         12.2701+-0.6880     ?  
> 12.7271+-1.7991        ? might be 1.0373x slower
>    string-concat-simple                              13.4256+-1.8914        
> 12.3635+-1.2296          might be 1.0859x faster
>    string-cons-repeat                                 9.0182+-0.6097        
> 8.7467+-0.9738          might be 1.0310x faster
>    string-cons-tower                                  9.3907+-1.2447        
> 9.3211+-0.7306        
>    string-equality                                   22.0378+-2.5024     ?  
> 22.5072+-1.5254        ? might be 1.0213x slower
>    string-get-by-val-big-char                         9.0933+-0.6653     ?  
> 9.5767+-1.6084        ? might be 1.0532x slower
>    string-get-by-val-out-of-bounds-insane             3.7552+-0.2094     ?  
> 4.2209+-0.6238        ? might be 1.1240x slower
>    string-get-by-val-out-of-bounds                    5.9472+-1.1375        
> 5.6396+-1.2327          might be 1.0546x faster
>    string-get-by-val                                  4.2775+-0.8043        
> 4.0179+-0.7219          might be 1.0646x faster
>    string-hash                                        2.9662+-0.6404        
> 2.5635+-0.2140          might be 1.1571x faster
>    string-long-ident-equality                        18.5957+-1.2897        
> 17.9845+-1.3679          might be 1.0340x faster
>    string-out-of-bounds                              13.8291+-1.0544     ?  
> 14.6154+-1.0221        ? might be 1.0569x slower
>    string-repeat-arith                               30.5954+-0.8910     ?  
> 31.8996+-1.6623        ? might be 1.0426x slower
>    string-sub                                        40.4389+-0.9658        
> 39.9894+-1.7412          might be 1.0112x faster
>    string-test                                        3.5357+-0.3190        
> 3.3853+-0.1459          might be 1.0444x faster
>    string-var-equality                               34.6604+-1.1793        
> 33.5125+-1.5620          might be 1.0343x faster
>    structure-hoist-over-transitions                   3.3355+-0.5213        
> 3.0807+-0.3825          might be 1.0827x faster
>    substring-concat-weird                            46.1805+-1.6207     ?  
> 46.3406+-2.7454        ?
>    substring-concat                                  57.0645+-13.3429       
> 53.4352+-6.9816          might be 1.0679x faster
>    substring                                         57.6203+-2.0547        
> 55.6892+-1.4337          might be 1.0347x faster
>    switch-char-constant                               4.3092+-1.7710        
> 3.1834+-0.1790          might be 1.3537x faster
>    switch-char                                       11.0283+-1.4521        
> 10.4748+-1.1642          might be 1.0528x faster
>    switch-constant                                   10.9519+-2.2607        
> 9.9019+-0.9154          might be 1.1060x faster
>    switch-string-basic-big-var                       17.3214+-1.4664     ?  
> 18.1223+-1.5923        ? might be 1.0462x slower
>    switch-string-basic-big                           17.0872+-0.4456     ?  
> 17.7165+-1.6952        ? might be 1.0368x slower
>    switch-string-basic-var                           16.1556+-0.9378     ?  
> 16.6256+-1.1177        ? might be 1.0291x slower
>    switch-string-basic                               15.5796+-0.9208        
> 15.3817+-1.1674          might be 1.0129x faster
>    switch-string-big-length-tower-var                22.9624+-1.2374        
> 22.5221+-1.6335          might be 1.0195x faster
>    switch-string-length-tower-var                    19.2947+-4.4788        
> 16.5537+-1.4153          might be 1.1656x faster
>    switch-string-length-tower                        14.8631+-1.7186        
> 14.1871+-0.8592          might be 1.0476x faster
>    switch-string-short                               14.8657+-1.3236        
> 13.8862+-0.5115          might be 1.0705x faster
>    switch                                            15.0835+-2.3002     ?  
> 15.5885+-2.1539        ? might be 1.0335x slower
>    tear-off-arguments-simple                          4.5382+-1.0854        
> 4.1415+-0.2787          might be 1.0958x faster
>    tear-off-arguments                                 6.4166+-0.8333     ?  
> 9.0220+-4.6615        ? might be 1.4060x slower
>    temporal-structure                                14.8082+-1.6891        
> 14.7939+-2.1990        
>    to-int32-boolean                                  15.5916+-0.9812        
> 15.2537+-0.5905          might be 1.0222x faster
>    try-catch-get-by-val-cloned-arguments             11.9802+-0.8643     ?  
> 13.0450+-1.5913        ? might be 1.0889x slower
>    try-catch-get-by-val-direct-arguments              2.8929+-0.2201     ?  
> 3.1169+-0.3813        ? might be 1.0775x slower
>    try-catch-get-by-val-scoped-arguments              8.1305+-1.4487     ^  
> 6.0885+-0.5280        ^ definitely 1.3354x faster
>    typed-array-get-set-by-val-profiling              38.3729+-1.8562        
> 37.6868+-2.7886          might be 1.0182x faster
>    undefined-property-access                        266.0795+-5.2251     ?  
> 270.9898+-12.9622       ? might be 1.0185x slower
>    undefined-test                                     3.6747+-0.4429        
> 3.5663+-0.3447          might be 1.0304x faster
>    unprofiled-licm                                   11.1497+-0.5764     ?  
> 11.6986+-1.6184        ? might be 1.0492x slower
>    varargs-call                                      17.5866+-1.2784     ?  
> 17.5916+-0.5779        ?
>    varargs-construct-inline                          27.4853+-2.4368     ?  
> 28.5149+-2.4999        ? might be 1.0375x slower
>    varargs-construct                                 24.8192+-1.5740     ?  
> 25.5864+-1.6675        ? might be 1.0309x slower
>    varargs-inline                                    10.3187+-0.3045     ?  
> 10.4608+-0.5664        ? might be 1.0138x slower
>    varargs-strict-mode                               12.8903+-2.0868        
> 11.3240+-0.5334          might be 1.1383x faster
>    varargs                                           11.0105+-0.1867     ?  
> 12.2509+-1.5407        ? might be 1.1127x slower
>    weird-inlining-const-prop                          3.1506+-0.3918     ?  
> 3.3766+-0.5321        ? might be 1.0717x slower
> 
>    <geometric>                                       10.3263+-0.0618     ?  
> 10.3342+-0.0867        ? might be 1.0008x slower
> 
>                                                             og              
> arrow                                       
> Geomean of preferred means:
>    <scaled-result>                                   33.7818+-0.5111     ?  
> 34.1329+-0.3176        ? might be 1.0104x slower

[Filip Pizlo]

(In reply to comment #160)
> (In reply to comment #159)
> > (In reply to comment #158)
> > > (In reply to comment #157)
> > > > (In reply to comment #156)
> > > > > (In reply to comment #155)
> > > > > > (In reply to comment #154)
> > > > > > > Did anyone run performance tests on this?
> > > > > > 
> > > > > > https://bugs.webkit.org/attachment.cgi?id=265179
> > > > > 
> > > > > That's in debug mode.  Debug mode performance numbers are not meaningful.
> > > > > 
> > > > > We should make sure to do release mode performance testing of patches like
> > > > > this.
> > > > 
> > > > I didn't run the tests so I don't know for sure but the results text result
> > > > looks like a release build. What made you say it was Debug?
> > > 
> > > The performance is very bad in absolute terms.
> > > 
> > > I also just noticed that the performance numbers are super noisy.
> > > 
> > > Either way, someone needs to run independent performance numbers on this
> > > because these don't look right.
> > 
> > I'll run them tonight.
> 
> When measuring perf in Linux, I can see these noisy result.
> On the other hand, when executing it in OSX with exactly the same
> run-jsc-benchmarks cmd,
> I can get somewhat solid result. So usually I measure perf on OSX machine.
> (In Linux, I ensured that cpu freq is fixed as "performance" mode, not
> "ondemand")
> I guess that is due to FTL's system allocator... But anyway, retaking it in
> OSX is nice.

I've run benchmarks on Linux, and I don't see it being this slow.

[Saam Barati]

(In reply to comment #163)
> (In reply to comment #162)
> > Perf seems okay. A tad bit noisy on a few benchmarks though.
> > 
> > VMs tested:
> > "og" at /Users/saambarati/WK/Clean/WebKitBuild/Release/jsc (r193765)
> > "arrow" at /Users/saambarati/WK/ternary/WebKitBuild/Release/jsc (r193766)
> >     export JSC_useSamplingProfiler=1
> 
> Why are you turning on the sampling profiler?
> 
> Also, this doesn't do what you think.  This enables the sampling profiler in
> both "og" and "arrow" because environment variable settings are sticky.  If
> you really want to test enabling the sampling profiler, you should do
> JSC_useSamplingProfiler=0 for "ok".
This was just a copy-pasted command for when I was running benchmarks on my sampling profiler patch. None of these builds have that option so it shouldn't have an effect on the results.

> 
> > 
> > Collected 8 samples per benchmark/VM, with 8 VM invocations per benchmark.
> > Emitted a call to gc() between sample measurements.
> > Used 1 benchmark iteration per VM invocation for warm-up. Used the
> > jsc-specific preciseTime() function to get microsecond-level
> > timing. Reporting benchmark execution times with 95% confidence intervals in
> > milliseconds.
> > 
> >                                                             og              
> > arrow                                       
> > SunSpider:
> >    3d-cube                                            5.5486+-0.3776     ?  
> > 6.1588+-1.4880        ? might be 1.1100x slower
> >    3d-morph                                           6.7723+-0.5524        
> > 6.5086+-0.1315          might be 1.0405x faster
> >    3d-raytrace                                        9.3464+-2.1256     ?  
> > 10.1861+-4.4079        ? might be 1.0898x slower
> >    access-binary-trees                                3.6955+-1.1855        
> > 3.4952+-0.9042          might be 1.0573x faster
> >    access-fannkuch                                    7.7849+-0.8594        
> > 7.7361+-1.0548        
> >    access-nbody                                       3.3492+-0.4328        
> > 3.1038+-0.2850          might be 1.0791x faster
> >    access-nsieve                                      3.8852+-0.1749     ?  
> > 4.1947+-0.6992        ? might be 1.0797x slower
> >    bitops-3bit-bits-in-byte                           1.7157+-0.2390     ?  
> > 2.4620+-1.6877        ? might be 1.4350x slower
> >    bitops-bits-in-byte                                4.7824+-0.3928        
> > 4.4350+-0.4019          might be 1.0783x faster
> >    bitops-bitwise-and                                 2.4158+-0.0954     ?  
> > 2.5887+-0.3844        ? might be 1.0716x slower
> >    bitops-nsieve-bits                                 3.8405+-0.5083     ?  
> > 4.1218+-0.5889        ? might be 1.0732x slower
> >    controlflow-recursive                              3.3475+-0.1065     ?  
> > 3.9525+-0.7372        ? might be 1.1807x slower
> >    crypto-aes                                         5.7680+-1.1998        
> > 5.5320+-1.2805          might be 1.0427x faster
> >    crypto-md5                                         3.6719+-0.4851     ?  
> > 4.3861+-0.9448        ? might be 1.1945x slower
> >    crypto-sha1                                        3.4907+-0.0351     !  
> > 3.9138+-0.3680        ! definitely 1.1212x slower
> >    date-format-tofte                                 10.4695+-0.3881     ?  
> > 11.5784+-0.8405        ? might be 1.1059x slower
> >    date-format-xparb                                  6.1061+-0.6993     ?  
> > 6.4102+-0.8086        ? might be 1.0498x slower
> >    math-cordic                                        4.6160+-0.9783     ?  
> > 4.8223+-0.9542        ? might be 1.0447x slower
> >    math-partial-sums                                  5.7780+-0.2839     ?  
> > 5.7858+-0.3766        ?
> >    math-spectral-norm                                 3.2014+-1.0684     ?  
> > 3.4571+-0.9249        ? might be 1.0798x slower
> >    regexp-dna                                         7.5759+-0.5813        
> > 7.0899+-0.1348          might be 1.0686x faster
> >    string-base64                                      5.3790+-0.4437     ?  
> > 6.0667+-0.8667        ? might be 1.1279x slower
> >    string-fasta                                       9.4520+-1.6485     ?  
> > 9.7833+-1.3737        ? might be 1.0351x slower
> >    string-tagcloud                                   10.2208+-0.6563     ?  
> > 11.7310+-2.2655        ? might be 1.1478x slower
> >    string-unpack-code                                24.7955+-2.5243     ?  
> > 28.7615+-2.5959        ? might be 1.1599x slower
> >    string-validate-input                              6.0537+-0.8694        
> > 5.9535+-0.6086          might be 1.0168x faster
> > 
> >    <arithmetic>                                       6.2716+-0.1802     ?  
> > 6.7006+-0.2872        ? might be 1.0684x slower
> 
> 6% slower on SunSpider!  That's not ok.  If you can repro this in a second
> run then we should roll this out.
> 
> Also, you're seeing a tremendous amount of noise.
I'll run them again when I get home tonight.

> 
> > 
> >                                                             og              
> > arrow                                       
> > LongSpider:
> >    3d-cube                                          979.6206+-12.9415    ?  
> > 983.8770+-7.6640        ?
> >    3d-morph                                        1867.6507+-10.6847    ?  
> > 1875.8593+-19.7275       ?
> >    3d-raytrace                                      744.7828+-9.5260     ?  
> > 746.7947+-13.2296       ?
> >    access-binary-trees                             1078.2459+-7.6618        
> > 1067.1676+-5.1968          might be 1.0104x faster
> >    access-fannkuch                                  384.0465+-43.1038       
> > 363.1958+-6.3895          might be 1.0574x faster
> >    access-nbody                                     644.0381+-12.3405       
> > 641.1700+-5.2252        
> >    access-nsieve                                    560.9791+-1.9321     !  
> > 568.0314+-3.5764        ! definitely 1.0126x slower
> >    bitops-3bit-bits-in-byte                          42.2215+-2.1880     ?  
> > 43.2518+-1.5597        ? might be 1.0244x slower
> >    bitops-bits-in-byte                               96.4558+-3.5735     ?  
> > 100.8814+-11.8439       ? might be 1.0459x slower
> >    bitops-nsieve-bits                               586.9264+-5.7668     ?  
> > 587.7823+-9.1255        ?
> >    controlflow-recursive                            557.2467+-9.5031        
> > 554.5475+-7.7653        
> >    crypto-aes                                       676.6859+-4.8312        
> > 676.2295+-9.5004        
> >    crypto-md5                                       595.0514+-7.1109     ?  
> > 610.5173+-37.8467       ? might be 1.0260x slower
> >    crypto-sha1                                      878.2572+-164.2451      
> > 799.1692+-7.3824          might be 1.0990x faster
> >    date-format-tofte                                680.3575+-5.7515     ?  
> > 681.8051+-18.2792       ?
> >    date-format-xparb                                776.8523+-10.6451    ?  
> > 788.6069+-21.1484       ? might be 1.0151x slower
> >    hash-map                                         188.7241+-3.8994        
> > 185.0798+-3.9975          might be 1.0197x faster
> >    math-cordic                                      607.3768+-8.5754     ?  
> > 634.5539+-71.1293       ? might be 1.0447x slower
> >    math-partial-sums                                571.6515+-6.3154     ?  
> > 573.2576+-5.8824        ?
> >    math-spectral-norm                               691.9677+-6.7637        
> > 691.5540+-5.2446        
> >    string-base64                                    444.7595+-2.8129        
> > 443.5006+-4.6501        
> >    string-fasta                                     441.8869+-2.5853        
> > 439.5662+-3.7555        
> >    string-tagcloud                                  218.1470+-11.6746       
> > 212.4490+-2.7693          might be 1.0268x faster
> > 
> >    <geometric>                                      495.2857+-4.2478        
> > 494.6303+-5.8083          might be 1.0013x faster
> > 
> >                                                             og              
> > arrow                                       
> > V8Spider:
> >    crypto                                            94.2758+-4.1621     ?  
> > 104.4034+-17.8815       ? might be 1.1074x slower
> >    deltablue                                        128.1318+-5.5391     ?  
> > 129.8629+-6.9113        ? might be 1.0135x slower
> >    earley-boyer                                      80.5216+-7.3165        
> > 77.0105+-6.5667          might be 1.0456x faster
> >    raytrace                                          58.9718+-6.9031     ?  
> > 65.5312+-15.6587       ? might be 1.1112x slower
> >    regexp                                            77.8062+-2.4904        
> > 76.6958+-3.0017          might be 1.0145x faster
> >    richards                                          99.3256+-4.2371        
> > 98.5087+-4.0453        
> >    splay                                             63.6587+-4.3887        
> > 62.8673+-4.6837          might be 1.0126x faster
> > 
> >    <geometric>                                       83.2690+-2.4624     ?  
> > 84.5431+-3.2161        ? might be 1.0153x slower
> 
> V8Spider measures similar things to SunSpider.  It's noisy but it's
> interesting that this also sees a slow-down.
> 
> I never see noise on V8Spider runs.  Why is yours so noisy?
I'll run this too when I'm home tonight.

> 
> > 
> >                                                             og              
> > arrow                                       
> > Octane:
> >    encrypt                                           0.19165+-0.00365       
> > 0.19029+-0.00518       
> >    decrypt                                           3.58433+-0.03293    ?  
> > 3.63544+-0.04199       ? might be 1.0143x slower
> >    deltablue                                x2       0.16695+-0.00244       
> > 0.16506+-0.00160         might be 1.0115x faster
> >    earley                                            0.36065+-0.00174    ?  
> > 0.36209+-0.00160       ?
> >    boyer                                             5.51499+-0.06528    ?  
> > 6.00535+-1.25312       ? might be 1.0889x slower
> >    navier-stokes                            x2       6.01258+-0.07613       
> > 5.98522+-0.06443       
> >    raytrace                                 x2       1.06516+-0.01745    ?  
> > 1.06660+-0.01788       ?
> >    richards                                 x2       0.11028+-0.00195       
> > 0.10828+-0.00086         might be 1.0186x faster
> >    splay                                    x2       0.56531+-0.01233    ?  
> > 0.57407+-0.00983       ? might be 1.0155x slower
> >    regexp                                   x2      30.42811+-0.43184       
> > 30.41776+-0.23783       
> >    pdfjs                                    x2      45.86188+-0.91945    ?  
> > 46.39565+-0.54838       ? might be 1.0116x slower
> >    mandreel                                 x2      68.52068+-2.13330       
> > 66.67114+-1.02211         might be 1.0277x faster
> >    gbemu                                    x2      55.31618+-3.54668    ?  
> > 56.20139+-3.38554       ? might be 1.0160x slower
> >    closure                                           0.69902+-0.00645    ?  
> > 0.69985+-0.00592       ?
> >    jquery                                            9.31115+-0.09030       
> > 9.22842+-0.07755       
> >    box2d                                    x2      15.09213+-2.62887       
> > 14.65425+-1.70357         might be 1.0299x faster
> >    zlib                                     x2     477.69994+-12.42784      
> > 477.31493+-11.55819      
> >    typescript                               x2    1013.44379+-51.85526      
> > 997.60849+-14.86373        might be 1.0159x faster
> > 
> >    <geometric>                                       7.21930+-0.13280       
> > 7.20891+-0.06947         might be 1.0014x faster
> > 
> >                                                             og              
> > arrow                                       
> > Kraken:
> >    ai-astar                                          158.360+-20.191        
> > 148.433+-2.056           might be 1.0669x faster
> >    audio-beat-detection                               57.754+-3.308      ?  
> > 62.284+-12.044        ? might be 1.0784x slower
> >    audio-dft                                         145.212+-24.168        
> > 136.132+-2.022           might be 1.0667x faster
> >    audio-fft                                          42.185+-1.458      ?  
> > 44.726+-5.909         ? might be 1.0602x slower
> >    audio-oscillator                                   69.004+-2.002      ?  
> > 72.244+-2.573         ? might be 1.0469x slower
> >    imaging-darkroom                                   74.577+-2.839         
> > 72.167+-3.033           might be 1.0334x faster
> >    imaging-desaturate                                 71.886+-3.510      ?  
> > 72.630+-3.979         ? might be 1.0104x slower
> >    imaging-gaussian-blur                             104.800+-3.349         
> > 104.723+-2.226         
> >    json-parse-financial                               48.685+-5.054      ?  
> > 49.805+-4.713         ? might be 1.0230x slower
> >    json-stringify-tinderbox                           30.644+-3.016      ?  
> > 31.420+-4.706         ? might be 1.0253x slower
> >    stanford-crypto-aes                                56.982+-3.034         
> > 53.615+-2.909           might be 1.0628x faster
> >    stanford-crypto-ccm                                49.070+-5.787      ?  
> > 51.168+-7.458         ? might be 1.0427x slower
> >    stanford-crypto-pbkdf2                            127.559+-21.382        
> > 117.815+-3.032           might be 1.0827x faster
> >    stanford-crypto-sha256-iterative                   44.168+-0.875      ?  
> > 45.854+-1.524         ? might be 1.0382x slower
> > 
> >    <arithmetic>                                       77.206+-3.385         
> > 75.930+-1.844           might be 1.0168x faster
> > 
> >                                                             og              
> > arrow                                       
> > JSRegress:
> >    abc-forward-loop-equal                            37.2579+-2.3398        
> > 35.7465+-1.0912          might be 1.0423x faster
> >    abc-postfix-backward-loop                         38.4064+-6.7649        
> > 35.9295+-1.9088          might be 1.0689x faster
> >    abc-simple-backward-loop                          35.5298+-1.3557     ?  
> > 35.9082+-1.2656        ? might be 1.0107x slower
> >    abc-simple-forward-loop                           36.6216+-0.9619        
> > 36.4425+-3.9351        
> >    abc-skippy-loop                                   26.0396+-1.5759     ?  
> > 28.4593+-8.1786        ? might be 1.0929x slower
> >    abs-boolean                                        3.1456+-0.1699     ?  
> > 3.5277+-0.6378        ? might be 1.1215x slower
> >    adapt-to-double-divide                            20.5440+-3.4677        
> > 19.6534+-1.0639          might be 1.0453x faster
> >    aliased-arguments-getbyval                         1.4484+-0.1026     ?  
> > 1.7911+-0.5195        ? might be 1.2366x slower
> >    allocate-big-object                                3.4569+-0.7461     ?  
> > 3.5705+-1.3345        ? might be 1.0328x slower
> >    arguments-named-and-reflective                    17.0524+-8.7680        
> > 13.8434+-1.6635          might be 1.2318x faster
> >    arguments-out-of-bounds                           12.3063+-0.4771     ?  
> > 13.1274+-1.1189        ? might be 1.0667x slower
> >    arguments-strict-mode                             11.6178+-0.7198     ?  
> > 12.5719+-1.2735        ? might be 1.0821x slower
> >    arguments                                         10.2392+-0.5618        
> > 9.8727+-0.1396          might be 1.0371x faster
> >    arity-mismatch-inlining                            1.6434+-0.7833        
> > 1.2252+-0.0868          might be 1.3414x faster
> >    array-access-polymorphic-structure                 8.6277+-0.5405     ?  
> > 9.1590+-1.3513        ? might be 1.0616x slower
> >    array-nonarray-polymorhpic-access                 33.2805+-4.0321        
> > 31.0485+-2.7368          might be 1.0719x faster
> >    array-prototype-every                             93.0138+-4.0171     ?  
> > 94.7696+-3.6091        ? might be 1.0189x slower
> >    array-prototype-forEach                           94.0331+-4.6714     ?  
> > 105.6436+-25.6265       ? might be 1.1235x slower
> >    array-prototype-map                              101.9197+-4.8605     ?  
> > 103.0874+-3.1996        ? might be 1.0115x slower
> >    array-prototype-reduce                            90.3503+-4.7914     ?  
> > 95.9212+-7.7394        ? might be 1.0617x slower
> >    array-prototype-reduceRight                       97.0178+-8.0480        
> > 92.3733+-6.7306          might be 1.0503x faster
> >    array-prototype-some                              97.1310+-5.0248        
> > 96.4595+-3.0243        
> >    array-splice-contiguous                           28.6559+-1.9033        
> > 27.7673+-1.5342          might be 1.0320x faster
> >    array-with-double-add                              4.3314+-0.1927     ?  
> > 4.3662+-0.2464        ?
> >    array-with-double-increment                        4.5760+-0.7823        
> > 3.9757+-0.2593          might be 1.1510x faster
> >    array-with-double-mul-add                          6.6307+-1.2763        
> > 6.1796+-1.4461          might be 1.0730x faster
> >    array-with-double-sum                              4.2396+-0.6035        
> > 4.0898+-0.3208          might be 1.0366x faster
> >    array-with-int32-add-sub                           9.9673+-1.2296        
> > 9.2478+-1.9793          might be 1.0778x faster
> >    array-with-int32-or-double-sum                     4.3331+-0.4979     ?  
> > 4.4148+-0.6502        ? might be 1.0189x slower
> >    ArrayBuffer-DataView-alloc-large-long-lived   
> >                                                      39.2668+-2.8121     ?  
> > 40.1184+-2.6948        ? might be 1.0217x slower
> >    ArrayBuffer-DataView-alloc-long-lived             15.9205+-1.2869        
> > 15.4484+-1.2372          might be 1.0306x faster
> >    ArrayBuffer-Int32Array-byteOffset                  4.5631+-0.3146        
> > 4.2748+-0.1547          might be 1.0674x faster
> >    ArrayBuffer-Int8Array-alloc-large-long-lived   
> >                                                      39.9039+-2.2320        
> > 38.2159+-2.6773          might be 1.0442x faster
> >    ArrayBuffer-Int8Array-alloc-long-lived-buffer   
> >                                                      25.4290+-2.0875        
> > 24.6682+-1.5413          might be 1.0308x faster
> >    ArrayBuffer-Int8Array-alloc-long-lived            14.1549+-0.8256     ?  
> > 15.2833+-1.9873        ? might be 1.0797x slower
> >    ArrayBuffer-Int8Array-alloc                       13.2227+-1.2507        
> > 12.7815+-1.0694          might be 1.0345x faster
> >    asmjs_bool_bug                                     9.2168+-0.6827        
> > 9.1978+-0.5884        
> >    assign-custom-setter-polymorphic                   2.8987+-0.1680     ?  
> > 3.3512+-0.3783        ? might be 1.1561x slower
> >    assign-custom-setter                               4.0440+-0.2516     ?  
> > 4.3845+-0.7428        ? might be 1.0842x slower
> >    basic-set                                         13.3817+-1.4564        
> > 12.6051+-0.4201          might be 1.0616x faster
> >    big-int-mul                                        5.3145+-1.0886        
> > 5.0489+-1.2849          might be 1.0526x faster
> >    boolean-test                                       4.4485+-1.6660        
> > 3.4810+-0.1771          might be 1.2780x faster
> >    branch-fold                                        4.4475+-0.2387     ?  
> > 5.6894+-1.9361        ? might be 1.2792x slower
> >    branch-on-string-as-boolean                       20.7794+-1.5399        
> > 19.5341+-0.6242          might be 1.0638x faster
> >    by-val-generic                                     2.9631+-0.2916     ?  
> > 3.2131+-0.4442        ? might be 1.0844x slower
> >    call-spread-apply                                 43.6687+-2.8071     ?  
> > 44.6581+-3.4074        ? might be 1.0227x slower
> >    call-spread-call                                  33.0528+-2.5648     ?  
> > 34.2193+-2.9838        ? might be 1.0353x slower
> >    captured-assignments                               0.6949+-0.2564        
> > 0.5858+-0.0358          might be 1.1862x faster
> >    cast-int-to-double                                 7.1781+-1.3036        
> > 6.8158+-0.3286          might be 1.0532x faster
> >    cell-argument                                      7.4037+-0.8052     ?  
> > 7.4144+-0.8340        ?
> >    cfg-simplify                                       3.5155+-0.4068     ?  
> > 3.8013+-1.0554        ? might be 1.0813x slower
> >    chain-getter-access                               10.5173+-0.1356     ?  
> > 11.8623+-1.4680        ? might be 1.1279x slower
> >    cmpeq-obj-to-obj-other                            18.6098+-3.6358        
> > 16.4263+-2.2825          might be 1.1329x faster
> >    constant-test                                      6.4961+-0.8532     ?  
> > 6.6080+-0.4624        ? might be 1.0172x slower
> >    create-lots-of-functions                          13.5147+-1.4590        
> > 13.0828+-1.5589          might be 1.0330x faster
> >    cse-new-array-buffer                               3.3037+-0.6428        
> > 3.0935+-0.4439          might be 1.0679x faster
> >    cse-new-array                                      3.2596+-0.4567        
> > 3.1004+-0.3207          might be 1.0514x faster
> >    DataView-custom-properties                        43.7892+-2.7348     ?  
> > 44.6245+-2.8140        ? might be 1.0191x slower
> >    deconstructing-parameters-overridden-by-function   
> >                                                       0.6794+-0.1088        
> > 0.6239+-0.0776          might be 1.0890x faster
> >    delay-tear-off-arguments-strictmode               16.3296+-1.2392     ?  
> > 17.3647+-1.6716        ? might be 1.0634x slower
> >    deltablue-varargs                                240.0904+-21.3412       
> > 233.3723+-5.2693          might be 1.0288x faster
> >    destructuring-arguments                          196.9813+-4.8798        
> > 196.6165+-3.5080        
> >    destructuring-swap                                 6.6623+-0.4985     ?  
> > 7.8062+-2.6722        ? might be 1.1717x slower
> >    direct-arguments-getbyval                          1.6988+-0.5177        
> > 1.4304+-0.1834          might be 1.1876x faster
> >    div-boolean-double                                 6.3949+-0.6125        
> > 6.0061+-0.1330          might be 1.0647x faster
> >    div-boolean                                       10.0115+-1.6846        
> > 9.6446+-0.3696          might be 1.0380x faster
> >    double-get-by-val-out-of-bounds                    6.7544+-0.8453        
> > 6.7137+-0.9961        
> >    double-pollution-getbyval                          9.9826+-0.6310     ?  
> > 10.2161+-0.6550        ? might be 1.0234x slower
> >    double-pollution-putbyoffset                       4.5938+-0.4472     ?  
> > 4.8499+-0.7388        ? might be 1.0558x slower
> >    double-real-use                                   30.0794+-1.9350     ?  
> > 30.5691+-1.7329        ? might be 1.0163x slower
> >    double-to-int32-typed-array-no-inline              3.2495+-0.3063     ?  
> > 3.2968+-0.4816        ? might be 1.0146x slower
> >    double-to-int32-typed-array                        3.0900+-0.3486     ?  
> > 3.1309+-0.2677        ? might be 1.0132x slower
> >    double-to-uint32-typed-array-no-inline             3.6238+-0.4522        
> > 3.4441+-0.4179          might be 1.0522x faster
> >    double-to-uint32-typed-array                       3.7118+-0.8975        
> > 3.0998+-0.3114          might be 1.1975x faster
> >    elidable-new-object-dag                           45.8504+-2.7162        
> > 45.1216+-2.4527          might be 1.0162x faster
> >    elidable-new-object-roflcopter                    43.5858+-1.4398     ?  
> > 43.9602+-1.1385        ?
> >    elidable-new-object-then-call                     41.8176+-2.5375        
> > 41.5889+-3.0084        
> >    elidable-new-object-tree                          55.7389+-7.5940        
> > 53.8633+-4.7310          might be 1.0348x faster
> >    empty-string-plus-int                              7.2627+-1.4399        
> > 7.0235+-1.4734          might be 1.0341x faster
> >    emscripten-cube2hash                              43.2194+-6.3927        
> > 39.4663+-1.6437          might be 1.0951x faster
> >    exit-length-on-plain-object                       18.7541+-1.0626        
> > 18.3673+-0.5603          might be 1.0211x faster
> >    external-arguments-getbyval                        2.7480+-2.4020        
> > 1.8173+-0.4893          might be 1.5121x faster
> >    external-arguments-putbyval                        3.3431+-0.5308        
> > 3.3301+-0.7049        
> >    fixed-typed-array-storage-var-index                1.7029+-0.1506     ?  
> > 1.9047+-0.4691        ? might be 1.1185x slower
> >    fixed-typed-array-storage                          1.2867+-0.0313     ?  
> > 2.1949+-1.0326        ? might be 1.7058x slower
> >    Float32Array-matrix-mult                           5.2332+-0.4382        
> > 5.0654+-0.3022          might be 1.0331x faster
> >    Float32Array-to-Float64Array-set                  59.1094+-1.8590     ?  
> > 60.0805+-2.2669        ? might be 1.0164x slower
> >    Float64Array-alloc-long-lived                     84.8658+-4.4382     ?  
> > 91.3128+-13.4277       ? might be 1.0760x slower
> >    Float64Array-to-Int16Array-set                    75.3679+-3.0505     ?  
> > 78.6457+-12.8880       ? might be 1.0435x slower
> >    fold-double-to-int                                15.8759+-1.3497     ?  
> > 16.0391+-1.7076        ? might be 1.0103x slower
> >    fold-get-by-id-to-multi-get-by-offset-rare-int   
> >                                                      16.4219+-1.6391        
> > 16.3318+-3.9740        
> >    fold-get-by-id-to-multi-get-by-offset             15.3993+-2.4073     ?  
> > 17.4256+-3.3929        ? might be 1.1316x slower
> >    fold-multi-get-by-offset-to-get-by-offset   
> >                                                      13.5442+-2.9402     ?  
> > 15.0516+-1.8716        ? might be 1.1113x slower
> >    fold-multi-get-by-offset-to-poly-get-by-offset   
> >                                                      13.3754+-1.9016     ?  
> > 15.5807+-2.1758        ? might be 1.1649x slower
> >    fold-multi-put-by-offset-to-poly-put-by-offset   
> >                                                      16.3234+-2.2109        
> > 14.7454+-2.5984          might be 1.1070x faster
> >    fold-multi-put-by-offset-to-put-by-offset   
> >                                                      16.5553+-2.3376        
> > 14.1646+-1.1066          might be 1.1688x faster
> >    fold-multi-put-by-offset-to-replace-or-transition-put-by-offset   
> >                                                      16.0363+-1.9765     ?  
> > 17.7013+-4.4254        ? might be 1.1038x slower
> >    fold-put-by-id-to-multi-put-by-offset             17.2283+-1.5242     ?  
> > 17.2981+-3.6472        ?
> >    fold-put-structure                                13.7028+-2.9131     ?  
> > 14.5268+-0.9158        ? might be 1.0601x slower
> >    for-of-iterate-array-entries                      14.0406+-0.6858     ?  
> > 16.5756+-4.1127        ? might be 1.1805x slower
> >    for-of-iterate-array-keys                          5.3665+-1.3754        
> > 5.2263+-1.0263          might be 1.0268x faster
> >    for-of-iterate-array-values                        4.7393+-0.5649     ?  
> > 4.9382+-0.6473        ? might be 1.0420x slower
> >    fround                                            21.3670+-1.7628        
> > 21.2838+-1.1406        
> >    ftl-library-inlining-dataview                     69.2258+-3.0072     ?  
> > 75.7873+-7.4709        ? might be 1.0948x slower
> >    ftl-library-inlining                             104.1258+-17.0993       
> > 94.6728+-3.0155          might be 1.0998x faster
> >    function-dot-apply                                 2.9359+-0.4578        
> > 2.9344+-0.2188        
> >    function-test                                      3.4261+-0.4497        
> > 3.3767+-0.2988          might be 1.0147x faster
> >    function-with-eval                               101.8975+-3.0056     ?  
> > 107.6019+-3.0544        ? might be 1.0560x slower
> >    gcse-poly-get-less-obvious                        25.8231+-2.3331        
> > 25.7687+-1.5290        
> >    gcse-poly-get                                     28.8874+-1.7344        
> > 28.3009+-1.1950          might be 1.0207x faster
> >    gcse                                               4.9285+-0.9418        
> > 4.6151+-0.3336          might be 1.0679x faster
> >    get-by-id-bimorphic-check-structure-elimination-simple   
> >                                                       3.4864+-0.3799        
> > 3.4534+-0.2181        
> >    get-by-id-bimorphic-check-structure-elimination   
> >                                                       6.3324+-0.9037     ?  
> > 6.4219+-0.8451        ? might be 1.0141x slower
> >    get-by-id-chain-from-try-block                     3.5633+-0.6249        
> > 3.3322+-0.4275          might be 1.0693x faster
> >    get-by-id-check-structure-elimination              5.4746+-1.1774        
> > 5.3190+-0.7651          might be 1.0293x faster
> >    get-by-id-proto-or-self                           20.8489+-1.4950     ?  
> > 21.8380+-2.0444        ? might be 1.0474x slower
> >    get-by-id-quadmorphic-check-structure-elimination-simple   
> >                                                       4.3014+-0.8478        
> > 3.9215+-0.7883          might be 1.0969x faster
> >    get-by-id-self-or-proto                           20.5865+-1.9381     ?  
> > 20.8556+-1.7183        ? might be 1.0131x slower
> >    get-by-val-out-of-bounds                           6.3422+-0.7075     ?  
> > 6.5540+-0.4376        ? might be 1.0334x slower
> >    get_callee_monomorphic                             5.3254+-1.6598        
> > 5.0698+-1.7555          might be 1.0504x faster
> >    get_callee_polymorphic                             4.4986+-0.4603        
> > 3.9905+-0.2309          might be 1.1273x faster
> >    getter-no-activation                               6.0191+-0.6340     ?  
> > 6.4662+-0.9116        ? might be 1.0743x slower
> >    getter-prototype                                  10.2050+-0.3790     ?  
> > 10.5055+-1.0068        ? might be 1.0295x slower
> >    getter-richards                                  201.9159+-12.7781       
> > 197.1846+-3.1066          might be 1.0240x faster
> >    getter                                             9.5755+-1.1654        
> > 8.3142+-0.8070          might be 1.1517x faster
> >    global-var-const-infer-fire-from-opt               0.9047+-0.0348     ?  
> > 1.4013+-0.4646        ? might be 1.5489x slower
> >    global-var-const-infer                             0.8293+-0.0577     ?  
> > 0.8658+-0.0876        ? might be 1.0440x slower
> >    HashMap-put-get-iterate-keys                      49.9581+-9.3407        
> > 48.1003+-4.4557          might be 1.0386x faster
> >    HashMap-put-get-iterate                           51.8194+-2.7933        
> > 50.6197+-3.5713          might be 1.0237x faster
> >    HashMap-string-put-get-iterate                    38.2748+-1.9891     ?  
> > 42.6238+-3.8388        ? might be 1.1136x slower
> >    hoist-make-rope                                   12.5659+-0.8705     ?  
> > 12.6675+-1.6290        ?
> >    hoist-poly-check-structure-effectful-loop   
> >                                                       4.7118+-0.5956        
> > 4.6806+-0.5861        
> >    hoist-poly-check-structure                         3.9561+-0.4244     ?  
> > 4.2675+-0.7336        ? might be 1.0787x slower
> >    imul-double-only                                   9.9329+-1.7565        
> > 9.8946+-1.1923        
> >    imul-int-only                                     10.0328+-1.3524        
> > 10.0313+-1.0619        
> >    imul-mixed                                         8.0088+-0.6250     ?  
> > 8.4963+-1.2590        ? might be 1.0609x slower
> >    in-four-cases                                     24.7942+-2.2616     ?  
> > 28.0699+-4.7857        ? might be 1.1321x slower
> >    in-one-case-false                                 16.5529+-1.1108        
> > 15.4301+-1.6122          might be 1.0728x faster
> >    in-one-case-true                                  16.3685+-1.9449     ?  
> > 17.4533+-3.6025        ? might be 1.0663x slower
> >    in-two-cases                                      15.4241+-0.9138     ?  
> > 16.7668+-0.8443        ? might be 1.0870x slower
> >    indexed-properties-in-objects                      3.9228+-0.5768     ?  
> > 4.7503+-2.6804        ? might be 1.2109x slower
> >    infer-closure-const-then-mov-no-inline             7.0280+-1.3573        
> > 5.8040+-1.3924          might be 1.2109x faster
> >    infer-closure-const-then-mov                      21.5053+-3.3825        
> > 21.2701+-1.7546          might be 1.0111x faster
> >    infer-closure-const-then-put-to-scope-no-inline   
> >                                                      13.7957+-0.9999        
> > 12.8392+-0.5734          might be 1.0745x faster
> >    infer-closure-const-then-put-to-scope             27.0936+-0.7978        
> > 26.8879+-1.1094        
> >    infer-closure-const-then-reenter-no-inline   
> >                                                      59.3963+-7.4071        
> > 55.9055+-4.1013          might be 1.0624x faster
> >    infer-closure-const-then-reenter                  27.5713+-1.0826        
> > 27.4870+-1.0522        
> >    infer-constant-global-property                     4.1000+-0.2353     ?  
> > 4.3567+-0.9074        ? might be 1.0626x slower
> >    infer-constant-property                            3.3316+-0.3537     ?  
> > 3.8195+-0.9738        ? might be 1.1464x slower
> >    infer-one-time-closure-ten-vars                    9.6924+-0.7754        
> > 9.3388+-0.5829          might be 1.0379x faster
> >    infer-one-time-closure-two-vars                    9.0012+-0.9003     ?  
> > 9.5344+-0.7486        ? might be 1.0592x slower
> >    infer-one-time-closure                             9.4675+-1.3114        
> > 8.2992+-0.3492          might be 1.1408x faster
> >    infer-one-time-deep-closure                       13.3735+-0.5226     ?  
> > 13.6130+-1.8708        ? might be 1.0179x slower
> >    inline-arguments-access                            5.2063+-0.5288     ?  
> > 6.1911+-1.9950        ? might be 1.1891x slower
> >    inline-arguments-aliased-access                    5.4153+-0.9304        
> > 5.3040+-0.5668          might be 1.0210x faster
> >    inline-arguments-local-escape                      5.5848+-0.7107        
> > 5.5738+-0.5697        
> >    inline-get-scoped-var                              9.0743+-3.7312        
> > 6.1892+-0.5828          might be 1.4662x faster
> >    inlined-put-by-id-transition                      14.2269+-1.8896     ?  
> > 14.6714+-1.5965        ? might be 1.0312x slower
> >    int-or-other-abs-then-get-by-val                   6.5051+-1.0603     ?  
> > 6.8251+-1.1843        ? might be 1.0492x slower
> >    int-or-other-abs-zero-then-get-by-val             19.3748+-1.3415        
> > 18.6546+-0.9527          might be 1.0386x faster
> >    int-or-other-add-then-get-by-val                   6.1991+-1.2500        
> > 6.0734+-1.0100          might be 1.0207x faster
> >    int-or-other-add                                   6.8814+-0.4687     ?  
> > 7.1674+-1.5134        ? might be 1.0416x slower
> >    int-or-other-div-then-get-by-val                   5.5648+-0.9681        
> > 5.4134+-0.7751          might be 1.0280x faster
> >    int-or-other-max-then-get-by-val                   5.9802+-2.2235        
> > 5.0877+-0.9310          might be 1.1754x faster
> >    int-or-other-min-then-get-by-val                   4.8323+-0.8217     ?  
> > 5.4706+-1.1039        ? might be 1.1321x slower
> >    int-or-other-mod-then-get-by-val                   4.5843+-0.5839     ?  
> > 5.5934+-1.9680        ? might be 1.2201x slower
> >    int-or-other-mul-then-get-by-val                   4.8411+-1.1100     ?  
> > 5.4257+-2.3754        ? might be 1.1208x slower
> >    int-or-other-neg-then-get-by-val                   6.2528+-0.5724     ?  
> > 6.3528+-1.0423        ? might be 1.0160x slower
> >    int-or-other-neg-zero-then-get-by-val             19.3617+-0.5449     ?  
> > 19.4342+-2.1737        ?
> >    int-or-other-sub-then-get-by-val                   7.1858+-1.0083        
> > 6.8348+-1.6533          might be 1.0514x faster
> >    int-or-other-sub                                   4.4160+-0.8960     ?  
> > 5.6829+-1.7405        ? might be 1.2869x slower
> >    int-overflow-local                                 5.8922+-1.0411     ?  
> > 6.0024+-0.7940        ? might be 1.0187x slower
> >    Int16Array-alloc-long-lived                       60.6396+-1.9842     ?  
> > 62.9409+-3.1944        ? might be 1.0380x slower
> >    Int16Array-bubble-sort-with-byteLength            26.9279+-1.7888     ?  
> > 27.8375+-1.9868        ? might be 1.0338x slower
> >    Int16Array-bubble-sort                            26.7879+-2.4825     ?  
> > 27.2955+-4.0658        ? might be 1.0189x slower
> >    Int16Array-load-int-mul                            2.4442+-0.7363        
> > 2.3841+-0.9629          might be 1.0252x faster
> >    Int16Array-to-Int32Array-set                      54.7574+-2.4504     ?  
> > 55.6938+-3.4496        ? might be 1.0171x slower
> >    Int32Array-alloc-large                            13.7660+-0.9221     ?  
> > 15.5786+-2.3366        ? might be 1.1317x slower
> >    Int32Array-alloc-long-lived                       71.8069+-2.9273        
> > 71.1467+-1.1266        
> >    Int32Array-alloc                                   3.5486+-0.1001     ?  
> > 3.8785+-0.5284        ? might be 1.0930x slower
> >    Int32Array-Int8Array-view-alloc                    7.7768+-1.1584        
> > 7.0909+-0.2946          might be 1.0967x faster
> >    int52-spill                                        6.8822+-1.1863     ?  
> > 7.8849+-1.1672        ? might be 1.1457x slower
> >    Int8Array-alloc-long-lived                        54.7040+-3.2661     ?  
> > 55.7315+-3.9118        ? might be 1.0188x slower
> >    Int8Array-load-with-byteLength                     4.5692+-0.6880        
> > 4.3046+-0.4991          might be 1.0615x faster
> >    Int8Array-load                                     4.8325+-1.7270        
> > 4.0877+-0.1485          might be 1.1822x faster
> >    integer-divide                                    12.4633+-1.0606     ?  
> > 13.3499+-1.6024        ? might be 1.0711x slower
> >    integer-modulo                                     2.2004+-0.5812     ?  
> > 3.0005+-0.3615        ? might be 1.3636x slower
> >    is-boolean-fold-tricky                             4.5012+-0.2893     ?  
> > 4.5383+-0.3627        ?
> >    is-boolean-fold                                    3.6093+-0.3428        
> > 3.3966+-0.2772          might be 1.0626x faster
> >    is-function-fold-tricky-internal-function   
> >                                                      12.4520+-1.6358     ?  
> > 12.8837+-1.5570        ? might be 1.0347x slower
> >    is-function-fold-tricky                            5.8409+-1.5565        
> > 5.0497+-0.6861          might be 1.1567x faster
> >    is-function-fold                                   3.8815+-0.7866        
> > 3.5265+-0.4044          might be 1.1007x faster
> >    is-number-fold-tricky                              5.1023+-0.8659     ?  
> > 5.2931+-0.8870        ? might be 1.0374x slower
> >    is-number-fold                                     3.3299+-0.2084        
> > 3.2468+-0.1569          might be 1.0256x faster
> >    is-object-or-null-fold-functions                   3.6634+-0.8199        
> > 3.2487+-0.0762          might be 1.1276x faster
> >    is-object-or-null-fold-less-tricky                 5.2957+-0.6472     ?  
> > 5.3200+-0.6984        ?
> >    is-object-or-null-fold-tricky                      6.5538+-1.3269        
> > 6.4363+-1.2027          might be 1.0183x faster
> >    is-object-or-null-fold                             3.4477+-0.3634        
> > 3.4066+-0.2580          might be 1.0121x faster
> >    is-object-or-null-trickier-function                5.2358+-1.0067     ?  
> > 5.5409+-0.8448        ? might be 1.0583x slower
> >    is-object-or-null-trickier-internal-function   
> >                                                      13.9175+-3.5380        
> > 13.2418+-2.0966          might be 1.0510x faster
> >    is-object-or-null-tricky-function                  5.4054+-0.9216        
> > 5.2749+-0.7598          might be 1.0247x faster
> >    is-object-or-null-tricky-internal-function   
> >                                                      11.6495+-3.0602        
> > 10.7815+-1.8177          might be 1.0805x faster
> >    is-string-fold-tricky                              4.4926+-0.0891     ?  
> > 5.0273+-0.8342        ? might be 1.1190x slower
> >    is-string-fold                                     3.2773+-0.1458     ?  
> > 3.8502+-0.8579        ? might be 1.1748x slower
> >    is-undefined-fold-tricky                           5.0959+-1.6424        
> > 4.6981+-0.8968          might be 1.0847x faster
> >    is-undefined-fold                                  3.4615+-0.3501        
> > 3.4347+-0.2692        
> >    large-int-captured                                 5.5484+-0.7128     ?  
> > 6.7182+-1.5821        ? might be 1.2108x slower
> >    large-int-neg                                     17.2491+-1.2234     ?  
> > 18.0859+-1.8745        ? might be 1.0485x slower
> >    large-int                                         16.2925+-0.7841        
> > 15.8744+-1.0113          might be 1.0263x faster
> >    load-varargs-elimination                          26.5208+-4.9690        
> > 24.4740+-1.1209          might be 1.0836x faster
> >    logical-not-weird-types                            4.0546+-0.3700     ?  
> > 4.8073+-1.0364        ? might be 1.1856x slower
> >    logical-not                                        6.6178+-1.0384        
> > 6.5918+-0.8072        
> >    lots-of-fields                                    12.0117+-1.1511     ?  
> > 12.5003+-1.6432        ? might be 1.0407x slower
> >    make-indexed-storage                               3.6068+-0.1934     ?  
> > 4.0336+-0.8168        ? might be 1.1183x slower
> >    make-rope-cse                                      5.0674+-0.4251     ?  
> > 5.3017+-0.9595        ? might be 1.0462x slower
> >    marsaglia-larger-ints                             40.3790+-3.3904        
> > 37.7698+-1.7711          might be 1.0691x faster
> >    marsaglia-osr-entry                               25.6728+-1.6537     ?  
> > 26.2175+-1.4756        ? might be 1.0212x slower
> >    math-with-out-of-bounds-array-values              27.4670+-2.2391        
> > 25.4466+-1.5306          might be 1.0794x faster
> >    max-boolean                                        3.5387+-0.6257        
> > 3.1871+-0.1961          might be 1.1103x faster
> >    method-on-number                                  21.2495+-4.1046        
> > 19.5970+-1.3532          might be 1.0843x faster
> >    min-boolean                                        3.5667+-0.4092     ?  
> > 4.0263+-0.7557        ? might be 1.1288x slower
> >    minus-boolean-double                               3.7137+-0.1919        
> > 3.6678+-0.2161          might be 1.0125x faster
> >    minus-boolean                                      3.4976+-0.6851        
> > 3.2144+-0.4545          might be 1.0881x faster
> >    misc-strict-eq                                    34.6359+-1.6161     ?  
> > 36.2059+-3.3835        ? might be 1.0453x slower
> >    mod-boolean-double                                12.7856+-0.2986     ?  
> > 13.1305+-0.4317        ? might be 1.0270x slower
> >    mod-boolean                                        9.7702+-0.3897        
> > 9.5118+-0.2316          might be 1.0272x faster
> >    mul-boolean-double                                 4.1799+-0.1579     ?  
> > 4.3141+-0.4004        ? might be 1.0321x slower
> >    mul-boolean                                        5.0107+-3.6920        
> > 3.4553+-0.3305          might be 1.4502x faster
> >    neg-boolean                                        3.8375+-0.2435     ?  
> > 4.1198+-0.6790        ? might be 1.0736x slower
> >    negative-zero-divide                               0.4586+-0.0226     ?  
> > 0.4858+-0.0315        ? might be 1.0594x slower
> >    negative-zero-modulo                               0.5408+-0.1042        
> > 0.4666+-0.0500          might be 1.1590x faster
> >    negative-zero-negate                               0.4578+-0.0177     ?  
> > 0.5044+-0.1266        ? might be 1.1018x slower
> >    nested-function-parsing                           52.4802+-1.4949     ?  
> > 53.1787+-1.6923        ? might be 1.0133x slower
> >    new-array-buffer-dead                            119.3326+-5.0016        
> > 115.3158+-2.9104          might be 1.0348x faster
> >    new-array-buffer-push                              8.0227+-0.3564     ?  
> > 8.0550+-0.6948        ?
> >    new-array-dead                                    19.7980+-1.8895     ?  
> > 20.4668+-1.7634        ? might be 1.0338x slower
> >    new-array-push                                     6.3156+-1.0398     ?  
> > 6.6227+-1.7680        ? might be 1.0486x slower
> >    no-inline-constructor                             39.3162+-2.5647     ?  
> > 40.9858+-2.6176        ? might be 1.0425x slower
> >    number-test                                        3.3954+-0.0963     ?  
> > 4.0158+-0.9138        ? might be 1.1827x slower
> >    object-closure-call                                7.4893+-1.0145     ?  
> > 7.6503+-1.2372        ? might be 1.0215x slower
> >    object-test                                        3.5358+-0.3848        
> > 3.2967+-0.2672          might be 1.0725x faster
> >    obvious-sink-pathology-taken                     131.2562+-2.6446        
> > 131.0823+-2.9774        
> >    obvious-sink-pathology                            41.9166+-2.7490        
> > 37.8715+-2.3766          might be 1.1068x faster
> >    obviously-elidable-new-object                     41.5632+-9.6682        
> > 37.9131+-2.4700          might be 1.0963x faster
> >    plus-boolean-arith                                 3.1219+-0.2494     ?  
> > 3.5114+-0.5974        ? might be 1.1248x slower
> >    plus-boolean-double                                4.0791+-0.7021        
> > 3.9313+-0.5593          might be 1.0376x faster
> >    plus-boolean                                       3.1550+-0.1742     ?  
> > 3.2582+-0.4869        ? might be 1.0327x slower
> >    poly-chain-access-different-prototypes-simple   
> >                                                       3.6239+-0.5373        
> > 3.5352+-0.5711          might be 1.0251x faster
> >    poly-chain-access-different-prototypes             3.4258+-0.3624     ?  
> > 3.6167+-0.6555        ? might be 1.0557x slower
> >    poly-chain-access-simpler                          3.2759+-0.1953     ?  
> > 3.8593+-0.7411        ? might be 1.1781x slower
> >    poly-chain-access                                  3.6336+-0.6427        
> > 3.3856+-0.4205          might be 1.0733x faster
> >    poly-stricteq                                     65.7043+-2.8066        
> > 64.6046+-1.6136          might be 1.0170x faster
> >    polymorphic-array-call                             1.5191+-0.0781     ?  
> > 1.9288+-0.5096        ? might be 1.2697x slower
> >    polymorphic-get-by-id                              3.7117+-0.4279     ?  
> > 3.8253+-0.5602        ? might be 1.0306x slower
> >    polymorphic-put-by-id                             30.9391+-1.9131        
> > 28.9586+-1.0124          might be 1.0684x faster
> >    polymorphic-structure                             16.2760+-1.1001        
> > 15.0356+-0.6728          might be 1.0825x faster
> >    polyvariant-monomorphic-get-by-id                 11.9882+-3.0016        
> > 10.5973+-2.1037          might be 1.1312x faster
> >    proto-getter-access                               10.7909+-0.8131     ?  
> > 10.9121+-0.3497        ? might be 1.0112x slower
> >    put-by-id-replace-and-transition                  12.1792+-3.7843        
> > 10.0818+-1.0230          might be 1.2080x faster
> >    put-by-id-slightly-polymorphic                     3.6127+-0.6350     ?  
> > 3.6818+-0.5384        ? might be 1.0191x slower
> >    put-by-id                                         15.4365+-1.7110        
> > 14.8394+-0.8973          might be 1.0402x faster
> >    put-by-val-direct                                  0.4554+-0.0163     ?  
> > 0.5510+-0.1951        ? might be 1.2099x slower
> >    put-by-val-large-index-blank-indexing-type   
> >                                                       6.9276+-1.4780        
> > 6.2964+-0.2987          might be 1.1003x faster
> >    put-by-val-machine-int                             3.5801+-1.0090        
> > 3.5800+-1.0489        
> >    rare-osr-exit-on-local                            16.7810+-1.0061     ?  
> > 19.3292+-2.3701        ? might be 1.1518x slower
> >    register-pressure-from-osr                        19.9251+-1.1388     ?  
> > 20.5262+-1.8323        ? might be 1.0302x slower
> >    repeat-multi-get-by-offset                        24.6384+-1.3236     ?  
> > 25.5090+-1.3420        ? might be 1.0353x slower
> >    setter-prototype                                  10.1467+-0.7022     ?  
> > 10.6124+-0.9191        ? might be 1.0459x slower
> >    setter                                            10.3702+-2.4096        
> > 8.5017+-1.0099          might be 1.2198x faster
> >    simple-activation-demo                            31.6666+-1.5279        
> > 30.5257+-2.5322          might be 1.0374x faster
> >    simple-getter-access                              14.1857+-1.2871        
> > 13.9896+-1.0179          might be 1.0140x faster
> >    simple-poly-call-nested                           11.6313+-1.2572        
> > 11.4275+-0.9490          might be 1.0178x faster
> >    simple-poly-call                                   1.9476+-0.3178     ?  
> > 2.1544+-0.3415        ? might be 1.1061x slower
> >    sin-boolean                                       22.8802+-1.8671     ?  
> > 23.3559+-2.2800        ? might be 1.0208x slower
> >    singleton-scope                                   69.6582+-2.1552     ?  
> > 72.0809+-10.5902       ? might be 1.0348x slower
> >    sink-function                                     13.8252+-1.5340        
> > 13.3280+-0.6244          might be 1.0373x faster
> >    sink-huge-activation                              20.1568+-1.9793        
> > 20.0931+-2.8004        
> >    sinkable-new-object-dag                           71.8883+-4.2435        
> > 69.5264+-4.7627          might be 1.0340x faster
> >    sinkable-new-object-taken                         58.1786+-3.2766        
> > 53.0621+-2.3383          might be 1.0964x faster
> >    sinkable-new-object                               42.2274+-3.2275        
> > 41.4475+-3.2643          might be 1.0188x faster
> >    slow-array-profile-convergence                     3.2567+-0.2881     ?  
> > 3.2681+-0.6965        ?
> >    slow-convergence                                   3.1827+-0.3755        
> > 3.1164+-0.3555          might be 1.0213x faster
> >    slow-ternaries                                    22.2468+-3.1090        
> > 21.1529+-1.6497          might be 1.0517x faster
> >    sorting-benchmark                                 23.0539+-1.5801     ?  
> > 24.5531+-3.5066        ? might be 1.0650x slower
> >    sparse-conditional                                 2.0818+-0.6262        
> > 1.9067+-0.5387          might be 1.0919x faster
> >    splice-to-remove                                  15.0973+-0.8389     ?  
> > 15.3209+-1.1898        ? might be 1.0148x slower
> >    string-char-code-at                               16.2507+-1.0273     ?  
> > 18.0287+-3.5918        ? might be 1.1094x slower
> >    string-concat-object                               2.9637+-0.3589        
> > 2.8384+-0.2461          might be 1.0442x faster
> >    string-concat-pair-object                          2.9768+-0.6081        
> > 2.7581+-0.1019          might be 1.0793x faster
> >    string-concat-pair-simple                         12.2701+-0.6880     ?  
> > 12.7271+-1.7991        ? might be 1.0373x slower
> >    string-concat-simple                              13.4256+-1.8914        
> > 12.3635+-1.2296          might be 1.0859x faster
> >    string-cons-repeat                                 9.0182+-0.6097        
> > 8.7467+-0.9738          might be 1.0310x faster
> >    string-cons-tower                                  9.3907+-1.2447        
> > 9.3211+-0.7306        
> >    string-equality                                   22.0378+-2.5024     ?  
> > 22.5072+-1.5254        ? might be 1.0213x slower
> >    string-get-by-val-big-char                         9.0933+-0.6653     ?  
> > 9.5767+-1.6084        ? might be 1.0532x slower
> >    string-get-by-val-out-of-bounds-insane             3.7552+-0.2094     ?  
> > 4.2209+-0.6238        ? might be 1.1240x slower
> >    string-get-by-val-out-of-bounds                    5.9472+-1.1375        
> > 5.6396+-1.2327          might be 1.0546x faster
> >    string-get-by-val                                  4.2775+-0.8043        
> > 4.0179+-0.7219          might be 1.0646x faster
> >    string-hash                                        2.9662+-0.6404        
> > 2.5635+-0.2140          might be 1.1571x faster
> >    string-long-ident-equality                        18.5957+-1.2897        
> > 17.9845+-1.3679          might be 1.0340x faster
> >    string-out-of-bounds                              13.8291+-1.0544     ?  
> > 14.6154+-1.0221        ? might be 1.0569x slower
> >    string-repeat-arith                               30.5954+-0.8910     ?  
> > 31.8996+-1.6623        ? might be 1.0426x slower
> >    string-sub                                        40.4389+-0.9658        
> > 39.9894+-1.7412          might be 1.0112x faster
> >    string-test                                        3.5357+-0.3190        
> > 3.3853+-0.1459          might be 1.0444x faster
> >    string-var-equality                               34.6604+-1.1793        
> > 33.5125+-1.5620          might be 1.0343x faster
> >    structure-hoist-over-transitions                   3.3355+-0.5213        
> > 3.0807+-0.3825          might be 1.0827x faster
> >    substring-concat-weird                            46.1805+-1.6207     ?  
> > 46.3406+-2.7454        ?
> >    substring-concat                                  57.0645+-13.3429       
> > 53.4352+-6.9816          might be 1.0679x faster
> >    substring                                         57.6203+-2.0547        
> > 55.6892+-1.4337          might be 1.0347x faster
> >    switch-char-constant                               4.3092+-1.7710        
> > 3.1834+-0.1790          might be 1.3537x faster
> >    switch-char                                       11.0283+-1.4521        
> > 10.4748+-1.1642          might be 1.0528x faster
> >    switch-constant                                   10.9519+-2.2607        
> > 9.9019+-0.9154          might be 1.1060x faster
> >    switch-string-basic-big-var                       17.3214+-1.4664     ?  
> > 18.1223+-1.5923        ? might be 1.0462x slower
> >    switch-string-basic-big                           17.0872+-0.4456     ?  
> > 17.7165+-1.6952        ? might be 1.0368x slower
> >    switch-string-basic-var                           16.1556+-0.9378     ?  
> > 16.6256+-1.1177        ? might be 1.0291x slower
> >    switch-string-basic                               15.5796+-0.9208        
> > 15.3817+-1.1674          might be 1.0129x faster
> >    switch-string-big-length-tower-var                22.9624+-1.2374        
> > 22.5221+-1.6335          might be 1.0195x faster
> >    switch-string-length-tower-var                    19.2947+-4.4788        
> > 16.5537+-1.4153          might be 1.1656x faster
> >    switch-string-length-tower                        14.8631+-1.7186        
> > 14.1871+-0.8592          might be 1.0476x faster
> >    switch-string-short                               14.8657+-1.3236        
> > 13.8862+-0.5115          might be 1.0705x faster
> >    switch                                            15.0835+-2.3002     ?  
> > 15.5885+-2.1539        ? might be 1.0335x slower
> >    tear-off-arguments-simple                          4.5382+-1.0854        
> > 4.1415+-0.2787          might be 1.0958x faster
> >    tear-off-arguments                                 6.4166+-0.8333     ?  
> > 9.0220+-4.6615        ? might be 1.4060x slower
> >    temporal-structure                                14.8082+-1.6891        
> > 14.7939+-2.1990        
> >    to-int32-boolean                                  15.5916+-0.9812        
> > 15.2537+-0.5905          might be 1.0222x faster
> >    try-catch-get-by-val-cloned-arguments             11.9802+-0.8643     ?  
> > 13.0450+-1.5913        ? might be 1.0889x slower
> >    try-catch-get-by-val-direct-arguments              2.8929+-0.2201     ?  
> > 3.1169+-0.3813        ? might be 1.0775x slower
> >    try-catch-get-by-val-scoped-arguments              8.1305+-1.4487     ^  
> > 6.0885+-0.5280        ^ definitely 1.3354x faster
> >    typed-array-get-set-by-val-profiling              38.3729+-1.8562        
> > 37.6868+-2.7886          might be 1.0182x faster
> >    undefined-property-access                        266.0795+-5.2251     ?  
> > 270.9898+-12.9622       ? might be 1.0185x slower
> >    undefined-test                                     3.6747+-0.4429        
> > 3.5663+-0.3447          might be 1.0304x faster
> >    unprofiled-licm                                   11.1497+-0.5764     ?  
> > 11.6986+-1.6184        ? might be 1.0492x slower
> >    varargs-call                                      17.5866+-1.2784     ?  
> > 17.5916+-0.5779        ?
> >    varargs-construct-inline                          27.4853+-2.4368     ?  
> > 28.5149+-2.4999        ? might be 1.0375x slower
> >    varargs-construct                                 24.8192+-1.5740     ?  
> > 25.5864+-1.6675        ? might be 1.0309x slower
> >    varargs-inline                                    10.3187+-0.3045     ?  
> > 10.4608+-0.5664        ? might be 1.0138x slower
> >    varargs-strict-mode                               12.8903+-2.0868        
> > 11.3240+-0.5334          might be 1.1383x faster
> >    varargs                                           11.0105+-0.1867     ?  
> > 12.2509+-1.5407        ? might be 1.1127x slower
> >    weird-inlining-const-prop                          3.1506+-0.3918     ?  
> > 3.3766+-0.5321        ? might be 1.0717x slower
> > 
> >    <geometric>                                       10.3263+-0.0618     ?  
> > 10.3342+-0.0867        ? might be 1.0008x slower
> > 
> >                                                             og              
> > arrow                                       
> > Geomean of preferred means:
> >    <scaled-result>                                   33.7818+-0.5111     ?  
> > 34.1329+-0.3176        ? might be 1.0104x slower

[Yusuke Suzuki]

(In reply to comment #164)
> 
> I've run benchmarks on Linux, and I don't see it being this slow.

https://gist.github.com/Constellation/a5cd0256bde09b5d2c68
   <arithmetic>                                       6.7587+-0.2600     ?      6.8858+-0.3450        ? might be 1.0188x slower
Like this... on simple Ubuntu 14.04 desktop with closing all apps. (but it's not related to this issue anyway ;) )

[Saam Barati]

Here are two different runs of sunspider and one run of longspider.
Looks OK to me. What do you think Fil?

VMs tested:
"og" at /Users/saambarati/WK/Clean/WebKitBuild/Release/jsc (r193765)
"arrow" at /Users/saambarati/WK/ternary/WebKitBuild/Release/jsc (r193766)

Collected 8 samples per benchmark/VM, with 8 VM invocations per benchmark. Emitted a call to gc() between
sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific
preciseTime() function to get microsecond-level timing. Reporting benchmark execution times with 95%
confidence intervals in milliseconds.

                                      og                      arrow                                       

3d-cube                        11.1971+-2.9243            8.3388+-1.8611          might be 1.3428x faster
3d-morph                        8.9554+-1.7642     ?     11.4620+-2.5170        ? might be 1.2799x slower
3d-raytrace                    13.3040+-2.5524           12.2059+-3.5086          might be 1.0900x faster
access-binary-trees             4.8946+-1.1630     ?      5.0883+-1.7141        ? might be 1.0396x slower
access-fannkuch                13.5523+-3.9946           12.2778+-4.3036          might be 1.1038x faster
access-nbody                    5.6672+-2.5076            3.6482+-0.2888          might be 1.5534x faster
access-nsieve                   5.0020+-0.5056     ?      5.2047+-1.5672        ? might be 1.0405x slower
bitops-3bit-bits-in-byte        2.4319+-0.6144     ?      2.8114+-0.4927        ? might be 1.1561x slower
bitops-bits-in-byte             5.2761+-0.3894     ?      6.0585+-1.9272        ? might be 1.1483x slower
bitops-bitwise-and              3.2231+-0.5712            2.8692+-0.3641          might be 1.1233x faster
bitops-nsieve-bits              5.5760+-0.9808            5.0917+-0.8403          might be 1.0951x faster
controlflow-recursive           5.7759+-1.5147            5.2474+-0.8221          might be 1.1007x faster
crypto-aes                      8.2600+-1.1792            7.9868+-2.2211          might be 1.0342x faster
crypto-md5                      7.4995+-1.7611            6.1377+-1.7272          might be 1.2219x faster
crypto-sha1                     4.9498+-1.5105     ?      5.2373+-0.9113        ? might be 1.0581x slower
date-format-tofte              16.1994+-2.4508     ?     17.2664+-3.1303        ? might be 1.0659x slower
date-format-xparb               9.1422+-2.2081     ?     10.0741+-2.0501        ? might be 1.1019x slower
math-cordic                     6.1152+-1.2756     ?      6.4916+-1.5066        ? might be 1.0616x slower
math-partial-sums               7.9380+-1.2882     ?      8.4283+-2.2624        ? might be 1.0618x slower
math-spectral-norm              3.7763+-0.9330     ?      5.1641+-1.2707        ? might be 1.3675x slower
regexp-dna                      8.8793+-1.1182            8.2438+-0.7173          might be 1.0771x faster
string-base64                   8.7371+-1.7754            7.9720+-1.9167          might be 1.0960x faster
string-fasta                   11.4577+-2.1522     ?     12.0093+-4.2335        ? might be 1.0481x slower
string-tagcloud                14.5190+-2.9123     ?     16.4438+-3.2625        ? might be 1.1326x slower
string-unpack-code             36.8401+-6.3663     ?     37.8590+-4.5574        ? might be 1.0277x slower
string-validate-input           9.2313+-1.3777            8.0797+-1.1960          might be 1.1425x faster

<arithmetic>                    9.1692+-0.5335            9.1422+-0.4078          might be 1.0030x faster



VMs tested:
"og" at /Users/saambarati/WK/Clean/WebKitBuild/Release/jsc (r193765)
"arrow" at /Users/saambarati/WK/ternary/WebKitBuild/Release/jsc (r193766)

Collected 8 samples per benchmark/VM, with 8 VM invocations per benchmark. Emitted a call to gc() between
sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific
preciseTime() function to get microsecond-level timing. Reporting benchmark execution times with 95%
confidence intervals in milliseconds.

                                      og                      arrow                                       

3d-cube                         9.6088+-2.6027     ?     10.4557+-5.3544        ? might be 1.0881x slower
3d-morph                        8.0501+-0.8959     ?      8.6181+-2.6335        ? might be 1.0706x slower
3d-raytrace                    13.4970+-3.6690           10.2892+-1.2474          might be 1.3118x faster
access-binary-trees             4.1437+-1.3518     ?      4.3534+-1.2479        ? might be 1.0506x slower
access-fannkuch                12.5846+-7.7778           11.2443+-7.1131          might be 1.1192x faster
access-nbody                    3.8764+-0.4017     ?      7.2526+-5.9725        ? might be 1.8710x slower
access-nsieve                   5.2353+-0.9890     ?      5.3614+-1.1405        ? might be 1.0241x slower
bitops-3bit-bits-in-byte        2.6994+-0.8289            2.5579+-0.4516          might be 1.0553x faster
bitops-bits-in-byte             6.1735+-1.3650            4.8952+-0.7169          might be 1.2611x faster
bitops-bitwise-and              2.7338+-0.1589            2.5470+-0.0679          might be 1.0733x faster
bitops-nsieve-bits              6.6436+-3.4889            5.0491+-0.7367          might be 1.3158x faster
controlflow-recursive           5.1042+-1.1157     ?      5.2909+-1.3070        ? might be 1.0366x slower
crypto-aes                      7.4602+-2.2039            6.4609+-0.9275          might be 1.1547x faster
crypto-md5                      5.8375+-1.4797     ?      6.3438+-1.2117        ? might be 1.0867x slower
crypto-sha1                     4.7869+-1.0691     ?      5.1622+-1.2222        ? might be 1.0784x slower
date-format-tofte              14.2384+-2.4922     ?     15.5785+-1.6542        ? might be 1.0941x slower
date-format-xparb               8.1640+-1.4987            7.1250+-0.9514          might be 1.1458x faster
math-cordic                     5.6341+-0.5853     ?      7.4354+-2.5841        ? might be 1.3197x slower
math-partial-sums               6.4926+-1.0302     ?      7.2438+-1.0040        ? might be 1.1157x slower
math-spectral-norm              4.5004+-1.1741            3.8982+-0.9674          might be 1.1545x faster
regexp-dna                      8.4105+-1.0031            8.0697+-0.6484          might be 1.0422x faster
string-base64                   7.1721+-1.0922            5.9737+-0.9375          might be 1.2006x faster
string-fasta                   10.8064+-2.0836     ?     11.3127+-1.5347        ? might be 1.0468x slower
string-tagcloud                12.9251+-1.3498           12.8169+-2.4959        
string-unpack-code             33.1742+-3.0602     ?     37.4317+-8.8420        ? might be 1.1283x slower
string-validate-input           9.8634+-4.2238            8.1750+-1.6476          might be 1.2065x faster

<arithmetic>                    8.4545+-0.5807     ?      8.4978+-0.3724        ? might be 1.0051x slower



VMs tested:
"og" at /Users/saambarati/WK/Clean/WebKitBuild/Release/jsc (r193765)
"arrow" at /Users/saambarati/WK/ternary/WebKitBuild/Release/jsc (r193766)

Collected 8 samples per benchmark/VM, with 8 VM invocations per benchmark. Emitted a call to gc() between
sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific
preciseTime() function to get microsecond-level timing. Reporting benchmark execution times with 95%
confidence intervals in milliseconds.

                                      og                      arrow                                       

3d-cube                       983.6629+-7.3041          977.7889+-8.9220        
3d-morph                     1862.9138+-26.4699        1858.1499+-36.4189       
3d-raytrace                   759.2477+-31.5693    ?    764.6617+-13.0372       ?
access-binary-trees          1088.7659+-23.3818    ?   1095.3451+-18.7199       ?
access-fannkuch               384.5294+-19.0932         374.4949+-15.5948         might be 1.0268x faster
access-nbody                  648.5317+-19.8080         639.8604+-9.2268          might be 1.0136x faster
access-nsieve                 560.6813+-3.9171     ?    567.9668+-9.7800        ? might be 1.0130x slower
bitops-3bit-bits-in-byte       40.4560+-1.5358     ?     40.9757+-1.3431        ? might be 1.0128x slower
bitops-bits-in-byte           108.4200+-8.4577          102.2412+-5.0243          might be 1.0604x faster
bitops-nsieve-bits            605.0081+-18.2534    ?    613.8606+-23.6750       ? might be 1.0146x slower
controlflow-recursive         547.9805+-7.9070     ?    551.3894+-4.1348        ?
crypto-aes                    690.1426+-24.7170         682.9080+-14.9937         might be 1.0106x faster
crypto-md5                    645.9974+-57.8796         641.0034+-45.9257       
crypto-sha1                   801.3771+-6.5853          801.1111+-21.4325       
date-format-tofte             734.4837+-38.3651         696.2906+-14.6269         might be 1.0549x faster
date-format-xparb             812.8120+-52.3705         799.0730+-18.5168         might be 1.0172x faster
hash-map                      191.8232+-10.5255    ?    194.7395+-8.2621        ? might be 1.0152x slower
math-cordic                   606.2941+-6.5982     ?    613.2130+-6.7173        ? might be 1.0114x slower
math-partial-sums             570.8638+-5.7038          565.4881+-8.3491        
math-spectral-norm            691.6819+-9.2737     ?    692.3966+-8.8570        ?
string-base64                 457.8477+-16.1481         452.6420+-12.3503         might be 1.0115x faster
string-fasta                  446.1532+-13.8048         445.3811+-11.5595       
string-tagcloud               215.2516+-7.1811     ?    226.0484+-13.9470       ? might be 1.0502x slower

<geometric>                   501.8473+-2.8435          500.2195+-2.7199          might be 1.0033x faster

[Michael Saboff]

(In reply to comment #167)
> Here are two different runs of sunspider and one run of longspider.
> Looks OK to me. What do you think Fil?
> 
...

The two sunspider runs look very noisy.  The longspider looks fine.