On 03/11/21 8:50 am, Jaikiran Pai wrote:
Hello Alan,
On 02/11/21 5:30 pm, Alan Bateman wrote:
On 02/11/2021 06:38, Jaikiran Pai wrote:
:
Perhaps run 1 writing the hash code of each of the boot modules'
descriptor into a file and then run 2 reading that same file to
compare the hash codes
Hello Alan,
On 02/11/21 5:30 pm, Alan Bateman wrote:
On 02/11/2021 06:38, Jaikiran Pai wrote:
:
Perhaps run 1 writing the hash code of each of the boot modules'
descriptor into a file and then run 2 reading that same file to
compare the hash codes would be one way to do it. But I think that
On Wed, 27 Oct 2021 21:42:29 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 sam
> 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 final hash code. While doing so it ends up calling
> hashC
On Wed, 3 Nov 2021 01:10:46 GMT, Joe Wang wrote:
>> Add setProperty/getProperty methods to the XPath API so that properties can
>> be supported in the future.
>
> Joe Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add default impl; A
> Add setProperty/getProperty methods to the XPath API so that properties can
> be supported in the future.
Joe Wang has updated the pull request incrementally with one additional commit
since the last revision:
Add default impl; Add tests.
-
Changes:
- all: https://git.openjd
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull request
On Tue, 2 Nov 2021 19:14:23 GMT, Pavel Rappo wrote:
>> Pragmatically, fix the script to ignore those keywords on comment lines.
>> Learn Perl, its just a regular expression pattern match and replace
>> expression.
>>
>> All of the changes have to be manually reviewed by the author and then th
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
This change optimizes random number generators using Math.unsignedMultiplyHigh()
-
Commit messages:
- Update Math.java
- 8275821: Optimize random number generators developed in JDK-8248862 using
Math.unsignedMultiplyHigh()
Changes: https://git.openjdk.java.net/jdk/pull/6206/files
On Fri, 24 Sep 2021 11:28:09 GMT, Masanori Yano wrote:
> Could you please review the 8250678 bug fixes?
>
> The `parse` method of ModuleDescriptor.Version class behaves incorrectly when
> the input string contains consecutive delimiters.
>
> The `parse` method treats strings as three sections,
On Tue, 2 Nov 2021 19:22:15 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/lang/invoke/CallSite.java line 88:
>>
>>> 86: */
>>> 87: public
>>> 88: abstract class CallSite {
>>
>> I think it's better to move all modifiers to the single line.
>
> This is a survivorship bias. This ex
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Tue, 2 Nov 2021 19:02:51 GMT, Maurizio Cimadamore
wrote:
>> What is missing, I think, is a check (size > arenaSize) at the beginning of
>> the method (we only check this in one of the paths). But we need to check
>> before and after, I think, as it is possible to allocate a segment and then
On Tue, 2 Nov 2021 18:55:47 GMT, Maurizio Cimadamore
wrote:
>> I'll have to think some more about this. I don't think this is covered
>> inside the block - that is, the block tries to allocate, and then in the
>> finally we throw if we realized we've allocated too much.
>
> What is missing, I
On Tue, 2 Nov 2021 18:48:57 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java
>> line 88:
>>
>>> 86: if (size > arenaSize) {
>>> 87: throw new OutOfMemoryError();
>>> 88:
On Tue, 2 Nov 2021 19:35:29 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjdk
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull request
On Tue, 2 Nov 2021 16:51:06 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Tweak javadoc of loaderLookup
>
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ArenaAllocator.java
On Tue, 2 Nov 2021 19:15:26 GMT, Andrey Turbanov wrote:
>> This PR follows up one of the recent PRs, where I used a non-canonical
>> modifier order. Since the problem was noticed [^1], why not to address it at
>> mass?
>>
>> As far as I remember, the first mass-canonicalization of modifiers to
This fixes Properties.loadFromXML/storeToXML so that it works correctly for
supplementary characters.
-
Commit messages:
- 8276207: Properties.loadFromXML/storeToXML works incorrectly for
supplementary characters
Changes: https://git.openjdk.java.net/jdk/pull/6216/files
Webrev: h
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Tue, 2 Nov 2021 18:48:20 GMT, Roger Riggs wrote:
> Pragmatically, fix the script to ignore those keywords on comment lines.
> Learn Perl, its just a regular expression pattern match and replace
> expression.
I understand in principle how to modify that script to ignore doc comments. The
th
Hi Joe,
Thanks. I have created a pull request[1].
The new entry in "testLoadAndStore" will do the roundtrip as you have
described.
So "testStoreWithSupplementaryCharacters" is redundant.
I have removed this method before creating the pull request.
[1] : https://github.com/openjdk/jdk/pull/6216
On Tue, 2 Nov 2021 18:17:36 GMT, Pavel Rappo wrote:
>> It's tough when a natural language clashes with a programming language. I
>> appreciate that this particular clash might cause discomfort to native
>> English speakers. (This reminds me of that _DOSASCOMP_ mnemonic for
>> adjective order.)
On Tue, 2 Nov 2021 18:48:06 GMT, Mark Sheppard wrote:
>> Here's a bit of archaeology. I found the original JDK-8136583 patch, which
>> has moved from where it was in the RFR to
>> https://cr.openjdk.java.net/~martin/webrevs/jdk9/blessed-modifier-order/.
>> That patch doesn't change Object.java
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Tue, 2 Nov 2021 17:45:07 GMT, Pavel Rappo wrote:
>>> In comments, I think the 'synchronized static 'reads better, the
>>> conventional order is for the code.
>>
>> I think Roger is right and maybe the change to the javadoc could be dropped
>> from this patch.
>
> It's tough when a natural l
On Tue, 2 Nov 2021 17:31:40 GMT, Joe Wang wrote:
> Add setProperty/getProperty methods to the XPath API so that properties can
> be supported in the future.
Are you planning to add tests? Also don't forget @since.
-
PR: https://git.openjdk.java.net/jdk/pull/6215
On Tue, 2 Nov 2021 17:39:17 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/lang/Object.java line 282:
>>
>>> 280: * For objects of type {@code Class,} by executing a
>>> 281: * static synchronized method of that class.
>>> 282: *
>>
>> In comments, I think the
On Tue, 2 Nov 2021 17:13:47 GMT, Roger Riggs wrote:
> In comments, I think the 'synchronized static 'reads better, the conventional
> order is for the code.
I think Roger is right and maybe the change to the javadoc could be dropped
from this patch.
-
PR: https://git.openjdk.java
Add setProperty/getProperty methods to the XPath API so that properties can be
supported in the future.
-
Commit messages:
- 8276141: XPathFactory set/getProperty method
Changes: https://git.openjdk.java.net/jdk/pull/6215/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr
On Mon, 1 Nov 2021 15:38:18 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 17 commits:
>>
>> - Add cache for memory address var handles
>> - Merge branch 'master' into JEP-419
>>
On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjdk
On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjdk
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Tue, 2 Nov 2021 06:25:33 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
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
This PR follows up one of the recent PRs, where I used a non-canonical modifier
order. Since the problem was noticed [^1], why not to address it at mass?
As far as I remember, the first mass-canonicalization of modifiers took place
in JDK-8136583 in 2015 [^2]. That change affected 1780 lines spa
On Mon, 1 Nov 2021 18:31:17 GMT, Naoto Sato wrote:
> This is a leftover document fix to `String` class for the JEP 400.
> Corresponding CSR has also been drafted:
> https://bugs.openjdk.java.net/browse/JDK-8276238
This pull request has now been integrated.
Changeset: 495c828a
Author:Naoto
On Tue, 2 Nov 2021 10:30:42 GMT, Maurizio Cimadamore
wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line
>> 111:
>>
>>> 109: class VarHandleCache {
>>> 110: private static final Map handleMap
>>> = new ConcurrentHashMap<>();
>>> 111:
On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjdk
Indeed. I was reminded of a discussion [1][2] back in July when I saw
this JEP candidate.
Now looking at it again, I guess we can easily prevent this risk once
this JEP is implemented (so finalizers are no-op and attacks cannot
happen even if the security manager is disallowed), and we might not
n
On 02/11/2021 14:00, - wrote:
On a side note, will the actual removal of finalization become a
dependency of the actual removal of the security manager? I recall
when the security manager was deprecated for removal, developers
pointed out that there can be security risks with finalization in the
On a side note, will the actual removal of finalization become a
dependency of the actual removal of the security manager? I recall
when the security manager was deprecated for removal, developers
pointed out that there can be security risks with finalization in the
mailing list.
On Mon, Nov 1, 2
On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote:
> Please review the integration of tzdata2021e (including tzdata2021d) to the
> JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests.
>
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fai
On 02/11/2021 06:38, Jaikiran Pai wrote:
:
Perhaps run 1 writing the hash code of each of the boot modules'
descriptor into a file and then run 2 reading that same file to
compare the hash codes would be one way to do it. But I think that
would just make this test more complex, which I think
On Tue, 2 Nov 2021 09:54:38 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>> is
On Tue, 2 Nov 2021 07:31:09 GMT, Stephen Colebourne
wrote:
>> I see what you're saying that an arbitrary `Temporal` could define its own
>> fields with its own ranges, but I would consider it a design bug if such an
>> implementation at a whim redefines the value ranges of well-defined
>> con
> Prompted by a request from Volkan Yazıcı I took a look at why the java.time
> formatters are less efficient for some common patterns than custom formatters
> in apache-commons and log4j. This patch reduces the gap, without having
> looked at the third party implementations.
>
> When printing
On Thu, 28 Oct 2021 13:03:56 GMT, Severin Gehwolf wrote:
> Please review this change to remove some API which no longer works as
> expected as recent OCI runtimes start to drop support for `--kernel-memory`
> switch. See the bug for references. This part of the API is not present in
> hotspot
On Tue, 2 Nov 2021 00:24:12 GMT, Paul Sandoz wrote:
>> Maurizio Cimadamore has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 17 commits:
>>
>> - Add cache for memory address var handles
>> - Merge branch 'master' into JEP-419
>>
On Thu, 28 Oct 2021 08:58:48 GMT, Aleksey Shipilev wrote:
>> `Unsafe.storeStoreFence` currently delegates to stronger
>> `Unsafe.storeFence`. We can teach compilers to map this directly to already
>> existing rules that handle `MemBarStoreStore`. Like explicit
>> `LoadFence`/`StoreFence`, we i
On Wed, 27 Oct 2021 11:53:47 GMT, Aleksey Shipilev wrote:
> `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`.
> We can teach compilers to map this directly to already existing rules that
> handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we
> intro
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the same
On Mon, 1 Nov 2021 15:59:22 GMT, Ludvig Janiuk wrote:
> Adds table headers to all tables in Formatter api docs. I inferred the header
> "Unicode" for the columns that contained unicode
> codepoints.
>
> Formatter api docs:
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/uti
On Thu, 28 Oct 2021 01:02:27 GMT, Yoshiki Sato wrote:
> Please review the integration of tzdata2021e (including tzdata2021d) to the
> JDK.
> The fix has passed all relevant JTREG regression tests and JCK tests.
>
> 8275754: (tz) Update Timezone Data to 2021d
> 8275849: TestZoneInfo310.java fai
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the same
On Sat, 4 Sep 2021 11:59:58 GMT, q2q-2q2 wrote:
> Shortcut String equality checks by checking equality of the value array
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/5370
On Mon, 1 Nov 2021 22:35:58 GMT, Claes Redestad wrote:
>> The commentary on this line could probably be improved, but this is in a
>> private printer-parser that will only be used for NANO_OF_SECOND and not any
>> arbitrary `TemporalField` (see line 704), thus I fail to see how this
>> assumpt
63 matches
Mail list logo
