On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote:
> The lack of anything to compile in `syslookup.c` is leading to a number of
> issues in our tooling, on some architectures more than others (s390x seems to
> be the most problematic). They expect to be able to retrieve debuginfo and
On Thu, 4 Nov 2021 05:16:42 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which fixes the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8275509?
>>
>> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
>> components to compute
On Fri, 22 Oct 2021 09:33:35 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8275509?
>
> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
> components to compute the
On Thu, 4 Nov 2021 14:08:50 GMT, Alan Bateman wrote:
> One final thought on this is whether we should remove the
> tools/jlink/JLinkReproducibleXXX tests from the exclude list.
Yes, I'm working on it in a separate PR.
-
PR: https://git.openjdk.java.net/jdk/pull/6078
On Wed, 3 Nov 2021 03:10:16 GMT, Ningsheng Jian wrote:
> Converting from double to long and then narrow to target types did not follow
> JLS. I will fix it. Thanks to @fg1417 for helping to find out this issue.
Fixed in the new commit. Thanks to @PaulSandoz for integrating the fix!
Hi Nick
On Thu, 4 Nov 2021 15:56:46 GMT, Paul Sandoz wrote:
>> This PR improves the performance of vector operations that accept masks on
>> architectures that support masking in hardware, specifically Intel AVX512
>> and ARM SVE.
>>
>> On architectures that do not support masking in hardware the
On Thu, 4 Nov 2021 12:40:15 GMT, Maurizio Cimadamore
wrote:
> Looks ok. As long as we don't introduce more dependencies.
>
> One question: would introducing a static function (so, not visible in the
> resulting DLL) be good enough?
I did wonder about this too. I'll have to check it still
On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard wrote:
> This PR enables reproducible Jars, Jmods and openjdk image zip files
> (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying
> ZipOutputStream's.
> It fixes the following keys issues relating to
> This change optimizes random number generators using
> Math.unsignedMultiplyHigh()
Vamsi Parasa has updated the pull request incrementally with one additional
commit since the last revision:
fix trailing whitespace
-
Changes:
- all:
> This change optimizes random number generators using
> Math.unsignedMultiplyHigh()
Vamsi Parasa has updated the pull request incrementally with two additional
commits since the last revision:
- Fix year in copyright
- micro benchmarks to test the performance
-
Changes:
-
On Thu, 4 Nov 2021 19:28:58 GMT, Mandy Chung wrote:
> The dot graph should print the edges in alphatical order. A simple fix to
> sort the edges before printing them.
This pull request has now been integrated.
Changeset: e21b5c7b
Author:Mandy Chung
URL:
On Thu, 4 Nov 2021 21:51:46 GMT, Joe Darcy wrote:
>> This PR enables reproducible Jars, Jmods and openjdk image zip files
>> (eg.src.zip).
>> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying
>> ZipOutputStream's.
>> It fixes the following keys issues relating to
On Thu, 4 Nov 2021 21:46:21 GMT, Anthony Vanelverdinghe
wrote:
>> The dot graph should print the edges in alphatical order. A simple fix to
>> sort the edges before printing them.
>
> src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java line 336:
>
>> 334: private
On Thu, 4 Nov 2021 21:51:46 GMT, Joe Darcy wrote:
>> This PR enables reproducible Jars, Jmods and openjdk image zip files
>> (eg.src.zip).
>> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying
>> ZipOutputStream's.
>> It fixes the following keys issues relating to
On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard wrote:
> This PR enables reproducible Jars, Jmods and openjdk image zip files
> (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying
> ZipOutputStream's.
> It fixes the following keys issues relating to
On Thu, 4 Nov 2021 19:28:58 GMT, Mandy Chung wrote:
> The dot graph should print the edges in alphatical order. A simple fix to
> sort the edges before printing them.
src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java line 336:
> 334: private final String name;
>
On Thu, 4 Nov 2021 20:12:52 GMT, Jiří Vaněk wrote:
> Most likely bad idea, but isnt there an threat, that the method will be
> dropped by optimising compiler?
It is a possibility that the function will be dropped, but maybe worth a try.
-
PR:
On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard wrote:
> This PR enables reproducible Jars, Jmods and openjdk image zip files
> (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying
> ZipOutputStream's.
> It fixes the following keys issues relating to
This PR enables reproducible Jars, Jmods and openjdk image zip files
(eg.src.zip).
It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying
ZipOutputStream's.
It fixes the following keys issues relating to reproducibility:
- Jar and ZipOutputStream are not SOURCE_DATE_EPOCH aware
On Thu, 4 Nov 2021 16:52:48 GMT, Ludvig Janiuk wrote:
> The first table is missing row headers, adding them to aid screen readers.
This pull request has now been integrated.
Changeset: 8ec80c4b
Author:Ludvig Janiuk
Committer: Naoto Sato
URL:
On Thu, 4 Nov 2021 17:03:54 GMT, Mandy Chung wrote:
>> Inferring from the flow of the text, the table should have been a list all
>> along, so I've made it that way. Before and after for comparison:
>>
On Thu, 4 Nov 2021 16:41:11 GMT, Ludvig Janiuk wrote:
> Added row headers missing in the table captioned "Access mode summary". This
> carries no visual change, but might be useful for screen readers.
This pull request has now been integrated.
Changeset: 7e87f946
Author:Ludvig Janiuk
On Thu, 4 Nov 2021 19:28:58 GMT, Mandy Chung wrote:
> The dot graph should print the edges in alphatical order. A simple fix to
> sort the edges before printing them.
Marked as reviewed by iris (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6266
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote:
> The lack of anything to compile in `syslookup.c` is leading to a number of
> issues in our tooling, on some architectures more than others (s390x seems to
> be the most problematic). They expect to be able to retrieve debuginfo and
On Thu, 4 Nov 2021 16:52:48 GMT, Ludvig Janiuk wrote:
> The first table is missing row headers, adding them to aid screen readers.
LGTM.
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6262
The dot graph should print the edges in alphatical order. A simple fix to
sort the edges before printing them.
-
Commit messages:
- JDK-8276650: GenGraphs does not produce deterministic output
Changes: https://git.openjdk.java.net/jdk/pull/6266/files
Webrev:
On Thu, 4 Nov 2021 16:18:45 GMT, Ludvig Janiuk wrote:
> Inferring from the flow of the text, the table should have been a list all
> along, so I've made it that way. Before and after for comparison:
>
> I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts
> verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
> have manually checked the changes made by the script to make sure they are
> sound.
Magnus Ihse Bursie has updated the pull request
On Thu, 4 Nov 2021 16:41:11 GMT, Ludvig Janiuk wrote:
> Added row headers missing in the table captioned "Access mode summary". This
> carries no visual change, but might be useful for screen readers.
Looks okay. Thanks for improving the documentation accessibility.
-
Marked as
On Thu, 4 Nov 2021 16:18:45 GMT, Ludvig Janiuk wrote:
> Inferring from the flow of the text, the table should have been a list all
> along, so I've made it that way. Before and after for comparison:
>
On Thu, 4 Nov 2021 16:18:45 GMT, Ludvig Janiuk wrote:
> Inferring from the flow of the text, the table should have been a list all
> along, so I've made it that way. Before and after for comparison:
>
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure
The first table is missing row headers, adding them to aid screen readers.
-
Commit messages:
- Added row headers in Character docs
Changes: https://git.openjdk.java.net/jdk/pull/6262/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6262=00
Issue:
On Wed, 3 Nov 2021 18:41:19 GMT, Naoto Sato wrote:
>> Ichiroh Takiguchi has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - 8274544: Langtools command's usage were garbled on Japanese Windows
>> - 8274544:
On Thu, 4 Nov 2021 16:18:45 GMT, Ludvig Janiuk wrote:
> Inferring from the flow of the text, the table should have been a list all
> along, so I've made it that way. Before and after for comparison:
>
Added row headers missing in the table captioned "Access mode summary". This
carries no visual change, but might be useful for screen readers.
-
Commit messages:
- Added table headers
Changes: https://git.openjdk.java.net/jdk/pull/6261/files
Webrev:
On Fri, 29 Oct 2021 10:38:41 GMT, Ivan Šipka wrote:
>> cc @ctornqvi
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> removed file added by accident
I guess the proper course of actions would be not to mention any
On Thu, 4 Nov 2021 02:14:09 GMT, Igor Ignatyev wrote:
>> Ivan Šipka has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> removed file added by accident
>
> Thanks for the clarification, David. I guess my recollection of jtreg code
> isn’t
Inferring from the flow of the text, the table should have been a list all
along, so I've made it that way. Before and after for comparison:
![image](https://user-images.githubusercontent.com/6298393/140376551-6f8ac0c9-5336-4da0-8504-01af806ecae0.png)
This fix is to require to include `Locale.ROOT` in the returned arrays/set from
`getAvailableLocales()` methods in various locale-sensitive classes. The
implementation has been including `Locale.ROOT` since its inception, it is
simply a doc clarification (+ a test case verifying it).
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure
On Thu, 4 Nov 2021 13:10:37 GMT, Christian Stein wrote:
> This PR implements the fix as suggested by Adam Farley, which reads:
>
>> Note: Looks to be as simple as adding `jaccessinspector-32` and
>> `jaccesswalker-32` to `TOOLS_NOT_TO_TEST` at the top of
>> `HelpFlagsTest.java`, as the
> This PR improves the performance of vector operations that accept masks on
> architectures that support masking in hardware, specifically Intel AVX512 and
> ARM SVE.
>
> On architectures that do not support masking in hardware the same technique
> as before is applied to most operations,
On Wed, 3 Nov 2021 11:58:42 GMT, Pavel Rappo wrote:
> This PR fixes two sentences which conflate a string with its length, and also
> makes the "equivalency wording" consistent.
>
> There are many ways to fix "the resulting String may be a different length
> than the original String". The
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure
On Thu, 4 Nov 2021 05:16:42 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which fixes the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8275509?
>>
>> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
>> components to compute
On Thu, 4 Nov 2021 05:16:42 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which fixes the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8275509?
>>
>> The `ModuleDescriptor.hashCode()` method uses the hash code of its various
>> components to compute
On Thu, 4 Nov 2021 05:21:25 GMT, Jaikiran Pai wrote:
> That's a good point and thank you for explaining that part. So to address
> that, how about not leaving them out, but instead of using `Enum#ordinal()`
> for the hashCode generation, we use `Enum#name()` which would translate to a
>
On Thu, 4 Nov 2021 13:54:37 GMT, Pavel Rappo wrote:
>> This PR fixes two sentences which conflate a string with its length, and
>> also makes the "equivalency wording" consistent.
>>
>> There are many ways to fix "the resulting String may be a different length
>> than the original String".
> This PR fixes two sentences which conflate a string with its length, and also
> makes the "equivalency wording" consistent.
>
> There are many ways to fix "the resulting String may be a different length
> than the original String". The proposed way might be one of the most
> lightweight ways
This PR implements the fix as suggested by Adam Farley, which reads:
> Note: Looks to be as simple as adding `jaccessinspector-32` and
> `jaccesswalker-32` to `TOOLS_NOT_TO_TEST` at the top of `HelpFlagsTest.java`,
> as the non-32bit versions are already there.
-
Commit messages:
On Thu, 4 Nov 2021 11:48:04 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts
> verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
> have manually checked the changes made by the script to make sure they
On Thu, 4 Nov 2021 12:30:40 GMT, Aleksei Efimov wrote:
>> I can see that this PR changes java.naming. Another bug to change
>> java.naming, JDK-8276552, was filed yesterday. Please check with its
>> reporter and coordinate this effort if necessary.
>
>> I can see that this PR changes
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote:
> The lack of anything to compile in `syslookup.c` is leading to a number of
> issues in our tooling, on some architectures more than others (s390x seems to
> be the most problematic). They expect to be able to retrieve debuginfo and
On Thu, 4 Nov 2021 11:31:50 GMT, Pavel Rappo wrote:
> I can see that this PR changes java.naming. Another bug to change
> java.naming, JDK-8276552, was filed yesterday. Please check with its reporter
> and coordinate this effort if necessary.
@magicus I'm ok with having `java.naming` changes
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure
I ran bin/blessed-modifier-order.sh on source owned by compiler. This scripts
verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
have manually checked the changes made by the script to make sure they are
sound.
-
Commit messages:
- 8276635: Use blessed
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure
I ran bin/blessed-modifier-order.sh on source owned by core-libs. This scripts
verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
have manually checked the changes made by the script to make sure they are
sound.
-
Commit messages:
- 8276629: Use blessed
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote:
> The lack of anything to compile in `syslookup.c` is leading to a number of
> issues in our tooling, on some architectures more than others (s390x seems to
> be the most problematic). They expect to be able to retrieve debuginfo and
On Mon, 1 Nov 2021 11:23:16 GMT, Aleksey Shipilev wrote:
> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
> giving failing intrinsics a second chance to match against the similar `Math`
> intrinsics. This has interesting consequence for matchers: we can match the
>
On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote:
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
> `Unsafe`
On Mon, 1 Nov 2021 07:36:53 GMT, Aleksey Shipilev wrote:
>> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
>> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed
>> (useless?) to call to runtime for a single memory barrier. We can simplify
>> the native `Unsafe`
Hi There,
Hotspot developers already identified a bug in verification (failure to
capture an invalid package name "die/verwandlung/" existing in the constant
pool of bytecode) at https://bugs.openjdk.java.net/browse/JDK-8276241 as I
raised via
66 matches
Mail list logo