On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad wrote:
> Extracting duplicate method references to static field reduce proxy class
> spinning and loading. In this case 2 less classes loaded when using
> `findAny()` on each type of stream.
Vicente filed a bug on javac to in
On Thu, 30 May 2024 13:04:46 GMT, Chen Liang wrote:
> Should we extract them to private static utility methods for potential
> laziness support in the future?
Ideally we shouldn't have to do any of this. I thought such method references
were already de-duplicated in javac - at least within
Extracting duplicate method references to static field reduce proxy class
spinning and loading. In this case 2 less classes loaded when using `findAny()`
on each type of stream.
-
Commit messages:
- De-duplicate identical lambdas in FindOps
Changes:
On Thu, 30 May 2024 10:02:25 GMT, Alan Bateman wrote:
> Would it be possible to provide more context/background here? This is not
> code that is used during startup. Is there benchmark data to share for first
> use of java.io.IO ?
I think this was brought to the fore by
On Wed, 29 May 2024 09:18:51 GMT, Pavel Rappo wrote:
>> The non-constant test was added because that very bailout caused a crash.
>> The other test is actually less interesting since it'll likely be covered
>> indirectly by regular use. But as we are hiding these away this gets ever
>> more
On Wed, 29 May 2024 22:25:09 GMT, Naoto Sato wrote:
>> Yes, `break` guarantees that the search completes one way or another once
>> the module name has been matched. This is not how it used to be done.
>
> Right. Since `findAny` is after the module name matching, there is at most 1
> match. In
On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato wrote:
> There is an initialization code in `Console` class that searches for the
> Console implementations. Refactoring the init code not to use lambda/stream
> would reduce the (initial) number of loaded classes by about 100 for
> java.base
On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo wrote:
>> Please review this PR, which supersedes a now withdrawn
>> https://github.com/openjdk/jdk/pull/14831.
>>
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
>> user-friendly methods. Here's a summary:
>>
>> - Made
On Wed, 29 May 2024 03:16:02 GMT, Chen Liang wrote:
>> In fact, if I change it to `2`, the following tests will fail:
>>
>> - `jdk/jdk/classfile/Utf8EntryTest.java`
>> - `jdk/java/util/zip/ZipCoding.java`
>> - `jdk/java/text/Format/MessageFormat/MessageRegression.java`
>
> Indeed, the
On Tue, 28 May 2024 19:13:30 GMT, Jorn Vernee wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 275:
>
On Tue, 28 May 2024 19:19:51 GMT, Jorn Vernee wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> test/hotspot/jtreg/compiler/intrinsics/TestArraysHashCode.java line 88:
>
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
1 - 100 of 649 matches
Mail list logo