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 Thu, 27 Mar 2008 18:17:58 GMT
On the 0x413 day of Apache Harmony Okonechnikov Konstantin wrote:
> Well, there are some questions.
> [IrBuilder]
>   If we clean out simplification, it wont affect the functionality of
> instructions, will it? (i.e.will OPT work without these simplifications?
> I ve tried to clean some instructions, it seems everything is OK (HelloWorld
> works) )

Ideally everything should work if we disable simplification. Although
I remember some problems running Eclipse solely on OPT with
simplification disabled. That was a long time ago, and if it appears,
that's a bug.

> I 've written sort of plan. Check this out.
> 1) Clean up IRBuilder
>   -remove Simplifier and its methods

sounds good

> 2) Move all simplification to Optimizer stage
>    (this is quite big task as I suppose, lots of instructions use
> simplification. Not sure if we should create separate action for every
> simplification....)
> 1 and 2 should be implemented concurrently

actually there is a stage called 'simplify' already that in fact uses
the same simplifier. So, it is not a huge work, need to ask somebody
to check performance of disabling simplification in translator and
running it from HLO right after the translator (with dead code
eliminator, blablabla).

> 3) Develop the translator
>     -  new PrePass (maybe from Jet?)
>
>     - implement data analisys, parser etc...
>
> Where am I mistaken? I will appreciate any additions and(or) corrections.

Kostya, thanks a lot for the draft plan! I have been quite busy and
could not discuss it with you earlier. Sorry for that. I like your
pro-active approach very much, please continue behave like that :)

Although, I have somewhat different views on the plan, those views are
more like discussable than final :) So, plz, do not take personally if
I just ruined your best dreams about the process))

TA-DAA! Here my suggestion goes..

I would recomend to hack the whole code starting from a small and
limited implementation and grow functionality doing small baby
steps. So, you would not need to implement the rock solid data flow
analysis at once. Just write one that looks beautiful by design, does
not support non-interesting instructions as well as difficult stuff
like exceptions, loops and JSR/RET, put asserts in places, where you
do not support something.

Then grow functionality until you can run HelloWorld. Constantly
ensuring that the code looks good and we love it.

This can be split into several sub-steps:

0. move simplifier out of IRBuilder, basically fix HARMONY-5500 or
   determine that it is not a part of our work if it unexpectedly
   wants to eat too much time :)

1. draft code that does prepass and data flow analysis in code _without_
   loops, exceptions, call instructions
1.1. prepass
1.2. data flow analysis
1.3. bytecode mapping

2. support call instructions and lazy resolution

3. with loops

4. with exceptions and loops

5. make sure Hello World works and fix bugs when it does not ;)

6. JSR/RET support

7. inliner support

8. make sure all tests and eclipse work in -Xem:opt mode
8.1. bytecode without JSR/RET
8.2. bytecode obtained by ECJ (with JSR/RET)

9. write barriers (?), other features...

10. what I forgot

(I am yet not sure about the order, though, pick what you want to do
first)

Let's review the code between steps, speak about it, think what we do
next and how. It also makes sense to review the code more often, once
noticeable features are implemented or code is refactored.

My picture is that we will commit it into a separate directory, your
code can be running via tweaked emconf file. That is because I do not
like branches :)

I separated exceptions, loops, resolution stuff because I think it
will let us better concentrate on coding in the early stages (what
else to separate?). Additionally, I think, exception support needs
little change. It has been completely rewritten once, looks not so bad
(although scattered around) and no bugs were found in it since
then. So, just move the code carefully. Same picture with JSR/RET
support. Looks like no need to rewrite.

Why is this approach worth trying? Because you can test the code while
writing. Make an emconf that uses your code on methods with supported
bytecodes and use JET or older OPT for others.

Sounds good?

-- 
Egor Pasko


Mime
View raw message