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.
JDK 8 JDK 9 Other
8u40Fixed 9 b17Fixed openjdk7uFixed
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".

This mixing of types should be cleaned up, even if we don't support s390. ILW=LLH=P5

Patch contributed by Dan Hor��k from RedHat

Assigning to GC because it seems to be related to heap sizing code.