On Mon, 12 Aug 2024 17:44:50 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
On Thu, 25 Jul 2024 00:43:09 GMT, Shaojin Wen wrote:
>> The solution is to call `.erase()` on the input method handle, and call
>> `viewAsType` on the result method handle.
>
> Sorry, I don't understand what you mean. The following code can't solve the
> above build error
>
>
> public static
On Mon, 12 Aug 2024 16:16:10 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision
On Mon, 12 Aug 2024 18:35:45 GMT, Shaojin Wen wrote:
> Should we change the title of the PR to `Implementing an efficient string
> concatenation hidden class strategy based on ClassFile API`?
Yes, or something shorter like `"8336856: Efficient hidden class-based string
concatenation strategy"`
On Mon, 12 Aug 2024 17:44:50 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
fix comments
-
Changes:
- all: https://git
On Mon, 12 Aug 2024 16:16:10 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision
On Mon, 12 Aug 2024 16:52:53 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/StringConcatHelper.java line 83:
>>
>>> 81:
>>> 82: @ForceInline
>>> 83: private final String concat(char value) {
>>
>> These mostly help avoid a bit of class spinning on startup, rig
On Mon, 12 Aug 2024 14:47:13 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix comments
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 83:
>
>> 81:
>> 82: @For
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with two additional
commits since the last revision:
- fix comments
- remove unused code
-
Chang
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with four additional
commits since the last revision:
- Update src/java.base/share/classes/java/lang/invoke/Str
On Thu, 8 Aug 2024 11:43:07 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
On Thu, 8 Aug 2024 11:43:07 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
On Thu, 8 Aug 2024 11:43:07 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
On Thu, 8 Aug 2024 11:43:07 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
fix comments
-
Changes:
- all: https://git
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
fix comments
-
Changes:
- all: https://git
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
1. not generate coderArgs unless needed
2. code style
-
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
refactor checkOverflow
-
Changes:
- all: h
On Tue, 6 Aug 2024 23:41:09 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with six additional
> commits since the last revision:
On Tue, 6 Aug 2024 23:41:09 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with six additional
> commits since the last revision:
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with six additional
commits since the last revision:
- checkOverflow
- highArity default 0
- use MethodTypeDe
On Tue, 6 Aug 2024 18:07:16 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision:
On Tue, 6 Aug 2024 18:07:16 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision:
On Tue, 6 Aug 2024 18:07:16 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision:
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with two additional
commits since the last revision:
- copyright
- remove unused import
-
Change
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
resolve the WithSecurityManager test failure
On Tue, 6 Aug 2024 17:01:11 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
fix comments & code style
-
Changes:
- all
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
typo
-
Changes:
- all: https://git.openjdk
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 93 commits:
- Merge remote-tracking branch '
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with four additional
commits since the last revision:
- copyright
- add comments & code style & make code clea
On Sun, 4 Aug 2024 16:09:08 GMT, Shaojin Wen wrote:
>> This PR implements the same algorithm as the current generateMHInlineCopy
>> based on bytecode to improve startup performance.
>
> Shaojin Wen has updated the pull request incrementally with 11 additional
> commits since the last revision:
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with 11 additional
commits since the last revision:
- 1. split length & coder & prepend method
2. fix commen
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
remove lengthcoder
-
Changes:
- all: https
> This PR implements the same algorithm as the current generateMHInlineCopy
> based on bytecode to improve startup performance.
Shaojin Wen has updated the pull request incrementally with 14 additional
commits since the last revision:
- Merge pull request #9 from cl4es/pr_20273_inject_cache
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Fri, 2 Aug 2024 00:59:06 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the len
On Fri, 2 Aug 2024 01:04:08 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix performance regression caused by args.erase()
>
> I think erasing arguments is needed for correctness - are you sur
On Fri, 2 Aug 2024 00:59:06 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the len
On Fri, 2 Aug 2024 00:59:06 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the len
On Fri, 2 Aug 2024 00:59:06 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the len
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Wed, 31 Jul 2024 22:27:53 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Sun, 28 Jul 2024 15:59:05 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Sun, 28 Jul 2024 13:58:05 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
On Sun, 28 Jul 2024 13:58:05 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Thu, 25 Jul 2024 23:36:02 GMT, Shaojin Wen wrote:
>> test/micro/org/openjdk/bench/java/lang/StringConcatGenerate.java line 47:
>>
>>> 45: @Measurement(iterations = 5, time = 1000, timeUnit =
>>> TimeUnit.MILLISECONDS)
>>> 46: @Fork(value = 3, jvmArgsAppend =
>>> "-Djava.lang.invoke.StringCo
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Sat, 27 Jul 2024 23:08:36 GMT, Shaojin Wen wrote:
> Should mixer and prepend add the two types of Integer and Long? Now we need
> to do integer.toString and then concatenate, which leads to performance
> degradation.
I think the generic problem with specializing on types is that this leads
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Thu, 25 Jul 2024 14:52:11 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
On Thu, 25 Jul 2024 10:15:20 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add benchmark
>
> test/micro/org/openjdk/bench/java/lang/StringConcatGenerate.java line 47:
>
>> 45: @Measurement(ite
On Thu, 25 Jul 2024 14:52:11 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Thu, 25 Jul 2024 08:58:14 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Wed, 24 Jul 2024 15:08:50 GMT, Chen Liang wrote:
>> If you do not use TRUSTED Lookup, errors will occur when processing records.
>>
>> You can see this build error
>> https://github.com/wenshao/jdk/actions/runs/10049344961/job/27775952878
>>
>> TEST: java/lang/reflect/records/RecordReflecti
On Tue, 23 Jul 2024 13:35:41 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains six commits:
>>
>> - Merge remote-tracking branch 'origin/optim_simple_concat_202407' into
>> optim_concat_fa
On Wed, 24 Jul 2024 14:56:48 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line
>> 1119:
>>
>>> 1117:
>>> 1118: private static MethodHandle generate(Lookup lookup,
>>> MethodType args, String[] constants) throws Exception {
>>> 1119:
On Wed, 24 Jul 2024 14:34:01 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 32 commits:
>>
>> - Merge remote-tracking branch 'upstream/master' into
>> optim_concat_factory_202407
>> - typo
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Wed, 24 Jul 2024 11:43:45 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
On Wed, 24 Jul 2024 11:43:45 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Wed, 24 Jul 2024 10:18:03 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
On Wed, 24 Jul 2024 10:18:03 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Tue, 23 Jul 2024 09:02:48 GMT, Shaojin Wen wrote:
> The ClassData of LambdaMetafactory has only one MethodHandle, but multiple
> MethodHandles are needed here.
In these cases, we pass a `List.of(methodHandles)`, and call extra
`.constantInstruction(index).invokeinterface(CD_List, "get", MTD
On Tue, 23 Jul 2024 12:22:57 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Tue, 23 Jul 2024 10:19:47 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Mon, 22 Jul 2024 14:27:39 GMT, Chen Liang wrote:
> For the question
> [here](https://github.com/openjdk/jdk/pull/20253#issuecomment-2242267516):
>
> 1. A sample of loading an otherwise inaccessible method handle from class
> data:
> https://github.com/openjdk/jdk/blob/c3226aaeb810521257e96
On Mon, 22 Jul 2024 22:34:01 GMT, Shaojin Wen wrote:
>> The current implementation of StringConcat is to mix the coder and length
>> into a long. This operation will have some overhead for int/long/boolean
>> types. We can separate the calculation of the coder from the calculation of
>> the le
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length, which can improve the performance in the scenario of
On Sun, 21 Jul 2024 12:25:36 GMT, Shaojin Wen wrote:
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length
On Sun, 21 Jul 2024 12:25:36 GMT, Shaojin Wen wrote:
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length
On Sun, 21 Jul 2024 12:25:36 GMT, Shaojin Wen wrote:
> The current implementation of StringConcat is to mix the coder and length
> into a long. This operation will have some overhead for int/long/boolean
> types. We can separate the calculation of the coder from the calculation of
> the length
The current implementation of StringConcat is to mix the coder and length into
a long. This operation will have some overhead for int/long/boolean types. We
can separate the calculation of the coder from the calculation of the length,
which can improve the performance in the scenario of concat i
92 matches
Mail list logo
