On Mon, 4 Jan 2021 18:59:09 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> src/hotspot/share/classfile/classLoader.cpp line 843:
>>
>>> 841: assert(first_append_entry() == NULL, "boot loader's append
>>> class path entry list not empty");
>>> 842: Atomic::store(&_first_append_entry_list, new_entry);
>>> 843: return;
>>
>> Not sure if it is a problem. There is a chance that an entry is added, e.g.
>> _last_append_entry = new_entry, but _first_append_entry_list == NULL. If
>> contains_append_entry() queries on this new entry, it may return false.
>
> That race also exists in the current code, since contains_append_entry()
> never acquired the same lock. Even if it did lock, there's a race when one
> thread adds an entry and the other reads the list.
void InstanceKlass::log_to_classlist(const ClassFileStream* stream) const {
if (ClassListWriter::is_enabled()) {
...
if (class_loader == NULL &&
ClassLoader::contains_append_entry(stream->source())) {
// .. but don't skip the boot classes that are loaded from
-Xbootclasspath/a
// as they can be loaded from the archive during runtime.
in logging loaded classes from the NULL class loader, this is where
contains_append_entry() races with a JVMTI thread concurrently adding a class
path entry, but this is benign because it's logging a class that's already
loaded, so it couldn't have loaded it from the partially added classpath.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1935
