-
Bug
-
Resolution: Fixed
-
P3
-
25
-
b06
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8362048 | 25.0.1 | Erik Gahlin | P3 | Resolved | Fixed | b02 |
| JDK-8361419 | 25 | Erik Gahlin | P3 | Resolved | Fixed | b31 |
SonarCloud points out that these two should probably be computed in longs:
public static final long MASK_THROTTLE = 1 << 62;
public static final long MASK_THROTTLE_CHECK = 1 << 63;
They indeed look like setting a single bit. Yet, since original `1` is int, this computes in int domain, which either sets a wrong bit due to wrap-around, or sets up for an awkward sign extension in later int-to-long promotion.
Observe:
jshell> Long.toHexString(1 << 62)
$1 ==> "40000000"
jshell> Long.toHexString(1 << 63)
$2 ==> "ffffffff80000000"
...while the correct behavior is likely:
jshell> Long.toHexString(1L << 62)
$3 ==> "4000000000000000"
jshell> Long.toHexString(1L << 63)
$4 ==> "8000000000000000"
public static final long MASK_THROTTLE = 1 << 62;
public static final long MASK_THROTTLE_CHECK = 1 << 63;
They indeed look like setting a single bit. Yet, since original `1` is int, this computes in int domain, which either sets a wrong bit due to wrap-around, or sets up for an awkward sign extension in later int-to-long promotion.
Observe:
jshell> Long.toHexString(1 << 62)
$1 ==> "40000000"
jshell> Long.toHexString(1 << 63)
$2 ==> "ffffffff80000000"
...while the correct behavior is likely:
jshell> Long.toHexString(1L << 62)
$3 ==> "4000000000000000"
jshell> Long.toHexString(1L << 63)
$4 ==> "8000000000000000"
- backported by
-
JDK-8361419 JFR: EventInstrumentation MASK_THROTTLE* constants should be computed in longs
-
- Resolved
-
-
-
- Resolved
-
- caused by
-
JDK-8351594 JFR: Rate-limited sampling of Java events
-
- Resolved
-
- links to
-
Commit(jdk25)
openjdk/jdk/8707167e
-
Commit(master)
openjdk/jdk/77e69e02
-
Review(jdk25)
openjdk/jdk/26126
-
Review(master)
openjdk/jdk/26028
(2 links to)