5 ms·

This post seems to be based on certain erronous assumptions. First, he seems to believe that "size of allocated memory" == "longer collection time", this is no

by Skinney 12y ago

This post seems to be based on certain erronous assumptions. First, he seems to believe that "size of allocated memory" == "longer collection time", this is not true, especially when, as he says, most of the allocated memory is short lived. A GC only scans live memory and considers the whatever hasn't been scanned as garbage. If most of your memory isn't live, as seems to be the case here, collection should be relatively consistent, regardless of allocated memory or the memory available to the JVM. Increasing the memory available should actually increase performance, because the JVM can run collections less often. It seems to me that what the devs should do (instead of waiting for a proper struct implementation, like .NET has, on the JVM, which would avoid these problems) is to make BlockPos mutable and store unused objects in a cache/buffer. This might be (barely) slower than just allocating the memory, but used correctly it will trigger fewer collections as you allocate way less.

personZ 12y ago
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-truth-about-value-types.aspx 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.
- adrusi 12y ago
  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
- Skinney 12y ago
  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.
  - personZ 12y ago
    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.
    - Skinney 12y ago
      This years JVM Language Summit http://www.oracle.com/technetwork/java/javase/community/jlssessions-2255337.html 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/ http://openjdk.java.net/projects/valhalla/
    - Locke1689 12y ago
      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.

by Skinney 12y ago

personZ 12y ago

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-truth-about-value-types.aspx 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.

adrusi 12y ago
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
Skinney 12y ago
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.
- personZ 12y ago
  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.
  - Skinney 12y ago
    This years JVM Language Summit http://www.oracle.com/technetwork/java/javase/community/jlssessions-2255337.html 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/ http://openjdk.java.net/projects/valhalla/
  - Locke1689 12y ago
    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.