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