harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general] GSoC 2008 Refactor Java Bytecode Translator
Date Thu, 27 Mar 2008 22:09:36 GMT
And if these baby steps

On 27 Mar 2008 21:17:58 +0300, Egor Pasko <egor.pasko@gmail.com> wrote:
> 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
>
>



-- 
With best regards,
Alexei

Mime
View raw message