Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kotlin multiplatform leaking memory #4037

Merged
merged 8 commits into from
Oct 1, 2024
Merged

Kotlin multiplatform leaking memory #4037

merged 8 commits into from
Oct 1, 2024

Conversation

vcoolish
Copy link
Contributor

@vcoolish vcoolish commented Sep 24, 2024

Fixes #4021

Android:

Before After
Screenshot 2024-09-24 at 19 57 16 Screenshot 2024-09-24 at 20 41 57

iOS:

BeforeStart BeforeEnd AfterStart AfterEnd
Screenshot 2024-09-25 at 15 36 58 Screenshot 2024-09-25 at 15 36 55 Screenshot 2024-09-25 at 15 43 40 Screenshot 2024-09-25 at 15 43 43

@satoshiotomakan satoshiotomakan marked this pull request as ready for review September 24, 2024 17:23
@satoshiotomakan satoshiotomakan linked an issue Sep 24, 2024 that may be closed by this pull request
Copy link

github-actions bot commented Sep 24, 2024

Binary size comparison

➡️ aarch64-apple-ios: 12.13 MB

➡️ aarch64-apple-ios-sim: 12.14 MB

➡️ aarch64-linux-android: 15.57 MB

➡️ armv7-linux-androideabi: 13.29 MB

➡️ wasm32-unknown-emscripten: 11.03 MB

@10gic
Copy link
Contributor

10gic commented Sep 25, 2024

Hi @vcoolish, glad to see this fixed. Could you provide some test data after the fix?

@vcoolish
Copy link
Contributor Author

Hi @vcoolish, glad to see this fixed. Could you provide some test data after the fix?

attached android and ios data, for JS I couldn't get memory usage increase yet

Copy link
Collaborator

@satoshiotomakan satoshiotomakan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the fix! I have one note

Comment on lines 83 to 86
init {
Thread {
try {
doDeletes()
Copy link
Collaborator

@satoshiotomakan satoshiotomakan Sep 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we spawn a new thread for each instance of HDWallet, AnyAddress etc?
I saw examples do the same, but it's not optimal. What if we have one PhantomReferenceRegistry singleton class that spawns one thread, and AnyAddress.init() and HDWallet.init() just register the nativeHandle with a corresponding delete function.
So the pseudocode will look like:

class AnyAddress {
  init {
        PhantomReferenceRegistry.getOrCreate().register(nativeHandle, TWAnyAddressDelete)
    }
}
class PhantomReferenceRegistry {
  init {
    Thread {
      doDeletes()
    }
  }

  // Sends a pair of `nativeHandle` and `TWAnyAddressDelete(nativeHandle)` to the spawned thread.
  private val channel: Channel<Pair<Long, (Long)>>
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for suggestion, done

Copy link
Collaborator

@satoshiotomakan satoshiotomakan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me!

@satoshiotomakan satoshiotomakan changed the base branch from master to dev October 1, 2024 09:06
@satoshiotomakan satoshiotomakan merged commit 00a8744 into dev Oct 1, 2024
13 checks passed
@satoshiotomakan satoshiotomakan deleted the kmp-leak branch October 1, 2024 10:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[KMP] Memory leak found in AnyAddress
4 participants