On the 0x3CE day of Apache Harmony Xiao-Feng Li wrote: > On 17 Jan 2008 15:41:08 +0300, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > 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? :) > > As I know, the team led by Prof Yang and Mao are using Open64 with the > new X86 backend. :) Of course, > if they make it well, they can apply the work to IPF as well. > I think the major issues are in root set enumeration support and the > stack frame work (gc safepoint, exception). Open64 middle-end has been > designed and tuned very well. But the issue is how to expand the > optimization scope with IPA, such as virtual method inlining and > escape analysis, etc.
yes, I agree, all these problems need to be resolved. It is a lot of work. But the benefit of throwing profile away here and there is, hm, very doubtful, right? :) -- Egor Pasko
