[SPAM] - Re: Re: [Soot-list] Help (fwd) - Email found in subject

[mbatch at cs.mcgill.ca]

> I have in mind the fact that the code produced by javac is not so
> optimized, be it speed or size-wise.

While javac is not the best, it isn't horrible either.

Our graduate level introduction course to compilers here at McGill holds a
peephole optimization contest every year - the idea being to come up with
just the sort of thing you mentioned (Expr, Dup, Store, Pop) - and it is
fairly time consuming to beat javac, let alone get close.

Soot currently has a peephole framework, but no peephole optimizations
(other than a few examples). This is not to say that the sort of problems
that can be solved by peepholes are not already solved through some other
types of transformation within Soot.

> Such optimizations go towards code-size reductions. Does JShrink do
> them? I'm sure Soot does...

As far as I know about the likes of JShrink and other Java classfile
"compressors", they simple shrink things like method and field names. I am
not aware of any bytecode transformations other than that. YMMV.

Certainly, it would be fairly simple to whip up a suite of peepholes in
Soot and we would welcome the contribution as well. (Since peepholes
operate on the lowest level of abstraction (Baf I think) then you don't
need to worry about the peepholes messing with higher-level optimizations
that might run, since they will be processed before the peepholes in Soot.
However, if you ever run a program through Soot after you optimize with
peepholes, you might get significantly different results).

Cheers,
Michael