June 2010 - squirrelfish-dev - lists.macosforge.org

Coalescing slow cases to improve JIT memory usage.
by Nathan Lawrence 26 Jun '10

26 Jun '10

The size of our JIT generated code is a memory known issue. According to Oliver the slow cases for some of our operations is on the order of 128 bytes. It occurred to me that we could reduce the JITed code by only compiling the slow case once and having all of the subsequent generated code jump to that specific slow case. The issue with this is our slow cases jump back to specific locations in the hot path, with potentially different values on the stack, as opposed to a normal function which returns back to a very specific state. We can circumvent this issue by hand writing the assembly to return to an offset of the return address with the required state. What do people think? -- Nathan

5 5

Exceptions in JSC C API
by Jedrzej Nowacki 14 Jun '10

14 Jun '10

Hi, I would like to ask about an exception handling policy in JSC C API implementation. After checking the code I found a common pattern: (A) if (exec->hadException()) { if (exception) *exception = toRef(exec, exec->exception()); exec->clearException(); } Which means that exception handler value is set only when an exception occurs. Another approach that I found is in JSValueCreateJSONString: (B) if (exception) *exception = 0; if (exec->hadException()) { if (exception) *exception = toRef(exec, exec->exception()); exec->clearException(); } That code always set exception handler. Advantage of this solution (B) is that after call, an api user can check if actually an exception occured by checking value of the exception handler (it was possible with the first approach (A) by initialize exception handler to null, but it is rather a side effect). The B pattern is not optimal, because the exception handler may be reinitialized. I believe that an exception handler should be used for simple error checking; - there is not null exception value => it means that returned value is not valid, because of an error. - there is null exception => everything is ok. What do you think about code C? (C) if (exception) { if (exec->hadException()) { *exception = toRef(exec, exec->exception()); exec->clearException(); } else *exception = 0; } else exec->clearException(); In this case exception handler is always set correctly. Would it make sense to change the behavior? The change unifies interface and is binary compatible. It shouldn't break a correct code... :-) Cheers, Jędrek

3 3

3 instructions
by Fern Moon 12 Jun '10

12 Jun '10

I am testing the interpreter in the webkit and the JIT is disabled. I always find that the following 3 instructions get compiled, but never get executed in the interpreter. [ 0] enter [ 1] sub r0, r-10, r-9 [ 6] ret r0 What are those instructions for ? Will them get executed someplace else? Thanks Fern

2 1