Re: RFR: race with nested repos in hgforest.sh

2013-02-04 Thread Ioi Lam
How about adding a message to indicate the sleep, just in case the directory is never created for whatever reason. If you don't like too many such messages, you can print the message after the initial wait. 177 while [ ! -d "$path" ] ## nested repo, ensure containing dir exists 1

Re: OpenJDK rebuilding on windows takes a long time

2013-02-14 Thread Ioi Lam
On 02/14/2013 02:24 AM, Alexander Scherbatiy wrote: On 2/13/2013 8:45 PM, Kelly O'Hair wrote: You are pointing at the fastdebug jdk as your boot jdk, why? The official boot jdk for jdk8 is jdk7u7 we cannot guarantee anything else will work, although it should, when tracking down issues like th

Re: Dollar ($) expansion still needs attention

2013-02-27 Thread Ioi Lam
While we are cleaning this up, would it make sense to replace the maddening \ and $ with something like this? sun/awt/motif/X11GB2312${DOLLAR}Decoder.class - Ioi On 02/26/2013 06:47 PM, David Holmes wrote: So ... nashorn pushed this change: http://hg.openjdk.java.net/jdk8/tl/di

Re: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074

2021-01-04 Thread Ioi Lam
On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun wrote: > From the error log we can see the root cause is that, develop_pd flag > 'pd_CICompileOSR' is undeclared in zero build. > > Where this flag is used? > Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 > of 'compiler_globals.

Re: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074

2021-01-04 Thread Ioi Lam
On Mon, 4 Jan 2021 10:09:23 GMT, Aleksey Shipilev wrote: > It is unclear to me why the original change in JDK-8258074 included > `compiler_globals_pd.hpp` in `globals.hpp` at all, @iklam? The reason is, for historical reasons, some PD flags related to the compiler, such as `BackgroundCompilati

Re: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074

2021-01-04 Thread Ioi Lam
On Mon, 4 Jan 2021 23:39:18 GMT, Jie Fu wrote: >> src/hotspot/share/compiler/compiler_globals.hpp line 29: >> >>> 27: >>> 28: #include "compiler/compiler_globals_pd.hpp" >>> 29: #ifdef COMPILER1 >> >> `#include "runtime/globals_shared.hpp"` should not be removed. >> compiler_globals.hpp uses

Re: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale

2021-01-04 Thread Ioi Lam
On Tue, 5 Jan 2021 00:41:11 GMT, Yasumasa Suenaga wrote: >> There are probably 25 or so places in our code where we use FormatMessage to >> get the error message. Are these all going to run into the same >> FormateMessage bug? >> >> Also, it's not clear to me why you are getting garbled text i

Re: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale

2021-01-04 Thread Ioi Lam
On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga wrote: > I got garbled exception message as following when I run `livenmethods` CLHSDB > command: > > sun.jvm.hotspot.debugger.DebuggerException : ?w???W > > My Windows laptop is set Japanese Locale, garbled message was written in > Japane

Re: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale

2021-01-04 Thread Ioi Lam
On Tue, 5 Jan 2021 01:31:28 GMT, Chris Plummer wrote: > > jdk.hotspot.agent do not have `FormatMessage()` call in other place. > > Did you say about whole JDK code? I haven't checked all of them, but some > > code (e.g. net_util_md.c) uses `JNU_ThrowByName()` which is provided by > > java.dll.

Re: RFR: 8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale

2021-01-04 Thread Ioi Lam
On Tue, 5 Jan 2021 03:07:49 GMT, Chris Plummer wrote: > Given that this seems to be a common problem in our code, and likely a very > very old problem at that, why has it never been reported before? I'm not > questioning the fix except to the extent that I'm questioning our > understanding of

Re: RFR: 8258857: Zero: non-PCH release build fails after JDK-8258074 [v2]

2021-01-05 Thread Ioi Lam
On Tue, 5 Jan 2021 12:06:18 GMT, Hao Sun wrote: >> From the error log we can see the root cause is that, develop_pd flag >> 'pd_CICompileOSR' is undeclared in zero build. >> >> Where this flag is used? >> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77 >> of 'compiler_glo

Re: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2]

2021-02-01 Thread Ioi Lam
ved in > [JDK-8068976](https://bugs.openjdk.java.net/browse/JDK-8068976), so their > declarations should be removed from jvm.h Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed macos build - Changes: - all: http

Re: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2]

2021-02-01 Thread Ioi Lam
On Mon, 1 Feb 2021 20:29:10 GMT, Gerard Ziemski wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fixed macos build > > src/java.base/share/native/libjava/check_version.c line 33: >

Re: AArch64 OpenJDK bootstrap failure on head

2021-02-01 Thread Ioi Lam
On 2/1/21 9:36 AM, Thomas Stüfe wrote: This does not solve the alignment problem, but I don't like that we unconditionally print a message here since this is a non-fatal error. Also, CDS mapping may fail for other reasons, for which we do not print unconditionally. I think we should make this i

Re: [External] : Re: AArch64 OpenJDK bootstrap failure on head

2021-02-02 Thread Ioi Lam
On 2/2/21 1:32 AM, Thomas Stüfe wrote: On Mon, Feb 1, 2021 at 10:11 PM Ioi Lam <mailto:ioi@oracle.com>> wrote: On 2/1/21 9:36 AM, Thomas Stüfe wrote: This does not solve the alignment problem, but I don't like that we unconditionally print a message here s

Re: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2]

2021-02-02 Thread Ioi Lam
On Tue, 2 Feb 2021 15:59:47 GMT, Gerard Ziemski wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fixed macos build > > Marked as reviewed by gziemski (Committer). Thanks @gerard-ziemski

Integrated: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX

2021-02-02 Thread Ioi Lam
On Mon, 1 Feb 2021 18:40:54 GMT, Ioi Lam wrote: > - JVM_GetInterfaceVersion() was used by "HotSpot Express" (HSX) which allowed > the same JDK library to use different version of HotSpot. However, HSX is no > longer supported so this API should be removed. > - Implement

Re: RFR: 8260193: Remove JVM_GetInterfaceVersion() and JVM_DTraceXXX [v2]

2021-02-02 Thread Ioi Lam
On Tue, 2 Feb 2021 16:00:43 GMT, Gerard Ziemski wrote: >> I am not sure if jni_utils.c is the right file (it defines the `JNU_XXX` >> functions that are used by other shared libraries). >> >> There are other .c files that have trivial `DEF_JNI_OnLoad` functions (e.g., >> java.base/share/native

Re: RFR: 8236847: CDS archive with 4K alignment unusable on machines with 64k pages [v6]

2021-03-03 Thread Ioi Lam
On Mon, 1 Mar 2021 17:08:02 GMT, Yumin Qi wrote: >> Hi, Please review >> Usually most OSes are configured with page size of 4K, but some others are >> configured with 64K. If jdk binary is built on 4K platform and run on >> different configured platforms, CDS fails to be loaded due to region

Re: RFR: 8236847: CDS archive with 4K alignment unusable on machines with 64k pages [v6]

2021-03-04 Thread Ioi Lam
On Wed, 3 Mar 2021 20:59:28 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request with a new target base due to a merge >> or a rebase. The pull request now contains six commits: >> >> - Merge master >> - Add --enable-compatible-cds-alignment for l

Re: RFR: 8263465: JDK-8236847 causes tier1 build failure on linux-aarch64

2021-03-11 Thread Ioi Lam
On Thu, 11 Mar 2021 18:41:10 GMT, Yumin Qi wrote: > Hi, Please review > > JDK-8236847 changes failed on build linux-aarch64 on xcross build. The > reason is we check BUILD_CDS_ARCHIVE which is not correct in such case. We > should check ENABLE_CDS instead. > > Thanks > Yumin LGTM

Re: RFR: 8263914: CDS fails to find the default shared archive on x86_32 [v2]

2021-03-22 Thread Ioi Lam
On Mon, 22 Mar 2021 03:37:05 GMT, Jie Fu wrote: >> Hi all, >> >> The VM fails to get initialized when running with `java -Xshare:on -version` >> on x86_32. >> The reason is that the default shared archive (classes_nocoops.jsa) doesn't >> exist. >> So the build system should generate classes_no

RFR: 8264874: Build interim-langtools for HotSpot only if Graal is enabled

2021-04-07 Thread Ioi Lam
Many HotSpot developers make only the `hotspot` target, and copy the resulting `libjvm.so` into an already-build JDK image. HotSpot requires `interim-langtools` only when Graal is enabled. When Graal is disabled, we can avoid building `interim-langtools`. This improves the build time of `make h

Re: RFR: 8264874: Build interim-langtools for HotSpot only if Graal is enabled

2021-04-08 Thread Ioi Lam
On Thu, 8 Apr 2021 01:13:45 GMT, Vladimir Kozlov wrote: >> Many HotSpot developers make only the `hotspot` target, and copy the >> resulting `libjvm.so` into an already-build JDK image. >> >> HotSpot requires `interim-langtools` only when Graal is enabled. When Graal >> is disabled, we can avo

Integrated: 8264874: Build interim-langtools for HotSpot only if Graal is enabled

2021-04-08 Thread Ioi Lam
On Wed, 7 Apr 2021 22:37:28 GMT, Ioi Lam wrote: > Many HotSpot developers make only the `hotspot` target, and copy the > resulting `libjvm.so` into an already-build JDK image. > > HotSpot requires `interim-langtools` only when Graal is enabled. When Graal > is disabled, we can

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

2021-04-09 Thread Ioi Lam
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related >> to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module — the `jaotc` tool >> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution

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

2021-04-09 Thread Ioi Lam
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 >

RFR: 8265696 move cds sources

2021-04-21 Thread Ioi Lam
The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. - src/hotspot/share/classfile/classListParser.cpp - src/hotspot/share/classfile/classListParser.hpp - src/hotspot/share/classfile/classListWr

Re: RFR: 8265696 move cds sources

2021-04-21 Thread Ioi Lam
On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve > modularity, the following files should be moved a new directory, > src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > -

Re: RFR: 8265696 move cds sources [v2]

2021-04-21 Thread Ioi Lam
s/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and > builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request incrementally with two

Re: RFR: 8265696 move cds sources [v2]

2021-04-21 Thread Ioi Lam
On Thu, 22 Apr 2021 04:14:38 GMT, David Holmes wrote: >> Thank you! > > I don't suppose we can just exclude the new directory rather than listing > individual files? Fixed. Now all files under share/cds are excluded. I needed to move compactHashtable.cpp back to its old location since a little

Re: RFR: 8265696 move cds sources [v2]

2021-04-21 Thread Ioi Lam
On Thu, 22 Apr 2021 06:10:17 GMT, Thomas Stuefe wrote: > Hi @iklam, > > this is a very welcome change! > > Nothing much to add to what David wrote (include guards need renaming). > > Apart from that, I was surprised that no gtests needed to be adapted, but > seems cds has no gtests? > > I te

Re: RFR: 8265696 move cds sources [v2]

2021-04-21 Thread Ioi Lam
On Thu, 22 Apr 2021 04:16:57 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - exclude all files under shared/cds if CDS is disabled; >> compactHashtable.cpp cannot be

Re: RFR: 8265696 move cds sources [v3]

2021-04-21 Thread Ioi Lam
s/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and > builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or

Re: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v4]

2021-04-22 Thread Ioi Lam
s/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and > builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or

Re: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v5]

2021-04-22 Thread Ioi Lam
s/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and > builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or

Re: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v6]

2021-04-22 Thread Ioi Lam
s/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and > builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or

Integrated: 8265696: Move CDS sources to src/hotspot/shared/cds

2021-04-22 Thread Ioi Lam
On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve > modularity, the following files should be moved a new directory, > src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > -

Re: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v6]

2021-04-22 Thread Ioi Lam
On Thu, 22 Apr 2021 06:10:17 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains 11

Re: RFR: 8265403: consolidate definition of CPU features [v4]

2021-04-23 Thread Ioi Lam
On Mon, 19 Apr 2021 19:56:45 GMT, Doug Simon wrote: >> While porting >> [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I >> noticed that new CPU features were defined for x86 and AArch64 without being >> exposed via JVMCI. To avoid this problem in future, this PR upd

Re: RFR: 8268821: Split systemDictionaryShared.cpp [v4]

2021-06-28 Thread Ioi Lam
On Fri, 25 Jun 2021 01:15:29 GMT, Yumin Qi wrote: >> Hi, Please review >> systemDictionaryShared becomes fatter and fatter so it is time to split it >> into functional files. Moved security and jar operation related code into >> CDSProtectionDomain, and moved shared class info (DumpTime/RunTime

RFR: 8272113: Build compare script fails with differences in classlist

2021-08-07 Thread Ioi Lam
The CDS classlist is generated with the `-XX:DumpLoadedClassList` option, which writes the name of the classes as they are being loaded. Since class loading order is affected by thread switching, the classes may appear in a non-deterministic order. Previously, the build compare script would sor

Re: RFR: 8272113: Build compare script fails with differences in classlist

2021-08-09 Thread Ioi Lam
On Mon, 9 Aug 2021 08:14:44 GMT, Thomas Schatzl wrote: >> The CDS classlist is generated with the `-XX:DumpLoadedClassList` option, >> which writes the name of the classes as they are being loaded. Since class >> loading order is affected by thread switching, the classes may appear in a >> non

Integrated: 8272113: Build compare script fails with differences in classlist

2021-08-09 Thread Ioi Lam
On Sat, 7 Aug 2021 07:25:01 GMT, Ioi Lam wrote: > The CDS classlist is generated with the `-XX:DumpLoadedClassList` option, > which writes the name of the classes as they are being loaded. Since class > loading order is affected by thread switching, the classes may appear in

RFR: 8273092: Sort classlist in JDK image

2021-08-27 Thread Ioi Lam
When the classlist is generated using build.tools.classlist.HelloClasslist, its contents may be non-deterministic due to Java thread execution order. We should sort the generated classlist to make the JDK image's contents more deterministic. Tested with Mach5 tier1, tier2, builds-tier5 ---

Re: RFR: 8273092: Sort classlist in JDK image [v2]

2021-08-30 Thread Ioi Lam
Mach5 tier1, tier2, builds-tier5 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dfuch comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/5288/files - new: https://git.openjdk.java.net/jdk/pull/5288/files/d

Re: RFR: 8273092: Sort classlist in JDK image [v2]

2021-08-30 Thread Ioi Lam
On Mon, 30 Aug 2021 12:51:43 GMT, Daniel Fuchs wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> @dfuch comments > > make/jdk/src/classes/build/tools/classlist/SortClasslist.java line 58

Re: RFR: 8273092: Sort classlist in JDK image [v2]

2021-08-31 Thread Ioi Lam
On Sat, 28 Aug 2021 13:18:37 GMT, Claes Redestad wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> @dfuch comments > > Seems OK. Thanks @cl4es @magicus @dfuch for the rev

Integrated: 8273092: Sort classlist in JDK image

2021-08-31 Thread Ioi Lam
On Fri, 27 Aug 2021 23:12:52 GMT, Ioi Lam wrote: > When the classlist is generated using build.tools.classlist.HelloClasslist, > its contents may be non-deterministic due to Java thread execution order. > > We should sort the generated classlist to make the JDK image

Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern

2021-09-30 Thread Ioi Lam
On Thu, 30 Sep 2021 08:31:51 GMT, Jie Fu wrote: > > `RANGEBASE` was added by > > [JDK-6500501](https://bugs.openjdk.java.net/browse/JDK-6500501) and later > > was modified by > > [JDK-8027829](https://bugs.openjdk.java.net/browse/JDK-8027829) > > Note the original comment from 6500501: > > ```

Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern

2021-09-30 Thread Ioi Lam
On Sun, 26 Sep 2021 09:55:00 GMT, Jie Fu wrote: > Hi all, > > I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019). > However, I failed with C4474 and C4778 warnings as below: > > Compiling 100 properties into resource bundles for java.desktop > Compiling 3038 files for java.base > e:\jie

Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern

2021-09-30 Thread Ioi Lam
On Thu, 30 Sep 2021 23:04:17 GMT, Jie Fu wrote: > I will do your experiment next week. This is because it's already our > National Day week and I can't find an English Windows machine until next > week. I'll let you know the result as soon as possible. Thanks. No need to hurry :-). In case you

Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern

2021-10-04 Thread Ioi Lam
On Sun, 26 Sep 2021 09:55:00 GMT, Jie Fu wrote: > Hi all, > > I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019). > However, I failed with C4474 and C4778 warnings as below: > > Compiling 100 properties into resource bundles for java.desktop > Compiling 3038 files for java.base > e:\jie

Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern [v2]

2021-10-05 Thread Ioi Lam
On Wed, 6 Oct 2021 02:33:30 GMT, Jie Fu wrote: >> Hi all, >> >> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019). >> However, I failed with C4474 and C4778 warnings as below: >> >> Compiling 100 properties into resource bundles for java.desktop >> Compiling 3038 files for java.base >>

Re: RFR: 8274329: Fix non-portable HotSpot code in MethodMatcher::parse_method_pattern [v3]

2021-10-05 Thread Ioi Lam
On Wed, 6 Oct 2021 05:17:28 GMT, Jie Fu wrote: >> Hi all, >> >> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019). >> However, I failed with C4474 and C4778 warnings as below: >> >> Compiling 100 properties into resource bundles for java.desktop >> Compiling 3038 files for java.base >>

Re: Does CDS archive generation work for crossbuilds?

2021-10-28 Thread Ioi Lam
How reliable would it be to use qemu to run the cross-compiled binaries? Has anyone tried that recently? On 10/23/21 5:48 AM, Thomas Stüfe wrote: Hi Alan, On Sat, Oct 23, 2021 at 9:58 AM Alan Bateman wrote: On 23/10/2021 07:57, Thomas Stüfe wrote: Hi, when I crossbuild (for linux aarch6

Re: Does CDS archive generation work for crossbuilds?

2021-11-07 Thread Ioi Lam
org/docs/master/user/main.html [2] https://github.com/openjdk/jdk/blob/master/.github/workflows/submit.yml#L514 On 10/29/21 14:35, Magnus Ihse Bursie wrote: On 2021-10-28 22:56, Ioi Lam wrote: How reliable would it be to use qemu to run the cross-compiled binaries? Has anyone tried that rece

RFR: 8253495: CDS generates non-deterministic output

2022-03-08 Thread Ioi Lam
This patch makes the result of "java -Xshare:dump" deterministic: - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp - Fixed a problem in hashtable ordering in heapShared.cpp - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-08 Thread Ioi Lam
tps://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, > windows-x86-cmp-baseline, etc). Ioi Lam has updated the pull request incrementally with one additional commit since t

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-08 Thread Ioi Lam
On Wed, 9 Mar 2022 06:49:02 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed zero build > > src/hotspot/share/prims/jvm.cpp line 2873: > >> 2871: // e

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-08 Thread Ioi Lam
On Wed, 9 Mar 2022 07:04:56 GMT, David Holmes wrote: > I have reservations about contorting things this way just to get > "deterministic output". > > The VM needs to fully initialize and then become quiescent before the dump > occurs, and as I say below if you don't start other threads then yo

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-10 Thread Ioi Lam
On Thu, 10 Mar 2022 13:51:56 GMT, Magnus Ihse Bursie wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed zero build > > I think he already did. I'm quoting: > >> Howeve

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-10 Thread Ioi Lam
On Wed, 9 Mar 2022 07:51:46 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed zero build > > src/hotspot/share/prims/jvm.cpp line 2887: > >> 2885:

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-10 Thread Ioi Lam
On Thu, 10 Mar 2022 13:51:56 GMT, Magnus Ihse Bursie wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed zero build > > I think he already did. I'm quoting: > >> Howeve

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-10 Thread Ioi Lam
On Wed, 9 Mar 2022 07:47:19 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed zero build > > src/hotspot/share/utilities/hashtable.hpp line 42: > >> 40

Re: RFR: 8253495: CDS generates non-deterministic output [v3]

2022-03-10 Thread Ioi Lam
tps://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, > windows-x86-cmp-baseline, etc). Ioi Lam has updated the pull request incrementally with one additional commit sinc

Re: RFR: 8253495: CDS generates non-deterministic output [v4]

2022-03-10 Thread Ioi Lam
tps://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, > windows-x86-cmp-baseline, etc). Ioi Lam has updated the pull request incrementally with one additional c

Re: RFR: 8253495: CDS generates non-deterministic output [v5]

2022-03-10 Thread Ioi Lam
tps://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, > windows-x86-cmp-baseline, etc). Ioi Lam has updated the pull request incrementally with one additional commit since the l

Re: RFR: 8253495: CDS generates non-deterministic output [v4]

2022-03-10 Thread Ioi Lam
On Fri, 11 Mar 2022 05:55:20 GMT, Kim Barrett wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> zero GC heap filler arrays > > src/hotspot/share/gc/shared/collectedHeap.cpp line 449: >

Re: RFR: 8253495: CDS generates non-deterministic output

2022-03-10 Thread Ioi Lam
On Fri, 11 Mar 2022 05:59:00 GMT, David Holmes wrote: > > I ended up changing `os::malloc()` to zero the buffer when running with > > -Xshare:dump. Hopefully one extra check of `if (DumpSharedSpaces)` doesn't > > matter too much for regular VM executions because `os::malloc()` already > > has

Re: RFR: 8253495: CDS generates non-deterministic output [v6]

2022-03-10 Thread Ioi Lam
tps://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, > windows-x86-cmp-baseline, etc). Ioi Lam has updated the pull request incrementally with one additional commit si

Re: RFR: 8253495: CDS generates non-deterministic output [v2]

2022-03-11 Thread Ioi Lam
On Fri, 11 Mar 2022 07:13:35 GMT, Thomas Stuefe wrote: > Is reproducibility also a topic for users calling -Xdump with custom JNI > coding? Or maybe having the VM instrumented somehow? Since it seems such an > easy fix, I would prevent attaching too. At least the user would get a clear > error

Re: RFR: 8253495: CDS generates non-deterministic output [v7]

2022-03-15 Thread Ioi Lam
tps://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, > windows-x86-cmp-baseline, etc). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase.

Re: RFR: 8253495: CDS generates non-deterministic output [v6]

2022-03-15 Thread Ioi Lam
On Mon, 14 Mar 2022 22:07:24 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added helper function CollectedHeap::zap_filler_array_with > > test/hotspot/jt

Re: RFR: 8253495: CDS generates non-deterministic output [v8]

2022-03-15 Thread Ioi Lam
tps://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, > windows-x86-cmp-baseline, etc). Ioi Lam has updated the pull request incrementally with one additional commit since th

Integrated: 8253495: CDS generates non-deterministic output

2022-03-15 Thread Ioi Lam
On Tue, 8 Mar 2022 19:11:02 GMT, Ioi Lam wrote: > This patch makes the result of "java -Xshare:dump" deterministic: > - Disabled new Java threads from launching. This is harmless. See comments in > jvm.cpp > - Fixed a problem in hashtable ordering in heapShared.cpp > -

RFR: 8282828: CDS uncompressed oops archive is not deterministic

2022-04-29 Thread Ioi Lam
During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java heap is chosen by the OS. Due to Address Space Layout Randomization, the heap will always start at a different location. This causes the archive for uncompressed oops ($JAVA_HOME/lib/server/classes_nocoops.jsa) to be no

Re: RFR: 8282828: CDS uncompressed oops archive is not deterministic

2022-04-29 Thread Ioi Lam
On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java > heap is chosen by the OS. Due to Address Space Layout Randomization, the heap > will always start at a different location. This causes the ar

Re: RFR: 8282828: CDS uncompressed oops archive is not deterministic [v2]

2022-05-02 Thread Ioi Lam
be patched again according to the real > location of the heap. > > Tested with tiers 1-5. I am running builds-tier5 several times to test the > xxx-cmp-baseline builds. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the

Re: RFR: 8282828: CDS uncompressed oops archive is not deterministic [v2]

2022-05-02 Thread Ioi Lam
On Mon, 2 May 2022 12:56:36 GMT, Erik Joelsson wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains two

Integrated: 8282828: CDS uncompressed oops archive is not deterministic

2022-05-02 Thread Ioi Lam
On Fri, 29 Apr 2022 22:50:45 GMT, Ioi Lam wrote: > During `java -Xshare:dump -XX:-UseCompressedOops`, the location of the Java > heap is chosen by the OS. Due to Address Space Layout Randomization, the heap > will always start at a different location. This causes the ar

Re: pre-submit tests for github PRs

2022-05-23 Thread Ioi Lam
On 5/23/2022 4:41 AM, Alan Bateman wrote: On 22/05/2022 23:58, David Holmes wrote: GHA tests a range of OpenJDK ports, not just the "mainstream platforms". The existing linux-86 failures (and others) are due to the Loom integration which only fully supports a couple of platforms and which

Re: RFR: 8287828: Fix so that one can select jtreg test case by ID from make

2022-06-06 Thread Ioi Lam
On Mon, 6 Jun 2022 10:48:05 GMT, David Holmes wrote: > Let me ask the obvious "dumb" question ... why does this have to be so > complicated? Why isn't the name of the test simply passed through to jtreg as > typed? Is it because `#` is treated as comment by the shell? Could it be encoded by s

Re: RFR: 8287828: Fix so that one can select jtreg test case by ID from make [v4]

2022-06-07 Thread Ioi Lam
On Tue, 7 Jun 2022 17:39:14 GMT, Leo Korinth wrote: >> One can select a testcase by ID when running a jtreg test case directly from >> jtreg (using the testcase.java#testID syntax). However, this has not been >> possible to do when launching jtreg indirectly from make. >> >> This fix attempts

Re: RFR: JDK-8188312 Use CDS if present when running the Boot JDK during build

2017-10-03 Thread Ioi Lam
If you use SharedArchiveFile, you should set -XX:-VerifySharedSpaces at the same time. Long story short -- for security, we don't want bad archives to be mapped into the JVM. If you don't specify SharedArchiveFile, the archive is loaded form the JDK installation directory, and we trust that

Re: RFR: JDK-8188312 Use CDS if present when running the Boot JDK during build

2017-10-04 Thread Ioi Lam
On 10/4/17 2:01 AM, Magnus Ihse Bursie wrote: On 2017-10-04 10:47, Magnus Ihse Bursie wrote: On 2017-10-04 02:36, Ioi Lam wrote: If you use SharedArchiveFile, you should set -XX:-VerifySharedSpaces at the same time. Long story short -- for security, we don't want bad archives

Re: RFR: JDK-8188312 Use CDS if present when running the Boot JDK during build

2017-10-05 Thread Ioi Lam
On 10/5/17 2:35 AM, Magnus Ihse Bursie wrote: On 2017-10-05 11:07, Claes Redestad wrote: On 2017-10-05 10:59, Magnus Ihse Bursie wrote: How often is -Xbootclasspath/p used? Why not use "-XX:-VerifySharedSpaces -XX:SharedArchiveFile=local.jsa -Xshare:auto"? That way you will have the star

Re: RFR: JDK-8188312 Use CDS if present when running the Boot JDK during build

2017-10-06 Thread Ioi Lam
On 10/6/17 2:04 AM, Magnus Ihse Bursie wrote: On 2017-10-05 18:08, Ioi Lam wrote: On 10/5/17 2:35 AM, Magnus Ihse Bursie wrote: On 2017-10-05 11:07, Claes Redestad wrote: On 2017-10-05 10:59, Magnus Ihse Bursie wrote: How often is -Xbootclasspath/p used? Why not use &quo

slowproduct build

2018-04-09 Thread Ioi Lam
Sometimes I want to debug the product build (I can't bother with turning off all the trueInDebug options in the hotspot globals.hpp). The only way that I have found to do this is:     configure --with-native-debug-symbols=internal     mv spec.gmk spec.gmk.old     cat spec.gmk | sed -e 's/[-]O[0

Re: slowproduct build

2018-04-10 Thread Ioi Lam
roduct defaults? > > I can see that this could make sense in certain scenarios. > > ..Thomas > >> On Tue, Apr 10, 2018 at 10:27 PM, Magnus Ihse Bursie >> wrote: >>> On 2018-04-10 02:00, Ioi Lam wrote: >>> Sometimes I want to debug the product build (I ca

Re: slowproduct build

2018-04-10 Thread Ioi Lam
On 4/10/18 2:21 PM, Magnus Ihse Bursie wrote: On 2018-04-10 23:08, Ioi Lam wrote: Yes that’s what I want. Yesterday I was using gdb to step into the interpreter generation code to see what’s generated for a particular routine for MethodHandles. The debug build contains a LOT of runtime

Re: RFR: 8193213 & 8182731: Make the UseAppCDS option obsolete

2018-04-25 Thread Ioi Lam
Hi Jiangli, The code changes look good to me. I agree with David's comments about the test cases. Thanks - Ioi On 4/24/18 11:17 PM, David Holmes wrote: cc'ing build-dev for the makefile change Hi Jiangli, On 25/04/2018 10:53 AM, Jiangli Zhou wrote: Please review the following changes tha

Re: RFR(L): 8202035: Archive the set of ModuleDescriptor and ModuleReference objects for system modules

2018-07-05 Thread Ioi Lam
Hi Jiangli, Thank you so much for working on this. I think it's great that we can get the start-up improvement by archiving the ModuleDescriptor. I just have some coding style comments regarding heapShared.cpp. This file contains the code for coping objects and relocating pointers. By its natu

Re: [Newbie question] Strange errors trying to build the JDK

2018-08-21 Thread Ioi Lam
I am not sure if this is documented anywhere. Try searching for "Error 2". It usually will tell you where the error is. Thanks - Ioi On 8/21/18 4:51 PM, Gustavo Romero wrote: Hi, On 08/21/2018 08:00 PM, David Holmes wrote: Hi, You need to search further up the build log to try and find the

Re: [Newbie question] Strange errors trying to build the JDK

2018-08-22 Thread Ioi Lam
Looks like it's this command that failed: cd /home/zambonifofex/jdk/build/linux-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs && \   /usr/bin/nm --defined-only *.o | /usr/bin/nawk '{ if ($3 ~ /^_ZTV|^gHotSpotVM|^UseSharedSpaces$|^_ZN9Arguments17SharedArchivePathE$/) print $

Re: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary

2018-08-28 Thread Ioi Lam
The JVM and test changes look good. I just have one comment: CheckDefaultArchiveFile.java   51  if (!Platform.isDefaultCDSArchiveSupported()) {   52 if (Files.notExists(jsa)) {   53 System.out.println("Passed. " + vmString +   54  

Re: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary

2018-08-28 Thread Ioi Lam
Looks good. Thanks! - Ioi On 8/28/18 6:32 PM, Jiangli Zhou wrote: Here is the updated webre with CheckDefaultArchiveFile.java changes.   http://cr.openjdk.java.net/~jiangli/8202951/webrev.01/ Thanks, Jiangli On 8/28/18 11:09 AM, Jiangli Zhou wrote: On 8/28/18 9:33 AM, Ioi Lam wrote: The

Re: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS

2018-10-08 Thread Ioi Lam
Looks good. Thanks for fixing this! - Ioi On 10/8/18 3:10 AM, Volker Simonis wrote: Hi Martin, Goetz, thanks for reviewing my patch! As Aleksey posted a similar patch for fixing the Zero build I've extended my patch to handle zero/minimal/core as well. In fact the patch now disables CDS on A

Stop using precompiled headers for Linux?

2018-10-30 Thread Ioi Lam
Is there any advantage of using precompiled headers on Linux? It's on by default and we keep having breakage where someone would forget to add #include. The latest instance is JDK-8213148. I just turn on precompiled headers explicitly in all my builds. I don't see any difference in build time

Re: Stop using precompiled headers for Linux?

2018-11-01 Thread Ioi Lam
Just a stupid question. Does GCC have actual support for PCH? I know windows can load pre-compiled information from a special binary file. Does GCC support that kind of functionality? Thanks Ioi > On Nov 1, 2018, at 5:09 AM, Magnus Ihse Bursie > wrote: > > > >> On 2018-11-01 12:51, Thomas

  1   2   >