Bug 195901 – [JSC] Generator should not create JSLexicalEnvironment if it is not necessary

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

[Yusuke Suzuki]

When looking into the cells allocated in JetStream2 Basic, I found that so many empty JSLexicalEnvironments are allocated.
I think this is because the current implementation of ES6 Generators always allocates JSLexicalEnvironments for their suspend and resume.
However it seems that fair amount of generators do not load and store registers, and we are allocating empty JSLexicalEnvironments.
Currently, still I'm investigating, but if it is true, we should emit op_create_lexical_environment only when the generatorification says it is required.

[Yusuke Suzuki]

(In reply to Yusuke Suzuki from comment #0)
> When looking into the cells allocated in JetStream2 Basic, I found that so
> many empty JSLexicalEnvironments are allocated.
> I think this is because the current implementation of ES6 Generators always
> allocates JSLexicalEnvironments for their suspend and resume.
> However it seems that fair amount of generators do not load and store
> registers, and we are allocating empty JSLexicalEnvironments.
> Currently, still I'm investigating, but if it is true, we should emit
> op_create_lexical_environment only when the generatorification says it is
> required.

In addition to memory footprint improvement, it potentially brings performance improvement.

[Yusuke Suzuki]

(In reply to Yusuke Suzuki from comment #1)
> (In reply to Yusuke Suzuki from comment #0)
> > When looking into the cells allocated in JetStream2 Basic, I found that so
> > many empty JSLexicalEnvironments are allocated.
> > I think this is because the current implementation of ES6 Generators always
> > allocates JSLexicalEnvironments for their suspend and resume.
> > However it seems that fair amount of generators do not load and store
> > registers, and we are allocating empty JSLexicalEnvironments.=

Hmm, it seems this is not correct. But it seems that it is correct that Basic allocates so many empty JSLexicalEnvironments. I'm investigating what is going on.

[Yusuke Suzuki]

(In reply to Yusuke Suzuki from comment #2)
> (In reply to Yusuke Suzuki from comment #1)
> > (In reply to Yusuke Suzuki from comment #0)
> > > When looking into the cells allocated in JetStream2 Basic, I found that so
> > > many empty JSLexicalEnvironments are allocated.
> > > I think this is because the current implementation of ES6 Generators always
> > > allocates JSLexicalEnvironments for their suspend and resume.
> > > However it seems that fair amount of generators do not load and store
> > > registers, and we are allocating empty JSLexicalEnvironments.=
> 
> Hmm, it seems this is not correct. But it seems that it is correct that
> Basic allocates so many empty JSLexicalEnvironments. I'm investigating what
> is going on.

No, it was correct. We are allocating empty JSLexicalEnvironment due to empty generator.

[Yusuke Suzuki]

Created attachment 365095 [details]
Patch

[Saam Barati]

Comment on attachment 365095 [details]
Patch

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

> Source/JavaScriptCore/ChangeLog:11
> +        are allocated in RAMification Basic test.

"RAMification Basic" => "RAMification's Basic"

> Source/JavaScriptCore/bytecode/BytecodeGeneratorification.cpp:286
> +        rewriter.insertFragmentAfter(instruction, [&](BytecodeRewriter::Fragment& fragment) {

style nit: I think space between "]" and "("

> Source/JavaScriptCore/bytecode/BytecodeGeneratorification.cpp:288
> +                // Generator frame is not necessary. Let's remove it if we can.

Let's rename this comment to say something like:
"This will cause us to put jsUndefined() into the generator frame's scope value."

> Source/JavaScriptCore/bytecode/BytecodeUseDef.h:160
> +    USES(OpCreateGeneratorFrameEnvironment, scope)

Do we not need to use initialValue/SymbolTable here?

> Source/JavaScriptCore/bytecode/BytecodeUseDef.h:368
> +    USES(OpCreateGeneratorFrameEnvironment, dst)

This needs to be DEFS

[Yusuke Suzuki]

Comment on attachment 365095 [details]
Patch

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

Thanks!

>> Source/JavaScriptCore/ChangeLog:11
>> +        are allocated in RAMification Basic test.
> 
> "RAMification Basic" => "RAMification's Basic"

Fixed.

>> Source/JavaScriptCore/bytecode/BytecodeGeneratorification.cpp:286
>> +        rewriter.insertFragmentAfter(instruction, [&](BytecodeRewriter::Fragment& fragment) {
> 
> style nit: I think space between "]" and "("

Fixed.

>> Source/JavaScriptCore/bytecode/BytecodeGeneratorification.cpp:288
>> +                // Generator frame is not necessary. Let's remove it if we can.
> 
> Let's rename this comment to say something like:
> "This will cause us to put jsUndefined() into the generator frame's scope value."

Sounds nice. Fixed.

>> Source/JavaScriptCore/bytecode/BytecodeUseDef.h:160
>> +    USES(OpCreateGeneratorFrameEnvironment, scope)
> 
> Do we not need to use initialValue/SymbolTable here?

Since op_create_lexical_environment / op_create_generator_frame_environment require that symbolTable / initialValue are constant, it will not affect on the correctness. But we can add them anyway, added.

>> Source/JavaScriptCore/bytecode/BytecodeUseDef.h:368
>> +    USES(OpCreateGeneratorFrameEnvironment, dst)
> 
> This needs to be DEFS

Fixed.

[Yusuke Suzuki]

Committed r243127: <https://trac.webkit.org/changeset/243127>

[Radar WebKit Bug Importer]

<rdar://problem/49004255>