RFR: JDK-8157141 & JDK-8166454: Solaris getisax(2) and meminfo(2) cleanup

[Alan Burlison]

On 27/09/2016 00:54, David Holmes wrote:

> Thanks Alan. It is the creation of the intermediate log-stream that can
> not be accomplished at this stage of VM initialization so we will need
> to stick with what you had. Thanks for trying.

Done. I've tweaked the output slightly, it is now:

torside-kz6$ ./java -Xlog:os+cpu -version
[0.177s][info][os,cpu] getisax(2) returned 1 words:
[0.177s][info][os,cpu]     word 1: 0x3ffe8df0

That's on a M5, on a T7 and similar it will be 2 words. I've respun the 
webrev, for reference here are the review links again:

getisainfo() manpage:
http://docs.oracle.com/cd/E53394_01/html/E54765/getisax-2.html

meminfo() manpage:
https://docs.oracle.com/cd/E53394_01/html/E54765/meminfo-2.html

Bugs:   https://bugs.openjdk.java.net/browse/JDK-8157141
         https://bugs.openjdk.java.net/browse/JDK-8166454
Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8157141%2bJDK-8166454/

A JPRT hotspot testset run is clean.

In the first review there was this question from Kim:

> The use of getisax with an empty array to determine how many elements
> to allocate for a real call doesn't obviously follow from the
> referenced documentation.  "... returns the number of array elements
> that contain non-zero values." suggests to me that it should be no
> greater than the "n" (second) argument and could be less, as it is the
> number of non-zero elements in the first (array) argument that is
> returned. Perhaps that's a bug in the documentation?

It is indeed a bug in the Solaris documentation. I've added a 
clarification to the original Solaris engineering case and logged a 
Solaris manpage bug (24716290) to clear that up.

I've also taken the opportunity to strip out most of the '#ifndef(FOO)' 
probes for the HW capability bit macros in vm_version_solaris_sparc.cpp. 
They are now redundant as the macros are are in the system header files 
from Solaris 11.1 onwards. The only ones that aren't are T7/M7 related 
ones (from Solaris 11.3 onwards), namely AV_SPARC_FMAF and 
AV2_SPARC_SPARC5. For those I've left the macro probes in place.

The other oddity was the AV_SPARC_FMAU macro defined in 
vm_version_solaris_sparc.cpp. This macro never actually appeared in any 
Solaris header file, the only references I can find are in engineering 
specifications from 2006 related to the cancelled ROCK processor. In 
addition, I couldn't find any uses of the feature that's being probed 
for in the JVM code. I've therefore removed it and all the associated 
infrastructure - VM_Version::fmau_instructions_m, fmau_instructions, 
CPUFeature.FMAU etc - from the JVM code as well.

-- 
Alan Burlison
--