RFR (XS) 8238247: CTW runner should sweep nmethods more aggressively

[Volker Simonis]

This looks good to me.

I wonder if there other possibilities  to make sweeping these methods
more efficient? Maybe setting -XX:MinPassesBeforeFlush=0 and
-XX:NmethodSweepActivity=2000 can help a little bit?

In the CTW case where we just batch-compile methods without ever
calling them it might also make sense to disable the concurrent
sweeper thread and call WB.forceNMethodSweep() directly. Unfortunately
I think there's currently no way to find out through WB if the
CodeCache is full, but we might get that information indirectly if a
compilation fails? Also, I think we can't currently disable the
sweeper thread with -XX:-MethodFlushing because then
WB.forceNMethodSweep() wouldn't work either (because it just notifies
the sweeper thread).

On Thu, Feb 6, 2020 at 2:50 AM Aleksey Shipilev <shade at redhat.com> wrote:
>
> RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8238247
>
> Candidate fix:
>   https://cr.openjdk.java.net/~shade/8238247/webrev.01/
>
> Current CTW runner leaves the just-compiled nmethods behind. At some point the sweeper comes in and
> make them go away, stabilizing on some number of nmethods. However, that stabilization point is too
> far away for the throwaway compilations CTW runner does.
>
> In the end, this leads to inflation of nmethod and dependencies population, which slows down the
> subsequent compiles and deopts. If you have a very large JAR file, it would take days to CTW. With
> this patch, it takes a few hours. applications/ctw/modules also improves quite nicely with it. See
> the comments in bug report for additional details.
>
> Testing: adhoc CTW runs, make run-test applications/ctw/modules
>
> --
> Thanks,
> -Aleksey
>