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

Make list_formatter data *almost* zero-copy #1680

Merged
merged 2 commits into from
Mar 14, 2022

Conversation

Manishearth
Copy link
Member

@Manishearth Manishearth commented Mar 9, 2022

Unfortunately, this cannot be 100% non-allocating due to the DFA::from_bytes() used for verification. I'm not sure what to do about that, technically the data is still zero-copy (and this can be done in a crab-bake-kosher way) but our tool will still complain.

Might be worth allowlisting it for allocating exactly 1408 bytes.

Part of #1678

@Manishearth Manishearth requested review from sffc and a team as code owners March 9, 2022 01:47
@Manishearth Manishearth requested review from robertbastian and sffc and removed request for a team and sffc March 9, 2022 01:48
@sffc
Copy link
Member

sffc commented Mar 9, 2022

Unfortunately, this cannot be 100% non-allocating due to the DFA::from_bytes() used for verification. I'm not sure what to do about that, technically the data is still zero-copy (and this can be done in a crab-bake-kosher way) but our tool will still complain.

Perhaps we can make an upstream contribution to make the verification be zero-alloc.

Might be worth allowlisting it for allocating exactly 1408 bytes.

Alternatively, could we add a flag to weaken the assertion from total bytes the same to current bytes the same, allowing for intermediate allocations during the deserialization process?

@Manishearth
Copy link
Member Author

I was thinking about that, I kinda prefer us obviating all allocations but I'm not against sticking to the "current" thing.

As far as upstream goes, I had a look, the problem is that they need to allocate a BTreeMap to do the check. Maybe there's a way around it.

@sffc
Copy link
Member

sffc commented Mar 9, 2022

I was thinking about that, I kinda prefer us obviating all allocations but I'm not against sticking to the "current" thing.

We should enforce "no allocations whatsoever" by default, but switching to "no net allocations" could be an alternative to the allowlist.

@Manishearth
Copy link
Member Author

sounds good, I've already updated that PR so that it measures both (but still uses total)

We should get that landed and iterate on that allowlist here

robertbastian
robertbastian previously approved these changes Mar 9, 2022
Copy link
Member

@robertbastian robertbastian left a comment

Choose a reason for hiding this comment

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

Ah good catch, we wouldn't have noticed this if we just checked for borrow annotations.

@Manishearth
Copy link
Member Author

(or get this landed first and add the allowlist there, either works for me)

@jira-pull-request-webhook
Copy link

Notice: the branch changed across the force-push!

  • tools/datagen/src/bin/verify-zero-copy.rs is now changed in the branch

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

@Manishearth
Copy link
Member Author

@sffc We now have two allowlists here

sffc
sffc previously approved these changes Mar 11, 2022
@jira-pull-request-webhook
Copy link

Notice: the branch changed across the force-push!

  • components/list/Cargo.toml is now changed in the branch
  • components/list/src/string_matcher.rs is now changed in the branch
  • experimental/list_formatter/Cargo.toml is no longer changed in the branch
  • experimental/list_formatter/src/string_matcher.rs is no longer changed in the branch

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

@Manishearth Manishearth requested a review from sffc March 12, 2022 23:22
@Manishearth Manishearth merged commit e8562c1 into unicode-org:main Mar 14, 2022
@Manishearth Manishearth deleted the list-zc branch March 14, 2022 17:26
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.

4 participants