JDK-8043722 : Swapped usage of idx_t and bm_word_t types in parMarkBitMap.cpp
- Type: Bug
- Component: hotspot
- Sub-Component: gc
- Affected Version: 9
- Priority: P5
- Status: Resolved
- Resolution: Fixed
- Submitted: 2014-05-22
- Updated: 2015-01-21
- Resolved: 2014-06-18
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 8 | JDK 9 |
|---|---|
8u40Fixed  |
9 b22Fixed |
Related Reports
|
Relates :
|
Description
From http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-May/014018.html I've created a patch [1] to fix swapped usage of idx_t and bm_word_t types in hotspot/src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp The code currently uses a pointer to idx_t as an argument to BitMap::set_map(bm_word_t* map) which fails on s390. For most platforms the idx_t and bm_word_t types are effectively the same, so the interchange is uncaught, but on s390 (32-bit) the size_t is "unsigned long" which makes it incompatible with "unsigned int".
Comments
|