Class unloading in jdk15

[Zhengyu Gu]

Hi Vicente,

Thanks for reporting the problem.

I think we have a bug in setting up pacing for evacuation, where we can 
not reuse immediately garbage regions until concurrent class unloading 
is completed. I see a few allocation failures during that phase, that 
sent GCs into STW modes.

In the meanwhile, you way want to play with pacing parameters for 
aggressive pacing.

-Zhengyu

On 4/12/20 1:51 PM, Vicente Rossello wrote:
> Hi,
> 
> I tried shenandoah with JDK15 (latest build from builds.shipilev.net) in
> our build, it works better than with G1, without even tuning anything, so
> that's great.
> 
> I also tried enabling class unloading (we have it disabled with G1,
> we don't really get a lot of memory back, but GC times do increase a little
> bit), but it didn't work with shenandoah, GC times become very high.
> 
> These are GC logs of our full build, with and without class unloading:
> https://gist.github.com/cocorossello/2c7e774b89f7cb3e3c97ec5758d879ff
> 
> Our application is a web application, using dependency injection and
> dynamic proxies. I have tried to make a reproducer but I couldn't, it's not
> an easy task... Maybe the problem comes from dependency injection that
> creates proxies...
> 
> I have tried reducing the build and enabling class load/unload logs
> (-verbose:class), to see if that helps:
> 
> https://gist.github.com/cocorossello/f77049148e694b91e785696b1808fb4e  ->
> Reduced build, class unloading off, verbose class define
> 
> 
> https://gist.github.com/cocorossello/52c1c88c782adc1a0537fd8aa92a6c82  ->
> Reduced build, class unloading on, verbose class define
> 
> Please let me know if I can do something else, unfortunately I can't share
> the code.
> 
> Thank you,
> Vicente.
>