harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [general] GSoC 2008 Refactor Java Bytecode Translator
Date Fri, 21 Mar 2008 10:54:56 GMT
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


> 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 ;)

--
Alexey Varlamov

>
> --
> Egor Pasko
>
>

Mime
View raw message