Reduce SharedHeap::process_strong_roots time

[Thomas Schatzl]

Hi,

On Wed, 2013-07-24 at 10:09 -0700, Ioi Lam wrote:
> On 07/24/2013 08:32 AM, Coleen Phillimore wrote:
> >
> > Ioi,
> >
> > Do you have any benchmarks showing the times spent processing #2?
> Not yet :-(
> > Another idea is to make Klass::_mirror and ArrayKlass::_component 
> > mirror jobjects, which are java handles and store them in the 
> > ClassLoaderData::_handles area, just as the 
> > ConstantPool::_resolved_references array is stored.
> >
> I looked at ClassLoaderData::_handles, which is a JNIHandleBlock. It 
> looks like JNIHandleBlock::oops_do() still need to scan all the 
> references one-by-one. So we are just shifting the problem around.
> 
> [disclaimer: I have zero knowledge of how the various hotspot GC works] 
> -- I was hoping that if we use a proper Java object array to store the 
> references (to interned strings, mirrors, etc), the array will be 
> eventually moved to old generation. Then, scanning of the roots in this 
> object array can be done using card tables (more efficient than linear 
> scanning??). Also, if the mirrors are also moved into old generation, 

Card table scanning is linear scanning. The card table saves you
scanning parts of the array that do not contain interesting references.

> then we will have no need to scan them at all (during young GCs).
> 
> Is my understanding correct?

Yes.

Some idea that has been floating around, without guarantees that it
makes sense:

For generational gcs (parallel gc, CMS) one idea may be to keep track of
strings and ClassLoaderData on a per-generation basis, i.e. if the
string or a field of the class loader data points into old gen or not it
is in one or the other set. Actually the gc is really only interested in
the ones containing references to the young gen; to make that idea
simpler, the young gen sets could be an extra set in addition to the
existing "all" sets (i.e. stringtable/system dictionary).

Lookups may need to consult both sets; the gc keeps the set(s) current.

For G1 an option could be to keep track of interned strings or
ClassLoaderData on a per-region basis (it's a single oop per class
loader data? Even if not, the gc could put the same classloaderdata into
multiple per-region sets?), similar to what has been done for nmethods
already.

Thomas