On Sun, 20 Oct 2024 00:19:25 GMT, Shaojin Wen 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 ne
> Can I please get a review of this change, which simplifies the interaction
> between the `java` launcher's native code with the
> `sun.launcher.LauncherHelper`?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change
> reduces the back and forth between the launcher
On Fri, 8 Nov 2024 08:51:38 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.org/browse/JDK-8211033?
>
> As noted in that issue, this is a clean up of the code which determines the
> "mode" through with the `java` application is being l
On Fri, 8 Nov 2024 08:51:38 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.org/browse/JDK-8211033?
>
> As noted in that issue, this is a clean up of the code which determines the
> "mode" through with the `java` application is being l
On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen 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 t
On Tue, 5 Nov 2024 15:29:39 GMT, Shaojin Wen wrote:
> Reuse the optimized putCharsAt method of StringLatin1 and StringUTF16 in PR
> #19626 to simplify the code, eliminate boundary checks, and improve
> performance
This pull request has now been integrated.
Changeset: 74ae3c68
Author:Shaoj
On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen 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 t
On Tue, 5 Nov 2024 15:29:39 GMT, Shaojin Wen wrote:
> Reuse the optimized putCharsAt method of StringLatin1 and StringUTF16 in PR
> #19626 to simplify the code, eliminate boundary checks, and improve
> performance
Looks good. Tier 1-3 tests pass.
-
Marked as reviewed by liach (R
> This addresses tendencies in previous update to increase fencing, scanning,
> and signalling that can increase contention, and slow down performance
> especially on ARM platforms. It also uses more ARM-friendly constructions to
> reduce overhead (leading to several changes that all of the same
On Sun, 10 Nov 2024 14:48:26 GMT, jyxzwd wrote:
>> I got it.Thank you for the detailed explanation!Maybe we should consider
>> another way to load the custom FileSystemProvider.
>
> If we load the custom DefaultFileSystemProvider by SystemClassLoader,then we
> will step into the method
> Syste
> The Type and AnnotatedType hierarchies have been enigmatic to new users:
> users have no clue how to categorize arbitrary type objects, when it is safe
> to cast to more specific types, and the exact conditions for method contracts.
>
> A manifest is [JDK-8306039](https://bugs.openjdk.org/brow
On Sun, 10 Nov 2024 04:50:36 GMT, jyxzwd wrote:
>> The jrt file system provider supports both the current JDK and a
>> remote/target JDK. When the JDK is not the current JDK then it loads the jrt
>> file system provider from target's JDK jrt-fs.jar. To understand this more,
>> try this example
> 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 d
> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ
> instruction for following IR pallets.
>
>
>MulVL ( AndV SRC1, 0x) ( AndV SRC2, 0x)
>MulVL (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>MulVL (URShiftVL SRC1 , 32) ( A
On Fri, 8 Nov 2024 20:25:23 GMT, Vladimir Ivanov wrote:
> In the latest version you added new Ideal nodes (`MulIVL` and `MulUIVL`). I
> don't see a compelling reason to do so. IMO matcher functionality is more
> than enough to cover `VPMULDQ` case. `MulIVL` is equivalent to `MulVL` +
> `has_in
15 matches
Mail list logo
