| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8063514 | 8u45 | Thomas Schatzl | P5 | Resolved | Fixed | b01 |
| JDK-8049594 | 8u40 | Thomas Schatzl | P5 | Resolved | Fixed | b01 |
| JDK-8070799 | emb-8u47 | Thomas Schatzl | P5 | Resolved | Fixed | team |
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".
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".
- backported by
-
JDK-8049594 Swapped usage of idx_t and bm_word_t types in parMarkBitMap.cpp
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
JDK-8024914 Swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp
-
- Resolved
-