Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: [drlvm][opt][translator] What dose JavaLabelPrepass do?
Date: 18 Jan 2008 12:35:48 +0300
Lines: 210
Message-ID: <0vqtzlbjx1n.fsf@gmail.com>
References: <3db9f87f0801160524t116f4e6dv9a6e5e9e87d81bb@mail.gmail.com>
 <0vqk5m8lvqh.fsf@gmail.com>
 <3db9f87f0801170104x6282a0ffi7e8595ad5533e61c@mail.gmail.com>
 <0vqfxwwlp5i.fsf@gmail.com>
 <3db9f87f0801170259p2356b621va2506d315b0f7793@mail.gmail.com>
 <0vqbq7klj4r.fsf@gmail.com>
 <3db9f87f0801170626j2824e91co21709f2027ba7e6d@mail.gmail.com>
 <0vqy7aojxtd.fsf@gmail.com>
 <9623c9a50801171606q26bd3745s2c3dbaf1d98b2cec@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
Sender: news <news@ger.gmane.org>

On the 0x3CF day of Apache Harmony Xiao-Feng Li wrote:
> On 17 Jan 2008 18:06:54 +0300, Egor Pasko <egor.pasko@gmail.com> wrote:
> > 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.
> 
> Egor, I should not talk too much here about their project, but it's
> not Harmony project, it's Open64 project.

Ah, OK then, sorry, I probably talk too much :/

> Thanks,
> xiaofeng
> 
> >
> > > 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
> >
> >
> 
> 
> 
> -- 
> http://xiao-feng.blogspot.com
> 

-- 
Egor Pasko