RFR: 8354228: Parallel: Set correct minimum of InitialSurvivorRatio [v2]

Albert Mingkun Yang ayang at openjdk.org
Wed Apr 23 10:00:55 UTC 2025


On Wed, 23 Apr 2025 04:32:20 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>>> If both InitialSurvivorRatio and MinSurvivorRatio are not set in command line and the condition InitialSurvivorRatio < MinSurvivorRatio is true
>> 
>> When will that happen? AFAIS, if neither is set on command line, the default values should be MinSurvivorRatio == 3 and InitialSurvivorRatio == 8 (as defined in gc_globals.hpp), so `MinSurvivorRatio <= InitialSurvivorRatio` should hold.
>> 
>>> Should we guard this situation (such as printing an error message) to catch the bug in the previous code?
>> 
>> I didn't really understand your suggestion. Could you clarify what you mean by "previous code"? Or maybe some pseudo code to outline your suggestion?
>
> Please read the following code. It can help us catch the bug about the wrong default/ergonomic values.
> 
> ```C++
>   if (InitialSurvivorRatio < MinSurvivorRatio) {
>     if (FLAG_IS_CMDLINE(InitialSurvivorRatio)) {
>       if (FLAG_IS_CMDLINE(MinSurvivorRatio)) {
>         jio_fprintf(defaultStream::error_stream(),
>           "Inconsistent MinSurvivorRatio vs InitialSurvivorRatio: %d vs %d\n", MinSurvivorRatio, InitialSurvivorRatio);
>       }
>       FLAG_SET_DEFAULT(MinSurvivorRatio, InitialSurvivorRatio);
>     } else if (FLAG_IS_CMDLINE(MinSurvivorRatio)) {
>       FLAG_SET_DEFAULT(InitialSurvivorRatio, MinSurvivorRatio);
>     } else {
>       // Here <----------
>       jio_fprintf(defaultStream::error_stream(),
>           "Inconsistent default/ergonomic MinSurvivorRatio vs InitialSurvivorRatio: %d vs %d\n", MinSurvivorRatio, InitialSurvivorRatio);
>     }
> }
> 
> 
>> When will that happen? AFAIS, if neither is set on command line, the default values should be MinSurvivorRatio == 3 and InitialSurvivorRatio == 8 (as defined in gc_globals.hpp), so MinSurvivorRatio <= InitialSurvivorRatio should hold.
> 
> Yes, the current default values are good, but we may change them in the future. So such guard operation seems good and helps us find the bug earlier.  May I be overthinking?

Thank you for the clarification -- the suggestion is about protecting ourselves from invalid default values in future changes. However, I feel such risk is extremely low, because those default values are completely under VM dev's control and do not change often (or even at all).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24556#discussion_r2055700506


More information about the hotspot-gc-dev mailing list