If a class is first accessed via a Runnable and multiple instances of the Runnable execute concurrently, it appears that the class can be loaded into memory multiple times. Multiple entries for the class, with the same classloader, appear in jcmd <pid> GC.class_stats output for the JVM.

I'm going to attach 2 files showing jcmd <pid> GC.class_stats output, pboc-problem.txt and pboc-fixed.txt. These are produced from analyzing a freshly booted WildFly instance running standalone-full.xml. In pboc-problem.txt you will find multiple entries for ParallelBootOperationContext and ParallelBootOperationContext$1. These files don't show the classloader information for the entries, but similar output prepared by James Perkins at https://docs.google.com/spreadsheets/d/151TW-rm2Vyqizsg6-jwDnSQ7DbtlETTIBq0PnaDJt60/edit#gid=329628539 shows that all the entries have the same classloader.

The pboc-fixed.txt does not show this problem. This is because it was run with a snapshot of WildFly Core with https://github.com/wildfly/wildfly-core/pull/2694 applied. That commit does 2 things:

1) During WildFly boot, numerous instance of the ParallelBootTask Runnable are instantiated and executed in rapid succession. The commit moves the initial use of the ParallelBootOperationContext class outside of that ParallelBootTask Runnable, thus ensuring the class is loaded before any ParallelBootTask executes.

That was enough to eliminate duplicate entries for ParallelBootOperationContext, but multiple entries for ParallelBootOperationContext$1 were still found, so apparently something was still initially being loaded concurrently. Fixing that required...

2) Removing a switch block from a method ParallelBootOperationContext, converting it to if/elseif/else. That removed the ParallelBootOperationContext$1 class altogether.