On Thu, 19 Nov 2020 11:08:26 GMT, Jorn Vernee wrote:
>> Mandy Chung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix the name passed to condy calling classData
>
> Left 2 minor comments on the new additions in line.
It is my understa
On Sun, 22 Nov 2020 22:15:20 GMT, Kim Barrett wrote:
> I didn't notice this before it was integrated.
>
> The test for inactive isn't right; rather than `next == this` it
> should be `next != null`. This becomes apparent once
> FinalizerHistogram is fixed to call getInactive() rather than get().
On Tue, 13 Oct 2020 13:08:14 GMT, Maurizio Cimadamore
wrote:
> This patch contains the changes associated with the first incubation round of
> the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory
> access support (see JEP 393 [2]
On Thu, 19 Nov 2020 13:50:30 GMT, Conor Cleary wrote:
> In TestNG 7, it is a requirement that TestNG is able to create a Test object
> using a default constructor.
>
> This simple fix addresses two such classes so that this requirement is
> satisfied by inserting default construtors. Example:
On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett wrote:
> Please review this change to Reference.clear() to address several issues.
>
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
>
> (JDK-8240696) For GCs
JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the
needed changes to get it working again.
Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro.
Using just JNI_ENTRY was causing a linkage failure, due to the declaration of
the function in th
[Sorry it took so long. Have been on break.]
From Guy:
Thanks for the forward. Here are my thoughts:
Good question from Rémi.
If we consider PRNGs to have started at about the time of von Neumann, circa
1946, then I would say that we have been inventing a new category about once
every 25 yea
Rémi,
> On Nov 21, 2020, at 8:03 AM, Remi Forax wrote:
>
> Ok, i've taking the time to read some literature about random generators
> because for me the Mersenne Twister was still the king.
>
> The current API proposed as clearly two levels, you have the user level and
> the implementation le
On Sat, 21 Nov 2020 11:22:55 GMT, Rémi Forax
wrote:
>> `listFromTrustedArrayNullsAllowed` is clearly not an option, as it will
>> produce shared-secret leaking (see
>> [JDK-8254090](https://bugs.openjdk.java.net/browse/JDK-8254090) for a
>> similar case). StreamEx solution is dirty as it reli
On Sat, 21 Nov 2020 09:21:06 GMT, John Lin
wrote:
>> @johnlinp, you cannot create a CSR by yourself at the moment. Someone else
>> will have to do that for you. Might as well be me. So here's my proposal:
>> come up with the meat, then I'll help you with the paperwork.
>>
>> For starters, ha
On Tue, 17 Nov 2020 17:19:13 GMT, Jorn Vernee wrote:
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing
On Tue, 17 Nov 2020 21:22:28 GMT, Paul Sandoz wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Gene
On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett wrote:
> Please review this change to Reference.clear() to address several issues.
>
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
>
> (JDK-8240696) For GCs
Both the Foreign Memory Access and the Foreign Linker APIs leave something to
be desired when it comes to handling NPEs - first, most of the API javadoc is
oblivious to NPEs being thrown. Secondly, not all API method implementations
add expicit NPE checks - with the result of NPE often being thr
On Tue, 17 Nov 2020 23:46:12 GMT, Paul Sandoz wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Gene
On Mon, 23 Nov 2020 14:57:59 GMT, Jim Laskey wrote:
>> src/java.base/share/classes/module-info.java line 250:
>>
>>> 248: exports jdk.internal.util.xml.impl to
>>> 249: jdk.jfr;
>>> 250: exports jdk.internal.util.random;
>>
>> Unqualified export, should this be `to jdk.random`?
On Mon, 23 Nov 2020 15:11:49 GMT, Maurizio Cimadamore
wrote:
> Both the Foreign Memory Access and the Foreign Linker APIs leave something to
> be desired when it comes to handling NPEs - first, most of the API javadoc is
> oblivious to NPEs being thrown. Secondly, not all API method implementa
On Wed, 18 Nov 2020 00:29:36 GMT, Paul Sandoz wrote:
>> Jim Laskey has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 40 commits:
>>
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Gene
On Fri, 20 Nov 2020 23:30:03 GMT, Roger Baumgartner
wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javado
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> javadoc can be found at
> http://cr.openjdk.java.net/~jlaskey/prng/doc/a
This is an enhancement which solves two issues:
1. Multiple reads of relevant cgroup interface files. Now interface files are
only read once per file (just like Hotspot).
2. Proxies creation of the impl specific subsystem via `determineType()` as
before, but now reads all relevant interface file
On Mon, 23 Nov 2020 15:46:56 GMT, Severin Gehwolf wrote:
> This is an enhancement which solves two issues:
>
> 1. Multiple reads of relevant cgroup interface files. Now interface files are
> only read once per file (just like Hotspot).
> 2. Proxies creation of the impl specific subsystem via `d
On Mon, 23 Nov 2020 15:46:56 GMT, Severin Gehwolf wrote:
> This is an enhancement which solves two issues:
>
> 1. Multiple reads of relevant cgroup interface files. Now interface files are
> only read once per file (just like Hotspot).
> 2. Proxies creation of the impl specific subsystem via `d
On Fri, 20 Nov 2020 17:55:55 GMT, Naoto Sato wrote:
> Hi,
>
> Please review the changes to the subject issue. This is to incorporate the
> latest language subtag registry definition into the JDK.
This pull request has now been integrated.
Changeset: ae0ca743
Author:Naoto Sato
URL:
On Mon, 23 Nov 2020 10:23:25 GMT, Chris Hegarty wrote:
> It is my understanding that `Lookup` object returned from
> defineHiddenClass[WithClassData] features the ORIGINAL access lookup mode,
> right? I cannot find a normative statement to confirm this. If it is the
> case, then it would be go
On Mon, 23 Nov 2020 15:11:49 GMT, Maurizio Cimadamore
wrote:
> Both the Foreign Memory Access and the Foreign Linker APIs leave something to
> be desired when it comes to handling NPEs - first, most of the API javadoc is
> oblivious to NPEs being thrown. Secondly, not all API method implementa
On Mon, 23 Nov 2020 17:58:22 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix cut/paste error in FunctionDescriptor
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/Funct
> Both the Foreign Memory Access and the Foreign Linker APIs leave something to
> be desired when it comes to handling NPEs - first, most of the API javadoc is
> oblivious to NPEs being thrown. Secondly, not all API method implementations
> add expicit NPE checks - with the result of NPE often b
On Thu, 19 Nov 2020 03:26:20 GMT, Sandhya Viswanathan
wrote:
> Remove partially implemented in-place conversion vector operators from Vector
> API:
>ofNarrowing, ofWidening, INPLACE_XXX
This pull request has now been integrated.
Changeset: 9de5d091
Author:Sandhya Viswanathan
URL:
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
On Mon, 23 Nov 2020 15:00:08 GMT, Roman Kennke wrote:
>> Please review this change to Reference.clear() to address several issues.
>>
>> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
>> field to null may extend the lifetime of the referent value.
>>
>> (JDK-8240696)
Hi,
Please review this simple doc fix. Thanks.
-
Commit messages:
- 8256839: JavaDoc for java.time.Period.negated() method
Changes: https://git.openjdk.java.net/jdk/pull/1399/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1399&range=00
Issue: https://bugs.openjdk.ja
On Mon, 23 Nov 2020 18:58:15 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was ca
On Mon, 23 Nov 2020 15:50:18 GMT, Severin Gehwolf wrote:
>> This is an enhancement which solves two issues:
>>
>> 1. Multiple reads of relevant cgroup interface files. Now interface files
>> are only read once per file (just like Hotspot).
>> 2. Proxies creation of the impl specific subsystem v
On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple doc fix. Thanks.
Marked as reviewed by rriggs (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1399
On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple doc fix. Thanks.
Looks fine and this is validated via
test/jdk/java/time/tck/java/time/TCKPeriod.java,
-
Marked as reviewed by lancea (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/139
On Mon, 23 Nov 2020 19:56:56 GMT, Severin Gehwolf wrote:
>> With respect to JDK-8255908, the changes look good to me.
>
>> With respect to JDK-8255908, the changes look good to me.
>
> Thanks!
@bobvandette Please review when you've got some cycles to spare. Much
appreciated!
-
PR
On Mon, 23 Nov 2020 19:39:18 GMT, Poonam Bajaj wrote:
> With respect to JDK-8255908, the changes look good to me.
Thanks!
-
PR: https://git.openjdk.java.net/jdk/pull/1393
On Mon, 23 Nov 2020 19:25:31 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains seven additional
>> com
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
On Mon, 23 Nov 2020 13:19:23 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR.
>
> src/hotspot/cpu/x86/universalNative
On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple doc fix. Thanks.
Marked as reviewed by joehw (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1399
When executing msiexec (possibly from batch script) retry on exitCode 1603 as
well as 1618
-
Commit messages:
- JDK-8256801: tools/jpackage/share/FileAssociationsTest.java#id0 failed
unpack.bat with "Exit code: 1603"
Changes: https://git.openjdk.java.net/jdk/pull/1400/files
Webre
Hi David,
Thanks for looking at this.
The intent was for method Class.permittedSubclasses() to be implemented
similarly to Class.getNestMembers(). Are you suggesting that a security
manager check be added to permittedSubclasses() similar to the security
manager check in getNestMembers()?
T
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the fu
On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett wrote:
> Please review this change to Reference.clear() to address several issues.
>
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
>
> (JDK-8240696) For GCs
On Mon, 23 Nov 2020 19:18:05 GMT, Per Liden wrote:
>> test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java line
>> 28:
>>
>>> 26: /* @test
>>> 27: * @bug 8256517
>>> 28: * @requires vm.gc.Z
>>
>> Please add | vm.gc.Shenandoah here.
>
> Note that for this test to be useful,
On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple doc fix. Thanks.
Marked as reviewed by scolebourne (Author).
-
PR: https://git.openjdk.java.net/jdk/pull/1399
On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett wrote:
> Please review this change to Reference.clear() to address several issues.
>
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
>
> (JDK-8240696) For GCs
On Sun, 22 Nov 2020 22:15:20 GMT, Kim Barrett wrote:
>> Thanks for adding this asserts. If there is any reason to use `getInactive`
>> by other references in the future, we could remove these asserts at that
>> time.
>
> I didn't notice this before it was integrated.
>
> The test for inactive
On Mon, 23 Nov 2020 20:16:58 GMT, Andy Herrick wrote:
> When executing msiexec (possibly from batch script) retry on exitCode 1603 as
> well as 1618
Marked as reviewed by asemenyuk (Committer).
-
PR: https://git.openjdk.java.net/jdk/pull/1400
On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this simple doc fix. Thanks.
This pull request has now been integrated.
Changeset: b3497f9b
Author:Naoto Sato
URL: https://git.openjdk.java.net/jdk/commit/b3497f9b
Stats: 2 lines in 1 file changed: 0 ins
> Please review this implementation of JEP 396
> (https://openjdk.java.net/jeps/396).
> Alan Bateman is the original author; I’ve credited him in the commit metadata.
> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.
Mark Reinhold has updated the pull request incrementally with o
> Please review this implementation of JEP 396
> (https://openjdk.java.net/jeps/396).
> Alan Bateman is the original author; I’ve credited him in the commit metadata.
> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.
Mark Reinhold has updated the pull request incrementally with o
On Mon, 23 Nov 2020 20:16:58 GMT, Andy Herrick wrote:
> When executing msiexec (possibly from batch script) retry on exitCode 1603 as
> well as 1618
Marked as reviewed by almatvee (Committer).
-
PR: https://git.openjdk.java.net/jdk/pull/1400
Hi Harold,
On 24/11/2020 6:27 am, Harold Seigel wrote:
Hi David,
Thanks for looking at this.
The intent was for method Class.permittedSubclasses() to be implemented
similarly to Class.getNestMembers(). Are you suggesting that a security
manager check be added to permittedSubclasses() simila
On Mon, 23 Nov 2020 20:36:11 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was ca
On Mon, 23 Nov 2020 20:16:58 GMT, Andy Herrick wrote:
> When executing msiexec (possibly from batch script) retry on exitCode 1603 as
> well as 1618
Looks fine.
-
Marked as reviewed by kizune (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1400
On Mon, 23 Nov 2020 14:35:37 GMT, Pavel Rappo wrote:
> The proposed CSR has a few problems that we need to resolve.
>
> 1. The **Specification** pseudo-code behaves differently from both the old
> pseudo-code and the actual implementation when `newValue == null && oldValue
> == null` and `map.
On Mon, 23 Nov 2020 18:10:47 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix cut/paste error in FunctionDescriptor
>
> Already looked at this in panama-foreign, but found one minor issue
> Please review this change to Reference.clear() to address several issues.
>
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
>
> (JDK-8240696) For GCs with concurrent reference processing, clearing the
> r
On Mon, 23 Nov 2020 12:50:31 GMT, Per Liden wrote:
> Looks good. Just want to request that you also remove the following comment
> in zReferenceProcessor.cpp, as it's no longer true.
>
> ```
> --- a/src/hotspot/share/gc/z/zReferenceProcessor.cpp
> +++ b/src/hotspot/share/gc/z/zReferenceProcesso
On Tue, 24 Nov 2020 02:59:50 GMT, Kim Barrett wrote:
>> Looks good. Just want to request that you also remove the following comment
>> in zReferenceProcessor.cpp, as it's no longer true.
>>
>> --- a/src/hotspot/share/gc/z/zReferenceProcessor.cpp
>> +++ b/src/hotspot/share/gc/z/zReferenceProcess
On Thu, 19 Nov 2020 20:45:23 GMT, Andy Herrick wrote:
>> …n name.
>
> Andy Herrick has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8256475: Fix Behavior when Installer name differs from application name.
Looks good.
src/jdk.jpackage/s
On Mon, 23 Nov 2020 14:06:02 GMT, sergus13
wrote:
>> This implementation duplicates the array twice, once in this.toArray() and
>> once in the constructor of ArrayList that calls toArray() on
>> Collections.ArrayList.
>>
>> I'm sure there is a better way
>
> In `ReferencePipeline` class we ha
On Sat, 21 Nov 2020 10:58:49 GMT, Rémi Forax
wrote:
>> It's an implementation invariant that the internal array be Object[]. Having
>> it be something other than Object[] can lead to subtle bugs. See
>> [JDK-6260652](https://bugs.openjdk.java.net/browse/JDK-6260652) for example.
>
> you can st
On Sat, 21 Nov 2020 11:02:27 GMT, Rémi Forax
wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adjust List.copyOf to null-check and copy allowNulls lists.
>> Fix equals, hashCode, indexOf, lastIndexOf to handle nu
On Mon, 23 Nov 2020 18:22:14 GMT, Maurizio Cimadamore
wrote:
>> Both the Foreign Memory Access and the Foreign Linker APIs leave something
>> to be desired when it comes to handling NPEs - first, most of the API
>> javadoc is oblivious to NPEs being thrown. Secondly, not all API method
>> imp
On Tue, 24 Nov 2020 01:14:20 GMT, David Holmes wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use the Unimplemented() macro instead of hlt()
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
>
>> 34:
> This change introduces a new terminal operation on Stream. This looks like a
> convenience method for Stream.collect(Collectors.toList()) or
> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
> method directly on Stream enables it to do what can't easily by done by a
On Tue, 24 Nov 2020 03:05:19 GMT, Kim Barrett wrote:
>> Please review this change to Reference.clear() to address several issues.
>>
>> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
>> field to null may extend the lifetime of the referent value.
>>
>> (JDK-8240696) F
71 matches
Mail list logo
