RFR(M): 8244660: Code cache sweeper heuristics is broken

[Man Cao]

Hi Nils,

Thanks for fixing this so quickly, and simplifying the logic!

Some high-level questions and suggestions:
*1. Sweep frequency *
With this new approach, is the sweeping expected to be less
frequent than the current approach, or more frequent? It looks more
frequent to me.

If I understand correctly, for the current approach, the conditions to
sweep are:
- Bytes from make_not_entrant_or_zombie() and make_unloaded() reach 1/100
of ReservedCodeCacheSize
OR
- Heuristics based on ReservedCodeCacheSize/16M, _time_counter
and _last_sweep.
I suppose the second condition is the "Number of safepoints with stack
scans" condition you mentioned,
which is not currently triggered.

With the new approach, the condition is:
- Bytes from make_not_entrant_or_zombie() and make_unloaded()
reach SweeperThreshold (1/256 of ReservedCodeCacheSize)

Is it better to make SweeperThreshold default to 1/100
of ReservedCodeCacheSize like before?
Also, could it be a percentage instead of a byte-size value?
In our experience, a percentage value is also easier to maintain for
production users.

We also would like to reduce the default sweep frequency, especially for
-XX:-TieredCompilation.
Because in JDK11, we have seen the higher sweep frequency caused regression
compared to JDK8,
and turning off code cache flushing could significantly improve performance.

*2. Sweep and make non-entrant*
> The threshold is capped at 1M because even if you have an enormous code
> cache - you don't want to fragment it, and you probably don't want to
> commit more than needed.
It is possible that sweeping will deoptimize some cold nmethods that will
be used soon.
Such deoptimizations could hurt performance more than fragmenting the code
cache.

Taking a closer look, perhaps the root problem is not just the sweep
frequency itself, but coupled
with the logic in NMethodSweeper::possibly_flush() to determine when to
make an nmethod not-entrant.
Perhaps the two flags NmethodSweepActivity and MinPassesBeforeFlush could
be adjusted
accordingly to the higher sweep frequency, to make JVM deoptimize fewer
cold but usable nmethods.

Do you think I should open a CR to investigate changing the default values
of these flags later?
It would be better if we could deprecate one of these two flags if they
serve the same purpose.

-Man