On Wed, 12 Mar 2025 15:53:33 GMT, Vladimir Ivanov wrote:
> the test output was cleanup for common execution.
I would argue against that.
While tests and test resources already comprise ~360M it could be argued that
adding this 3.5M dictionary file wouldn't hurt all that much -- but OTOH this
On Mon, 24 Mar 2025 19:34:55 GMT, Vladimir Ivanov wrote:
>> Tests that use data from the file 'cmudict-0.7b.txt' was deleted. Currently
>> these tests using empty data set that looks bad.
>
> Vladimir Ivanov has updated the pull request incrementally with one
> additional commit since the last
On Thu, 20 Mar 2025 23:39:24 GMT, Vladimir Ivanov wrote:
>> Tests that use data from the file 'cmudict-0.7b.txt' was deleted. Currently
>> these tests using empty data set that looks bad.
>
> Vladimir Ivanov has updated the pull request incrementally with one
> additional commit since the last
On Wed, 12 Mar 2025 15:53:33 GMT, Vladimir Ivanov wrote:
> the test output was cleanup for common execution.
The root cause seems to be that `DataProviders.dictionary()` attempts to load a
dictionary file that isn't there, which means that the microbenchmark is likely
not testing what the orig
On Tue, 25 Feb 2025 22:08:33 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 2241:
>>
>>> 2239: var form = constantForm(basicType);
>>> 2240:
>>> 2241: if (type.isPrimitive()) {
>>
>> I think you could simplify this using `Wrapp
On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang wrote:
>> LF editor spins classes, this avoids the spinning overhead and should speed
>> up non-capturing lambdas too.
>>
>> There may need to be additional intrinsic work for MH combinator lf bytecode
>> generation.
>
> Chen Liang has updated the p
On Mon, 24 Feb 2025 23:45:37 GMT, Chen Liang wrote:
>> LF editor spins classes, this avoids the spinning overhead and should speed
>> up non-capturing lambdas too.
>>
>> There may need to be additional intrinsic work for MH combinator lf bytecode
>> generation.
>
> Chen Liang has updated the p
On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote:
> As is suggested in
> [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should
> be used consistently in microbenchmarks to 'align with the intuition that
> when you use jvmArgsAppend/-Prepend intent is to add to a set of
On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan wrote:
>> Hi all,
>>
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()"
>> because "is" is null', because the file
>> 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing
>> the required xml input fil
On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan wrote:
>> Hi all,
>>
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()"
>> because "is" is null', because the file
>> 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing
>> the required xml input fil
On Wed, 19 Feb 2025 03:21:37 GMT, SendaoYan wrote:
>> Hi all,
>>
>> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()"
>> because "is" is null', because the file
>> 'build/linux-x86_64-server-release/images/test/micro/benchmarks.jar' missing
>> the required xml input fil
On Tue, 11 Feb 2025 20:56:39 GMT, Coleen Phillimore wrote:
> Class.isInterface() can check modifier flags, Class.isArray() can check
> whether component mirror is non-null and Class.isPrimitive() needs a new
> final transient boolean in java.lang.Class that the JVM code initializes.
> Tested wi
On Mon, 3 Feb 2025 18:56:12 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> skip coder change
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 845:
>
>> 843: int spa
On Mon, 3 Feb 2025 16:37:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which backs out the commit that was
>> introduced for https://bugs.openjdk.org/browse/JDK-8333893?
>>
>> The comment in the PR review of that issue
>> https://github.com/openjdk/jdk/pull/19626#issu
On Mon, 3 Feb 2025 17:04:33 GMT, Shaojin Wen wrote:
>> Jaikiran Pai has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains two
>> new commit
On Mon, 20 Jan 2025 14:32:22 GMT, Shaojin Wen wrote:
>> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
>> offset overflow issue has been fixed.
>>
>> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication.
>>
>> 2) HexDigi
On Sat, 18 Jan 2025 21:48:39 GMT, Chen Liang wrote:
>> The doc of `Unsafe::putChar()` delegates to the doc of `Unsafe::putInt()`
>> which clearly states that the `Object` and `offset` arguments must locate a
>> variable of the same type as the one of argument `x`, which is not the case
>> here
On Wed, 11 Dec 2024 22:30:32 GMT, Shaojin Wen wrote:
>> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
>> offset overflow issue has been fixed.
>>
>> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication.
>>
>> 2) HexDigi
On Fri, 3 Jan 2025 12:46:27 GMT, Adam Sotona wrote:
> ASM-based benchmarks were useful to directly compare performance of ASM and
> Class-File API.
> However Class-File API performance history is now continuously tracked and
> direct comparison to ASM becomes obsolete.
>
> This patch removes A
On Mon, 9 Dec 2024 06:24:21 GMT, Shaojin Wen wrote:
>> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
>> offset overflow issue has been fixed.
>>
>> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication.
>>
>> 2) HexDigit
On Thu, 31 Oct 2024 13:29:35 GMT, Claes Redestad wrote:
> Benchmarks using Indify was added to the JMH microbenchmarks corpus in the
> JDK 8 timeframe. This adds overhead to the microbenchmarks build and has been
> blocking/slowing progress on some indy-based prototyping as the in
On Thu, 31 Oct 2024 13:29:35 GMT, Claes Redestad wrote:
> Benchmarks using Indify was added to the JMH microbenchmarks corpus in the
> JDK 8 timeframe. This adds overhead to the microbenchmarks build and has been
> blocking/slowing progress on some indy-based prototyping as the in
On Thu, 31 Oct 2024 13:56:42 GMT, Chen Liang wrote:
>> Benchmarks using Indify was added to the JMH microbenchmarks corpus in the
>> JDK 8 timeframe. This adds overhead to the microbenchmarks build and has
>> been blocking/slowing progress on some indy-based prototyping as the indify
>> tool i
Benchmarks using Indify was added to the JMH microbenchmarks corpus in the JDK
8 timeframe. This adds overhead to the microbenchmarks build and has been
blocking/slowing progress on some indy-based prototyping as the indify tool
itself may not be 100% forward compatible.
I suggest we remove the
On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, et
On Wed, 30 Oct 2024 16:31:28 GMT, Jaikiran Pai wrote:
>> @eirbjo will know for sure but I think it's intentional since if there's an
>> encoding error we'd have thrown earlier when hashing over the full name.
>
> Hello Claes,
>
>> if there's an encoding error we'd have thrown earlier when hash
On Wed, 30 Oct 2024 16:14:48 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Map versions by entry name hashcode instead of by entry name. This avoids
>> String allocation and storage
>> -
On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, et
On Mon, 28 Oct 2024 20:51:22 GMT, Andrey Turbanov wrote:
>> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
>> reasonable or necessary flags, but when deploying and running micros we
>> often want to add or replace flags to tune to the machine, test different
>> GCs, etc.
On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, et
Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM reasonable
or necessary flags, but when deploying and running micros we often want to add
or replace flags to tune to the machine, test different GCs, etc. The
inconsistent use of the different `jvmArgs` options make it error p
On Thu, 24 Oct 2024 13:52:57 GMT, Claes Redestad wrote:
> Many OpenJDK micros use `@Fork(jvmArgs/-Append/-Prepend)` to add JVM
> reasonable or necessary flags, but when deploying and running micros we often
> want to add or replace flags to tune to the machine, test different GCs, et
On Wed, 23 Oct 2024 06:14:52 GMT, Chen Liang wrote:
>> @cl4es discovered that Stack Map generation in ClassFile API uses
>> `componentType` and `arrayType` for `aaload` `aastore` instructions, which
>> are currently quite slow. We can split out array class descriptors from
>> class or interfac
On Fri, 18 Oct 2024 16:02:26 GMT, Eirik Bjørsnøs wrote:
>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1796:
>>
>>> 1794: if (metaVersions == null)
>>> 1795: metaVersions = new HashMap<>();
>>> 1796:
On Sat, 19 Oct 2024 20:39:48 GMT, Claes Redestad wrote:
> Trivially removing some unused left-over `LambdaForm$Kind` enums.
>
> - Last use of `COLLECT` and `SPREAD` was removed by fac39fe9
> - `FIELD` was added by 8d5f5b9a but had no usage from the start
> - Last use of `CONVE
On Sat, 19 Oct 2024 20:39:48 GMT, Claes Redestad wrote:
> Trivially removing some unused left-over `LambdaForm$Kind` enums.
>
> - Last use of `COLLECT` and `SPREAD` was removed by fac39fe9
> - `FIELD` was added by 8d5f5b9a but had no usage from the start
> - Last use of `CONVE
On Mon, 21 Oct 2024 07:58:42 GMT, Emanuel Peter wrote:
>> Shaojin Wen 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 26 additional
>> commits s
On Fri, 18 Oct 2024 21:56:53 GMT, Shaojin Wen wrote:
>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into
>> primitive arrays by combining values into larger stores.
>>
>> This PR rewrites the code of appendNull and append(boolean) methods so that
>> these two meth
On Fri, 18 Oct 2024 23:29:58 GMT, Shaojin Wen wrote:
> After PR 19970, the performance has been significantly improved. Below are
> the performance numbers for AMD CPU (x64)
It'd be interesting to check performance on this micro with #19970 alone
-
PR Comment: https://git.openjdk.
Trivially removing some unused left-over `LambdaForm$Kind` enums.
- Last use of `COLLECT` and `SPREAD` was removed by fac39fe9
- `FIELD` was added by 8d5f5b9a but had no usage from the start
- Last use of `CONVERT` was removed by eda5f090
-
Commit messages:
- 8341776: Remove unused
On Sat, 19 Oct 2024 16:28:34 GMT, Lance Andersen wrote:
>> Please review the changes for
>> [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a
>> follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025)
>> which addresses that
>>
>> - ZipEntry(String)
>> - Z
On Sat, 19 Oct 2024 15:52:59 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/zip/ZipEntry.java line 723:
>>
>>> 721: * @return true if valid CEN Header size; false otherwise
>>> 722: */
>>> 723: static boolean isCENHeaderValid(String name, byte[] extra, String
On Fri, 18 Oct 2024 21:24:18 GMT, Lance Andersen wrote:
>> Please review the changes for
>> [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a
>> follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025)
>> which addresses that
>>
>> - ZipEntry(String)
>> - Z
On Sat, 19 Oct 2024 06:39:54 GMT, ExE Boss wrote:
>> This DMH is derived from invokerName, which comes from
>> java.lang.invoke.LambdaForm.Kind#defaultLambdaName
>
> `"NFI"` and `"LFI"` should probably also be added to this `switch`.
No: I believe these names are used for invokers spun exclusiv
On Fri, 18 Oct 2024 12:08:08 GMT, Eirik Bjørsnøs wrote:
>> There are a few possible strategies for avoiding that additional parse,
>> since the effect we're getting at here is to have a quick filter to avoid
>> pointless lookups and not necessarily an exact mapping.
>>
>> One is to store the `
On Fri, 18 Oct 2024 13:54:30 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which speeds up `JarFile::getEntry` lookup
>> significantly for multi-release JAR files.
>>
>> The changes in this PR are motivated by the following insights:
>>
>> * `META-INF/versions/` is sparsely populated.
>>
On Fri, 18 Oct 2024 12:34:18 GMT, Claes Redestad wrote:
>>> One is to store the `checkedHash` rather than the full `String`. This gets
>>> `openCloseZipFile` down to ~91 ns/op. (`checkedHash` very hot in
>>> profiles). There's still a chance for redu
On Fri, 18 Oct 2024 09:31:45 GMT, Eirik Bjørsnøs wrote:
>> With this change to `ZipFileOpen`:
>>
>> diff --git a/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
>> b/test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java
>> index 4f6ae6373ec..0e22cf7f0ab 100644
>> --- a/test/m
On Thu, 17 Oct 2024 22:32:12 GMT, Claes Redestad wrote:
>>> I guess performance leans on there being only one or a small number of
>>> versions per entry.
>>
>> I checked Spring Petclinic:
>>
>> * 109 JAR dependencies
>> * 15 are multi-releas
On Thu, 17 Oct 2024 08:40:05 GMT, Eirik Bjørsnøs wrote:
>> I guess performance leans on there being only one or a small number of
>> versions per entry. Which I think is a fair assumption. Still would be good
>> to have a stress test with many entries having many versions and make sure
>> we d
On Tue, 15 Oct 2024 08:05:44 GMT, Eirik Bjørsnøs wrote:
>> Yep, looks good. And I agree with Claes' evaluation that we should not
>> complicate this construction further, especially that the result is quickly
>> garbage collected when we compile into the string to int array map.
>
> We could al
On Mon, 14 Oct 2024 19:52:50 GMT, Eirik Bjørsnøs wrote:
>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1831:
>>
>>> 1829: metaVersions = new HashMap<>();
>>> 1830: for (var entry : metaVersionsMap.entrySet()) {
>>> 1831: // Conv
On Tue, 8 Oct 2024 22:34:38 GMT, Shaojin Wen wrote:
>> A simple optimization that eliminates the allocation of the
>> MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates
>> the allocation of argNames when parameterCount is equal to 1
>
> Shaojin Wen has updated the pull r
On Tue, 8 Oct 2024 22:25:03 GMT, Shaojin Wen wrote:
> Are you talking about merging multiple writeU2 in places like
> AbstractAttributeMapper? I am planning to make a new PR to complete these
> works, because this PR has too many changes.
Good. I would have suggested the same.
-
On Tue, 8 Oct 2024 09:57:43 GMT, Shaojin Wen wrote:
>> Some DirectCodeBuilder related optimizations to improve startup and running
>> performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 inste
On Mon, 7 Oct 2024 22:54:24 GMT, Shaojin Wen wrote:
>> Some DirectCodeBuilder related optimizations to improve startup and running
>> performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 inste
Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>
> Co-authored-by: Claes Redestad
Marked as reviewed by redestad (R
On Tue, 8 Oct 2024 18:03:14 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>> line 193:
>>
>>> 191: String argName = i < ARG_NAME_CACHE_SIZE ? ARG_NAME_CACHE[i] :
>>> null;
>>> 192: if (argName == null) {
>>> 193:
On Tue, 8 Oct 2024 15:52:35 GMT, Shaojin Wen wrote:
>> A simple optimization that eliminates the allocation of the
>> MethodTypeDescImpl object when parameterCount is equal to 0 and eliminates
>> the allocation of argNames when parameterCount is equal to 1
>
> Shaojin Wen has updated the pull r
On Tue, 8 Oct 2024 01:14:32 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/util/zip/ZipUtils.java line 173:
>>
>>> 171: * The bytes are assumed to be in Intel (little-endian) byte order.
>>> 172: */
>>> 173: public static final int get16(byte[] b, int off) {
>>
>> Can
On Sun, 6 Oct 2024 14:16:44 GMT, Claes Redestad wrote:
> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
> improve performance in zip-related microbenchmarks, but the suggested PR
> would increase startup overheads by early use of `ByteArrayLittleEndian`
On Tue, 8 Oct 2024 01:13:37 GMT, Chen Liang wrote:
>> @cl4es discovered that Stack Map generation in ClassFile API uses
>> `componentType` and `arrayType` for `aaload` `aastore` instructions, which
>> are currently quite slow. We can split out array class descriptors from
>> class or interface
On Mon, 7 Oct 2024 20:03:29 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix merge error
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
> line 989:
>
>> 987:
On Sat, 5 Oct 2024 16:33:50 GMT, Shaojin Wen wrote:
>> Some DirectCodeBuilder related optimizations to improve startup and running
>> performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 inste
On Sun, 6 Oct 2024 16:42:15 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which suggests we clean up iteration and validation
> logic in `ZipFile.Source::initCEN` and some related methods to use a simpler
> and more consistent style:
>
> * The main loop in `ZipFile.Source::initCEN` curren
On Sun, 6 Oct 2024 19:33:49 GMT, Eirik Bjørsnøs wrote:
>> As it's a pre-existing issue I'd prefer to keep this one focused on the
>> switch-over. How would you model unsigned long values here, though? Sure we
>> could read into a `BigInteger` or accept negative values, but to really
>> support
ficant
>
>
> This PR also address some code duplication in `ZipUtils`.
>
> An appealing alternative would be to implement a merge load analogue to the
> merge store optimizations in C2. Such optimizations would be very welcome
> since it would improve similar code outside
On Sun, 6 Oct 2024 15:48:57 GMT, Eirik Bjørsnøs wrote:
>> Sure, I think the JIT is pretty good at eliminating the (intrinsic)
>> `checkIndex` calls when they are redundant though. Performance with and
>> without these `checkIndex`es are the same in my testing, so we can eat and
>> have the cak
On Sun, 6 Oct 2024 15:53:55 GMT, Eirik Bjørsnøs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 195:
&
On Sun, 6 Oct 2024 16:27:52 GMT, Chen Liang wrote:
>> test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 110:
>>
>>> 108: zf2.close();
>>> 109: }
>>> 110:
>>
>> A short comment stating the purpose of the main method would not hurt.
>
> https://github.com/openjdk/jdk/p
ficant
>
>
> This PR also address some code duplication in `ZipUtils`.
>
> An appealing alternative would be to implement a merge load analogue to the
> merge store optimizations in C2. Such optimizations would be very welcome
> since it would improve similar code outside
On Sun, 6 Oct 2024 14:56:27 GMT, Eirik Bjørsnøs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1644:
>
On Sun, 6 Oct 2024 15:29:13 GMT, Eirik Bjørsnøs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 258:
&g
On Sun, 6 Oct 2024 15:11:19 GMT, Chen Liang wrote:
>> It's actually not less overhead in my tests, since `checkIndex` is intrinsic
>> and mostly disappears, while with `checkFromIndexSize` performance gets
>> significantly worse (on par with baseline). It's on my todo to investigate
>> this in
ficant
>
>
> This PR also address some code duplication in `ZipUtils`.
>
> An appealing alternative would be to implement a merge load analogue to the
> merge store optimizations in C2. Such optimizations would be very welcome
> since it would improve similar code outside
On Sun, 6 Oct 2024 14:40:37 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> copyright
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 175:
>
&g
#14632 showed that coalescing loads in the `ZipUtils` utility methods could
improve performance in zip-related microbenchmarks, but doing so would increase
startup overheads. Progress was stalled as we backed out some related early use
of `ByteArray(LittleEndian)` and started exploring merge sto
On Mon, 23 Sep 2024 09:44:57 GMT, Claes Redestad wrote:
> This PR suggests refactoring `ZipFile.Source.initCEN` to move as much logic
> as possible into the per-entry method processor. This inner method will be
> called often and JIT optimized earlier in the bootstrap sequence.
>
On Tue, 1 Oct 2024 10:18:15 GMT, Maurizio Cimadamore
wrote:
>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some
>> round of adaptation.
>> Adapting a var handle results in a so called *indirec
On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen wrote:
> The new API loadConstant(int) can shorten the calling path and can replace
> ldc when the parameter is of int/Integer type.
I'm in favor of removing `ldc(ConstantDesc)`, keeping the
`ldc(LoadableConstantEntry)` for advanced uses. It's easi
On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen wrote:
> The new API loadConstant(int) can shorten the calling path and can replace
> ldc when the parameter is of int/Integer type.
I consider this a bug in the API, too. Perhaps we could assert against usage
that would have been better expressed
On Mon, 30 Sep 2024 11:17:20 GMT, Chen Liang wrote:
> This can also avoid cp entries for small values and use 2-byte bipush or
> 1-byte constants, both smaller in size.
Yikes, I was unaware `ldc` wouldn't optimize the emitted bytecode but reading
through the code and docs it's pretty obvious.
On Mon, 30 Sep 2024 10:03:57 GMT, Shaojin Wen wrote:
> The new API loadConstant(int) can shorten the calling path and can replace
> ldc when the parameter is of int/Integer type.
Marked as reviewed by redestad (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/21259#pullreq
On Mon, 30 Sep 2024 09:24:22 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not
>> include the 22-byte trailing`END` header when reading the `CEN` section of
>> the ZIP file.
>>
>> The reading of the END header was probably brought over from na
On Sun, 29 Sep 2024 13:35:14 GMT, Shaojin Wen wrote:
>> Some DirectCodeBuilder related optimizations to improve startup and running
>> performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 inst
On Wed, 25 Sep 2024 13:43:49 GMT, Claes Redestad wrote:
>> This PR suggests refactoring `ZipFile.Source.initCEN` to move as much logic
>> as possible into the per-entry method processor. This inner method will be
>> called often and JIT optimized earlier in the
On Wed, 21 Aug 2024 20:25:07 GMT, Chen Liang wrote:
> @cl4es discovered that Stack Map generation in ClassFile API uses
> `componentType` and `arrayType` for `aaload` `aastore` instructions, which
> are currently quite slow. We can split out array class descriptors from class
> or interfaces t
On Wed, 25 Sep 2024 16:22:55 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not
>> include the 22-byte trailing`END` header when reading the `CEN` section of
>> the ZIP file.
>>
>> The reading of the END header was probably brought over from na
On Sun, 8 Sep 2024 14:39:06 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not
> include the 22-byte trailing`END` header when reading the `CEN` section of
> the ZIP file.
>
> The reading of the END header was probably brought over from native c
On Wed, 25 Sep 2024 14:44:32 GMT, Chen Liang wrote:
> Apparently forgot to push when I re-requested a review after the renames.
I thought something was off, but on the third refresh the changes came in :-)
-
PR Comment: https://git.openjdk.org/jdk/pull/21170#issuecomment-2374309882
On Wed, 25 Sep 2024 14:47:10 GMT, Chen Liang wrote:
>> `MethodHandles.Lookup` defines a `ClassFile` for simple validations; it is
>> unnecessary and can be scalarized manually. The removal of `ClassFile` class
>> is also slightly helpful for bootstrap by reducing class loading. Also
>> improve
t; openCloseZipFilex2 1024 15 117959.071 ± 1528.426 111773.937 ± 1604.412
> ns/op 1.06x (p = 0.000*)
> * = significant
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Typo
-
Changes:
- all: https://git.openjdk.o
On Wed, 25 Sep 2024 10:12:50 GMT, Claes Redestad wrote:
>> This PR desugars the enum added by JDK-8301873 to reduce classes loaded on
>> bootstrap and stored in the default CDS archive by 2.
>
> Claes Redestad has updated the pull request incrementally with two additional
&
On Wed, 25 Sep 2024 09:15:04 GMT, Claes Redestad wrote:
> This PR desugars the enum added by JDK-8301873 to reduce classes loaded on
> bootstrap and stored in the default CDS archive by 2.
This pull request has now been integrated.
Changeset: d8790aa0
Author: Claes Redesta
On Wed, 25 Sep 2024 12:58:22 GMT, Chen Liang wrote:
>> AFAICT they already use the record names, so we're not generating redundant
>> code there.
>
> I mean the name variable in makeHiddenClassDefiner and makeClassDefiner that
> leads up here.
Ah.. Yeah, either way you like, but if it's an int
On Wed, 25 Sep 2024 12:03:58 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2276:
>>
>>> 2274: var thisClass = cm.thisClass();
>>> 2275: name = thisClass.asInternalName();
>>> 2276: sym = thisClass.as
On Wed, 25 Sep 2024 10:10:13 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/util/zip/ZipCoder.java line 69:
>>
>>> 67: * to the encoded string.
>>> 68: */
>>> 69: EXACT_MATCH = 1,
>>
>> Would there be
On Sun, 8 Sep 2024 14:39:06 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which makes `ZipFile.Source.initCEN` not
> include the 22-byte trailing`END` header when reading the `CEN` section of
> the ZIP file.
>
> The reading of the END header was probably brought over from native c
On Wed, 25 Sep 2024 09:53:39 GMT, Eirik Bjørsnøs wrote:
>> Claes Redestad has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Shift constant values
>> - Update src/java.base/share/classes/java/util/zip
On Wed, 25 Sep 2024 09:52:20 GMT, Eirik Bjørsnøs wrote:
>> Claes Redestad has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Shift constant values
>> - Update src/java.base/share/classes/java/util/zip
1 - 100 of 1047 matches
Mail list logo
