FW: RFR(S): 8047812: Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops
Stefan Karlsson
stefan.karlsson at oracle.com
Mon Jun 23 15:45:47 UTC 2014
Markus,
You need to include all three mailing list in the same mail, or else the
mail threads will diverge.
thanks,
StefanK
On 2014-06-23 17:26, Markus Grönlund wrote:
>
> Sending this to the Hotspot-GC-dev group as well.
>
> /Markus
>
> *From:*Markus Grönlund
> *Sent:* den 23 juni 2014 17:03
> *To:* hotspot-runtime-dev; serviceability-dev
> *Subject:* RFR(S): 8047812: Ensure
> ClassLoaderDataGraph::classes_unloading_do only delivers klasses from
> CLDs with non-reclaimed class loader oops
>
> Greetings,
>
> Kindly asking for reviews for the following change:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8047812
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8047812/webrev01
> <http://cr.openjdk.java.net/%7Emgronlun/8047812/webrev01>
>
> Description:
>
> The "8038212: Method::is_valid_method() check has performance regression
> impact for stackwalking" - changeset introduced a change in how the
> ClassLoaderDataGraph::_unloading list of ClassLoaderData's is purged.
>
> This change to the purging of the CLD's work the same as before for
> most GC's, but when using CMS GC, SystemDictionary::do_unloading() is
> called twice with no explicit purge call in between. On the second
> call (post-sweep), we can now get stale class loader oops delivered as
> part of the Klass closure callbacks from the _unloading list. Again,
> this is because there is no explicit purge call in between these two
> entries to SystemDictionary::do_unloading() - and being CMS and
> concurrent, it is very hard to accommodate a timely and proper purge
> call here.
>
> The first do_unloading call comes after CMS concurrent marking, and
> the second comes from a Full GC triggered while sweeping the CMS heap.
>
> This fix ensures the unloading purge mechanism to work correctly also
> for the CMS collector, in that only CLDs with non-reclaimed class
> loader oops will deliver klasses from the _unloading list. In
> addition, this will ensure a single "logical" pass is achieved when
> iterating the unloading list in-between purges (avoiding the
> processing of the same data twice).
>
> This fix is precipitated by nightly testing failures with CMS after
> the introduction of 8038212: Method::is_valid_method() check has
> performance regression
> impact for stackwalking" - for example
> "nsk/sysdict/vm/stress/jck12a//sysdictj12a008" which is crashing
> because of following up stale klass loader oop's from the
> ClassLoaderDataGraph::_unloading list.
>
> Thanks
>
> Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140623/39254c02/attachment.htm>
More information about the hotspot-gc-dev
mailing list