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

[Schmidt, Lutz]

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.

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. 

Regards,
Lutz


On 17.10.19, 18:35, "Andrew Dinn" <adinn at redhat.com> wrote:

    Hi Lutz,
    
    On 17/10/2019 16:36, Schmidt, Lutz wrote:
    > Thank you for looking at the change and, of course, for your thoughts
    > and comments.
    > 
    > Let me cover the easy part (heap.cpp:383 - 419) first:
    > ======================================================
    > I fully agree to your suggestions. Your wording is much clearer and
    > easier to understand. Your suggestions will be contained in the next
    > webrev iteration. I will not create a separate webrev just for that.
    
    Sure, no need to see another webrev on that account.
    
    > About the particular test:
    > ==========================
    > Yes, the test is completely synthetic in freeing thousands of
    > CodeHeap blocks in a row. Such a situation will most likely never
    > occur in a real-world workload. I was digging into this only because
    > the test timed out on some of our machines.
    > 
    > I'm not sure if we need another synthetic test to model the real
    > world. It would be possible as well to add the timing to some
    > real-world test(s) and analyze what's happening there. Would JBB2005
    > or JBB2013 be close enough to the real world?
    
    A real test is probably a good place to start. My thought re a synthetic
    test was that if the cache management time is only a small percentage of
    the total runtime then that may make it hard to accurately measure the
    benefit of the patch.
    
    Why not start by seeing if a real-world test provides a clear measurable
    difference? If that fails it might then be worth resorting to running a
    synthetic test that only exercises the cache management code. It would
    be good to have evidence that this is actually going to improve performance.
    
    > About the risk of segment map fragmentation:
    > 
    > ============================================
    > 
    > Yes, there will be some fragmentation. I never observed fragmentation
    > to become excessive, however. And there is reason for that: each time
    > a HeapBlock allocation is satisfied out of the FreeBlock list, that
    > segment map interval is re-initialized. ...
    Ah yes, (doh!). I guess you would need a truly pathological pattern of
    allocs and merges for that to fail to defrag the map.
    
    regards,
    
    
    Andrew Dinn
    -----------