JDK-8284632 : runtime/Thread/StopAtExit.java possibly leaking memory again
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 19
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2022-04-10
  • Updated: 2022-05-06
  • Resolved: 2022-05-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 19
19 b21Fixed
Related Reports
Relates :  
JDK-8282704 - runtime/Thread/StopAtExit.java may leak memory
Relates :  
JDK-8286333 - "queue must be flushed before delete" after JDK-8284632
Relates :  
JDK-8283610 - runtime/Thread/StopAtExit.java failing in loom repo
Relates :  
JDK-8286088 - add comment to InstallAsyncExceptionHandshake destructor
Relates :  
JDK-8283651 - nsk/jvmti/SuspendThread/suspendthrd003 may leak native memory
Relates :  
JDK-8283044 - Use asynchronous handshakes to deliver asynchronous exceptions
Description
In my stress testing of jdk-19+17, it appears that
StressWrapper_StopAtExit is possibly leaking memory again.

I have sightings on my linux-x64 and macosx-aarch64 machine
during all three runs of jdk-19+17 stress testing on each machine.
Comments
Changeset: 4a79270c Author: Daniel D. Daugherty <dcubed@openjdk.org> Date: 2022-05-02 15:23:03 +0000 URL: https://git.openjdk.java.net/jdk/commit/4a79270c0195e79cfc59f774c1ac58c56321ea8a
02-05-2022
I replaced my fix with the one that [~rehn] proposed in the PR, merged it with my counter based debug code and tested it with StressWrapper_StopAtExit.java and the latest StopAtExit.java version: $ grep dcubed_ build/macosx-x86_64-normal-server-release/test-support/jtreg_open_test_hotspot_jtreg_StressWrapper_StopAtExit_java/StressWrapper_StopAtExit.jtr vm_exit: dcubed_async_global_alloc_cnt=34998851 vm_exit: dcubed_async_global_release_cnt=34998851 $ grep dcubed_ build/macosx-x86_64-normal-server-fastdebug/test-support/jtreg_open_test_hotspot_jtreg_StressWrapper_StopAtExit_java/StressWrapper_StopAtExit.jtr vm_exit: dcubed_async_global_alloc_cnt=70362610 vm_exit: dcubed_async_global_release_cnt=70362610 $ grep dcubed_ build/macosx-x86_64-normal-server-slowdebug/test-support/jtreg_open_test_hotspot_jtreg_StressWrapper_StopAtExit_java/StressWrapper_StopAtExit.jtr vm_exit: dcubed_async_global_alloc_cnt=20947308 vm_exit: dcubed_async_global_release_cnt=20947308 The StressWrapper_StopAtExit is configured to run StopAtExit for 101 minutes and these test results are great. No signs of leakage.
29-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/8388 Date: 2022-04-25 22:12:38 +0000
27-04-2022
Here's the sightings for jdk-19+17 on linux-x64: $ unzip -l jdk-19+17_linux.8284632.zip Archive: jdk-19+17_linux.8284632.zip Length Date Time Name --------- ---------- ----- ---- 84438 04-08-2022 06:14 jdk-19+17_1/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.fastdebug 108585 04-08-2022 06:05 jdk-19+17_1/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.release 114342 04-09-2022 05:19 jdk-19+17_2/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.release 100097 04-09-2022 07:10 jdk-19+17_2/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.slowdebug 85850 04-10-2022 04:35 jdk-19+17_3/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.fastdebug 92432 04-10-2022 06:19 jdk-19+17_3/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.slowdebug --------- ------- 585744 6 files
18-04-2022
Still learning how to poke around with VisualVM... I've attached a picture that shows that 99% of the heap space is retained by java.lang.ThreadDeath objects. Now I have something to hunt...
18-04-2022
Here's the sightings for jdk-19+18 on linux-x64: $ unzip -l jdk-19+18_linux.8284632.zip Archive: jdk-19+18_linux.8284632.zip Length Date Time Name --------- ---------- ----- ---- 88175 2022-04-15 04:49 jdk-19+18_1/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.fastdebug 86264 2022-04-15 04:41 jdk-19+18_1/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.release 82523 2022-04-15 06:21 jdk-19+18_1/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.slowdebug 82602 2022-04-16 03:46 jdk-19+18_2/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.fastdebug 85557 2022-04-16 03:38 jdk-19+18_2/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.release 85149 2022-04-16 05:19 jdk-19+18_2/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.slowdebug 100512 2022-04-17 04:20 jdk-19+18_3/failures.linux-x86_64/StressWrapper_StopAtExit.jtr.slowdebug --------- ------- 610782 7 files
17-04-2022
Here's the sightings for jdk-19+18 on macosx-aarch64: $ unzip -l jdk-19+18_macosx-aarch64.8284632.zip Archive: jdk-19+18_macosx-aarch64.8284632.zip Length Date Time Name --------- ---------- ----- ---- 91083 04-15-2022 04:18 jdk-19+18_1/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.fastdebug 84735 04-15-2022 04:16 jdk-19+18_1/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.release 115724 04-15-2022 05:09 jdk-19+18_1/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.slowdebug 115919 04-16-2022 02:02 jdk-19+18_2/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.fastdebug 101077 04-16-2022 02:53 jdk-19+18_2/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.slowdebug 100784 04-16-2022 23:45 jdk-19+18_3/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.release 102567 04-17-2022 00:36 jdk-19+18_3/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.slowdebug --------- ------- 711889 7 files
17-04-2022
The memory leak reproduces on my MBP13 with jdk-19+17 bits. I verified that the memory leak does not reproduce on my MBP13 with jdk-19+16 bits. I bisected all the build-IDs between jdk-19+16 and jdk-19+17 and figured out that the memory leak does not occur with jdk-19+17-1106, but it does reproduce with jdk-19+17-1107. There is only one changeset in 19+17-1107: JDK-8283044 Use asynchronous handshakes to deliver asynchronous exceptions So now I need to figure out the why...
17-04-2022
Here's the sightings for jdk-19+17 on macosx-aarch64: $ unzip -l jdk-19+17_macosx-aarch64.8284632.zip Archive: jdk-19+17_macosx-aarch64.8284632.zip Length Date Time Name --------- ---------- ----- ---- 108651 04-08-2022 05:43 jdk-19+17_1/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.fastdebug 108662 04-08-2022 05:42 jdk-19+17_1/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.release 111179 04-08-2022 06:31 jdk-19+17_1/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.slowdebug 112900 04-09-2022 03:24 jdk-19+17_2/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.fastdebug 102813 04-09-2022 03:22 jdk-19+17_2/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.release 111583 04-09-2022 04:16 jdk-19+17_2/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.slowdebug 90973 04-10-2022 01:10 jdk-19+17_3/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.fastdebug 108957 04-10-2022 01:43 jdk-19+17_3/failures.macosx-aarch64/StressWrapper_StopAtExit.jtr.slowdebug --------- ------- 855718 8 files
10-04-2022