- Move the following from 'deserialization' to 'descriptors':
NotFoundClasses.kt
AdditionalClassPartsProvider.kt
ClassDescriptorFactory.kt
PlatformDependentDeclarationFilter.kt
findClassInModule.kt
- Move the following form 'descriptors' to 'deserialization':
BuiltInSerializerProtocol.kt
builtInsPackageFragmentProvider.kt
- Extract a marker interface from BuiltInsPackageFragment and move its
implementation to 'deserialization'
- Change the type of parameters in PlatformDependentDeclarationFilter
and AdditionalClassPartsProvider to ClassDescriptor
This will help in getting rid of the circular dependency of
'descriptors' <-> 'deserialization'
The problem was that an overload of CodedOutputStream.newInstance
without size uses 4000 as a default value, thus allocating
a 4k-sized byte array.
At the same time the array remained effectively unused
in the most cases since it only used for storing data
for unknown fields.
Because such arrays are being created for each read of
protobuf message, during compilation of IntelliJ project
it was producing 25% of redundant memory traffic.
Of course these arrays were all in the young gen, but still
they have some effect on GC
Instead of requiring to pass it in SerializerExtensionBase's
constructor, pass it always in serializePackage. This is more
straightforward and helps in a situation where one SerializerExtension
instance is used for the whole module, not one per-package
Instead of multiple .kjsm files for different classes and .kotlin_string_table,
.kotlin_file_table, .kotlin_classes files for each package, serialize the
contents of each package to a single foo/bar/baz/baz.kjsm file. The short name
of the file is the last segment in the FQ name of the package, or
"root-package" if the package is root.
There are two main reasons for this change:
1) Such structure takes less space, is more IO-friendly and will not cause
multiple exceptions as the old one, where we sometimes tried to read
non-existing files
2) This is exactly the same format that is used to serialize built-in
declarations (.kotlin_builtins) at the moment, which will allow us to reuse
some code
Also write a separate Header protobuf message to the beginning of the .kjsm
file. This will be used as arguments of the kotlin.Metadata annotation are used
in the JVM-specific parts of the compiler: to be able to provide some general
information about the binary file without parsing the whole protobuf data.
This commit breaks decompiled text & stub builder consistency tests. This is OK
because they're removed in a future commit.
Fixes EA-79605, EA-81947, EA-84277 and maybe EA-86787
#KT-10894 Fixed
#KT-14124 Fixed
#KT-15755 Fixed
Instead of writing many different files and serializing this "virtual file
system" to a byte array in a protobuf message, just write the needed stuff
directly, as fields in the Library message. Make it consist of many Part
messages, where the Part message is equivalent to the BuiltIns message in
builtins.proto. The next step would be to combine Library.Part and BuiltIns,
which will allow us to simplify some serialization-related code soon.
In this commit, no changes happened to the .kjsm format. But since the code
that serialized the abovementioned files was shared, a temporary abstraction
over two serialization formats was made, see SerializerCallbacks.
This commit temporarily breaks .kjsm decompiler and stub builder
Do not serialize everything in the same package to the same file (as is done
for built-ins) because this approach is unfriendly to incremental compilation,
which is going to be supported in the future. Instead, similarly to JVM
serialize each class to its own file, and each source file with top-level
callables/typealiases to its own file.
E.g. if a file named test.kt contains a class Foo and some
functions/properties, the output will contain two files: TestKt.kotlin_metadata
and Foo.kotlin_metadata. Each one of this files contains the serialized
BuiltIns message (see builtins.proto)
If deserializing a type with arguments based on a local class for
decompiler, then just return Any type (without arguments).
Previously Any constructor was used with serialized arguments, that lead
to exception
Note that in case of deserialization for compiler nothing changes about
local-classes-based types (LocalClassifierResolverImpl is just inlined)
#KT-13408 Fixed
Alexander Udalov