Most class loader implementations aren't parallel-capable

dmlloyd commented 7 months ago

Describe the bug

The following seven production implementations of ClassLoader within Quarkus do not call registerAsParallelCapable during their static initializer:

io.quarkus.bootstrap.runner.RunnerClassLoader
io.quarkus.deployment.dev.filesystem.ReloadableFileManager$JoinClassLoader
The class loader produced by io.quarkus.smallrye.openapi.runtime.OpenApiRecorder#classLoaderHack()
The class loader produced by io.quarkus.mutiny.reactive.operators.runtime.ReactiveStreamsOperatorsRecorder#classLoaderHack()
The class loader produced by io.quarkus.smallrye.reactivestreamsoperators.runtime.ReactiveStreamsOperatorsRecorder#classLoaderHack()
The class loader produced by io.quarkus.undertow.runtime.UndertowDeploymentRecorder#createDeployment()
The class loader produced by io.quarkus.launcher.JBangIntegration#postBuild()

There are also class loaders used for testing which should be registered (it may have somewhat of an impact on performance):

io.quarkus.test.common.DefineClassVisibleClassLoader
io.quarkus.test.component.QuarkusComponentTestClassLoader
io.quarkus.arc.test.ArcTestClassLoader

Every class loader should call registerAsParallelCapable in their static initializer without exception.

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of `uname -a` or `ver`

No response

Output of `java -version`

No response

Quarkus version or git rev

No response

Build tool (ie. output of `mvnw --version` or `gradlew --version`)

No response

Additional information

No response

quarkus-bot[bot] commented 7 months ago

/cc @maxandersen (jbang), @quarkusio/devtools (jbang)

geoand commented 7 months ago

I remember we took this call out because @Sanne found that using it resulted in higher memory usage IIRC

geoand commented 7 months ago

There is a complete discussion about this here.

quarkusio / quarkus