harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "cannibal wang" <cannibal.w...@gmail.com>
Subject Re: [drlvm][opt][translator] What dose JavaLabelPrepass do?
Date Fri, 18 Jan 2008 11:53:11 GMT
18 Jan 2008 12:42:00 +0300, Egor Pasko <egor.pasko@gmail.com>:
>
> On the 0x3CF day of Apache Harmony cannibal wang wrote:
> > 2008/1/17, Simon Chow <simon.harmony@gmail.com>:
> > >
> > > Actually, we are targeting at x86 platform :)  IPF is not concerned
> until
> > > now.
> > > I am sorry that I did not make this clear before.
> >
> >
> > Agree, we will graduate next year, so we have only one year at most to
> do
> > so, unless our future work
> > involves Harmony,:)
> >
> > 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?
> >
> >
> > Initially, we planned to compile a java program to WHIRL using Open64,
> > then translate WHIRL to OPT HIR, because WHIRL has five levels, and it
> can
> > deal with more detailed information.
> > in the end, dynamical optimization in Harmony will be utilized.
> > Is this idea feasible?
>
> Five levels? wow! Unless you tell what the levels are, what levels you


indeed, five levels...some guys in another team are managing to make open64
compile java application, they are focusing on the front end of open64.
Actually, I know little about implementation details in open64 as well, but
there is a detailed document about it.

are going to translate to Jitrino HIR and what apply then in Jitrino,
> I cannot tell much. And this description turns into a small design
> document :)


We just wanna evaluate the feaibility of such design which is just one of
our designs. We are now discussing four designs and picking up the most
feasible one, then try hard to implement it.

Overall seems interesting. But I am afraid a lot to do, so, once you


I couldn't agree with you more!
However, I have got to try my best to graduate from university
successfully:)

get a working version passing Harmony tests that would be a huge
> success, even if the system is slower on the start.
>
> Good luck.
>
> > 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?
> > > I have little experience here.
> > >
> > > And I have not tried DRLVM on IPF yet...
> > >
> > > 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
> > >
> >
> >
> >
> > --
> > Cannibal
> > CS.Fudan University
>
> --
> Egor Pasko
>
>


-- 
Cannibal
CS.Fudan University

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message