Memory leak caused by creating a unique logger for each `KrpcServerService` instance

[akowal]

krpc version: 0.10.1

I found that kotlinx.rpc.krpc.server.internal.KrpcServerService creates a unique logger for each instance:

private val logger = RpcInternalCommonLogger.logger(rpcInternalObjectId(descriptor.fqName))

Since KrpcServerService is created on each service registration (basically, on each new connection) over time this leads to a huge number of loggers created and kept in memory by logging framework implementations (e.g. Logback).

A simple example reproducing the issue: https://github.com/akowal/krpc-log-memleak

Here's a couple of heap charts:

And some picks from the heapdump after JVM OOM (can be found in the example repo):

[akowal]

Same goes for all descendants of kotlinx.rpc.krpc.server.KrpcServer and kotlinx.rpc.krpc.client.KrpcClient since they also create unique loggers using RpcInternalCommonLogger.logger(rpcInternalObjectId())

[Mr3zee]

@akowal Well, it's not a memory leak. It may be an excessive memory usage, yes, but the loggers are cleaned up by GC when the service is.

The real issue that I can see here - is how many memory is used per connection on a server and if this can be reduced.

[akowal]

@Mr3zee I would argue that it is indeed a memory leak:

1. Those loggers are effectively unreachable/unusable from the app code perspective, despite being reachable from GC root.
2. They're never collected by GC regardless of whether krpc service instances are collected or not. Typically, logging frameworks treat loggers as permanent objects -- they are created and cached, but never evicted. For example, check Logback's implementation (ch.qos.logback.classic.LoggerContext#loggerCache).