JDK-8191683 : Compile problem on ARM after JDK-8043070
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2017-11-21
  • Updated: 2017-12-15
  • Resolved: 2017-11-22
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 10
10 b36Fixed
Related Reports
Relates :  
JDK-8043070 - nmethod::verify_interrupt_point() shouldn't enter safepoint
Description
On ARM char is unsigned by default, which causes a warning:

/export/boris/openjdk/jdk/src/hotspot/share/code/nmethod.hpp: In member function ���bool nmethod::is_not_installed() const���:
/export/boris/openjdk/jdk/src/hotspot/share/code/nmethod.hpp:319:67: error: comparison is always false due to limited range of data type [-Werror=type-limits]
   bool  is_not_installed() const                  { return _state == not_installed; }

A possible solution would be to declare nmethod::_state signed explicitly.
Comments
Sorry yes bool is 8-bits. So in product mode it would have been the case that 3 bools plus this char fit in 32-bit word. That said, jvmci now inserts a single bool further up so that's likely to waste 24-bits anyway. Anyway simple change to explicit "signed char" seems best fix. Interesting to note vmstructs already assumes signed-ness of char. declare_integer_type(char) !
22-11-2017
Good point, updated. Thanks!
22-11-2017
+ declare_unsigned_integer_type(volatile signed char) should be + declare_integer_type(volatile signed char) ?
22-11-2017
bool is 8 bits though.
22-11-2017
I looked at surrounding fields and couldn't see any obvious reason why char would be of use here. It's surrounded by bools which will all consume an int anyway.
22-11-2017
Webrev: http://cr.openjdk.java.net/~iveresov/8191683/webrev.00/
22-11-2017
To make the structure more compact?
22-11-2017
Why is it a char to begin with? Normal thing would be to use an enum/int.
22-11-2017
I also got this failure. At least, a "signed char" should fix.
22-11-2017