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 13:04:23 GMT
On the 0x3CE day of Apache Harmony Gregory Shimansky wrote:
> Egor Pasko said the following on 17.01.2008 15:41:
> > 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.OPT could
> >> 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?
> 
> It runs in interpreter mode ATM. On JIT there is something bad
> happening, a classloader helper is called with a class handle NULL and
> fails on assertion that it shouldn't be NULL. How this NULL handle was
> passed to the helper I don't know because I didn't debug compiled code.
> 
> DRLVM compiles on old SLES9 gcc 3.3.3 but fails to compile on SLES10
> gcc 4.1.2. The reason is several assembly files which new assembler
> doesn't like (some compiler directives have to be removed) and a
> couple of C++ errors coming from Jitrino code. I didn't fix assembly
> yet because I can't test whether the result would actually work since
> I can't get to the end of DRLVM build.

Thanks, Gregory!

the picture is not very optimistic for a young researcher :)

-- 
Egor Pasko


Mime
View raw message