Hacker News Reader

Comment by alkonaut | Hacker News Reader

Is there work ongoing or planned to try to add/improve escape analysis, as the article suggests?

.net already has in-place allocated types (e.g. 'structs') which are dropped on the stack or inside the allocation of their owner (in the case of members fields), which explicitly covers most cases that escape analysis tries to handle implicitly. However, they still need to be heap-alloc'd when boxed (e.g. when used as a IEnumerator or something), which would definitely benefit from hotspot-style allocation-inlining (though the C# compiler already tries to do this prejit for common cases like iterators, too, for practicality's sake).

In general - yes: https://github.com/dotnet/coreclr/issues/1784. However, nothing more specific I can say...

For a VM as mature as .NET, I am surprised they don't do escape analysis. Java and Go both do escape analysis, though the coreclr issue you linked to makes the point that Java really needs escape analysis because it doesn't have value types like C# structs.

I'd say .NET is surprisingly immature considering it's age and it's popularity, at least compared to JVM and JS options.

Don't get me wrong I think .NET is great, and they've made some smart decisions that allow it to be competitive with much less engineering work on the VM.

As well as not having escape analysis it also lacks tiered compilation which is a much more pressing problem from my perspective, and is being actively tackled now.

Looking from the outside, but also following everything that comes out of MS and MSR, I think it was a political consequence.

There was always the DevTools vs WinDev differences regarding the role of .NET in Windows, and for a while it seemed Microsoft has happy having .NET just be good enough.

Thankfully they have changed their mindset and are improving .NET to be as close to C++ as possible, at least for 99% of the use cases where using a GC language is an acceptable trade off.

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?

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).

> Does java detect that this escaped the stack? How?

There isn't one Java, rather lots of it.

So, in what concerns Oracle, there are reports from Oracle Labs that Graal is better than Hotspot on escape analysis.

No idea where IBM, Azul, Aicas, microEJ, PTC stand.

Even less regarding Android, because not only Google has done their own thing, each OEM also has the freedom to change how ART works.

Regarding your actual question, I have this feeling none of them is able to detect it.

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.

This post has a nice investigation into 'Escape Analysis' in Java, https://shipilev.net/jvm-anatomy-park/18-scalar-replacement/

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

> Does java detect that this escaped the stack? How?

Well you assigned the instance to a global variable. That's how Java knows. If you can see that then so can the Java compiler.

Reply on news.ycombinator.com