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 <[EMAIL PROTECTED]> wrote: > >>> On the 0x3CE day of Apache Harmony Simon Chow wrote: > >>>> On 17 Jan 2008 11:08:54 +0300, Egor Pasko <[EMAIL PROTECTED]> 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
