RFR (M) 8213753: SymbolTable is double walked during class unloading and clean up table timing in do_unloading
Aleksey Shipilev
shade at redhat.com
Wed Jan 30 14:01:16 UTC 2019
On 1/30/19 2:27 PM, coleen.phillimore at oracle.com wrote:
>> *) In SystemDictionary::do_unloading, do we think that trigger_cleanup() are cheap? Otherwise it
>> makes sense to retain a single GCTraceTime block around all three trigger_cleanups?
>
> The three trigger cleanups aren't specifically ClassLoaderData, so I didn't include them in the
> timing. I think people/tools might look for ClassLoaderData so I didn't want to change the name of
> the timing. Checking now...
>
> GCTraceTime(Debug, gc, phases) t("ClassLoaderData", gc_timer);
>
> I thought of removing it completely but the timing but the enclosing timers (exception in
> shenandoah) also include timing CodeCache::do_unloading and clean_weak_klass_links which are more
> expensive than ClassLoaderData.
My only (little) concern was that SD::do_unloading now has only one GCTraceTime("ClassLoaderData").
Without knowing beforehand if ::trigger_cleanup-s are cheap, it seems odd to drop GCTraceTime from
them. Something like:
GCTraceTime(Debug, gc, phases) t("Trigger cleanups", gc_timer);
ResolvedMethodTable::trigger_cleanup();
if (unloading_occurred) {
SymbolTable::trigger_cleanup();
// Oops referenced by the protection domain cache table may get unreachable independently
// of the class loader (eg. cached protection domain oops). So we need to
// explicitly unlink them here.
// All protection domain oops are linked to the caller class, so if nothing
// unloads, this is not needed.
_pd_cache_table->trigger_cleanup();
}
...but that can be indeed skipped if we know that those triggers cost much less than the timer itself.
-Aleksey
More information about the hotspot-dev
mailing list