[Soot-list] Why is not soot used in the workflow of a modern Java compiler?

[Patrick Lam]

On 14/12/13 02:13 AM, Zhoulai wrote:
> Hello,
>
> I have a very naive question.
>
> Since SOOT can be used to optimize Java codes, say, by eliminating dead
> codes, or by constant propagation, etc. Why isn’t it integrated into
> modern compiler like javac as a post-processing step so that they could
> have produced more efficient codes?
>
> One might think that  SOOT takes too much time.   However, I feel
> (although not sure)  that even a simple  intra-procedural analysis like
> those built in SOOT could have improved significantly bytecodes compiled
> by Javac, and such intra-procedural can be very fast I suppose. So
>   there should be practical reasons explaining  why  these optimisations
> in Soot not integrated as a part of Javac’s workflow? Can anyone clarify
> this point? Many thanks.

Hi Zhoulai,

Most of the performance optimization for production Java Virtual 
Machines happens at runtime by the Just-in-Time compiler, which has a 
better view of the code and can easily do optimizations that are more 
interprocedural as well as intraprocecedural. The exact bytecode layout 
turns out to not matter that much. So Soot is really only worth using 
for performance when you are otherwise generating code that is 
egregiously bad (like for AspectJ) or if you are going to do some really 
worthwhile high-level optimization that is hard to do at runtime. Of 
course, many people also use Soot for verification-related analyses.

pat