harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm] Helper inlining in JIT
Date Wed, 16 Aug 2006 08:26:51 GMT
On 8/16/06, Rana Dasgupta <rdasgupt@gmail.com> 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. :-)


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message