Live data from Hacker News

.NET GC Internals mini-series

tooslowexception.com

51–60 of 77 posts

Re: .NET GC Internals mini-series

#51
post #24

Please forgive me ignorance, but why can't I manually delete an object? Lots of times I know this one object is pretty big and want to delete it when I am done with it, but have to force the GC to run to clean it up.

In extreme cases you might be able to emulate arena allocation by spawning an external process, create huge object, do some work on it, throw away the process. How viable this is depends on the programming language you are using. In erlang it can work great, because gc is per process (no shared memory) and you can use green-threads; in languages with very grummy GC like python it can also be worth considering[1] even with the cost of spawning a system process. I haven't kept up to date with Net, but my guess would be it's generally not a very attractive strategy.

[1] Refcounting will be instantaneous of course, but if you have a large heap with a lot of objects and GC kicks in you can have very long gc pauses (even if next to nothing will be reclaimed).

Re: .NET GC Internals mini-series

#52
post #18

Is this the GC that’s contained in one single 50,000 loc file?

Yes, a 43K line file. https://raw.githubusercontent.com/dotnet/runtime/master/src/...

Is this somehow concatenated together in a build process, or is it actually written and maintained like that?

Re: .NET GC Internals mini-series

#53
post #2

How do I know this person really knows about .NET GC internals for me to spend any time watching some videos?

He's very well known in the community. If one has been in any talks regarding .net gc, chances are they meet him there. Oh yeah he is also the author of an entire book about .net gc Pro .NET Memory Management. So I trust he knows what's he doing.

Re: .NET GC Internals mini-series

#54
post #18

Earlier quoted context omitted.

Yes, a 43K line file. https://raw.githubusercontent.com/dotnet/runtime/master/src/...

Is this somehow concatenated together in a build process, or is it actually written and maintained like that?

Originally it was written in lisp then translated using a tool. But I believe it's maintained like that.

Re: .NET GC Internals mini-series

#55
post #21

Anyone have a good comparison of .net vs java GCs? I never had trouble with the former but Java has been terrible. I'm not sure if its just my project or having the xmx memory cap.

Regarding Java GC's it depends pretty much which JVM implementation, and what GC is chosen from the pleothara that each vendor packages.

Even if it has the same name to other vendor, it doesn't mean it is 1:1, as each vendor fine tunes their own implementation.

This also applies to .NET actually, as there are other implementations besides .NET Framework/Core.

So it always boils down to profiling.

Re: .NET GC Internals mini-series

#56
post #54

Earlier quoted context omitted.

Is this somehow concatenated together in a build process, or is it actually written and maintained like that?

Originally it was written in lisp then translated using a tool. But I believe it's maintained like that.

I think this lisp part was in this talk, but I'm not 100% sure what he did say

Re: .NET GC Internals mini-series

#57
post #18

Is this the GC that’s contained in one single 50,000 loc file?

Yes, a 43K line file. https://raw.githubusercontent.com/dotnet/runtime/master/src/...

Lol this might be a common thing in MS language projects. I heard the Typescript compiler is also a single notoriously large file

Re: .NET GC Internals mini-series

#58
post #21

Anyone have a good comparison of .net vs java GCs? I never had trouble with the former but Java has been terrible. I'm not sure if its just my project or having the xmx memory cap.

.NET GC is nothing to write home about, pretty standard with long stop the world phase. It's not super interesting so nobody raves about it.

Java's new collectors ZGC and Shenandoah are state of the art, perhaps the best GC's in the world. There's collectors with lower latency and higher throughput but nothing out there that achieves both like Java's new collectors do.

It's a large part of why you hear that Java "performs better in production" than Go and C# even though those languages are faster in micro benchmarks. Java doesn't have value types and generates a ton of garbage but the collectors are good enough that it's still competitive with these faster languages.

Some will tell you that Go's GC is state of the art but I disagree. Last time it came up I started a huge flamewar in the comments so I'll avoid comparing them :).

Re: .NET GC Internals mini-series

#59
post #43
post #42

Earlier quoted context omitted.

There's an inherent issue with doing that while still being safe: what if there's still a reference to your "big object" somewhere? The only way for the runtime to know for certain it's safe to delete the object is to effectively run the GC anyway. The alternative is that the object gets deleted without any checks and any references to it will now (probably) cause a crash - and it'll be a hard native crash rather tha…

True but all it takes to fix this is to add if on the reference count of the object. You only need a full scan to handle circular references. You could have a gc.collect(obj) which will collect this object and all of its dependencies provided their reference count has gone to zero. And otherwise do nothing until the next full garbage collection.

But to get the reference count you’d need to run the entire mark phase.

Re: .NET GC Internals mini-series

#60
post #18

Earlier quoted context omitted.

Yes, a 43K line file. https://raw.githubusercontent.com/dotnet/runtime/master/src/...

Lol this might be a common thing in MS language projects. I heard the Typescript compiler is also a single notoriously large file

When you get into more "low level" domains, huge single files are more common. Some feel there is a correctness justification, being able to follow the code from top to bottom rather than jumping around, see: http://number-none.com/blow/blog/programming/2014/09/26/carm...

Personally I think it just doesn't matter. 50k lines of code is 50k lines of code. Whether it is in one file or 10 or 100, only changes whether you jump around via a file tree or other editor tools.

There are some practical problems when you get too huge though, like not being able to view the thing in github!

Post reply on HN