[gclist] Re: gclist-digest V2 #55

[Jeremy Fitzhardinge]

Hans Boehm wrote:
> On May 26,  8:01pm, Marc Shapiro wrote:
> > 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.

We've found in our Java implementation that after using a JIT to make
bytecode execution reasonably efficient, GC performance outweighs most
other factors for an interesting proportion of Java code.

We're currently using Hans' GC, and we've played with all the knobs to
get the most out of it.  We're using /proc to get dirty bit information
under Sparc Solaris (its completely broken on Intel Solaris), and it
certainly helps performance, but using it is still pretty expensive. 
It's clearly not something that Sun have bothered optimising (or
debugging; we've found a number of panic-causing kernel bugs in this
area).  We considered using SIGSEGV and signal handlers, on the
supposition that it might be more tuned in the kernel than an obscure
/proc feature, but this has other complications with regard to
system-call arguments and threading.

We've also noticed that using page dirtybit information is less useful
on Ultra-class machines, which have 8k pages, but we haven't yet
quantified this.

Despute the tuning work we've done with the conservative collector,
we're finding that it doesn't scale very well in the threaded case, and
generally gets bogged down in large heaps.

	J
	Softway Pty Ltd
	www.softway.com.au