JDK-8177390: java -version does not differentiate between which port of AArch64 is used

[David Holmes]

On 25/03/2017 3:24 AM, Bob Vandette wrote:
>
>> On Mar 24, 2017, at 11:57 AM, Mario Torre <neugens at redhat.com> wrote:
>>
>> On Fri, Mar 24, 2017 at 4:15 PM, Bob Vandette <bob.vandette at oracle.com> wrote:
>>> Do we dump the contents of the “release” file in the hotspot error log?
>>>
>>> If so, there’s a key in that file called “IMPLEMENTOR” that is set to Oracle for the binaries that we produce (from the hotspot/src/cpu/arm sources).
>>>
>>> Alternatively, we could add HOTSPOT_TARGET_CPU_PORT to the release file.
>>
>> Hello Bob,
>>
>> Thanks for this suggestion too.
>>
>> I have a patch that may work, is not very intrusive and only adds some
>> things for the aarch64, so it should be ok, hopefully:
>>
>> http://cr.openjdk.java.net/~neugens/8177390/webrev.3/
>>
>> This follows David's suggestion on having the -Xinternalversion
>> changed slightly. I also add a property (I hope that's ok and doesn't
>> require CCC or spec changes approvals), the property is
>> "aarch64.community.port" and only there for the aarch64 port so that
>> code can query it, the value for all the other ports will be null.
>>
>> Would that be acceptable?
>
> I’m not opposed to the approach, just the name of the property.
>
> The “community” is free to build a 64-bit (aarch64) ARM port from either hotspot/src/cpu/arm
> or hotspot/src/cpu/aarch64 sources, so aarch64.community.port is a bit misleading since
> binaries produced from either port can be a “community” port.
>
> What we are trying to differenciate are the two difference cpu and os_cpu directories
> used to produce an aarch64 image.  I’m hopeful that one day, we’ll consolidate these
> two ports so I don’t want to do anything too permanent.

The src distinction is handled in the build system using the variable 
HOTSPOT_TARGET_CPU_ARCH (arm, aarch64), which is then used to define:

-DTARGET_ARCH_arm

or

-DTARGET_ARCH_aarch64

for the Oracle and Original-Open Aarch64 ports respectively.

The -Xinternalversion string currently uses the -DCPU define which is 
set by the build from the OPENJDK_TARGET_CPU_VM_VERSION variable, which 
in turn is defined from OPENJDK_TARGET_CPU (in most cases).

For both of the ports OPENJDK_TARGET_CPU will be set to aarch64.

I would suggest changing the value set for -DCPU in CompileJVM.gmk to 
use aarch64 for the original open port, and arm64 for the Oracle port. 
This would update the -Xinternalversion string and would also update the 
value returned by the Abstract_VM_Version::vm_platform_string(), which 
is used in vmError reporting _and_ in the output of the VMInfo Dcmd.

diff -r dabd810a9825 make/lib/CompileJvm.gmk
--- a/make/lib/CompileJvm.gmk
+++ b/make/lib/CompileJvm.gmk
@@ -118,6 +118,12 @@
    OPENJDK_TARGET_CPU_VM_VERSION := amd64
  else ifeq ($(OPENJDK_TARGET_CPU), sparcv9)
    OPENJDK_TARGET_CPU_VM_VERSION := sparc
+else ifeq ($(HOTSPOT_TARGET_CPU_ARCH), arm)
+  ifeq ($(OPENJDK_TARGET_CPU), aarch64)
+    # This sets the Oracle Aarch64 port to use arm64
+    # while the original Aarch64 port uses aarch64
+    OPENJDK_TARGET_CPU_VM_VERSION := arm64
+  endif
  else
    OPENJDK_TARGET_CPU_VM_VERSION := $(OPENJDK_TARGET_CPU)
  endif


This gives:

Java HotSpot(TM) 64-Bit Server VM 
(9-internal+0-2017-03-23-222147.daholme.jdk9-hs) for linux-arm64 JRE 
(9-internal+0-2017-03-23-222147.daholme.jdk9-hs), built on Mar 26 2017 
20:58:41 by "daholme" with gcc 4.8.3 20131111 (prerelease)

versus a previous:

Java HotSpot(TM) 64-Bit Server VM (fastdebug 
9-internal+0-2016-11-23-194303.daholme.jdk9-hs) for linux-aarch64 JRE 
(9-internal+0-2016-11-23-194303.daholme.jdk9-hs), built on Nov 23 2016 
20:04:21 by "daholme" with gcc 4.8.3 20131111 (prerelease)

> Can we use the property hotspot.target.cpu.port={aarch64,arm}

The original request here was for a way to distinguish the two ports 
based on "java -version", which is satisfied by the change suggested for 
"java -Xinternalversion". I do not see that it is necessary to have a 
programmatic means of querying this property from inside a running VM. 
That said the change proposed above will expose the version through the 
VMInfo Dcmd.

System properties tend to be long-lived so adding them should not be 
undertaken lightly. Adding a property would require a CCC approval.

Thanks,
David
-----


> Bob.
>
>
>>
>> The benefit of this is that it can be queried by java applications,
>> can be output on the terminal via -Xinternalversion and appears in the
>> hotspot error file [1]:
>>
>> vm_info: OpenJDK 64-Bit Server VM (9-internal+0-adhoc.neugens.jdk9)
>> for linux-aarch64 (aarch64) JRE (9-internal+0-adhoc.neugens.jdk9),
>> built on Mar 24 2017 15:09:52 by "neugens" with gcc 4.8.3 20140911
>> (Red Hat 4.8.3-9)
>>
>> As opposed to (crash from the arm64 port):
>>
>> vm_info: OpenJDK 64-Bit Server VM (9-internal+0-adhoc.neugens.jdk9)
>> for linux-aarch64 JRE (9-internal+0-adhoc.neugens.jdk9), built on Mar
>> 24 2017 15:27:39 by "neugens" with gcc 4.8.3 20140911 (Red Hat
>> 4.8.3-9)
>>
>> This is way better than my original patch did, and serves all our use cases.
>>
>> Cheers,
>> Mario
>>
>> [1] Kudos to Aleksey for suggesting a very clever way to crash the jdk
>> on demand :)
>