Together with almost every type now there's also an id which references a type
from a separate table. Storing such ids instead of Type messages will allow to
reduce the size of the metadata for files where types are used many times over
and over again. Currently only deserialization of such types is supported,
along with the former mechanism
Original commit: 82d2e623d3
This proved to be a fragile technique, which probably doesn't even improve
performance in most cases but has lots of unexpected problems: unconditional
initialization of reflection classes, increasing the size of the bytecode, bugs
with <clinit> in annotations on JVM 6, inability to support conversion of a
class from Kotlin to Java without recompiling clients which use it
reflectively, etc.
Original commit: a4732b442d
When the trivial type mapping (implemented in JvmProtoBufUtil) from
ProtoBuf.Type instances works fine, don't write the signature since it can be
loaded by exactly the same trivial type mapping
Original commit: 864926ee2e
External annotations will only be considered in the IDE for additional
inspections based on more precise types in Java libraries
Original commit: 13c54a2678
- move enums and messages nested in Callable to top level, since they're likely
to be reused in other messages soon
- delete obsolete comments: some did not any value, some became obsolete with
custom options ("id in StringTable" -> name_id_in_table)
Original commit: e4090d3f30
This format of the string table allows to reduce the size of the Kotlin
metadata in JVM class files by reusing constants already present in the
constant pool. Currently the string table produced by JvmStringTable is not
fully optimized in serialization (in particular, the 'substring' operation
which will be used to extract type names out of generic signature, is not used
at all), but the format and its complete support in the deserialization
(JvmNameResolver) allows future improvement without changing the binary version
Original commit: 1036506b25
Nothing especially helpful happens here, this is only a big refactoring
introducing a separate string array for the string table, which is currently
always empty, but will contain actual strings soon
Original commit: 6a8d0fbd75
Store the whole method & field descriptor strings. Moving these strings to
separate annotation arguments later will allow to reuse them with the ones in
the constant pool, presumably allowing to save lots of space (up to 10%)
Original commit: 7d5bd3cf50
Alexander Udalov