Neat idea. One thing to consider is that some "slow" cases are pretty hot. For example, on 64bit, double addition is a "slow" case. Turning double addition into a function call might be too expensive. I'd suggest instrumenting the code to count how often certain slow cases are taken, and strategizing accordingly. Maybe code in these slow cases needs to move onto the hot path. Alternatively, maybe rare slow cases can change to functions, and hot slow cases can remain as they are. Geoff 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