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

Changing blob to use arc pointers in order to limit wasteful copying … #8860

Merged
merged 1 commit into from Jan 7, 2016

Conversation

@craftytrickster
Copy link
Contributor

craftytrickster commented Dec 6, 2015

Fixes #8801.

Review on Reviewable

// simpler to use version of read_out_buffer
pub fn clone_bytes(&self) -> Vec<u8> {
self.bytes.clone().unwrap_or(vec![])
self.bytes[start..end].to_vec()

This comment has been minimized.

@SimonSapin

SimonSapin Dec 6, 2015

Member

This (.to_vec()) still copies bytes. It looks like this method is used to send Vec<u8> messages, so it probably can’t simply return &[u8] instead.

To reduce copying, the Vec<u8> messages should probably be changed to some reference counted thing. Maybe tendrils? https://github.com/servo/tendril

CC @jdm

This comment has been minimized.

@jdm

jdm Dec 7, 2015

Member

I don't know much about tendril and it doesn't really have any good examples of usage afaict. I'm not sure I see any options here; the websocket library accepts a Vec<u8>, so I believe we're going to have to copy at some point here.

This comment has been minimized.

@jdm

jdm Dec 7, 2015

Member

Hmm, I'm wrong - the library does accept &[u8], so I think we should make this return &[u8] instead.

@jdm
Copy link
Member

jdm commented Dec 7, 2015

So looking at the code in filereader.rs, I see we'll need another change to avoid copying while dealing with slices appropriately. I propose we extract the buffer and slice data into a separate structure (BlobSlice) that can be sent between threads, and has a method that returns the actual slice (-> &[u8]). This struct can be the return value of get_bytes() on Blob. Does that make sense?

@craftytrickster
Copy link
Contributor Author

craftytrickster commented Dec 8, 2015

@jdm that does make sense, I'll see what I can do.

@craftytrickster
Copy link
Contributor Author

craftytrickster commented Dec 8, 2015

I pushed a new test commit to show an approach to avoid using to_vec in the get_bytes method.

However, I do not know if I like the decision to split of the DataSlice/BlobSlice into its own struct, it does not feel very ergonomic to me. I'd prefer to keep those fields in the Blob struct. I guess you can look at the latest commit to see if you agree or not. Also, splitting up the struct caused me to get compiler errors on DataSlice unless I implemented heap_size_of_children and trace. I was not sure how to remove these errors, so for the prototype I just kept empty implementations.

@jdm
Copy link
Member

jdm commented Dec 8, 2015

For what it's worth, that looks like what I was expecting :) I agree that it would be nice to keep the representation of the data within the containing blob, but our current design forbids us from being able to access the internals of JS-owned values (such as Blobs) on other threads.

@bors-servo
Copy link
Contributor

bors-servo commented Dec 8, 2015

The latest upstream changes (presumably #8867) made this pull request unmergeable. Please resolve the merge conflicts.

@craftytrickster craftytrickster force-pushed the craftytrickster:8801/blob-vec branch from cdafb6f to fea9cd9 Dec 9, 2015
@craftytrickster craftytrickster force-pushed the craftytrickster:8801/blob-vec branch 2 times, most recently from d491137 to a280078 Dec 9, 2015
@nox
Copy link
Member

nox commented Dec 10, 2015

@jdm What if we had something like:

pub enum BlobData {
    Owned(Vec<u8>),
    Borrowed(JS<Blob>, usize, usize)
}

This would allow us to actually track the memory usage of the blobs (by making BlobData's HeapSizeOf implementation return 0 for Borrowed values).

@jdm
Copy link
Member

jdm commented Dec 10, 2015

@nox I'm not sure that really helps if the original blob is inaccessible and only the slice is holding it alive.

@Ms2ger
Copy link
Contributor

Ms2ger commented Dec 10, 2015

Another thing to keep in mind is that you can postMessage() a Blob to a worker.

@nox
Copy link
Member

nox commented Dec 10, 2015

@bors-servo
Copy link
Contributor

bors-servo commented Dec 11, 2015

The latest upstream changes (presumably #8922) made this pull request unmergeable. Please resolve the merge conflicts.

@craftytrickster craftytrickster force-pushed the craftytrickster:8801/blob-vec branch from a280078 to 4f33b07 Dec 11, 2015
@craftytrickster
Copy link
Contributor Author

craftytrickster commented Jan 5, 2016

Hi @KiChjang, I am still waiting for any feedback on what needs to be done here. If you have any comments, please let me know


Review status: 0 of 7 files reviewed at latest revision, 1 unresolved discussion.


Comments from the review on Reviewable.io

@craftytrickster
Copy link
Contributor Author

craftytrickster commented Jan 5, 2016

Review status: 0 of 7 files reviewed at latest revision, 1 unresolved discussion.


components/script/dom/blob.rs, line 101 [r1] (raw file):
I am no longer doing to_vec and copying the bytes, I am simply passing a reference to the datsaslice now


Comments from the review on Reviewable.io

@jdm jdm self-assigned this Jan 5, 2016
@jdm
Copy link
Member

jdm commented Jan 5, 2016

Sorry this fell through the cracks!

@jdm
Copy link
Member

jdm commented Jan 5, 2016

This looks like what I expected! There are a couple changes we can make to improve clarity, and I think we might be able to avoid duplicating the blob contents in the websocket code, though.
-S-awaiting-review +S-needs-code-changes


Reviewed 2 of 5 files at r1, 5 of 5 files at r2.
Review status: all files reviewed at latest revision, 5 unresolved discussions.


components/script/dom/blob.rs, line 106 [r3] (raw file):
On second thought, let's extend the new constructor to accept bytes_start and bytes_end instead of duplicating this.


components/script/dom/filereader.rs, line 359 [r3] (raw file):
We don't need a sender and receiver any longer. We can store the result of blob.get_data().clone() in a variable and pass that to perform_annotated_read_operation.


components/script/dom/filereader.rs, line 410 [r3] (raw file):
blob_contents should be a DataSlice value instead of a Receiver.


components/script/dom/websocket.rs, line 389 [r3] (raw file):
Can we get rid of the to_vec here?


Comments from the review on Reviewable.io

@bors-servo
Copy link
Contributor

bors-servo commented Jan 6, 2016

The latest upstream changes (presumably #9160) made this pull request unmergeable. Please resolve the merge conflicts.

@craftytrickster
Copy link
Contributor Author

craftytrickster commented Jan 6, 2016

@jdm thank you for the notes, I will take a look at them when I have time tonight and make the appropriate changes

…ying of byte vector
@craftytrickster craftytrickster force-pushed the craftytrickster:8801/blob-vec branch from 4f33b07 to 76f689c Jan 7, 2016
@craftytrickster
Copy link
Contributor Author

craftytrickster commented Jan 7, 2016

Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.


components/script/dom/blob.rs, line 106 [r3] (raw file):
Originally, I tried that, but I was having issues compiling with the use of "box". It seems to work fine now though, so I was able to remove the duplicated function body.

However, since new implies a fresh object, it seems awkward to have to specified None, None, every single time in the constructor. I think we should still keep a separated new_sliced function to avoid this.

If you do not agree, I can simply converge the new & new_sliced together.


components/script/dom/websocket.rs, line 389 [r3] (raw file):
This is a bit complicated, because we would have to change the net_traits lib.rs file that contains the MessageData enum. It would have to be changed to Blob instead of a Vec in order to avoid using to_vec.

The problem is that we cannot import (script) Blob there, because it would create a circular dependency. I am not sure what you would like to do here. Should we move blob to another crate?


Comments from the review on Reviewable.io

@jdm
Copy link
Member

jdm commented Jan 7, 2016

@bors-servo: r+
Thanks for doing this work!


Reviewed 4 of 4 files at r4.
Review status: all files reviewed at latest revision, 1 unresolved discussion.


components/script/dom/websocket.rs, line 389 [r3] (raw file):
Oh right, I forgot that this became more complicated recently. Nothing we can do here!


Comments from the review on Reviewable.io

@bors-servo
Copy link
Contributor

bors-servo commented Jan 7, 2016

📌 Commit 76f689c has been approved by jdm

@bors-servo
Copy link
Contributor

bors-servo commented Jan 7, 2016

Testing commit 76f689c with merge 0fcee73...

bors-servo added a commit that referenced this pull request Jan 7, 2016
Changing blob to use arc pointers in order to limit wasteful copying …

Fixes #8801.

<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8860)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Jan 7, 2016

💔 Test failed - mac-rel-css

@KiChjang
Copy link
Member

KiChjang commented Jan 7, 2016

@bors-servo
Copy link
Contributor

bors-servo commented Jan 7, 2016

Previous build results for android, gonk, linux-dev, linux-rel, mac-dev-ref-unit, mac-rel-wpt are reusable. Rebuilding only mac-rel-css...

@bors-servo
Copy link
Contributor

bors-servo commented Jan 7, 2016

@bors-servo bors-servo merged commit 76f689c into servo:master Jan 7, 2016
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

8 participants
You can’t perform that action at this time.