| |||||||||||||
The Managed Runtime Initiative kernel modificationsThe Managed Runtime Initiative kernel modificationsPosted Jun 17, 2010 10:05 UTC (Thu) by cesarb (subscriber, #6266)In reply to: The Managed Runtime Initiative kernel modifications by bgallmeister Parent article: The Managed Runtime Initiative
Let me see if I understood. You are saying "pluggable memory managers and schedulers" are not how it should be, but only a way of separating the code so it is easier to discuss? That is, the way you would really want it done is actually changing the core mm and sched code directly, instead of changing it to create a pluggable interface and then plugging the things you want done over it?
I think everyone is going to discuss the "pluggable" part and ignore the rest of the code.
(Log in to post comments)
The Managed Runtime Initiative kernel modifications Posted Jun 17, 2010 14:44 UTC (Thu) by giltene (guest, #67734) [Link]
The purpose of releasing the code, and of the initiative as a whole, is to demonstrate the value of new functionality [as it pertains to improving runtime execution] and to advocate for the inclusion of such functionality in upstream projects and products. We think that "solving" garbage collection [across the 1GB-640GB range] is a pretty good demonstration, and will be interesting enough to consider the inclusion of the new functionality and interfaces that make it possible.
We fully expect that the code itself will morph 17 ways before it is accepted upstream. It's layout will change. It's APIs will change, and the functionality it provides will change, as people comment/argue about other generic uses of the same capabilities and how to best integrate the new functionality and interfaces with the existing ones [e.g. should/could everything be done under madvise? Should mmap be extended with new options?].
Whether pluggable memory modules are good/bad will be a separate [sub]discussion - and we're not that attached to either form. It's a good development vehicle for now, and makes it convenient to focus most of the big functionality additions and new interfaces in isolated modules while their details are being ironed out and stabilized. Rapid fire changes to system calls is usually a bad thing, and a loadable module with ioctls allows for easier to experimentation and morphing.
The Managed Runtime Initiative kernel modifications Posted Jun 18, 2010 9:09 UTC (Fri) by cmot (subscriber, #53097) [Link]
I have the suspicion that a large (and apparently under-documented) code dump like this will never seriously be looked at in depth.
The way to get code in the kernel has always been small, incremental steps (or subsystems that are well isolated and speak to the kernel using established APIs, like new filesystems/drivers/... - but memory management and CPU scheduling code is probably not in this category...)
The Managed Runtime Initiative kernel modifications Posted Jun 18, 2010 9:59 UTC (Fri) by marcH (subscriber, #57642) [Link]
> I have the suspicion that a large (and apparently under-documented) code dump like this will never seriously be looked at in depth.
All good then, since the post you are replying to explains this was not a goal.
|
|||||||||||||