Kotlin/Native: Missing fillInStackTrace() causes performance issues with frequent coroutine cancellations

[messyguuuuys]

Description

In Kotlin/JVM, Throwable.fillInStackTrace() allows controlling stack trace collection, which is crucial for performance when exceptions are used for control flow (e.g., CancellationException in coroutines).

Kotlin/Native lacks this method, causing mandatory stack trace collection on every exception initialization, leading to performance degradation and app freezes when cancelling coroutines frequently.

Current Behavior

// Kotlin/Native
class MyCancellationException : CancellationException() {
    // ❌ No fillInStackTrace() to override
    // Stack trace is always collected
}

Expected Behavior

// Like Kotlin/JVM
class MyCancellationException : CancellationException() {
    override fun fillInStackTrace(): Throwable {
        return this // Skip stack trace collection
    }
}

Performance Impact

• High-frequency job cancellations cause significant overhead
• Stack trace collection on main thread → UI freezes
• Measured X ms per cancellation in production

Reproduce

import kotlinx.coroutines.*

fun main() = runBlocking {
    repeat(10000) {
        launch {
            try {
                delay(Long.MAX_VALUE)
            } catch (e: CancellationException) {
                // Stack trace collected here unnecessarily
            }
        }.cancel()
    }
}

Environment

• Kotlin version: 1.x.x
• Kotlin/Native version:
• Target: iOS/Android Native
• Coroutines version: 1.x.x

Proposed Solutions

1. Add fillInStackTrace() support to Kotlin/Native Throwable
2. Add compiler flag to disable stack traces for specific exception types
3. Make CancellationException not collect stack traces by default

References

• Similar issue in coroutines: [link if exists]
• JVM behavior documentation: [link]

[fzhinkin]

@messyguuuuys, do you have a benchmark showcasing the impact of stack trace collection on cancellation performance in K/N? Or it is an educated guess?

[messyguuuuys]

@fzhinkin

No, this is not an educated guess. We encountered this issue in our production environment.

In scenarios like live streaming chat/danmaku, we heavily use thread-switching operations with delays and cancellations. The cancellation operations are where we hit the performance issues with kotlin-native's stack trace collection.

Here's a simplified demo code that reproduces our use case:

import kotlinx.coroutines.*

class TaskScheduler {
    private val jobMap = ConcurrentMutableMap<Any, Job>()
    private val uiDispatcher = Dispatchers.Main
    private val scope = CoroutineScope(SupervisorJob() + Dispatchers.Default)
    
    /**
     * Run a task on UI thread after a delay
     * @param runnable The task to execute
     * @param token Unique identifier for this task
     * @param delayMillis Delay in milliseconds
     */
    fun runOnUIThreadDelay(runnable: () -> Unit, token: Any, delayMillis: Long) {
        val job = scope.launch {
            try {
                delay(delayMillis)
                withContext(uiDispatcher) {
                    runnable()
                }
            } catch (e: Exception) {
                // Handle exception
            } finally {
                jobMap.remove(token)
            }
        }
        
        jobMap[token] = job
    }
    
    /**
     * Cancel and remove job associated with the token
     * @param token The token to identify the job
     */
    fun removeJobWithToken(token: Any) {
        jobMap.remove(token)?.cancel()  // Performance bottleneck here
    }
}

// Usage example simulating live chat scenario
class LiveChatManager {
    private val scheduler = TaskScheduler()
    
    fun handleDanmakuMessage(messageId: String, content: String) {
        // Display message after short delay
        scheduler.runOnUIThreadDelay(
            runnable = { displayMessage(content) },
            token = "danmaku_$messageId",
            delayMillis = 100
        )
        
        // Auto-hide after 5 seconds
        scheduler.runOnUIThreadDelay(
            runnable = { hideMessage(messageId) },
            token = "hide_$messageId",
            delayMillis = 5000
        )
    }
    
    fun cancelMessage(messageId: String) {
        // Frequently called when messages are manually dismissed
        // This is where we see performance impact from stack trace collection
        scheduler.removeJobWithToken("danmaku_$messageId")
        scheduler.removeJobWithToken("hide_$messageId")
    }
    
    private fun displayMessage(content: String) { /* UI update */ }
    private fun hideMessage(messageId: String) { /* UI update */ }
}

Performance Impact:

In our production environment during peak live streaming hours, we're seeing:

• Thousands of removeJobWithToken() calls per minute
• Each cancel() call triggers stack trace collection
• Noticeable performance degradation on Native(iOS/OHOS) devices, especially on older models

The stack trace collection overhead becomes significant when cancellations happen at this scale.

[fzhinkin]

@messyguuuuys, thank you for elaborating and providing a test case.

Indeed, K/N spends a lot of time on exception handling, but most of the time is spent on stack unwinding (walking the stack up and looking for someone to handle an exception) and I don't see an easy way to fix it right now. I'll discuss with colleagues how to address the issue.