JDK-8178352 : BitMap::get_next_zero_offset may give wrong result on Mac
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 9
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2017-04-09
- Updated: 2017-08-25
- Resolved: 2017-05-03
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 10 |
|---|
10 b21Fixed  |
Related Reports
|
Blocks :
|
|
|
Relates :
|
Description
A call to get_next_zero_offset with a constant 0 start index may return the wrong result on Macs. This is because in the statement bm_word_t res = (map(index) >> pos) | left_n_bits((int)pos); the left_n_bits expression gets "miscompiled" due to JDK-8178348. One solution is to fix JDK-8178348. However, a better solution to the BitMap problem is to eliminate the use of left_n_bits. It is being used to replace the high order zeros shifted in by the ">> pos", to avoid confusing the following search for the first zero in res. But a different (and better) approach would be to change that to bm_word_t res = ~map(index) >> pos; and search for the first one in res.
Comments
|