Koundinya Veluri
Koundinya Veluri
I don't see any issues with this either, marked as ready-for-review
> I don't patch existing call-counting-stubs to avoid race conditions for now, will investigate how much memory they consume on close-to-real-world projects but I assume not much - they're pretty...
I won't be able to fully review this soon as I'll be on vacation, I'll take a closer look when I get back in a couple of weeks. cc @mangod9
Hmm you had mentioned on the other issue that 5.0 is free of this issue, is this really specific to 3.1? Timings have changed between 3.1 and 5.0 such that...
Also I don't think there should be any guarantee that there would not be any allocation happening in the background. As we move more stuff to managed code like the...
Ok I think it is the virtual slot backpatching storage. It's probably the rejit timing that is causing the allocation to happen earlier and not show up in the benchmark...
>> An alternative to the delay may be to set COMPlus_TC_AggressiveTiering=1 > I am afraid that this could lead to BDN reporting "too perfect" results that could differ from what...
> @kouvel is dotnet/runtime#45901 going to affect this behavior? will Tiered JIT stop allocating managed memory in the background thread? No it wouldn't affect the allocation. The allocation is from...
@timcassell the underlying issue is not fixed, it just may not be reproducing anymore by chance. When measuring GC allocations I would for now still suggest turning off tiered compilation...
Yes this should be fixed now in .NET 7.0 by https://github.com/dotnet/runtime/pull/67160