Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

2021-04-09 Thread Dean Long
On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam wrote: >> Vladimir Kozlov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > LGTM. Just a small nit. @iklam I thought the fingerprint code was also us

Re: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1

2021-07-08 Thread Dean Long
On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but > I saw following errors: > > > In file included from > /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > fr

Re: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1

2021-07-08 Thread Dean Long
On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but > I saw following errors: > > > In file included from > /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > fr

Re: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1

2021-07-08 Thread Dean Long
On Fri, 9 Jul 2021 00:28:38 GMT, Yasumasa Suenaga wrote: >> I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but >> I saw following errors: >> >> >> In file included from >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, >>

Re: RFR: 8273459: Update code segment alignment to 64 bytes

2021-09-17 Thread Dean Long
On Thu, 16 Sep 2021 13:52:24 GMT, Scott Gibbons wrote: > Change the default code entry alignment to 64 bytes from 32 bytes. This > allows for maintaining proper 64-byte alignment of data within a code > segment, which is required by several AVX-512 instructions. > > I ran into this while imp

RFR(M) 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor

2018-11-07 Thread dean . long
https://bugs.openjdk.java.net/browse/JDK-8213348 https://bugs.openjdk.java.net/browse/JDK-8211781 http://cr.openjdk.java.net/~dlong/8213348/webrev/ Added new make/gensrc/Gensrc-jdk.internal.vm.compiler.management.gmk to create module-info.java.extra for jdk.internal.vm.compiler.management.  I al

Re: RFR(M) 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor

2018-11-08 Thread dean . long
Thanks Erik. dl On 11/8/18 9:02 AM, Erik Joelsson wrote: Hello, The build changes look ok as long as Jon and Mandy are happy with how javac is invoked. /Erik On 2018-11-07 19:56, dean.l...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8213348 https://bugs.openjdk.java.net/br

Re: RFR(M) 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor

2018-11-08 Thread dean . long
I get this without --module-path:   Fatal Error: Unable to find package java.lang in classpath or bootclasspath I guess before, when it was using the unnamed module, that it was picking up these system classes from the jdk10 bootjdk, which doesn't seem ideal. It works without --upgrade-modu

Re: RFR(M) 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor

2018-11-08 Thread dean . long
On 11/8/18 11:49 AM, Mandy Chung wrote: This is strange.  upgrade module path precedes the application module path in the search path.  I would not expect --module-path would help. Sorry, the error is if I remove both --upgrade-module-path and --module-path. Putting back either one makes it

Re: RFR(M) 8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor

2018-11-08 Thread dean . long
Thanks Mandy. dl On 11/8/18 1:02 PM, Mandy Chung wrote: On 11/8/18 12:37 PM, dean.l...@oracle.com wrote: On 11/8/18 11:49 AM, Mandy Chung wrote: This is strange.  upgrade module path precedes the application module path in the search path.  I would not expect --module-path would help. So

Re: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT

2018-12-16 Thread dean . long
If we are adding JDK_EXPORT, does it make sense to add JDK_CALL as well? dl On 12/16/18 4:57 PM, David Holmes wrote: Hi Magnus, Thanks for explaining how addition of JNIEXPORT may have started this problem. One follow up: This will also need a CSR request due to the change in linking beha

Re: RFR: 8224087: Compile C code for at least C99 Standard compliance

2019-05-20 Thread dean . long
Isn't that going to break inline asm? dl On 5/20/19 3:40 PM, Erik Joelsson wrote: That sounds good to me. I missed that distinction before, but pure c99 does sound better. /Erik On 2019-05-20 15:31, David Holmes wrote: Hi Volker, Thanks for the xlc update - I will incorporate that. It has

Re: RFR(xxs): 8227170: (.hg)Ignore the JTwork and JTreport directories generated at the root of the repo

2019-07-10 Thread dean . long
The ** syntax isn't working for me in Mercurial 2.9, but the following: syntax: glob JTreport/* JTwork/* seems to work in both 2.9 and 4.6.1.  This also seems to work: syntax: glob JTreport JTwork but it matches files and not just directories. dl On 7/10/19 4:48 AM, Jaikiran Pai wrote: Ping

RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed

2019-10-04 Thread dean . long
https://bugs.openjdk.java.net/browse/JDK-8231902 http://cr.openjdk.java.net/~dlong/8231902/webrev/ A recent upstream Graal change causes the META-INF/providers directory to contain only a single file, causing the $(GREP) command to not prepend the filename to the output.  The simple fix is to c

Re: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed

2019-10-04 Thread dean . long
Here's an alternative version with $(NAWK) usage suggested by Erik Joelsson: http://cr.openjdk.java.net/~dlong/8231902/webrev.2/ dl On 10/4/19 12:29 PM, dean.l...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8231902 http://cr.openjdk.java.net/~dlong/8231902/webrev/ A recent upst

Re: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed

2019-10-04 Thread dean . long
Thanks Vladimir. dl On 10/4/19 1:03 PM, Vladimir Kozlov wrote: Good. Thanks Vladimir On Oct 4, 2019, at 12:29 PM, dean.l...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8231902 http://cr.openjdk.java.net/~dlong/8231902/webrev/ A recent upstream Graal change causes the META-IN

Re: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed

2019-10-07 Thread dean . long
Thanks Magnus and Erik! dl On 10/7/19 8:20 AM, Erik Joelsson wrote: Looks good! Thanks! /Erik On 2019-10-04 15:09, dean.l...@oracle.com wrote: Here's an alternative version with $(NAWK) usage suggested by Erik Joelsson: http://cr.openjdk.java.net/~dlong/8231902/webrev.2/ dl On 10/4/19 12

Request for approval: Backport of 8031064(XS)

2015-02-02 Thread Dean Long
I would like to backport 8031064 to 8u60: https://bugs.openjdk.java.net/browse/JDK-8031064 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/72904af52714 It has been baking in jdk9 for over a week, and the patch applied cleanly except for the copyright year. dl

Re: Request for approval: Backport of 8031064(XS)

2015-02-02 Thread Dean Long
Thanks David. dl On 2/2/2015 5:19 PM, David Holmes wrote: On 3/02/2015 9:26 AM, Dean Long wrote: I would like to backport 8031064 to 8u60: https://bugs.openjdk.java.net/browse/JDK-8031064 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/72904af52714 It has been baking in jdk9 for over

Re: RFR: JDK-8072904: building jdk9 with jdk9 boot jdk can cause failure or incorrect results

2015-02-17 Thread Dean Long
Looks good to me too. dl On 2/11/2015 12:11 PM, David Holmes wrote: On 11/02/2015 9:35 PM, Erik Joelsson wrote: Hello, New webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.02/ On 2015-02-11 10:53, David Holmes wrote: Hi Erik, On 11/02/2015 7:23 PM, Erik Joelsson wrote: Hel

Re: RFR: JDK-8075140: Solaris build of native libraries not consistently using EXTRA_CFLAGS and EXTRA_LDFLAGS

2015-03-14 Thread Dean Long
On 3/13/2015 5:08 PM, David Holmes wrote: Hi Erik, On 14/03/2015 12:08 AM, Erik Joelsson wrote: Hello, While working on the new Hotspot makefiles in build-infra I noticed this problem. When introducing devkits for Solaris, we rely on the variables EXTRA_CFLAGS, EXTRA_CXXFLAGS and EXTRA_LDFLAGS

Re: RFR: 8072740: move closed jvm.cfg files out of open repo

2015-03-25 Thread Dean Long
te: bug: https://bugs.openjdk.java.net/browse/JDK-8072740 webrev: http://cr.openjdk.java.net/~dholmes/8072740/webrev/ Simple fix, contributed by Dean Long, that allows the jvm.cfg file to be located in the "closed" location. The arm and ppc jvm.cfg files can then be moved to that "closed" location. Thanks, David

Re: RFR (XS) 8033946 - Hotspot build should ignore "ide" folder

2014-09-04 Thread Dean Long
Wouldn't it be better to replace $(HOTSPOT_TOPDIR) with $(HOTSPOT_TOPDIRS), so we don't even search in top-level directories that aren't interesting? dl On 9/4/2014 9:45 AM, Gerard Ziemski wrote: hi all, Please review a very small fix that makes hotspot build ignore "ide" folder, which is wh

Re: RFR: AARCH64: Top-level JDK changes

2014-11-14 Thread Dean Long
On 11/14/2014 12:39 AM, Magnus Ihse Bursie wrote: 13 nov 2014 kl. 19:33 skrev Christian Thalinger : On Nov 13, 2014, at 6:09 AM, Magnus Ihse Bursie wrote: On 2014-11-10 11:32, Volker Simonis wrote: On Mon, Nov 10, 2014 at 10:42 AM, Erik Joelsson wrote: On 2014-11-10 10:27, Volker Simoni

Re: RFR: AARCH64: Top-level JDK changes

2014-11-17 Thread Dean Long
On 11/17/2014 4:59 PM, Christian Thalinger wrote: On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie wrote: On 2014-11-14 21:44, Dean Long wrote: The distribution exception is there exactly since anyone should be able to distribute the files with their configure script. That does not mean that

Re: RFR: AARCH64: 8064357: Top-level JDK changes

2014-11-21 Thread Dean Long
One minor comment: do we want to preserve the history in the new config.sub, or check it in as a new file? dl On 11/21/2014 10:03 AM, Magnus Ihse Bursie wrote: On 2014-11-21 18:02, Andrew Haley wrote: On 11/21/2014 03:46 PM, Magnus Ihse Bursie wrote: 1) Comment in config.sub identifies it

Re: RFR: AARCH64: 8064357: Top-level JDK changes

2014-11-21 Thread Dean Long
ild-infra: nonstandard copyright headers under common/autoconf/build-aux changeset: 423:e1830598f0b7 parent: 417:42f275168fa5 user:ohair date:Tue Apr 10 08:18:28 2012 -0700 summary: 7074397: Build infrastructure changes (makefile re-write) Thanks, Vladimir On 11/21/

Re: RFR: AARCH64: 8064357: Top-level JDK changes

2014-11-21 Thread Dean Long
/generated-configure.sh M common/autoconf/jdk-options.m4 M common/autoconf/platform.m4 A common/autoconf/build-aux/autoconf-config.sub R common/autoconf/build-aux/config.sub And webrev shows config.sub diffs vs original one and not as new file. Vladimir On 11/21/14 12:28 PM, Dean Long wrote: I wa

Re: RFR: AARCH64: Top-level JDK changes

2015-01-11 Thread Dean Long
I found a small problem with the new config.sub wrapper. It works with the bash shell but not with the dash shell. The problem seems to be with this line: result=`. $DIR/autoconf-config.sub $sub_args "$@"` "dash" doesn't seem to support args passed with ".", so $sub_args "$@" are ignored.

Re: RFR: AARCH64: Top-level JDK changes

2015-01-13 Thread Dean Long
On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote: On 2015-01-12 05:31, Dean Long wrote: I found a small problem with the new config.sub wrapper. It works with the bash shell but not with the dash shell. The problem seems to be with this line: result=`. $DIR/autoconf-config.sub $sub_args

Re: RFR: AARCH64: Top-level JDK changes

2015-01-13 Thread Dean Long
On 1/12/2015 2:25 AM, Andrew Haley wrote: On 12/01/15 04:31, Dean Long wrote: I found a small problem with the new config.sub wrapper. It works with the bash shell but not with the dash shell. The problem seems to be with this line: result=`. $DIR/autoconf-config.sub $sub_args

Re: RFR: AARCH64: Top-level JDK changes

2015-01-13 Thread Dean Long
On 1/13/2015 1:08 AM, Andrew Haley wrote: On 13/01/15 08:44, Dean Long wrote: I came up with a simpler version, where I replace "aarch64-" with "arm-", run autoconf-config.sub, then replace "arm-" back to "aarch64-". Thanks. That sounds good to me.

Re: RFR: AARCH64: Top-level JDK changes

2015-01-14 Thread Dean Long
On 1/14/2015 5:27 AM, Magnus Ihse Bursie wrote: On 2015-01-13 09:32, Dean Long wrote: On 1/12/2015 3:49 AM, Magnus Ihse Bursie wrote: On 2015-01-12 05:31, Dean Long wrote: I found a small problem with the new config.sub wrapper. It works with the bash shell but not with the dash shell. The

AARCH64: RFR (XS) 8068927: AARCH64: better handling of aarch64- triples (was RFR: AARCH64: Top-level JDK changes)

2015-01-14 Thread Dean Long
Can I get a review for this? https://bugs.openjdk.java.net/browse/JDK-8068927 http://cr.openjdk.java.net/~dlong/8068927/webrev/ thanks, dl On 1/13/2015 10:56 AM, Dean Long wrote: On 1/13/2015 1:08 AM, Andrew Haley wrote: On 13/01/15 08:44, Dean Long wrote: I came up with a simpler version

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

2015-01-15 Thread Dean Long
On 1/14/2015 11:01 PM, David Holmes wrote: On 15/01/2015 4:40 PM, Dean Long wrote: On 1/14/2015 10:31 PM, David Holmes wrote: Hi Dean, Code reviews don't go to jdk9-dev. Build-infra is not relevant to this either. You only need hotspot-dev for a hotspot build issue (though build-dev mig

Re: [aarch64-port-dev ] AARCH64: RFR (XS) 8068927: AARCH64: better handling of aarch64- triples (was RFR: AARCH64: Top-level JDK changes)

2015-01-15 Thread Dean Long
On 1/15/2015 5:41 AM, Magnus Ihse Bursie wrote: On 2015-01-15 00:34, Dean Long wrote: Can I get a review for this? https://bugs.openjdk.java.net/browse/JDK-8068927 http://cr.openjdk.java.net/~dlong/8068927/webrev/ Looks good to me. (However, I'm not a formal reviewer for the aarch64

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

2015-01-16 Thread Dean Long
On 1/15/2015 2:57 PM, Magnus Ihse Bursie wrote: On 2015-01-15 08:01, David Holmes wrote: If the build-dev guys confirm we already assume bash that is fine. For the rest of the world, we only use bash. For hotspot, we will use bash if called from the top-level Makefile. I can't say anything a

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

2015-01-20 Thread Dean Long
Here's version 2, which does everything in vm.make and doesn't do anything that is shell-specific: http://cr.openjdk.java.net/~dlong/8031064//webrev.2/ thanks, dl

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

2015-01-21 Thread Dean Long
ot;\t" $$3 ";" }' should give you the same result with less efforts -Dmitry On 2015-01-21 07:59, Dean Long wrote: Here's version 2, which does everything in vm.make and doesn't do anything that is shell-specific: http://cr.openjdk.java.net/~dlong/8031064//webrev.2/ thanks, dl

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

2015-01-22 Thread Dean Long
On 1/22/2015 2:19 AM, David Holmes wrote: On 22/01/2015 8:39 AM, Dean Long wrote: Thanks Dmitry. The updated webrev is here: http://cr.openjdk.java.net/~dlong/8031064/webrev.3/ This looks weird: + VMDEF_PAT = ^_ZTV + VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT) + VMDEF_PAT

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

2015-01-22 Thread Dean Long
Done: https://bugs.openjdk.java.net/browse/JDK-8071436 dl On 1/22/2015 10:45 PM, Dmitry Samersoff wrote: Dean, Can we make cleaning up the other platforms a separate RFE? I think yes. So please file the RFE. -Dmitry On 2015-01-22 21:01, Dean Long wrote: On 1/22/2015 2:19 AM, David

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

2015-01-22 Thread Dean Long
On 1/22/2015 11:01 PM, David Holmes wrote: On 23/01/2015 4:01 AM, Dean Long wrote: On 1/22/2015 2:19 AM, David Holmes wrote: On 22/01/2015 8:39 AM, Dean Long wrote: Thanks Dmitry. The updated webrev is here: http://cr.openjdk.java.net/~dlong/8031064/webrev.3/ This looks weird

Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile

2015-01-23 Thread Dean Long
David and Dmitry, thanks for the reviews! dl On 1/22/2015 11:41 PM, David Holmes wrote: On 23/01/2015 5:36 PM, Dean Long wrote: On 1/22/2015 11:01 PM, David Holmes wrote: On 23/01/2015 4:01 AM, Dean Long wrote: On 1/22/2015 2:19 AM, David Holmes wrote: On 22/01/2015 8:39 AM, Dean Long