Alexander Udalov
098a935aa7
When we inline an anonymous object which captures something such as crossinline values or reified parameters, we copy and transform its metadata in `AnonymousObjectTransformer.transformMetadata`. Basically we read the metadata of the original class, add a minor protobuf extension and write it to the new class. This also includes copying the string table. We read the string table into `JvmNameResolver` (a representation of string table used in deserialization), then construct a `JvmStringTable` (a representation used in _serialization_) and then write it back. There's a few optimizations in the string table representation in JVM metadata which allow to store less strings and thus take less space. See `StringTableTypes.Record` in `jvm_metadata.proto` for more information. One of the optimizations `Record.range` allows to avoid storing the same record many times in a sequence. For example, if we have N different strings in the string table but none of them require any operation (such as substring, char replacement, etc.), then we only store the record with all default values (no operation, no predefined string, etc.) and set its `range` to N. Upon reading such optimized record list in `JvmNameResolver`, we "expand" it back to normal, so that we could index it quickly and figure out what operation needs to be performed on each string from the string table. The problem was that when we expanded this list, we didn't set the range of the expanded record entry to 1. So each record in `JvmNameResolver.records` still has its original range. It doesn't cause any problems most of the time because the range in this expanded list is almost unused. However, when copying/transforming metadata for anonymous objects, we mistakenly passed this expanded list with incorrect ranges to `JvmStringTable`. So the metadata in the copied anonymous object ended up being incorrect: each record now was present the number of times equal to its range. Copying such metadata once again led to another multiplication of the record list size. Multiple copies resulted in exponential increase in memory consumption and quickly led to OOM. For the fix, we now take the original, unexpanded list of records when creating `JvmStringTable` out of `JvmNameResolver` for transformation of anonymous object metadata. Note that another possible fix would be to make range for each record in `JvmNameResolver.records` equal to 1. This is undesirable though, since then we'd need to copy each `JvmProtoBuf.StringTableTypes.Record` instance, of which there could be many, and use some memory for no apparent gain (since ranges in that expanded list are now not used at all). #KT-38197 Fixed
54 lines
1.3 KiB
Kotlin
Vendored
54 lines
1.3 KiB
Kotlin
Vendored
// FILE: test.kt
|
|
// WITH_RUNTIME
|
|
// WITH_COROUTINES
|
|
|
|
var result = "Fail"
|
|
|
|
fun use(token: String) {
|
|
result = token
|
|
}
|
|
|
|
inline fun f(crossinline body: suspend () -> Unit) =
|
|
g<
|
|
Any, Any, Any, Any, Any, Any, Any, Any, Any, Any,
|
|
Any, Any, Any, Any, Any, Any, Any, Any, Any, Any,
|
|
>(body)
|
|
|
|
inline fun <
|
|
reified U01, reified U02, reified U03, reified U04, reified U05, reified U06, reified U07, reified U08, reified U09, reified U10,
|
|
reified U11, reified U12, reified U13, reified U14, reified U15, reified U16, reified U17, reified U18, reified U19, reified U20,
|
|
> g(crossinline body: suspend () -> Unit): suspend () -> Unit {
|
|
return run {
|
|
run {
|
|
run {
|
|
run {
|
|
run {
|
|
run {
|
|
run {
|
|
run {
|
|
suspend {
|
|
body()
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
// FILE: box.kt
|
|
|
|
import kotlin.coroutines.*
|
|
import helpers.*
|
|
|
|
fun box(): String {
|
|
var token = "OK"
|
|
f {
|
|
use(token)
|
|
}.startCoroutine(EmptyContinuation)
|
|
return result
|
|
}
|