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

Update CachedQuery.java #948

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

LittleWuCoding
Copy link

Fix increaseExecuteCount(int inc) for potential overflows .

Fix increaseExecuteCount(int inc)  for potential overflows .
@@ -42,6 +42,11 @@ public void increaseExecuteCount(int inc) {
if (newValue > 0) { // if overflows, just ignore the update
executeCount = newValue;
}
 else if(executeCount != 0){ //if overflows, comes to here.
Copy link
Member

Choose a reason for hiding this comment

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

Could you please explain:

  1. How can there be two "if (overflows)" branches? (see line 42)
  2. What is the actual issue? I guess overflow condition should already been handled by line 42.

Choose a reason for hiding this comment

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

line 42 is actually "save result if no overflow"

Copy link
Member

Choose a reason for hiding this comment

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

line 42 is actually "save result if no overflow"

So what? Is it good enough?

Copy link
Author

Choose a reason for hiding this comment

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

@vlsi OK, for your question 1 : sorry , I forgot to delete the comment on line 42. Just like @panchenko says, line 42 ~44 only handled the situation of no overflows. For overflows, just thinks about a situation query q1's executeCount is Max_value -3 ,query q2's executeCount is Max_value -2 ,they are both in the cache pool, now q2 increased by 3 or larger and q1 is increase by 2, now the newValue of q2 was turn to be negative number ,so q2's executeCount was unchanged ,but q1's executeCount is Max_value,which is larger than q2's executeCount . That means q1 has Higher opportunities rsesides in Cache. But actually, q2's execution times is more than q1's. This is just a extreme examples, but is shows there must be some problems.
And my patch can ensure that if q2's execution times is more than q1‘s, then q2's ’executeCount will be larger or at least equal to q1's.

Copy link
Member

Choose a reason for hiding this comment

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

A) executeCount is never used for cache eviction policy.
B) executeCount is used only for executeCount > prepareThreshold check. In that regard things around MAX_VALUE do not make any difference
C) If there are queries with MAX_VALUE-2, then they all should better be kept in the cache, so it does not matter if a query has "execute count MAX_VALUE-2 vs MAX_VALUE-3"

Copy link
Author

Choose a reason for hiding this comment

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

@vlsi OK, I missunderstand the code, but what if a query‘s’ initial value is a very small integer(less than prepareThreshold) , but the parameter inc of function increaseExecuteCount(int inc) is a big one ,their sum is overflows, in that way, this query's executeCount unchanged, With a high execution times ,this query may not be prepared, is it a problem?
Anyway, I am happy to discuss it with you~

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.

None yet

3 participants