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
On Thu, 25 Apr 2024 16:46:25 GMT, Chen Liang 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/share/classes/java/lang/i
> 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 13:35:59 GMT, Chen Liang wrote:
> Do we have any research on the average length of method descriptor strings? I
> wonder if manual pre-allocation works better (iterating all descriptor
> strings, allocate the sum of their sizes plus 2 (for parentheses), as
> descriptor
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.
-
Commit messages:
- Adapt
On Wed, 24 Apr 2024 10:05:27 GMT, Aleksey Shipilev wrote:
>>> I really wish this change was not done with ClassFile API, but with a
>>> simple bundled ASM, so it would be easily backportable, if we decide to. It
>>> does not look like CFA buys us a lot here readability/complexity wise:
>>>
On Thu, 25 Apr 2024 13:38:56 GMT, Viktor Klang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> comma-separated
>
> src/java.base/share/classes/java/lang/constant/MethodTyp
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 th
On Thu, 25 Apr 2024 11:11:48 GMT, Florent Guillaume wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> comma-separated
>
> src/java.base/share/classes/java/lang/constant/MethodTyp
When analyzing (startup) performance of the Classfile API I found this
opportunity to further improve `MethodTypeDescImpl::descriptorString`.
Performance improves across the board in existing microbenchmarks:
Name
(descString) Cnt
Hi,
IIUC this optimization leans on 4 long divs being slower than 1 long div + 4
int divs, which might not be true on all platforms, nor stay true in the
future. Long values will in practice likely be biased towards lower values, so
it’s important that any optimization to .. longer values
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 updated the
On Wed, 24 Apr 2024 10:08:42 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
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 updated
On Wed, 24 Apr 2024 09:57:42 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
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 updated the
On Mon, 22 Apr 2024 10:34:29 GMT, Claes Redestad wrote:
> This switch expression in `Locale::createLocale` is causing a somewhat large
> startup regression on my local system. Desugaring to if statements seem like
> the right thing to do while we investigate ways to further reduce
On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad wrote:
>> This switch expression in `Locale::createLocale` is causing a somewhat large
>> startup regression on my local system. Desugaring to if statements seem like
>> the right thing to do while we investigate ways to furthe
cycles 0,55x (p = 0,000*)
> :.instructions 408219060,350 ± 4031173,140 219415574,800 ± 376992,067
> instructions 0,54x (p = 0,000*)
> :.taskclock 53,500 ± 4,249 22,500 ± 3,858
> ms 0,42x (p = 0,000*)
> * = significant
C
On Mon, 22 Apr 2024 13:05:47 GMT, Chen Liang wrote:
>> This switch expression in `Locale::createLocale` is causing a somewhat large
>> startup regression on my local system. Desugaring to if statements seem like
>> the right thing to do while we investigate ways to further reduce overheads
>>
This switch expression in `Locale::createLocale` is causing a somewhat large
startup regression on my local system. Desugaring to if statements seem like
the right thing to do while we investigate ways to further reduce overheads in
`SwitchBootstraps`.
These numbers are against a baseline
On Thu, 18 Apr 2024 14:50:30 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 Fri, 19 Apr 2024 07:42:19 GMT, Claes Redestad wrote:
>> Investigating a recent regression in mainline I realized we have an
>> opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap
>> by using `invokeExact` in a way similar to what we already do for LM
On Thu, 18 Apr 2024 20:11:15 GMT, Claes Redestad wrote:
> Investigating a recent regression in mainline I realized we have an
> opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by
> using `invokeExact` in a way similar to what we already do for LMF and SC
On Fri, 19 Apr 2024 13:23:53 GMT, Claes Redestad wrote:
> We can reduce overhead of first use of a switch bootstrap by moving
> `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and
> `equals`. The first change avoids loading and initializing the `TypePairs`
On Sat, 20 Apr 2024 07:39:53 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 685:
>>
>>> 683: record TypePairs(Class from, Class to) {
>>> 684:
>>> 685: private static final Map typePairToName =
>>> initialize();
>>
>> If
excess code generation from
> happening on first use.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Revert changes, splitting these out to a separate PR
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18865/files
excess code generation from
> happening on first use.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Remove redundant mappings; store an immutable copy
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18865/files
We can reduce overhead of first use of a switch bootstrap by moving
`typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and
`equals`. The first change avoids loading and initializing the `TypePairs`
class in actual cases, the second remove some excess code generation from
and equates to a one-off
> startup win of around 5ms in any app that ever has the need to spin up a
> toString, equals or hashCode method on a record.
Claes Redestad has updated the pull request incrementally with two additional
commits since the last revision:
- Copyr
On Fri, 19 Apr 2024 04:45:56 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use Arrays.copyOfRange
>
> src/java.base/share/classes/java/lang/invoke/Bootstrap
and equates to a one-off
> startup win of around 5ms in any app that ever has the need to spin up a
> toString, equals or hashCode method on a record.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Use Arrays.copyOfRange
Investigating a recent regression in mainline I realized we have an opportunity
to improve the bootstrap overheads of ObjectMethods::bootstrap by using
`invokeExact` in a way similar to what we already do for LMF and SCF BSMs. This
avoids generating type checking adapters and equates to a
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 upda
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 upd
On Wed, 17 Apr 2024 15:21:32 GMT, Adam Sotona wrote:
>> java.base java.lang.invoke package heavily uses ASM to generate lambdas and
>> method handles.
>>
>> This patch converts ASM calls to Classfile API.
>>
>> This PR is continuation of https://github.com/openjdk/jdk/pull/12945
>>
>> Any
On Fri, 10 Nov 2023 08:17:22 GMT, Per Minborg wrote:
>> This PR outlines a solution for making immutable maps `@ValueBased` by
>> removing cacheing of certain values in `AbstractMap`.
>>
>> By removing these caching fields in `AbstractMap`, we can make the immutable
>> maps `@ValueBased` and
101 - 200 of 701 matches
Mail list logo
