On Mon, 14 Apr 2025 14:40:02 GMT, Roger Riggs wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> from @valeriepeng
>
> Looks ok; but will need to be re-opened. It would seem odd to app
On Tue, 20 May 2025 16:10:07 GMT, Per Minborg wrote:
>> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
>> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
>> instances can be used in classes that were not covered by
>> https://github.com/openjdk
On Tue, 20 May 2025 16:10:07 GMT, Per Minborg wrote:
>> This PR proposes to use `JavaNioAccess::getBufferAdress` rather than
>> `DirectBuffer::address` so that `Buffer` instances backed by MemorySegment
>> instances can be used in classes that were not covered by
>> https://github.com/openjdk
ecurity.util.KnownOIDs$7
> [0.669s][info][class,load] sun.security.util.KnownOIDs$8
> [0.669s][info][class,load] sun.security.util.KnownOIDs$9
> [0.669s][info][class,load] sun.security.util.KnownOIDs$10
Shaojin Wen has updated the pull request incrementally with one additional
On Fri, 7 Feb 2025 01:46:03 GMT, Valerie Peng wrote:
> > The reproducer you provided doesn't try to load KnownOIDs on my machine.
> > What am I missing?
> > Other than that, the change looks reasonable to me.
>
> Me neither and I'm using linux. Are you sure the Startup.java is right? Just
> cu
On Thu, 6 Feb 2025 23:45:57 GMT, Johannes Graham wrote:
>> you are right, but accessing static field from enum constructor is not
>> allowed
>
> You could define the static field on another class, like SecurityConstants,
> and then use it in the enum constructor.
Creating a new empty string ar
On Wed, 5 Feb 2025 12:26:17 GMT, Daniel Jeliński wrote:
> The reproducer you provided doesn't try to load KnownOIDs on my machine. What
> am I missing?
>
> Other than that, the change looks reasonable to me.
Sorry, maybe I am wrong. My test above is using
build/macosx-aarch64-server-release/j
On Wed, 5 Feb 2025 15:21:59 GMT, Roger Riggs wrote:
>> During JVM startup, the class KnownOIDs is loaded. KnownOIDs has 10
>> anonymous classes, which slows down the startup. This PR is to improve
>> KnownOIDs and eliminate unnecessary embedded classes.
>>
>>
>> Here's how to reproduce this:
During JVM startup, the class KnownOIDs is loaded. KnownOIDs has 10 anonymous
classes, which slows down the startup. This PR is to improve KnownOIDs and
eliminate unnecessary embedded classes.
Here's how to reproduce this:
public class Startup {
public static void main(String[] args) {}
}
This PR is a resubmission after PR #21593 was rolled back, and the unsafe
offset overflow issue has been fixed.
Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
reduce duplication
HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
Putting these two
On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen wrote:
> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash,
>
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more
> testing is needed, so let's roll it back first.
This pul
On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen wrote:
> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash,
>
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more
> testing is needed, so let's roll it back first.
It has be
8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash,
so submit this PR to roll back
-
Commit messages:
- Revert "8342650: Move getChars to DecimalDigits"
Changes: https://git.openjdk.org/jdk/pull/22012/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&p
On Sun, 20 Oct 2024 17:33:09 GMT, j3graham wrote:
>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication
>>
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid the
Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
reduce duplication
1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
2. Putting these two methods into DecimalDigits can avoid the need to expose
them in JavaLangAccess
3. Eliminate duplicate code
Optimize ClassDesc related string concatenation, which will reduce object
allocation during startup.
-
Commit messages:
- Optimize the string concatenation related to ClassDesc during startup
Changes: https://git.openjdk.org/jdk/pull/20705/files
Webrev: https://webrevs.openjdk.or
#print
> method.
>
> ## 3. String.format directly calls j.u.Formatter
> String.format directly calls j.u.Formatter via SharedSecrets to improve
> performance
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now con
The current implementation of StringConcat is to mix the coder and length into
a long. This operation will have some overhead for int/long/boolean types. We
can separate the calculation of the coder from the calculation of the length,
which can improve the performance in the scenario of concat i
On Sat, 6 Jul 2024 00:15:04 GMT, Shaojin Wen wrote:
>> String.format is widely used, and improving its performance is very
>> meaningful. This PR can significantly improve the performance of
>> String.format. Sorry, there are many changes, which will take a lot of time.
On Sat, 6 Jul 2024 00:15:04 GMT, Shaojin Wen wrote:
>> String.format is widely used, and improving its performance is very
>> meaningful. This PR can significantly improve the performance of
>> String.format. Sorry, there are many changes, which will take a lot of time.
#print
> method.
>
> ## 3. String.format directly calls j.u.Formatter
> String.format directly calls j.u.Formatter via SharedSecrets to improve
> performance
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
Implementi
On Fri, 5 Jul 2024 20:43:51 GMT, Shaojin Wen wrote:
>> String.format is widely used, and improving its performance is very
>> meaningful. This PR can significantly improve the performance of
>> String.format. Sorry, there are many changes, which will take a lot of time.
#print
> method.
>
> ## 3. String.format directly calls j.u.Formatter
> String.format directly calls j.u.Formatter via SharedSecrets to improve
> performance
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excl
On Fri, 5 Jul 2024 18:56:58 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - use unknownFormatConversion method construct
>> UnknownFormatConversionException
>
#print
> method.
>
> ## 3. String.format directly calls j.u.Formatter
> String.format directly calls j.u.Formatter via SharedSecrets to improve
> performance
Shaojin Wen has updated the pull request incrementally with four additional
commits since the last revision:
- use unkno
On Fri, 5 Jul 2024 15:40:24 GMT, Shaojin Wen wrote:
> String.format is widely used, and improving its performance is very
> meaningful. This PR can significantly improve the performance of
> String.format. Sorry, there are many changes, which will take a lot of time.
> I hope yo
String.format is widely used, and improving its performance is very meaningful.
This PR can significantly improve the performance of String.format. Sorry,
there are many changes, which will take a lot of time. I hope you can review it
patiently.
Improved performance includes the following:
##
On Mon, 16 Oct 2023 22:27:34 GMT, Shaojin Wen wrote:
> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
> use try...catch to handle CharacterCodingException and throw
> IllegalArgumentException instead of CharacterCodingException to make the
> calling
On Tue, 17 Oct 2023 14:09:08 GMT, Raffaello Giulietti
wrote:
> @wenshao The proposal changes the exception types for seemingly no reason.
> What concrete problem does this enhancement PR address?
@lianch 's suggestion in PR #14812 :
"Make the NoRepl methods throw IllegalArgument (like NoRepl1
> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
> use try...catch to handle CharacterCodingException and throw
> IllegalArgumentException instead of CharacterCodingException to make the
> calling code cleaner.
Shaojin Wen has updated the pull request i
> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
> use try...catch to handle CharacterCodingException and throw
> IllegalArgumentException instead of CharacterCodingException to make the
> calling code cleaner.
Shaojin Wen has updated the pull request i
> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
> use try...catch to handle CharacterCodingException and throw
> IllegalArgumentException instead of CharacterCodingException to make the
> calling code cleaner.
Shaojin Wen has updated the pull request i
> When calling String::newStringNoRepl and String::getBytesNoRepl, we need to
> use try...catch to handle CharacterCodingException and throw
> IllegalArgumentException instead of CharacterCodingException to make the
> calling code cleaner.
Shaojin Wen has updated the pull request i
When calling String::newStringNoRepl and String::getBytesNoRepl, we need to use
try...catch to handle CharacterCodingException and throw
IllegalArgumentException instead of CharacterCodingException to make the
calling code cleaner.
-
Commit messages:
- Make the NoRepl methods thro
34 matches
Mail list logo
