8277854: The upper bound of GCCardSizeInBytes should be limited to 512 for 32-bit platforms

[DamonFool]

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

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8277854: The upper bound of GCCardSizeInBytes should be limited to 512 for 32-bit platforms

Reviewers

• Thomas Schatzl (@tschatzl - Reviewer)
• Hamlin Li (@Hamlin-Li - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6569/head:pull/6569
$ git checkout pull/6569

Update a local copy of the PR:
$ git checkout pull/6569
$ git pull https://git.openjdk.java.net/jdk pull/6569/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6569

View PR using the GUI difftool:
$ git pr show -t 6569

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6569.diff

[bridgekeeper]

👋 Welcome back jiefu! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@DamonFool The following label will be automatically applied to this pull request:

• hotspot-gc

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (15ec0a3a)

[Hamlin-Li]

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?
• Does a CSR needed?
• A regression test would be helpful.

[DamonFool]

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

[tschatzl]

Thanks for spotting this - that slipped past our testing (we do not do much 32 bit testing).

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.

I will talk to the CSR team whether there needs to be an amendment to the CSR for 32 bit platforms. please do not integrate before this has been handled.

[tschatzl]

I think this is good, but I had to amend the CSR (https://bugs.openjdk.java.net/browse/JDK-8275142) for it for this case. As soon as it has been approved again sometime next week, this change can be integrated.
Also fixed the release note.

[openjdk]

@DamonFool This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8277854: The upper bound of GCCardSizeInBytes should be limited to 512 for 32-bit platforms

Reviewed-by: tschatzl, mli

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 27 new commits pushed to the master branch:

• 825e633: 8277944: JDK 18 - update GA Release Date
• 3d39f09: 8277654: Shenandoah: Don't produce new memory state in C2 LRB runtime call
• 05ab176: 8277797: Remove undefined/unused SharedRuntime::trampoline_size()
• ad51d06: 8277789: G1: G1CardSetConfiguration prefixes num_ and max_ used interchangeably
• 614c6e6: 8277878: Fix compiler tests after JDK-8275908
• 960bdde: 8277904: G1: Remove G1CardSetArray::max_entries
• 45e8973: 8277896: Remove unused BOTConstants member methods
• e5676f8: 8277450: Record number of references into collection set during gc
• 2622ab3: 8277928: Fix compilation on macosx-aarch64 after 8276108
• 37de442: 8275241: Unused ArrayList is created in RequestEngine.addHooks
• ... and 17 more: https://git.openjdk.java.net/jdk/compare/7e54d065a17f1277adf1b8561fadb8a480bc6bed...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[DamonFool]

I think this is good, but I had to amend the CSR (https://bugs.openjdk.java.net/browse/JDK-8275142) for it for this case. As soon as it has been approved again sometime next week, this change can be integrated. Also fixed the release note.

Sure.
Thanks @tschatzl for your review.

[Hamlin-Li]

• 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.

I'm fine with it.

• 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.

Please follow Thomas's suggestion.

• A regression test would be helpful.

There is already a jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java for this regression.

I was wondering why it's not caught by regionion test until I saw Thomas' response.

Thanks for clarifying and fixing this.

[DamonFool]

Thanks @Hamlin-Li for your review.

[tschatzl]

/csr needed

We need a new CSR for this change after all (see https://bugs.openjdk.java.net/browse/JDK-8277891).

[openjdk]

@tschatzl this pull request will not be integrated until the CSR request JDK-8277891 for issue JDK-8277854 has been approved.

[DamonFool]

@tschatzl this pull request will not be integrated until the CSR request JDK-8277891 for issue JDK-8277854 has been approved.

The CSR had been approved.
So integrate it.
Thanks.

/integrate

[openjdk]

Going to push as commit 3a4a94e.
Since your change was applied there have been 27 commits pushed to the master branch:

• 825e633: 8277944: JDK 18 - update GA Release Date
• 3d39f09: 8277654: Shenandoah: Don't produce new memory state in C2 LRB runtime call
• 05ab176: 8277797: Remove undefined/unused SharedRuntime::trampoline_size()
• ad51d06: 8277789: G1: G1CardSetConfiguration prefixes num_ and max_ used interchangeably
• 614c6e6: 8277878: Fix compiler tests after JDK-8275908
• 960bdde: 8277904: G1: Remove G1CardSetArray::max_entries
• 45e8973: 8277896: Remove unused BOTConstants member methods
• e5676f8: 8277450: Record number of references into collection set during gc
• 2622ab3: 8277928: Fix compilation on macosx-aarch64 after 8276108
• 37de442: 8275241: Unused ArrayList is created in RequestEngine.addHooks
• ... and 17 more: https://git.openjdk.java.net/jdk/compare/7e54d065a17f1277adf1b8561fadb8a480bc6bed...master

Your commit was automatically rebased without conflicts.

[openjdk]

@DamonFool Pushed as commit 3a4a94e.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.