API to get serializer for a class without creating kotlin reflection class

[develar]

What is your use-case and why do you need this feature?

Current experimental API ::kotlin.get().serializer() implies creating extra kotlin reflection class. That's not acceptable from a performance point of view in all cases.

Describe the solution you'd like

Could you please provide API to use just a java Class?

[develar]

official API:

using java class only:

   // findStaticGetter cannot be used because type of Companion is unknown
    val companion = lookup.unreflectGetter(aClass.getDeclaredField("Companion")).invoke()
    @Suppress("UNCHECKED_CAST")
    serializer = companion.javaClass.getDeclaredMethod("serializer").invoke(companion) as KSerializer<Any>

[qwwdfsad]

Current experimental API ::kotlin.get().serializer() implies creating extra kotlin reflection class.

Could you please share a small example of the overhead for us to have something we can compare?

It seems like we indeed can provide a delicate API that operates with a regular Class and even speedup Type-based API

[develar]

For years already in IJ Platform, we do not create kotlin reflection class wrappers if we can avoid it. Profiler snapshot provided above. We have hundreds of persistence state components. That's also not only about performance, but about avoiding extra caches and so on (dynamic plugin reloading, for example).

Say, because it is visible in a profiler snapshot, then another core team member will ask me again and again about that on some performance and/or memory issues investigation.

Fewer issues, easier for me to promote kotlin.

[qwwdfsad]

I'm not a developer of the IJ platform and not aware of your internal guidelines and constraints, thus I've been asking for additional details.

Profiler snapshot provided above.

There may be a lot of reasons why this call appeared in the snapshot. For example, it's the very first call to Kotlin reflection and thus it's loading all the classes.
The very first call to LambdaMetafactory is also slow and may appear in the snapshot, but it's not the reason to avoid Java lambdas, is it?

about avoiding extra caches and so on (dynamic plugin reloading, for example).

Are you talking about the cache in Kotlin reflection itself (one in kotlin.jvm.internal.Reflection.getOrCreateKotlinClass) or about your own caches?

Are you interested in a "cold" performance (e.g. one-shot invocation) or a "hot" one (when JIT kicks in)?
Do you have any performance criteria besides "it's visible in the profiler"? E.g. if the overhead of KClass instantiation will take ~10% of the serializer() call -- will it still be an issue?
Are Kotlin reflection classes loaded in IJ platform at all?

[develar]

but it's not the reason to avoid Java lambdas, is it?

It may be a reason. We are working on speeding up the start-up. Every used API is checked and profiled. If we can avoid using something and it is worth it, we do avoid it.

Are you talking about the cache in Kotlin reflection itself

Yes, I mean potential not clear side-effects of used 3rd-party API.

Are you interested in a "cold" performance (e.g. one-shot invocation) or a "hot" one (when JIT kicks in)?

Cold :( For example, running tests, application start-up.

Do you have any performance criteria besides "it's visible in the profiler"? E.g. if the overhead of KClass instantiation will take ~10% of the serializer() call -- will it still be an issue?

We have very different people in a core team ;) In short — often easier to avoid questionable code than to explain and check again and again that this piece of code is innocent and doesn't bring any issues. The first question is always — can we avoid it at all? If we cannot, then the second question — is it acceptable or not? Here no need to think about "is 10% ok or not", because it is clear that kotlin reflection wrapper is not needed here at all.

Are Kotlin reflection classes loaded in IJ platform at all?

Only by mistake or if we cannot avoid it. For example, in some cases we have to use a special shim in Java to avoid it (https://github.com/JetBrains/intellij-community/blob/master/platform/object-serializer/src/PropertyAnnotationUtil.java)

[qwwdfsad]

I've investigated potential solutions for the problem.

In general, it seems to be working as intended with the only exception -- if the target class is marked with @Polymorphic (or, in general, is interface), the implementation is obliged to return PolymorphicSerilizer(javaClass.kotlin). Is it going to work for you?

Also, I've studied implementation from JetBrains/intellij-community@51be4e7 -- it seems to be incomplete. E.g. it won't work for enums, primitive types, classes with named companions*, classes with generic parameters and arrays.

• -- e.g.:

@Serializable
class Box(...) {
    companion object Default {

    }
}

[develar]

Is it going to work for you?

Not required for our use case. Polymorphic cannot be on a root class, only on a nested (but we don't check nested — that's up to root class serializer). Under "nested" I mean a class of some root class fields.

it seems to be incomplete

For now, we do not use kotlinx serialization for these types. I do understand, that you probably don't want to open API, that will support only regular classes (it is currently internal in your implementation) — to reduce API surface and simplify it. I don't bother about performance loss on such checks, I guess it is negligible.

[qwwdfsad]

Let me rephrase it directly: consider we have an API Class<?>.serializer() which mirrors KClass<?>.serializer() -- supports all the types the latter does, instantiates KClass for polymorphic serializers and does all the checks required for API to function -- whether the class is enum, interface and so on, will such API be useful for you? Are you still going to adopt it?

[develar]

Yes, such an API will be useful for me and it will be used as is (and serializerOrNull in addition). Currently, it is under aClass.isAnnotationPresent(Serializable::class.java) check anyway, so, we do call it only for serializable classes.

[sandwwraith]

I'm a bit late here, but what's wrong with the serializer(java.lang.Type) function?

kotlinx.serialization/core/jvmMain/src/kotlinx/serialization/SerializersJvm.kt

Line 30 in bb0d274

public fun serializer(type: Type): KSerializer<Any> = EmptySerializersModule.serializer(type)

j.l.Class implements Type so everything should work fine. Or do you want to avoid instanceof check completely? Or is it a generic argument you want to preserve?

[qwwdfsad]

serializer(type) is fine, but now it uses quite a lot of Klass machinery internally, the PR has the explanation

[qwwdfsad]

In the new release,it should be enough to use Type-based functions, they avoid instantiating KClass as much as possible