Escape analysis/scalar replacement question

[Vladimir Kozlov]

Hi, Tiark

What you are asking is split through Phi optimization
for AddP and LoadI nodes. Currently this optimization is
done during IGVN optimization after EA is done and only
for referencing one non escaping allocation (for example,
without the allocation inside the loop for your case).
But I agree that such optimization could be done for your case.

We have a plan for next few months to work on improvement
of EA and we will consider your case also.

Thanks,
Vladimir

Tiark Rompf wrote:
> Hi,
> 
> we're currently reworking parts of the Scala collections library and 
> there are a couple of places that would profit greatly from escape 
> analysis and scalar replacement. For some cases, -XX:+DoEscapeAnalysis 
> already gives very good speedups, but we're frequently encountering 
> situations where the hotspot compiler fails to eliminate allocations 
> although it should be safe to do so. Here is a simplified example:
> 
> final class VectorStub {
>     int index;
> }
> 
> class Test1 {
>     void test() {
>         VectorStub it = new VectorStub();
>         int max = 1000;
>         while (it.index != max) {
>             int cur = it.index;
>             it = new VectorStub();
>             it.index = cur + 1;
>         }
>     }
> }
> 
> Clearly, none of the allocated objects can escape, but scalar 
> replacement does not take place. It does, however, when I pull the 
> current index out of the loop into a local variable:
> 
> class Test2 {
>     void test() {
>         VectorStub it = new VectorStub();
>         int max = 1000;
>         int cur = it.index;
>         while (it.index != max) {
>             it = new VectorStub();
>             it.index = cur + 1;
>             cur = it.index;
>         }
>     }
> }
> 
> 
> Browsing the hotspot source code revealed that encountering an AddP node 
> whose inputs might stem from different allocation sites will mark these 
> allocations as ArgEscape. Looking at the ideal graph representation of 
> the above code shows that this is indeed what prevents scalar replacement:
> 
>     Allocate      Allocate
>      |             |
>     Initialize    Initialize
>      |             |
>     CheckCastPP    |
>      |            /
>      |  CheckCastPP
>      | /
>     Phi
>      |
>     CastPP
>      ||
>     AddP
>      |
>     LoadI
>          ...
> 
> Pushing the AddP through to beyond the Phi does the trick in this case, 
> so my question is whether something can be done about in general. I've 
> been talking about this briefly with Cliff Click at ECOOP yesterday, and 
> he said it should not be too much work to fix it.
> 
> So, is there a chance of seeing this improved in the not too distant 
> future?
> 
> Thanks in advance,
> - Tiark