-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b51
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8025376 | 8 | Thomas Schatzl | P4 | Resolved | Fixed | b109 |
JDK-8024959 | hs25 | Thomas Schatzl | P4 | Resolved | Fixed | team |
The code in hotspot/src/share/vm/utilities/bitMap.inline.hpp
incorrectly swaps the usage of the idx_t and bm_word_t types. For most
platforms these 2 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". The patch is result of my
understanding of the logic inside bitMap.inline.hpp, so it needs
definitely a review although I think I'm right :-) The same patch is
used in our openjdk7 Fedora packages and the code compiles and works
without issue on both s390 and s390x architectures there.
from bitmap.hpp
typedef size_t idx_t; // Type used for bit and word indices.
typedef uintptr_t bm_word_t; // Element type of array that represents
// the bitmap.
- backported by
-
JDK-8024959 Swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp
-
- Resolved
-
-
JDK-8025376 Swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp
-
- Resolved
-
- duplicates
-
JDK-8024959 Swapped usage of idx_t and bm_word_t types in bitMap.inline.hpp
-
- Resolved
-
- relates to
-
JDK-8043722 Swapped usage of idx_t and bm_word_t types in parMarkBitMap.cpp
-
- Resolved
-