-
Notifications
You must be signed in to change notification settings - Fork 406
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
Remove MemorySpace::[de]allocate overloads without labels #6835
base: develop
Are you sure you want to change the base?
Remove MemorySpace::[de]allocate overloads without labels #6835
Conversation
4838e38
to
7965fc0
Compare
7965fc0
to
ee43803
Compare
Should these |
Yeah, that's up for debate. For me, they are implementation details but of course they could be used somewhere. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the need for a discussion for a potential deprecation, looks good to me.
Let me add a commit with the deprecations. |
3998a0c
to
2cca334
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since when do we have these MemSpace::[de]allocate
overload with a label vs the ones w/o a label?
What is problematic about having both?
Why is requiring a label the right thing to do?
The version with labels was introduced in #3084. The one without labels was the only overload before that.
There doesn't seem to be a good case where you cannot provide a meaningful label. We require a label for
This pull request is motivated by #6794 (comment). It's very hard to understand Kokkos Tools output for allocation/deallocation events if the label is omitted. In that issue, we were trying to hunt down a specific deallocation that made a test introspecting Tools events fail (since there was an unexpected fence). With the changes in this pull request, we would have caught the offending deallocation directly. |
2cca334
to
f7e0122
Compare
…ace_allocate_without_labels
81efbd9
to
1714060
Compare
f610030
to
ea10a4b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am blocking for now. I am not sure I agree with removing the allocate function without label. I am even less sure I agree with removing the deallocate function with label - since it means that a user has to track the label around somewhere. And what would it mean to provide a different label at deallocate than was used on allocate.
@masterleinad , @crtrott -- on the agenda for discussion |
I noticed in #6794 (comment) that we call
MemorySpace::deallocate
without a label only from internal allocations where we can do better.Thus, this pull request suggests streamlining the interface by removing all overloads for
MemorySpace::[de]allocate
that don't take a label and attempts to include labels KokkosTools events in allocate and deallocate.So far, I only made sure to provide labels forSYCL
in all places that need them now.This also mirrors better what we do for
View
allocations anyway, i.e., we force the user to provide a label when allocating. The label is passed implicitly when deallocating whereas here it is explicit (since we also don't store it in SharedAllocationRecord or the like).