[gclist] Re: gclist-digest V2 #55

[Hans Boehm]

On May 26,  8:01pm, Marc Shapiro wrote:
> Subject: [gclist] Re: gclist-digest V2 #55
>  || 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.)

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
comparatively
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
issue.

Hans



-- 
Hans-Juergen Boehm
boehm@mti.sgi.com