We do it because sometimes we want to treat a regular class as
an inline class. For example, in the Wasm backend we treat classes
with the `@WasmAutoboxed` annotation as inline classes. Also, in
the JS IR backend the `Char` class is declared as a regular class for
compatibility reasons, but we want it to be an inline class for
performance.
When new mark phase finished before previous finalization is done,
extra objects are still in list, which would be passed to finalize.
This could lead to unpredictable effects.
After this commit such objects are marked by new flag and ignored by
next gc runs.
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
Add a test that checks that Kotlin Continuation wrapping Objective-C
completion handler has strong reference to it, i.e. completion handler
doesn't get reclaimed too early.
Follow-up to 4dcfd38.
The main benefit is that now lowerings and codegen are compiled in
parallel, which speeds up the build. Hopefully, this will also improve
incremental compilation in case of implementation changes because the
rest of the compiler (cli & tests) has no "api" dependency on lowerings
and codegen.
Move out utilities which are used both in lowerings and codegen to
JvmIrUtils and JvmIrTypeUtils, and introduce new JvmIrCoroutineUtils and
JvmIrInlineUtils (probably can be renamed or moved somewhere more
appropriate in the future).
Sergej Jaskiewicz