Regarding testing the garbage collector, nothing beats seeing decaf survive
three or more GCs ... as I know to my cost from trying to get this to work
back in October/November, it all falls into a quivering heap if the
slightest thing goes wrong. The test code I wrote was spectacularly
underpowered in comparison.
-- George
> -----Original Message-----
> From: Todd L. Miller [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, March 08, 2000 3:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JOS-Kernel] Kernel Tests
>
> > It is possible, isn't it? We can write C/C++ programs to
> test/demonstrate
> > kernel functions. At the point where jJOS invokes decaf, jJOS could
> invoke
> > a power-on self-test, a diagnostic program, or some other
> > test/demonstration program written in C/C++.
>
> The kernel right now is cleanly (sort of) divided between the
> ASM, C, and C++ sections. The C++ sections could be unit tested by class,
> but almost all of the ASM can't be tested without running it. Someone
> who's sufficiently adventerous might be able to hack kdb or VMware to help
> out here, but I'm certainly note one of them :) The C section is the
> garbage collector, whic is One Of Those Things I Would Someday Like To Try
> My Hand At. I'm not really sure what the proper testing procedure for a
> garbage collector (esp. on written in C) might be, but if you're curios,
> ask George Marrows, who wrote it.
>
> > Where and when should we implement memory management? In the kernel? Or,
> in
> > decaf? Should we do it now, when there is no swap file? Or later?
>
> No, definitely not in decaf. The memory management is going to be
> intimately tied with the virtual memory system and the garbage collector,
> so they'll need to be looked at together. (For instance, it may be
> worthwhile to garbage-collect a page before swapping it out, and so on; do
> we prefer to garbage collect before swapping when we run out of RAM? How
> does the pager's LRU list interact with the possibility of generational
> GC? Etc.)
>
> > We should implement memory management in the kernel. The host build of
> the
> > kernel simply uses the memory management of a foreign operating system.
> The
> > i386 build of the kernel must implement memory management independently
> > from any other operating system.
>
> Since we're currently running a monolithic system, much less a
> monolithic kernel, I have to agree with you here. On the other hand,
> Linux seems to be doing just fine with a user-space swapper, etc -- and
> Mach with its microkernel architecture. Whatever we en up doing w.r.t. to
> memory management should be portable with the minimum of effort to
> whatever kernel/system design we end up `finalizing' on.
>
> -_Quinn
>
>
>
> _______________________________________________
> Kernel maillist - [EMAIL PROTECTED]
> http://jos.org/mailman/listinfo/kernel
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
