RFR: 8259067: bootclasspath append takes out object lock

[Coleen Phillimore]

On Mon, 4 Jan 2021 18:59:09 GMT, Coleen Phillimore <coleenp at 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