Reduce SharedHeap::process_strong_roots time

[Coleen Phillimore]

On 07/29/2013 09:11 AM, Thomas Schatzl wrote:
> 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.

Yes, but at least they'll be together in the handle block rather than 
scattered through metadata in each klass.

The other idea we had early on is to have two _klasses array.   One for 
klasses before the mirror(s) have been promoted to old and one for 
afterward.   GC shifts the klasses from the first to the second.

>>
>> [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
>

For MVM we want to move the references_array pointer into the mirror, so 
that it's per-task.  I think this would also help GC because you 
wouldn't have to scan the _handles in ClassLoaderData anymore.   These 
things would likely be promoted together.

Coleen