From edward.nevill at gmail.com  Sun Mar 12 15:52:24 2017
From: edward.nevill at gmail.com (Edward Nevill)
Date: Sun, 12 Mar 2017 15:52:24 +0000
Subject: Result: New aarch32-port Committer Anton Kozlov
Message-ID: <1489333944.2164.5.camel@gmail.com>

Voting for Anton Kozlov [1] is now closed.

Yes: 3
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Edward Nevill

[1]?http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2017-February/000752.html


From aph at redhat.com  Thu Mar 16 16:50:10 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 16 Mar 2017 16:50:10 +0000
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
Message-ID: <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>

I've just noticed a nasty problem.  "java -version" on AArch64 gives
no clue about which version of HotSpot, Oracle's or the aarch64-port
project, is running.  I hadn't realized that the version wasn't going
to appear anywhere.

And all that a crash says is

#  SIGSEGV (0xb) at pc=0x0000007fb7a0c2e4, pid=44736, tid=44737
#
# JRE version:  (9.0) (build )
# Java VM: OpenJDK 64-Bit Server VM (9-internal+0-adhoc.aph.hs, mixed mode, tiered, compressed oops, g1 gc, linux-aarch64)

There is a bit more in the log:

---------------  S U M M A R Y ------------
Command Line:
Host: AArch64 Processor rev 0 (aarch64), 48 cores, 62G, Random Linux Distro

I guess the Oracle proprietary release will have the Oracle copyright
etc., so that one wil be clear enough, and if it's from a Linux distro
we'll know which port they use, unless some distro (Gentoo?  Debian?)
is crazy enough to package both versions, in which case it's their
problem.

I had assumed that Oracle's port would call itself "arm64" or
somesuch, to distinguish it.

Even the bug database only has "aarch32" and "aarch64", so it's going
to be crazy hard to distinguish which port has a bug.  We should
really get that fixed.

It's funny how this stuff comes out of the woodwork.

Andrew.

From bob.vandette at oracle.com  Thu Mar 16 18:03:55 2017
From: bob.vandette at oracle.com (Bob Vandette)
Date: Thu, 16 Mar 2017 14:03:55 -0400
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
Message-ID: <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>

I agree that this is an issue but I?m not sure that it?s a show stopper.

The Oracle build will not have OpenJDK in the version string which will help to differentiate 
our binaries from OpenJDK builds.

The bug database field that I think you are describing is only an indication of the architecture
that a bug can be reproduced on.  It is not meant to describe the sources that were used to produce
the binaries or where the binaries came from.  That should to be specified elsewhere in the bug report.

I don?t like the idea of listing arm64 in the version string since we are only using arm64 internally to
trigger the use of the hotspot ?arm? directory.  We?d also end up with lots of incorrect bug entries since folks
will fail to use arm64 to report a bug in the Oracle 64-bit ARM port running on an aarch64 based system.

If we start putting build configuration information in the version string, then where do we stop.

Bob.

> On Mar 16, 2017, at 12:50 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> I've just noticed a nasty problem.  "java -version" on AArch64 gives
> no clue about which version of HotSpot, Oracle's or the aarch64-port
> project, is running.  I hadn't realized that the version wasn't going
> to appear anywhere.
> 
> And all that a crash says is
> 
> #  SIGSEGV (0xb) at pc=0x0000007fb7a0c2e4, pid=44736, tid=44737
> #
> # JRE version:  (9.0) (build )
> # Java VM: OpenJDK 64-Bit Server VM (9-internal+0-adhoc.aph.hs, mixed mode, tiered, compressed oops, g1 gc, linux-aarch64)
> 
> There is a bit more in the log:
> 
> ---------------  S U M M A R Y ------------
> Command Line:
> Host: AArch64 Processor rev 0 (aarch64), 48 cores, 62G, Random Linux Distro
> 
> I guess the Oracle proprietary release will have the Oracle copyright
> etc., so that one wil be clear enough, and if it's from a Linux distro
> we'll know which port they use, unless some distro (Gentoo?  Debian?)
> is crazy enough to package both versions, in which case it's their
> problem.
> 
> I had assumed that Oracle's port would call itself "arm64" or
> somesuch, to distinguish it.
> 
> Even the bug database only has "aarch32" and "aarch64", so it's going
> to be crazy hard to distinguish which port has a bug.  We should
> really get that fixed.
> 
> It's funny how this stuff comes out of the woodwork.
> 
> Andrew.


From aph at redhat.com  Thu Mar 16 18:27:49 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 16 Mar 2017 18:27:49 +0000
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
Message-ID: <642003bd-a5dc-d1ae-87ff-aca50388cb9c@redhat.com>

On 16/03/17 18:03, Bob Vandette wrote:

> I agree that this is an issue but I?m not sure that it?s a show
> stopper.
> 
> The Oracle build will not have OpenJDK in the version string which
> will help to differentiate our binaries from OpenJDK builds.

Right, like I said.

> The bug database field that I think you are describing is only an
> indication of the architecture that a bug can be reproduced on.  It
> is not meant to describe the sources that were used to produce the
> binaries or where the binaries came from.  That should to be
> specified elsewhere in the bug report.

OK.  I would surely have tried to insist that the version strings were
different for our two ports at the time your port was committed, but I
blew my chance.

> I don?t like the idea of listing arm64 in the version string since
> we are only using arm64 internally to trigger the use of the hotspot
> ?arm? directory.  We?d also end up with lots of incorrect bug
> entries since folks will fail to use arm64 to report a bug in the
> Oracle 64-bit ARM port running on an aarch64 based system.
> 
> If we start putting build configuration information in the version
> string, then where do we stop.

It's going to be rather horrible, though.  How do we reproduce a bug
if we don't know what port is causing the bug?  How do we even ask the
question if we don't know what the ports are called?  I always assumed
we were "aarch64" and you were "arm64".  How are we to ask a user if
we can't tell them what to look for?

Even if we don't change anything in OpenJDK itself, we'll still have
to agree on a label to use in the bug database.  I don't know what
labels we should use, but we should agree on them now.  Do you have
any preferences?

Andrew.

From bob.vandette at oracle.com  Thu Mar 16 18:40:00 2017
From: bob.vandette at oracle.com (Bob Vandette)
Date: Thu, 16 Mar 2017 14:40:00 -0400
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <642003bd-a5dc-d1ae-87ff-aca50388cb9c@redhat.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
 <642003bd-a5dc-d1ae-87ff-aca50388cb9c@redhat.com>
Message-ID: <4E700D62-8D04-47F7-9298-D1ED776BE376@oracle.com>


> On Mar 16, 2017, at 2:27 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 16/03/17 18:03, Bob Vandette wrote:
> 
>> I agree that this is an issue but I?m not sure that it?s a show
>> stopper.
>> 
>> The Oracle build will not have OpenJDK in the version string which
>> will help to differentiate our binaries from OpenJDK builds.
> 
> Right, like I said.
> 
>> The bug database field that I think you are describing is only an
>> indication of the architecture that a bug can be reproduced on.  It
>> is not meant to describe the sources that were used to produce the
>> binaries or where the binaries came from.  That should to be
>> specified elsewhere in the bug report.
> 
> OK.  I would surely have tried to insist that the version strings were
> different for our two ports at the time your port was committed, but I
> blew my chance.
> 
>> I don?t like the idea of listing arm64 in the version string since
>> we are only using arm64 internally to trigger the use of the hotspot
>> ?arm? directory.  We?d also end up with lots of incorrect bug
>> entries since folks will fail to use arm64 to report a bug in the
>> Oracle 64-bit ARM port running on an aarch64 based system.
>> 
>> If we start putting build configuration information in the version
>> string, then where do we stop.
> 
> It's going to be rather horrible, though.  How do we reproduce a bug
> if we don't know what port is causing the bug?  How do we even ask the
> question if we don't know what the ports are called?  I always assumed
> we were "aarch64" and you were "arm64".  How are we to ask a user if
> we can't tell them what to look for?
> 
> Even if we don't change anything in OpenJDK itself, we'll still have
> to agree on a label to use in the bug database.  I don't know what
> labels we should use, but we should agree on them now.  Do you have
> any preferences?

I agree that a label would be very useful.  For this purpose, I?m not opposed
to using the arm64 versus aarch64 names.   Let me check around to see
if anyone has a better suggestion.

Bob.



> 
> Andrew.


From bob.vandette at oracle.com  Fri Mar 17 20:14:45 2017
From: bob.vandette at oracle.com (Bob Vandette)
Date: Fri, 17 Mar 2017 16:14:45 -0400
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <4E700D62-8D04-47F7-9298-D1ED776BE376@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
 <642003bd-a5dc-d1ae-87ff-aca50388cb9c@redhat.com>
 <4E700D62-8D04-47F7-9298-D1ED776BE376@oracle.com>
Message-ID: <B707785B-0929-4B9C-8256-E395E015C216@oracle.com>

I checked with the hotspot compiler team and their manager and they are ok with
using the labels ?arm64? and ?aarch64? to mark bugs that are specific to 64-bit aarch64
builds that are done using hotspot/src/cpu/arm versus hotspot/src/cpu/aarch64 sources.

Please publicize this label?s use throughout interested OpenJDK developers.

Bob.


> On Mar 16, 2017, at 2:40 PM, Bob Vandette <bob.vandette at oracle.com> wrote:
> 
> 
>> On Mar 16, 2017, at 2:27 PM, Andrew Haley <aph at redhat.com> wrote:
>> 
>> On 16/03/17 18:03, Bob Vandette wrote:
>> 
>>> I agree that this is an issue but I?m not sure that it?s a show
>>> stopper.
>>> 
>>> The Oracle build will not have OpenJDK in the version string which
>>> will help to differentiate our binaries from OpenJDK builds.
>> 
>> Right, like I said.
>> 
>>> The bug database field that I think you are describing is only an
>>> indication of the architecture that a bug can be reproduced on.  It
>>> is not meant to describe the sources that were used to produce the
>>> binaries or where the binaries came from.  That should to be
>>> specified elsewhere in the bug report.
>> 
>> OK.  I would surely have tried to insist that the version strings were
>> different for our two ports at the time your port was committed, but I
>> blew my chance.
>> 
>>> I don?t like the idea of listing arm64 in the version string since
>>> we are only using arm64 internally to trigger the use of the hotspot
>>> ?arm? directory.  We?d also end up with lots of incorrect bug
>>> entries since folks will fail to use arm64 to report a bug in the
>>> Oracle 64-bit ARM port running on an aarch64 based system.
>>> 
>>> If we start putting build configuration information in the version
>>> string, then where do we stop.
>> 
>> It's going to be rather horrible, though.  How do we reproduce a bug
>> if we don't know what port is causing the bug?  How do we even ask the
>> question if we don't know what the ports are called?  I always assumed
>> we were "aarch64" and you were "arm64".  How are we to ask a user if
>> we can't tell them what to look for?
>> 
>> Even if we don't change anything in OpenJDK itself, we'll still have
>> to agree on a label to use in the bug database.  I don't know what
>> labels we should use, but we should agree on them now.  Do you have
>> any preferences?
> 
> I agree that a label would be very useful.  For this purpose, I?m not opposed
> to using the arm64 versus aarch64 names.   Let me check around to see
> if anyone has a better suggestion.
> 
> Bob.
> 
> 
> 
>> 
>> Andrew.
> 


From aph at redhat.com  Tue Mar 21 14:26:15 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 21 Mar 2017 14:26:15 +0000
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
Message-ID: <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com>

On 16/03/17 18:03, Bob Vandette wrote:
> If we start putting build configuration information in the version string, then where do we stop.

Two separate ports is pretty large for a "build configuration issue".

How about we define a unique global dynamic symbol?  Then, at least,
it's just a matter of using nm or equivalent to have a look at which
port we have.

Andrew.


From bob.vandette at oracle.com  Tue Mar 21 15:25:58 2017
From: bob.vandette at oracle.com (Bob Vandette)
Date: Tue, 21 Mar 2017 11:25:58 -0400
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
 <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com>
Message-ID: <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com>

I?d prefer to use something like these System properties.

"java.vendor"	JRE vendor name
"java.vendor.url"	JRE vendor URL

 or to add something to the ?release? file.

HOTSPOT_ARCH_DIR=arm

or 

HOTSPOT_ARCH_DIR=aarch64

Bob.


> On Mar 21, 2017, at 10:26 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 16/03/17 18:03, Bob Vandette wrote:
>> If we start putting build configuration information in the version string, then where do we stop.
> 
> Two separate ports is pretty large for a "build configuration issue".
> 
> How about we define a unique global dynamic symbol?  Then, at least,
> it's just a matter of using nm or equivalent to have a look at which
> port we have.
> 
> Andrew.
> 


From aph at redhat.com  Tue Mar 21 15:27:33 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 21 Mar 2017 15:27:33 +0000
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
 <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com>
 <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com>
Message-ID: <ea5b93c3-511d-3bcb-351c-d27a9c11c3cb@redhat.com>

On 21/03/17 15:25, Bob Vandette wrote:
> I?d prefer to use something like these System properties.
> 
> "java.vendor"	JRE vendor name
> "java.vendor.url"	JRE vendor URL
> 
>  or to add something to the ?release? file.
> 
> HOTSPOT_ARCH_DIR=arm
> 
> or 
> 
> HOTSPOT_ARCH_DIR=aarch64

OK, sounds good.  I'll have a think.

Andrew.


From bob.vandette at oracle.com  Thu Mar 23 18:58:52 2017
From: bob.vandette at oracle.com (Bob Vandette)
Date: Thu, 23 Mar 2017 14:58:52 -0400
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <ea5b93c3-511d-3bcb-351c-d27a9c11c3cb@redhat.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
 <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com>
 <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com>
 <ea5b93c3-511d-3bcb-351c-d27a9c11c3cb@redhat.com>
Message-ID: <595FE441-10E0-4AB6-B7EE-686132F2269C@oracle.com>

What does your aarch64 build have as IMPLEMENTOR in it?s ?release? file.
I wonder if we can use this difference for now?

IMPLEMENTOR="Oracle Corporation?

Bob.


> On Mar 21, 2017, at 11:27 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 21/03/17 15:25, Bob Vandette wrote:
>> I?d prefer to use something like these System properties.
>> 
>> "java.vendor"	JRE vendor name
>> "java.vendor.url"	JRE vendor URL
>> 
>> or to add something to the ?release? file.
>> 
>> HOTSPOT_ARCH_DIR=arm
>> 
>> or 
>> 
>> HOTSPOT_ARCH_DIR=aarch64
> 
> OK, sounds good.  I'll have a think.
> 
> Andrew.
> 


From aph at redhat.com  Thu Mar 23 19:05:33 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 23 Mar 2017 19:05:33 +0000
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <595FE441-10E0-4AB6-B7EE-686132F2269C@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
 <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com>
 <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com>
 <ea5b93c3-511d-3bcb-351c-d27a9c11c3cb@redhat.com>
 <595FE441-10E0-4AB6-B7EE-686132F2269C@oracle.com>
Message-ID: <ecebf5be-c9aa-da78-9ddf-8b19d3311459@redhat.com>

On 23/03/17 18:58, Bob Vandette wrote:
> What does your aarch64 build have as IMPLEMENTOR in it?s ?release? file.
> I wonder if we can use this difference for now?
> 
> IMPLEMENTOR="Oracle Corporation?

At the moment,

SOURCE=".:d660c00d91bf corba:ff8cb43c07c0 hotspot:9bfa2cceba90+ jaxp:8c9a2a24752b jaxws:92aa05eff5d1 jdk:a2d3b7f65c95 langtools:69e2e4d7136c nashorn:4a07ebdf8b45"
IMPLEMENTOR="N/A"

I don't know where that file comes from or even what it means.
It would be OK, but what would we put there?  "OpenJDK"?  They're
both supposed to be OpenJDK projects.

Andrew.


From bob.vandette at oracle.com  Thu Mar 23 19:27:27 2017
From: bob.vandette at oracle.com (Bob Vandette)
Date: Thu, 23 Mar 2017 15:27:27 -0400
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <ecebf5be-c9aa-da78-9ddf-8b19d3311459@redhat.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
 <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com>
 <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com>
 <ea5b93c3-511d-3bcb-351c-d27a9c11c3cb@redhat.com>
 <595FE441-10E0-4AB6-B7EE-686132F2269C@oracle.com>
 <ecebf5be-c9aa-da78-9ddf-8b19d3311459@redhat.com>
Message-ID: <96A77F56-4F35-449D-83EB-CE19FDEEF768@oracle.com>

I?m not sure of the exact meaning of these variables but the logic that
generates this file is in jdk9/make/ReleaseFile.gmk.  I?ll look into
the intended purpose.

Perhaps the fact that you have N/A and our build is Oracle might be good enough.

Bob.


> On Mar 23, 2017, at 3:05 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 23/03/17 18:58, Bob Vandette wrote:
>> What does your aarch64 build have as IMPLEMENTOR in it?s ?release? file.
>> I wonder if we can use this difference for now?
>> 
>> IMPLEMENTOR="Oracle Corporation?
> 
> At the moment,
> 
> SOURCE=".:d660c00d91bf corba:ff8cb43c07c0 hotspot:9bfa2cceba90+ jaxp:8c9a2a24752b jaxws:92aa05eff5d1 jdk:a2d3b7f65c95 langtools:69e2e4d7136c nashorn:4a07ebdf8b45"
> IMPLEMENTOR="N/A"
> 
> I don't know where that file comes from or even what it means.
> It would be OK, but what would we put there?  "OpenJDK"?  They're
> both supposed to be OpenJDK projects.
> 
> Andrew.
> 


From david.holmes at oracle.com  Fri Mar 24 01:42:31 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 24 Mar 2017 11:42:31 +1000
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <96A77F56-4F35-449D-83EB-CE19FDEEF768@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
 <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com>
 <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com>
 <ea5b93c3-511d-3bcb-351c-d27a9c11c3cb@redhat.com>
 <595FE441-10E0-4AB6-B7EE-686132F2269C@oracle.com>
 <ecebf5be-c9aa-da78-9ddf-8b19d3311459@redhat.com>
 <96A77F56-4F35-449D-83EB-CE19FDEEF768@oracle.com>
Message-ID: <a9e79515-fb07-d5cd-6d41-504690113a15@oracle.com>

This issue seems to be fragmenting, given that Mario has put out a RFR 
on jdk9-dev based on the VENDOR_URL!

We can easily change -Xinternalversion output, which would also affect 
hs-err log file.

David

On 24/03/2017 5:27 AM, Bob Vandette wrote:
> I?m not sure of the exact meaning of these variables but the logic that
> generates this file is in jdk9/make/ReleaseFile.gmk.  I?ll look into
> the intended purpose.
>
> Perhaps the fact that you have N/A and our build is Oracle might be good enough.
>
> Bob.
>
>
>> On Mar 23, 2017, at 3:05 PM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 23/03/17 18:58, Bob Vandette wrote:
>>> What does your aarch64 build have as IMPLEMENTOR in it?s ?release? file.
>>> I wonder if we can use this difference for now?
>>>
>>> IMPLEMENTOR="Oracle Corporation?
>>
>> At the moment,
>>
>> SOURCE=".:d660c00d91bf corba:ff8cb43c07c0 hotspot:9bfa2cceba90+ jaxp:8c9a2a24752b jaxws:92aa05eff5d1 jdk:a2d3b7f65c95 langtools:69e2e4d7136c nashorn:4a07ebdf8b45"
>> IMPLEMENTOR="N/A"
>>
>> I don't know where that file comes from or even what it means.
>> It would be OK, but what would we put there?  "OpenJDK"?  They're
>> both supposed to be OpenJDK projects.
>>
>> Andrew.
>>
>

From aph at redhat.com  Fri Mar 24 08:07:17 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 24 Mar 2017 08:07:17 +0000
Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port
In-Reply-To: <a9e79515-fb07-d5cd-6d41-504690113a15@oracle.com>
References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com>
 <58421A35.5070706@oracle.com>
 <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com>
 <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com>
 <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com>
 <4082474e-c3bf-ec2b-99d6-dc8a995c16fe@redhat.com>
 <B5A829C0-6FAA-459A-9B41-65F1F11E3970@oracle.com>
 <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com>
 <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com>
 <ea5b93c3-511d-3bcb-351c-d27a9c11c3cb@redhat.com>
 <595FE441-10E0-4AB6-B7EE-686132F2269C@oracle.com>
 <ecebf5be-c9aa-da78-9ddf-8b19d3311459@redhat.com>
 <96A77F56-4F35-449D-83EB-CE19FDEEF768@oracle.com>
 <a9e79515-fb07-d5cd-6d41-504690113a15@oracle.com>
Message-ID: <5eaabe83-75f0-221a-910e-b73954c4f250@redhat.com>

On 24/03/17 01:42, David Holmes wrote:
> This issue seems to be fragmenting, given that Mario has put out a RFR 
> on jdk9-dev based on the VENDOR_URL!
> 
> We can easily change -Xinternalversion output, which would also affect 
> hs-err log file.

It's not fragmenting at all: Mario's idea looks decent enough.  I would
love you to explain what to do with -Xinternalversion.  That would be
awesome.  It'd be nice to have something that can easily be read
programmatically.

Andrew.