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

cti functions and emit_op_new_array
by wingoog moon 03 Apr '12

03 Apr '12

Hi!! Trying to understand cti functions on the example of emit_op_new_array functions. Here is the code of emit_op_new_array void JIT::emit_op_new_array(Instruction* currentInstruction) { JITStubCall stubCall(this, cti_op_new_array); stubCall.addArgument(Imm32(currentInstruction[2].u.operand)); stubCall.addArgument(Imm32(currentInstruction[3].u.operand)); stubCall.call(currentInstruction[1].u.operand); } As I understand stubCall.call(currentInstruction[1].u.operand) calls function DEFINE_STUB_FUNCTION(JSObject*, op_new_array) from JITStubs.cpp. And at this point execution of our JS programm is "interputing" and here C functions starting to work to "create array". The question is how can I get reference to the craeted array to manipulate it in future? And in general, can anyone please explain in detail how this scheme of cti functions works? Thanks!

2 2

block scope status, march edition
by Andy Wingo 26 Mar '12

26 Mar '12

Hi, I have been plugging away at the block scope stuff. My current work is on https://bugs.webkit.org/show_bug.cgi?id=74708. Like some other patches, it uses catch clauses as the proof of concept, because there are so many tests around that area. It does lazy creation and tear-off if possible, and only in the case in which a scope has captured variables. I have two remaining things to fix before it is fully baked. One is static lookup of free variables (e.g. ResolveResult::Lexical variables). The issue is that with lazy scope creation ("reification") the depth in the scope chain cannot be computed statically. Let's say you are resolving "foo" in: (function () { var foo = 1; return function () { var bar = 3; function qux(x) { return bar+x; } return bar + foo; } })() Here, both functions will lazily create their activations. (I put in the qux to make sure the inner function has a lazy activation.) Here is their bytecode: Outer: 32 m_instructions; 256 bytes at 0xb10cf0; 1 parameter(s); 12 callee register(s); 4 variable(s) [ 0] enter [ 1] init_lazy_reg r0 [ 3] init_lazy_reg r2 [ 5] init_lazy_reg r1 [ 7] mov r3, Int32: 1(@k0) [ 10] create_activation r0 [ 12] new_func_exp r4, f0 [ 15] mov r5, Undefined(@k1) [ 18] call r4, 1, 12 [ 24] op_call_put_result r4 [ 27] tear_off_activation r0, r2 [ 30] ret r4 Constants: k0 = Int32: 1 k1 = Undefined Inner: 27 m_instructions; 216 bytes at 0xb0c930; 1 parameter(s); 6 callee register(s); 5 variable(s) [ 0] enter [ 1] init_lazy_reg r0 [ 3] init_lazy_reg r2 [ 5] init_lazy_reg r1 [ 7] init_lazy_reg r4 [ 9] mov r3, Int32: 3(@k0) [ 12] get_scoped_var r5, 3, 1 [ 17] add r5, r3, r5 [ 22] tear_off_activation r0, r2 [ 25] ret r5 Constants: k0 = Int32: 3 Note the get_scoped_var in the inner function, corresponding to the resolution of "foo". It indicates that "foo" can be found in the third register of the scope object one scope deep. However there might be an additional object on the scope chain, corresponding to the lazily created activation of the inner function. There is explicit code to account for skipping over an activation in the implementations of put_scoped_var and get_scoped_var. But with more lazily reified scopes that may or may not be on the scope chain (depending on whether the code path traversed a with, eval, or function expression), such an approach doesn't work. You can't determine the static depth from the top of the scope chain, because you'd like to avoid creating the entire scope chain if you can. I suggest that we change the users of scope chains (eval, with, and function expressions) to receive the scope chain register as a parameter. The compiler already has to handle lazy scope creation, so it's just as easy to put the scope in a temporary as it is to put it in the callframe. Free variable lookup will continue to use the register in the callframe. As a bonus, that code can be simpler because it doesn't have to check if the there is an activation or not. OK, that's one. The second issue is handling temporal dead zone errors. In ES6 it is a SyntaxError if you access the value of a let- or const-bound variable before it is initialized. In practice this means that in the general case, we mark uninitialized variables with a sentinel value (JSValue(), via init_lazy_reg). Access to let- or const-bound variables that need a barrier is preceded by a check that the variable is initialized. We can prove for some cases that no barrier is needed, and elide the barrier, but OK. My question is how to structure this check. Currently I have an assert_lazy_reg_init opcode that throws an error if the value isEmpty(). I guess we need to associate a name with that error too, so that opcode should take an identifier as a parameter as well. WDYT? Currently there is also an assert_lazy_reg_not_init opcode, but that was based on a misunderstanding -- you can only initialize const variables, not assign to them. Hence initialization doesn't need such a check. Finally, two more thoughts. One is that we can use op_reify_scope / op_tear_off_scope for parameters and locals in some cases, if a function does not have non-strict eval, as Gavin suggested. Also I hope to get a patch for "const" in today. The break-the-web aspect is a bit tricky, but we'll see how that goes. Thanks for comments! Andy -- http://wingolog.org/

4 6

Opaque roots questions
by Yanov, Andrey 26 Mar '12

26 Mar '12

Hi everyone. Could someone please explain 1. where opaque roots are created and 2. how to parse (print to file) all its children recursively ? I'm trying to trace JSAudioElement not being deleted and need to trace which root it belongs to. Please don't be ignorant ) Andrey ________________________________ This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.

1 0

Implement SFX ctiTrampoline function in SH4 ARCH Base MSVS2008
by talking1239＠gmail.com 23 Mar '12

23 Mar '12

Hi, If this topic should not send to this mail address, please tell me which mail address i should send this topic, thanks. Is anyone is familair with SH-4 inline assemble in the MSVS2008 SDK, i implement the ctiTrampolinen function as follow code, but it will be crashed when run javascript code, extern "C" { void __asm(const char *, ...); /* code (r4), RegisterFile* (r5), CallFrame* (r6), JSValue* exception (r7), Profiler**(sp), JSGlobalData (sp)*/ EncodedJSValue ctiTrampoline(void* code, RegisterFile* registerFile, CallFrame* callframe, JSValue* exception, Profiler** profiler, JSGlobalData* jsGlobalData) { EncodedJSValue result; __asm( "mov.l r7, @-r15 \n" "mov.l r6, @-r15 \n" "mov.l r5, @-r15 \n" "mov.l r8, @-r15 \n" "mov #127, r8 \n" "mov.l r14, @-r15 \n" "sts.l pr, @-r15 \n" "mov.l r13, @-r15 \n" "mov.l r11, @-r15 \n" "mov.l r10, @-r15 \n" "add #-60, r15 \n" "mov r6, r14 \n" "jsr @r4 \n" "nop \n" "add #60, r15 \n" "mov.l @r15+,r10 \n" "mov.l @r15+,r11 \n" "mov.l @r15+,r13 \n" "lds.l @r15+,pr \n" "mov.l @r15+,r14 \n" "mov.l @r15+,r8 \n" "add #12, r15 \n" "rts \n" "nop \n" "mov.l @(24,sp), r0 \n", code, registerFile, callframe, exception, *profiler, jsGlobalData, &result ); return result; } -- BGs/Felix Shi

2 1

Question about SlotVisitor::drain()
by Yanov, Andrey 20 Mar '12

20 Mar '12

Hi everyone, I'm investigating one issue regarding HTMLAudioElement objects leakage on a cuttherope.ie page on a custom QNX port. What I've found so far is that JS object, holding WebCore::HTMLAudioElement is not deleted. To be short, markRoots is called from collectAllGarbage(). In markRoots() the code m_handleHeap.visitStrongHandles(heapRootVisitor); visitor.drain(); leads to marking JSHTMLAudioElement as being in use (testAndSetMarked()). This way, I have a weird situation: I've navigated away from the page but the audio objects are marked as being in use. Could you please direct me where I should dig further ? What should I check ? Am I correct that there elements are stored as strong handles ? Who decides which objects should be weak and which should be strong ? Thank you for any help. Andrey ________________________________ This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you.

1 0

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

CallFrame vs ExecState: FIGHT
by Andy Wingo 07 Mar '12

07 Mar '12

Hello! Ye olde https://bugs.webkit.org/show_bug.cgi?id=21295 from 2008 has a hopeful note that CallFrame is the new ExecState. Is this still the general desire? I'm sure I'll remember after this thread, but I've been confusing these for a long time now. We should choose one name or the other. I'm happy to file a mega-patch if there is consensus as to what to do. Thoughts? Regards, Andy

3 3