Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Watching Go's new garbage collector move through the heap

theconsensus.dev

Post reply on HN
Print view View original

21–30 of 48 posts

Re: Watching Go's new garbage collector move through the heap

#21

Post by Rohansi »

KolmogorovComp wrote: post #14
KolmogorovComp wrote: post #13

Tangential but this makes me think of a video about C# GC, and the developer switching to Swift to avoid it, in which the dev says they estimate the development of a pause-less GC to be 5B$ R&D away, does that ring the bell to anyone?

Ah it's from 2023, Miguel de Icaza : Swift Godot: Fixing the Multi-million dollar mistake: https://www.youtube.com/watch?v=tzt36EGKEZo Highly recommend.

Can't say I totally agree with the claim that GC is a dealbreaker for games. There are trade-offs either way and games typically need to do things a bit differently to achieve high performance anyway. It is, however, a strong benefit of Godot over Unity because Unity is still stuck with the worst possible GC (Boehm) for the foreseeable future.

Re: Watching Go's new garbage collector move through the heap

#22

Post by pjmlp »

Rohansi wrote: post #21
KolmogorovComp wrote: post #14

Earlier quoted context omitted.

Ah it's from 2023, Miguel de Icaza : Swift Godot: Fixing the Multi-million dollar mistake: https://www.youtube.com/watch?v=tzt36EGKEZo Highly recommend.

Can't say I totally agree with the claim that GC is a dealbreaker for games. There are trade-offs either way and games typically need to do things a bit differently to achieve high performance anyway. It is, however, a strong benefit of Godot over Unity because Unity is still stuck with the worst possible GC (Boehm) for the foreseeable future.

It isn't, some people managed to get quite rich with games written in GC languages.

There is an agenda there, the business did not go down well with Unity for Xamarin, and now there is the whole Swift for Godot that needs to be sold for adoption.

Unreal uses a GC for C++ code, yet the performance problem most people hit on Unreal is compiling shaders.

Finally from academia point of view, reference counting is a GC algorithm, as any book worth reading in CS curriculum will have it as such.

Re: Watching Go's new garbage collector move through the heap

#23

Post by anamax »

jerf wrote: post #6
nomorewords wrote: post #2

This was very interesting, but the ending was a bit abrupt. I was under the impression that there was something more that I was missing under the subscribe banner. But to the point of the article - are there cases in which manually moving objects around to compact them in a specific area is done with golang? I don't use golang that much, and I'm sure that there are very strong arguments for not compacting the heap po…

It's because of what's in the second paragraph, which I will paste here for convenience: "Taking a step back, Go manages memory by allocating objects of the same size class (an object’s size is rounded up to the nearest size class) within a contiguous chunk (or span in Go terminology) of one or more 8KiB pages. Size-segregated allocation is common in some malloc implementations (like tcmalloc, which Go’s allocator de…

> You can't get the inability to allocate some large object because there's a spray of small objects in its way ... The large objects live in their own space

Assume for the sake of argument that the large object space is for objects >=1MB.

Allocate lots of 1MB objects then free every other one (by address).

Unless you're willing to let the large object space grow without bounds....

Re: Watching Go's new garbage collector move through the heap

#24

Post by Someone »

anamax wrote: post #23
jerf wrote: post #6

Earlier quoted context omitted.

It's because of what's in the second paragraph, which I will paste here for convenience: "Taking a step back, Go manages memory by allocating objects of the same size class (an object’s size is rounded up to the nearest size class) within a contiguous chunk (or span in Go terminology) of one or more 8KiB pages. Size-segregated allocation is common in some malloc implementations (like tcmalloc, which Go’s allocator de…

> You can't get the inability to allocate some large object because there's a spray of small objects in its way ... The large objects live in their own space Assume for the sake of argument that the large object space is for objects >=1MB. Allocate lots of 1MB objects then free every other one (by address). Unless you're willing to let the large object space grow without bounds....

I haven’t read the article, but for allocations that large, chances are they get allocated as entire memory pages and the garbage collector returns that memory to the OS.

Also, even if it doesn’t, in a 64-bit address space it takes lots of 1MB objects to make that cause problems (there’s room for over 10¹⁶ of such objects)

Re: Watching Go's new garbage collector move through the heap

#25

Post by amelius »

okzgn wrote: post #7

Excellent optimization technique: manually copying objects to a new slice so they don't prevent the GC from releasing memory by sitting right in the middle of a page it intends to free.

That's what every "copying GC" does.

https://www.cs.cornell.edu/courses/cs312/2003fa/lectures/sec...

Re: Watching Go's new garbage collector move through the heap

#28

Post by bob1029 »

Rohansi wrote: post #21
KolmogorovComp wrote: post #14

Earlier quoted context omitted.

Ah it's from 2023, Miguel de Icaza : Swift Godot: Fixing the Multi-million dollar mistake: https://www.youtube.com/watch?v=tzt36EGKEZo Highly recommend.

Can't say I totally agree with the claim that GC is a dealbreaker for games. There are trade-offs either way and games typically need to do things a bit differently to achieve high performance anyway. It is, however, a strong benefit of Godot over Unity because Unity is still stuck with the worst possible GC (Boehm) for the foreseeable future.

> Unity is still stuck with the worst possible GC (Boehm) for the foreseeable future.

How are we measuring "worst possible" here?

Unity's GC is unique in that it has an incremental marking phase. The most important thing in a unity application is frame latency, not raw GC throughput. If you are generating so much garbage every frame that the incremental collector falls behind, that's probably on you.

Re: Watching Go's new garbage collector move through the heap

#30

Post by mnw21cam »

jeffbee wrote: post #12
toast0 wrote: post #10

Earlier quoted context omitted.

AFAIK, FreeBSD has been doing transparent superpages for decades (I think it was implemented in 2002 for x86 [1], and 2014 for arm [2]) and I don't know of any real issues with it? (I'm sure you could build a test case where it thrashes and causes trouble) Not sure why Linux wouldn't do the same?? [1] https://www.usenix.org/legacy/events/osdi02/tech/full_papers... [2] https://www.bsdcan.org/2014/schedule/attachments/…

Linux also has support for it but it is up to the distribution, or the user, to enable or disable it. The whole discourse was poisoned years ago when the author of Redis told everyone to disable THP on Linux, but this was caused by Redis being a poor program, not by THP being a poor feature. Unfortunately, even though the Redis project finally removed their document about this, many people still carry this bias.

There was also an issue with Linux about 8 years ago where the THP daemon would start busy-looping searching for pages to amalgamate, wasting loads of CPU time (and I believe freezing the processes it was inspecting), and so people were advising switching off THP for that reason until it was fixed. It hit our large Java processes quite badly.
Post reply on HN