Use parallel OopStorage iterator to scan JNI, JVMTI and JFR (strong&weak) roots

[Roman Kennke]

This messed up the thread-local blocks. Fix:

Incremental:
http://cr.openjdk.java.net/~rkennke/par-roots/webrev.01.diff/
Full:
http://cr.openjdk.java.net/~rkennke/par-roots/webrev.01/

Ok now?

BTW, there are more possible improvements that keep popping up. For
example, some of the root oops_do() methods now take templated closures,
allowing to inline the actual closure calls. However, this needs some
sorting out in ShRootProcessor: it's starting to get real messy.

Roman

> We currently process JNI handles and the weak roots serially. Those are
> now backed by OopStorage and can easily be parallelized:
> 
> http://cr.openjdk.java.net/~rkennke/par-roots/webrev.00/
> 
> This should yield slightly better concurrency during root-marking.
> (Can't do any useful testing on puny laptop, but can't see why it would
> cause troubles either)
> 
> Testing: tier3_gc_shenandoah
> 
> Next step: this (at least the JNI and SystemDictionary/VM handles)
> should be easy to do *concurrent* with Java threads by implementing the
> *not_in_heap stuff in ShenandoahBarrierSet.
> 
> We should consider (later) that WeakProcessor is also called in our
> weak-ref-processing to update remaining roots. It's probably doing
> unnecessary double work, and this should probably also be parallelized.
> 
> Also, we need to consider (later) the string table roots. It seems that
> this is always scanned/marked when we do ref-processing, but it seems
> unrelated. I believe this should also go under the other weak roots and
> only be visited for updating remaining refs. As it is now, it would keep
> interned strings alive for no reason when ref-processing is active.
> 
> Roman
>