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?
Won't this potentially cause stack overflows in programs that ran fine in older versions though?
An ArrayList<Float> is a list of pointers though.
Eventually value classes might close the gap, finally available as EA.
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.
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.
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.
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.
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.
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.