JDK-8165482 : java in ldoms, with cpu-arch=generic has problems
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: sparc
  • Submitted: 2016-09-06
  • Updated: 2018-02-08
  • Resolved: 2016-10-18
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 7 JDK 8 JDK 9
7u141Fixed 8u131Fixed 9 b143Fixed
Related Reports
Blocks :  
JDK-8157141 - Fix for JDK-8031290 is unnecessarily fragile
Blocks :  
JDK-8164002 - Add a new CPU family (S_family) for SPARC S7 and above processors
Relates :  
JDK-8177958 - Possible uninitialized char* in vm_version_solaris_sparc.cpp
Description
when running jdk9, inside an ldom, where the ldom was created with
ldm set-domain cpu-arch=generic
or cpu-arch=migration-class1

the kstat info for the cpu type is set to sun4v-cpu, which java does not know about.

./java
Java HotSpot(TM) 64-Bit Server VM warning: Can't parse CPU implementation = 'SUN4V-CPU', assume generic SPARC
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/vm_version_sparc.cpp:433
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/u01/andyb/jdk9/hotspot/src/cpu/sparc/vm/vm_version_sparc.cpp:433), pid=2248, tid=2
#  assert(is_T_family(features) == is_niagara(features)) failed: Niagara should be T series

the platform is actually a T4
Comments
Updated patch to fix code format.
04-10-2016
Proposed solution
19-09-2016
Agreed, this needs looking at with old cruft being removed. This should be filed as a separate cleanup issue. In the short term, a possible fix is to utilise the prom to attempt to identify the CPU type. This, in combination with the existing mechanisms, should yield the correct result, even in the case above.
19-09-2016
Currently the JVM uses a mix of kstats, picl, sysconf, sysinfo, getisax and possibly others as well to determine the Solaris platform it is running on. This bug could be worked around by just adding in sun4v-cpu as a supported CPU type but it is probably time to take a fresh look at the way the JVM determines which Solaris sort of Solaris platform it is on. The JVM code in this area could be significantly simplified, for example, as Java has a dependency on a minimum Solaris version, there is no point supporting hardware in the JVM that isn't supported any longer by the underlying OS.
06-09-2016
Not being able to run Java inside a correctly configured LDOM would seem to be a P2 bug, at least
06-09-2016