On Fri, 24 May 2024 08:24:15 GMT, Adam Sotona wrote:
>> Hi,
>> During performance optimization work on Class-File API as JDK lambda
>> generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields
>> initialized with
On Mon, 20 May 2024 10:52:27 GMT, Claes Redestad wrote:
> We can fold the call to `Objects.checkIndex` into the code generated in
> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
> This loads 9 less classes (of which 8 generated LFs and Specie
On Thu, 23 May 2024 11:09:14 GMT, Claes Redestad wrote:
>> We can fold the call to `Objects.checkIndex` into the code generated in
>> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
>> This loads 9 less classes (of which 8 generated LFs a
On Thu, 23 May 2024 09:46:51 GMT, Jan Lahoda wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add type switch to HelloClasslist
>
> src/java.base/share/classes/java/lang/runtime
used `findStatic`
> calls to a holder. All in all this means a reduction by 22M cycles to
> bootstrap a trivial switch expression on my M1.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Remove unused im
On Wed, 22 May 2024 07:49:27 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test-only change for addressing
>> https://bugs.openjdk.org/browse/JDK-8332490?
>>
>> The jmh test opens a `InflaterInputStream`, reads the stream contents, but
>> then doesn't close the stream. This
On Wed, 22 May 2024 07:20:04 GMT, Alan Bateman wrote:
>> Can I please get a review of this test-only change for addressing
>> https://bugs.openjdk.org/browse/JDK-8332490?
>>
>> The jmh test opens a `InflaterInputStream`, reads the stream contents, but
>> then doesn't close the stream. This
On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change for addressing
> https://bugs.openjdk.org/browse/JDK-8332490?
>
> The jmh test opens a `InflaterInputStream`, reads the stream contents, but
> then doesn't close the stream. This can
On Tue, 21 May 2024 09:01:32 GMT, Claes Redestad wrote:
>> We can fold the call to `Objects.checkIndex` into the code generated in
>> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
>> This loads 9 less classes (of which 8 generated LFs a
On Tue, 21 May 2024 09:01:32 GMT, Claes Redestad wrote:
>> We can fold the call to `Objects.checkIndex` into the code generated in
>> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
>> This loads 9 less classes (of which 8 generated LFs a
used `findStatic`
> calls to a holder. All in all this means a reduction by 22M cycles to
> bootstrap a trivial switch expression on my M1.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Add type switch to HelloClas
used `findStatic`
> calls to a holder. All in all this means a reduction by 22M cycles to
> bootstrap a trivial switch expression on my M1.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Revert bf68b1d, tidy up
---
On Tue, 21 May 2024 00:16:51 GMT, Chen Liang wrote:
>> We can fold the call to `Objects.checkIndex` into the code generated in
>> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
>> This loads 9 less classes (of which 8 generated LFs and Species classes) on
>> a
On Mon, 20 May 2024 18:06:32 GMT, Chen Liang wrote:
>> We can fold the call to `Objects.checkIndex` into the code generated in
>> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
>> This loads 9 less classes (of which 8 generated LFs and Species classes) on
>> a
On Mon, 20 May 2024 10:52:27 GMT, Claes Redestad wrote:
> We can fold the call to `Objects.checkIndex` into the code generated in
> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
> This loads 9 less classes (of which 8 generated LFs and Specie
We can fold the call to `Objects.checkIndex` into the code generated in
generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
This loads 9 less classes (of which 8 generated LFs and Species classes) on a
minimal test, while being neutral on a throughput sanity test:
On Mon, 6 May 2024 14:39:08 GMT, Claes Redestad wrote:
> This PR suggests refactoring the implementation classes of java.lang.constant
> into a new package jdk.internal.constant to enable sharing some trusted
> static factory methods with users elsewhere in
On Wed, 15 May 2024 11:17:42 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewher
On Wed, 15 May 2024 11:17:42 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewher
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Redestad ha
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Redestad has
On Wed, 15 May 2024 09:51:13 GMT, Adam Sotona wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use sb.repeat, consolidate
>
> src/java.base/share/classes/java/lang/constant/Clas
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Redestad
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes R
On Tue, 14 May 2024 20:20:59 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add microbenchmark for ClassDesc methods + a few optimizations
>
> src/java.base/sh
On Tue, 14 May 2024 17:25:37 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewher
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Redesta
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Redes
On Fri, 10 May 2024 08:50:07 GMT, Claes Redestad wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewher
On Mon, 6 May 2024 18:24:25 GMT, Adam Sotona wrote:
>> Hi,
>> During performance optimization work on Class-File API as JDK lambda
>> generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields
>> initialized with
On Fri, 10 May 2024 04:55:21 GMT, Chen Liang wrote:
>> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's
>> LambdaForm method type parameters. Since they are distinct from those of
>> Linkers, they are now tracked and generated separately. It seems that no
>> proper
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Redestad h
On Thu, 9 May 2024 13:34:16 GMT, Claes Redestad wrote:
>> A rather large startup regression was introduced in 23-b13 from
>> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
>> been dealt with as enhancements such as
>> [JDK-8330802](https:/
On Wed, 8 May 2024 14:53:05 GMT, Claes Redestad wrote:
> A rather large startup regression was introduced in 23-b13 from
> [JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
> been dealt with as enhancements such as
> [JDK-8330802](https://bugs.openjdk.or
On Thu, 9 May 2024 21:15:31 GMT, Chen Liang wrote:
>> A peek into TypeKind during the research for #19105 reveals that TypeKind
>> has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
>> use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if
On Thu, 9 May 2024 12:29:40 GMT, Adam Sotona wrote:
>> I actually am not sure of the reason; it is indeed a tableswitch in
>> bytecode. @cl4es might know it better?
>
> Generally I agree with the API changes and with the
> `descriptor.isPrimitive()` test before requesting a descriptor string.
rticular case
> since the amount of added bootstrapping overhead is dependent on which locale
> the system runs under, which complicates testing and comparisons due to
> relatively large differences in paths taken on different systems.
Claes Redestad has updated the pull request incre
On Wed, 8 May 2024 18:32:42 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove redundant constructor
>
> src/java.base/share/classes/jdk/internal/util/Reference
On Wed, 8 May 2024 20:24:52 GMT, Chen Liang wrote:
> This patch allows us to merge parsing logic for invoke, constant, and
> classfile in the future, all in jdk.internal.
Thanks for reviewing! Yes, that's the idea.
-
PR Comment:
On Wed, 8 May 2024 19:06:35 GMT, ExE Boss wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Refactor to further avoid re-validating arguments
>
> src/java.base/share
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Redestad has
On Wed, 8 May 2024 17:57:22 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove redundant constructor
>
> src/java.base/share/classes/sun/util/locale/Bas
On Wed, 8 May 2024 17:23:25 GMT, Alan Bateman wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Extract singleton for interning BaseLocale
>
> src/java.base/share/classes/j
rticular case
> since the amount of added bootstrapping overhead is dependent on which locale
> the system runs under, which complicates testing and comparisons due to
> relatively large differences in paths taken on different systems.
Claes Redestad has updated the pull request incre
rticular case
> since the amount of added bootstrapping overhead is dependent on which locale
> the system runs under, which complicates testing and comparisons due to
> relatively large differences in paths taken on different systems.
Claes Redestad has updated the pull request incre
rticular case
> since the amount of added bootstrapping overhead is dependent on which locale
> the system runs under, which complicates testing and comparisons due to
> relatively large differences in paths taken on different systems.
Claes Redestad has updated the pull request incre
A rather large startup regression was introduced in 23-b13 from
[JDK-8309622](https://bugs.openjdk.org/browse/JDK-8309622). Some of that has
been dealt with as enhancements such as
[JDK-8330802](https://bugs.openjdk.org/browse/JDK-8330802),
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Red
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Redestad has
On Tue, 7 May 2024 12:18:52 GMT, Rémi Forax wrote:
>> I assume it's about performance. If so, I would defer any
>> performance-related tweaks until they are necessary. Interactive reading
>> from console does not sound like something requiring that level of
>> performance tweaking.
>
> yes,
On Tue, 7 May 2024 01:49:27 GMT, Chen Liang wrote:
>> A peek into TypeKind during the research for #19105 reveals that TypeKind
>> has a few issues:
>> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
>> use "newarray code"
>> 2. `fromDescriptor` can throw IOOBE if
On Mon, 6 May 2024 20:48:05 GMT, Chen Liang wrote:
> A peek into TypeKind during the research for #19105 reveals that TypeKind has
> a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
> use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the
On Mon, 6 May 2024 20:48:05 GMT, Chen Liang wrote:
> A peek into TypeKind during the research for #19105 reveals that TypeKind has
> a few issues:
> 1. Name mismatch for `newarraycode` and `fromNewArrayCode`: Renamed both to
> use "newarray code"
> 2. `fromDescriptor` can throw IOOBE if the
On Mon, 6 May 2024 14:58:02 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename ofTrusted to ofValidated, remove accidental module-info exports
>
> src/jav
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Redest
ge
> ClassDescFactories.ReferenceOnly.ofNested 6 209,853 ± 132,525 22,017 ±
> 0,573 ns/op 9,53x (p = 0,000*)
> * = significant
>
>
> The optimizations could be split out and PRd independently, but I think they
> are simple enough to include in this refactoring.
Claes Redestad
On Mon, 6 May 2024 14:51:17 GMT, Chen Liang wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
On Mon, 6 May 2024 14:46:09 GMT, Chen Liang wrote:
>> This PR suggests refactoring the implementation classes of
>> java.lang.constant into a new package jdk.internal.constant to enable
>> sharing some trusted static factory methods with users elsewhere in
>> java.base, such as
This PR suggests refactoring the implementation classes of java.lang.constant
into a new package jdk.internal.constant to enable sharing some trusted static
factory methods with users elsewhere in java.base, such as java.lang.invoke and
java.lang.classfile. The refactoring also adds some
On Thu, 2 May 2024 11:08:16 GMT, Adam Sotona wrote:
>> Hi,
>> During performance optimization work on Class-File API as JDK lambda
>> generator we found some static initialization killers.
>> One of them is `java.lang.classfile.Attributes` with tens of static fields
>> initialized with
On Tue, 30 Apr 2024 14:38:11 GMT, Pavel Rappo wrote:
> Please review this trivial method rename. While this issue was originally
> spotted in [another PR], it makes sense to address it separately. Test
> results are pending; not that I expect failures, but still.
>
> [another PR]:
>
On Mon, 29 Apr 2024 08:11:06 GMT, Claes Redestad wrote:
> I'm looking at ways at reducing/eliminating startup overheads the classfile
> API in preparation of #17108, and have pushed a series of enhancements to
> that effect already. This PR is a collection of minor improvements which
On Mon, 29 Apr 2024 17:45:55 GMT, Mandy Chung wrote:
> The changes look good to me but I wonder if the non-zero length check before
> calling `arraycopy` really needed? That seems to add some noise to the code.
I recall benchmarking similar code in `MethodType` extensively, and found that
it
On Mon, 29 Apr 2024 14:16:34 GMT, Per Minborg wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Simplified void check
>
> src/java.base/share/classes/java/lang/constant/Constant
ons - or a 5% reduction in
> executed bytecode - on a simple lambda startup test.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Simplified void check
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18991/files
On Mon, 29 Apr 2024 12:18:15 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Descriptors can't be empty, optimize isArray and isClassOrInterface with
>> descripto
ons - or a 5% reduction in
> executed bytecode - on a simple lambda startup test.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Descriptors can't be empty, optimize isArray and isClassOrInterface with
descriptorSt
I'm looking at ways at reducing/eliminating startup overheads the classfile API
in preparation of #17108, and have pushed a series of enhancements to that
effect already. This PR is a collection of minor improvements which add up to a
1.5% reduction in retired instructions - or a 5% reduction
On Thu, 25 Apr 2024 09:41:11 GMT, Claes Redestad wrote:
> When analyzing (startup) performance of the Classfile API I found this
> opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>
> Performance improves across the board in existing microbenchmark
On Fri, 26 Apr 2024 14:57:07 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally avail
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as
On Fri, 26 Apr 2024 22:27:43 GMT, Claes Redestad wrote:
>> When analyzing (startup) performance of the Classfile API I found this
>> opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>>
>> Performance improves across the board in existing micr
lied similar approach to `MethodTypeDesc::displayDescriptor`:
> while not performance sensitive I think these are so inter-related that it
> makes sense to implement them in a similar fashion.
Claes Redestad has updated the pull request with a new target base due to a
merge or a rebase.
On Fri, 26 Apr 2024 20:35:44 GMT, Mandy Chung wrote:
>> While I agree it may seem non-sensical to define `CD_Object` for `Object`,
>> there's precedent in that `Wrapper.primitiveType` is `Object.class` - so for
>> consistency I wired it up the same way. For the usage patterns introduced
>>
On Fri, 26 Apr 2024 18:21:16 GMT, Mandy Chung wrote:
> I am glad that this only focuses on the descriptor string as
> `MethodTypeDesc::displayDescriptor` is typically used for debugging and
> exception message and not performance-sensitive.
Yes, which is why I'd really like to desugar it:
On Fri, 26 Apr 2024 17:57:52 GMT, Mandy Chung wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Copyrights and other comments from @JornVernee
>
> src/java.base/share/classes/sun/inv
On Fri, 26 Apr 2024 02:20:34 GMT, Mandy Chung wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Nits, clean up constant, introduce missing constant MethodTypeDesc for
>> toStri
On Fri, 26 Apr 2024 14:47:16 GMT, Chen Liang wrote:
> For the `equals` remark, it's that DynamicConstantDesc's equals is final so
> subclasses cannot provide a faster implementation. But that's another topic.
Hmm, that is unfortunate, yes.
-
PR Comment:
le avoiding perturbing performance
> at the vast majority of call sites.
>
> I was asked to use the new class file API for mainline. There's a version of
> this patch implemented using ASM in 7c52a9f which might be a reasonable basis
> for a backport.
Claes Redestad has
On Fri, 26 Apr 2024 10:27:16 GMT, Claes Redestad wrote:
> This PR makes ClassDesc.ofDescriptor return the shared constant for primitive
> descriptor strings ("I" etc..), and leverages this further by refactoring
> `MethodTypeDescImpl.ofDescriptor` to avoid the int
On Fri, 26 Apr 2024 12:43:32 GMT, Chen Liang wrote:
> Primitive class desc sharing should be really helpful, especially considering
> that they are represented as condy and their `equals` is thus quite
> inefficient.
Ok. We could consider overriding `equals` in `PrimitiveClassDescImpl` if
On Fri, 26 Apr 2024 12:58:35 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 163:
>>
>>> 161: // implicit null-check
>>> 162: return (descriptor.length() == 1)
>>> 163:?
>>>
On Thu, 25 Apr 2024 14:15:56 GMT, Claes Redestad wrote:
> Splitting out the ASM-based version from #18690 to push that first under the
> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
> this as a subtask. See discussion in that #18690 for more details, d
On Fri, 26 Apr 2024 11:27:35 GMT, Jorn Vernee wrote:
> Looks like your `MethodTypeDescFactories` benchmark is missing form the PR?
>
Pre-existing.
> Does removing the explicit null checks make that much difference for
> performance? They are kind of nice for clarity.
>
It helps startup at
,000*)
> :gc.alloc.rate.norm
> 520,002 ± 0,000328,001 ± 0,000 B/op 0,63x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ()[Ljava/lang/String;
> 6 35,036 ± 0,351 36,010 ± 3
,000*)
> :gc.alloc.rate.norm
> 520,002 ± 0,000328,001 ± 0,000 B/op 0,63x (p = 0,000*)
> MethodTypeDescFactories.ofDescriptor ()[Ljava/lang/String;
> 6 35,036 ± 0,351 36,010 ± 3
This PR makes ClassDesc.ofDescriptor return the shared constant for primitive
descriptor strings ("I" etc..), and leverages this further by refactoring
`MethodTypeDescImpl.ofDescriptor` to avoid the intermediate substring for
primitives.
Microbenchmarks results look good with expected
On Fri, 26 Apr 2024 09:42:06 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #1869
On Fri, 26 Apr 2024 08:45:45 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #1869
> Splitting out the ASM-based version from #18690 to push that first under the
> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
> this as a subtask. See discussion in that #18690 for more details, discussion
> and motivation for this.
Claes Redestad
On Thu, 25 Apr 2024 19:53:46 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #1869
> Splitting out the ASM-based version from #18690 to push that first under the
> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
> this as a subtask. See discussion in that #18690 for more details, discussion
> and motivation for this.
Claes Redestad
On Fri, 26 Apr 2024 02:36:22 GMT, Chen Liang wrote:
> Also a side note for backport: ClassFileDumper exists only since JDK 21, so
> for earlier backports you need to use an alternative dumping method or remove
> dumping ability.
Yes, original code used ProxyClassDumper, which was
On Fri, 26 Apr 2024 03:14:54 GMT, Mandy Chung wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove accidental use of java.lang.classfile
>
> src/java.base/
On Fri, 26 Apr 2024 02:20:34 GMT, Mandy Chung wrote:
> It's a little confusing for JDK-8327247 to have 2 PRs but it's okay. We can
> add a note in JDK-8327247 to clarify. I assume you plan to use PR to convert
> to use ClassFile API after you pull from JDK-8327247 once integrated?
Yes, this
On Thu, 25 Apr 2024 23:03:58 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java line
>> 181:
>>
>>> 179: sb.append(argType.descriptorString());
>>> 180: }
>>> 181: desc =
>>>
On Thu, 25 Apr 2024 23:06:00 GMT, Chen Liang wrote:
> For the precise-length approach, do you have the results? I guess if we can
> avoid copying the stringbuilder array, we can make this even faster.
Not sure what you mean - the latest performance numbers I posted are for the
precise length
lied similar approach to `MethodTypeDesc::displayDescriptor`:
> while not performance sensitive I think these are so inter-related that it
> makes sense to implement them in a similar fashion.
Claes Redestad has updated the pull request incrementally with one additional
commit since t
lied similar approach to `MethodTypeDesc::displayDescriptor`:
> while not performance sensitive I think these are so inter-related that it
> makes sense to implement them in a similar fashion.
Claes Redestad has updated the pull request incrementally with one additional
commit since the la
On Thu, 25 Apr 2024 13:34:50 GMT, Claes Redestad wrote:
>> When analyzing (startup) performance of the Classfile API I found this
>> opportunity to further improve `MethodTypeDescImpl::descriptorString`.
>>
>> Performance improves across the board in existing micr
1 - 100 of 637 matches
Mail list logo
