<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Garbage Collection for Multicore NUMA Machines · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1105.2554/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/1105.2554/feed.xml" rel="self" type="application/rss+xml" /><item><title>Garbage Collection for Multicore NUMA Machines — mentioned by larsberg</title><link>https://news.ycombinator.com/item?id=3395691</link><guid isPermaLink="false">urn:hackerpapers:mention:1105.2554:3395691</guid><pubDate>Tue, 27 Dec 2011 13:33:14 GMT</pubDate><description>&lt;p&gt;It&amp;#x27;s still not trivial even with massive parallelism. Performance is easily killed if you: 1) Completely saturate the memory interconnect between the processors and RAM chips 2) If your parallel collector threads are touching the same memory that your worker threads are, you&amp;#x27;re going to have some cache contention 3) One of the big challenges with cache lines that have writes in them is if they are shared between processors. For example, create two ref cells and have two parallel threads set them -- if the compiler did not happen to pad them out to cache line size, they&amp;#x27;ll be fighting for the…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1105.2554/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.PL</category></item></channel></rss>
