RFR: 8277854: The upper bound of GCCardSizeInBytes should be limited to 512 for 32-bit platforms
Jie Fu
jiefu at openjdk.java.net
Fri Nov 26 08:36:04 UTC 2021
On Fri, 26 Nov 2021 06:29:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:
> Hi all,
>
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crashes on linux/x86_32 with `-XX:GCCardSizeInBytes=1024`.
>
> This is because if`-XX:GCCardSizeInBytes=1024` then `BOTConstants::N_words` [1] would be 256.
> Then the guarantee [2] always fails due to _bot->offset_array(start_card), which is a u_char value, never equals to 256.
>
> So for 32-bit platforms, the upper bound of `GCCardSizeInBytes` should be limited to 512.
>
> Thanks.
> Best regards,
> Jie
>
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/blockOffsetTable.cpp#L45
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp#L186
Good questions!
Thanks @Hamlin-Li for your review.
> Several initial comments:
>
> * Not sure if the lower bound should also be distinguished between 32 and 64. It's not because of crash, but as you're touching it, should we consider this?
Not sure if there is any benefit to distinguish the lower bounds between 32-bit and 64-bit platforms.
But this pr aims at fixing the crash caused by the incorrect upper bound on 32-bit platforms.
So a separate pr seems better if the lower bound needs to be re-considered.
> * Does a CSR needed?
Maybe not since no VM flags are added or removed and jdk18 hasn't been released yet.
But I'm not sure.
> * A regression test would be helpful.
There is already a jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java for this regression.
Thanks.
Best regards,
Jie
-------------
PR: https://git.openjdk.java.net/jdk/pull/6569
More information about the hotspot-gc-dev
mailing list