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.
7u141Fixed 8u131Fixed 9 b143Fixed
Related Reports
Blocks :  
Blocks :  
Relates :  
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 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
Updated patch to fix code format.

Proposed solution

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.

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.

Not being able to run Java inside a correctly configured LDOM would seem to be a P2 bug, at least