On Thu, 19 Sep 2024 08:43:50 GMT, sli-x <d...@openjdk.org> wrote: > Here with the limited codecache size, the free_ratio will get lower and lower > (so as the threshold) if no methods can be swept and thus leads to a more and > more frequent collection behavior. Since the collection happens in stw, the > whole performance of gc will also be degraded. > >So a simple solution is to delete the scaling logic here. However, I think >here lies some problems worth further exploring. > >There're two options to control a code cache sweeper, >StartAggressiveSweepingAt and SweeperThreshold. StartAggressiveSweepingAt is a >sweeper triggered for little space in codeCache and does little harm. However, >SweeperThreshold, first introduced by >[JDK-8244660](https://bugs.openjdk.org/browse/JDK-8244660), was designed for a >regular sweep for codecache, when codeCache sweeper and heap collection are >actually individual. After >[JDK-8290025](https://bugs.openjdk.org/browse/JDK-8290025) and some patches >related, the old mechanism of codeCache sweeper is merged into a concurrent >heap collection. So the Code cache sweeper heuristics and the unloading >behavior will be promised by the concurrent collection. There's no longer any >"zombie" methods to be counted. Considering it will introduce lots of useless >collection jobs, I think SweeperThreshold should be deleted now.
I think the general concern presented out by the code > // After threshold is reached, scale it by free_ratio so that more > aggressive > // GC is triggered as we approach code cache exhaustion is still valid. How this is implemented also makes somewhat sense: changes are the trigger for collections, allow larger changes before trying to clean out the code cache the emptier the code cache is. It tries to limit code cache memory usage by increasingly doing more frequent collections the more occupied the code cache becomes, i.e. some kind of backpressure on code cache usage. Your use case of limiting the code cache size (and setting initial == max) seems to be relatively unusual one to me, and apparently does not fit that model as it seems that you set code cache size close to actual max usage. Removing `SweepingThreshold` would affect the regular case as well in a significant way (allocate until bumping into the `StartAggressiveSweepingAt`) I do not think removing this part of the heuristic isn't good (or desired at all). Maybe an alternative could be only not doing this heuristic part in your case; and even then am not sure that waiting until hitting the `StartAggressiveSweepingAt` threshold is a good idea; it may be too late to avoid disabling the compiler at least temporarily. And even then, as long as the memory usage keeps being larger larger than the threshold, this will result in continuous code cache sweeps (_every time_ _any_ memory is allocated in the code cache). >From the [JDK-8244660](https://bugs.openjdk.org/browse/JDK-8244660) CR: > This is because users with different sized code caches might want different > thresholds. (Otherwise there would be no way to control the sweepers > intensity). Which means that one could just take that suggestion literally and not only change the initial/max code cache size but also that threshold in your use case. Stepping back a little, this situation very much resembles issues with G1's `InitiatingHeapOccupancyPercent` pre [JDK-8136677](https://bugs.openjdk.org/browse/JDK-8136677) where a one-size-fits-all value also did not work, and many many people tuned `InitiatingHeapOccupancyPercent` manually in the past. Maybe a similar mechanism at least taking actual code cache allocation rate into account ("when will the current watermark will be hit"?) would be preferable to replace both options (note that since I'm not an expert in code cache, there may be other reasons to clean out the code cache than just occupancy threshold)? Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/21084#issuecomment-2383475220
