Hi, the second part is true for ARM as well. Cortex A8 and A9 has a buffer with 8 entries to predict return addresses. If it fails (frequently), it flush this buffer, and this becomes a big performance loss since it cannot even predict even those return addresses, which was on the stack before (ineffective to implement a better hw logic). An example: 1) A calls B calls C calls D 2) put something to the link register, do a return 3) this flushes the return predictor -> return address of D, C, B, A also cannot be predicted anymore. I agree with the second part about moving big chunk of common code to custom functions. This would basically be a Macro Assembler based inline assembly, and practically would be a static function. Would it be possible to generate assembly at compile time from such functions and link it to the code? Would reduce the initial startup time of jsc, and probably the resulting code would be faster as well, although this would be against the FMW (favourite magic word = complexity), since the macro assembler should also generate assembly. Zoltan
Hey Nathan,
Absolutely - this is effective what we do for calls, where the bulk of the work of the slow case is performed by a shared routine. We've experimented with using this technique more broadly in the early stages of developing the JIT, and back then there was a measurable performance degradation from the call overhead – but the code had changed a lot since then, and the tradeoffs and requirements may be different now (particularly across the varying hardware platforms the JIT has now been ported to).
However returning to an offset to a return address is probably not a good plan. Upon executing a call, processors commonly cache the return address of the call instruction in a circular buffer used to predict return destinations. When it reaches the return instruction it pops a value from the return address stack to predict the destination of the return. If you change the address you're going to get a mispredict and probably a pipe flush. (We modify the return address in our exception handling path, but we don't expect exceptions to be high performance). However bear in mind that there is no conditional call instruction on x86, so to eliminate the slow path altogether you'd have to litter the hot path with inverted branches over the calls out to the trampolines. I'd suggest you'd be more likely to find success in keeping the hot path branching out to slow cases, and experiment with moving the bulk of the work of larger slow cases out into shared routines (which would be being called from the slow case).
This is certainly an interesting area to investigate.
cheers, G.
On Jun 25, 2010, at 4:20 PM, Nathan Lawrence wrote:
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 _______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
_______________________________________________ squirrelfish-dev mailing list squirrelfish-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev