[gclist] Re: gclist-digest V2 #55
Mon, 26 May 1997 20:06:03 -0700
On May 26, 8:01pm, Marc Shapiro wrote:
> Subject: [gclist] Re: gclist-digest V2 #55
> || From: email@example.com (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
> || 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
> course, as I have not done the exercice myself.)
It's been a long time since I looked at real numbers, but my impressions is
that the costs are highly variable, with the mutation rate for software
barrier, and with the OS for a VM-based barrier. One or two operating systems
provide direct access to kernel-maintained dirty bits. This is sometimes
sufficent to implement a VM write barrier without handling page faults in user
code. Others vary greatly in the fault-handling cost. And the cost may vary
depending on seemingly irrelevant factors. For example, I think Irix has a
reasonable fault handling cost, unless you make the heap executable. At that
point the mprotect calls in the handler get much more expensive.
> 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?
Many Java implementations (including SGIs, Microsoft's and several freely
available Java-to-C translators) do compile to native code. I think it's fair
to say that GC is sometimes already an issue, though certainly not the only