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: [general] GSoC 2008 Refactor Java Bytecode Translator
Date Fri, 21 Mar 2008 11:16:28 GMT
On the 0x40E day of Apache Harmony Alexey Varlamov wrote:
> 21 Mar 2008 12:00:22 +0300, Egor Pasko <egor.pasko@gmail.com>:
> > 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


Mime
View raw message