hi john-


>The problem with the object management code has been a TOTAL lack of
>understanding.  There is absolutely no documentation on the technique
>(I believe that the MACH people simply ignored it.)  

yes, i agree that the documentation in this area is not very good.
it was pretty frustrating trying to understand that code (and i started
before the 4.4bsd book was available so all i had was mach papers and
source code).

because of my experience with the bsd/mach code, i've been making efforts
to improve the state of documentation with uvm.   i'd like for people 
(especially students!) to be able to look at the documentation and code 
and find it at least somewhat understandable.   

to do this i've taken several actions.   first, i've tried to comment
the source code well (especially when something "tricky" is happening).
not only should this help people reading the code for the first time,
but it also helps me because the vm code is so large that i tend to
forgot why i've done something if i haven't worked on it in a while.
comments help me remember.    

second, i've been writing a document that explains that design and
implementation of uvm.   since i have to write something like this 
for my school work anyway, i figure that i might as well put it in 
as useful a format as possible.   this is what i've been working 
on recently.   the document is written using latex, has postscript 
figures, and is currently about 100 pages (it looks like it will end 
up around 200 or so pages -- i've got more work to do in this area...).

third, i've included a "history" feature in uvm that can be used either
for debugging or for learning more about the code.   the idea is that
you can take the log output from this and use it to help trace your way
through the source code and learn what path a process takes through
the source code to handle a specific vm event (e.g. page fault, fork,
protection change, etc...).   while using this i discovered several 
redundant vm calls uvm inherited from bsd/mach vm in the fork/exec/exit 
path of the code.

finally, i've tried to improve vm-related debugging commands of ddb.
i fixed the kernel printf so that it could do all the formatting of
the libc printf and then cleaned up the output of "show proc", "show map",
etc.   once all the documentation is in place, this should make it easy
for people like Jim to break into ddb and see what the VM system is 
currently up to.


>The object mgmt is complex only due to a lack of understanding.  I don't
>know how to explain it, and indeed it is different that previous practice.

yeah, i understand what you are saying.   being so familiar with 
my code, i've found it hard to write "entry level" documentation 
for it.  fortunately i've got an excellent proof-reader who gets
on my case when i write something that isn't clear...



>I think that you are doing good work, and any criticism of a 
>position taken or code written should not be inferred as criticism 
>of your work.  The UVM stuff is interesting (and I have had the ability
>to see it for much longer than it has been publically available,
>but I didn't want anyone to violate confidientiality), and
>valuable.

thanks!   there is still lots of cleanup and tuning to be done on
uvm, so it is a bit premature to take a hard critical look at the 
performance issues.   also, the issue of merging the vm and buffer 
cache hasn't been addressed yet either (although it is being worked
on).

chuck