RFR: 8339573: Update CodeCacheSegmentSize and CodeEntryAlignment for ARM

[Lutz Schmidt]

On Mon, 9 Sep 2024 19:11:44 GMT, Vladimir Kozlov <kvn 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.

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

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