GC [LWN.net]

GC

Posted Oct 14, 2010 12:51 UTC (Thu) by droundy (guest, #4559)
In reply to: GC by aanno
Parent article: Quotes of the week

The trouble with GC seems to be that there is so much language-specific information that could affect its optimization, e.g. knowing which memory involves points. Pessimistic GC is leaky on 32-bit systems, besides being slow. How much information need a language runtime pass to the kernel? (And what to do about finalizers, soft pointers, etc.)

On the other hand, if there's *something* the kernel could do to help GC, that'd be great.

GC

Posted Oct 15, 2010 19:33 UTC (Fri) by kingdon (guest, #4526) [Link] (1 responses)

The patches in the paper don't get the kernel nearly that involved. They add a system call called vm_relinquish which means (roughly) "please swap out this page soon" and a way for the process to say "please send me a real-time signal when you're about to page out one of my pages". There is a version of their patch here (see also description). I also see a vm_getswaprate system call which lets the process ask how much it is paging. I think that's about it (the patch also includes Scott Kaplans lightweight version of Rik van Riels reverse mapping patch but unless I'm mistaken that was long ago merged into Linux).

GC

Posted Oct 17, 2010 15:57 UTC (Sun) by i3839 (guest, #31386) [Link]

Also, the quoted performance numbers are compared to other garbage
collectors, not to normal explicit memory allocation. And under heavy memory pressure when swapping happens. All in all less interesting that it seemed to be at first glance.