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 09:00:22 GMT
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

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

Details later, if you wish.

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

Egor Pasko

View raw message