Proof-of-concet: Fast arraycopy/clone barrier for traversal

[Roman Kennke]

This is a proof of concept for a fast arraycopy/clone barrier for
Traversal GC. The idea is that what the barriers need to do
post-arraycopy or post-clone is basically the same thing that traversal
GC needs to do for any field:
- load the field
- evac the referent
- update the field
- enqueue the evac'd referent into task queue

so, instead of doing all this mutator thread, let's enqueue this work
for later processing by the GC. This should cut down the time that
mutators spend in barrier code after large arraycopy tremendously (to a
very short constant-time enqueue op).

The implementation is fairly basic: I've added a GrowableArray+lock
based queue (actually, it's a stack. duh.) array-copies with count >
certain threshold get pushed there, GC threads pop those tasks and
process them.

BTW, we seem to be getting lots of arraycopy with count==0. I've added a
short-circuit there. Might be worth looking where they come from, if
they come from compiled code, maybe short-circuit there, even before we
enter runtime land.

The same thing also works for clone. However, I've noticed that 1. many
clones have no refs at all, or very few refs. 2. if I enable this I get
a tremendous amount of traffic, to which the locking based impl clearly
doesn't scale ;-)

I disabled that path for now. We may want to check for objArrayKlass
with largish size and even instanceKlass with largish size to also catch
cases when somebody does a clone on such object. (Hey, has nobody ever
thought of implementing something like has_refs() in InstanceKlass? This
can't be so very difficult because it should be known at classloading-time?

I'm mainly sending this out for further experimentation and suggestions:
http://cr.openjdk.java.net/~rkennke/fast-arraycopy-barrier/webrev.00/

Cheers, Roman