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