RFR: Handle metadata induced GC

[Zhengyu Gu]

Updated patch is based on current head without any refactoring.

Instead of introducing asynchronous GC, the new approach communicates 
metaspace OOM by informing GC heuristics, and allows it to start new GC 
cycle early and performs classes unloading, etc.

http://cr.openjdk.java.net/~zgu/shenandoah/metadata_gc/webrev.01/

Test:
   tier3_gc_shenandoah (fastdebug and release)

 
vmTestbase/metaspace/stressHierarchy/stressHierarchy012/TestDescription.java

Thanks,

-Zhengyu

On 10/25/2018 08:43 AM, Zhengyu Gu wrote:
> 
> 
> 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
>>