8360869: jcstress is able to crash jdk8 on aarch64 with jfr on

[judovana]

We are seeing rare crashes in jcstress with jdk8 on aarch64 with jfron. Those crashes are real, however we were not able to reproduce with builds on gcc 5 and up. The real culprint was not found. but gcc version on aarch64 should be checked. Ideal version seems 7, but I'm not that bold.

I think this change must be accompanied by regenerating generated-configure but am not sure with process on it.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8360869 needs maintainer approval

Issue

• JDK-8360869: jcstress is able to crash jdk8 on aarch64 with jfr on (Bug - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/697/head:pull/697
$ git checkout pull/697

Update a local copy of the PR:
$ git checkout pull/697
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/697/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 697

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/697.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back jvanek! 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]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[mlbridge]

Webrevs

• 04: Full - Incremental (78ee959b)
• 03: Full - Incremental (e06588df)
• 02: Full - Incremental (f4c31107)
• 01: Full - Incremental (dc7efed9)
• 00: Full (1a23a459)

[gnu-andrew]

I would move the AC_MSG_RESULT earlier i.e.

      AC_MSG_RESULT([found ($COMPILER_VERSION_NUMBER])
      if test $COMPILER_VERSION_NUMBER_MAJOR -lt 5; then
        AC_MSG_ERROR([GCC < 5 is known to lead to incorrect compilation on aarch64. See JDK-8360869.])
      fi

And yes, configure needs to be regenerated at present.

I've removed the approval request. This should only be done after successful review and with a comment as to why it is suitable for inclusion. Easier way is with the /approval request command.

[judovana]

I would move the AC_MSG_RESULT earlier i.e.

      AC_MSG_RESULT([found ($COMPILER_VERSION_NUMBER])
      if test $COMPILER_VERSION_NUMBER_MAJOR -lt 5; then
        AC_MSG_ERROR([GCC < 5 is known to lead to incorrect compilation on aarch64. See JDK-8360869.])
      fi

Sure, sounds good. Done.

And yes, configure needs to be regenerated at present.

Any recommended version of autoconf to use? When I use 2.72, the diff is 90% of the file.

I've removed the approval request. This should only be done after successful review and with a comment as to why it is suitable for inclusion. Easier way is with the /approval request command.

Sure thing. Whether to do it or so, is if course on you and @theRealAph . I will do my best on how to do that. Thanx!

[mlbridge]

Mailing list message from Andrew Haley on jdk8u-dev:

On 17/09/2025 08:08, Ji?? Van?k wrote:

     AC\_MSG\_ERROR\(\[GCC \< 5 is known to lead to incorrect compilation on aarch64\. See JDK\-8360869\.\]\)

"Known" is a bit too strong. "GCC < 5 may incorrectly compile HotSpot"
is better.

--
Andrew Haley (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

[judovana]

"Known" is a bit too strong. "GCC < 5 may incorrectly compile HotSpot"

sure. TY!

[gnu-andrew]

I would move the AC_MSG_RESULT earlier i.e.

      AC_MSG_RESULT([found ($COMPILER_VERSION_NUMBER])
      if test $COMPILER_VERSION_NUMBER_MAJOR -lt 5; then
        AC_MSG_ERROR([GCC < 5 is known to lead to incorrect compilation on aarch64. See JDK-8360869.])
      fi

Sure, sounds good. Done.

Thanks. This looks good with aph's amendments as well.

It should mean the checking line is always completed with the version number and the error is on its own line.

And yes, configure needs to be regenerated at present.

Any recommended version of autoconf to use? When I use 2.72, the diff is 90% of the file.

I'll look at what I used. You may need to dust off an older version (2.72 sounds very new, not sure I've seen that one yet)

It can produce differing results even with the same version from different distro packages, so I would like to drop it as we have on later JDKs. If you would rather wait on that backport, that's an alternative option. I would like to finally get that into the January update.

I've removed the approval request. This should only be done after successful review and with a comment as to why it is suitable for inclusion. Easier way is with the /approval request command.

Sure thing. Whether to do it or so, is if course on you and @theRealAph . I will do my best on how to do that. Thanx!

This is just the general process across all update releases. If there are PRs in the approval queue that still need a review, it clogs it up and can mean that ones that are ready to go are missed. In theory, there are a lot more reviewers than maintainers :)

[judovana]

Thanx! Regenerated with self built 2.69. Output was sane this time, only I manually skipped about 50 hunks like this:

@@ -50158,7 +50167,7 @@ ac_compiler_gnu=$ac_cv_cxx_compiler_gnu
 /* end confdefs.h.  */
 
 int
-main (void)
+main ()
 {
 return 0;
   ;

I guess thats done by too new gcc

[openjdk]

@judovana Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.