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 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.
(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.
(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.
Created attachment 365095 [details] Patch
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
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.
Committed r243127: <https://trac.webkit.org/changeset/243127>
<rdar://problem/49004255>