Hacker News Reader

Comment by personZ | Hacker News Reader

instead of waiting for a proper struct implementation, like .NET has, on the JVM, which would avoid these problems

http://blogs.msdn.com/b/ericlippert/archive/2010/09/30/the-t...

And it's worth noting that escape analysis, which the JVM currently has and .NET does not, is the best of both worlds -- the developer doesn't need to decide or make such macro optimizations, but the runtime can choose, based upon the lifetime of the object, whether it should be a stack or heap allocation.

I once thought the whole value type thing was a superior choice of the .NET team, but now it seems that the everything is an object, just make the VM smarter, was the better choice.

View on HN

Problem is that escape analysis can't always do a good enough job, it doesn't catch everything. Lead JVM developers have stated this themselves, which is why Orcale is exploring how to implement value types on the JVM. Naturally, value types doesn't magically solve things either (I'm well aware of the shortcomings as described in that article), but for this particular use case, it seems like the perfect solution.

Lead JVM developers have stated this themselves

Where? Who?

Yes, of course they explore options and alternatives, and no solution is a panacea, but this debate is well over a decade and a half old: This is not new ground. And while we're in a world where Microsoft is saying "give it up with the whole value / reference type thing" (the value/reference type is an implementation detail), Java went ahead and optimized the existing platform to a pretty good degree, in many (but not all) cases, leaving it to a pretty good GC to pick up the pieces.

Just to be clear, I'm no Java booster. I've spent a good chunk of my career heavily involved with .NET. But for all of the talk about the superiority of the .NET platform and its illustrious value types, it's Java that quite soundly takes the performance crown when they go head to head.

This years JVM Language Summit

http://www.oracle.com/technetwork/java/javase/community/jlss...

Evolving the JVM By Brian Goetz and John Rose

Also, take a look at project valhala: http://openjdk.java.net/projects/valhalla/

And while we're in a world where Microsoft is saying "give it up with the whole value / reference type thing" (the value/reference type is an implementation detail)

No. First, they are semantically different, but second -- it's an implementation detail that provides better performance when used correctly. So, exactly what the parent was describing.

This is not to say that the CLR couldn't also optimize better, but personally I'm just voting for Project N.

It's an implementation detail that may provide better performance, but often provides no measurable difference at all (yes there is a profound semantic difference, and such is the foundation for the mechanism in the first place, but that hasn't been the context of this discussion). The parent was contrasting it against a JVM that does both better garbage collection, and actual escape analysis, so the comparison borders on absurd, and it is a statement made with zero context.

I can tell you that in Roslyn it is a very important component of our optimization strategy. System.Collections.Immutable.ImmutableArray is an obvious example.

As an extremely high performance managed application that competes directly with native code, it seems to be quite a good proxy for similar applications, including Minecraft.

Escape analysis can't handle the case when a short-lived object is returned from the scope it's created in. It will be heap allocated and become garbage soon after. Value types can be returned and still not become garbage. A further optimization of reference types might be ownership analysis, like rust's borrow checker, but I'm pretty sure that would require an analysis of the entire program, and so would not be possible without AOT hints

Reply on news.ycombinator.com