onClick lambda will leak refrences.

[seyedjafariy]

If any reference is used in the onClick lambdas the reference will be leaked and won't be garbage collected.
that applies to both: Modifier.clickable{} and Button(onClick= {})

here is a small sample to showcase this issue:

@Composable
private fun ScreenAInternal(state: Int, presenter: ScreenAPresenter) {
    Box(contentAlignment = Alignment.Center, modifier = Modifier.background(highlightedAccentColor).fillMaxWidth()) {
        Text("state A= $state", modifier = Modifier.align(Alignment.TopStart).clickable {
            presenter.state.value = presenter.state.value + 1
        })

        val appState = AppStateManager.stateManager.current

        Button({
            appState.currentState = AppScreenState.BScreen
        }) {
            Text("to screen B")
        }

        if (state in 6..10) {
            ScreenAHidden(Modifier.align(Alignment.TopEnd).background(Color.Blue))
        }else if (state > 10){
            ScreenAHidden(Modifier.align(Alignment.TopEnd).background(Color.Red))
        }
    }
}

In here the presenter object will be leak just because it's been referenced in the onClick lambda. there is the object graph which leads to: root Recomposer, AppManager and awt.Window

summary of heap graph by JProfiler: (Jprofiler noob here sorry if I couldn't export it any better way!)

[olonho]

Not sure if this is what typically called "leak". That's how generally value capturing works. If certain object is used in lambda - its reference is held by lambda object. Probably slight rework on state management with more granular state objects may help.

[seyedjafariy]

Thanks for your comment @olonho . Passing the reference and holding it in the lambda is ok and is exactly what I want.
But the issue is that this reference will never get garbage collected.

After calling GC manually or even waiting a long time (for automatic GC to happen) all of the other useless objects were removed from the heap except this one.

ScreenAInternal is an "entire screen" @Composable. So if I change my "screen" to another and come back to this, I expect a new Presenter to be created (which it does) but I also expect that the old presenters to be GCed out in the next cycle(worth mentioning the garbage collection works for all other object and only fails for the references that passed to an onClick lambda), this part is not working. hence multiple ScreenAPresenter will be created and held in the heap.
So as I understood from the profiler (ScreenShots above) the problem is not my object it's the onClick lambdas that never get GCed. and they will live throughout the entire app runtime.

[igordmn]

Thanks!

I checked this code:

import androidx.compose.desktop.Window
import androidx.compose.foundation.layout.Column
import androidx.compose.material.*
import androidx.compose.runtime.*

fun main() = Window {
    App()
}

@Composable
fun App() {
    var i by remember { mutableStateOf(0) }
    Column {
        Button(onClick = {
            i++
            System.gc()
        }) {
            Text("Next")
        }
        if (i % 2 == 0) {
            View1()
        } else {
            View2()
        }
    }
}

@Composable
fun View1() {
    View(remember { Presenter("View1") })
}

@Composable
fun View2() {
    View(remember { Presenter("View2") })
}

@Composable
fun View(presenter: Presenter) {
    Button(onClick = { presenter.click() }) {
        Text(presenter.text)
    }
}

class Presenter(val text: String) {
    fun click() {
    }
}

And indeed, we have a memory leak. And probably we already have a solution. Will try it

[seyedjafariy]

@igordmn Thanks for the complete example. I should have pasted my example completely too, sorry.
Is there a public link for the solution?
https://partnerissuetracker.corp.google.com/issues/170869626#comment4
I can not access this

[jimgoog]

@worldsnas Try https://issuetracker.google.com/issues/170869626#comment4

[olonho]

Shall be fixed with 0.4.0-build179.

[okushnikov]

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.