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

[Andrew Dinn]

Hi Lutz,

Thanks for persevering and obtaining these measurements. The benchmark
may not necessarily be a great indicator of real-world problems but it
is a better indicator of code cache performance than any other tests we
have seen so far. I'm happy to accept this as evidence that the patch
will improve performance. So, yes, reviewed!

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill

On 19/11/2019 14:35, Schmidt, Lutz wrote:
> finally(!) I was able to create some measurements which show kind of
> an effect on a real-world problem.
> 
> I added my timers when running the renaissance benchmark
> (https://renaissance.dev). I am well aware of the limitations. One
> could argue this benchmark does not solve a real-world problem.
> Furthermore, the optimizations do not have a visible effect on the
> overall runtime (> 1 hour) of the test. But at least, deep down, the
> inner mechanics of CodeHeap management show some timing difference. I
> have attached a file with some measurement data to this mail for
> convenience. The same file was also uploaded to the bug. The
> measurements are from runs on linuxppc64. Other platforms show
> similar results.
> 
> Here is what you can see (and my interpretation of the visible):
> 
> CodeHeap::mark_segmap_as_used()
> ===============================
> The number of segment map entries to be processed per call is reduced
> by a factor of 2.5 to 5. As a consequence, the time spent in the
> method decreases as well, but not by the same factor. This is due to
> the added check for fragmentation and the defragmentation itself
> which occurs twice and eliminates roughly 3.500 excessive fragments.
> 
> CodeHeap::add_to_freelist()
> ===========================
> Here, the free list length controls the effort spent. Depending on
> the platform, the length increases by a factor of 2 (with
> optimizations turned on) or decreases by the same factor. Even with
> increased free list length, the total time spent in the method
> decreases. That's obviously an effect of not having to search the
> free list from the beginning every time.
> 
> 
> I have created a new webrev, mainly to reflect the changes I applied,
> based on Thomas' comments: 
> http://cr.openjdk.java.net/~lucy/webrevs/8231460.02/
> 
> jdk/submit tests pending...
> 
> Please let me know if we have reached a state now where this change
> can be considered reviewed.