Messages in this thread | | | From | "Zack Weinberg" <> | Subject | Re: Garbage collectors and VM | Date | Fri, 04 Jul 2003 09:13:33 -0700 |
| |
Jamie Lokier <jamie@shareable.org> writes:
> Zack Weinberg wrote: >> Thus, a new pseudo-device, with the semantics: > > I like it! I'd use it, too.
Thanks. Implementing it is way beyond me, but it's good to hear that other people might find it useful.
>> * Reading from the descriptor produces a list of user-space pointers >> to all the pages that have been reset to read-write since the last >> read. > > Would it be appropriate to have a limit on the number of pages which > become writable before a signal is delivered instead of continuing to > make more pages writable? Just like the kernel, sometimes its good to > limit the number of dirty pages in flight in userspace, too.
Maybe. The GC I wanted to use this with is rather constrained in some ways - it can't walk the stack, for instance - so it can only collect when the mutator tells it it's okay. I suppose it could just copy the list to its own buffer and continue, which saves the kernel from having to store a potentially very large list.
>> * I never decided what to do if the program forks. The application I >> personally care about doesn't do that, but for a general GC like >> Boehm it matters. > > It should clone the state, obviously, and COW should be invisible to > the application :)
Well, yeah, that would be the cleanest thing, but it does require two dirty bits.
> Btw, are these pages swappable?
They certainly ought to be.
> On a different but related topic, it would be most cool if there were > a way for the kernel to request memory to be released from a userspace > GC, prior to swapping the GC's memory. Currently the best strategy is > for each GC to guess how much of the machine's RAM it can use, however > this is not a good strategy if you wish to launch multiple programs > each of which has its own GC, nor is it a particularly good balance > between GC application pages and other page-cache pages.
Again, this is not particularly useful to me since the collector can't collect at arbitrary points - but it would be a good thing to have for a general GC, and maybe I ought to be using a general GC anyway...
zw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |