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
> 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
commits since the last revision:
- Shift constant values
- Update src/jav
On Tue, 24 Sep 2024 22:07:25 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
> improved cl
This PR desugars the enum added by JDK-8301873 to reduce classes loaded on
bootstrap and stored in the default CDS archive by 2.
-
Commit messages:
- Fix docs
- Merge branch 'master' into no-comparison
- Desugar Comparison enum
Changes: https://git.openjdk.org/jdk/pull/21176/file
On Tue, 24 Sep 2024 20:21:48 GMT, Chen Liang wrote:
> This implementation code was written in JDK 7, before storeFence was
> available in JDK 8. We should update this legacy code to make it clear.
Marked as reviewed by redestad (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/
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:
Fix botched merge, improve overflow conciousness
---
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.
Startup tests using the OpenJDK benchmarks.jar show a ~1ms improvement on both
On Fri, 20 Sep 2024 16:35:07 GMT, Shaojin Wen wrote:
>> CheckLocal once, reduce redundant checkLocal, rewrite switch, reduce method
>> size, codeSize is reduced from 367 to 263.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Fri, 20 Sep 2024 16:35:05 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
>> line 1069:
>>
>>> 1067: localsSize += 2;
>>> 1068: } else {
>>> 1069: if (desc == CD_int || desc == C
On Fri, 20 Sep 2024 09:18:32 GMT, Shaojin Wen wrote:
> CheckLocal once, reduce redundant checkLocal, rewrite switch, reduce method
> size, codeSize is reduced from 367 to 263.
LGTM
src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
line 1069:
> 1067:
On Thu, 19 Sep 2024 17:07:41 GMT, Chen Liang wrote:
> The `tag` field in `AbstractPoolEntry` is redundant, as it's always of the
> same value for each subtype. This is now replaced with an override. This can
> reduce the footprint of the entries..
>
> The removal of `hash` was considered but w
On Thu, 19 Sep 2024 14:08:04 GMT, Claes Redestad wrote:
> This PR changes proxy code gen to avoid generating
> `Class.forName("java.lang.Object")`, instead emitting an ldc for the class
> literal, `ldc(CD_Object)`, java code equivalent `Object.class`.
>
> More types
On Thu, 19 Sep 2024 14:08:04 GMT, Claes Redestad wrote:
> This PR changes proxy code gen to avoid generating
> `Class.forName("java.lang.Object")`, instead emitting an ldc for the class
> literal, `ldc(CD_Object)`, java code equivalent `Object.class`.
>
> More types
On Thu, 19 Sep 2024 18:02:07 GMT, Chen Liang wrote:
>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through
>> `ClassDesc` comparison and reusing descriptor hash to calculate internal
>> name hash if possible. No suitable device to run benchmarks so need to find
>> something
On Thu, 19 Sep 2024 14:14:59 GMT, Chen Liang wrote:
>> This PR changes proxy code gen to avoid generating
>> `Class.forName("java.lang.Object")`, instead emitting an ldc for the class
>> literal, `ldc(CD_Object)`, java code equivalent `Object.class`.
>>
>> More types could profitably use `ldc
This PR changes proxy code gen to avoid generating
`Class.forName("java.lang.Object")`, instead emitting an ldc for the class
literal, `ldc(CD_Object)`, java code equivalent `Object.class`.
More types could profitably use `ldc(ClassDesc/-Entry)`, taking cues from
`InvokerBytecodeGenerator.isSt
On Wed, 18 Sep 2024 03:04:50 GMT, Ioi Lam wrote:
>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> The implementation of java.lang.invoke uses SoftReferences so that unused
>> MethodHandles, LambdaForms, etc, can b
On Tue, 17 Sep 2024 09:28:02 GMT, Claes Redestad wrote:
> This PR exploits the observation that in many of the cases where we call
> `methodType.invokerType()` we immediately translate it into a `Name[]` where
> the only effect is to create an array with an additiona
On Tue, 17 Sep 2024 22:40:34 GMT, Claes Redestad wrote:
>> This PR exploits the observation that in many of the cases where we call
>> `methodType.invokerType()` we immediately translate it into a `Name[]` where
>> the only effect is to create an array with an
le.
>
> Number of executed bytecode on a trivial HelloLambda application drops
> locally from ~517k to ~505k.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.base/share/classes/java/lang/invoke/DirectMethodH
le.
>
> Number of executed bytecode on a trivial HelloLambda application drops
> locally from ~517k to ~505k.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Remove argumentsWithTrailingObjectArguments (only one
On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang wrote:
>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through
>> `ClassDesc` comparison and reusing descriptor hash to calculate internal
>> name hash if possible. No suitable device to run benchmarks so need to find
>> something
On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang wrote:
>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through
>> `ClassDesc` comparison and reusing descriptor hash to calculate internal
>> name hash if possible. No suitable device to run benchmarks so need to find
>> something
This PR exploits the observation that in many of the cases where we call
`methodType.invokerType()` we immediately translate it into a `Name[]` where
the only effect is to create an array with an additional leading
`BasicType.L_TYPE` argument. Only in a subset of cases will a corresponding
`inv
On Sun, 15 Sep 2024 13:22:22 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/Util.java line 372:
>>
>>> 370: * }
>>> 371: * }
>>> 372: * This is converted to explicit initialization to avoid bootstrap
>>> overhead.
>>
>> Have you measured this t
On Fri, 13 Sep 2024 15:40:46 GMT, Claes Redestad wrote:
> Simple internal refactor to load a few classes less on startup. Arguably
> cleaner and avoids some iterator allocations.
This pull request has now been integrated.
Changeset: e1ebeef0
Author: Claes Redestad
URL:
On Mon, 16 Sep 2024 07:58:44 GMT, Claes Redestad wrote:
>> Simple internal refactor to load a few classes less on startup. Arguably
>> cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional
>
On Sat, 14 Sep 2024 02:45:47 GMT, Shaojin Wen wrote:
>> This is a large method. By splitting it into multiple methods with the same
>> name, the caller can automatically select based on the different types of
>> parameters, avoiding this large call that cannot be inlined, which can also
>> imp
On Sun, 15 Sep 2024 12:59:21 GMT, Claes Redestad wrote:
>> Simple internal refactor to load a few classes less on startup. Arguably
>> cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional
>
> Simple internal refactor to load a few classes less on startup. Arguably
> cleaner and avoids some iterator allocations.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Translate to int flags at edge, avoiding TOCT
On Sun, 15 Sep 2024 12:59:21 GMT, Claes Redestad wrote:
>> Simple internal refactor to load a few classes less on startup. Arguably
>> cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional
>
> Simple internal refactor to load a few classes less on startup. Arguably
> cleaner and avoids some iterator allocations.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Improve edge invariant checks
-
C
On Sat, 14 Sep 2024 20:35:30 GMT, Chen Liang wrote:
>> The public methods used to throw `IllegalArgumentException` when duplicate
>> class options were passed though, as a result of using [`Set.of(…)`].
>>
>> [`Set.of(…)`]:
>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/u
> Simple internal refactor to load a few classes less on startup. Arguably
> cleaner.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Unused import
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21002
> Simple internal refactor to load a few classes less on startup. Arguably
> cleaner.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Add override to fix build error and eliminate all allocations
-
Changes:
On Fri, 13 Sep 2024 15:57:41 GMT, Jorn Vernee wrote:
>> Claes Redestad has updated the pull request incrementally with six
>> additional commits since the last revision:
>>
>> - no clone
>> - Update src/java.base/share/classes/java/lang/invoke/MethodHandles.ja
> Simple internal refactor to load a few classes less on startup. Arguably
> cleaner.
Claes Redestad has updated the pull request incrementally with six additional
commits since the last revision:
- no clone
- Update src/java.base/share/classes/java/lang/invoke/MethodHandles.java
Simple internal refactor to load a few classes less on startup. Arguably
cleaner.
-
Commit messages:
- Refactor makeHiddenClassDefiner to take ClassOption ...
Changes: https://git.openjdk.org/jdk/pull/21002/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21002&range=00
I
On Thu, 12 Sep 2024 13:26:45 GMT, Claes Redestad wrote:
> Minor refactoring to avoid the need to define two anonymous classes that
> override `EntryMap`. Minor speed-up in interpreter, as well.
This pull request has now been integrated.
Changeset: 0765917d
Author: Claes Redesta
On Thu, 12 Sep 2024 13:26:45 GMT, Claes Redestad wrote:
> Minor refactoring to avoid the need to define two anonymous classes that
> override `EntryMap`. Minor speed-up in interpreter, as well.
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/20966#issuecomment-2346561354
Minor refactoring to avoid the need to define two anonymous classes that
override `EntryMap`. Minor speed-up in interpreter, as well.
-
Commit messages:
- Simplify jdk.internal.classfile.impl.EntryMap
Changes: https://git.openjdk.org/jdk/pull/20966/files
Webrev: https://webrevs.o
On Thu, 12 Sep 2024 11:28:20 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which speeds up `ZipFile.getZipEntry` by removing
>> slash-checking logic which is already taking place during lookup in
>> `ZipFile.Source.getEntryPos`.
>>
>> `ZipFile.Source.getEntryPos` includes logic to match
On Wed, 11 Sep 2024 23:31:33 GMT, Chen Liang wrote:
> Some type descriptors are validated against generic utf8 entries, such as
> field or method types; we can cache a type descriptor wrapping the content of
> the utf8 entry if this entry is ever used as a type descriptor.
>
> This patch is mo
On Wed, 11 Sep 2024 08:34:09 GMT, Eirik Bjørsnøs wrote:
>> src/java.base/share/classes/java/util/zip/ZipFile.java line 681:
>>
>>> 679:
>>> 680: e.flag = CENFLG(cen, pos);
>>> 681: e.method = CENHOW(cen, pos);
>>
>> Not reading `nlen` when it's not needed is a good change, and
On Tue, 10 Sep 2024 18:35:52 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which speeds up `ZipFile.getZipEntry` by removing
> slash-checking logic which is already taking place during lookup in
> `ZipFile.Source.getEntryPos`.
>
> `ZipFile.Source.getEntryPos` includes logic to match a lo
On Tue, 10 Sep 2024 18:35:52 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which speeds up `ZipFile.getZipEntry` by removing
> slash-checking logic which is already taking place during lookup in
> `ZipFile.Source.getEntryPos`.
>
> `ZipFile.Source.getEntryPos` includes logic to match a lo
On Tue, 10 Sep 2024 18:35:52 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which speeds up `ZipFile.getZipEntry` by removing
> slash-checking logic which is already taking place during lookup in
> `ZipFile.Source.getEntryPos`.
>
> `ZipFile.Source.getEntryPos` includes logic to match a lo
On Mon, 9 Sep 2024 22:53:28 GMT, Claes Redestad wrote:
> Misc improvements to InnerClassLambdaMetafactory and InvokerBytecodeGenerator:
> - Define `ClassEntry` early, use it when profitable (there are some warts in
> the API where using `ce.name(), ce.type()` in a few places means we
On Tue, 10 Sep 2024 13:28:55 GMT, Chen Liang wrote:
> After all, this patch will still be valid with ClassEntry hash updates.
Thanks for checking and reviewing!
-
PR Comment: https://git.openjdk.org/jdk/pull/20925#issuecomment-2340800697
On Tue, 10 Sep 2024 10:58:19 GMT, Claes Redestad wrote:
> Trivially remove a static optimization mapping for a non-existent method in
> LambdaMetafactory. The referenced method was refactored into a set of factory
> methods in java.lang.invoke.ConstantBootstraps before ever becoming
On Mon, 9 Sep 2024 01:53:01 GMT, Shaojin Wen wrote:
>> This is a follow-up to PR #20273, which improves performance when the number
>> of parameters exceeds 20.
>>
>> When the number of parameters is large, the possibility of reuse will be
>> lower, so we can use the static concat method and w
On Tue, 10 Sep 2024 11:41:43 GMT, Jorn Vernee wrote:
>> Trivially remove a static optimization mapping for a non-existent method in
>> LambdaMetafactory. The referenced method was refactored into a set of
>> factory methods in java.lang.invoke.ConstantBootstraps before ever becoming
>> a publi
Trivially remove a static optimization mapping for a non-existent method in
LambdaMetafactory. The referenced method was refactored into a set of factory
methods in java.lang.invoke.ConstantBootstraps before ever becoming a public
API.
-
Commit messages:
- Remove unused BootstrapM
1 - 100 of 995 matches
Mail list logo
