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

[Bob Vandette]

I like that solution David.  It’s consistent with our use of labels to mark the sources
that a bug is associated with.  I didn’t want to mess around with changing the name
of the CPU arch in case there are consumers expecting aarch64 but you’re change
seems very localized to the version string.

Thanks,
Bob.


> On Mar 26, 2017, at 9:08 PM, David Holmes <David.Holmes at oracle.com> wrote:
> 
> 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 :)
>>