RFR: Handle metadata induced GC

[Aleksey Shipilev]

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?

> 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.

-Aleksey