February 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

Native code generation for put_global_var instruction on X86_64 platform
by wingoog moon 22 Feb '12

22 Feb '12

Hi! Trying to understand how put_global_var is translated to x86_64 native code. But still have several questions Lets say i have following bytecode instruction put_global_var 4, Int32: 6(@k1) Lets look at the source code void JIT::emit_op_put_global_var(Instruction* currentInstruction) { JSGlobalObject* globalObject = m_codeBlock->globalObject(); emitGetVirtualRegister(currentInstruction[2].u.operand, regT0); move(TrustedImmPtr(globalObject), regT1); loadPtr(Address(regT1, JSVariableObject::offsetOfRegisters()), regT1); storePtr(regT0, Address(regT1, currentInstruction[1].u.operand * sizeof(Register))); emitWriteBarrier(globalObject, regT0, regT2, ShouldFilterImmediates, WriteBarrierForVariableAccess); } 1. What is mean of currentInstruction[2]? As I Understand it's holds information about "Int32: 6(@k1)". Am I right?? 2. As I understand after emitGetVirtualRegister(currentInstruction[2].u.operand, regT0) we have encoded value of "Int32: 6(@k1)" in regT0. 3. Cant't understad mean of move(TrustedImmPtr(globalObject), regT1). globalObject is a pretty big class. Can't figure out what is happening here 4. loadPtr(Address(regT1, JSVariableObject::offsetOfRegisters()), regT1); // What the mean of JSVariableObject::offsetOfRegisters()?? 5. storePtr(regT0, Address(regT1, currentInstruction[1].u.operand * sizeof(Register))); // As I understand currentInstruction[1].u.operand holds address where to put my constant, i.e "4". Am I right? And question about mov instruction on x86_64 platform JSC::X86Assembler::movq_i64r void movq_i64r(int64_t imm, RegisterID dst) { m_formatter.oneByteOp64(OP_MOV_EAXIv, dst); m_formatter.immediate64(imm); } How will look appropriate assembly for this code?? Thanks for attention!!

1 0

Which type inference is used in squirrelfish
by Michael.Kang 21 Feb '12

21 Feb '12

hi everyone: I am a newbie here and interesting on JIT of javascript. In my understanding since the dynamic type of javascript, the JIT can not generate large native code block. My question is which type inference methodology in squirrelfish system is used now? I heard some news that static type inference algorithm is used in google v8 engine. Any suggestion or discussion is appreciated . Thanks MK -- www.skyeye.org

1 0

Re: [squirrelfish] [webkit-dev] Difference between jit/JITArithmetic32_64 and jit/JITArithmetic
by wingoog moon 18 Feb '12

18 Feb '12

Thanks for answer!! But what you mean when say 32_64 value representation? Do you mean it must work for 32 bit architecture?? On Fri, Feb 17, 2012 at 10:47 AM, Filip Pizlo <fpizlo(a)apple.com> wrote: > The JIT class is quite large, and so its implementation is broken up into > multiple files. The manner in which it is broken up is somewhat arbitrary, > with the main goal being to not have any outrageously large .cpp files. > Here's the intuition I use for finding what I want: > > JIT.cpp: the harness that runs the JIT and a few utility functions that > are not related to any particular bytecode opcode. > JITArithmetic.cpp: implementation of arithmetic instructions. > JITCall.cpp: implementation of calling convention, including call > instructions. > JITPropertyAccess.cpp: implementation of heap access instructions. > JITOpcodes.cpp: implementation of miscellaneous instructions that don't > fit into the above. > > But there is also a second split: the JIT can either be generating code > that uses the 32_64 value representation, or the 64-bit value > representation. These two representations require two completely different > code generators and most of the code in the JIT is specialized on one or > the other. Hence any file that is marked 32_64 (like JITArithmetic32_64) > contains implementations for the 32_64 value representation, whereas files > that do not have "32_64" in them are implementing either the 64-bit value > representation, or code that is agnostic towards value representation. > > -Filip > > > > On Feb 17, 2012, at 7:02 AM, wingoog moon wrote: > > > HI All. > > Can't understand difference between jit/JITArithmetic32_64 and > jit/JITArithmetic. > > Both of them are implementing JIT class. So when program calls functions > from JITArithmetic and when JITArithmetic32_64. > > > > I also noticed that that there is JITOpcodes class, which is also > implementing JIT class. Why we need this class. > > > > P.s > > Sorry for bad English > > thanks for answers. > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev(a)lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >

1 0