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

[David Holmes]

Hi Alan,

On 27/09/2016 11:47 PM, Alan Burlison wrote:
> 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.

Okay. The old implementation at:

https://java.net/projects/solaris/sources/on-src/content/usr/src/lib/libc/port/gen/getisax.c

supports this.

> 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.

Ok.

> 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.

Yes we had some bleeding edge support in there from 2006.

I think all these cleanups/removals seem fine.

Reviewed.

Thanks,
David