On the 0x40E day of Apache Harmony Alexey Varlamov wrote: > 21 Mar 2008 12:00:22 +0300, Egor Pasko <[EMAIL PROTECTED]>: > > On the 0x40D day of Apache Harmony Okonechnikov Konstantin wrote: > > > >hm, and how is it going? :) > > > > > > well, right now I modify [codegen]->stacklayout action. Callee-save > > > registers are always being saved/restored in the begining/end of the > > > method. But sometimes not all pathes use callee saved regs. > > > Motion of the spill code inside CFG can reduce memory calling rate. > > > (So called "shrink wrapping" > > > technique). I have > > > already implemented functions that collect info about callee save regs > > > usage in each block and find proper postion for spill code, > > > hope to finish the optimization to the end of April. > > > > wow, this is a very interesting work, assuming some tradeoffs to > > consider. I love this :) > > > > > >seriously, what is your experience with the code? > > > > > > I am familiar with common principles ( DRVLM,HIR, LIR, CFG etc) > > > and have expierience with codegenerator. > > > > nice nice nice > > > > > > ... there is a JavaLabelPrepass class that namely should only mark > > > >boundaries of basic blocks. But it does a lot more, for example, > > > >inferring types of variables. It is very complicated, makes > > > >unpredictable number of traversals through the bytecode, not easy to > > > >support. > > > > > > Some questions. > > > As I > > > understood TranslatatorSession::translate() starts parsing calling > > > JavaTranslator::translateMethod(), right? > > > Then we parse bytecode using JavaByteCodeTranslator as parser > > > callback. When are JavaLabelPrepass methods called? > > > > I agree, this is not very logical. You are now closer to the crappy > > code, just start feeling it :) > > > > in constructor of JavaByteCodeTranslator: > > JavaByteCodeTranslator.cpp:142: initLocalVars(); > > > > in initLocalVars:220: > > // > > // perform label prepass in this method > > // > > parser.parse(&prepass); > > prepass.parseDone(); > > > > it was supposed that parser incapsulates generic code for parsing, > > but it does not have a lot of code to incapsulate and only makes things > > more complicated. > > > > > What is VariableIncarnation? What is SlotVar? > > > > In brief, VariableIncarnation will refer to a single operand in > > HIR. But during translation phase we do not know which variables > > (local variables and stack variables) will represent the same operand, > > so, during translation VariableIncarnations will be connected in > > chains of equivalent vars. One chain represent a future operand. > > > > SlotVar .. you know, slot is an element of java operand stack. Just to > > keep corresponding VariableIncarnations connected to the slot in > > operation. > > > > Details later, if you wish. > IMO the JavaLabelPrepass quite closely implements data-flow analysis > as described in JVMS [1], and VariableIncarnations represent merged > state of variables for each instruction, as Egor said. > [1] > http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#9801
Alexey, thanks for the handy link! Most of JavaLabelPrepass functionality is data-flow analysis. I forgot to mention it :( > > I think you should not dive into details of JavaLabelPrepass. Better > > try avoid it. And implement a readable and nice translator from scratch. > > > > > > ...IRBuilder separation necessity is reported as HARMONY-5500. > > > Looks like refactoring of JavaLabelPrepass and IRBuilder separation are > > > quite independent tasks. And separation is more important, isn't it? > > > > JavaLabelPrepass has nothing in common with IRBuilder. Though, both > > are a part of the translator. I cannot judge the importance here. Both > > improve design, readability, etc. IRBuilder separation is easier to > > implement, and, probably, this is what you want to start from. > > > > > >A good example of clean code that does similar things is Jitrino.JET > > > >compiler, but I did not investigate if it could be reused. Maybe you > > > >can first try to build IR by extending Jitrino.JET. > > > You mean modify or extend > > > JET in order to use instead of JavaByteCodeTranslator? > > > > I meant take the basic concept and implement translator using this > > concept/code-patterns. Then decide if there is a common part between > > two and whether we need to separate it. > > > > I suggest to look more in JET code than in prepass or translator when > > implementing the next big thing :) > > JFYI, I recall there are peculiarities related to subroutines (JSRs) > processing, and current JET does not handle them completely > (HARMONY-4740). So you might want to fix that as well ;) Yes, JSR and RET instructions are tricky. Current aproach in Jitrino is to keep the info about JSR+RET pairs until the CFG is fully generated. And then inline them as if it is a CFG optpass. I suggest to keep this code. So, only pre-CFG hefactoring for this functionality. HARMONY-4740 suggests a similar approach, though, with CFG it is easier. -- Egor Pasko
