improve memory usage for hostTrackData #431
Open
+49
−11
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR improves the data usage of the HostTrackData.
Before, when tracks were deleted, the g4idToGPUid map could not be cleaned as it is still needed if a track goes from GPU to CPU to GPU. In that case, we have to ensure that the second time the track goes to the GPU it has the same track ID as the first time, as the track ID is used to seed the RNG. However, when the track is killed, we can safely delete all of it. Now, we have two functions, one to fully remove a track from the hostTrackData when the track is killed and one to "retire" it to the CPU so that we keep the g4idToGPUid in case the CPU decides to put the track back on the GPU. This is only needed in case the of a out-of-gpu-region leak.
Also, a destructor is added to clean all data, as before the data was only cleaned upon a new event, leading to a memory leak