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

Move kmath-memory into a separate project #432

Open
altavir opened this issue Nov 9, 2021 · 4 comments
Open

Move kmath-memory into a separate project #432

altavir opened this issue Nov 9, 2021 · 4 comments
Labels
feature A new feature request good first issue The issue awaits its hero. Contributions are welcome

Comments

@altavir
Copy link
Member

altavir commented Nov 9, 2021

Create a separate project for low-level multiplatform memory management. Let's call it memory.kt.
Implement several memory backends:

  • ByteBuffer for JVM
  • WebGL buffers for JS
  • ByteArray for Native
  • JEP 393 foreign memory support for JVM (Implement Memory using JEP-370 #83). Additional module with JDK 17 target.

The following features should be present:

  • Random access primitive read
  • Random access primitive write
  • Separate lifecycle handlers for readers and writers (control that only one writer could exist at a given time).
  • [Optional] Freeze access on borrow via coroutines like suspend fun Memory.borrow{ block: Memory.()->Unit} to pass it to other code or external process
  • [Optional] Kotlinx-serialization infrastructure to perform operations directly on memory (could be useful for ktor-io).
@NorbertSandor
Copy link

As I see this is already implemented, is it? Thanks.

@altavir
Copy link
Member Author

altavir commented Jul 18, 2022

No, it is not. @CommanderTvis started working on this, but It is not finished. I have some ideas, but it requires a lot of research to understand how it should work and what benefits it has. For example I have an idea about using a Buffer/Matrix/Tensor algebra based on manual memory layout with pooling/nogc implementation of the Memory. But sadly I have no time for it now. All ideas and contributions are welcome.

@NorbertSandor
Copy link

@altavir Thanks, but the more I dive into the requirements of the "waiting for a hero" issues, the more I see that these are at another level :D

@altavir
Copy link
Member Author

altavir commented Jul 18, 2022

Yep, it is a research library. It is requires a lot of thinking. For straight cases I would start with #405 or #66

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A new feature request good first issue The issue awaits its hero. Contributions are welcome
Projects
None yet
Development

No branches or pull requests

2 participants