Instance (or some part of it) not released from heap after closing in JPro

[xcporter]

Hello!

I'm currently working with TornadoFX 1.7.20, and serving a demo on the web with JPro. I'm running a heap size of 350mB, and after about 5 to 10 instances launched and closed, I start having low memory issues. Looking at a profile, it seems the amount left over is about 40mB per login. I don't see any memory issues unless I'm running multiple instances on the same jvm.

I am using a menu structure built with the EventBus, and there are also a few custom Fragments and UI components as well. Additionally, I suspect that the way I build certain node trees with functions might be to blame.

Is there something more I should be doing to release Views, Components, etc. from memory?
I'm somewhat new to the JVM environment, but it looks like NIO HeapByteBuffers are taking up the most space.

Here are the JVM arguments:

-Xms350m
-Xmx350m
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200

Simplified version of project: https://github.com/xcporter/memtest

Possible leak suspects:

EventBus use, also--
does this EventHandler need to be manually unsubscribed?

menuButton.addEventHandler(MOUSE_PRESSED) { fire(ViewChange(ViewState.MENU, scope)) }

class ViewChange(val state: ViewState, scope: Scope) : FXEvent(scope = scope)

subscribe<ViewChange> {}

the way views are replaced

root.center.replaceWith(
                            find<ColumnConnect>().root,
                            transition = ViewTransition.Slide(0.5.seconds, ViewTransition.Direction.LEFT)
                    )

jpro scope/ setup

class WebScope(val stage: Stage) : Scope() {
    val webAPI: WebAPI get() = WebAPI.getWebAPI(stage)
}

class Main : JProApplication() {
    val app = EfasApp()

    override fun start(primaryStage: Stage) {
        app.scope = WebScope(primaryStage)
        app.start(primaryStage)
    }

    override fun stop() {
        app.stop()
        super.stop()
    }
}

[mswokk]

Not sure about cause of this issue is same with my issue,
I tried to fix some memory leaking.
See #1318 , #1319