> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
> offset overflow issue has been fixed.
>
> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
> reduce duplication.
>
> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF
It definitely helps.
I guess my next question is, there is no bridge method, which is why this
fails. Why not add a bridge method? What is stopping Java from doing this?
And to be clear, it is obvious to me that SewuencedSet.of is the right
answer. I am just trying to understand the point you rai
On Fri, 17 Jan 2025 23:33:50 GMT, Justin Lu wrote:
>> Please review this PR and CSR which adds a method to _java.util.Currency_
>> which returns a stream of the available Currencies.
>>
>> The motivation can be found in the CSR.
>
> Justin Lu has updated the pull request incrementally with one
> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
> offset overflow issue has been fixed.
>
> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
> reduce duplication.
>
> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF
On Fri, 17 Jan 2025 23:33:50 GMT, Justin Lu wrote:
>> Please review this PR and CSR which adds a method to _java.util.Currency_
>> which returns a stream of the available Currencies.
>>
>> The motivation can be found in the CSR.
>
> Justin Lu has updated the pull request incrementally with one
> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
> offset overflow issue has been fixed.
>
> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
> reduce duplication.
>
> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF
On 1/17/2025 5:00 PM, David Alayachew wrote:
Thanks for the corrections folks. I was thinking from the perspective
of LSP. I now see that there is the performance perspective to
consider too.
Now that said, I don't understand your comment Joe Darcy. Could you
explain it in more detail?
S
> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
> offset overflow issue has been fixed.
>
> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
> reduce duplication.
>
> 2) HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF
On Fri, 17 Jan 2025 15:29:32 GMT, Raffaello Giulietti
wrote:
>> fixed it
>
> Sorry, I was just reading the comment and not how DIGITS is initialized and
> used.
>
> The _correct_ comment should be something like
>
> * 97 -> '9' | ('7' << 8) -> 0x3739
>
> so the `short` value was co
Thanks for the corrections folks. I was thinking from the perspective of
LSP. I now see that there is the performance perspective to consider too.
Now that said, I don't understand your comment Joe Darcy. Could you explain
it in more detail?
My initial pick up of your comment is that, the paramet
On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote:
>> Some VM flags might depend on the environment and it makes sense to log
>> final flags so it is possible to get their value when investigating failures.
>>
>> I added them to VMProps, so it is always dump final flags before running
>> t
On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote:
> Please review this PR which contains the l10n translations for between RDP1
> and RDP2 for the JDK24 stabilization branch.
>
> Note that these translations are only associated with changes made to the
> stabilization branch. This PR will not
> Please review this PR and CSR which adds a method to _java.util.Currency_
> which returns a stream of the available Currencies.
>
> The motivation can be found in the CSR.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
provide messa
On Fri, 17 Jan 2025 23:10:54 GMT, Justin Lu wrote:
>> Please review this PR and CSR which adds a method to _java.util.Currency_
>> which returns a stream of the available Currencies.
>>
>> The motivation can be found in the CSR.
>
> Justin Lu has updated the pull request incrementally with one
On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote:
> Please review this PR which contains the l10n translations for between RDP1
> and RDP2 for the JDK24 stabilization branch.
>
> Note that these translations are only associated with changes made to the
> stabilization branch. This PR will not
On Fri, 17 Jan 2025 23:18:43 GMT, Justin Lu wrote:
> Should the copyright years be 2025, unless they were _published_ in 2024?
I saw the same but forgot to mention it after looking up the original files to
compare to German. I'm also not sure if this should be 2024 vs 2025. I'd assume
2024 sin
The synchronized scope was reduced from whole methods to sections that need
hash map access control. The tier1 and jaxp tests are OK. The score of the
specjvm2008:xml.transform improved a little bit. On the Xeon 8480+ reported
scores are:
original: 1vCPU - 148.4, 112vCPU - 12743.4, 224vCPU - 134
On Fri, 17 Jan 2025 18:50:22 GMT, Leonid Mesnik wrote:
>> Some VM flags might depend on the environment and it makes sense to log
>> final flags so it is possible to get their value when investigating failures.
>>
>> I added them to VMProps, so it is always dump final flags before running
>> t
On Fri, 17 Jan 2025 22:49:07 GMT, Roger Riggs wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> init hashset w/ accurate size via HashSet.newHashSet(int)
>
> src/java.base/share/classes/java/util/Currency.java line 439:
> Please review this PR and CSR which adds a method to _java.util.Currency_
> which returns a stream of the available Currencies.
>
> The motivation can be found in the CSR.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
reflect Roger
On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote:
> Please review this PR which contains the l10n translations for between RDP1
> and RDP2 for the JDK24 stabilization branch.
>
> Note that these translations are only associated with changes made to the
> stabilization branch. This PR will not
On Fri, 17 Jan 2025 22:39:14 GMT, Justin Lu wrote:
>> Please review this PR and CSR which adds a method to _java.util.Currency_
>> which returns a stream of the available Currencies.
>>
>> The motivation can be found in the CSR.
>
> Justin Lu has updated the pull request incrementally with one
On Fri, 17 Jan 2025 22:42:05 GMT, Justin Lu wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line
>> 60:
>>
>>> 58: main.opt.target-platform.arg=target-platform
>>> 59: main.opt.module-path=Modulpfad
>>> 60: main.opt.hash-modules=Berechnet und erfasst Hashes zur
On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote:
> Please review this PR which contains the l10n translations for between RDP1
> and RDP2 for the JDK24 stabilization branch.
>
> Note that these translations are only associated with changes made to the
> stabilization branch. This PR will not
On Fri, 17 Jan 2025 22:37:35 GMT, Damon Nguyen wrote:
>> Please review this PR which contains the l10n translations for between RDP1
>> and RDP2 for the JDK24 stabilization branch.
>>
>> Note that these translations are only associated with changes made to the
>> stabilization branch. This PR
On Fri, 17 Jan 2025 22:29:15 GMT, Justin Lu wrote:
> Please review this PR which contains the l10n translations for between RDP1
> and RDP2 for the JDK24 stabilization branch.
>
> Note that these translations are only associated with changes made to the
> stabilization branch. This PR will not
On Fri, 17 Jan 2025 22:11:51 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> synchronize init method over block
>
> src/java.base/share/classes/java/util/Currency.java line 467:
>
>> 465: private
> Please review this PR and CSR which adds a method to _java.util.Currency_
> which returns a stream of the available Currencies.
>
> The motivation can be found in the CSR.
Justin Lu has updated the pull request incrementally with one additional commit
since the last revision:
init hashset
Please review this PR which contains the l10n translations for between RDP1 and
RDP2 for the JDK24 stabilization branch.
Note that these translations are only associated with changes made to the
stabilization branch. This PR will not include any translations for changes
since RDP1, that were no
On Thu, 16 Jan 2025 22:39:52 GMT, Justin Lu wrote:
>> Please review this PR and CSR which adds a method to _java.util.Currency_
>> which returns a stream of the available Currencies.
>>
>> The motivation can be found in the CSR.
>
> Justin Lu has updated the pull request incrementally with one
On Thu, 19 Dec 2024 00:36:44 GMT, Brian Burkhalter wrote:
> Update the specification of `java.io.File.exists()` to match its behavior,
> which seems correct in the context of how the empty abstract pathname is
> documented elsewhere in the class.
continue;
-
PR Comment: https://g
On Fri, 17 Jan 2025 20:12:43 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8347740: Remove Windows version check and ignore IOException thrown by
>> File.createTempFile
>
> test/jdk/java
> Fix the means of determining whether an exception is to be expected in the
> Windows test.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8347740: Remove vestigial constant WINDOWS_11_MINIMUM_BUILD
-
Changes:
-
On Fri, 17 Jan 2025 20:00:16 GMT, Brian Burkhalter wrote:
>> Fix the means of determining whether an exception is to be expected in the
>> Windows test.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8347740: Remove W
On Fri, 17 Jan 2025 18:19:56 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which adds the `final` modifier to non-subclassable
>> classes in `java.base`.
>>
>> The classes were identified using an automated analysis. See CSR for details.
>>
>> Besides simply adding the `final` access mod
On Fri, 17 Jan 2025 18:15:17 GMT, Brian Burkhalter wrote:
>> we don't care if there's an exception or not. It's not part of the spec.
>
> Yes, I think I'll rework this. Thanks.
The build number could be obtained from the value of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
N
> Fix the means of determining whether an exception is to be expected in the
> Windows test.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8347740: Remove Windows version check and ignore IOException thrown by
File.createTempF
On Fri, 17 Jan 2025 17:27:32 GMT, Roger Riggs wrote:
> This seems like overkill for a weak use case.
>
> The resulting log file is in the scratch directory so it will not be retained
> for long. In local builds, whoever is running the test could add the
> arguments.
Thanks for your feedback.
On Tue, 22 Oct 2024 19:29:43 GMT, Eirik Bjørsnøs wrote:
>> FWIW: I don't believe a change to a link in a comment in an internal class
>> requires a CSR.
>> For PortConfig.java - it would be good to have someone involved in the AIX
>> port comment on the proposed changes.
>> Removing the obsole
> Please review this cleanup PR which updates a total of 12 links to external
> documentation or references in `java.base` to use https instead of plain text
> http.
>
> Links in `java.security` and `share/data/tzdata` are excluded from this PR.
>
> This is a documentaton-only cleanup. No tests
> Some VM flags might depend on the environment and it makes sense to log final
> flags so it is possible to get their value when investigating failures.
>
> I added them to VMProps, so it is always dump final flags before running
> tests using "-XX:+PrintFlagsFinal".
>
> Update:
> There were i
> Please review this PR which adds the `final` modifier to non-subclassable
> classes in `java.base`.
>
> The classes were identified using an automated analysis. See CSR for details.
>
> Besides simply adding the `final` access modifier, the PR:
>
> * Updates a note in `java.lang.constant.Dyna
On Fri, 17 Jan 2025 18:12:00 GMT, Daniel Jeliński wrote:
>>> I think it should accept both outcomes (success and the specific exception)
>>
>> But whether there's an exception varies by Windows version / build number.
>> I'll take another look and see whether there is some other way.
>
> we don
On Fri, 17 Jan 2025 17:09:51 GMT, Brian Burkhalter wrote:
>> No, it wouldn't cover any future Windows versions, but it would definitely
>> buy us a few years.
>>
>> Regarding a more permanent solution: the test is supposed to verify the fix
>> for [JDK-8013827](https://bugs.openjdk.org/browse/
On Fri, 17 Jan 2025 00:45:54 GMT, Naoto Sato wrote:
>> This fix is a follow on for
>> [JDK-8342550](https://bugs.openjdk.org/browse/JDK-8342550). Replaces/Removes
>> usages of those deprecated time zone ids in tests.
>
> Naoto Sato has updated the pull request incrementally with one additional
> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in
> order to help improve vectorization performance.
>
> Currently vectorization does not kick in for loops containing either of these
> calls because of the following error:
>
>
> VLoop::check_preconditions: failed:
On Tue, 14 Jan 2025 08:54:34 GMT, Emanuel Peter wrote:
>> @eme64 I've fixed the test issue, it's ready to be reviewed
>
> @galderz I ran some testing on our side, feel free to ping me in 1-2 days for
> the results.
@eme64 I've addressed all the comments. I've not run the `VectorReduction2` for
> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in
> order to help improve vectorization performance.
>
> Currently vectorization does not kick in for loops containing either of these
> calls because of the following error:
>
>
> VLoop::check_preconditions: failed:
On 1/16/2025 11:26 PM, Rafael Winterhalter wrote:
Would it even be possible to change the return types of Set.of(...)
and Map.of(...) without breaking binary compatibility?
In short, no.
The methods in question are *static* methods. Switching to covariant
overrides with more precise return t
On Fri, 17 Jan 2025 15:59:50 GMT, Leonid Mesnik wrote:
>> Some VM flags might depend on the environment and it makes sense to log
>> final flags so it is possible to get their value when investigating failures.
>>
>> I added them to VMProps, so it is always dump final flags before running
>> t
Hi Viktor.
I guess for 1-4 I'm just looking for a quick eyeball to check if my
takeaways are valid, nothing too committal.
I'm a little more interested in 5, because I'm currently building a
document that is attempting to capture how the stream internals fit
together, including visualizing stream
On Fri, 17 Jan 2025 17:05:56 GMT, Daniel Jeliński wrote:
> I think it should accept both outcomes (success and the specific exception)
But whether there's an exception varies by Windows version / build number. I'll
take another look and see whether there is some other way.
-
PR Re
On Fri, 17 Jan 2025 16:46:58 GMT, Brian Burkhalter wrote:
>> test/jdk/java/io/File/createTempFile/SpecialTempFile.java line 95:
>>
>>> 93:
>>> 94: String cmd = "Systeminfo";
>>> 95: Process p = Runtime.getRuntime().exec(new String[] {cmd});
>>
>> I'm not a big fan of running th
On Fri, 17 Jan 2025 15:59:50 GMT, Leonid Mesnik wrote:
>> Some VM flags might depend on the environment and it makes sense to log
>> final flags so it is possible to get their value when investigating failures.
>>
>> I added them to VMProps, so it is always dump final flags before running
>> t
On Fri, 17 Jan 2025 11:04:09 GMT, Daniel Jeliński wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8347740: Change Windows exceptionExpected to be based on build number
>
> test/jdk/java/io/File/createTempFile/S
On Fri, 17 Jan 2025 15:46:25 GMT, Raffaello Giulietti
wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix comment, from @rgiulietti
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 434:
>
On Wed, 15 Jan 2025 00:28:50 GMT, Paul Sandoz wrote:
>> Hi @PaulSandoz ,
>>
>> In above code snippet the return type 'short' of intrinsic call does not
>> comply with the value being returned which is of box type, thereby mandating
>> addition glue code.
>>
>> Regular primitive type boxing
> Hi All,
>
> This patch adds C2 compiler support for various Float16 operations added by
> [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>
> Following is the summary of changes included with this patch:-
>
> 1. Detection of various Float16 operations through inline expansion or
> patt
> Some VM flags might depend on the environment and it makes sense to log final
> flags so it is possible to get their value when investigating failures.
>
> I added them to VMProps, so it is always dump final flags before running
> tests using "-XX:+PrintFlagsFinal".
>
> Update:
> There were i
On Fri, 17 Jan 2025 00:09:11 GMT, Shaojin Wen wrote:
>> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
>> offset overflow issue has been fixed.
>>
>> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication.
>>
>> 2) HexDigi
On Fri, 17 Jan 2025 00:09:11 GMT, Shaojin Wen wrote:
>> This PR is a resubmission after PR #21593 was rolled back, and the unsafe
>> offset overflow issue has been fixed.
>>
>> 1) Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to
>> reduce duplication.
>>
>> 2) HexDigi
On Tue, 14 Jan 2025 05:07:55 GMT, Galder Zamarreño wrote:
>> @galderz So you want me to review again?
>
> @eme64 I've fixed the test issue, it's ready to be reviewed
> @galderz I don't remember from above, but did you ever run the Long Min/Max
> benchmarks from this?
https://github.com/openjdk/
On Fri, 17 Jan 2025 00:05:25 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 42:
>>
>>> 40:
>>> 41: /**
>>> 42: * Each element of the array represents the packaging of two ascii
>>> characters based on little endian:
>>
>> The table be
On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik wrote:
> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new
> possible issues.
>
> The main goal is to avoid new such issues in the testlibrary.
> Tested with tie
On Fri, Jan 17, 2025 at 9:22 AM Ethan McCue wrote:
> Just so there are some strawman arguments against:
>
To pile on...
If I go to a restaurant and order a hamburger and they bring me a
cheeseburger and also charge me extra for it, I'm going to complain!
A Set and a SequencedSet are two differ
On Tue, 14 Jan 2025 08:33:36 GMT, Emanuel Peter wrote:
>> Galder Zamarreño has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Make sure it runs with cpus with either avx512 or asimd
>
> test/hotspot/jtreg/compiler/loopopts/superword/MinMaxR
Just so there are some strawman arguments against:
* Does altering Set.of to maintain order increase its memory footprint? If
the answer is yes, does that matter? If the answer is no, is there a new
standalone collection type to add?
SetThatIsOrderedInTheSameMannerAsPythonsSetIsOrderedAndThusHasNo
On Tue, 26 Nov 2024 13:04:41 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which adds the `final` modifier to non-subclassable
> classes in `java.base`.
>
> The classes were identified using an automated analysis. See CSR for details.
>
> Besides simply adding the `final` access modifier,
Sure, changing the return type to a more specialized type is never a
problem. And even if it was, the explicit documentation on those factory
methods was that the actual implementation is subject to change, and should
not be depended on.
Also, your argument about iteration order doesn't make sense
On Tue, 26 Nov 2024 13:04:41 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which adds the `final` modifier to non-subclassable
> classes in `java.base`.
>
> The classes were identified using an automated analysis. See CSR for details.
>
> Besides simply adding the `final` access modifier,
On Wed, 15 Jan 2025 21:26:49 GMT, Brian Burkhalter wrote:
>> Fix the means of determining whether an exception is to be expected in the
>> Windows test.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8347740: Change W
Hi Daniel,
Thanks for your patience.
What kind of feedback/responses are you looking for primarily?
Have you attempted to make changes and run any of the openjdk stream benches
(after running the tests)?
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
__
72 matches
Mail list logo
