RFR: 8290025: Remove the Sweeper

[Erik Österlund]

On Thu, 4 Aug 2022 12:38:50 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Erik,
> 
> 
> 
> A time ago (not the current code base under review) I noticed that your code sweeper algorithm is more aggressive.
> 
> Capturing data from output of the -XX:+PrintMethodFlushing option (since the option does not exist in your code, 
> 
> I've added the printout of CodeCache::unallocated_capacity), I build a CodeCache capacity picture 
> 
> while the application run (jmh renaissance benchmark with -f 0 option). Before the changes, free space was steadily declining.
> 
> With your change, cold methods were quickly cleaned up despite the fact that the cache is less than half full.
> 
> 
> 
> (I try to insert pictures here: before and after the change)
> 
> ![before](https://user-images.githubusercontent.com/42576543/182845087-c2631745-6662-46c2-8fd0-578be35b1163.png)
> 
> ![remove-the-sweeper](https://user-images.githubusercontent.com/42576543/182845246-d3e19628-1a8d-4d8f-8673-c5fd33b5fe4a.png)
> 
> 
> 
> My concern is that there may be performance degradation in cases where the application periodically changes activity while running.
> 
> 
> 
> thanks,
> 
> Boris

I would be interested in seeing what the graph looks like with my current proposed change. I don't know what state my prototype was in when you performed measurements, and the heuristics have been tweaked.

Having said that, if half the code cache was filled up, it sounds like it's getting to a point where you do want to flush things that haven't been used in a long while, to avoid getting into the "red zone" of aggressive sweeping at 90%, in order to free up space for currently hot code. To me it looks like it is working kind of as expected.

Was there a regression due to unloading perceivably cold code?

You can get more information about the heuristic decisions with -Xlog:codecache with my change.

-------------

PR: https://git.openjdk.org/jdk/pull/9741