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 Sat, 29 Mar 2008 12:11:14 GMT
On the 0x416 day of Apache Harmony Okonechnikov Konstantin wrote:
> Alexei, Egor, thanks for helpful discussion.
> So, there are two
> basic approaches:
> 1. rewrite the current impl, introduce limited functionality, grow
>    functionality in evolutionary way
> 2. take the current impl, evolutionary move it to something better and
> >    better
> >
> > Yes, I preferred (1) because changing (2) requires understanding the
> > current impl, which is not so fun.
> It seems to me I won't avoid digging into the code. 

Somewhat -- yes, but do not spend a lot of time on this! this code is
time eater. You will basically need to find out _what_ the code does,
but not _how_ it does. Try using the JET _how_.

> And I don't want to make the same mistakes again.

You won't! We are here to prevent that. Release your patches "early
and often", this is one of the good properties of open source
development (releasing early and often).

> I think I have to get familiar with current implementation to
> understand better its problems. Maybe not so detailed, but I believe
> that I could use some of this code.

please, refer to the above notes about _what_ and _how_ while doing
this. I do not want this brain-damaging implementation to hurt you :)

> But the big plus of (2) is that no matter of how much work is done,
> > the impl becomes better :)
> Could it happen so that the only possible improvment is total refactoring?

This question is not easy to answer. On one hand total refactoring is
not necessary in some places. We already discussed that support of
some features will most likely remain the same (Exception support,
JSR/RET, Simplifier).

But on the other hand JavaTranslator has to be eliminated
completely. It affects a lot.

Another idea: if you prefer not to start from the IRBuilder
refactoring, there is an alternative way. The task is to separate
JavaLabelPrepass into two passes:
1. marking basic blocks
2. data flow analysis

try doing it in no more than one week. And do not feel upset if you do
not complete it, it is a step to get some knowledge on _what_ is done
there (OK, and you will have to find out the _how_, but here it is
unavoidable at the moment)

P.S.: It is so good that you share your opinion often, because it
makes me think about the subject more, and emit (crappy:) ideas. So,
keep updating us on your thoughts and plans.

Egor Pasko

View raw message