JDK-8043723 : max_heap_for_compressed_oops() declared with size_t, but defined with uintx
- Type: Bug
- Component: hotspot
- Sub-Component: gc
- Affected Version: 9
- Priority: P5
- Status: Resolved
- Resolution: Fixed
- Submitted: 2014-05-22
- Updated: 2017-05-24
- Resolved: 2014-05-26
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 | Other |
|---|---|---|
8u40Fixed  |
9 b17Fixed |
openjdk7uFixed |
Description
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".
Comments
|