logoalt Hacker News

nasretdinov • today at 6:34 AM • 5 replies • view on HN

Unfortunately that's somewhat expected - regardless of implementation, the sole fact that the GC needs to somehow walk the entire tree to trace still referenced sections makes swap highly impractical -- even if you had not had 40ms stop-the-world pauses the LRU cache used by swap would get thrown away at every GC.

I believe that's actually the same reason why Apple stopped using GC in their frameworks in favour of automatic reference counting.


Replies

renox • today at 7:29 AM

> Unfortunately that's somewhat expected - regardless of implementation

Yes, that's expected and no not "regardless of implementation": the GC implementation CAN be improved.

See this discussion on reddit: https://old.reddit.com/r/programming/comments/1wf2fei/40ms_g...

Copy/pasted here: >>

I remember a research paper about swap and GC, where the GC cooperated with the OS to avoid this kind of issue. AFAIK it went nowhere, too bad.

[–]andreiross[S] 15 points il y a 21 jours

Are you talking about this one? https://cse.buffalo.edu/\~mhertz/bc-pldi-2005.pdf. If so, yes. Too bad. I don't know the repercusions this paper had in the past, though, in the sense of pros and cons of the bookmark collector. Don't know if anyone tried to actually implement it or design it at some point.

[–]renozyx 9 points il y a 21 jours

Yes, congratulations for finding it. And I don't know either,. Except that they did implement it on Linux (of course) https://plasma.cs.umass.edu/emery/cooperative-memory-managem...

<<

pjmlp • today at 6:53 AM

Reference counting is a GC algorithm, and no this isn't expected, it depends pretty much on the implementation.

Many make the mistake to think there is only one way to do a GC.

One of the authoritative books on the subject, https://gchandbook.org/contents.html

And a quite well known paper on the matter as well, https://dl.acm.org/doi/10.1145/1035292.1028982

➕ show 4 replies
torginus • today at 8:11 AM

Modern OSes need a facility to signal to a thread that it hit a paged out chunk of memory. It's not like it's not possible to create a swap-aware GC (or any other kind of code that touches lots of memory).

I would go further - I think the whole swap lifecycle needs to be communicated. Before the OS swaps out a page, if it could invoke the GC which would clean up that piece of memory so that we dont end up writing garbage to swap.

The OS should also allow marking pages as piority to stop them from being swapped out.

➕ show 1 reply
torginus • today at 8:16 AM

The issue described in the article isn't really GC specific. The Go GC has a critical section that reads metadata.

Any program that has a rarely accessed, but vital chunk of memory is vulnerable to this sort of issue.

the8472 • today at 7:59 AM

A region-based collector like Hotspot's G1 combined with madvise could probably operate in a manner that's more swap-friendly by focusing on a smaller working-set at any given moment and announcing its intent to switch the working set to the OS ahead of time.