Re: Review Request: JDK-8170424 install build is broken due to the new location of src.zip

+1 -phil. On 11/28/16, 5:03 PM, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170424/webrev.00/ This back out the src.zip change in JDK-8169816 to give time to update the installer properly. Mandy

Review Request: JDK-8170424 install build is broken due to the new location of src.zip

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170424/webrev.00/ This back out the src.zip change in JDK-8169816 to give time to update the installer properly. Mandy

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

Looks good. /Erik On 2016-11-28 17:28, Gustavo Romero wrote: Hi all, I'm re-sending due to JDK title update to include s390x and aarch64 archs. Could the following webrev be reviewed, please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ webrev 2/2: http://cr.openjdk.java.net/

Re: RFR: JDK-8166737: default langtools make test settings result in no ouput

Erik: The various test/Makefile in the forest do no all behave the same. The langtools/test/Makefile in particular has a different default verbosity setting compared to the rest. When running tests for the whole forest for CI, it would be more convenient if the verbosity was coherent. The other

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

Hi all, I'm re-sending due to JDK title update to include s390x and aarch64 archs. Could the following webrev be reviewed, please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ bug:https://bugs.openjdk.java.net

RFR: JDK-8166737: default langtools make test settings result in no ouput

The various test/Makefile in the forest do no all behave the same. The langtools/test/Makefile in particular has a different default verbosity setting compared to the rest. When running tests for the whole forest for CI, it would be more convenient if the verbosity was coherent. The other repo

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

On Mon, Nov 28, 2016 at 2:34 PM, Gustavo Romero wrote: > Hi Volker, > > On 25-11-2016 14:32, Volker Simonis wrote: >> 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

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: file >> invalid or corrupt

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

Hi Volker, On 25-11-2016 14:32, Volker Simonis wrote: > 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

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

Hi Volker, Sorry for not replying earlier, it was day-off on Friday here... On 25-11-2016 11:32, Volker Simonis wrote: > 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 fi

Re: RFR: JDK-8170392: JDK-8031567 broke builds from source bundles

Thanks, but unfortunately, the build breaks again later. Updated webrev in place. /Erik On 2016-11-28 13:49, Staffan Larsen wrote: Looks good to me! Thanks, /Staffan On 28 Nov 2016, at 13:41, Erik Joelsson wrote: In JDK-8031567, the format for storing source revision information for use

Re: RFR: JDK-8170392: JDK-8031567 broke builds from source bundles

Looks better to me! /Staffan > On 28 Nov 2016, at 13:52, Erik Joelsson wrote: > > Thanks, but unfortunately, the build breaks again later. Updated webrev in > place. > > /Erik > > > On 2016-11-28 13:49, Staffan Larsen wrote: >> Looks good to me! >> >> Thanks, >> /Staffan >> >>> On 28 Nov

Re: RFR: JDK-8170392: JDK-8031567 broke builds from source bundles

Looks good to me! Thanks, /Staffan > On 28 Nov 2016, at 13:41, Erik Joelsson wrote: > > In JDK-8031567, the format for storing source revision information for use in > builds from source bundles changed. The behavior when building without either > mercurial or the stored revision information

RFR: JDK-8170392: JDK-8031567 broke builds from source bundles

In JDK-8031567, the format for storing source revision information for use in builds from source bundles changed. The behavior when building without either mercurial or the stored revision information also changed. We used to silently ignore the lack of source revision information, but now the

Re: RFR: JDK-8056215 AWT source dirs should only point to java2d, not below

It looks like this will result in the same files being built, but just to be sure, have you verified the result to be equal? /Erik On 2016-11-28 10:47, Magnus Ihse Bursie wrote: This is from a code review following the jigsaw source file restructuring: * The makefiles include too specific d

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

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: file invalid or corrupt This creates frustration and support questions in the build mailing list

RFR: JDK-8056215 AWT source dirs should only point to java2d, not below

This is from a code review following the jigsaw source file restructuring: * The makefiles include too specific directories. Instead of including e.g. ./*/native/common/sun/java2d/opengl and ./*/native/common/sun/java2d/x11, we should just include ./*/native/common/sun/java2d. This level corre

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

When building with VS2010 without SP1, the build will fail with: LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt This creates frustration and support questions in the build mailing list from time to time. We should check for VS2010 without SP1 at config

Re: Size difference of Java.base image between OSX and Linux

Hello, In my build of OpenJDK 9 (updated from dev today), libjvm.so on linux x64 is 20902848B. It has been stripped using "strip -g" which means remove all debug symbols. It seems it can be reduced further to 17611752B using "strip --strip-unneeded", but I don't know if that is safe to do.

Re: RFR: JDK-8170385 JDK-8031567 broke source bundles

Looks good. /Erik On 2016-11-28 10:11, Magnus Ihse Bursie wrote: Unfortunately, the fix for JDK-8031567 got some untested last-minute changes which broke it. :-( Bug: https://bugs.openjdk.java.net/browse/JDK-8170385 Patch inline: diff --git

RFR: JDK-8170385 JDK-8031567 broke source bundles

Unfortunately, the fix for JDK-8031567 got some untested last-minute changes which broke it. :-( Bug: https://bugs.openjdk.java.net/browse/JDK-8170385 Patch inline: diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk --- a/make/Sourc