On Thu, 29 Aug 2024 09:28:50 GMT, Stefan Karlsson wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bit counts in GCForwarding
>
> src/hotspot/share/cds/archiveHeapWriter.cpp line 214:
>
>> 212: oopDesc::s
On Mon, 24 Jun 2024 17:21:18 GMT, Ioi Lam wrote:
> Resolve `CONSTANT_MethodRef` entries during CDS dump time to improve start-up
> performance.
>
> - This PR uses the same framework introduced in #19355 and just added
> handling for methods.
> - Support for getstatic/puts
On Wed, 26 Jun 2024 18:17:00 GMT, Matias Saavedra Silva
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 contai
; [JDK-8334898](https://bugs.openjdk.org/browse/JDK-8334898)
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 five additional commits since the last
On Tue, 25 Jun 2024 16:45:49 GMT, Matias Saavedra Silva
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 contai
On Mon, 24 Jun 2024 20:23:30 GMT, Matias Saavedra Silva
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 contai
; [JDK-8334898](https://bugs.openjdk.org/browse/JDK-8334898)
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 four additional commits since the last
On Tue, 25 Jun 2024 23:24:59 GMT, Calvin Cheung 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 four
On Mon, 24 Jun 2024 21:22:48 GMT, Ioi Lam wrote:
> More filtering is needed when building the default archive in the JDK:
> constant pool resolution when running the
> `build.tools.classlist.HelloClasslist` program is not deterministic (due to
> concurrency in core library cl
On Mon, 24 Jun 2024 21:50:37 GMT, Calvin Cheung wrote:
>> More filtering is needed when building the default archive in the JDK:
>> constant pool resolution when running the
>> `build.tools.classlist.HelloClasslist` program is not deterministic (due to
>> concurrency in core library classes).
On Mon, 24 Jun 2024 17:21:18 GMT, Ioi Lam wrote:
> Resolve `CONSTANT_MethodRef` entries during CDS dump time to improve start-up
> performance.
>
> - This PR uses the same framework introduced in #19355 and just added
> handling for methods.
> - Support for getstatic/puts
More filtering is needed when building the default archive in the JDK: constant
pool resolution when running the `build.tools.classlist.HelloClasslist` program
is not deterministic (due to concurrency in core library classes). This could
cause different values in the `@cp` lines in the classlist
Resolve `CONSTANT_MethodRef` entries during CDS dump time to improve start-up
performance.
- This PR uses the same framework introduced in #19355 and just added handling
for methods.
- More filtering is needed when building the default archive in the JDK:
constant pool resolution when running t
On Wed, 22 May 2024 21:48:44 GMT, Ioi Lam wrote:
> ### Overview
>
> This PR archives `CONSTANT_FieldRef` entries in the _resolved_ state when
> it's safe to do so.
>
> I.e., when a `CONSTANT_FieldRef` constant pool entry in class `A` refers to a
> *non-static* fi
On Thu, 23 May 2024 12:36:55 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
Limitations
>
> - For safety, we limit this optimization to only classes loaded by the boot,
> platform, and app class loaders. This may be relaxed in the future.
> - We archive only the constant pool entries that are actually resolved during
> the training run. We don't s
Limitations
>
> - For safety, we limit this optimization to only classes loaded by the boot,
> platform, and app class loaders. This may be relaxed in the future.
> - We archive only the constant pool entries that are actually resolved during
> the training run. We don't spec
Limitations
>
> - For safety, we limit this optimization to only classes loaded by the boot,
> platform, and app class loaders. This may be relaxed in the future.
> - We archive only the constant pool entries that are actually resolved during
> the training run. We don't spec
Limitations
>
> - For safety, we limit this optimization to only classes loaded by the boot,
> platform, and app class loaders. This may be relaxed in the future.
> - We archive only the constant pool entries that are actually resolved during
> the training run. We don't s
Limitations
>
> - For safety, we limit this optimization to only classes loaded by the boot,
> platform, and app class loaders. This may be relaxed in the future.
> - We archive only the constant pool entries that are actually resolved during
> the training run. We don't spec
On Fri, 31 May 2024 18:43:49 GMT, Ioi Lam wrote:
>> The current algorithm says:
>>
>> for each bytecode in each method:
>> switch(bytecode) {
>> case getfield:
>> case outfield:
>> InterpreterRuntime::resolve_get_put(bc, raw_index, mh,
On Fri, 31 May 2024 12:21:09 GMT, Dan Heidinga wrote:
>> If you look at the version in the Leyden repo, there are many different
>> types of references that are handled in
>> `ClassPrelinker::maybe_resolve_fmi_ref`
>>
>> https://github.com/openjdk/leyden/blob/4faa72029abb86b55cb33b00acf9f3a18a
On Thu, 30 May 2024 04:15:24 GMT, Dan Heidinga wrote:
>> `preresolve_list` has the original CP indices (E.g., `putfield #123` as
>> stored in the classfile), but in HotSpot, after bytecode rewriting, the u2
>> following the bytecode is changed to an index into the
>> `cpcache()->_resolved_fiel
On Wed, 29 May 2024 12:53:57 GMT, Dan Heidinga 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 five
Limitations
>
> - For safety, we limit this optimization to only classes loaded by the boot,
> platform, and app class loaders. This may be relaxed in the future.
> - We archive only the constant pool entries that are actually resolved during
> the training run. We don't spec
On Thu, 23 May 2024 20:50:47 GMT, Matias Saavedra Silva
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 conta
Limitations
>
> - For safety, we limit this optimization to only classes loaded by the boot,
> platform, and app class loaders. This may be relaxed in the future.
> - We archive only the constant pool entries that are actually resolved during
> the training run. We don't s
On Thu, 23 May 2024 20:28:49 GMT, Matias Saavedra Silva
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 conta
On Wed, 22 May 2024 21:48:44 GMT, Ioi Lam wrote:
> ### Overview
>
> This PR archives `CONSTANT_FieldRef` entries in the _resolved_ state when
> it's safe to do so.
>
> I.e., when a `CONSTANT_FieldRef` constant pool entry in class `A` refers to a
> *non-static* fi
Limitations
>
> - For safety, we limit this optimization to only classes loaded by the boot,
> platform, and app class loaders. This may be relaxed in the future.
> - We archive only the constant pool entries that are actually resolved during
> the training run. We don't s
This PR tries store CONSTANT_FieldRef entries in the resolved state whenever
it's safe to do so.
I.e., when a constant pool entry in class `A` refers to a *non-static* field
`B.F`,
- `B` must be the same class as `A`; or
- `B` is a supertype of `A`; or
- `B` is one of the
[vmClasses](https://g
On Wed, 8 May 2024 15:14:16 GMT, Thomas Stuefe wrote:
> On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K,
> and (when run on Mac M1 hardware) 16K.
>
> Since forgetting to specify `--enable-compatible-cds-alignment` is a common
> error that is only noticed when running
On Wed, 15 Feb 2023 21:21:47 GMT, Justin King wrote:
>> Update MSVC CFlags to be more consistent with other compilers. Also disables
>> RTTI in a simliar manner to GCC/Clang for the JVM.
>
> Justin King has updated the pull request incrementally with one additional
> commit since the last revis
On Thu, 19 Jan 2023 20:10:23 GMT, Matias Saavedra Silva
wrote:
>> This is an enhancement of the test case in
>> [JDK-8296754](https://bugs.openjdk.org/browse/JDK-8296754), which tests
>> against an archive created by the "boot JDK", which is usually set as the
>> previous official JDK release
On Fri, 13 Jan 2023 17:05:10 GMT, Matias Saavedra Silva
wrote:
>> This is an enhancement of the test case in
>> [JDK-8296754](https://bugs.openjdk.org/browse/JDK-8296754), which tests
>> against an archive created by the "boot JDK", which is usually set as the
>> previous official JDK release
On Tue, 10 Jan 2023 23:17:06 GMT, Justin King wrote:
>> This change instruments Metaspace for ASan. Metaspace allocates memory using
>> `mmap`/`munmap` which ASan is not aware of. Fortunately ASan supports
>> applications [manually poisoning/unpoisoning
>> memory](https://github.com/google/san
On Thu, 12 Jan 2023 03:02:51 GMT, Matias Saavedra Silva
wrote:
>> This is an enhancement of the test case in
>> [JDK-8296754](https://bugs.openjdk.org/browse/JDK-8296754), which tests
>> against an archive created by the "boot JDK", which is usually set as the
>> previous official JDK release
On Tue, 10 Jan 2023 17:27:33 GMT, Justin King wrote:
>> This change instruments Metaspace for ASan. Metaspace allocates memory using
>> `mmap`/`munmap` which ASan is not aware of. Fortunately ASan supports
>> applications [manually poisoning/unpoisoning
>> memory](https://github.com/google/san
On Mon, 9 Jan 2023 15:48:48 GMT, Justin King wrote:
>> I like this, but would compilers not complain about unused statements?
>
> I don't believe so, at least not based on current options. Other projects use
> similar tricks, like ABSL_DCHECK from Abseil which short circuits expressions
> when
On Fri, 6 Jan 2023 22:23:35 GMT, Matias Saavedra Silva
wrote:
>> This is an enhancement of the test case in
>> [JDK-8296754](https://bugs.openjdk.org/browse/JDK-8296754), which tests
>> against an archive created by the "boot JDK", which is usually set as the
>> previous official JDK release
On Fri, 6 Jan 2023 13:47:22 GMT, Erik Joelsson wrote:
>> Matias Saavedra Silva 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 eight
>> addition
On Thu, 5 Jan 2023 19:25:07 GMT, Coleen Phillimore wrote:
>> This is an enhancement of the test case in
>> [JDK-8296754](https://bugs.openjdk.org/browse/JDK-8296754), which tests
>> against an archive created by the "boot JDK", which is usually set as the
>> previous official JDK release when
On Wed, 4 Jan 2023 20:07:48 GMT, Matias Saavedra Silva
wrote:
> This is an enhancement of the test case in
> [JDK-8296754](https://bugs.openjdk.org/browse/JDK-8296754), which tests
> against an archive created by the "boot JDK", which is usually set as the
> previous official JDK release when
On Wed, 4 Jan 2023 20:07:48 GMT, Matias Saavedra Silva
wrote:
> This is an enhancement of the test case in
> [JDK-8296754](https://bugs.openjdk.org/browse/JDK-8296754), which tests
> against an archive created by the "boot JDK", which is usually set as the
> previous official JDK release when
On Wed, 4 Jan 2023 20:07:48 GMT, Matias Saavedra Silva
wrote:
> This is an enhancement of the test case in
> [JDK-8296754](https://bugs.openjdk.org/browse/JDK-8296754), which tests
> against an archive created by the "boot JDK", which is usually set as the
> previous official JDK release when
On Tue, 22 Nov 2022 19:21:51 GMT, Matias Saavedra Silva
wrote:
>> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however,
>> this flag doesn't work across JDK 19 and 20.
>>
>> Expected: JDK 20 should recreate the specified CDS archive
>> Actual: JDK 20 cannot recognize the ar
On Thu, 17 Nov 2022 21:46:45 GMT, Matias Saavedra Silva
wrote:
>> The -XX:+AutoCreateSharedArchive flag was implemented in JDK 19, however,
>> this flag doesn't work across JDK 19 and 20.
>>
>> Expected: JDK 20 should recreate the specified CDS archive
>> Actual: JDK 20 cannot recognize the ar
On Fri, 2 Sep 2022 05:31:35 GMT, Ioi Lam wrote:
> I moved all code related to loading the archive heap regions into a new file,
> archiveHeapLoader.cpp.
>
> A diff of the new archiveHeapLoader.cpp and the old heapShared.cpp shows that
> the moved code is identical, except fo
On Fri, 2 Sep 2022 12:42:36 GMT, Erik Joelsson wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Cleaned up header files
>
> Build change looks good.
Thanks for the review @erikj79 @col
On Fri, 2 Sep 2022 17:16:42 GMT, Coleen Phillimore wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Cleaned up header files
>
> src/hotspot/share/cds/archiveHeapLoader.cpp lin
pLoader::`.
>
> I also removed unnecessary entries in JVM_EXCLUDE_FILES that are already
> covered by the `cds/` pattern.
Ioi Lam has updated the pull request incrementally with one additional commit
since the last revision:
Cleaned up header files
-
Changes:
- all:
I moved all code related to loading the archive heap regions into a new file,
archiveHeapLoader.cpp.
A diff of the new archiveHeapLoader.cpp and the old heapShared.cpp shows that
the moved code is identical, except for the change of `HeapShared::` to
`ArchiveHeapLoader::`.
I also removed unnec
On Wed, 24 Aug 2022 06:04:52 GMT, Aleksey Shipilev wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> @shipilev review comments
>
> Zero can default to G1 after #9994. Together with this pa
On Tue, 23 Aug 2022 15:56:35 GMT, Ioi Lam wrote:
> ZERO uses UseSerialGC by default. When we dump the default CDS archive during
> the build process, it fails to dump the shared heap (which requires G1GC).
>
> The fix is to force -XX:+UseG1GC when dumping the default CDS archive d
peed up:
>
> (Before)
> $ perf stat -r 40 ./images/jdk/bin/java -version
> 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% )
>
> (After)
> $ perf stat -r 40 ./images/jdk/bin/java -version
> 0.011986 +- 0.000205 seconds time elapsed ( +- 1.71% )
Ioi Lam has updated the pull req
On Wed, 24 Aug 2022 10:26:36 GMT, Magnus Ihse Bursie wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> @shipilev review comments
>
> make/Images.gmk line 141:
>
>> 139:
>
On Tue, 23 Aug 2022 17:12:44 GMT, Erik Joelsson wrote:
>> In that case, the loop you proposed make a lot of sense and I think you
>> should add it.
>
> Oh, the loop is already there, it's jus the naming of the variable. I think
> we should adjust that so the check-jvm-feature macro can be used.
On Tue, 23 Aug 2022 16:56:08 GMT, Erik Joelsson wrote:
>> That doesn't work because `check-jvm-feature` requires `JVM_VARIANT` to be
>> set, but `CreateCDSArchive` is not called in a context where `JVM_VARIANT`
>> is set. ( `JVM_VARIANT` is set only in a few specific places in Main.gmk,
>> et
On Tue, 23 Aug 2022 16:34:06 GMT, Thomas Stuefe wrote:
> Stupid question, does that not mean that the CDS dump generated at build time
> is not usable with the VM at runtime if that is started with default options?
The CDS archive is still useable.
- If G1 is used at runtime, the shared heap i
On Tue, 23 Aug 2022 16:27:40 GMT, Aleksey Shipilev wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> @shipilev review comments
>
> make/Images.gmk line 132:
>
>> 130:
>>
peed up:
>
> (Before)
> $ perf stat -r 40 ./images/jdk/bin/java -version
> 0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% )
>
> (After)
> $ perf stat -r 40 ./images/jdk/bin/java -version
> 0.011986 +- 0.000205 seconds time elapsed ( +- 1.71% )
Ioi Lam has updated the pull req
ZERO uses UseSerialGC by default. When we dump the default CDS archive during
the build process, it fails to dump the shared heap (which requires G1GC).
The fix is to force -XX:+UseG1GC when dumping the default CDS archive during
the build process.
Speed up:
(Before)
$ perf stat -r 40 ./images
On Sun, 14 Aug 2022 05:21:13 GMT, Ioi Lam wrote:
> Enable CDS for zero builds. `java --version` is about 2x faster now.
>
>
> $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version
> 0.034645 +- 0.44 seconds time elapsed ( +- 0.13% )
> $ perf stat -r 40 ./i
On Tue, 16 Aug 2022 06:36:26 GMT, Aleksey Shipilev wrote:
>>> Do you know how much testing is done by the community with zero? We don't
>>> test it that much in our pipeline.
>>
>> You could ask the Debian people (Adrian Glaubitz), IIRC they have test farms
>> with broad platform support and u
On Tue, 16 Aug 2022 16:50:09 GMT, Aleksey Shipilev wrote:
>> When running with dynamic dump (`-XX:ArchiveClassesAtExit=foo.jsa`),
>> `UseSharedSpaces` is true, so it's possible for a method to be rewritten
>> here, and later dumped into the CDS archive).
>>
>> I think we should remove `!UseSh
seconds time elapsed ( +- 2.15% )
>
> I also fixed a bug in Images.gmk that always wrote the default archive to
> $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to
> have a default CDS archive.
Ioi Lam has updated the pull request incrementally with one
On Tue, 16 Aug 2022 06:31:41 GMT, Aleksey Shipilev wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fixed copyright and whitespaces
>
> src/hotspot/share/interpreter/zero/bytecodeInterpr
seconds time elapsed ( +- 2.15% )
>
> I also fixed a bug in Images.gmk that always wrote the default archive to
> $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to
> have a default CDS archive.
Ioi Lam has updated the pull request incrementally with two a
On Tue, 16 Aug 2022 06:36:26 GMT, Aleksey Shipilev wrote:
> > Do you know how much testing is done by the community with zero? We don't
> > test it that much in our pipeline.
>
> You could ask the Debian people (Adrian Glaubitz), IIRC they have test farms
> with broad platform support and use
seconds time elapsed ( +- 2.15% )
>
> I also fixed a bug in Images.gmk that always wrote the default archive to
> $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to
> have a default CDS archive.
Ioi Lam has updated the pull request incrementally with one
On Mon, 15 Aug 2022 17:18:54 GMT, Aleksey Shipilev wrote:
>>> Good stuff. Actually, let me see how easy it is to implement the `nofast_*`
>>> bytecodes in Zero, so we don't have to do the shared-code exceptions for it.
>>
>> That took some debugging :) But here it is, applied on top of your PR:
seconds time elapsed ( +- 2.15% )
>
> I also fixed a bug in Images.gmk that always wrote the default archive to
> $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to
> have a default CDS archive.
Ioi Lam has updated the pull request with a new target base
seconds time elapsed ( +- 2.15% )
>
> I also fixed a bug in Images.gmk that always wrote the default archive to
> $JAVA_HOME/lib/server. This fix also makes it possible for a client libjvm to
> have a default CDS archive.
Ioi Lam has updated the pull request incrementally with two a
Enable CDS for zero builds. `java --version` is about 2x faster now.
$ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version
0.034645 +- 0.44 seconds time elapsed ( +- 0.13% )
$ perf stat -r 40 ./images/jdk/bin/java -version
0.018080 +- 0.000388 seconds time elapsed ( +- 2.15% )
I a
My windows build is very slow, and it spends the first few minutes
compiling test_xxx.obj files.
Is it possible to build the HotSpot VM .obj files first?
Thanks
- Ioi
$ time make hotspot LOG=info
Generating main target list
Running make as 'make LOG=info hotspot'
Building target 'hotspot' in c
75 matches
Mail list logo
