During the initialization of the classloader, we preload some jar files, that are necessary for the compiler to work correctly. In this process of preloading classes, we unpack each jar file and look at the value of the Class-Path in its META_INF. So we will determine, which files are depends on by original jars. We will load the resulting jars in the next iteration of class preloading. Thus, we get nested classloaders. However, in practice, it turned out that the jar files needed for the second iteration were already loaded in the first iteration, so there is no point in loading them again. Moreover, if we do not find the class in the first loader, then we will not find it in the second either. However, the case, when there are some jars from Class-Path of original jars and they were not loaded by first iteration, does not change.
Aldo needed for KT-49786
Use reasonable defaults for the options: no time profiling, no instrumenters,
empty classpath, 4096 as the class number estimate. Replace 4096 in the
codebase with the constant field.
Keep the old interface intact until the build is bootstrapped and the new one
can be used in all compilation steps
40 Mb of bytes of preloaded compiler classes during the compilation become 16
Mb after this change
This is a slightly reworked version of 58b033d (reverted in 3f05419). The
problem in that commit was that URLClassLoader did not work in the fashion
MemoryBasedClassLoader was designed to work (child first, parent last). So some
resource was found in an incorrect jar which was causing the compiler to break
Aleksei.Cherepanov