Jvm SegmentPool and coroutines

[ThibaultBee]

Hi,

I am just raising a question because I got an issue with ktor.

If my understanding is correct about this:

kotlinx-io/core/jvm/src/SegmentPool.kt

Line 302 in b1db70b

return (Thread.currentThread().id and mask).toInt()

The SegmentPool contains Buckets that are ordered by bucketId.

 private fun bucketId(mask: Long): Int {
        // Get a value in [0..HASH_BUCKET_COUNT_L2) based on the current thread.
        @Suppress("DEPRECATION") // TODO: switch to threadId after JDK19
        return (Thread.currentThread().id and mask).toInt()
}

And when calling take or recycle, the SegmentPool tries to get or to put a Segment to the buckets of id bucketId.

When using a single thread executor, the bucketId is always going to be the same value. It also works with a limited number of thread.
But in the coroutine context, we don't have any info about the thread. The calling thread might be different every time take or recycle is called. We don't have a clue on how coroutine deal with the thread (only in a SingleExecutor dispatcher - but it is not Kotlin multiplatform friendly).

How the SegmentPool could be sure to reuse a Segment in a coroutine context?
Am I missing something?

[fzhinkin]

How the SegmentPool could be sure to reuse a Segment in a coroutine context?

Assuming that coroutines taking segments from the pool and coroutines returning them back are evenly distributed across different threads, it does not really matter from which particular bucket a segment was taken and into which one it was returned.

It might become a problem if, for instance, segments are always taken from a bucket 0 and then returned to a bucket 1. But the second level pool is there to avoid excessive allocations in this case, so it will mostly result in slightly worse performance.

In worst case, if a second level cache is disabled (as it is on Android, for example) and we're facing the behavioral pattern from the previous paragraph, some segments will not be returned to a pool due a bucket being full, and a take will always allocate a new segment. Which is unpleasant, but the segment pool is just a way to reduce GC pressure, and it allows such behavior.

Do you have a particular scenario when it's a problem?

[ThibaultBee]

Thanks for your answer 👍

As my library is running on Android, that might be the issue I am facing.
See https://youtrack.jetbrains.com/issue/KTOR-8642

Do you have a workaround to suggest?