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
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 Redes
On Fri, 12 Apr 2024 15:06:36 GMT, Chen Liang wrote:
>> I'd prefer considering such optimizations as follow-ups. We need to think
>> about where to define such shared classes in a way that considers the full
>> lifecycle, facilitates class unloading (one cache per classloader?) while
>> still
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 update
On Sat, 13 Apr 2024 17:54:54 GMT, Brett Okken wrote:
>> Possibly. I tried a few simple variants that initialized the `StringBuilder`
>> capacity at various guesses, such as sum of constant sizes + some factor
>> based on args, but across a diverse set of micros that gives both some wins
>>
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 Fri, 12 Apr 2024 14:26:04 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> @liach feedback
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory
On Fri, 12 Apr 2024 14:53:58 GMT, Chen Liang 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 an
>>
On Fri, 12 Apr 2024 14:32:05 GMT, Chen Liang 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 an
>>
On Fri, 12 Apr 2024 13:44:23 GMT, Rémi Forax wrote:
> One class per arity + value classes can be a good combo ?
Not sure value classes matter here? We would need one static instance per call
site holding the constants. Trickier for performance is the potential for
profile pollution between
On Fri, 12 Apr 2024 11:41:17 GMT, Thomas Stuefe wrote:
> Yes, we are concerned with that, especially for a possible future where
> Lilliput is the sole default. Atm we can address about 4 million classes.
> There are thoughts about making this number of classes infinite, but if
> possible we
On Fri, 12 Apr 2024 03:16:58 GMT, Brett Okken 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 an
>>
On Fri, 12 Apr 2024 06:34:32 GMT, Thomas Stuefe wrote:
> Stupid question maybe, this would be one LambdaForm per argument set? E.g.
> would two invocations with the same arguments re-use the same LambdaForm?
>
> I would like to get an understanding of the numbers of classes involved for
>
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
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 an all-or-nothing
strategy choice.
Instead of reintroducing a binary
On Wed, 20 Mar 2024 22:56:38 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Fri, 22 Mar 2024 17:58:25 GMT, Raffaello Giulietti
wrote:
> Make use of an unused local variable probably intended to replace later casts.
Marked as reviewed by redestad (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/18460#pullrequestreview-1955510870
On Thu, 14 Mar 2024 00:00:53 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Thu, 14 Mar 2024 00:00:53 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Mon, 18 Mar 2024 14:09:09 GMT, Per Minborg wrote:
> This PR proposes to remove the native method `StringUTF16::isBigEndian` and
> its corresponding C implementation and instead rely on the
> `jdk.internal.misc.Unsafe::isBigEndian` method.
>
> This PR passes tier1-3 tests.
> Initialization
On Mon, 18 Mar 2024 14:09:09 GMT, Per Minborg wrote:
> This PR proposes to remove the native method `StringUTF16::isBigEndian` and
> its corresponding C implementation and instead rely on the
> `jdk.internal.misc.Unsafe::isBigEndian` method.
Does this change how early `Unsafe` is initialized,
On Wed, 13 Mar 2024 13:12:54 GMT, Shaojin Wen wrote:
>> If the input is "+" or "-" an exception will be thrown on line 583
>>
>> boolean isneg = c == '-'; // leading minus means negative
>> if (isneg || c == '+') {
>> c = val.charAt(++offset);
>>
On Wed, 13 Mar 2024 09:52:45 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Tue, 12 Mar 2024 19:09:27 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Tue, 12 Mar 2024 13:07:26 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Tue, 12 Mar 2024 10:34:33 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Tue, 12 Mar 2024 10:34:33 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Tue, 12 Mar 2024 10:34:33 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Tue, 12 Mar 2024 06:18:27 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
On Mon, 11 Mar 2024 14:15:38 GMT, Chen Liang wrote:
> Looks great to me. Sorry for the pings, but we may need @rgiulietti to verify
> the math correctness and @cl4es to comment on whether having these 2 separate
> code paths or trying to extract a common part is the better approach.
I'd love
On Mon, 4 Mar 2024 17:27:26 GMT, Alan Bateman wrote:
> It's a bit unusual to have the final modifier on static methods, looks like
> it goes back to JDK 1.1 at least, not clear if it was intentional.
Right, I was asked by JCK folks to either file a CSR to have the change
recorded, or revert.
On Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad wrote:
> [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally
> removed `final` from the `static final DataInputStream.readUTF` method. This
> has a minor compatibility impact (allows hiding the method in a subclass,
[JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally removed
`final` from the `static final DataInputStream.readUTF` method. This has a
minor compatibility impact (allows hiding the method in a subclass, while
before that would throw an exception at compile time) and since it
On Mon, 4 Mar 2024 12:00:18 GMT, Adam Sotona wrote:
>> ClassFile API performance related improvements have been separated from
>> #17121 into this PR.
>>
>> These improvements are important to minimize performance regression of
>> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to
On Mon, 15 Jan 2024 12:01:37 GMT, Adam Sotona wrote:
>> ClassFile API performance related improvements have been separated from
>> #17121 into this PR.
>>
>> These improvements are important to minimize performance regression of
>> 8294961: Convert java.base/java.lang.reflect.ProxyGenerator to
> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via
> Data- and ObjectInputStream
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Stray space
-
Changes:
On Mon, 26 Feb 2024 15:50:55 GMT, Roger Riggs wrote:
>> Claes Redestad has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java
>>
&
On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote:
> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via
> Data- and ObjectInputStream
>
> Testing: tier1-3
This pull request has now been integrated.
Changeset: 9a9cfbe0
Author:Claes Redestad
URL:
On Mon, 26 Feb 2024 11:05:10 GMT, Claes Redestad wrote:
> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when
> generating some classes.
>
> Since JDK 9 we have a fast-path (which avoids creating encoders) for
> UTF-8-encoding strings which is bootstra
On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote:
>> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when
>> generating some classes.
>>
>> Since JDK 9 we have a fast-path (which avoids creating encoders) for
>> UTF-8-encoding stri
On Mon, 26 Feb 2024 14:47:06 GMT, Roger Riggs wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove temporary microbenchmark
>
> src/java.base/share/classes/jdk/internal/reflec
xed` from the PR before merging,
> but wanted to include it initially to show what I've measured.)
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Remove temporary microbenchmark
-
Changes:
- all: https://git.openj
jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when
generating some classes.
Since JDK 9 we have a fast-path (which avoids creating encoders) for
UTF-8-encoding strings which is bootstrapped very early, so it seems safe to
rewire this and remove the UTF8 helper class
On Tue, 20 Feb 2024 20:58:50 GMT, Claes Redestad wrote:
> Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem
> out-of-place (not testing `StringBuffer`), redundant (covered by other tests
> like StringSubstring or the various String concatenation tests)
On Tue, 20 Feb 2024 20:58:50 GMT, Claes Redestad wrote:
> Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem
> out-of-place (not testing `StringBuffer`), redundant (covered by other tests
> like StringSubstring or the various String concatenation tests)
Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem
out-of-place (not testing `StringBuffer`), redundant (covered by other tests
like StringSubstring or the various String concatenation tests), or both. This
cleans them out.
My apologies to Sigurd.
-
Commit
On Tue, 20 Feb 2024 18:42:16 GMT, Claes Redestad wrote:
>> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
>> StringBuilder/StringBuffer::toString returns `""` when the builders are
>> empty.
>>
>>
>> Name
On Tue, 20 Feb 2024 16:32:54 GMT, Claes Redestad wrote:
> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
> StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
>
>
> Name Cnt Base
ate 9208,656 ± 1234,399 0,007 ± 0,000 MB/sec
> 0,00x (p = 0,000*)
> :gc.alloc.rate.norm 40,000 ±0,000 0,000 ± 0,000 B/op
> 0,00x (p = 0,000*)
> :gc.count96,000 0,000 counts
> :gc.time
On Tue, 20 Feb 2024 18:30:25 GMT, Aleksey Shipilev wrote:
>> It's needed again now that I reverted the code removals.. :-)
>
> Mhm. I don't see any new `@Setup` methods anywhere. Just checked out the PR
> locally, removed this import and benchmarks still build, and
> `StringBuilderToString`
On Tue, 20 Feb 2024 18:08:11 GMT, Aleksey Shipilev wrote:
>> I couldn't figure out why we'd want to have `String::substring` micros in a
>> test `StringBuffers` (there's also a `StringSubstring` micro), though I
>> could deal with that as an explicit cleanup RFE.
>
> Yeah, I would like to keep
On Tue, 20 Feb 2024 17:02:40 GMT, Aleksey Shipilev wrote:
>> Claes Redestad has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Revert StringBuffers removals
>> - Update from review comments by @shipilev
&
ate 9208,656 ± 1234,399 0,007 ± 0,000 MB/sec
> 0,00x (p = 0,000*)
> :gc.alloc.rate.norm 40,000 ±0,000 0,000 ± 0,000 B/op
> 0,00x (p = 0,000*)
> :gc.count96,000 0,000 counts
> :gc.time
On Tue, 20 Feb 2024 17:00:14 GMT, Aleksey Shipilev wrote:
>> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
>> StringBuilder/StringBuffer::toString returns `""` when the builders are
>> empty.
>>
>>
>> Name Cnt Base Error Test
JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
Name Cnt Base Error Test Error Unit
Change
StringBuffers.emptyToString5 12,289 ±0,384
> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via
> Data- and ObjectInputStream
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with two additional
commits since the last revision:
- Update test/micro/org/openjdk/b
On Thu, 15 Feb 2024 13:07:20 GMT, Claes Redestad wrote:
>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via
>> Data- and ObjectInputStream
>>
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one addit
> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via
> Data- and ObjectInputStream
>
> Testing: tier1-3
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Update src/java.base/share/cla
On Wed, 14 Feb 2024 20:04:42 GMT, Brian Burkhalter wrote:
> As there are no regression tests added by this request, I assume that
> existing tests must sufficiently cover this area. If so, however, the issue
> has no `noreg-` label.
At least for `ObjectInputStream` there's a large and
On Thu, 15 Feb 2024 10:33:07 GMT, Claes Redestad wrote:
>> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via
>> Data- and ObjectInputStream
>>
>> Testing: tier1-3
>
> Claes Redestad has updated the pull request incrementally with one addit
201 - 300 of 742 matches
Mail list logo
