Hi, yesterday I spend some time for a leak in our ...

# eap

[Sinan Kozak]

Hi, yesterday I spend some time for a leak in our application. it turn out collected item is not cleared from Channel. I found KT-16222 as fixed in 1.4.20-M1 but provided sample code and our own code still leaks and don’t clean up. I tested with both M1 and M2. (Our issue is much more similar to linked KT-33986). I am looking at the source code to find out any test for those issues. KT-16222 should be open again if it is not fixed yet.

[Sinan Kozak]

hey, @louiscad thank you for checking. I will run your examples now. Do you use new IR compiler or default one?

[louiscad]

I just made a check, and the issue is indeeded fixed.
I didn't use the JVM IR.

[louiscad]

But I'm happy to read the results of your experiments with the JVM IR @Sinan Kozak

[Sinan Kozak]

I found out in my example, compiled code uses same object to ref and first and second ref.get(). In you example because there is repeat logic. compiler doesnt use same local object for ref.get

[Sinan Kozak]

fuunny enough adding repeat also fixes the original code sample

[louiscad]

The same happens if you unroll the repeat properly, right?

[Sinan Kozak]

if i remove repeat lambda call and add

Thread.sleep(10)
    System.gc()

10 times, reference is kept. But think this is not a great example. because in this example compiler tries to reuse local object references.

[louiscad]

@Sinan Kozak Did you try adding a yield() call before the calls to System.gc()?

[Sinan Kozak]

Our leak actually more similar to KT-16222. I tested this code just to be sure about fix. But example is not great. There is definitely fixes and cleanups.

[louiscad]

Well, that's the issue we're talking about in this thread.

If the behavior is different when the same code is called without repeat, then I think it's worth reporting about.

[Sinan Kozak]

adding yield changes the output because rest of the code become part of different code block in bytecode. So they dont reuse same local object

[louiscad]

Alright, so in long running coroutines, there's no issue

[Sinan Kozak]

exactly

[louiscad]

Am I right that the weakreference is bypassed somehow in your tests?

[Sinan Kozak]

Kind of. Compiled code reuse local object without setting null. So it keeps reference to object until next ref.get call

[Sinan Kozak]

when compiler plan to reuse same local object, it should set to null that object until setting again

[louiscad]

If you can pinpoint the issue, I think it makes sens to open a new issue since the original one is indeed fixed.

[Sinan Kozak]

👍 I will create a new issue for the improvement request after KT-16222.

[Sinan Kozak]

Thank you for your time and suggestions @louiscad

[louiscad]

You're welcome 🙂

[Sinan Kozak]

Here is the new ticket. https://youtrack.jetbrains.com/issue/KT-43031

[Sinan Kozak]

i think this is not a problem for most of the use cases. That wasn’t the issue I was trying to fix 😄 I will focus on KT-33986 to reproduce the issue and provide details if needed/Or fix it if i can.

[louiscad]

I'd add a Thread.sleep(1000) after the 2 System.gc() calls

[louiscad]

GC is not necessarily synchronous

[Sinan Kozak]

let me test that

[Sinan Kozak]

I dont expect gc to clena that value because ref still there.

[louiscad]

I'm not saying it will produce a different result as-is, but when checking for resolution, it'll likely have an impact.

[Sinan Kozak]

So i tested with 10seconds, still same result

[louiscad]

In fact, I think System.gc() is never synchronous, for performance reasons.