3 ms·

Quoting https://www.beyondjava.net/#/blog/escape-analysis-java https://www.beyondjava.net/#/blog/escape-analysis-java > Moving objects from the heap to the sta

Quoting https://www.beyondjava.net/#/blog/escape-analysis-java https://www.beyondjava.net/#/blog/escape-analysis-java > Moving objects from the heap to the stack > Many sources report that escape analysis moves Java objects from the heap to the stack. As Aleksey Shipilёv points out in his article about scalar replacement, the JVM does not do this implementation. It's just a misconception. But it's an interesting one, and I wonder why the JVM doesn't implement it.

mhaymo 8y ago
Interesting article, but the distinction you're making is quite subtle. Using escape analysis, Java can avoid heap allocations by removing the creation of the Object altogether, treating its fields as if they were local variables which live in registers/the stack. The practical difference between that and simply allocating the object on the stack is that no space is required for the object header, and some reference-based operations are not possible.
- MaxBarraclough 8y ago
  But the article states "Anything you create with new is always created on the heap."
  - mhaymo 8y ago
    Yes, but it then explains that escape analysis allows the runtime to avoid creating the Object entirely with scalar replacement. It's written in a confusing way, which is why I felt the need to clarify.
    - MaxBarraclough 8y ago
      Ugh, you're right, of course. In my defence the sentence I quoted isn't so much deliberately misleading, as outright false. It essentially states that 'new' always results in a heap allocation, which just isn't true. A profoundly unhelpful writing style, going out of its way to punish skim-readers. I'm reminded of this TV Tropes page: http://tvtropes.org/pmwiki/pmwiki.php/Main/ByNoIMeanYes http://tvtropes.org/pmwiki/pmwiki.php/Main/ByNoIMeanYes
MaxBarraclough 8y ago
Edit: Turns out that BeyondJava article is just poorly written, and tries so hard to emphasise its subtle distinctions that it ends up being actively harmful to the reader's understanding. I'll leave my comment anyway. From that article: > Java doesn't store any object in the stack. It does store local variables on the stack: primitive types like int or boolean. It also store the pointers to objects on the stack. But it doesn't store the objects themselves on the stack. Anything you create with new is always created on the heap. Is that true? For years now there have been articles from serious sources discussing JVM escape-analysis-based optimisations. Is there something mistaken in the analysis in this DZone article? https://dzone.com/articles/do-not-let-your-java-objects-escape https://dzone.com/articles/do-not-let-your-java-objects-esca... How about this StackOverflow answer, which even goes into the detail of distinguishing escape-analysis, stack allocation of objects, and object deconstruction+scalar replacement: https://stackoverflow.com/a/43002529/ https://stackoverflow.com/a/43002529/
sorokod 8y ago
Link to Shipilev's article: https://shipilev.net/jvm-anatomy-park/18-scalar-replacement https://shipilev.net/jvm-anatomy-park/18-scalar-replacement If stack allocation was really done, it would allocate the entire object storage on the stack, including the header and the fields, and reference it in the generated code. The caveat in this scheme is that once the object is escaping, we would need to copy the entire object block from the stack to the heap, because we cannot be sure current thread stays in the method and keeps this part of the stack holding the object alive. Which means we have to intercept stores to the heap, in case we ever store stack-allocated object — that is, do the GC write barrier.

mhaymo 8y ago

Interesting article, but the distinction you're making is quite subtle. Using escape analysis, Java can avoid heap allocations by removing the creation of the Object altogether, treating its fields as if they were local variables which live in registers/the stack. The practical difference between that and simply allocating the object on the stack is that no space is required for the object header, and some reference-based operations are not possible.

MaxBarraclough 8y ago
But the article states "Anything you create with new is always created on the heap."
- mhaymo 8y ago
  Yes, but it then explains that escape analysis allows the runtime to avoid creating the Object entirely with scalar replacement. It's written in a confusing way, which is why I felt the need to clarify.
  - MaxBarraclough 8y ago
    Ugh, you're right, of course. In my defence the sentence I quoted isn't so much deliberately misleading, as outright false. It essentially states that 'new' always results in a heap allocation, which just isn't true. A profoundly unhelpful writing style, going out of its way to punish skim-readers. I'm reminded of this TV Tropes page: http://tvtropes.org/pmwiki/pmwiki.php/Main/ByNoIMeanYes http://tvtropes.org/pmwiki/pmwiki.php/Main/ByNoIMeanYes

MaxBarraclough 8y ago

Edit: Turns out that BeyondJava article is just poorly written, and tries so hard to emphasise its subtle distinctions that it ends up being actively harmful to the reader's understanding. I'll leave my comment anyway. From that article: > Java doesn't store any object in the stack. It does store local variables on the stack: primitive types like int or boolean. It also store the pointers to objects on the stack. But it doesn't store the objects themselves on the stack. Anything you create with new is always created on the heap. Is that true? For years now there have been articles from serious sources discussing JVM escape-analysis-based optimisations. Is there something mistaken in the analysis in this DZone article? https://dzone.com/articles/do-not-let-your-java-objects-escape https://dzone.com/articles/do-not-let-your-java-objects-esca... How about this StackOverflow answer, which even goes into the detail of distinguishing escape-analysis, stack allocation of objects, and object deconstruction+scalar replacement: https://stackoverflow.com/a/43002529/ https://stackoverflow.com/a/43002529/

sorokod 8y ago

Link to Shipilev's article: https://shipilev.net/jvm-anatomy-park/18-scalar-replacement https://shipilev.net/jvm-anatomy-park/18-scalar-replacement If stack allocation was really done, it would allocate the entire object storage on the stack, including the header and the fields, and reference it in the generated code. The caveat in this scheme is that once the object is escaping, we would need to copy the entire object block from the stack to the heap, because we cannot be sure current thread stays in the method and keeps this part of the stack holding the object alive. Which means we have to intercept stores to the heap, in case we ever store stack-allocated object — that is, do the GC write barrier.