See also: Preparing for the .NET 10 GC - https://news.ycombinator.com/item?id=45358527
What .NET 10 GC changes mean for developers
1–10 of 253 posts
Re: What .NET 10 GC changes mean for developers
#2On the topic of DATAS, there was a discussion here recently: https://news.ycombinator.com/item?id=45358527
Re: What .NET 10 GC changes mean for developers
#3Interesting, 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?
Re: What .NET 10 GC changes mean for developers
#4I think that DATAS also has more knobs to tune it than the old GC. I plan to set the Throughput Cost Percentage (TCP) via System.GC.DTargetTCP to some low value so that is has little impact on latency.
https://learn.microsoft.com/en-us/dotnet/core/runtime-config...
Re: What .NET 10 GC changes mean for developers
#5Interesting, 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.
Re: What .NET 10 GC changes mean for developers
#6Very mixed feelings about this as there’s a strong case for the decisions made here but it also moves .NET further away from WASMGC, which makes using it in the client a complete non-starter for whole categories of web apps.
It’s a missed opportunity and I can’t help but feel that if the .NET team had gotten more involved in the proposals early on then C# in the browser could have been much more viable.
Re: What .NET 10 GC changes mean for developers
#7Interesting, 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?
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.
Re: What .NET 10 GC changes mean for developers
#8Are you now allowed to benchmark the .Net runtime / GC?
Edit: Looks like you are allowed to benchmark the runtime now. I was able to locate an ancient EULA which forbade this (see section 3.4): https://download.microsoft.com/documents/useterms/visual%20s...
> You may not disclose the results of any benchmark test of the .NET Framework component of the Software to any third party without Microsoft’s prior written approval.
Re: What .NET 10 GC changes mean for developers
#9Are you now allowed to benchmark the .Net runtime / GC? Edit: Looks like you are allowed to benchmark the runtime now. I was able to locate an ancient EULA which forbade this (see section 3.4): https://download.microsoft.com/documents/useterms/visual%20s... > You may not disclose the results of any benchmark test of the .NET Framework component of the Software to any third party without Microsoft’s prior written appr…
...Were you not before?
Re: What .NET 10 GC changes mean for developers
#10Are you now allowed to benchmark the .Net runtime / GC? Edit: Looks like you are allowed to benchmark the runtime now. I was able to locate an ancient EULA which forbade this (see section 3.4): https://download.microsoft.com/documents/useterms/visual%20s... > You may not disclose the results of any benchmark test of the .NET Framework component of the Software to any third party without Microsoft’s prior written appr…
why wouldn't you be?