7 ms·
I haven't looked into the JVM's stack allocation logic in several years, so it may have improved to the point where that is now true. (It wasn't so in 2010.) Ho
by crawshaw 12y ago
I haven't looked into the JVM's stack allocation logic in several years, so it may have improved to the point where that is now true. (It wasn't so in 2010.) However, Go does have features that make it easier to control allocations than Java. One example,
type s struct {
x int32
y int32
}
v := make([]s, 1e5)
The object v uses 1e5 * 8 bytes of storage. Equivalent Java code would require boxing of each s value. That is, instead of []s, you end up with []*s and allocating each s.
- pcwalton 12y agoSure, I wasn't disputing that Go has more interior allocation features than Java does.
- chrisseaton 12y agoI wrote a blog post that showed how powerful JVM compilers like the new Graal can be with removing allocations. I can show a test case in Ruby running on Graal where there are many complicated objects that cross many method boundaries, and they're all entirely removed. http://www.chrisseaton.com/rubytruffle/pushing-pixels/ http://www.chrisseaton.com/rubytruffle/pushing-pixels/ Graal can do normal escape analysis, and so scalar replacements, but it can also do partial escape analysis - that is doing scalar replacement even if an object will later escape.