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

Store label in SharedAllocationRecord #4647

Merged
merged 4 commits into from
Jan 6, 2022

Conversation

masterleinad
Copy link
Contributor

@masterleinad masterleinad commented Jan 6, 2022

Fixes #2029. Supersedes #4615.

@masterleinad masterleinad marked this pull request as ready for review January 6, 2022 17:28
@masterleinad masterleinad linked an issue Jan 6, 2022 that may be closed by this pull request
@masterleinad
Copy link
Contributor Author

masterleinad commented Jan 6, 2022

Storing the labels in SharedAllocationRecord additionally seems to also fix the broken tests in TestEventCorrcetness.hpp.

Copy link
Member

@dalg24 dalg24 left a comment

Choose a reason for hiding this comment

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

Pleas expand the description. The original issue consider multiple options. Make it clear which one you implemented.

@@ -149,7 +150,7 @@ class SharedAllocationRecord<void, void> {
SharedAllocationRecord* arg_root,
#endif
SharedAllocationHeader* arg_alloc_ptr, size_t arg_alloc_size,
function_type arg_dealloc);
function_type arg_dealloc, const std::string& label);
Copy link
Member

Choose a reason for hiding this comment

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

Consider taking it by value and moving it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In most (all?) cases, we obtain the label as a const std::string& already so I opted for passing by const std::string& here, too. If there are other good reasons to rather pass by value and move, I am happy to adapt, of course.

Copy link
Contributor

Choose a reason for hiding this comment

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

As written, there's guaranteed to be a copy into the ultimate m_label member.

In the common case where the label is coming from some temporary object, Damien's suggestion will allow the compiler to do elision, and construct the temporary directly into the function argument, which will then get inexpensively moved from.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree with that but we never pass a temporary object here.
Anyway, if anyone requests changes, I will change.

@masterleinad
Copy link
Contributor Author

This implements #2029 (comment), i.e we are storing the label additionally/redundantly in SharedAllocationRecord.

@crtrott crtrott merged commit ff4db53 into kokkos:develop Jan 6, 2022
@masterleinad masterleinad deleted the replace_label branch January 7, 2022 19:56
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.

Don't keep labels in device allocation
4 participants