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

[Schmidt, Lutz]

Hi Andrew,

I understand what you are interested in. And I was hoping to be able to provide some (first) numbers by today. Unfortunately, the measurement code I activated last Friday was buggy and blew most of the tests I had hoped to run over the weekend.

I will take your modified test and run it with and without my optimization. In parallel, I will try to generate some (non-random) numbers for other tests.

I'll be back as soon as I have results. 

Thanks,
Lutz 

On 21.10.19, 13:13, "Andrew Dinn" <adinn at redhat.com> wrote:

    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
    -----------