#KT-28852 fixed
The loaders and hence some classes were repeatedly loaded and
jit-compiled everytime when KaptExecution were dispatched. Those
classes, like JavaCompiler, can be very large and therefore created a
significant overhead. In some projects, the overhead accounted for more
than 40% of total CPU time of annotation processing.
This change tries to cache the classloaders so that they won't be
reloaded and re-jitted.
The compiler uses thread local values,
so when the compiler runs Gradle's thread,
it leaks classes preventing
a compiler's classloader from being collected.
#KT-28037 fixed
In cases when kapt compiler plugin runs in stubs generation mode,
Java usage tracker was not completed. This caused issues with
the incremental compilation if Java files changed.
E.g. if a constant defined in Java source file changed, stubs
would not be recompiled because the Java usage tracker would
not report changed type. This commit fixes that issue.
Instead of trying to access a missing field `Foo.foo`, call the
synthetic accessor `Foo.access$getFoo$cp` which, as per previous commit,
no longer contains the lateinit assertion
#KT-21862 Fixed
Previously, for a property named `x` in the companion object of a class
named `Foo`, we generated:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x` and lateinit
assertion
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
Now, we generate:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x`
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
and lateinit assertion
The reason is that this way we can avoid generating another accessor and
reuse `Foo.access$getX$cp` in case `isInitialized` is called on a
lateinit property from companion.
For private properties, getX is not generated, but instead the assertion
is generated on each access to the field (which can be improved, see
KT-28331). The same happens for access to non-private properties from
inside the same context where they're declared.
#KT-21862 In Progress
Mikhael Bogdanov