Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx> wrote: > Shawn, any references for the ability of JIT's abilities to stack allocate in this context? For > me learning, will commit anyway. See [1] for example. I read a presentation from a HotSpot engineer at Sun a year or two ago that talked about it as a feature in the Sun Java 6 runtime, but I can't track that down now. Its a pretty simple concept. Folks realized that some types, e.g. StringBuilder, are often used only within a single stack frame, and that escape analysis can be used to prove that the StringBuilder instance is only visible within that stack frame. Doing a stack allocation instead of a heap allocation would allow the JVM to avoid creating unnecessary garbage. Ah, according to [2] the feature is only in 6u14 and later, and is an option you still need to enable on the command line. But its the direction the Sun JVM is going. I imagine it would be on by default in the future, various performance tests seem to indicate its a worthwhile optimization. [1] http://www.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-lnxw01JavaUrbanLegends [2] http://java.sun.com/javase/6/webnotes/6u14.html -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html