You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've seen a common pattern emerging where plugin authors will call proxy_get_buffer_bytes with a specific length in mind, do something with the buffer, then clear all buffers when returning from the callback.
By allowing authors to pass a pre-allocated buffer, we'd permit plugin authors to stack-allocate this memory, which is cheaper to manage than heap allocating. In the case of garbage collected languages, such as Go, this would allow us to completely bypass the garbage collector.
Furthermore, this approach can provide plugin authors significantly more control over the memory usage when using garbage collected languages, since the contents of the buffer are guaranteed to be freed at the end of the callback (and individual callbacks in a thread local vm are guaranteed non-concurrent).
The text was updated successfully, but these errors were encountered:
We've seen a common pattern emerging where plugin authors will call proxy_get_buffer_bytes with a specific length in mind, do something with the buffer, then clear all buffers when returning from the callback.
By allowing authors to pass a pre-allocated buffer, we'd permit plugin authors to stack-allocate this memory, which is cheaper to manage than heap allocating. In the case of garbage collected languages, such as Go, this would allow us to completely bypass the garbage collector.
Furthermore, this approach can provide plugin authors significantly more control over the memory usage when using garbage collected languages, since the contents of the buffer are guaranteed to be freed at the end of the callback (and individual callbacks in a thread local vm are guaranteed non-concurrent).
The text was updated successfully, but these errors were encountered: