8296270: Memory leak in ClassLoader::setup_bootstrap_search_path_impl

[caoman]

Hi all,

Could anyone help review this fix for a memory leak? There is a redundant code branch in ClassLoader::setup_bootstrap_search_path_impl() for exploded-image build that is unnecessary and causes a leak.

I'm sponsoring colleague Justin King (jcking@google.com) for this contribution, who remarkably made LeakSanitizer working for HotSpot and found this leak.

@jianglizhou also helped validate this fix. Quoting her comment:

For the ClassPathEntry* new_entry = create_class_path_entry(current, path, &st, false, false); else case with an exploded build in jdk head codebase, it does appear to be not needed. It only creates the class path entry for /modules/java.base, which is handled by ClassLoader::add_to_exploded_build_list later again. Just to be sure, I checked in lldb. The /modules/java.base module path entry is created twice.

-Man

---

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

Issue

• JDK-8296270: Memory leak in ClassLoader::setup_bootstrap_search_path_impl

Reviewers

• David Holmes (@dholmes-ora - Reviewer)
• Jiangli Zhou (@jianglizhou - Reviewer)

Contributors

• Justin King <jcking@google.com>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10973/head:pull/10973
$ git checkout pull/10973

Update a local copy of the PR:
$ git checkout pull/10973
$ git pull https://git.openjdk.org/jdk pull/10973/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10973

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10973.diff

[bridgekeeper]

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

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

• hotspot-runtime

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.

[caoman]

/contributor add Justin King jcking@google.com

[openjdk]

@caoman
Contributor Justin King <jcking@google.com> successfully added.

[mlbridge]

Webrevs

• 00: Full (655b32ea)

[jianglizhou]

Could you please include testing information?

[dholmes-ora]

So we have:

} else {
    // It's an exploded build.
    ClassPathEntry* new_entry = create_class_path_entry(current, path, &st, false, false);
}

and AFAICS create_class_path_entry has no side-effects i.e. it doesn't update any global class-path data structure, so this code should be obviously redundant as new_entry is created but not used? Did I miss something?

[caoman]

Yes, I reached the same conclusion that create_class_path_entry has so side effect. Jiangli mainly tries to be extra careful.

I finished running fastdebug tier2 on x64 Linux locally, with both this change and JDK-8296347, and found no new failure. Waiting for tier3 now. The presubmit tier1 test failure is due to JDK-8295867.

[dholmes-ora]

Is any of that testing you are doing actually using the exploded image though?

[caoman]

Ah, thanks for reminding. I just used make test, and I'll retry using make exploded-test.

testing.md says "Not all tests will run successfully on the exploded image, but using this target can greatly improve rebuild times for certain workflows." Does OpenJDK's continuous testing framework monitor the results from make exploded-test?

[dholmes-ora]

Does OpenJDK's continuous testing framework monitor the results from make exploded-test?

I have no idea whether GHA testing or Oracle CI testing, test an exploded -image.

[caoman]

Results from make exploded-test for tier1 and tier2:

Without any change:

   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:tier1                     2201  2146    55     0 <<
>> jtreg:test/jdk:tier1                               2205  2178    27     0 <<
>> jtreg:test/langtools:tier1                         4351  4346     5     0 <<
   jtreg:test/jaxp:tier1                                 0     0     0     0   
   jtreg:test/lib-test:tier1                             0     0     0     0   
>> jtreg:test/hotspot/jtreg:tier2                      741   494   247     0 <<
>> jtreg:test/jdk:tier2                               3986  3806   178     2 <<
   jtreg:test/langtools:tier2                           11    11     0     0   
>> jtreg:test/jaxp:tier2                               470   379    91     0 <<

With this change and JDK-8296347

   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:tier1                     2197  2144    53     0 <<
>> jtreg:test/jdk:tier1                               2205  2178    27     0 <<
>> jtreg:test/langtools:tier1                         4351  4346     5     0 <<
   jtreg:test/jaxp:tier1                                 0     0     0     0   
   jtreg:test/lib-test:tier1                             0     0     0     0   
>> jtreg:test/hotspot/jtreg:tier2                      742   494   248     0 <<
>> jtreg:test/jdk:tier2                               3986  3806   178     2 <<
   jtreg:test/langtools:tier2                           11    11     0     0   
>> jtreg:test/jaxp:tier2                               470   379    91     0 <<

Some tests are apparently flaky.
I compared the diff of summary.txt, and did not find any new failures.

There seems some problem with counting the total tests. summary.txt for hotspot/tier1 shows 2201 lines in both runs, but second run only counts 2197 total tests. Similarly summary.txt for hotspot/tier2 shows 742 lines in both runs.

Overall, I think this is good to go. The presubmit test failures also seem unrelated.

[dholmes-ora]

Seems fine. Thanks for the attempted exploded-image testing. Apparently we use the exploded-image during the build process so that also tests it.

Thanks.

[openjdk]

@caoman 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:

8296270: Memory leak in ClassLoader::setup_bootstrap_search_path_impl

Co-authored-by: Justin King <jcking@google.com>
Reviewed-by: dholmes, jiangli

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 21 new commits pushed to the master branch:

• c2f7638: 8296335: Fix accessibility manual test instruction
• 91292d5: 8286301: Port JEP 425 to RISC-V
• 581133a: 8294696: BufferedInputStream.transferTo should drain buffer when mark set
• d8573b2: 8294488: Delete KCMS transforms wrappers
• f857f79: 8015739: Background of JInternalFrame is located out of JInternalFrame
• b847fb6: 8296414: [BACKOUT] JDK-8295319: pending_cards_at_gc_start doesn't include cards in thread buffers
• 5b7e706: 8295753: (fs) UnixPath::toRealPath does not return correct case when links not followed
• 82f9819: 8294536: Update troff form of man page for new --spec-base-url option
• b49bdae: 8294816: C2: Math.min/max vectorization miscompilation
• c206f28: 8283101: serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java failing #VirtualThread-Frozen: number of frames expected: 14, got: 9
• ... and 11 more: https://git.openjdk.org/jdk/compare/034980393fc3e40b8a75b6aa19c68b3b58c9dd90...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.

[jianglizhou]

There seems some problem with counting the total tests. summary.txt for hotspot/tier1 shows 2201 lines in both runs, but second run only counts 2197 total tests. Similarly summary.txt for hotspot/tier2 shows 742 lines in both runs.

Was the second run sharing the work/result directory from the first run, or it's a fresh run?

Overall, I think this is good to go. The presubmit test failures also seem unrelated.

Yes, it seems to be safe.

[caoman]

Was the second run sharing the work/result directory from the first run, or it's a fresh run?

It was a fresh run from a different parent directory for running make.

[caoman]

/integrate

[openjdk]

Going to push as commit 556377a.
Since your change was applied there have been 21 commits pushed to the master branch:

• c2f7638: 8296335: Fix accessibility manual test instruction
• 91292d5: 8286301: Port JEP 425 to RISC-V
• 581133a: 8294696: BufferedInputStream.transferTo should drain buffer when mark set
• d8573b2: 8294488: Delete KCMS transforms wrappers
• f857f79: 8015739: Background of JInternalFrame is located out of JInternalFrame
• b847fb6: 8296414: [BACKOUT] JDK-8295319: pending_cards_at_gc_start doesn't include cards in thread buffers
• 5b7e706: 8295753: (fs) UnixPath::toRealPath does not return correct case when links not followed
• 82f9819: 8294536: Update troff form of man page for new --spec-base-url option
• b49bdae: 8294816: C2: Math.min/max vectorization miscompilation
• c206f28: 8283101: serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java failing #VirtualThread-Frozen: number of frames expected: 14, got: 9
• ... and 11 more: https://git.openjdk.org/jdk/compare/034980393fc3e40b8a75b6aa19c68b3b58c9dd90...master

Your commit was automatically rebased without conflicts.

[openjdk]

@caoman Pushed as commit 556377a.

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