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: 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 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: 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: <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> <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 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> <642003bd-a5dc-d1ae-87ff-aca50388cb9c@redhat.com> <4E700D62-8D04-47F7-9298-D1ED776BE376@oracle.com> Message-ID: 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 wrote: > > >> On Mar 16, 2017, at 2:27 PM, Andrew Haley 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: 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: <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> <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 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> <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com> <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com> Message-ID: 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: 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> <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com> <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.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 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> <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com> <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com> <595FE441-10E0-4AB6-B7EE-686132F2269C@oracle.com> Message-ID: 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: 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> <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com> <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com> <595FE441-10E0-4AB6-B7EE-686132F2269C@oracle.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 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> <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com> <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com> <595FE441-10E0-4AB6-B7EE-686132F2269C@oracle.com> <96A77F56-4F35-449D-83EB-CE19FDEEF768@oracle.com> Message-ID: 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 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: 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> <5f79ca1a-18a9-4f52-6332-205ffff2e1a0@redhat.com> <1FBB8985-1FE6-44E1-B338-7C6D49372D93@oracle.com> <595FE441-10E0-4AB6-B7EE-686132F2269C@oracle.com> <96A77F56-4F35-449D-83EB-CE19FDEEF768@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.