On 8/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
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.
The service routines' interaces are a finite set, and I think this work is a not necessarily to be framework. If the runtime services' interfaces are well-defined, JIT can always inline their implementations. Once the interface is defined, any new GC has to follow it in order for its serives to be inlined. We don't want to introduce the full dynamic interface discovery complications at this moment. :-) (I guess a framework is only needed when we want to support multiple different IRs for different service routine inlining.) But still we have two things to consider: 1. Which compoent is going to make the inlining decision? (Some new GC doesn't provide the inlinable version for fast-path, or we just don't want to inline for some reason.) 2. What flexibility can we give the serivce routine developer? (The service routine may call other methods implemented internally or in library, natively or in Java.)
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.
Yes, this is what I thought as well. This work can be also useful for the MMTk integration.
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 :-) ?
Perhaps. :-) The serive routine inlining is special because it relates all the components of JVM in ways of both high-level and low-level designs. That is, e.g., to inline gc_alloc_object, we need define both the functional interface, calling conventions, and module interactions. If we have a new native interface and related compilation framework, we probably will change the current design of service inlining. My estimation is this Java fast-path inlining work can be finished quickly, so it is worth to have a try anyway. :-) Thanks, xiaofeng --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
