Interesting, I mostly work in JVM, and am always impressed how much more advanced feature-wise the .NET runtime is.
Won't this potentially cause stack overflows in programs that ran fine in older versions though?
Interesting, I mostly work in JVM, and am always impressed how much more advanced feature-wise the .NET runtime is.
Won't this potentially cause stack overflows in programs that ran fine in older versions though?
I don't think the runtime is "much more advanced", the JVM has had most of these optimizations for years.
The JVM famously boxes everything though, probably because it was originally designed to run a dynamic language. An array list of floats is an array list of pointers. This created an entire cottage industry of alternative collections libraries with concrete array list implementations.
A float[] is packed and not a list of pointers in the jvm.
An ArrayList<Float> is a list of pointers though.
Arrays have a static fixed size though, making them far less useful in practice. Anything one builds with generics is boxed. Dotnet doesn't have this problem.
Currently you can get around this with Panama, even if the API is kind of verbose for the purpose.
Eventually value classes might close the gap, finally available as EA.
Valhalla is over 10 years in the works already and there is still no clear date when or if at all it would be released. It's very difficult to change (or fix) such fundamental things so late in the game.
Because it is a huge engineering effort to add value types without breaking existing binary libraries.
Doing a Python 3 would mean no one wanted going to adopt it.
Yes it is long process.
Some of the JEP in the last versions are the initial baby steps for integration.
They're famously working on changing that. I think we're all hopeful that we'll start seeing the changes from Valhalla roll in post-25.
Almost none of this is in the JVM. Escape analysis is extremely limited on the standard JVM, and it's one of GraalVM's "enterprise" features. You have to pay for it.
> one of GraalVM's "enterprise" features. You have to pay for it.
Free for some (most?) use cases these days.
Basically enterprise edition does not exist anymore as it became the "Oracle GraalVM" with a new license.
https://www.graalvm.org/faq/
One limitation of the stack is that it needs to be contiguous virtual addresses, so it was often limited when devices just didn't have the virtual address space to "waste" on a large stack for every thread in a process.
But 64 bits of virtual address space is large enough that you can keep the stacks far enough apart that even for pretty extreme numbers of threads you'll run out of physical memory before they start clashing. So you can always just allocate more physical pages to the stack as needed, similar to the heap.
I don't know if the .net runtime actually does this, though.
> So you can always just allocate more physical pages to the stack as needed, similar to the heap.
You set the (max) stack size once when you create the thread and you can’t increase the (max) size after that.
Processes see a virtual address space that is handled by the OS, so you would have to involve the OS if you needed to add to the stack size dynamically.
After process start and it's initial state, the stack is just another virtual address and the just sp another register. It can be mapped, remapped, changed to point to whatever. With overcommit even the initial state may not be entirely backed by physical pages.
Many userspace apps already do custom stack handling, it's how things like green threads work. And many non-native runtimes like .net already have custom handling for their managed stacks, as they often have different requirements and limitations to the "native" stack, and often incompatible formats and trying to isolate from possible bugs means there's less benefit to sharing the same stack with "native" code.
[dead]
> Won't this potentially cause stack overflows in programs that ran fine in older versions though?
That's certainly a possibility, and one that's come up before even between .net framework things migrated to .net core. Though usually it's a sign that something is awry in the first place. Thankfully the default stack sizes can be overridden with config or environment variables.
I am surprised that they didn't already do a lot of optimizations informed by escape analysis, even though they have had value types from the beginning. Hotspot is currently hampered by only having primitive and reference types, which Project Valhalla is going to rectify.