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
JavaScript Translation
This module performs the translation of Kotlin source code to JavaScript.
There are various Kotlin APIs to JavaScript environments in the standard library.
Compiling the Kotlin Standard Library for JavaScript
The Kotlin Standard Library for JS is built with gradle, see the corresponding module's ReadMe.
Reusing JVM based test cases in JavaScript
Any Kotlin test cases using the org.junit.Test annotation and the kotlin.test package, such as this test case are automatically converted to JavaScript using QUnit.
This allows the test cases to be run directly in a web page in any web browser.
Using the Kotlin Library in JavaScript
There is a simple sample which shows how to use the Kotlin Standard Library from inside JavaScript in a web page.
Contributing
We love contributions! The JavaScript translation could really use your help! If you fancy contributing:
- check the contributing section on general stuff like getting the code etc
- try fix one of the pending JavaScript translation issues