3 ms·

This is .NET and not JVM, my previous comment describes how it works today. Be it C++, Rust or C#, the necessary space on stack is usually reserved in function

This is .NET and not JVM, my previous comment describes how it works today. Be it C++, Rust or C#, the necessary space on stack is usually reserved in function/method prologue when known statically. Additionally, because C# guarantees that all local variables/memory are initialized, the corresponding stack space is pre-zeroed (it is efficient since it is done with widest applicable writes - scalar, sse/avx(2/512)/neon, etc. (arm64 has dczva which kicks in above certain threshold). Regardless, the cost is not in bumping the offset/ptr or zeroing out the memory, it is in going through the allocator call (even if it's inlined, you're still executing more code) and the book-keeping required for heap allocations in general (both .NET's GC and allocators like Mimalloc do it), and then there is subsequent cost for tracking and collecting objects in the case of GC. In addition, .NET does not do escape analysis because, again, it is not JVM - while it may be added in the future, it is (relatively) unprofitable to do today because allocation traffic is far lower since everything isn't a potentially escaping object, and structs or stack-allocated buffers are often used in performance-sensitive code (or where it makes sense to do so in general). The way .NET views the objects is similar to the way C++ views heap allocated data, albeit with less aggressive (and often unsound or UB) assumptions compared to GCC. I cannot stress this enough that while JVM's escape analysis does lead to object stack-allocation, the reasoning the compilers can do about state of the data on stack is what e.g. JVM gets as a result of doing escape analysis, not vice versa. And other "unmanaged" languages are subject to similar limitations when it comes to stack vs heap.

vips7L 3y ago
IIRC escape analysis in HotSpot won’t actually allocate the whole object on the stack. It’ll explode the object into its sub fields and store them in registers or spill them into the stack if register pressure is high.
- astrange 3y ago
  This is a common optimization in any compiler, not just HotSpot. Although it's more important and more extensive in the JVM where almost everything is a heap allocation, yes. (Although the technical term isn't "escape analysis"; that just covers analysis, not resulting optimization.) I've noticed Microsoft seems to think ordinary compiler optimizations are deep magic they're very proud of not implementing. Do they just not have good enough compiler people?
  - vips7L 3y ago
    > Although the technical term isn't "escape analysis"; that just covers analysis, not resulting optimization. Yeah I meant scalar replacement!
  - neonsunset 3y ago
    > I've noticed Microsoft seems to think ordinary compiler optimizations are deep magic they're very proud of not implementing. Do they just not have good enough compiler people? What in our discussion has prompted you to respond with an ad-hominem attack?
    - astrange 3y ago
      That's not an attack, unless you designed .NET, in which case I'm of course referring to your recruiters and not you. Anyway, it's the part about how C# doesn't need to implement scalar replacement because it has structs. Do it anyway, it's good! But I've also noticed (reading some .NET developer blog post I couldn't find for you now) them talking about how they couldn't do inlining because it would take too long and be too slow, so they put some very simple heuristics that did not look like a good trade off. Inlining of course is often very beneficial and can decrease code size.
      - neonsunset 3y ago
        Well, this kind of attitude is just sad. Rather than imagining issues .NET has without verifying them first and then complaining, I'd like to suggest to spot check assumptions with Godbolt[0] which would be a good start (it can't show DynamicPGO, NativeAOT-specific and some other opts but is still fairly illustrative). A more comprehensive view of produced asm can be acquired with [DisassemblyDiagnoser] attribute when running code with BenchmarkDotNet [1] (in the Java world a similar solution is called JMH). [0] https://godbolt.org/ https://godbolt.org/ [1] https://benchmarkdotnet.org/articles/guides/getting-started.html https://benchmarkdotnet.org/articles/guides/getting-started....

vips7L 3y ago

IIRC escape analysis in HotSpot won’t actually allocate the whole object on the stack. It’ll explode the object into its sub fields and store them in registers or spill them into the stack if register pressure is high.

astrange 3y ago
This is a common optimization in any compiler, not just HotSpot. Although it's more important and more extensive in the JVM where almost everything is a heap allocation, yes. (Although the technical term isn't "escape analysis"; that just covers analysis, not resulting optimization.) I've noticed Microsoft seems to think ordinary compiler optimizations are deep magic they're very proud of not implementing. Do they just not have good enough compiler people?
- vips7L 3y ago
  > Although the technical term isn't "escape analysis"; that just covers analysis, not resulting optimization. Yeah I meant scalar replacement!
- neonsunset 3y ago
  > I've noticed Microsoft seems to think ordinary compiler optimizations are deep magic they're very proud of not implementing. Do they just not have good enough compiler people? What in our discussion has prompted you to respond with an ad-hominem attack?
  - astrange 3y ago
    That's not an attack, unless you designed .NET, in which case I'm of course referring to your recruiters and not you. Anyway, it's the part about how C# doesn't need to implement scalar replacement because it has structs. Do it anyway, it's good! But I've also noticed (reading some .NET developer blog post I couldn't find for you now) them talking about how they couldn't do inlining because it would take too long and be too slow, so they put some very simple heuristics that did not look like a good trade off. Inlining of course is often very beneficial and can decrease code size.
    - neonsunset 3y ago
      Well, this kind of attitude is just sad. Rather than imagining issues .NET has without verifying them first and then complaining, I'd like to suggest to spot check assumptions with Godbolt[0] which would be a good start (it can't show DynamicPGO, NativeAOT-specific and some other opts but is still fairly illustrative). A more comprehensive view of produced asm can be acquired with [DisassemblyDiagnoser] attribute when running code with BenchmarkDotNet [1] (in the Java world a similar solution is called JMH). [0] https://godbolt.org/ https://godbolt.org/ [1] https://benchmarkdotnet.org/articles/guides/getting-started.html https://benchmarkdotnet.org/articles/guides/getting-started....