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

Stop creating references unnecessarily to compare pointers by-address #452

Merged
merged 1 commit into from
Aug 25, 2024

Conversation

JoJoDeveloping
Copy link
Contributor

@JoJoDeveloping JoJoDeveloping commented Aug 23, 2024

The test common::deque::basics contains several lines that look like this:

assert!(std::ptr::eq(head_d, unsafe { node1_ptr.as_ref() }));

What is happening is that we assert that head_c, a reference, is equal by-address to node1_ptr, a NonNull<_>. However, the way we do this is by creating a reference, instead of using as_ptr.

The current way has several downsides:

  • It requires an unsafe block. Comparing pointer addresses is safe so this should be unnecessary.
  • It is unsound, at least under Tree Borrows rules. The references created there violate the uniqueness of references/Boxes created internally in the Deque, which trips the Deque later when it tries to use these internally-held references.
  • It is unnecessary -- comparing the result of as_ptr works just the same, maybe even faster due to less intermediary methods.

As such, the test should be updated to only use as_ptr. When done, it actually makes the tests pass under Tree Borrows.

See also moka-rs/mini-moka#31

The test `common::deque::basics` contains several lines that look like this:
```
assert!(std::ptr::eq(head_d, unsafe { node1_ptr.as_ref() }));
```

What is happening is that we assert that `head_c`, a reference, is equal
by-address to `node1_ptr`, a `NonNull<_>`. However, the way we do this
is by creating a reference, instead of using `as_ptr`.

The current way has several downsides:
* It requires an `unsafe` block. Comparing pointer addresses is safe so
  this should be unnecessary.
* **It is unsound**, at least under Tree Borrows rules.
  The references created there violate the uniqueness of references/Boxes
  created internally in the `Deque`, which trips the `Deque` later when
  it tries to use these internally-held references.
* It is unnecessary -- comparing the result of `as_ptr` works just the same,
  maybe even faster due to less intermediary methods.

As such, the test should be updated to only use `as_ptr`. When done, it
actually makes the tests pass under Tree Borrows.
Copy link

codecov bot commented Aug 24, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.97%. Comparing base (8854bb1) to head (9a70b56).
Report is 5 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #452      +/-   ##
==========================================
- Coverage   95.04%   94.97%   -0.08%     
==========================================
  Files          44       44              
  Lines       20979    20979              
==========================================
- Hits        19939    19924      -15     
- Misses       1040     1055      +15     

Copy link
Member

@tatsuya6502 tatsuya6502 left a comment

Choose a reason for hiding this comment

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

Thank you for submitting this pull request with detailed explanations! That is very very helpful.

Actually, we are already running CI with miri on the deque and timer_wheel modules. However it did not detect the issue you reported as we only used stacked borrows model. I created another pull request #454 to use tree borrows in the CI in addition to stacked borrows.

@tatsuya6502 tatsuya6502 merged commit fa2a2a1 into moka-rs:main Aug 25, 2024
23 checks passed
@JoJoDeveloping
Copy link
Contributor Author

Thanks for merging, and nice that you use Tree Borrows in your CI 🥳 But be warned that in miri, Tree Borrows currently comes with a performance impact, since there's a bit more to check. While I plan to optimize this further, I can't promise anything. Though if you notice any code that is significantly slower under TB than SB, reach out and I will see what I can do.

Besides, can you also merge the sister PR for mini-moka?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants