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

Free JS slices arguments after use? #111

Closed
francisbouvier opened this issue Oct 6, 2023 · 0 comments · Fixed by #142
Closed

Free JS slices arguments after use? #111

francisbouvier opened this issue Oct 6, 2023 · 0 comments · Fixed by #142
Milestone

Comments

@francisbouvier
Copy link
Member

When we need to handle JS arguments who are slices (string are slices, but we have also variadic arguments and arrays), we need to allocate them on the heap, before filling it with the JS values translated in Zig.

Right now those slices are not free after calling the API function.

We can free them automatically easily, right after the function call.
The good thing if we do so is that we use less memory.
The bad thing is that the API function will have the responsibility to duplicate them (ie. allocate), if needed.

It's not a problem per se, as the API function has already the possibility to ask an allocator in its arguments.
It's just something that the API function will be responsible of.

For example if a setter User.set_name(name: []const u8) takes a string, it can now just save the string in its internal fied, without worring about it.
With this change the setter signature will be User.set_name(alloc: std.mem.Allocator, name: []const u8) and the function will have to copy/duplicate the slice, only if it want to keep it for further usage of course.

The good thing of leaving the responsability to the API is that duplication (ie. allocation) will not be systematic: sometimes a function just want a slice to do some logic without storing it.
For example document.createElement(tag_name: []const u8) will not store the tag name, just using it to process the element creation. So in this case the change will reduce memory consumption.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant