Reduce SharedHeap::process_strong_roots time

Coleen Phillimore coleen.phillimore at
Wed Jul 24 15:32:35 UTC 2013


Do you have any benchmarks showing the times spent processing #2?
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.

Then we have zero oops to follow in any metadata.

It has an extra complication with MVM because I need to virtualize them 
but I need to virtualize a lot of things in ClassLoaderData for MVM.

It might also cost a lock creating them but we only create the mirrors once.


On 07/19/2013 05:16 PM, Ioi Lam wrote:
> There are two large group of "strong roots"  scanned during inside 
> SharedHeap::process_strong_roots:
>     #1. interned strings
>     #2. Klass::_mirror
> For some large apps, it's common for #1 to be in the order of hundreds 
> of thousands, and #2 to be in tens of thousands.
> (There's also #3, system dictionary, but I am addressing that with 
> JDK-8003420).
> (#1 is partially addressed with parallel scanning JDK-8015237, but 
> it's still a large number per parallel task).
> I am wondering if we can simplify the scanning by using a form of 
> handles. E.g, instead of having
>     class Klass {
>       oop _java_mirror;
>       oop java_mirror() const              { return _java_mirror; }
>    }
> we have
>     class Klass {
>       int _java_mirror_index;
>       oop java_mirror() const              { return 
> _globalArrayOop->obj_at(_java_mirror_index); }
>    }
> This way, SharedHeap::process_strong_roots only has to scan a single 
> pointer: &_globalArrayOop.
> The up side would be reduced GC pauses.
> The down side is increased footprint, and potentially slower 
> performance. Because _globalArrayOop is a regular Java obj array, we 
> will need a separate int array to keep track of the free slots. So on 
> 64-bit platforms, we need an additional 12 bytes per reference.
> Also, there will be internal fragmentation in the _globalArrayOop 
> after class unloading, so in the worst case, more work needs to be 
> done (scanning a lot of NULL entries in this array).
> What do you think?
> - Ioi

More information about the hotspot-gc-dev mailing list