RFR: 8311248: Refactor CodeCache::initialize_heaps to simplify adding new CodeCache segments [v7]

[Boris Ulasevich]

On Tue, 20 Feb 2024 23:06:16 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Let us assume that with the previous calculations we have this layout:
>> - {cache_size=18004KB, non_profiled.size = 6002KB, profiled.size = 6002KB, non_nmethod.size=6000KB}
>> 
>> With next align_down for profiled and non_profiled segments, we get:
>> - {cache_size=18004KB, non_profiled.size = 6000KB, profiled.size = 6000KB, non_nmethod.size=6000KB}
>> 
>> My intention here is to put 4KB into the non_nmethod segment to make the sum of the segment sizes equal to cache_size:
>> - {cache_size=18004KB, non_profiled.size = 6000KB, profiled.size = 6000KB, non_nmethod.size=6004KB}
>
> Why has `non_nmethod` been chosen? I have not seen it running out of space. It usually has a lot of free space. Also in case of large pages, e.g. 2M, it can get even more space than needed.
> I'd rather give additional space to `profiled` or `non_profiled`. As `profiled` is optional, to simplify the code we can have:
> 
>   non_nmethod.size = align_up(non_nmethod.size, min_size);
>   profiled.size = align_down(profiled.size, min_size);
>   profiled.size = align_down(cache_size - profiled.size - non_nmethod.size, min_size);
> 
> 
> For you example, we will have:
> 
> {cache_size=18004KB, non_profiled.size = 6004KB, profiled.size = 6000KB, non_nmethod.size=6000KB}

My reasons are: the logic was before the change and we know non_nmethod segment always exist. Although, ok, let it be non_profiled segment to get an extra load.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17244#discussion_r1516000632