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 Sun, 06 Apr 2008 14:46:41 GMT
On the 0x41D day of Apache Harmony Okonechnikov Konstantin wrote:
> Egor, Ian thanks for helpful information.
> I have some good news: Simplifier and CSE removal from IRBuilder is
> accomplished.

Great news, Kostya! I am eager to see how it works ;)

> 1) What is done:
> - Simplifier* IrBuilder::simplifier and all connected methods are removed or
> modified
> - CSEHashtable IrBuilder::cseHashTable and its methods are removed
> - Instruction generation doesn't include simplification and hashing anymore
> - DoSimplify, DoCSE flags are removed from IRBuilderFlags

all cool stuff!

Also consider removing other flags like expandNullChecks it pollutes
the code and does not make much sence. Once I needed to remove all
checks I just fixed some bits in the corresponding optpass :

> 2) Results: WinXP/x86/ia32
>      Jvmti, CUnit, Smoke tests passed
>      Some kernel tests failed, but they appear to be the same as with
> unmodified IRBuilder, I am investigating this problem.

good good good

I am also thinking about the ways to compare the code after translator
and optimizations, to not kill performance accidentally. The thinking
probably smells like bad news for you since it is probably a lot of
unexpected work.. Sorry for that. Will try to keep the amount of work

The testing methodology sounds like that to me:
1. disable inliner
2. run non-modified version Harmony on HelloWorld in OPT mode, collect all logs
3. run new translator, collect all logs
4. compare the logs recursively
5. classify and analyse the differences

I hope 5 would not be hard, but no guarantee here. Need a short
(perl?) script that compares the logs, ignoring non-essential differencies.

opt path should probably be:

for the fair comparison probably need to run old version with path:

I am really sorry that so much extra work needs to be done, but we
should be very careful here, it is easy to kill performance in
translator (or gain it?:). I would not insist on very-very tricky ways
to test the changes, just a sanity check to see in practice how it
works. Is ot OK with you?

> 3) TODO: rebuild on Linux; play with OPT chain;

feel free to ask questions on it, even the dummiest ones. I hope to be
quicker answering than now :(

> examine carefully instructions, determine which are not required in IrBuilder
> (as I suppose so called SIMPLIFIER GEN instructions have to be carefully
> investigated); make more thorough testing

> I 've read information on how to commit, but didn't find some facts. What
> are the requirments for commiting the
> code?

basically you need to pass smoke, unit tests. in case of translator I
suggest to run all in OPT mode, also regression tests. (I'll tell how)
AFAIR, Eclipse is also a good catcher of translator bugs, so, I
suggest to run it too, create a new project, type in Hello World
application there, run it. All in OPT mode, of course :)

>  Are there any branches for unstable code?

no, we do not like to keep branches of unstable code. You can keep
patches of code in JIRA. When there is a lot of them, we try to
stabilize and commit. Aligned with the general strategy: commit early
and often (though, I cannot say I myself conform to this strategy
completely, eh)

We run more aggressive testing in stabilization periods before
releasing stable builds. Do not need to care about those tests when

GIT [1] is a powerful version control system to operate on patches,
slightly brain-damaging in the beginning, but I find it extremely
useful. I can give you hints on it.

> Unfortunately I have bad news: due to some technical problems I can't
> access temporarily SVN repository and checkout the code. I was modifying the
> IRBuilder using stable snapshot (r629320). As I found out from browsing
> Harmony Repository
> online, since r629320 2 patches were implemented to IRBuilder ( r636777,
> r645073). So I suppose, when I am able to checkout the code, I will
> need to implement them. I am not sure, maybe this is not a big problem,
> nevertheless... hope it's not that difficult to handle :)

I sent you a gtalk invite to discuss this crap. Feel free to accept it

[1] http://git.or.cz/

Egor Pasko

View raw message