Class unloading in jdk15

[Roman Kennke]

Sorry, that was the wrong link. Please use:

https://builds.shipilev.net/openjdk-jdk/

Thanks,
Roman

> Also, I just learned that we made some changes (I have been away for a
> week and something). In particular, we re-ordered weak-roots and
> strong-roots processing and can reclaim memory a little earlier, and we
> have separate phases for weak and strong roots, which will report
> separate timings. Would it be possible that you test again with a recent
> jdk15 build, and send us the logs?
> 
> https://builds.shipilev.net/openjdk-shenandoah-jdk/
> 
> Thanks,
> Roman
> 
> 
>> Hello Vicente,
>>
>> Sometimes, the concurrent roots processing phase appears to become quite
>> long, e.g.:
>>
>> GC(6) Concurrent roots processing 661.442ms
>>
>> During that time, the application keeps allocating while the GC cannot
>> yet reclaim any memory, and eventually runs out of allocation space. At
>> roughly 1GB/s allocation rate, it'll take about 1/3rd of the total heap
>> during that time.
>>
>> The concurrent root time seems very much out of proportion. For example,
>> the corresponding marking phase only took:
>>
>> GC(6) Concurrent marking (unload classes) 75.039ms
>>
>> As a band-aid I suggest to run with more enforced headroom, e.g.
>> -XX:ShenandoahMinFreeThreshold=20 (instead of the default value of 10).
>> You may want to play with even higher values.
>>
>> We (the Shenandoah devs) shall look into what's going on there. I guess
>> that either the concurrent roots work is not parallelized well (and hogs
>> a single thread instead, thus taking longer to complete). We should also
>> make the heuristics take concurrent-roots-time into account when
>> computing trigger thresholds.
>>
>> Roman
>>
>>
>>> 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.
>>>
>>
>