I realize it's a pretty hard problem - and hadn't java already demonstrated the feasibility of it, I would have doubted it to be possible at all without major surgery to both language and runtime (special scoped types etc). So I guess my question is: is there something about C# or .NET that makes it much harder to do escape analysis than it is in Java world?
An evil example is
class Something
{
private static readonly Something _inst;
public Something()
{
_inst = this;
}
}
Where the reference leaked just by instantiating it. Does java detect that this escaped the stack? How?
Shows that the Hotspot doesn't handle it in all scenarios:
> But, EA is not ideal: if we cannot statically determine the object is not escaping, we have to assume it does. Complicated control flow may bail earlier. Calling non-inlined — and thus opaque for current analysis — instance method bails. Doing some things that rely on object identity bail, although trivial things like reference comparison with non-escaping objects gets folded efficiently.
> This is not an ideal optimization, but when it works, it works magnificently well. Further improvements in compiler technology might widen the number of cases where EA works well.
Thanks that clears some of it up. It seems that java runtimes that do EA actually do this sort of crazy difficult analysis that quickly breaks down with branches and non-inlined code.
FWIW, graal has partial escape analysis, which can avoid a lot of those pitfalls by allowing allocations to escape through just some of the branches. For instance, if you have
X thing = new ...;
if (slowpath) {
unlikely_function(thing);
}
...
Even if unlikely_function isn't inlined, it can still perform scalar replacement, and push the allocation site into the branch (reconstructing the state of the allocated object as it would've been at that point), which is a big improvement.
This in turn lets the inliner be smarter about what it does and doesn't inline, vs c2 which tries to greedily inline everything, partly to assist escape analysis
I believe it is not difficulty level problem but the fact that due to value types existence in .NET it was ok to live without escape analysis for so many years (like @cpeterso also pointed out).
Construction is a two step process. The space for something is allocated and then the constructor is called so there isn’t anything magical in that example.
It does however also remove half the guarantees about uninitiated object visibility in the java memory model because your leaking the reference inside the constructor.
An evil example is
Where the reference leaked just by instantiating it. Does java detect that this escaped the stack? How?