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

Adding Arena Allocator? #4434

Closed
s3rj1k opened this issue Aug 24, 2024 · 6 comments
Closed

Adding Arena Allocator? #4434

s3rj1k opened this issue Aug 24, 2024 · 6 comments

Comments

@s3rj1k
Copy link

s3rj1k commented Aug 24, 2024

Adding a first-class support for memory arenas could possibly benefit in avoiding some of GC issues especially present in WASM.

@aykevl
Copy link
Member

aykevl commented Aug 24, 2024

I don't see how an arena allocator can possibly be used safely in Go. Go is a garbage collected language, so if any outside objects have a pointer to an object inside the arena that will become a dangling pointer after freeing the arena.

I can't prevent anybody from shooting themselves in the foot, but I don't think this is something we're going to add to TinyGo to be honest.

A better solution in my opinion would be to improve the GC itself. For example, I've been working on adding the (very well tuned) Boehm GC to TinyGo: #4385
It will take some work to also get it working correctly on WebAssembly (WebAssembly is a difficult system), but I don't see any fundamental blockers why it couldn't work.

@s3rj1k
Copy link
Author

s3rj1k commented Aug 24, 2024

@aykevl What about support of explicit free for some allocation, so that most of the work is GC based but for some specific cases manual memory management?

(feel free to close the issue in any case, thanks)

@aykevl
Copy link
Member

aykevl commented Aug 26, 2024

Can you describe your use case?
Is it perhaps large areas of pointer-free memory that are slow?

@aykevl aykevl closed this as not planned Won't fix, can't repro, duplicate, stale Aug 26, 2024
@s3rj1k
Copy link
Author

s3rj1k commented Aug 26, 2024

Can you describe your use case?

Mainly WASM binaries for web server custom filters.

ref: https://github.com/tetratelabs/proxy-wasm-go-sdk

According to the above project, one of major issues is GC in WASM.
So I was thinking that having some kind of opt-in manual memory management could help.

@aykevl
Copy link
Member

aykevl commented Aug 27, 2024

Hmm, okay. I have seen that comment, but I haven't experienced those issues myself. GC is a known issue in WebAssembly because WebAssembly doesn't allow scanning the stack so it's always going to be less efficient. I hope to make it at least a bit more efficient with bdwgc. Or, maybe, it will be possible in the future to use the built-in WebAssembly GC (which is currently entirely unsupported in LLVM so right now is impossible to implement).

@s3rj1k
Copy link
Author

s3rj1k commented Aug 27, 2024

Yea I understand that issue is basically on WASM side, this will be an issue for all languages that use GC in some way, Kotlin native probably has similar issues with WASM and GC.

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

No branches or pull requests

2 participants