RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks

[Andrew Dinn]

Hi Lutz,

On 17/10/2019 20:52, Schmidt, Lutz wrote:
> Hi Andrew,
> 
> I don't expect a real-world test to show an effect which pops out of
> measurement noise. But I'll try. And I will add timing in the
> CodeHeap management methods to see how often they were called and how
> much time was spent in there.

Agreed.

> The most pathological (synthetic) test I could think of is 
> test/hotspot/jtreg/compiler/codecache/OverflowCodeCacheTest.java It
> obviously frees the code blobs in "the right order", such that there
> is just one free block which grows, and grows, and grows. If the
> sequence would be such that it would result in ten free blocks, the
> inefficiency would be much less visible.
> 
> Why? The original algorithm has an effort of O(n*n). If you divide
> the effort into ten parts, you get ten times O((n/10)*(n/10)) =
> O(n*n)/100. I hope this is somehow understandable. I'm not skilled in
> explaining mathematical facts in English.

I follow what you are saying. However, I'm interested to see how much
gain you get in a non-pathological case. The worst case gain is less
interesting than the common case gain.

I tweaked OverflowCodeCacheTest a little to provide a more realistic
allocate/free scenario. It woudl be useful to see before and after
figures for this test. The code is available here:

  http://cr.openjdk.java.net/~adinn/stresscodecache/StressCodeCacheTest.java

Here is a brief explanation of what it does:

The test allocates up to 90% of the cache with varying size blobs
(between 70% and 130% of the size used in the Overflow test). Once the
cache reaches 90% full it then frees some fraction of the allocated
blobs and starts allocating again. That process is repeated 10 times.

The frees are done in randomly sized runs of 3 to 15 successively
allocated blobs, with a probability of 1 blob being freed in each run.
Retained blobs are freed first on the next run before any newly
allocated blobs so the cache is slowly cycled.

n.b. feel free to tweak or improve it!

regards,


Andrew Dinn
-----------