Bug 147666

Summary: Interpreter::unwind shouldn't be responsible for assigning the correct scope.
Product: WebKit Reporter: Saam Barati <saam>
Component: JavaScriptCoreAssignee: Saam Barati <saam>
Status: RESOLVED FIXED    
Severity: Normal CC: basile_clement, benjamin, cdumez, commit-queue, fpizlo, ggaren, mark.lam, mmirman, msaboff, oliver, ysuzuki
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 147657    
Bug Blocks: 147374    
Attachments:
Description Flags
patch
none
patch
ggaren: review+, ggaren: commit-queue-
patch for landing. none

Saam Barati
Reported 2015-08-04 17:11:53 PDT
BytecodeGenerator should do this since it will have the necessary info to do so.
Attachments
patch (27.80 KB, patch)
2015-08-05 18:05 PDT, Saam Barati
no flags
patch (27.83 KB, patch)
2015-08-05 23:04 PDT, Saam Barati
ggaren: review+
ggaren: commit-queue-
patch for landing. (27.18 KB, patch)
2015-08-07 08:18 PDT, Saam Barati
no flags
Geoffrey Garen
Comment 1 2015-08-05 11:04:22 PDT
👍
Saam Barati
Comment 2 2015-08-05 18:05:57 PDT
WebKit Commit Bot
Comment 3 2015-08-05 18:09:28 PDT
Attachment 258326 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2635: Missing space before { [whitespace/braces] [5] Total errors found: 1 in 13 files If any of these errors are false positives, please file a bug against check-webkit-style.
Saam Barati
Comment 4 2015-08-05 23:04:33 PDT
WebKit Commit Bot
Comment 5 2015-08-05 23:09:43 PDT
Attachment 258350 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2635: Missing space before { [whitespace/braces] [5] Total errors found: 1 in 13 files If any of these errors are false positives, please file a bug against check-webkit-style.
Geoffrey Garen
Comment 6 2015-08-06 16:15:10 PDT
Comment on attachment 258350 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=258350&action=review r=me, with a fixup below > Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2840 > + m_topMostScope = addVar(); > + m_topMostScope->ref(); > + emitMove(m_topMostScope, scopeRegister()); Not new to this patch, but: Does our new lexical scoping have the behavior that we now have var registers and temporary registers interleaved with each other, such that I might have: [Var][Temp][Var][Temp] ? That's a little sad because all temporary registers prior to the last vars will "leak" in the sense that the function will never reuse them, thus bloating its stack frame size. Also, there's no need to ref m_topMostScope here because addVar() already refs. Also, if you did want to ref(), I would ask you to use RefPtr.
Saam Barati
Comment 7 2015-08-06 16:35:30 PDT
Comment on attachment 258350 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=258350&action=review >> Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2840 >> + emitMove(m_topMostScope, scopeRegister()); > > Not new to this patch, but: Does our new lexical scoping have the behavior that we now have var registers and temporary registers interleaved with each other, such that I might have: > > [Var][Temp][Var][Temp] > > ? > > That's a little sad because all temporary registers prior to the last vars will "leak" in the sense that the function will never reuse them, thus bloating its stack frame size. > > Also, there's no need to ref m_topMostScope here because addVar() already refs. > > Also, if you did want to ref(), I would ask you to use RefPtr. We don't do this. I believe we have an assert in addVar() that will prevent this from happening. It would also be wrong if we did this because it would break op_enter. The way we handle register reuse for block scope variables like "let" is that while we're generating code for the block's statements we'll reserve a non-temp register for the block scope variable. Once we're done generating code for that block scope, we will reclaim those block scoped registers. The code that does this is in pushLexicalScopeInternal and popLexicalScopeInternal and reclaimFreeRegisters. This doesn't mean that we won't have some block scoped variables that are live for the entire function. For example, functions with default parameter values will have all parameters be in a block scope that never frees its variables. (These registers will still be allocated after the "var" register locations). I'll remove the ref and land later.
Saam Barati
Comment 8 2015-08-07 08:18:32 PDT
Created attachment 258502 [details] patch for landing.
WebKit Commit Bot
Comment 9 2015-08-07 08:19:40 PDT
Attachment 258502 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:2635: Missing space before { [whitespace/braces] [5] Total errors found: 1 in 13 files If any of these errors are false positives, please file a bug against check-webkit-style.
WebKit Commit Bot
Comment 10 2015-08-07 10:41:38 PDT
Comment on attachment 258502 [details] patch for landing. Clearing flags on attachment: 258502 Committed r188136: <http://trac.webkit.org/changeset/188136>
WebKit Commit Bot
Comment 11 2015-08-07 10:41:42 PDT
All reviewed patches have been landed. Closing bug.
Chris Dumez
Comment 12 2015-08-07 11:51:17 PDT
Chris Dumez
Comment 13 2015-08-07 11:53:27 PDT
(In reply to comment #12) > Committed r188144: <http://trac.webkit.org/changeset/188144> Sorry, wrong bug. My changelog got messed up somehow.
Geoffrey Garen
Comment 14 2015-08-07 12:46:28 PDT
> The way we handle register reuse for block scope variables like "let" is that > while we're generating code for the block's statements we'll reserve a > non-temp > register for the block scope variable. Once we're done generating code for > that block scope, we will reclaim those block scoped registers. The code that > does this is in pushLexicalScopeInternal and popLexicalScopeInternal and > reclaimFreeRegisters. Oh! I get it now.
Note You need to log in before you can comment on or make changes to this bug.