harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm] Helper inlining in JIT
Date Wed, 16 Aug 2006 20:21:23 GMT
On 8/16/06, Rana Dasgupta <rdasgupt@gmail.com> wrote:
> On 8/16/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>
> > On 8/16/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > >>
> > >> So why can't we optimize native (JNI) calls from Java code using
> > annotations
> > >> similar to those used to annotate helper's slow call above?
> > >> Once developer annotates native call with information about it's
> > sideffects
> > >> we can optimize the call and reduce JNI overhead.
> > >> ?
> >
> > >This is off-topic now. :-)  But one (crazy) idea is to compile the
> > >native code with JVM compiler as well so that both Java and native
> > >code can use same IR.
>
>
>  Let's skip JNI optimization on this thread, I am sorry I brought it up.
>
>   -  So we will write the inlinable  fastpaths wherever possible in pure
>   Java, using an annotated calling convention to call the slowpath ( to
>   support developer freedom :-) ).
>   - Where the fastpaths cannot be expressible in pure Java, we will
>   first use asm to develop the helper and a custom calling convention to
>   invoke and test it
Yes. I agree with this approach.  Note that the assembler syntax is
different between windows and Linux.  Writing this sticky code twice
is not a good idea.  Back when I did the original port of ORP to
Linux, I borrowed the code emitter from the JIT.  Then wrote basically
portable asm code that would compile at boottime and run equally on
both Lin and Win.  LIL was created later to try to remove the asm.  I
would vote for removing LIL entirely.  It seems more productive to
focus energies on moving to Java that fixing up LIL.

>   - As and when the magic classes are all available( I have not seen
>   Alex and Weldon's code ), we will switch the second set  above to Java +
>   magic and start inlining these as well

Actually, you really want two pieces.  First the JIRA patches that
make Jitrino.JET do the correct thing with vmmagic classes.  See
http://issues.apache.org/jira/browse/HARMONY-816.  You also need the
dummy vmmagic classes.  You write code that calls these classes.  Then
compile to bytecode.  When Jitrino.JET compiles this bytecode, it will
do "funny stuff" with the calls to the vmmagic classes.

The dummy vmmagic classes you need are contained in:
http://cs.anu.edu.au/~Steve.Blackburn/private/mmtk-20060714.jar

Incidentally the code I am working on, the MMTk port, will be
interesting to you but I suggest you look at it later.  The first
focus should be understanding how vmmagic works and what you can do
with it.

I have been trying to get vmmagic regression tests donated to open
source for a while.  These tests should help you with code
development.

>   - We can start with the new object allocation helper and .Jet if we
>   want to, I guess
>   - For folks who are interested in this, the core helpers live in
>   vmcore\src\jit\jit_runtime_support.cpp and the exports in
>   vmcore\include\jit_export.h.  There is platform specific stuff under
>   vmcore\util\[platform]\base
>
> Thanks,
> Rana
>
>
>
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
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


Mime
View raw message