On 11/18/20 3:55 AM, Florian Weimer wrote:
I think it's also needed for an efficient null element check in
List::copyOf. I have a hunch that with the posted implementation, it
would incorrectly produce an immutable list that contains null
elements.
(Sorry for the delay; oddly, this comment
On Tue, 24 Nov 2020 02:19:34 GMT, Pavel Rappo wrote:
> 2. Both the proposed pseudo-code and the existing pseudo-code deviate from
> the documented behaviour (written in prose) and the actual implementation.
Let me clarify something. The "documented behavior" is actually the API
specification,
> 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 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-8188055 added the function Reference.refersTo. For performance, the
supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
should be intrinsified by C2.
Initial patch was prepared by @fisk.
Tested hs-tier1-4. Added new compiler tests to test intrinsics.
Ran new test w
On Mon, 23 Nov 2020 20:36:57 GMT, Roman Kennke wrote:
>> Kim Barrett has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - new tests need ref in oldgen too
>> - remove obsolete comment about races with clear and enqueue
>
> Looks good! Than
On Tue, 24 Nov 2020 13:35:17 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 11/24/20 3:18 PM, Remi Forax wrote:
Hi Mandy,
given that almost nobody knows about sealed packages, i'm not sure that adding
a reference to Package::isSealed in Class::isSealed actually helps, it might be
confusing.
It's even better if the API note in `Class::isSealed` from PR is remo
- Mail original -
> De: "Mandy Chung"
> À: "compiler-dev" , "core-libs-dev"
> , "hotspot-dev"
>
> Envoyé: Mercredi 25 Novembre 2020 00:02:53
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second
> Preview)
> On Tue, 17 Nov 2020 00:25:51 GMT, Mandy Chung wrote:
On Tue, 17 Nov 2020 00:25:51 GMT, Mandy Chung wrote:
>> src/java.base/share/classes/java/lang/Package.java line 227:
>>
>>> 225: * This method reports on a distinct concept of sealing from
>>> 226: * {@link Class#isSealed() Class::isSealed}.
>>> 227: *
>>
>> This API note will be
On 24/11/2020 11:56 pm, [email protected] wrote:
- Mail original -
De: "David Holmes"
À: "Remi Forax"
Cc: "Harold David Seigel" , "Vicente Romero"
, "compiler-dev"
, "core-libs-dev" ,
"hotspot-dev"
Envoyé: Mardi 24 Novembre 2020 13:16:39
Objet: Re: RFR: 8246778: Compiler implementat
On Wed, 18 Nov 2020 00:30:53 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
- Mail original -
> De: "Jim Laskey"
> À: "Remi Forax"
> Cc: "Jim Laskey" , "build-dev"
> , "core-libs-dev"
> , "security-dev"
>
> Envoyé: Lundi 23 Novembre 2020 14:27:31
> Objet: Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
> [v3]
> [Sorry it took so long. Ha
Original mail:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
Hello,
while working with `StringBuilder.insert()` I've spotted that its delegate
`AbstractStringBuilder.insert()` is missing
a fast-path for the most frequent case when its argument is `String`.
Pr
On Tue, 24 Nov 2020 09:58:19 GMT, Claes Redestad wrote:
>> Original mail:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
>>
>> Hello,
>>
>> while working with `StringBuilder.insert()` I've spotted that its delegate
>> `AbstractStringBuilder.insert()` is mi
- Mail original -
> De: "Jim Laskey"
> À: "Remi Forax"
> Cc: "Jim Laskey" , "core-libs-dev"
> , "security-dev"
>
> Envoyé: Lundi 23 Novembre 2020 14:58:50
> Objet: Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
> Rémi,
Hi Jim,
>
>> On Nov 21, 2020, at 8:03 AM,
On Tue, 29 Sep 2020 14:28:52 GMT, Сергей Цыпанов
wrote:
> Original mail:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
>
> Hello,
>
> while working with `StringBuilder.insert()` I've spotted that its delegate
> `AbstractStringBuilder.insert()` is missing
On Tue, 24 Nov 2020 18:43:02 GMT, Mandy Chung wrote:
> This adds API note in `Package::isSealed` javadoc to clarify package sealing
> vs sealed class or interface. Since it's spec clarification, CSR is not
> strictly needed.
This pull request has now been integrated.
Changeset: 3c230b8a
Aut
On Sun, 22 Nov 2020 16:00:45 GMT, Alan Bateman wrote:
>> This change terminally deprecates the following methods defined by
>> java.lang.ThreadGroup
>>
>> - stop
>> - destroy
>> - isDestroyed
>> - setDaemon
>> - isDaemon
>>
>> The stop method has been deprecated since=1.2 because it is i
On Tue, 24 Nov 2020 18:43:02 GMT, Mandy Chung wrote:
> This adds API note in `Package::isSealed` javadoc to clarify package sealing
> vs sealed class or interface. Since it's spec clarification, CSR is not
> strictly needed.
Marked as reviewed by alanb (Reviewer).
src/java.base/share/classe
> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live
> objects
> be shared between a hidden class and other classes. A hidden class can load
> these live objects as dynamically-computed constants via this API.
>
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs
This adds API note in `Package::isSealed` javadoc to clarify package sealing vs
sealed class or interface. Since it's spec clarification, CSR is not strictly
needed.
-
Commit messages:
- make it api Note
- 8256993: Clarify Package::isSealed javadoc about package sealing vs seale
On Wed, 18 Nov 2020 17:32:55 GMT, Roger Riggs wrote:
> ObjectInputStream has nearly identical but separate implementations to read
> values from the stream.
> Both implementations read primitive and object values from the stream and
> return an object holding the values.
> OIS.readFields() uses
On Tue, 24 Nov 2020 15:38:17 GMT, Maurizio Cimadamore
wrote:
>> Marked as reviewed by chegar (Reviewer).
>
> Following @dholmes-ora suggestion and also @jddarcy (in CSR review), I've
> uploaded a new iteration which instead of adding a `@throws` tag at every
> method, adds a general statement
> 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 Tue, 24 Nov 2020 15:54:47 GMT, Joel Borggrén-Franck
wrote:
> The fix for JDK-8256693 too often produces a ParameterizedType as the result
> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
> when this type or any of its transitive owner types has type parameters, b
The fix for JDK-8256693 too often produces a ParameterizedType as the result of
getAnnotatedReceiverType().getType() . A ParameterizedType is necessary when
this type or any of its transitive owner types has type parameters, but should
be avoided if this isn't the case.
This implementation recu
> 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
> 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 Tue, 24 Nov 2020 09:34:09 GMT, Chris Hegarty wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix cut/paste error in FunctionDescriptor
>
> Marked as reviewed by chegar (Reviewer).
Following @dholmes-ora
> 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
> 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 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
This pull request has now been integrated.
Changeset: ff6df15b
Author:Andy Herrick
URL: https://git.openjdk.java.net/jdk/commit/ff6df1
On Wed, 18 Nov 2020 22:17:07 GMT, Andy Herrick wrote:
> …n name.
This pull request has now been integrated.
Changeset: 303631e3
Author:Andy Herrick
URL: https://git.openjdk.java.net/jdk/commit/303631e3
Stats: 216 lines in 18 files changed: 176 ins; 13 del; 27 mod
8256475: Fix Be
On Tue, 24 Nov 2020 03:38:01 GMT, Alexander Zuev wrote:
>> 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.
>
> src/jdk.jpackage/share/classes/j
On Tue, 24 Nov 2020 13:31:17 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Remove JNI_ENTRY_CPP_NOENV
>> - - Move reset_last_Java_frame
>
> This looks fine to me. PIty to see `CATCH` on th
- Mail original -
> De: "David Holmes"
> À: "Remi Forax"
> Cc: "Harold David Seigel" , "Vicente Romero"
> , "compiler-dev"
> , "core-libs-dev"
> , "hotspot-dev"
>
> Envoyé: Mardi 24 Novembre 2020 13:16:39
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second
>
On Tue, 24 Nov 2020 13:21:08 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
> 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
> 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 Tue, 24 Nov 2020 10:30:33 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use the Unimplemented() macro instead of hlt()
>
> I have a few minor comments, in addition to what David is saying
The main assumption is that calling code is fully foreign, and that it
does not know how to Java handle exceptions at all.
So, if an exception is thrown at this point, we should probably just
crash, and make it the callee's responsibility to handle exception if
they need/want to.
Looking at
On 24/11/2020 9:38 pm, Jorn Vernee wrote:
On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes wrote:
src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
34: extern struct JavaVM_ main_vm;
35:
36: JNI_ENTRY_CPP_NOENV(void, ProgrammableUpcallHandler::upcall_helper(jobject
rec, address buff
Hi Remi,
On 24/11/2020 7:45 pm, Remi Forax wrote:
- Mail original -
De: "David Holmes"
À: "Harold David Seigel" , "Vicente Romero"
, "compiler-dev"
, "core-libs-dev" ,
"hotspot-dev"
Envoyé: Mardi 24 Novembre 2020 02:04:55
Objet: Re: RFR: 8246778: Compiler implementation for Sealed C
On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes wrote:
>> src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
>>
>>> 34: extern struct JavaVM_ main_vm;
>>> 35:
>>> 36: JNI_ENTRY_CPP_NOENV(void,
>>> ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff))
>>
>> I do not like
On Mon, 23 Nov 2020 23:14:11 GMT, Mark Reinhold wrote:
>> 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.
On Tue, 24 Nov 2020 10:12:23 GMT, Chris Hegarty wrote:
> Minor cleanup - Reflective access to j.l.Record is no longer required since
> it became standard.
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1406
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 Tue, 24 Nov 2020 10:12:23 GMT, Chris Hegarty wrote:
> Minor cleanup - Reflective access to j.l.Record is no longer required since
> it became standard.
Looks good!
-
Marked as reviewed by redestad (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1406
Minor cleanup - Reflective access to j.l.Record is no longer required since it
became standard.
-
Commit messages:
- 8255904: Remove superfluous use of reflection in Class::isRecord
Changes: https://git.openjdk.java.net/jdk/pull/1406/files
Webrev: https://webrevs.openjdk.java.net/
On Sat, 21 Nov 2020 00:39:23 GMT, Mandy Chung wrote:
>> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live
>> objects
>> be shared between a hidden class and other classes. A hidden class can load
>> these live objects as dynamically-computed constants via this API.
>>
>
On Mon, 23 Nov 2020 17:48:31 GMT, Mandy Chung 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
- Mail original -
> De: "David Holmes"
> À: "Harold David Seigel" , "Vicente Romero"
> , "compiler-dev"
> , "core-libs-dev"
> , "hotspot-dev"
>
> Envoyé: Mardi 24 Novembre 2020 02:04:55
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second
> Preview)
> Hi Harol
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
54 matches
Mail list logo
