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

refactor: remove Isolate.shared_response_buf #3759

Merged
merged 3 commits into from
Jan 23, 2020

Conversation

bartlomieju
Copy link
Member

@bartlomieju bartlomieju commented Jan 23, 2020

Removed Isolate.shared_response_buf.

Currently we have a pretty complex situation when responding from Rust to V8 when shared queue overflows, covered by those three cases:
a) response is bigger than shared_response_buf (1Mb) - create new ArrayBuffer
b) shared_response_buf has not been instantiated - lazy instantiate it
c) response fits into shared_response_buf - use it

Instead I rewrote this situation to always transfer memory from Rust to V8, ie. always create new ArrayBuffer and set it's backing store to underlying Rust-allocated memory.

@bartlomieju bartlomieju requested a review from ry January 23, 2020 09:08
core/bindings.rs Outdated Show resolved Hide resolved
Copy link
Member

@ry ry left a comment

Choose a reason for hiding this comment

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

@bartlomieju LGTM - this is a very very nice clean up - thank you! I'm so glad to be rid of these complex pseudo optimizations.

I would have expected a speed improvement in isolate::tests::overflow_res_sync (and the other overflow tests), but that doesn't seem to have happened. I don't understand this. Nevertheless, I think you've successfully made it so that the return buffers from ops are zero-copy.

@ry ry merged commit 5a658a2 into denoland:master Jan 23, 2020
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.

None yet

2 participants