Profiling the compilation of kotlinx.serialization, MaxStackFrameSizeAndLocalsCalculator
causes ~7% of the runtime to be spent in java.lang.Object.hashCode
This is through two uses:
- visitMaxs(..) has a pushed hashSet that causes ~2%
- labelWrappersMap used to attach additional data to asm Labels, causes ~ 5%
visitMaxs can use the existing SmartSet (not to be confused with SmartHashSet)
Analysis of the visitMaxs HashSet creation & sizes:
| What | Amount |
| calls to visitMaxs | 4416 |
| max pushed | 158 |
| median pushed | 4 |
| average pushed | 5.20 |
| stddev pushed | 7.66 |
| 90 percentile | 10 |
Analysis of labelWrappersMap creation & sizes:
| What | Amount |
| ------------------ | ------ |
| hashtables created | 4006 |
| max entries | 175 |
| median entries | 5 |
| average entries | 6.10 |
| stdev entries | 8.28 |
| 90 percentile | 11 |
testing with a non hash based map using an array for keys and an array for values
showed that the cost of MaxStackFrameSizeAndLocalsCalculator became neglible to
the overall running time.
SmartIdentityTable is a Map like structure that uses reference identity for keys.
It uses 2 arrays to store keys & values until the number of entries stored is larger than 10.
At that point it switches to using an IdentityHashMap.
This structure can be used instead of HashMap when reference identity can be used and
the number of entries inserted is small (<= 10) on average, drastically reducing the overhead
of calls to Object.hashCode
Between the two changes, compilation of kotlinx.serialization through kotlinc
commandline decreased from 14 seconds to 11 seconds on my machine
It's enough to have at least one good constraint.
Note that the whole algorithm can be a bit more general:
we could check also Out<T>, In<T> and verify that T has good only
lower constraint or upper constraint, but there are questions for
types like Inv<Out<T>>, where T should have lower and upper constraints
#KT-31514 Fixed
A synthetic property descriptor created for `B.value` (see the added
test) should not be equal to the normal descriptor created by the fake
override construction algorithm. Otherwise we can't reach this synthetic
non-abstract descriptor when building bridges in `C`, which results in
exception.
#KT-31367 Fixed
It uses isStaticMethod to determine whether to set ACC_STATIC, which is
not correct (see PR #2341). This results in using incorrectly typed
opcodes (as all arguments are shifted by 1) when modifying the inlined
lambda's bytecode. For example, in the test added by this commit, these
opcodes are inserted to spill the stack into locals before calling
another inline function.
Because getMethodAsmFlags is used by the non-IR backend (see PR #2341
again for why changing stuff might not be a good idea), the proposed
solution is to ditch it completely and override generateLambdaBody in
IrExpressionLambdaImpl to use FunctionCodegen's IR-based flag
computation logic.
Although the intention of the change 9894c216c1 (#2341) was sensible, it
unfortunately caused the type mapper to map a default method incorrectly
under certain _undiscovered_ circumstances, which leads to incorrect
bytecode being generated. Specifically, this led to an exception:
java.lang.NoSuchMethodError : org.jetbrains.kotlin.idea.debugger.evaluate.KotlinDebuggerCaches$Companion.compileCodeFragmentCacheAware$default(Lorg/jetbrains/kotlin/psi/KtCodeFragment;Lcom/intellij/debugger/SourcePosition;Lkotlin/jvm/functions/Function0;ZILjava/lang/Object;)Lkotlin/Pair;
in a developer branch where this class was refactored and moved to
another module. I was not able to determine the exact reason of this
error, so I'm workarounding it by limiting this change to the IR backend
only (where it's needed), and postponing the investigation of the
failure above for now.
The synthesized arguments caused the size of default value mask off by
one when it is close to the boundary of Int.SIZE, which in turn
resulted in wrong signature at call sites.
in OUTERCLASS field.
The inliner generates two versions of suspend functions/lambdas in
inline functions: with state-machine and without. The former is used
to call the function from Java or via reflection and have ordinary
name, while the latter is used by inliner and have $$forInline suffix.
The inliner throws the state-machine version away, duplicates
$$forInline version and then call state-machine generator.
If these suspend functions/lambdas are not going to be inlined,
$$forInline version is not generated. However, all objects, which are
used in these suspend functions/lambdas, have $$forInline version
written to OUTERCLASS field. This leads to errors by proguard.
Since they are used in both state-machine version and for-inline ones,
we can simply remove $$forInline suffix from OUTERCLASS field and this
fixes the issue.
#KT-31242 Fixed
In 1.3.31 I fixed Java interop for inline function with coroutines
(TL;DR: when we need a state machine, generate two methods: one with
normal name, and the other one with $$forInline suffix, for the inliner
to use, just like inline suspend functions), however, I forgot a case
with inline suspend function with inline suspend function parameter.
In this case, the compiler a generated two functions, as needed, but,
neither of them had a state-machine. This change adds the state-machine
for the method with normal name. Note, that suspend inline functions
with crossinline parameter, which are also supported by the change,
did not cause incorrect behaviour, since until now they were generated
as synthetic.
#KT-31354 Fixed
This change also makes sure that no line numbers are generated
in the wrappers in the JVM_IR backend.
Change-Id: If6c37f8a20894455abddb526039df059e02015a3
During coroutines transformation, we analyse liveness of local variables
in order to decide whether we need to spill them or not.
This analysis contains hot method `useVar`, in which we previously
iterated over all variables in LVT. This is done, since these variables
are seen by debugger and we assume they are alice.
However, this variables can be generated by inliner. In this case, the
LVT's size in huge. I.e. we have loop in hot method.
By hoisting the liveness analysis of the LVT and combining its result
with result of usual liveness analysis, we achieve speed-up from 2m30s
down to 5s.
#KT-30603 Fixed
This fixes Java interop of inline functions, which use coroutines.
However, we cannot transform the state-machine. Thus, we generate
a $$forInline counterpart for suspend functions (similar to inline
suspend functions) and invokeSuspend$$forInline for lambdas if these
coroutines are going to transformed (i.e. are declared inside inline
functions).
During transformation we just skip method with state-machine and
transform the $$forInline counterpart. Of course, if inline site is
inline itself, we generate both state-machine version (which will be
dropped during the next transformation) and $$forInline version.
Consequently, the final version of the coroutines will not have
$$forInline counterpart.
Unfortunately, since CompileKotlinAgainstInlineKotlin tests do not allow
java sources, the tests for the interop are usual box tests.
#KT-30707 Fixed
The type mapper does not map enum parameters and outer this parameters
to the right parameter signature kinds so around half the tests
are still failing. Since a new type mapper is being worked
on I will not investigate that further right now.
Two known issues with generateNonPartClassDeclarations that was here
before were the fact that we didn't sort sealed classes and its
subclasses which led to NoSuchMethodError (KT-27097), and the fact that
we didn't skip expect classes which led to incorrect duplicate JVM class
name diagnostic (KT-30843)
#KT-27097 Fixed
#KT-30843 Fixed
if they are not inlined, but directly called.
Previously, all inline and crossinline lambda calls were treated by
codegen as if they are always going to be inlined. However, this is not
always the case.
Note, that we cannot generate these markers during codegen, since we
can inline code with no suspension points, but the whole inlined code
will become one giant suspension point. This, of course, breaks
tail-call optimization and, hence, slows down cold streams.
Because of that, we generate these markers, when we are sure, that they
are not going to be inlined. The only place, in which we know that, is
the inliner. During inlining of the inline function, we check, whether
the parameter is inline or crossinline and whether it is not an inline
lambda. If these checks pass, we generate the markers. Noinline
parameters are already covered by the codegen.
#KT-30706 Fixed
#KT-26925 Fixed
#KT-26418 Fixed
Jeffrey van Gogh