Re: RFR: JDK-8198627 JDK-8198318 broke readlink testing

Good patch, Magnus! We've been affected by this as well but instead of digging deeper into the problem we've installed "readlink" on our AIX build machines, where it wasn't available until now. Good to know that "readlink" is still not a mandatory requirement for the build :) On Fri, Feb 23,

Re: RFR: JDK-8197571 Change storage location for generated-configure.sh

Hi Magnus, thanks for doing this change. It was actually on my TODO list but I somehow forgot about it :) The change looks good. Thumb up from me, Volker On Mon, Feb 12, 2018 at 2:09 PM, Magnus Ihse Bursie wrote: > In JDK-8195689, the generated-configure.sh was

Re: The generated-configure.sh script is dead - autoconf seems to write into the sources in the build process

On Tue, Feb 6, 2018 at 6:28 PM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > > > On 2018-02-06 15:53, Volker Simonis wrote: >> >> Hi, >> >> as Matthias wrote, we're usually running configure from a newly >> created build directory which i

Re: The generated-configure.sh script is dead - autoconf seems to write into the sources in the build process

Hi, as Matthias wrote, we're usually running configure from a newly created build directory which is outside the source tree. Also, the build user who calls configure may differ from the user owning the source tree. I'd therefor like to propose the following small change which checks from where

Re: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

ot he -> to the > Will fix tomorrow morning when I’m back in the office! > I'm also surprised this doesn't need any quoting: > >ifneq ($(COMPANY_NAME), N/A) > Me too, but I can assure you that it doesn’t work if quoted. I’ve tried it :) > Thanks, > David > >

Re: [10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

Erik Joelsson <erik.joels...@oracle.com> schrieb am Mi. 17. Jan. 2018 um 20:16: > Looks good to me. I can sponsor it. Thanks a lot Erik! Regards, Volker > > /Erik > > > On 2018-01-17 08:03, Volker Simonis wrote: > > Hi, > > > > can I please have

[10] RFR(S): 8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag

Hi, can I please have a review and sponsor for this change which finally exposes the various "vendor*" properties: java.vendor java.vm.vendor java.vendor.url java.vendor.url.bug as configure arguments: http://cr.openjdk.java.net/~simonis/webrevs/2018/8189761

Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad

to the regular update? > > Kind regards, > > Martin > > -----Original Message- > From: Volker Simonis [mailto:volker.simo...@gmail.com] > Sent: 22 December 2017 16:25 > To: Evans, Martin <martin.ev...@kingfisher.com> > Cc: Baesken, Matthias <matthias.baes..

Re: Building hsdis?

On Thu, Dec 28, 2017 at 11:48 AM, Andrew Haley <a...@redhat.com> wrote: > On 27/12/17 11:26, Volker Simonis wrote: >> There are two different problems here: >> >> 1. It is not possible to build and redistribute hsdis.so because of >> GPLv2 and GPLv3 license inco

Re: Building hsdis?

On Mon, Dec 25, 2017 at 11:58 PM, Andrew Haley <a...@redhat.com> wrote: > On 24/12/17 12:16, Volker Simonis wrote: >> Andrew Haley <a...@redhat.com> schrieb am So. 24. Dez. 2017 um 09:27: >> >>> On 23/12/17 17:02, Volker Simonis wrote: >>>> Andre

Re: Building hsdis?

y, otherwise there wouldn't be a problem. > Indeed, GPL v2 and v3 are not compatible, but if the upgradability is > allowed then the effective version is already 3. The rest of the openjdk > code is v2 only afaik though. > > Cheers, > Mario > > On Sun 24. Dec 2017 at 13:17

Re: Building hsdis?

Andrew Haley <a...@redhat.com> schrieb am So. 24. Dez. 2017 um 09:27: > On 23/12/17 17:02, Volker Simonis wrote: > > Andrew Haley <a...@redhat.com> schrieb am Sa. 23. Dez. 2017 um 12:25: > > > >> On 20/12/17 09:54, Volker Simonis wrote: > >>> Yes, t

Re: Building hsdis?

Andrew Haley <a...@redhat.com> schrieb am Sa. 23. Dez. 2017 um 12:25: > On 20/12/17 09:54, Volker Simonis wrote: > > Yes, that's exactly the issue. And it was communicated to the OpenJDK > > Governing Board more than two and a half years ago (see my mail > >

Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad

://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/def07b5ce3be On Wed, Dec 20, 2017 at 11:18 AM, Evans, Martin <martin.ev...@kingfisher.com> wrote: > Many thanks guys, I look forward to testing. > > Regards, > > Martin > > -Original Message- > From: Volker Simonis [m

Re: Building hsdis?

On Wed, Dec 20, 2017 at 10:40 AM, David Buck wrote: > Hi Ted! > >> BTW, I'm sure there's a good reason for this, but why doesn't >> OpenJDK/Oracle offer pre-built versions of hsdis for a variety of common >> platforms? Is there a licensing issue? > > Yes, binutils is GPL 3,

Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad

Hi Matthias, the change looks good! I can sponsor it once we get the approval. Also forwarded to buil-dev for the minimal build change. Thank you and best regards, Volker On Wed, Dec 20, 2017 at 9:50 AM, Baesken, Matthias wrote: > Hello , Mark reported this issue

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

On Tue, Dec 5, 2017 at 7:55 PM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > > On 2017-12-05 18:33, Sean Mullan wrote: >> >> On 12/5/17 12:01 PM, Volker Simonis wrote: >>> >>> Hi Rajan, >>> >>> 'cacerts' is a b

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

Hi Rajan, 'cacerts' is a binary file and I thought we have at least the convention in the OpenJDK project that we don't want to check in binary artefact's if possible. One problem with 'cacerts' being a binary file is that we can not add a license and copyright to it. Another one is that it is

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

On Tue, Dec 5, 2017 at 10:08 AM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > On 2017-12-05 09:44, Volker Simonis wrote: >> >> On Tue, Dec 5, 2017 at 9:19 AM, Magnus Ihse Bursie >> <magnus.ihse.bur...@oracle.com> wrote: >>> >>> On 2

Re: RFR 8189131: Open-source the Oracle JDK Root Certificates

On Tue, Dec 5, 2017 at 9:19 AM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > On 2017-12-01 18:16, Volker Simonis wrote: >> >> Hi Rajan, >> >> great to see this finally happen! >> >> I have just a quick question related to the tests

Re: Howto build an old version of hotspot (pre forest consolidation)

anced revset query, looking for descendants > of 104 and ancestors of 105. Many of these changes will be merges that > brought the actual changes in, typically when the integrator brought 104 > down from dev. > > /Erik > > > > On 2017-11-13 08:09, Volker Simonis wrote: >>

Howto build an old version of hotspot (pre forest consolidation)

Hi, can somebody provide any hints on how to build an older version of hotspot in the correct context? I have a reproducible hotspot crash which occurs with jdk-9+105 but not with jdk-9+104. I can sync to both tags and successfully build the corresponding jdk. But it seems impossible to update

Re: AIX build not generating a jre image

Hi Goetz, How do our nightly builds look like? Do they create the JRE image? Regards, Volker Lindenmaier, Goetz schrieb am Mi. 18. Okt. 2017 um 14:56: > Hi Steve, > > I think this is an error. > We never decided not to generate a jre image as far as I know. > > Best

Re: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto

team please comment on this and ideally fix it? Thank you and best regards, Volker On Thu, Sep 7, 2017 at 10:07 AM, Doug Simon <doug.si...@oracle.com> wrote: > >> On 7 Sep 2017, at 07:06, Thomas Stüfe <thomas.stu...@gmail.com> wrote: >> >> On Wed, Sep 6

Re: C++11/C++14 support in XLC ?

On Wed, Jul 19, 2017 at 1:56 AM, Kim Barrett wrote: >> On Jun 30, 2017, at 6:08 PM, Kim Barrett wrote: >> >>> On Jun 29, 2017, at 5:17 PM, Jeff Heath wrote: >>> >>> Hi all, >>> >>> On the LE Linux platform, XL C/C++ V13.1.5 has

Re: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug

Thanks, Tim! Regards, Volker Tim Bell <tim.b...@oracle.com> schrieb am Mi. 19. Juli 2017 um 03:30: > Hello - > > This fix has been pushed to OpenJDK jdk10/jdk10: > >http://hg.openjdk.java.net/jdk10/jdk10/rev/2fe66ca1e2b3 > > Tim > > On 07/18/17 01:58, V

Re: RFR: compile-time guard some UseSharedSpaces-only coding with the INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro

Hi Matthias, thanks for doing this change. It looks good! Can somebody from Oracle (maybe you Jiangli) please sponsor it? Unfortunately I still can't push it because it is in shared code :( Thank you and best regards, Volker On Tue, Jul 18, 2017 at 10:35 AM, Baesken, Matthias

Re: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug

ke Volker! > > ... > > So, do I need a sponsor for this or can I push this on my own? > > Thanks, Thomas > > On Tue, Jul 18, 2017 at 8:58 AM, Volker Simonis <volker.simo...@gmail.com> > wrote: >> >> Looks good! >> >> Thanks, >>

Re: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug

> > Kind Regards, Thomas > > On Tue, Jul 18, 2017 at 7:46 AM, Thomas Stüfe <thomas.stu...@gmail.com> > wrote: >> >> Thank you Volker! >> >> I'll restore the original comment and prepare a new webrev. >> >> ..Thomas >> >> On Mon, J

Re: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug

Hi Thomas, the change looks good, but I'd prefer if you leave the initial comment in place which also mentions "-qminimaltoc" as a way of resolving TOC overflow errors. I actually don't remember exactly, but I think "-qminimaltoc" works by creating distinct TOCs for each compilation unit. That

Re: RFR: JDK-8179892 Update build documentation for JDK 9

On Wed, Jun 21, 2017 at 12:59 PM, Magnus Ihse Bursie wrote: > On 2017-06-21 09:02, Thomas Stüfe wrote: >> >> Hi Magnus, >> >> excellent work! > > > Thank you! :-) > >> Some minor remarks: >> >> You also mentioned Cygwin hg in the "Special considerations" section. >>

Re: RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio

On Thu, Jun 1, 2017 at 7:51 AM, Kim Barrett wrote: >> On May 31, 2017, at 9:22 PM, David Holmes wrote: >> >> Hi Erik, >> >> A small change with big questions :) >> >> On 31/05/2017 11:45 PM, Erik Österlund wrote: >>> Hi, >>> It would be desirable

Re: Required Solaris Studio version for jdk9 ?

On Thu, Mar 30, 2017 at 11:22 AM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > On 2017-03-30 10:33, Volker Simonis wrote: > > Hi, > > the current common/doc/building.md [1] file mentions Studio 12 Update > 4 with several patches as the minimal build requireme

Re: Required Solaris Studio version for jdk9 ?

On Thu, Mar 30, 2017 at 10:49 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > Hello Volker, > > On 2017-03-30 10:33, Volker Simonis wrote: >> >> Hi, >> >> the current common/doc/building.md [1] file mentions Studio 12 Update >> 4 with several patc

Required Solaris Studio version for jdk9 ?

Hi, the current common/doc/building.md [1] file mentions Studio 12 Update 4 with several patches as the minimal build requirement for jdk9 on Solaris. Is this information still up to date and do you plan to use the mentioned versions for the Java 9 GA build? Does somebody know how I can find out

Re: gold for linking

We've experimented with this as well a few years ago. The problem was that it doesn't correctly support all architectures (if I remember right there were some problems with unknown relocation types). So when you add this we have to take care that it will be only used on ppc/s390/aarch if it really

Re: RTTI on Solaris/SPARC builds

As far as I can see we don't explicitly set a compatibility mode so according to the SS 12 documentation [1] we are using -compat=5, which is the default. Also, according to [1], -feature=nortti can only be used in compat mode 4. So I'm afraid we have no choice :) Regards, Volker

Re: configure - gcc >4.6 needed for JDK9 build

On Wed, Jan 25, 2017 at 8:13 PM, Kim Barrett wrote: >> On Jan 24, 2017, at 7:34 PM, David Holmes wrote: >> >> Hi Kim, >> >> On 25/01/2017 7:25 AM, Kim Barrett wrote: On Jan 23, 2017, at 5:34 AM, Mike Burton wrote:

Re: RFR(xxs): 8172579: 8168503 broke AIX build

Hi Thomas, why not simply using GNU grep? We already insist for so many other tools on the GNU version that this wouldn't be a big thing. And as far as I remember, GNU grep is already installed on most of our machines anyway. You just have to place /opt/freeware/bin in front of your PATH. Your

Re: Using hard links for debug builds

Hi Ioi, I think the problem with links (both, hard and soft) is that they are not supported on all filesystems. The same applies to the proposed "cp --reflink". So you would at least have to check if it works during the configuration step. Regards, Volker On Wed, Jan 11, 2017 at 1:57 AM, Ioi

Re: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian)

to start it for legacy code which is not needed in jdk9 anyway. Regards, Volker > Thanks, > David > > > On 28/12/2016 3:17 AM, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review and approval for pushing the following >> small, ppc64-only fix to jdk8u

Re: RFR(xs): 8171408: [aix] TOC overflow when linking the gtest libjvm.so

Looks good now! Thanks, Volker On Tue, Dec 20, 2016 at 9:30 AM, Thomas Stüfe wrote: > Hi guys, > > updated webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8171408-aix-TOC-overflow-when-linking-the-gtest-libjvm/webrev.01/webrev/ > > Only change is that I removed

Re: RFR(xs): 8171433: [aix] switch on gtest AIX build

Hi Thomas, the change looks good. Thanks for finally getting gtest to work on AIX! And thank you David for sponsoring. Regards, Volker On Tue, Dec 20, 2016 at 5:35 AM, Thomas Stüfe wrote: > Great, David, please push them all for me. > > The TOC overflow one (8171408)

Re: RFR(xs): 8171225: [aix] Build gtests on AIX 7.1 with xlC 12

Looks good! Volker On Mon, Dec 19, 2016 at 2:33 PM, Thomas Stüfe wrote: > > On Sun, Dec 18, 2016 at 1:13 PM, Thomas Stüfe > wrote: >> >> HI all, >> >> after investigating I see a number of issues preventing gtest from running >> on AIX, so I

Re: correct version of the autoconf tools?

I think it's still 2.69 - at least that's what generated-configure.sh pretends: #! /bin/sh # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.69 for OpenJDK jdk9. In general you don't have to really care because it has to be re-generated on Oracle's

Re: RFR: JDK-8072413 Configure should fail for VS2010 without SP1 since that cannot build

On Fri, Dec 2, 2016 at 1:35 PM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > On 2016-11-28 16:28, Volker Simonis wrote: > > On Mon, Nov 28, 2016 at 10:56 AM, Erik Joelsson > <erik.joels...@oracle.com> wrote: > > Looks good. > > /Erik > > &

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

is could be addressed the next time we see a similar problem, otherwise it is probably always too much at the bottom of the priority list :) Thank you and best regards, Volker > Would you like me to create a bug for you ? > > Thanks > Kumar > > > On 9/29/2016 9:59 AM, Volker Simo

Re: RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation

Thanks Gustavo, the change looks good. So now we're just waiting for another review from somebody of the aarch64 folks. Once we have that and the fc-request is approved I'll push the changes. Regards, Volker On Mon, Nov 28, 2016 at 5:28 PM, Gustavo Romero wrote: >

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

On Mon, Nov 28, 2016 at 2:34 PM, Gustavo Romero <grom...@linux.vnet.ibm.com> wrote: > Hi Volker, > > On 25-11-2016 14:32, Volker Simonis wrote: >> On Fri, Nov 25, 2016 at 3:51 PM, Andrew Haley <a...@redhat.com> wrote: >>> On 22/11/16 09:57, Andrew Haley wr

Re: RFR: JDK-8072413 Configure should fail for VS2010 without SP1 since that cannot build

On Mon, Nov 28, 2016 at 10:56 AM, Erik Joelsson wrote: > Looks good. > > /Erik > > > > On 2016-11-28 10:43, Magnus Ihse Bursie wrote: >> >> When building with VS2010 without SP1, the build will fail with: >> LINK : fatal error LNK1123: failure during conversion to COFF:

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

On Fri, Nov 25, 2016 at 3:51 PM, Andrew Haley wrote: > On 22/11/16 09:57, Andrew Haley wrote: >> On 22/11/16 00:41, Gustavo Romero wrote: >>> Do you know if the gap between Math and StrictMath is also huge on aarch64? >> >> I'll try to have a look. > > The gap is just the same as

Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Gustavo, we've realized that we have exactly the same problem on Linux/s390 so I hope you don't mind that I've updated the bug and the webrev to also include the fix for Linux/s390: http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.top/

Re: RFR: JDK-8170280: Enable -g for all java compilation in the build

Hi Erik, the Java developers out there will love you for this change! And yet another feature where you catch up with the SAP JVM :) The change looks good, thumbs up from me. Regards, Volker On Wed, Nov 23, 2016 at 4:10 PM, Erik Joelsson wrote: > It was pointed out

Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation

Hi Gustavo, thanks a lot for tracking this down! The change looks good and I a can sponsor it once you get another review from the build group and the FC Extension Request was approved. In general I'd advise to sign the OCTLA [1] to get access to the Java SE TCK [2] as this contains quite a lot

RFR(XXS): 8169630: Fix wrong cpu build flag for Linux/ppc64le build

Hi, can somebody please review and sponsor the following tiny build fix which only affects ppc64le but requires the re-generation of generated-config.sh: http://cr.openjdk.java.net/~simonis/webrevs/2016/8169630/ https://bugs.openjdk.java.net/browse/JDK-8169630 On ppc64le we use "-mcpu=power7

Re: RFR(XS): 8169625: Libjsig build doesn't set flags for ppc64/s390 builds

Thanks a lot Erik! Volker On Mon, Nov 14, 2016 at 11:14 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > Looks good. I will push it. > > /Erik > > > > On 2016-11-14 11:09, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

On Fri, Oct 28, 2016 at 10:57 AM, Erik Joelsson wrote: > Hello, > > > On 2016-10-28 09:56, Vladimir Kozlov wrote: >> >> Webrevs updated in place (please, reload webpage to get new version). >> generated-configure.sh changes are included. >> >>

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

, Vladimir Kozlov <vladimir.koz...@oracle.com> wrote: > Yes, you need to integrate graal-core into hotspot for that. > > I just send final RFR which explains what to do: > > 8166417: Graal-core into JDK for AOT compiler > > Regards, > Vladimir > > > On 10/27/16

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

I can't even compile this on Linux/x86_64. I get the following error: /usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/classes/module-info.java:159: error: module not found: jdk.vm.compiler jdk.vm.compiler; ^

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

On Thu, Oct 27, 2016 at 2:22 PM, Volker Simonis <volker.simo...@gmail.com> wrote: > Hi, > > currently libelf support is checked on every 64-bit Linux and Solaris > platform (see lib-elf.m4): > > if ((test "x$OPENJDK_TARGET_OS" = "xlinux" \ >

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

Hi, currently libelf support is checked on every 64-bit Linux and Solaris platform (see lib-elf.m4): if ((test "x$OPENJDK_TARGET_OS" = "xlinux" \ || test "x$OPENJDK_TARGET_OS" = "xsolaris") && \ (test "x$OPENJDK_TARGET_CPU_BITS" = "x64")); then LIBJELFSHIM_ENABLED="true"

Re: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler

Hi Vladimir, I'm trying to build and test these changes on our platforms and I've just realized that the top-level changes do not contained the generated-configure.sh script. I for myself have generated it for me, but I think it would be useful to always include that into a webrev for convenience

Re: RFR(XS): 8168302: --disable-warnings-as-errors doesn't work for the hotspot build on Solaris

r >> >> >> On Wed, Oct 19, 2016 at 5:54 PM, Volker Simonis >> <volker.simo...@gmail.com> wrote: >> >>> Hi, >>> >>> can I please get a review and a sponsor for the following trivial change: >>> >>> http://cr.openjdk

Re: RFR(XS): 8168302: --disable-warnings-as-errors doesn't work for the hotspot build on Solaris

PING - can somebody please have a look at this trivial change? Thanks, Volker On Wed, Oct 19, 2016 at 5:54 PM, Volker Simonis <volker.simo...@gmail.com> wrote: > Hi, > > can I please get a review and a sponsor for the following trivial change: > > http://cr.openjdk.java

RFR(XS): 8168302: --disable-warnings-as-errors doesn't work for the hotspot build on Solaris

Hi, can I please get a review and a sponsor for the following trivial change: http://cr.openjdk.java.net/~simonis/webrevs/2016/8168302/ https://bugs.openjdk.java.net/browse/JDK-8168302 After change "8152666: The new Hotspot Build System" setting --disable-warnings-as-errors doesn't work for the

Re: RFR: JEP draft for Linux/s3990x port

; on linuxs390. >> >> The s390-files though are not yet fully in shape, I'm still editing them >> to get >> rid of legacy stuff and SAP JVM specific code. E.g. all the code guarded >> by >> #ifdef SAPJVM will go away in the end. >> >> I hope to have t

Re: RFR(XS): 8166800: [s390] Top-level build changes required for Linux/s390x

ok to me. I can sponsor this tomorrow. > > /Erik > > > > On 2016-10-05 16:43, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review and sponsor for the following tiny >> top-level build change required for building the OpenJDK on >>

RFR(XXS): 8166801: [s390] Add jvm.cfg file for Linux/s390x

Hi, can somebody please review the following trivial change which simply adds a new jvm.cfg file for Linux/s390x: http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/8166801/ https://bugs.openjdk.java.net/browse/JDK-8166801 This is so far the only change we need in the jdk-repository for our

RFR(XS): 8166800: [s390] Top-level build changes required for Linux/s390x

Hi, can I please have a review and sponsor for the following tiny top-level build change required for building the OpenJDK on Linux/s390: http://cr.openjdk.java.net/~simonis/webrevs/2016/s390x/8166800/ https://bugs.openjdk.java.net/browse/JDK-8166800 All this change does is to add some

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > > On 2016-09-29 16:54, Alan Burlison wrote: >> >> On 29/09/2016 08:03, Volker Simonis wrote: >> >>> Sorry, but that doesn't sound like a solution to me at all. I think w

Re: RFR: JEP draft for Linux/s3990x port

dimir.koz...@oracle.com> wrote: > On 9/27/16 10:49 AM, Volker Simonis wrote: >> >> Hi, >> >> can you please review and endorse the following draft JEP for the >> integration of the Linux/s390x port into the jkd9 master repository: >> >> https://bugs.ope

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

On Wed, Sep 28, 2016 at 8:54 PM, Chris Bensen <chris.ben...@oracle.com> wrote: > > On Sep 28, 2016, at 11:50 AM, Thomas Stüfe <thomas.stu...@gmail.com> wrote: > > > > On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz <marti...@google.com> > wrote: >&g

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

On Wed, Sep 28, 2016 at 3:03 PM, Kumar Srinivasan <kumar.x.sriniva...@oracle.com> wrote: > > Hello Thomas, Volker, > > > Hi Kumar, > >> >> On 9/16/2016 10:34 AM, Volker Simonis wrote: >>> >>> Hi Christoph, >>> >>> I t

RFR: JEP draft for Linux/s3990x port

Hi, can you please review and endorse the following draft JEP for the integration of the Linux/s390x port into the jkd9 master repository: https://bugs.openjdk.java.net/browse/JDK-8166730 As detailed in the JEP, the Linux/s390x requires very few shared changes and we therefore don't foresee any

Re: Official JDK used to build JDK9

Shouldn't any Java 8 compatible JDK be enough to bootstrap the Java 9 build? If not I would consider this a bug. We are using various (HotSpot based) versions of Java 8 to bootstrap JDK 9 and haven't seen any problems until now. IBM J9 was known for causing some problems in the past because of

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

t; > On 26/07/2016 10:26 PM, Alan Bateman wrote: >> >> This looks right but I'm curious why it was initially implemented to use >> VERSION_NUMBER. >> >> -Alan >> >> >> On 26/07/2016 13:20, Volker Simonis wrote: >> >>> Forwardi

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

4:26 skrev Alan Bateman <alan.bate...@oracle.com>: >> >> This looks right but I'm curious why it was initially implemented to use >> VERSION_NUMBER. >> >> -Alan >> >> >>> On 26/07/2016 13:20, Volker Simonis wrote: >>> >>> Forwardin

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

or 9, but I leave it to them to > determine how to best handle the issue. I think it would be reasonable for > them to decline to add complexity to the build without any current need for > such a feature. See above. I think this is something the HotSpot team should care about

Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version

t; On 26/07/2016 13:20, Volker Simonis wrote: > >> Forwarding to build-dev in the hope to get a review there :) >> More details can be found in the bug description. >> >> Thank you and best regards, >> Volker >> >> >> -- Forwarded message --

RFR(XXS): 8149519: Investigate implementation of java.specification.version

Forwarding to build-dev in the hope to get a review there :) More details can be found in the bug description. Thank you and best regards, Volker -- Forwarded message -- From: Volker Simonis <volker.simo...@gmail.com> Date: Mon, Apr 4, 2016 at 6:47 PM Subject: RFR(XXS): 8

Re: Setting/overriding HOTSPOT_VERSION_STRING

Hi Doug, HOTSPOT_VERSION_STRING comes from VERSION_STRING: hotspot/make/lib/CompileJvm.gmk: -DHOTSPOT_VERSION_STRING='"$(VERSION_STRING)" and VERSION_STRING comes from configure. In your build directory you can do: grep VERSION_STRING spec.gmk VERSION_STRING :=

Re: RFR(S): 8160423: Serial build is broken because of missing dependencies for jmod

requirement for finding any other build bug :) Regards, Volker On Tue, Jun 28, 2016 at 9:27 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > > On 2016-06-28 09:15, Volker Simonis wrote: >> >> Hi, >> >> can somebody please review the following change: &g

RFR(S): 8160423: Serial build is broken because of missing dependencies for jmod

Hi, can somebody please review the following change: http://cr.openjdk.java.net/~simonis/webrevs/2016/8160423/ https://bugs.openjdk.java.net/browse/JDK-8160423 The serial build (i.e. JOBS=1) is currently not working because of missing dependencies for jmod. At the time when jmod is called

Re: RFR(XS): 8158763 : --disable-hotspot-gtest not working on Solaris

Thanks a lot David! Regards, Volker On Wed, Jun 8, 2016 at 3:37 AM, David Holmes <david.hol...@oracle.com> wrote: > Pushing to jdk9/hs under the "trivial - 1 Reviewer" rule > > David > > > On 7/06/2016 5:07 PM, Volker Simonis wrote: >> >> On Tue, J

Re: How is the override mechanism in JvmOverrideFiles.gmk supposed to work?

On Tue, Jun 7, 2016 at 3:37 PM, Erik Joelsson <erik.joels...@oracle.com> wrote: > Hello Volker, > > On 2016-06-07 15:10, Volker Simonis wrote: >> >> Hi, >> >> I've just realized the the override mechanism from >> JvmOverrideFiles.gmk isn't really 'ov

How is the override mechanism in JvmOverrideFiles.gmk supposed to work?

Hi, I've just realized the the override mechanism from JvmOverrideFiles.gmk isn't really 'overriding' options but just 'appending' new ones. So for example: BUILD_LIBJVM_sharedRuntimeTrig.cpp_CXXFLAGS := -DNO_PCH $(CXX_O_FLAG_NONE) will not replace the CXXFLAGS flags for sharedRuntimeTrig.cpp

Re: RFR(XS): 8158763 : --disable-hotspot-gtest not working on Solaris

On Tue, Jun 7, 2016 at 4:28 AM, David Holmes <david.hol...@oracle.com> wrote: > Hi Volker, > > On 6/06/2016 11:59 PM, Volker Simonis wrote: >> >> Hi, >> >> I'd like to get the following tiny bug fix into jdk9-dev. What's the >> current procedure to

RFR(XS): 8158763 : --disable-hotspot-gtest not working on Solaris

Hi, I'd like to get the following tiny bug fix into jdk9-dev. What's the current procedure to get this change approved? http://cr.openjdk.java.net/~simonis/webrevs/2016/8158763/ https://bugs.openjdk.java.net/browse/JDK-8158763 On Solaris, the configure test for libstlport.so.1 isn't disabled by

Re: RFR(S): 8154251: ANSI-C Quoting bug in hotspot.m4 during configure on SLES 10 and 11

gt; > > On 2016-04-14 17:55, Volker Simonis wrote: > >> Hi, >> >> can somebody please review this small hotspot build fix for SLES 10 an 11: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8154251/ >> https://bugs.openjdk.java.net/browse/JDK-81542

RFR(S): 8154251: ANSI-C Quoting bug in hotspot.m4 during configure on SLES 10 and 11

Hi, can somebody please review this small hotspot build fix for SLES 10 an 11: http://cr.openjdk.java.net/~simonis/webrevs/2016/8154251/ https://bugs.openjdk.java.net/browse/JDK-8154251 I've encountered a strange configure problem with the new hotspot build system on SLES 10 and 11: ...

RFR(S): 8154087: Fix AIX and Linux/ppc64le after the integration of the new hotspot build

Hi, can I please have a review for the following trivial changes to make the build work again on AIX and Linux/ppc64le after the integration of the new hotspot build system. The changes are all AIX and/or ppc64 specific and shouldn't change the behavior on any other platform. Because the

Re: RFR(xs): 8153727: AIX jdk build broken after 8145174

Hi Thomas, thanks for doing this fix. It looks good. I've also forwarded your request to build-dev as this is a build change. Just one question: do we pass the new test test/java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java which came in with 8145174 on AIX or

Re: RFR(XS): 8151987: jexec should be executable

On Wed, Mar 16, 2016 at 12:29 PM, Volker Simonis <volker.simo...@gmail.com> wrote: > > > On Wed, Mar 16, 2016 at 12:14 PM, Alan Bateman <alan.bate...@oracle.com> > wrote: > >> On 16/03/2016 11:08, Volker Simonis wrote: >> >>> Hi, >>> &

Re: RFR(XS): 8151987: jexec should be executable

Great! Thanks a lot, Volker On Wed, Mar 16, 2016 at 1:45 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > On 16/03/2016 12:19, Volker Simonis wrote: > >> >> >> So here comes a new (and even smaller) version of the patch which fixes

RFR(XS): 8151987: jexec should be executable

Hi, can I please have a review for the following small fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8151987/ https://bugs.openjdk.java.net/browse/JDK-8151987 'jexec' is currently not executable in the created images (i.e. images/{jdk,jre}/lib/jexec. There is currently a special

Re: Fix the version of required jdk

Hi Yuji, your fix looks reasonable. But as the name implies, 'generated-configure.sh' is a generated file. A complete patch should change the source files (in this case common/autoconf/help.m4) and recreate 'generated-configure.sh' by calling common/autoconf/autogen.sh (you should use autoconf

Re: RFR (XXS): 8151497: Set REQUIRED_OS_NAME and REQUIRED_OS_VERSION on AIX

Great! Thanks a lot, Volker On Wed, Mar 9, 2016 at 11:12 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > Looks good, I will push it. > /Erik > > > On 2016-03-09 10:39, Volker Simonis wrote: >> >> Hi, >> >> can I please have a rev

RFR (XXS): 8151497: Set REQUIRED_OS_NAME and REQUIRED_OS_VERSION on AIX

Hi, can I please have a review and sponsor (because this change requires the recreation of generated-configure.sh) for this trivial fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8151497/ https://bugs.openjdk.java.net/browse/JDK-8151497 For some reason we've never set REQUIRED_OS_NAME

Should we use '-fno-asynchronous-unwind-tables' to reduce the size of libjvm.so by 10 percent?

Hi, We are currently building and linking the libjvm.so on Linux with -fnoexceptions because we currently don't use C++ exception handling in the HotSpot. Nevertheless, g++ generates unwind tables (i.e. .eh_frame sections) in the object files and shared libraries which can not be stripped from

RFR(S): JDK-8150197: Integrate AIX fixes from build-infra

Hi, can I please have a reviewer and sponsor for this AIX build change: http://cr.openjdk.java.net/~simonis/webrevs/2016/8150197/ https://bugs.openjdk.java.net/browse/JDK-8150197 The change is actually a downport from build-infra and it has already been informally reviewed by Magnus in that

<    1   2   3   4   5   >