January 2012 - squirrelfish-dev - lists.macosforge.org

block scope work
by Andy Wingo 12 Mar '12

12 Mar '12

Hey folks, As you mentioned, we should probably discuss my block scope on a higher level than individual bugs. What I have is a series of patches that implement "block scoping" for const in strict mode, in the ES6 sense of the phrase. I wasn't familiar with JSC internals before developing this patch series, so it has been an educational experience ;) Therefore, if in the end we need to take another implementation strategy, I'm fine with that. I just needed to dive in and get something done in order to get productive with the code base. Now, on to specifics. There is a similarity between ES6 block scope and the scoping of the function name, in named function expressions, and the exception identifier, in catch clauses. It seems to me that whatever ES6 block scope implementation that JSC gets should also be available in non-strict mode in these two specific cases. To implement block scoping, you start with the parser. In general there is a tree of block scopes for every function, and the existence of block scope imposes constraints for normal "var" declarations, like: // assuming strict mode { const x = 10; var x = 20 } // error { const x = 10; { var x = 20; } } // error { var x = 10; const x = 20; } // error { const x = 10; const x = 20; } // error { var x = 10; { const x = 20; } } // OK { const x = 10; { const x = 20; } } // OK Before block scope, you don't have to bother with much of this, as all vars are hoisted to the function, global, or eval code node. With block scope, you need to maintain nested scopes at compile time. You also need to maintain nested scopes at runtime, in the general case: function foo(x) { var y = 10; if (x) { const z = 20; { return function(x){eval(x);} } } return function(x){eval(x)}; } foo(1)('y') => 10 foo(1)('z') => 20 foo(0)('z') => error But it would be nice to have access to multiple scopes without pushing scope objects ever: function foo() { var x = 10; { const y = 20; // allocate in a register in the function codeblock return x + y; } } So. Let me walk you through my set of patches. It took me a while to rebase them on top of the suggested refactor, and I haven't had time yet to properly consider the lazy tearoff suggestion, so do keep it in mind -- but I wanted to show what I have so that at least we are talking about the same thing. * Refactor identifier resolution in BytecodeGenerator https://bugs.webkit.org/show_bug.cgi?id=76285 This is ResolveResult location = generator.resolve(m_ident). Performance-neutral, seems like a win refactoring-wise. * Interpose CodeNode between ScopeNode and ProgramNode et al https://bugs.webkit.org/show_bug.cgi?id=74509 This one pulls apart the concerns of holding a codeblock and being a variable scope into separate classes, looking forward to adding a BlockScopeNode. You do need something to hold scoping information at parse and compile time, and I think this is a fine element of the AST for that. A block scope node may or may not correspond to an object in the scope chain at runtime though: it could be that all of the bindings may be hoisted to an outer scope. It could be that some bindings get hoisted. You might need a symbol table, you might not. But I think there are enough things that are different about functions and blocks in ES that it's worth dividing this. * Avoid double-lookup when setting static-scoped vars in strict mode https://bugs.webkit.org/show_bug.cgi?id=74628 * Allow JSStaticScope to bind more than one variable https://bugs.webkit.org/show_bug.cgi?id=74633 These makes sense iff we go with a JSStaticScope chain. Dunno, for me they win either way, but there is room to differ here... * Optimize access to block-scoped local variables https://bugs.webkit.org/show_bug.cgi?id=74708 Here we get interesting! We track block scopes at compile time. Note, we have to do this with either implementation strategy; it's not sufficient to just push on a block and call it the current compilation unit, because of how many ES things work on a function level (e.g. `return'). I really like what this patch does to the bytecompiler, but the runtime support is nasty: I still have those negative depths in there. Not sure what to do about it, but I suppose it's related to the ultimate choice of how block scopes should work. I guess I should mention that this patch will allocate all block-scoped variables in JSStaticScope objects on the heap. This is not good. In many cases, we will be able to allocate them in registers in the function instead, in the future. However there is a bright side here, and that's that `var' access still goes through registers. The lazy tear-off solution does have the disadvantage that it penalizes `var' access within blocks, or access to any block-scoped let/const in an outer scope. (A block doesn't logically capture a variable; only a function or eval does.) Anyway. It's there. * Remove the `value' argument to op_push_new_scope https://bugs.webkit.org/show_bug.cgi?id=74718 A refactor, assuming the use of static scope objects.. * Implement block-scoped const in strict mode --harmony https://bugs.webkit.org/show_bug.cgi?id=74725 I removed the pieces in this patch that referenced runtime options, and indeed I removed the #if ENABLE(ES6) stuff as well; it was hindering the discussion, and in the end things should be able to work together, so I figured for the time being, it would be OK without the guards. * * * I'm sorry this mail is so long; as the man said, I didn't have time to make it shorter. But this does give a general overview of the work. I pushed new versions of my patches just as talking points, really; I want something to go in, but I agree we need to talk it over first, and maybe come to some alternate strategies. So. I'm all ears :) Let me know what you think. Andy

4 18

a patch to slow down jsc
by Andy Wingo 28 Feb '12

28 Feb '12

Hello list! I was poking about the parser recently and thought I could clean up some of the shenanigans there. I came up with the attached patch, which seems to slow down sunspider by about half a percent. My question is, why is this? It would seem to be easier on the allocator to make one object than two. Is WTF_MAKE_FAST_ALLOCATED really so powerful that it's worth splitting objects into multiple pieces? Just wondering :) Cheers, Andy

2 2

Easy way to understand SFX source code
by wingoog moon 31 Jan '12

31 Jan '12

Hi all. I'm trying to understand SFX source code for a week but there are over 20 000 lines of code and very poor comments. So it seems inposiible to me to understand SFX workflow((((( Is there any spechial way to do that??? Maybe somе advices or tips? Thanks!!

1 0

(no subject)
by wingoog moon 07 Jan '12

07 Jan '12

HI!! I know that DFG JIT can do some general optimizatiopns such as CSE,OSR,dead code eliminations. But all these optimizations are machine independent. So what machine dependent optimizations DFG JIT can do???(for inatance for ARM platform)

2 1