RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment for ARM

[Lutz Schmidt]

On Tue, 10 Sep 2024 11:02:38 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>>> There were several optimization done for this code by @RealLucy [JDK-8223444](https://bugs.openjdk.org/browse/JDK-8223444) and [JDK-8231460](https://bugs.openjdk.org/browse/JDK-8231460). But it is still using `linked list` for free segments. Should we consider something more complex? Or it is not an issue?
>> 
>> During my testing of the mentioned fixes, I never saw such long freelists. They can only appear with really severe fragmentation in the code cache. Artificial creation would work like allocating many (small) code blobs and then freeing every other.
>> 
>> Adjacent free slots are fused (combined together) during free processing. During code blob allocation, the free list is searched first for a match. That usually helps well against a growing free list. To gain more insight, you may want to try `-XX:+PrintCodeHeapAnalytics`. The same information (with more options) is also available via jcmd.
>> 
>> CodeCacheSegmentSize should not be chosen too small to keep memory and processing overhead in check. 64 bytes appears to be a feasible choice.
>
>> During my testing of the mentioned fixes, I never saw such long freelists.
> 
> I see the warning every time I run Renaissance benchmarks with the VerifyCodeCache option. Is this a problem and not just a reflection of the fact that the codeheap contains 20K of methods with some holes in between?
> 
> 
> $ ./build/linux-aarch64-server-fastdebug/jdk/bin/java -XX:+VerifyCodeCache -XX:+PrintCodeCache -jar ~/renaissance-jmh-0.14.2-95-gae3b5ce.jar Dotty
> # Run progress: 0.00% complete, ETA 00:00:00
> # Fork: 1 of 5
> # Warmup Iteration   1: 86079.453 ms/op
> # Warmup Iteration   2: 8212.947 ms/op
> # Warmup Iteration   3: 5416.496 ms/op
> # Warmup Iteration   4: 6841.073 ms/op
> # Warmup Iteration   5: 4248.337 ms/op
> # Warmup Iteration   6: OpenJDK 64-Bit Server VM warning: CodeHeap: # of free blocks > 10000
> 3530.697 ms/op
> # Warmup Iteration   7: 3186.153 ms/op
> 
> 
>> CodeCacheSegmentSize should not be chosen too small to keep memory and processing overhead in check. 64 bytes appears to be a feasible choice.
> 
> OK. Thanks!

@bulasevich Thanks for providing the Code Heap Stats.

At vm shutdown time, when the stats were taken, there is no pathological state in the code heap. 

- non-profiled nmethods has 70 free blocks, occupying 1033k in total.
- profiled nmethods has 525 free blocks, occupying 5550k in total.
- non-nmethods has 5 free blocks, occupying 263k in total. 

The warning must be triggered by a transient situation, when many methods are removed from the code heap in a short period of time, without significant new method compilations. Eventually, this large number of free blocks will either be reallocated for new compilations or collapse into less, but larger, blocks when even more methods are removed from the code heap. 

In short: no need to worry.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20864#issuecomment-2341196975