Escape analysis/scalar replacement question

[Tiark Rompf]

Vladimir,
thank you very much for your reply! Please keep me posted if there are  
any major EA improvement news.
- Tiark

On 08.07.2009, at 18:40, Vladimir Kozlov wrote:

> 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