[gclist] Re: gclist-digest V2 #55

[Marc Shapiro]

 || From: markj@cs.utexas.edu (Mark Stuart Johnstone)
 || Date: Sat, 24 May 1997 14:20:45 -0500
 || Subject: [gclist] Using VM hardware for GC
 || 
 || I've recently become interested in the issues involved with using an OS's
 || VM hardware to support generational garbage collection.  I looked over the
 || work by Hosking, Hudson, and Moss, and they pretty much seem to put the
 || question to rest by pointing out that the costs of scanning a VM page are
 || larger than the win by using the VM hardware for the write-barrier.

Let me qualify that: it's not the cost of scanning, it's the cost of taking
the page fault.  With current Unix implementations, a page fault costs many
orders of magnitude more than it should, considering hardware costs.

Not everybody is ready to throw away their favorite OS of course.  In some
contexts, such as academic research, or embedded systems, this is an option.
If you go that way, I'm willing to bet that you will find that Hosking's
conclusions are grossly exagerated.  (This is pure intellectual speculation of
course, as I have not done the exercice myself.)

 || They also argue that these costs will only get higher as page size
 || increases.  However, they don't address the possibility of the hardware
 || providing sub-page protection. So, what I am wondering is could a
 || processor built with sub-page protection (and the corresponding OS
 || support) be more efficient than a software only approach?

Hey, if you are willing to hack the processor, by all means, first consider
hacking the OS.  Sure, it's not easy, but it's a lot easier than convincing
Sun and Intel and Motorola to change their MMUs.

 || If so, any guesses as to what granularity of protection would be optimal?
 || I realize that the frequency of mutations has a lot to do with this
 || issue. I am currently most interested in Java as a target language.

I think you are way off target.  The cost of the Java VM is so high that any
GC costs are negligeable.  You would be better off modifying the VM to put in
a software write barrier.  Unless you are considering Java compiled to the
bare hardware?

                                                Marc