Copied from JDK-8306331, regarding Parse::dynamic_branch_prediction():
... this code could handle saturated values better. The BranchData and JumpData counters are stored as uint and saturate at 0xffffffff, while scale_count() counters and return value use int and saturate at 0x7fffffff. We should be able to make a meaningful comparison between "taken" and "not_taken" paths with raw counter values up to 0xfffffffe, but the current code loses information converting to int. Also, the current code limits the sum of taken + not_taken to <= 0x7fffffff even if neither value is saturated. Finally, it seems like we should be able to compare 0 on one path to "saturated" on the other path, but again the current code doesn't allow that because a raw 0xffffffff saturated value becomes negative and is rejected.
See also Kim's suggestion inJDK-8306331 for using INT_MAX/2 as the saturated value.
... this code could handle saturated values better. The BranchData and JumpData counters are stored as uint and saturate at 0xffffffff, while scale_count() counters and return value use int and saturate at 0x7fffffff. We should be able to make a meaningful comparison between "taken" and "not_taken" paths with raw counter values up to 0xfffffffe, but the current code loses information converting to int. Also, the current code limits the sum of taken + not_taken to <= 0x7fffffff even if neither value is saturated. Finally, it seems like we should be able to compare 0 on one path to "saturated" on the other path, but again the current code doesn't allow that because a raw 0xffffffff saturated value becomes negative and is rejected.
See also Kim's suggestion in
- relates to
-
JDK-8306331 assert((cnt > 0.0f) && (prob > 0.0f)) failed: Bad frequency assignment in if
-
- Resolved
-