Xiaofeng, Thanks for the excellent description. My question was not whether partial inling of helpers( or fastpath inlining ) is necessary. It was more whether a generalized framework is absolutely necessary to support it. Or whether there is a finite set of helpers/services fastpaths that one can teach the jit about, so that the jit knows a priori how to generate the code for these inline. As far as I know, several product implementations are OK with teaching the jit, and their performance is quite excellent. This may not be "ideal" for modularity and openness, but is it as bad as it sounds? If you plugged a new gc into drlvm that introduced a completely new helper never used before, jitrino would need to know something about its semantics and when to call it. So the seperation is not as clean as one might think. If I am overruled and we feel that a framework is absolutely necessary, what you are suggesting makes sense. We could have a 2 phased approach:- 1) We code some of the helpers in Java and jitrino can inline them. We code the rest(unsafe) in asm and invoke them as naked or frameless calls ( not jni ). My experience is that the cost is not in the call/ret ( unless you mispredict the branch ), but in setting up and tearing down the prolog/epilog, aligning the frame etc. We could add a helper calling convention to the jit for efficient parameter passing. 2) We develop the unsafe intrinsics and if using them we can get better performance we can use them to progressively replace the asm helpers.
On a different topic, if we wanted to also optimize the JNI interface at some point, would we then develop a different framework for it :-) ? Thanks, Rana
