It looks like names of GC threads may be accessed before they were set. For example, see http://hg.openjdk.java.net/jdk9/dev/hotspot/file/bdb0acafc63c/src/share/vm/gc/g1/concurrentG1RefineThread.cpp#l61

...
  create_and_start();

  // set name
  set_name("G1 Refine#%d", worker_id);
...

It seems that a race starts after a new thread is created in create_and_start():

set_name() method allocates memory for "_name" field which is accessed in set_native_thread_name() method by the new thread:

  ConcurrentG1RefineThread::run()
    ConcurrentGCThread::initialize_in_thread()
      NamedThread::initialize_named_thread()
        Thread::set_native_thread_name(char const*)
          os::set_native_thread_name(char const*)

initialize_named_thread() uses NamedThread::name() which returns _name only if it is not null:

http://hg.openjdk.java.net/jdk9/dev/hotspot/file/bdb0acafc63c/src/share/vm/runtime/thread.cpp#l1175

...
void NamedThread::initialize_named_thread() {
  set_native_thread_name(name());
}
...

http://hg.openjdk.java.net/jdk9/dev/hotspot/file/bdb0acafc63c/src/share/vm/runtime/thread.hpp#l701

...
virtual char* name() const { return _name == NULL ? (char*)"Unknown Thread" : _name; }
...

The similar problem seems to exist in hotspot/src/share/vm/gc/g1/g1YoungRemSetSamplingThread.cpp

It doesn't seem that null-dereference is possible. It doesn't look like a serious issue, but it might be better to allocate a buffer before staring a thread that may use it.