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.
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
Core: Limit memory used by ParallelIterable #10691
Core: Limit memory used by ParallelIterable #10691
Changes from 10 commits
6967388
ec4c52f
c561cc4
84de5fc
fc1c734
984473d
6102802
3a0d6ca
4ab1c01
fd0a261
6258455
b716bfc
1ffdf3a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
The
mayInterruptIfRunning
flag has no effect inCompletableFuture
, so I guess it's possible the thread cannot be released here?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 thought the if check here only prevents restarting continuations too early by skipping the
checkTasks
later in the method?To prevent resuming too late, we need to reduce the
Thread.sleep(10)
?I feel bulk this comment section might be better to move to method Javadoc. add a comment right before the
if
check to preventing resuming too early?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 think there is a lot we can change about this code. I don't like the fact that method called "check tasks" has side-effect of scheduling new tasks. I also don't like the fact we do thread sleep. At minimum, the sleep should be interrupted when new item is put into the queue.
however, i wanted to avoid doing too many changes in single PR. I thought it's generally discouraged.
@stevenzwu would be OK to consider the sleep(10) to be pre-existing and not address now? Or do you think this sleep, when combined with changes introduced in this PR, has overall more negative effect that it used to be?
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.
sorry for the confusion. I didn't mean to change the sleep. I was mainly talking about the code comment, which seems mainly about "resume too early"
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.
Why is this a local variable? if it is a constant it could be a final field.
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 a variable, so it has a name, which is aimed at help understanding what's going on.
maxQueueSize is a configuration parameter. queueLowWaterMark can indeed be a field, i am not convinced it would increase readability, because the usage and the value formulae would be separated.
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 think either way doesn't affect readability. but since it is static, it might be a little bit to set in the constructor as a final field.
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.
technically, it's not static. this is a constructor parameter. the static field serves as a default.
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.
static is probably the wrong world. it is a constant for the object and could be a class field just like
maxQueueSize
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.
re this being class static field -- currently this is instance parameter, the constant serves only as a default
re this being class non-static (instance) field -- i replied to this in #10691 (comment). let me know what you think about this.
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.
@findepi, I think by "static" Steven meant "does not change" rather than Java's
static
. This is minor, but we don't typically want to recalculate a value in every method call if it can be set when the instance is created. The name isn't the problem, it is that this doesn't need to be recalculated every call.