Please forgive me for going a bit off-topic here, but I need to rant.
DaemonR: You are inexperienced, and you are giving inadvisable / irrelevant / ignorant advise. This is harmful to newcomers. Stop doing so until you really know what you are talking about, because as Combuster and I will demonstrate, you don't know what you are talking about.
DaemonR wrote:In fact, the kernel shouldn't manage memory at all. It should simply provide a function called sbrk that's used to extend the memory of the running application. Libraries like malloc and talloc then provide a wrapper around sbrk for alloc/realloc/free. This is why malloc.h is not part of the standard C library. Garbage Collection is a language runtime feature, not a kernel feature.
What the **** are you talking about? Managing memory at the page level is one of the most important tasks of the kernel! The data structure maintained by malloc is done entirely in user-space, but it is constructed in pages provided by the kernel.
Malloc is not a library, it's part of the standard library implementation, i.e. just as automatically-available as strlen in hosted C programs. Talloc is something entirely else, actually a library, but it's _not_ built upon sbrk as that would be highly dangerous, it's either built on malloc or mmap. Don't advise people to implement sbrk, it's a broken obsolete interface that cannot be used safely anywhere but in the malloc implementation, and even there it has serious design flaws such as not allowing the heap to be fragmented. The interface people should be advised to implement is mmap() - you can fairly easily implement a subset of it (no file mapping, just anonymous pages), and you can gradually improve it with more features. You can't do that with sbrk. In fact, it's best to stop talking about sbrk (unless telling people not to implement it) lest newcomers actually implement it (I did - what a waste of time).
You are missing the point. I think the OP is talking about using garbage collection inside the kernel, not providing it to user-space. This is entirely reasonable in principle. There are designs where the kernel could provide garbage collection to user-space, especially if the user-space code is managed. If the user-space code has not been verified, it's probably dangerous to do garbage-collection in the kernel from a security point of view.
Finally, the reason malloc.h is not part of the standard is that there is no reason for it to exist. The standard malloc(3)/free(3)/realloc(3)/calloc(3) routines are defined in the stdlib.h header. If a system has malloc.h it is non-standard and nobody knows to put in there. Some systems put malloc internals there. Either way, programs can't trust that header to do anything meaningful for them and including it is an error. Did you think malloc(3) was defined in malloc.h instead of stdlib.h? Then you really don't know what you are talking about.
DaemonR wrote:This is what shared libraries are for. Or you can just not use garbage collection for drivers (seeing as how that's probably a bad idea anyway) and just use sbrk itself.
DaemonR wrote:As I added to my previous post, you can still use sbrk. But that aside, I can't see a case in which you'd ever need memory allocation in a driver. To be honest, it sounds like a really bad idea.
What are you taking about? Shared libraries are generally a user-space thing (or are you thinking about loadable kernel modules, but still tyhen, what are you talking about). Have you even implemented real drivers? Memory allocations are useful there. Yes, you shouldn't do it in the main interrupt path to avoid deadlocks and have error cases, but it's perfectly reasonable to do memory allocations from drivers. Again, don't recommend code use sbrk, it cannot be safely used from outside of malloc (and malloc should be built using mmap).
DaemonR wrote:It doesn't have to be standardized in order to be part of a runtime. Malloc isn't standardized, yet it's still linked with the runtime by default. The point here is that garbage collection is a feature implemented and dependent on the language, not to debate whether or not it's defined by the language's standards.
Malloc is very much standardized. It's was added to Unix C after calloc proved a bit bothersome because it had two arguments for no real reason (at least, as far as I can see in the early Unix source code). It was standardized as part of C89. “still linked with the runtime by default” - I'm not sure what you mean here (and I fear you misunderstood something) but I see a single interpretation where this is true, so I won't bash that remark.
In short, while there are a few shattered truths in your posts here, they are generally filled with false information and bad advise. Please get more experience by implementing a real operating system, so you actually can be useful to newcomers. There is no reason to reply to my post, it'll only make more noise than good.