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

[Zhoulai Fu]

Thanks a lot Patrick. I would go to a wrong direction if it it were not your help. 

Regards,
-
Zhoulai 

Sent from my iPhone

> On 14 déc. 2013, at 15:54, Patrick Lam <plam at sable.mcgill.ca> wrote:
> 
>> 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
>