| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8063513 | 8u45 | Thomas Schatzl | P5 | Resolved | Fixed | b01 |
| JDK-8049593 | 8u40 | Thomas Schatzl | P5 | Resolved | Fixed | b01 |
| JDK-8070798 | emb-8u47 | Thomas Schatzl | P5 | Resolved | Fixed | team |
| JDK-8180974 | openjdk7u | Thomas Schatzl | P5 | Resolved | Fixed | master |
From http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-May/014020.html
I've created a patch [1] to fix usage of uintx where size_t type is
expected in hotspot/src/share/vm/runtime/arguments.cpp
The Arguments::max_heap_for_compressed_oops() method is declared in
arguments.hpp as
size_t max_heap_for_compressed_oops()
but later defined in arguments.cpp as
uintx max_heap_for_compressed_oops()
For most platforms the uintx and size_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 usage of uintx where size_t type is
expected in hotspot/src/share/vm/runtime/arguments.cpp
The Arguments::max_heap_for_compressed_oops() method is declared in
arguments.hpp as
size_t max_heap_for_compressed_oops()
but later defined in arguments.cpp as
uintx max_heap_for_compressed_oops()
For most platforms the uintx and size_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-8049593 max_heap_for_compressed_oops() declared with size_t, but defined with uintx
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-