RFR: 8296270: Memory leak in ClassLoader::setup_bootstrap_search_path_impl

David Holmes dholmes at openjdk.org
Fri Nov 4 02:53:26 UTC 2022


On Fri, 4 Nov 2022 01:20:41 GMT, Man Cao <manc at openjdk.org> wrote:

> 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 at 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 <path>/modules/java.base, which is handled by [ClassLoader::add_to_exploded_build_list](http://google3/third_party/java_src/jdk/head/src/src/hotspot/share/classfile/classLoader.cpp;l=671;rcl=478881875) later again. Just to be sure, I checked in lldb. The <path>/modules/java.base module path entry is created twice.
> 
> -Man

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?

-------------

PR: https://git.openjdk.org/jdk/pull/10973


More information about the hotspot-runtime-dev mailing list