Re: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton

On Mon, 22 Mar 2021 19:40:19 GMT, Aleksei Voitylov wrote: > With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. > > After JDK-8253081 with CDS enabled two instances of empty layer appear in the > runtime. One comes from default initialization of >

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread [v3]

On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett wrote: >> Please review this change to java.util.Timer, replacing the use of >> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner. >> >> In addition, Timer.cancel now cancels any later execution of the the no >> longer

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread [v2]

On Mon, 22 Mar 2021 07:19:28 GMT, Kim Barrett wrote: >> Please review this change to java.util.Timer, replacing the use of >> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner. >> >> In addition, Timer.cancel now cancels any later execution of the the no >> longer

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread

On Mon, 22 Mar 2021 05:40:10 GMT, Kim Barrett wrote: >> test/jdk/java/util/Timer/AutoStop.java line 47: >> >>> 45: public void run() { >>> 46: tdThread = Thread.currentThread(); >>> 47: synchronized(wakeup) { >> >> tdThread should be set

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread

On Sun, 21 Mar 2021 03:53:24 GMT, Kim Barrett wrote: > Please review this change to java.util.Timer, replacing the use of deprecated > finalization-based cleanup with use of java.lang.ref.Cleaner. > > In addition, Timer.cancel now cancels any later execution of the the no > longer relevant

Re: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer thread

On Sun, 21 Mar 2021 03:53:24 GMT, Kim Barrett wrote: > Please review this change to java.util.Timer, replacing the use of deprecated > finalization-based cleanup with use of java.lang.ref.Cleaner. > > In addition, Timer.cancel now cancels any later execution of the the no > longer relevant

Re: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)?

https://bugs.openjdk.java.net/browse/JDK-8022671 Cheers, David On 17/03/2021 1:21 pm, Jaikiran Pai wrote: Please consider this trivial code: import java.io.*; import java.nio.file.*; public class FileTest {     public static void main(final String[] args) throws Exception {    

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM

On 16/03/2021 2:59 pm, David Holmes wrote: On 16/03/2021 11:58 am, Sergey Bylokhov wrote: On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote: This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS. As @dholmes-ora pointed out

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM

On 16/03/2021 11:58 am, Sergey Bylokhov wrote: On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote: This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS. As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM

Hi Henry, On 15/03/2021 9:40 am, Henry Jen wrote: This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS. As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v27]

On Fri, 12 Mar 2021 16:44:38 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]

On 12/03/2021 5:12 pm, Anton Kozlov wrote: On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes wrote: Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: 8262903: [macos_aarch64] Thread::current() called on detached thread src/hotspot

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]

On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of

Re: RFR: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category) [v2]

On Fri, 5 Mar 2021 18:58:44 GMT, Naoto Sato wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix omitted synchronized > > Looks good. If I read the order right your benchmark findings were done before you added

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]

On Tue, 2 Mar 2021 21:19:18 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of the

Re: RFR: 8262271: SA: Add new stress test that tests getting the stack trace of an active thread

Hi Chris, On 25/02/2021 1:59 pm, Chris Plummer wrote: This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up. Sorry but I don't see how this ensures it runs jstack as the jshell is starting up, the startup could be

Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2]

On 20/02/2021 12:00 am, Naoto Sato wrote: On Thu, 18 Feb 2021 14:49:20 GMT, Roger Riggs wrote: The table is informative and should not be construed as specification. The wording "has supported" should be sufficient. If this is not specification then doesn't that imply that any provider of

Re: RFR: 8259800: timeout in tck test testForkJoin(ForkJoinPool8Test) [v2]

On Sun, 21 Feb 2021 23:22:00 GMT, Doug Lea wrote: >> This addresses interactions between parallelism-0 and new shutdown support >> in https://bugs.openjdk.java.net/browse/JDK-8259800 > > Doug Lea has updated the pull request incrementally with one additional > commit since the last revision: >

Re: RFR: 8261621: Delegate Unicode history from JLS to j.l.Character [v2]

On Fri, 12 Feb 2021 15:22:15 GMT, Roger Riggs wrote: > > > The table is informative and should not be construed as specification. > The wording "has supported" should be sufficient. If this is not specification then doesn't that imply that any provider of any version of OpenJDK would be free

Re: RFR: 8252883: AccessDeniedException caused by delayed file deletion on Windows [v3]

On Tue, 16 Feb 2021 21:15:58 GMT, Evan Whelan wrote: >> Hi, >> >> Please review this fix for JDK-8252883. This handles the case when an >> AccessDeniedException is being thrown on Windows, due to a delay in deleting >> the lock file it is trying to write to. >> >> This fix passes all

Re: RFR: 8261449: Micro-optimize JVM_LatestUserDefinedLoader

On Tue, 9 Feb 2021 15:40:03 GMT, Aleksey Shipilev wrote: > `JVM_LatestUserDefinedLoader` is called normally from > `ObjectInputStream.resolveClass` -> `VM.latestUserDefinedLoader0`. And it > takes a measurable time to walk the stack. There is JDK-8173368 that wants to > replace it with

Re: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v3]

On Fri, 5 Feb 2021 02:28:31 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/systemDictionary.cpp line 503: >> >>> 501: } else { >>> 502: log_debug(protectiondomain)("granted"); >>> 503: } >> >> Did you intend leaving this in? > > Yes, why not? It's very useful in

Re: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v3]

On Fri, 5 Feb 2021 02:25:15 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/dictionary.cpp line 145: >> >>> 143: #ifdef ASSERT >>> 144: if (protection_domain == instance_klass()->protection_domain()) { >>> 145: MutexLocker ml(ProtectionDomainSet_lock, >>>

Re: RFR: 8195744: Avoid calling ClassLoader.checkPackageAccess if security manager is not installed [v3]

On Fri, 5 Feb 2021 02:37:54 GMT, Coleen Phillimore wrote: >> This change does not call up to Java for checkPackageAccess if the security >> manager is NULL, but still saves the protection domain in the pd_set for >> that dictionary entry. If the option -Djava.security.manager=disallow is >>

Re: RFR: 8261149: Initial nroff manpage update for JDK 17

On Thu, 4 Feb 2021 10:13:31 GMT, Magnus Ihse Bursie wrote: > We need to regenerate the exported nroff man pages to include the proper > version string. This will also bring in some recent textual updates to the > man pages. LGTM. Thanks, David - Marked as reviewed by dholmes

Re: [jdk16] RFR: 8258378: Final nroff manpage update for JDK 16

On Mon, 1 Feb 2021 11:09:25 GMT, Magnus Ihse Bursie wrote: > Before RC phase we need to ensure we have the final set of manpage updates > published in OpenJDK. Thanks for doing this Magnus! I had overlooked the fact we would need to re-run this in 2021 regardless of whether there were any

Re: RFR: 8259814: test/jdk/tools/jlink/plugins/CompressorPluginTest.java has compilation issues [v2]

On Mon, 1 Feb 2021 11:41:43 GMT, Alan Bateman wrote: >> Athijegannathan Sundararajan has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Removed CompressorPluginTest.java from ProblemList.txt > > Marked as reviewed by alanb (Reviewer).

Re: RFR: 8260860: ProblemList tools/jlink/plugins/CompressorPluginTest.java

On Mon, 1 Feb 2021 22:06:31 GMT, Daniel D. Daugherty wrote: > A trivial fix to put tools/jlink/plugins/CompressorPluginTest.java back on the > ProblemList. It was removed in error (see the bug for the details). LGTM - Marked as reviewed by dholmes (Reviewer). PR:

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v2]

Hi Alex, On 28/01/2021 7:44 am, Alex Menkov wrote: On Tue, 19 Jan 2021 23:18:04 GMT, David Holmes wrote: Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Non-lava launchers should process all "-J" arguments Hi Alex

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

I don't know why the Skara tools decided to associate my comment with Alan Hayward's comment as they are not at all related. :( David On 27/01/2021 4:50 pm, David Holmes wrote: On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward wrote: AIUI, the configure line needs passing a prebuilt

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

On Tue, 26 Jan 2021 12:34:11 GMT, Alan Hayward wrote: >>> AIUI, the configure line needs passing a prebuilt JavaNativeFoundation >>> framework >>> ie: >>> `--with-extra-ldflags='-F >>>

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v2]

Alex, On 20/01/2021 11:47 am, Alex Menkov wrote: On Tue, 19 Jan 2021 23:16:30 GMT, David Holmes wrote: What do you mean by this? The -J args are not "translated" here but later in TranslateApplicationArgs. I meant that they are translated in TranslateApplicationArgs. Looks

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v2]

On Tue, 19 Jan 2021 23:02:54 GMT, Alex Menkov wrote: >> The fix adds NMT handling for non-java launchers > > Alex Menkov has updated the pull request incrementally with one additional > commit since the last revision: > > Non-lava launchers should process all "-J" arguments Hi Alex, I

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly

On 17/01/2021 10:58 pm, David Holmes wrote: On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov wrote: The fix adds NMT handling for non-java launchers Alex, This approach results in two scans of the argument list in the IsJavaArgs case. I don't know if we care about startup in the non-Java

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly

On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov wrote: > The fix adds NMT handling for non-java launchers Alex, This approach results in two scans of the argument list in the IsJavaArgs case. I don't know if we care about startup in the non-Java launchers, but this will likely affect it.

Re: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection

Hi Severin, On 13/01/2021 12:31 am, Severin Gehwolf wrote: On Tue, 15 Dec 2020 12:57:12 GMT, Severin Gehwolf wrote: @bobvandette Please review when you've got some cycles to spare. Much appreciated! Ping? Anyone? Anybody willing to review this? FYI Bob retired at the end of last year.

Re: SoftReferences and java.lang.OutOfMemoryError: Direct buffer memory

On 29/12/2020 7:15 pm, Florian Weimer wrote: * David Holmes: More accurately soft-references will be cleared before throwing an OOME due to Java heap exhaustion. There are other things that can throw OOME (like your array example, or "throw new OutOfMemoryError();") that don't

Re: SoftReferences and java.lang.OutOfMemoryError: Direct buffer memory

Hi Brett, On 29/12/2020 5:16 am, Brett Okken wrote: I am cross posting this from the nio-dev mailing list. The javadoc for SoftReference states: All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError. As

Re: Impossible (?) code path resulting in IllegalStateException on jdk14+

remove the forkjoinpool from the repro (just threads?) AFAICS the FJP is critical here as it is the unexpected exception from managedBlock() that causes the problem. Cheers, David On Sun, Dec 13, 2020 at 6:28 PM David Holmes <mailto:david.hol...@oracle.com>> wrote: Hi Dawid,

Re: Impossible (?) code path resulting in IllegalStateException on jdk14+

Hi Dawid, This appears to be a bug in AbstractQueuedSynchronizer and FJP interaction, so cc'ing core-libs as this is not a hotspot issue. Also cc'ing Martin and Doug as this is a j.u.c bug. Cheers, David On 12/12/2020 12:56 am, Dawid Weiss wrote: So, I know what this is. Sort of. This

Re: RFR: 8257450: Start of release updates for JDK 17 [v5]

On Tue, 8 Dec 2020 17:10:30 GMT, Joe Darcy wrote: >> Start of JDK 17 updates. > > Joe Darcy 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 12

Re: A Bug involving MethodHandles, Nestmates, Reflection and @CallerSensitive

Hi Johannes, I've filed this bug report for you: https://bugs.openjdk.java.net/browse/JDK-8257874 Thanks, David On 8/12/2020 11:20 am, Johannes Kuhn wrote: Let's start with the reproducer:     public class NestmateBug {     private static int field = 0;     public static void

Re: RFR: 8243614: Typo in ReentrantLock's Javadoc

On Fri, 4 Dec 2020 22:06:03 GMT, Martin Buchholz wrote: > Add missing semicolon > > Martin's first github pr. Looks trivially fine. - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1633

Re: RFR: 8257450: Start of release updates for JDK 17

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote: > Start of JDK 17 updates. Looks good - 99% sym stuff :) Doesn't look like the hotspot deprecated flag test will need updating this time, as no newly deprecated flags marked for obsoletion in 17. src/hotspot/share/opto/type.cpp line 827: >

Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview) [v2]

On 1/12/2020 10:39 am, Mandy Chung wrote: On Mon, 30 Nov 2020 20:57:32 GMT, Harold Seigel wrote: src/java.base/share/classes/java/lang/Class.java line 4480: 4478: } 4479: 4480: private native Class[] getPermittedSubclasses0(); Does this JVM method return the permitted subclasses

Re: Why having the wrong InnerClasses attribute is an issue for the VM ?

On 30/11/2020 8:04 pm, fo...@univ-mlv.fr wrote: - Mail original - De: "David Holmes" À: "Remi Forax" , "core-libs-dev" Envoyé: Lundi 30 Novembre 2020 08:57:37 Objet: Re: Why having the wrong InnerClasses attribute is an issue for the VM ? On 30/11/

Re: Why having the wrong InnerClasses attribute is an issue for the VM ?

On 30/11/2020 5:08 pm, Remi Forax wrote: I've forgotten a cast in an invokedynamic, hence a call to wrongTargetType, but in order to create the error message, MethodType.toString(), getSimpleName() is called and it fails because getDeclaringClass() verifies the InnerClasses attribute. For me

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v7]

On Wed, 25 Nov 2020 12:09:07 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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v6]

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

Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

On 24/11/2020 11:56 pm, fo...@univ-mlv.fr wrote: - Mail original - De: "David Holmes" À: "Remi Forax" Cc: "Harold David Seigel" , "Vicente Romero" , "compiler-dev" , "core-libs-dev" , "hotspot-dev" Env

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4]

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

Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4]

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/universalUpcal

Re: RFR: 8256865: Foreign Memory Access and Linker API are missing NPE checks [v2]

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

Re: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4]

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

Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

() similar to the security manager check in getNestMembers()? No I'm suggesting the change to the API is plain wrong. :) Please see discussion in the CSR. Cheers, David Thanks, Harold On 11/18/2020 12:31 AM, David Holmes wrote: Hi Vincente, On 16/11/2020 11:36 pm, Vicente Romero wrote: Please

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3]

Hi Alan, On 20/11/2020 6:04 pm, Alan Bateman wrote: On Fri, 20 Nov 2020 07:33:50 GMT, David Holmes wrote: I'm somewhat surprised by the extent of the other changes given the basic change here is to deprecate the option and change its default. I literally expected to see only 2 simple

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3]

On Thu, 19 Nov 2020 23:08:21 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

Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

Hi Vincente, On 16/11/2020 11:36 pm, Vicente Romero wrote: Please review the code for the second iteration of sealed classes. In this iteration we are: - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies. -

Re: RFR: 8253280: Use class name as class loading lock

Hi Robert, I have to agree with Mandy and Alan here. What you propose, in terms of getting more visibility into which class the classloader is trying to load, is quite reasonable. But the mechanism is quite problematic for a number of reasons as Mandy mentioned. In particular platform code

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v18]

On 11/11/2020 9:19 pm, Jorn Vernee wrote: On Wed, 11 Nov 2020 07:18:33 GMT, David Holmes wrote: Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision: - Merge pull request #7 from JornVernee/Additional_Review_Comments

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v18]

On Tue, 10 Nov 2020 14:16:22 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

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

On 10/11/2020 2:34 am, Jorn Vernee wrote: On Mon, 9 Nov 2020 12:11:56 GMT, Jorn Vernee wrote: I agree with Coleen. I'll give this another try, but I think last time I tried this resolution of the class failed when trying to build the JDK, seemingly since it exists in an incubator module,

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v16]

On Mon, 9 Nov 2020 18:25:27 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

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

Hi Jorn, On 9/11/2020 9:57 pm, Jorn Vernee wrote: On Mon, 9 Nov 2020 03:29:05 GMT, David Holmes wrote: src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99: 97: if (thread == NULL) { 98: JavaVM_ *vm = (JavaVM *)(_vm); 99: vm -> functi

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

On Fri, 6 Nov 2020 21:42:41 GMT, Coleen Phillimore 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 64 commits: >> >> - Merge branch '8254162' into 8254231_linker >> - Fix post-merge issues caused

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v14]

On Fri, 30 Oct 2020 12:16:02 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

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

On Thu, 5 Nov 2020 21:26:16 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

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v15]

On Thu, 5 Nov 2020 21:26:16 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

Re: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethod…

On 5/11/2020 7:09 pm, Aleksey Shipilev wrote: On Thu, 5 Nov 2020 02:52:05 GMT, Hui Shi wrote: …AccessorImpl object We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883 Optimize solution is adding a new

Re: RFR: 8255231: Avoid upcalls when initializing the statSampler [v4]

e pull request contains 21 additional > commits since the last revision: > > - Address review comments from David Holmes > - Merge branch 'master' into com_ns > - Refactor to remove stable_java_property_counters and clarify comments > - Merge branch 'master' into com_ns > - Reve

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett wrote: >> Finally returning to this review that was started in April 2020. I've >> recast it as a github PR. I think the security concern raised by Gil >> has been adequately answered. >>

Re: RFR: 8255043: Incorrectly styled copyright text

On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov wrote: > In some files, the copyright text is styled as a JavaDoc comment. > Most of the affected files are tests, only one product file is affected: > src/java.sql/share/classes/javax/sql/package-info.java > > The chenge is trivial: > - /** >

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

On 20/10/2020 5:51 pm, Kim Barrett wrote: On Oct 20, 2020, at 3:21 AM, David Holmes wrote: On 20/10/2020 5:01 pm, Kim Barrett wrote: On Oct 20, 2020, at 2:09 AM, David Holmes wrote: I think that can be addressed by considering a Reference created with a null referent to be immediately

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

On 20/10/2020 5:01 pm, Kim Barrett wrote: On Oct 20, 2020, at 2:09 AM, David Holmes wrote: On 20/10/2020 3:26 pm, Kim Barrett wrote: On Tue, 20 Oct 2020 03:25:45 GMT, Mandy Chung wrote: @kimbarrett your reworded text is okay. I think "if it initially had some other referent value

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

On 20/10/2020 3:26 pm, Kim Barrett wrote: On Tue, 20 Oct 2020 03:25:45 GMT, Mandy Chung wrote: @kimbarrett your reworded text is okay. I think "if it initially had some other referent value" can be dropped. For a `Reference` constructed with a `null` referent, we can clarify in the spec

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

On 20/10/2020 12:40 pm, Kim Barrett wrote: On Oct 19, 2020, at 7:20 PM, Mandy Chung wrote: On Mon, 19 Oct 2020 23:10:23 GMT, Mandy Chung wrote: Looks good. That's the crux of it: what exactly is meant by "the referent"? Does it mean the original object that was used as the referent, or

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

Hi Mandy, On 20/10/2020 9:20 am, Mandy Chung wrote: On Mon, 19 Oct 2020 23:10:23 GMT, Mandy Chung wrote: Looks good. That's the crux of it: what exactly is meant by "the referent"? Does it mean the original object that was used as the referent, or does it mean the current value of the

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

Hi Kim, On 19/10/2020 9:29 pm, Kim Barrett wrote: On Oct 18, 2020, at 5:36 PM, David Holmes wrote: On 17/10/2020 1:23 am, Kim Barrett wrote: src/java.base/share/classes/java/lang/ref/Reference.java line 348: 346: * Tests if this reference object refers to {@code obj}. If {@code obj

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v4]

Hi Jorn, I'm not reviewing this but this exchange caught my attention ... On 16/10/2020 9:15 pm, Jorn Vernee wrote: On Thu, 15 Oct 2020 22:42:49 GMT, Coleen Phillimore wrote: Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

On 17/10/2020 1:23 am, Kim Barrett wrote: On Fri, 16 Oct 2020 05:41:17 GMT, David Holmes wrote: Kim Barrett 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

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

On Thu, 15 Oct 2020 17:04:37 GMT, Kim Barrett wrote: >> Finally returning to this review that was started in April 2020. I've >> recast it as a github PR. I think the security concern raised by Gil >> has been adequately answered. >>

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

On Thu, 15 Oct 2020 17:04:37 GMT, Kim Barrett wrote: >> Finally returning to this review that was started in April 2020. I've >> recast it as a github PR. I think the security concern raised by Gil >> has been adequately answered. >>

Re: Howto replicate failure of 8254790?

Hi Jason, On 15/10/2020 10:42 am, Tatton, Jason wrote: Hi all, I am trying to replicate the failure of the tier2 test mentioned in 8254790 but I am only seeing it pass under an x86 linux machine. Are there any specific architectural

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3]

On Thu, 24 Sep 2020 16:59:03 GMT, Richard Reingruber wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]

Hi Chris, Monica, On 25/09/2020 1:47 am, Chris Plummer wrote: As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of other non-SA files that are new and also have the same copyright issue. If a file was created completely from

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]

On Thu, 24 Sep 2020 04:57:39 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequ

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5]

On Wed, 23 Sep 2020 13:23:43 GMT, Monica Beckwith wrote: >> This is a continuation of >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2]

On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote: >> Marked as reviewed by kvn (Reviewer). > > Have you run the JFR tests in test/jdk/jdk/jfr? @marschall Please do not force-push anything as it breaks the commit history in the PR and renders previous reviews/comments obsolete. There is no

Re: Looking for a sponsor for JDK-8138732

Hi Philippe, On 22/09/2020 3:57 pm, Philippe Marschall wrote: Hello I am looking for a sponsor for JDK-8138732 [1]. The ready to integrate PR is here [2]. Sorry I can't volunteer to sponsor this. Changes between the current code and the reviewed code: - I removed the jdk.internal export

Re: Request for review of JDK-8251548

- Cheers, Sergey 17.09.2020, 14:11, "David Holmes" : On 17/09/2020 7:24 pm, Сергей Цыпанов wrote:  Hi David,  thanks for pointing this out!  I've created a PR there [1], but GitHub for some reason wants me to sign OCA,  which I have already signed in 2017. I've redone the procedure

Re: Request for review of JDK-8251548

." [1] https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300=1 Cheers, David - Regards, Sergey 1. https://github.com/openjdk/jdk/pull/218 17.09.2020, 09:22, "David Holmes" : Hi Sergey, Since OpenJDK has moved to git/github, this needs to reformulated as a Pull Request

Re: Request for review of JDK-8251548

Hi Sergey, Since OpenJDK has moved to git/github, this needs to reformulated as a Pull Request (PR). Cheers, David On 17/09/2020 5:19 pm, Сергей Цыпанов wrote: Hello, is it possible to have a code review for the changes proposed in JDK-8251548? Sean Mullan has created an issue and

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

On 14/09/2020 6:18 pm, Richard Reingruber wrote: On Mon, 14 Sep 2020 04:57:21 GMT, David Holmes wrote: Hi, this is the continuation of the review of the implementation for: https://bugs.openjdk.java.net/browse/JDK-8227745 https://bugs.openjdk.java.net/browse/JDK-8233915 It allows for JIT

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

On Thu, 10 Sep 2020 20:48:23 GMT, Richard Reingruber wrote: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape

Re: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2]

On Wed, 9 Sep 2020 00:08:35 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> JDK-8247589: Implementation of Alpine Linux/x64 Port > > Attempting to use th

Re: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2]

On Fri, 11 Sep 2020 07:36:57 GMT, Aleksei Voitylov wrote: >> test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c line 282: >> >>> 280: >>> 281: pthread_attr_init(_attr); >>> 282: pthread_attr_setstacksize(_attr, stack_size); >> >> Just a comment in response to the explanation as to why

Re: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2]

On Fri, 11 Sep 2020 07:03:37 GMT, Aleksei Voitylov wrote: >> continuing the review thread from here >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html >> >>> The download side of using JNI in these tests is that it complicates the >>> setup a bit for those

Re: RFR: 8251397: Add release fence to ClassValueMap constructor

On Thu, 10 Sep 2020 13:29:29 GMT, Severin Gehwolf wrote: >> Just noting here that @galderz is a Red Hat employee and should be covered >> by the Red Hat OCA: >> https://www.oracle.com/technical-resources/oracle-contributor-agreement.html#r > > @galderz We'll have to wait until somebody marks

Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

On 10/09/2020 10:07 pm, Dmitriy Dumanskiy wrote: On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do the same in the java.desktop module (JDK-8223237). Changing

<    1   2   3   4   5   6   7   8   9   10   >