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

[Andrew Dinn]

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