Class unloading in jdk15

[Vicente Rossello]

Hi,

I just tested with latest jdk. Setting  ShenandoahMinFreeThreshold did help
a bit, but still no usable.

JVM Version: 15-testing+0-builds.shipilev.net-openjdk-jdk-b1226-20200420
With class unloading, no ShenandoahMinFreeThreshold set
https://gist.github.com/cocorossello/fc29a2471fff3cefaae5ef1cda9101d2

JVM Version: 15-testing+0-builds.shipilev.net-openjdk-jdk-b1226-20200420
With class unloading, ShenandoahMinFreeThreshold=20:
https://gist.github.com/cocorossello/ae193797899d9e3be040b7ef4a359803

JVM Version: 15-testing+0-builds.shipilev.net-openjdk-jdk-b1226-20200420
Without class unloading:
https://gist.github.com/cocorossello/35333cdd9e60b1283455143bfdec1516

Let me know if I can provide something else

Thanks,
Vicnete.

On Tue, Apr 21, 2020 at 12:24 PM Roman Kennke <rkennke at redhat.com> wrote:

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