3 ms·
Kernels tend to want to be very specific about how memory is being used. GCs cause the opposite situation. i.e. these "specific requirements and limitations" y
by jblow 12y ago
Kernels tend to want to be very specific about how memory is being used. GCs cause the opposite situation.
i.e. these "specific requirements and limitations" you mention have a LOT to do with memory.
- msandford 12y agoKernels need to be very specific about how other program's memory is being used. And they try and keep their own memory usage low (and predictable) because that's easier to understand and debug and doesn't waste system resources. Just because there's a GC on the kernel's memory doesn't mean that the GC is somehow now working on all the process' memory that the kernel is running. That's not how the kernel works. The page table just holds a bunch of information about which processes are using which pages, garbage collecting a particular page table entry because the entry wasn't being used anymore wouldn't cause the memory which the entry was pointing to to suddenly be destroyed. And if the page table entry somehow gets to the point where it could be garbage collected that would mean that nothing is referencing it anymore, which would (in a properly written kernel free of bugs!) mean that the process isn't using the memory anymore, so there's no harm done.
- falcolas 12y agoYes, locations in memory, not the kernel's working memory space. i.e. so long as you can have your program loaded after a certain point, write to, and read from, specific locations in memory, you're fine. How the kernel manages its own memory is up to it (for example, one of the tasks which is required to bootstrap into C is establishing a stack so you can call a C method). EDIT: Real life example of a GC'ed kernel: https://en.wikipedia.org/wiki/JavaOS https://en.wikipedia.org/wiki/JavaOS