harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][opt][translator] What dose JavaLabelPrepass do?
Date Thu, 17 Jan 2008 15:06:54 GMT
On the 0x3CE day of Apache Harmony Simon Chow wrote:
> Actually, we are targeting at x86 platform :)  IPF is not concerned until
> now.

Now it turns to be more real

> I am sorry that I did not make this clear before.
> Now we just plan to enhance OPT using Open64 only for loops and other
> computation-intensive sections.

> Does it have some opportunities for performance improving?

OK, so, you probably are most interested in high-level
optimizations. There are opportunities. We are constantly working on
this kind of optimizations and constantly get improvements here and
there.

many optimizations benefit from knowledge of Java specifics, for
example, semantics of virtual calls (we can "devirtualize") or
eliminating unnecessary array bounds checks. A C/C++/Fortran compiler
won't do it for you. So, I guess, you will need to apply open64
optimizer after all inlining, unrolling, etc., etc. by Jitrino.OPT.

And since Java code is naturally full of explicit null-checks,
bounds-checks, virtual and interface calls, C compiler won't be able
to optimize across these things unless you teach it to do so.

Looks like a lot of work to do, but not actually much room for
performance improvement. This is my humble opinion.

> As you said, code motion and prefetch optimizations is more helpful in C
> compilers,
> and what is the advantaging we can take using JIT compiler? profiling? and?

..and in-depth knowledge about Java specifics

> I have little experience here.
> 
> And I have not tried DRLVM on IPF yet...

me too :)

P.S.: Xiaofeng, I am personally fond of your way of generating a lot
of research around Harmony. I would be happy to learn from you. But
don't you think that this specific task is overkill? Maybe, we can
find some equivalent cool optimizer-related subject within Harmony?
For example, we could know that Open64 does optimization A better than
Jitrino. The task is: investigate and reimplement A in Jitrino. This
eliminates the licensing problem as a bonus.

> Thanks
> 
> On 17 Jan 2008 15:41:08 +0300, Egor Pasko <egor.pasko@gmail.com> wrote:
> >
> > On the 0x3CE day of Apache Harmony Simon Chow wrote:
> > > On 17 Jan 2008 13:31:05 +0300, Egor Pasko <egor.pasko@gmail.com> wrote:
> > > >
> > > > On the 0x3CE day of Apache Harmony Simon Chow wrote:
> > > > > On 17 Jan 2008 11:08:54 +0300, Egor Pasko <egor.pasko@gmail.com>
> > wrote:
> > > > > >
> > > > > > On the 0x3CD day of Apache Harmony Simon Chow wrote:
> > > > > > > I am studying OPT in jitrino. For understanding the process
of
> > > > building
> > > > > > CFG,
> > > > > > > I have read some code of JavaByteCodeTranslator.
> > > > > > > In the constructor of JavaByteCodeTranslator, there is
an
> > additional
> > > > > > pass
> > > > > > > named JavaLabelPrepass,
> > > > > > > I would like to ask what is the exact purpose of this pass?
> > > > > >
> > > > > > the purpose is to mark basic blocks and inference stack variables
> > and
> > > > > > local variables with their types.
> > > > > >
> > > > > > This information goes to the input of JavaByteCodeTranslator,
> > which in
> > > > > > single pass goes through each bytecode instruction and converts
it
> > to
> > > > > > operand-based representation from the stack-based in bytecode.
> > > > > >
> > > > > > The problem is a little tricky (with variable merging logic)
and
> > > > > > current design is poor.
> > > > > >
> > > > > > > Besides this, It is seems that the translator part will
be
> > refined,
> > > > > > which I
> > > > > > > saw in the wiki. Has it already been done in the current
> > version?
> > > > > > > Thanks!
> > > > > >
> > > > > > no, translator is not refined, low priority task.
> > > > > >
> > > > > > Why do you study the process of building CFG? If you want to
do
> > > > > > something with it, I would suggest to try some other place since
> > all
> > > > > > JIT people here will agree that debugging JavalabelPrepass is
> > > > > > brain-damaging.
> > > > >
> > > > >
> > > > > Thank!
> > > > > I am doing a project for combining static compiler with dynamic
> > > > compilation
> > > > > environment (jitrino.OPT)
> > > > > As first step, now I am planning to translate the Harmony IR to
> > WHIRL.
> > > >
> > > > hm, do you have a kind of draft design document on how you want to do
> > > > this? ..probably Harmony gurus can give some valuable input having
> > > > read this doc.
> > >
> > >
> > > There is no document for this yet, but I will write one in the next few
> > days
> > > after having a discussion with others in my group.
> > > Our static compilation platform is Open64, some of my teammates are
> > working
> > > on it.
> >
> > just to make sure.. is the primary goal to replace/enhance Jitrino.OPT
> > on IPF machines? Oh, those itanics..
> >
> > > I only have a little understanding of jitrino.OPT.
> > > For achieving higher performance, which part or phases of jitrino.OPTcould
> > > be refined or replaced by Open64 optimization?
> > > Could you give me some suggestion?
> >
> > I am afraid I am not familiar with Open64 at all, and there are
> > concerns using a mix of Jitrino.OPT and Open64 since the latter is
> > licensed under GPL. So, do not show me their code :)
> >
> > Jitrino.OPT/IPF is rather immature/experimental/untested/etc. So, if
> > using Jitrino.OPT on IPF consider throwing away the code generator
> > (but take care about generating the right calling convention and
> > VM-related stuff like threading)
> >
> > As for the High-level optimizations, I do not know, where Open64 is
> > better, maybe Xiaofeng knows? :)
> >
> > I may try to forsee something: Fortran & C compilers have more freedom
> > for code motion and prefetch optimizations than a Java JIT compiler
> > (which has a more dynamic nature), so, when ported to Java realities a
> > C compiler is likely to behave not very cool.
> >
> > I would suggest you to enhance Jitrino IPF codegenerator in
> > if-conversion and register allocation, that looks like more
> > interesting and performance-beneficial. However, I am not sure if it
> > suits you good as a subject of research.
> >
> > Did you try running DRLVM on IPF? Does it work? Does it even compile?
> >
> > > By the way, This idea is original from Xiaofeng :)
> > >
> > > Thank you every much!
> > >
> > > > But I can not find more information for the CFG structure in
> > jitrino.OPT,
> > > > > which leads me to read the code in translation part. :(
> > > > > Any advice for this?
> > > >
> > > > there is no complete reference guide for HIR instructions yet. Once I
> > > > gave advice on this:
> > > >
> > > > http://article.gmane.org/gmane.comp.java.harmony.devel/24474/
> > > >
> > > > feel free to ask specific questions on CFG and instructions :)
> > > >
> > > > --
> > > > Egor Pasko
> > > >
> > > >
> > >
> > >
> > > --
> > > From : Simon.Chow@Software School of Fudan University
> >
> > --
> > Egor Pasko
> >
> >
> 
> 
> -- 
> From : Simon.Chow@Software School of Fudan University

-- 
Egor Pasko


Mime
View raw message