Escape analysis/scalar replacement question

Tiark Rompf tiark.rompf at epfl.ch
Wed Jul 8 08:42:35 PDT 2009


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



More information about the hotspot-compiler-dev mailing list