-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-15246][Core] Fix code style and improve volatile for SPARK-4452 #13020
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
Conversation
|
|
||
| // Number of elements read from input since last spill | ||
| @volatile protected def elementsRead: Long = _elementsRead | ||
| protected def elementsRead: Long = _elementsRead |
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.
can you comment on why the changes are safe/correct?
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.
It has only one thread to use this method. So we can remove volatile.
|
cc @davies |
| if (!isSpilled) { | ||
| 0L | ||
| } else { | ||
| _elementsRead = 0 |
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 delete this code in order to _elementsRead is called by one thread. So we do not need to make _elementsRead volatile.
|
Is this really an hot fix (serious bug or breaking tests)? |
|
@davies I think it is not an hot fix. So i have updated PR. thanks. |
|
Test build #58203 has finished for PR 13020 at commit
|
|
LGTM |
| protected def forceSpill(): Boolean | ||
|
|
||
| // Number of elements read from input since last spill | ||
| @volatile protected def elementsRead: Long = _elementsRead |
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.
It's not meaningful to make a method volatile anyway right? the fact that it's not an error makes me think I could be missing something. No objection
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.
Yes, I think you understand correctly. we can remove volatile of elementsRead method because there is only one thread to use it.
|
Merging in master/2.0. Thanks. |
## What changes were proposed in this pull request? 1. Fix code style 2. remove volatile of elementsRead method because there is only one thread to use it. 3. avoid volatile of _elementsRead because Collection increases number of _elementsRead when it insert a element. It is very expensive. So we can avoid it. After this PR, I will push another PR for branch 1.6. ## How was this patch tested? unit tests Author: Lianhui Wang <[email protected]> Closes #13020 from lianhuiwang/SPARK-4452-hotfix. (cherry picked from commit 9f0a642) Signed-off-by: Reynold Xin <[email protected]>
What changes were proposed in this pull request?
After this PR, I will push another PR for branch 1.6.
How was this patch tested?
unit tests