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
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
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
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 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 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
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: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 spec
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
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 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 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,
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
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
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
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
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
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
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 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 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 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
; [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 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
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
; [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 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
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 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
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
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
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
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 incrementally with one
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 two a
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 one
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
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 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
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
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 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:
>>
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: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 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 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:
>
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 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
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
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
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:
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 Tue, 12 Nov 2024 23:27:27 GMT, Calvin Cheung wrote:
> With this change, the compact object headers related CDS archives
> (`classes_coh.jsa` and `classes_nocoops_coh.jsa`) will not be generated by
> default. If the user needs them, the user can specify the
> `--enable-cds-archive-coh=yes` b
On Wed, 13 Nov 2024 23:15:47 GMT, Calvin Cheung wrote:
>> With this change, the compact object headers related CDS archives
>> (`classes_coh.jsa` and `classes_nocoops_coh.jsa`) will not be generated by
>> default. If the user needs them, the user can specify the
>> `--enable-cds-archive-coh=ye
gram that
> accomplishes the same effect as the current implementation.
>
> ** Changes in this PR **
>
> This PR combines the invocation of these Java tools into a single Java
> program, so we just have a single AOT configuration file. It also uses the
> `-XX:ExtraSharedClassLi
On Thu, 13 Feb 2025 19:20:05 GMT, Erik Joelsson wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Comments from @erikj79
>
> make/RunTests.gmk line 734:
>
>> 732: $$(ca
gram that
> accomplishes the same effect as the current implementation.
>
> ** Changes in this PR **
>
> This PR combines the invocation of these Java tools into a single Java
> program, so we just have a single AOT configuration file. It also uses the
> `-XX:ExtraSharedClassLi
gram that
> accomplishes the same effect as the current implementation.
>
> ** Changes in this PR **
>
> This PR combines the invocation of these Java tools into a single Java
> program, so we just have a single AOT configuration file. It also uses the
> `-XX:ExtraSharedClassLi
On Fri, 14 Mar 2025 23:43:53 GMT, Erik Joelsson wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments from @erikj79 and @lmesnik
>
> make/test/BuildTest
I modified TestSetupAOT.java to exercise more functionalities in the JDK so
that we can have a more substantial AOT cache when running tests with
`AOT_JDK=true`. E.g:
make test JTREG=AOT_JDK=true \
TEST=open/test/jdk/java/util/TimeZone/ListTimeZones.java
Before: the generated AOT cache wa
On Fri, 14 Mar 2025 20:13:57 GMT, Ioi Lam wrote:
> I modified TestSetupAOT.java to exercise more functionalities in the JDK so
> that we can have a more substantial AOT cache when running tests with
> `AOT_JDK=true`. E.g:
>
>
> make test JTREG=AOT_JDK=true \
> TE
a
>
>
> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125
> resolved indies
> After: the generated AOT cache is about 34 MB, with 4703 classes and 912
> resolved indies
>
> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have
a
>
>
> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125
> resolved indies
> After: the generated AOT cache is about 34 MB, with 4703 classes and 912
> resolved indies
>
> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have
On Fri, 14 Mar 2025 23:21:59 GMT, Leonid Mesnik wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments from @erikj79 and @lmesnik
>
> make/RunTests.gmk line 738:
a
>
>
> Before: the generated AOT cache was about 20 MB, with 2245 classes and 125
> resolved indies
> After: the generated AOT cache is about 34 MB, with 4703 classes and 912
> resolved indies
>
> I verified with Mach5 tiers 4, 5, 6, 10 with all tests tasks that have
On Fri, 18 Apr 2025 18:45:24 GMT, Vladimir Kozlov wrote:
>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class
>> information in AOT cache which helps Java startup performance.
>>
>> We should also preserve adapters (i2c, c2i) to further improve performance
>> of class link
On Sun, 27 Apr 2025 01:11:39 GMT, Vladimir Kozlov wrote:
>> I think it's OK to test without these two additional flags. This will make
>> sure that the two diagnostic flags don't have any bad side effect even if
>> AOT class linking is disabled (due to flags like -XX:+UseZGC).
>
> I see them in
On Wed, 30 Apr 2025 02:05:41 GMT, Vladimir Kozlov wrote:
>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class
>> information in AOT cache which helps Java startup performance.
>>
>> We should also preserve adapters (i2c, c2i) to further improve performance
>> of class link
On Tue, 29 Apr 2025 15:29:08 GMT, Vladimir Kozlov wrote:
>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class
>> information in AOT cache which helps Java startup performance.
>>
>> We should also preserve adapters (i2c, c2i) to further improve performance
>> of class link
On Thu, 24 Apr 2025 00:51:31 GMT, Vladimir Ivanov wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix message
>
> src/hotspot/share/cds/aotCacheAccess.hpp line 38:
>
>> 36: // AOT Cache API for AOT compiler
>>
On Sat, 26 Apr 2025 23:35:01 GMT, Igor Veresov wrote:
>> test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line
>> 30:
>>
>>> 28: * @requires vm.cds
>>> 29: * @comment work around JDK-8345635
>>> 30: * @requires !vm.jvmci.enabled
>>
>> Consider adding:
>>
>> * @require
On Sun, 27 Apr 2025 00:02:41 GMT, Igor Veresov wrote:
>> src/hotspot/share/cds/dumpAllocStats.hpp line 151:
>>
>>> 149: }
>>> 150:
>>> 151: void record_dynamic_proxy_class() {
>>
>> This is not called. This code seems not related.
>
> True. @iklam, this came with a change you wanted me to
gram that
> accomplishes the same effect as the current implementation.
>
> ** Changes in this PR **
>
> This PR combines the invocation of these Java tools into a single Java
> program, so we just have a single AOT configuration file. It also uses the
> `-XX:ExtraSharedClassLi
On Tue, 18 Feb 2025 20:40:12 GMT, Erik Joelsson wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move the contents of SetupAOT.gmk back to RunTests.gmk, as it is not
>> necessary to h
gram that
> accomplishes the same effect as the current implementation.
>
> ** Changes in this PR **
>
> This PR combines the invocation of these Java tools into a single Java
> program, so we just have a single AOT configuration file. It also uses the
> `-XX:ExtraSharedClassLi
On Fri, 28 Feb 2025 00:37:24 GMT, Calvin Cheung wrote:
>> A simple fix in `os::jvm_path()` so that gtest can be run with CDS
>> (`-Xshare:on`). The fix is just to change the directory name from `hotspot`
>> to `server`.
>> Note that the bug doesn't exist on macOS and thus no change is required
When running HotSpot jtreg tests in the "AOT mode", for example:
make test JTREG_AOT_JDK=true open/test/hotspot/jtreg/runtime/stringtable
Before this PR, in the test set up phase, we record several AOT configuration
files by running a few separate Java tools (javac, javap, jlink, and jar), and
1 - 100 of 122 matches
Mail list logo
