RFR: Handle metadata induced GC

[Zhengyu Gu]

On 10/24/2018 07:22 PM, Aleksey Shipilev wrote:
> On 10/24/2018 09:08 PM, Zhengyu Gu wrote:
>> To address this issue, we need to a mechanism to schedule asynchronous GC, so that, it does not
>> block metadata allocation when threshold is reached, allows asynchronous GC to cleanup metaspace in
>> background, and only force a full GC when metaspace OOM is actually reached.
> 
> You can request ShControlThread to perform explicit GC right now, can you not? I wonder if
> asynchronicity is actually the requirement, and I imagine it isn't, because how would STW GC satisfy it?

Yes, we can request explicit GC, but DisableExplicitGC and 
ExplicitGCInvokesConcurrent can stand in the way to make it useful for 
this scenario.

> 
>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/metadata_gc/webrev.00/index.html
> 
> Oh no, you don't! Do not expect to do a bulk rewrite of a critical GC code path without review
> friction. Solve the problem with minimal code possible, and then discuss improvements to the
> ShenandoahControlThread that could make it simpler.
> 
> Right now, it is completely impossible to follow what was changed to accept new behavior and what
> was the attempt at cleaning the code up. At _very least_ new functionality and code refactoring
> should go as separate changesets. Smaller, understandable, reasonable pieces with discussion why the
> particular piece is sane, please.

It is unfortunate that we only discover this so late in the game, and 
yes, it is risky.

I think I have another way to introduce asynchronous effect without 
schedule_async_gc_if_possible() and the scope of changes, let me try that.

Okay, I will get refactoring part in first.

Thanks,

-Zhengyu

> 
> -Aleksey
>