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 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:
> 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: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: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.
src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java line 336:
> 334: private final String name;
>
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 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
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:
>>
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 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 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
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: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 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 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
> 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:
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
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 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 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:
> 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 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 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 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
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 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:
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
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 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 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:
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 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
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 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 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, 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
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
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`
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 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: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
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:
> 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
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
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 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 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 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".
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 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
> 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 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
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 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
66 matches
Mail list logo
