Hi Coleen,
On 8/8/18 13:36, coleen.phillim...@oracle.com wrote:
Hi Serguei, Thank you for the code review. I thought you were going
on vacation so I pushed it already.
No problem, it is my fault I replied that late.
I will add a comment next time I change classLoaderData, which is
Hi Serguei, Thank you for the code review. I thought you were going on
vacation so I pushed it already.
I will add a comment next time I change classLoaderData, which is
probably soon.
Thank you!
Coleen
On 8/8/18 4:15 PM, serguei.spit...@oracle.com wrote:
Hi Coleen,
It looks good to
Hi Coleen,
It looks good to me.
Thank you a lot for taking care about this!
This refactoring is tricky so it is worth to add a comment, for instance,
to explain the conditions/logic that trigger metaspaces cleaning.
It can be added to the should_clean_metaspaces or do_cleanup_tasks where
it is
On 8/7/18 8:37 AM, Erik Österlund wrote:
Hi Coleen,
Thank you for moving this stuff out of the class unloading path.
One tiny question... would it be possible to have
ClassLoaderDataGraph::should_clean_metaspaces() not have side effects,
and make the resetting explicit? I always get
Hi Coleen,
Thank you for moving this stuff out of the class unloading path.
One tiny question... would it be possible to have
ClassLoaderDataGraph::should_clean_metaspaces() not have side effects,
and make the resetting explicit? I always get confused when getters have
side effects. Or maybe
Summary: move to safepoint cleanup actions to do if needed.
This is in support of concurrent class unloading. See bug description
for more details.
open webrev at http://cr.openjdk.java.net/~coleenp/8208677.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8208677
Ran mach5