I got this wild idea today, that one could use a HLL like some Lisp dialect to implement an OS kernel provided that (in addition to low-level access functions) one provided the Lisp code with 2 separate heaps. One of the heaps would be temporary, the other permanent. The permanent heap could be somewhat restricted to allow reference counting, or simply manually managed, while the temporary heap could contain all the throw-away structures that Lisp code creates.
The idea is basicly, that in case of a microkernel, the kernel flow-pattern is more or less "entry->process->return". I wouldn't be surprised if many C-kernel implementations reset the stack on every entry, so why not reset the temporary part of the heap too. Effective, the automatically managed part of heap is only available until the next return to userspace. Data that will be needed after this, must be saved manually to the permanent structures. As long as we can provide memory for a single run of the microkernel without garbage collection, no sophisticated (slow) GC is needed for the temporary stuff created.
One could even give each thread a separate temporary heaps space, similar to private kernel stacks, and with little runtime support even partial resets of the temporary heap could be supported (simply reset, then allocate those parts you need to preserve explicitly before allowing any other allocations).
In short, instead of specifying what to free or writing a garbage collector to do this, how about requiring the code to explicitly say if it actually wants something preserved. No idea if this is actually useful, just my wild thoughts..
HLL kernel memory management
-
Jamethiel
Re:HLL kernel memory management
I had a similar notion a while back, about having a number of interrupt-handler allocation areas that were reset on entry to the interrupt. It certainly is an attractive idea, but I don't think that I will be using it.
What I'm thinking now is that I'll have every interrupt perform a task switch, and I'll just have to make sure that time-critical interrupts don't cons. Since task switches should take O(1) time (apart from cache reloads and whatnot), this should be quite acceptable.
Most hardware interrupt handlers should just schedule a task for execution and kill the interrupt request anyway.
Another idea might be to have something like the EXTRA-PDL-AREA on the TI LispMs, which had special rules to it. Specifically, pointers to the EXTRA-PDL-AREA were not allowed "outside of the machine". That is, you could only hold them in registers and in the part of the stack that was cached. Any time you tried to write them out you would get a GC fault and the value would be moved to newspace. Of course, so far as I know, the EXTRA-PDL-AREA on the Explorer was only used for BIGNUMs, but there's no reason that something similar couldn't be arranged for interrupt handlers.
What I'm thinking now is that I'll have every interrupt perform a task switch, and I'll just have to make sure that time-critical interrupts don't cons. Since task switches should take O(1) time (apart from cache reloads and whatnot), this should be quite acceptable.
Most hardware interrupt handlers should just schedule a task for execution and kill the interrupt request anyway.
Another idea might be to have something like the EXTRA-PDL-AREA on the TI LispMs, which had special rules to it. Specifically, pointers to the EXTRA-PDL-AREA were not allowed "outside of the machine". That is, you could only hold them in registers and in the part of the stack that was cached. Any time you tried to write them out you would get a GC fault and the value would be moved to newspace. Of course, so far as I know, the EXTRA-PDL-AREA on the Explorer was only used for BIGNUMs, but there's no reason that something similar couldn't be arranged for interrupt handlers.