-
Bug
-
Resolution: Unresolved
-
P3
-
25
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"
- caused by
-
JDK-8351594 JFR: Rate-limited sampling of Java events
-
- Resolved
-