JDK-8046938 : Using mixed types in MIN2/MAX2 functions causes build problems on s390 (32-bit)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2014-06-16
  • Updated: 2018-05-17
  • Resolved: 2016-05-02
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 9
9.1Resolved
Related Reports
Blocks :  
JDK-8074459 - Flags handling memory sizes should be of type size_t
Duplicate :  
JDK-8074459 - Flags handling memory sizes should be of type size_t
Relates :  
JDK-8203030 - Zero s390 31 bit size_t type conflicts in shared code
Description
The MIN2/MAX2 functions are implemented using templates and require both arguments to be of the same type. This is a problem when one parameter is of size_t type and the second of uintx type and the platform has size_t defined as eg. unsigned long as on s390 (32-bit).

A solution is to typecast the smaller type (uintx) to size_t which is of the same or larger size.
Comments
With no other information at hand I'll assume that JDK-8074459 fixed the issues. Please reopen if there are more problems related to this.
02-05-2016
How much of the original problem still exists now when JDK-8074459 has been fixed?
30-03-2015
A few more comments from the discussion: "The discussion back in July suggested that a large fraction of the problem cases were in argument processing, where size_t wasn���t supported, so some option values that were semantically sizes were being captured in uintx values and then later being compared with size_t values." "The solution is not to get rid of uintx as such. Instead I think the right approach is to go through our code and make sure that we use appropriate types in all places. The fact that we want to compare values of different types indicate that we are either using the wrong types or have a possible bug lurking. The goal should probably be to get rid of the usage of uintx as far as possible, but not necessarily get rid of the type." It is now possible to use size_t for flags so the next step here should be to invetsigate if changing flags that have the wrong type today to be of size_t, and see if that solves the problematic cases seen on s390.
10-02-2015
After some internal discussions it seems that switching to use size_t all over instead of uintx is not an option. A few qoutes from the discussion: "If you do a quick look at src/share/vm/runtime/globals.hpp there are some variables declared as uintx that wouldn't make sense declared as size_t because they aren't measurements in size of anything. So even if they are the same size, these type names mean something different." "IMHO, this can lead to other issues. size_t is interpreted differently on a lot of platforms and I've had issue with it on embedded platforms. The problem here seems to be that size_t is bigger than uintx on that platform. Unfortunately, for platforms where size_t is bigger, using size_t may have a direct impact on the availability of atomic instructions to update the corresponding values. " "size_t could be almost any size it depends to OS and platform. So bulk change of uintx to size_t is extremely dangerous."
09-02-2015
Isn't the whole issue here that uintx and size_t may not be the same size on some platforms?
09-02-2015
Hi Jesper, I think it will work, both uintx and size_t are the same size (32-bits), so there shouldn't be any functional change.
26-01-2015
Jesper, I've reached out to Dan Horak in order to get your question answered. He'll get back to you once his OpenJDK authorship is done (hopefully soon).
16-01-2015
Severin, I guess you could shed some light on whether it's possible to replace uintx with size_t throughout the code base. Would that work for the s390 platform?
15-01-2015
Thanks for the update Jesper!
15-01-2015
JFYI: The bug is assigned to me since the developer doing the actual work (Dan Hor��k) does not have an JBS account yet. A short summary of the discussion: The latest webrev is here: http://cr.openjdk.java.net/~jwilhelm/8046938/webrev/ This looks OK to me but as pointed out in the thread it is a fragile solution since it doesn't prevent this problem from being re-introduced in later changes. Kim suggested the use of a template to deal with the problem more permanently but the general opinion among Hotspot developers has been a bit negative to templates. This might have changed, but just recently other changes has been rejected due to the more complicated uses of templates. One approach that has been discussed offline is to simply remove the type uintx and use size_t all over. I haven't investigated if this is a viable solution yet.
15-01-2015
References to review threads so far: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-June/014254.html http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-July/014789.html It seems progress has been stalled since July. Thoughts?
13-01-2015