Based on a conversation between Holly and @dmlloyd. When doing a test run in a module that contains several test profiles or test resources, a new Quarkus application is created for each test configuration. Each application comes with four classloaders. As we saw when @WithTestResource changed the default isolation, the memory requirements of these classloaders can add up quickly. #42852 reduced the number of applications in a typical configuration by giving more useful defaults, but doesn't improve the underlying efficiency. #34681 makes the impact of the resource duplication worse, by frontloading the creation of ALL the classloaders to the test discovery stage.

It should be possible to share more resources between different Quarkus applications in the same JVM. It's non-trivial, since we need to make sure that transformed classes, and anything else that would be affected by the Quarkus profile/resources doesn't leak between invocations. But for most application configurations, a lot of the classpath and classpath resources would be common.

This should not be started before #34681 , not because there's a cast iron technical prerequisite, but just to avoid merge suffering. (Well, and #34681 makes this more necessary.)

This is also related to @gsmet's #42560, which aims to improve sharing by moving some hungry and/or leaky classes to be loaded parent-first, which guarantees re-use across a JVM.