- squirrelfish-dev - lists.macosforge.org

Mystery of resolve_global bytecode instruction
by wingoog moon 19 Jul '12

19 Jul '12

Hi all. I'm trying to understand how resolve_global instruction works for several days. Let's look at the code void JIT::emit_op_resolve_global(Instruction* currentInstruction, bool) { // Fast case void* globalObject = m_codeBlock->globalObject(); unsigned currentIndex = m_globalResolveInfoIndex++; GlobalResolveInfo* resolveInfoAddress = &(m_codeBlock->globalResolveInfo(currentIndex)); // Check Structure of global object move(TrustedImmPtr(globalObject), regT0); //*loads address of globalObject to eax(regT0)* move(TrustedImmPtr(resolveInfoAddress), regT2);*// loads address of resolveInfoAddress to ecx(regT2)* loadPtr(Address(regT2, OBJECT_OFFSETOF(GlobalResolveInfo, structure)), regT1); addSlowCase(branchPtr(NotEqual, regT1, Address(regT0, JSCell::structureOffset()))); // Structures don't match *// Do some checking * // Load cached property // Assume that the global object always uses external storage. loadPtr(Address(regT0, OBJECT_OFFSETOF(JSGlobalObject, m_propertyStorage)), regT0); *// loads m_propertyStorage to eax* * * *// Here is interesting thing happens* *// offset member of GlobalResolveInfo class is always 0;* load32(Address(regT2, OBJECT_OFFSETOF(GlobalResolveInfo, offset)), regT1); *//move value of **GlobalResolveInfo offset member(it's always 0 ) to edx(regT1)* *//So here we always mov same value to eax(regT0), regardless of whether our global Array , String or Object* loadPtr(BaseIndex(regT0, regT1, ScalePtr), regT0); emitValueProfilingSite(); emitPutVirtualRegister(currentInstruction[1].u.operand); } So 1. What is mystery of this instruction, how it's really works let's say for this example??? var a=Array(5); var s=String; var o=Object; 2. What is in m_propertyStorage, and when it's sets? Thanks for attention!

1 0

A grumble
by Andy Wingo 04 Jul '12

04 Jul '12

Hi, I'm happy that we can set JSC options on the command line. That's great news. However, I would like to grumble a bit. This feature was originally implemented here: https://bugs.webkit.org/show_bug.cgi?id=72960 That patch was never merged, because the macrology that was added to Options.h: https://bugs.webkit.org/show_bug.cgi?id=72938 Was rolled out: https://bugs.webkit.org/show_bug.cgi?id=74807 And then something very similar was rolled back in, but with another author, and no reference to the prior work, with the same characteristics of having the defaults in the header that caused the initial rollout: https://bugs.webkit.org/show_bug.cgi?id=90420 Look, I'm happy with the direction of JSC. But trying to contribute to it can be quite a pain, and unnecessarily so. Please have a little compassion for those of us that would like to get some patches in, but do not happen to share an office with you. Regards, Andy -- http://wingolog.org/

1 0

Re: [squirrelfish] Porting DFG JIT
by Zoltan Herczeg 30 Jun '12

30 Jun '12

Hi, thanks for the reply. > label1: > ... some code > branch label3 > label2: > <watchpoint> > ... some short op (smaller than maxJumpReplacementSize) > label3: Is there anything which ensures that a watchpoint is always immediately followed by a label, which inserts the nops? So the code layout look always like this: watchpoint - multiple times allowed label - terminate the watchpoints, inserts the nops (btw on ARM we insert one nop like arithmetic instruction and one constant pool entry) wouldn't it be better, if the watchpoint would insert the nops, detects if called again (and no more nops are inserted) and the label would work as it worked before (we could get rid of one label type in this case). The operations performed by inlined labels seems too much at the moment. Regards, Zoltan

2 2

Porting DFG JIT
by Zoltan Herczeg 29 Jun '12

29 Jun '12

Hi, I think this is the best mailing list to discuss the technical questions about the porting of DFG JIT since everybody is here, still we do not pollute webkit-dev. My questions: - What is the difference between labelIgnoringWatchpoints, labelForWatchpoint, and label. - What is the difference between *_FUNCTION_WRAPPER_WITH_RETURN_ADDRESS_* macros? Are they similar to the DEFINE_STUB_FUNCTION macros? Thanks, Zoltan

2 2

while (regex.exec(string)) is surprisingly slow
by Zoltan Herczeg 15 Jun '12

15 Jun '12

Hi, I compared the following two in JSC and in v8: A: result = str.match(regex); B: while (regex.exec(str)) ++count; str was about 20M input, and regex was /./gm JSC: A: 618 ms B: 3469 ms V8: A: 2640 ms B: 1833 ms I was quite surprised that although the result is a really huge array, str.match was much faster in JSC. Is there a known reason to that? Can B be improved in JSC? Regards, Zoltan

2 1

sin is slow on 64 bit
by Zoltan Herczeg 08 Jun '12

08 Jun '12

Hi guys, I played with result differences on 32/64 bit systems today, and here is something interesting revealed by one sputnik test: sputnik/Conformance/15_Native_Objects/15.8_Math/15.8.2/15.8.2.16_sin/S15.8.2.16_A7.html Try this snippet on a 32 and a 64 bit system: #include <math.h> #include <stdio.h> int main() { int i; double d = 6.283185307179586, k; for (i = 0; i < 10000000; ++i) k = sin(d); return 0; } The 32 bit is 15x faster. Why? Because it simply calls fsin, while the 64 bit has an own SSE2 based implementation. I know x87 is obsolote and everything, but it is 15x faster... Shall we optimize this? Regards, Zoltan

3 6

inlining scopechainnode into scope objects
by Andy Wingo 30 Apr '12

30 Apr '12

Hi Gavin, hi list, As we discussed last week, it could be a good idea to inline ScopeChainNode into scope objects, effectively giving scope objects a pointer to the next object in the chain. "With" objects would be on the chain via a wrapper object. This way we remove an indirection on accessing scopes and an allocation when creating them. I'm giving it a go, as it make some block stuff easier. So far so good. The current class hierarchy looks like: JSScopeObject: A new base class, holding the next pointer, global object, and global this + JSDynamicScope: A new class, wrapping "with" objects in the scope. + JSVariableObject + JSStaticScopeObject + JSActivation + JSGlobalObject Anyway, now my question: what is the deal with the "globalThis" object? Specifically, does it exist in a 1-to-1 relationship with the global object? If so, then it's fine to have globalThis be a (possibly settable) field of JSGlobalObject. If not, I have to rethink this plan. In the meantime I'll continue pushing forward here. Regards, & comments welcome, Andy -- Igalia, S.L.

2 6

Instruction emission slow cases
by wingoog moon 17 Apr '12

17 Apr '12

Hi! As I understand there are two passes to translate SFX bytecode to the native code(functions privateCompileMainPass() and privateCompileSlowCases()). So whats the purpose of privateCompileSlowCases(). Why we need slow cases for each bytecodeInstruction? Is it needed when arguments of instruction not integer or something else? Thanks for attention!

1 0

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