Re: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022 [v2]

On Thu, 2 Sep 2021 08:16:52 GMT, Matthias Baesken wrote: >> Hello, please review this small change. >> The OS detection code of the JDK/JVM should recognize the new Windows server >> 2022 : >> >> https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 >>

Re: RFR: JDK-8273229: Update OS detection code to recognize Windows Server 2022

On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken wrote: > Hello, please review this small change. > The OS detection code of the JDK/JVM should recognize the new Windows server > 2022 : > > https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022 >

Re: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation [v2]

On Wed, 1 Sep 2021 18:28:30 GMT, Paul Sandoz wrote: >> Vladimir Ivanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Improve comments > > src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 1152: > >> 1150: * The call

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3]

On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified >> unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the >> child VM have failed, the VM is

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3]

On Wed, 1 Sep 2021 15:12:16 GMT, Roger Riggs wrote: > I've had very inconsistent results using the Windows 'timeout' command. > There appear to multiple versions. Some give an error message "Type "TIMEOUT > /?" for usage.", (Windows 10) > others a error message "Try 'timeout --help' for more

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3]

On Wed, 1 Sep 2021 15:02:44 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/Basic.java line 2665: >> >>> 2663: >>> 2664: Path exePath = >>> Path.of(TEST_NATIVEPATH).resolve("BasicSleep.exe"); >>> 2665: System.out.println("exePath: " + exePath + ", canExec:

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3]

On Tue, 24 Aug 2021 19:06:55 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/Basic.java line 30: >> >>> 28: * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 >>> 29: * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 >>> 30: *

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3]

On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified >> unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the >> child VM have failed, the VM is

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v3]

On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote: >> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified >> unexpected messages from a child Java VM >> as the cause of the test failure. Attempts to control the output of the >> child VM have failed, the VM is

Re: StringBuilder OOMs earlier with JRE 11 compared to JRE 8

Hi Simeon, Redirecting this to core-libs-dev as it is not a serviceability issue. (bcc serviceabillity-dev) Thanks, David On 27/08/2021 8:53 pm, S A wrote: Hi all, while working on https://bugs.eclipse.org/bugs/show_bug.cgi?id=575641 ,

Re: Replace StringBuffers to StringBuilders in tests

On 27/08/2021 8:42 pm, Daniel Fuchs wrote: Hi Sergei, I wouldn't bother replacing StringBuffers with StringDuilders in tests. It seems a bit gratuitous - and possibly could complicate future tests backports. But that's my personal opinion. Others might disagree. I agree with you. Complete

Re: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation

On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote: > Get rid of WeakReference-based logic in > DirectMethodHandle::checkInitialized() and reimplement it with > `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`. > > The key observation is that `Unsafe::ensureClassInitialized()`

Re: RFR: 8273000: Remove WeakReference-based class initialisation barrier implementation

On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote: > The key observation is that `Unsafe::ensureClassInitialized()` does not block > the initializing thread. I'm unclear exactly what that statement is meant to indicate. The thread actually running "clinit" does not block due to the

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system > property from "allow" to "disallow". This means unless it's explicitly set to > "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The

Re: RFR: 8270380: Change the default value of the java.security.manager system property to disallow

On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote: > This change modifies the default value of the `java.security.manager` system > property from "allow" to "disallow". This means unless it's explicitly set to > "allow", any call to `System.setSecurityManager()` would throw an UOE. > > The

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

On 3/08/2021 2:25 am, Igor Ignatyev wrote: On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: Hi all, could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? the majority of the patch is the

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves >> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >>

Re: RFR: JDK-8256844: Make NMT late-initializable

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe wrote: > Short: this patch makes NMT available in custom-launcher scenarios and during > gtests. It simplifies NMT initialization. It adds a lot of NMT-specific > testing, cleans them up and makes them sideeffect-free. > > - > > NMT

Re: RFR: JDK-8256844: Make NMT late-initializable

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe wrote: > Short: this patch makes NMT available in custom-launcher scenarios and during > gtests. It simplifies NMT initialization. It adds a lot of NMT-specific > testing, cleans them up and makes them sideeffect-free. > > - > > NMT

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package

On Thu, 29 Jul 2021 01:30:37 GMT, Vladimir Kozlov wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves >> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions:

Re: RFR: 8271368: [BACKOUT] JDK-8266054 VectorAPI rotate operation optimization

On Wed, 28 Jul 2021 05:35:59 GMT, Vladimir Kozlov wrote: > Backout the following changes due to vector tests failures in tier 2 and > later: > [JDK-8266054](https://bugs.openjdk.java.net/browse/JDK-8266054) VectorAPI > rotate operation optimization > > Changes also caused copyright header

Re: RFR: JDK-8256844: Make NMT late-initializable

On 28/07/2021 12:17 am, Thomas Stuefe wrote: On Mon, 26 Jul 2021 21:08:04 GMT, David Holmes wrote: Before looking at this, have you checked the startup performance impact? Thanks, David - Hi David, performance should not be a problem. The potentially costly thing is the underlying

Re: RFR: JDK-8256844: Make NMT late-initializable

Hi Thomas, On 26/07/2021 10:15 pm, Thomas Stuefe wrote: Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing. Before looking at this, have you checked the startup performance impact?

Re: JNI WeakGlobalRefs

Hi Hans, On 22/07/2021 7:54 am, Hans Boehm wrote: Is this an appropriate list to discuss JNI? No - hotspot-dev (to get runtime and GC folk) is the place to discuss JNI. Thanks, David I'm concerned that the current semantics of JNI WeakGlobalRefs are still dangerous in a very subtle way

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v4]

On Fri, 16 Jul 2021 14:38:35 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to >> fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the >> VM, and then afterwards did the same

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to >> fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the >> VM, and then afterwards did the same

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

On Thu, 15 Jul 2021 10:47:17 GMT, Jorn Vernee wrote: >> src/hotspot/share/prims/universalUpcallHandler.cpp line 121: >> >>> 119: } >>> 120: >>> 121: MACOS_AARCH64_ONLY(thread->enable_wx(WXExec)); >> >> Not clear why this is needed? JavaCallWrapper doesn't use it. > > I took this from

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v3]

On Thu, 15 Jul 2021 11:02:21 GMT, Jorn Vernee wrote: >> How does native code reach a safepoint polling point? > > The stack trace looks like this: > > > Current thread (0x02a2489f0b50): JavaThread "Thread-4551" > [_thread_in_Java, id=24920, stack(0x00d9e050,0x00d9e060)] >

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

On 15/07/2021 10:29 pm, Jorn Vernee wrote: On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes wrote: Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Assert frame is correct type in frame_data_for_frame src/hotspot/share/prims

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

On Fri, 25 Jun 2021 21:04:27 GMT, Jorn Vernee wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Assert frame is correct type in frame_data_for_frame > > src/hotspot/share/runtime/safepoint.cpp line 931: > >> 929:

Re: [jdk17] RFR: 8269240: java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC [v2]

On Tue, 13 Jul 2021 15:16:26 GMT, Jorn Vernee wrote: >> This patch rewrites the prologue and epilogue of panama upcalls, in order to >> fix the test failure from the title. >> >> Previously, we did a call to potentially attach the current thread to the >> VM, and then afterwards did the same

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible

On Mon, 5 Jul 2021 06:01:23 GMT, Yi Yang wrote: >> Class loading order is different to class initialization order. >> >> There are a lot more tests than just tier1. :) I don't expect many, if any, >> tests to be looking for a specific IOOBE message, and I can't see an easy >> way to find such

Re: [jdk17] RFR: 8269281: java/foreign/TestUpcall.java times out

On Thu, 1 Jul 2021 21:11:44 GMT, Maurizio Cimadamore wrote: > The previous fix to this test which used removed the `VerifyDependency` flag > worked well, but we're still observing rare timeouts. Looking at the test > reports, it seems likely that slightly increasing the timeout would do the

Re: [jdk17] RFR: 8269486: CallerAccessTest fails for non server variant

On 29/06/2021 12:52 am, Christoph Göttschkes wrote: On Mon, 28 Jun 2021 13:14:51 GMT, Christoph Göttschkes wrote: Hi, please review this small fix. The test case uses a custom launcher and before launching the JVM, it adds the "lib" and "lib/server" directories to the environment variable

Re: [jdk17] RFR: 8269486: CallerAccessTest fails for non server variant

On Mon, 28 Jun 2021 13:14:51 GMT, Christoph Göttschkes wrote: > Hi, > > please review this small fix. The test case uses a custom launcher and before > launching the JVM, it adds the "lib" and "lib/server" directories to the > environment variable which controls the native library search

Re: RFR: 8269384: Determine native byte order for StringUTF16 via ByteOrder

On Mon, 28 Jun 2021 03:25:09 GMT, Yi Yang wrote: >> Prefer using ByteOrder to compute byte order for StringUTF16 to determining >> byte order by native method StringUTF16.isBigEndian. > > Hi Aleksey, do you have a concrete issue/discussion about bootstrapping > problems? I don't see it because

Re: RFR: 8268276: Base64 Decoding optimization for x86 using AVX-512 [v7]

On Wed, 23 Jun 2021 00:31:55 GMT, Scott Gibbons wrote: >> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration. >> Also allows for performance improvement for non-AVX-512 enabled platforms. >> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to

Re: [jdk17] RFR: JDK-8266310: deadlock between System.loadLibrary and JNI FindClass loading another class

On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov wrote: > Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 > against JDK17. > > This fixes the deadlock in ClassLoader between the two lock objects - a lock > object associated with the class being loaded, and the >

Re: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails [v2]

Hi Jorn, On 17/06/2021 9:28 pm, Jorn Vernee wrote: On Thu, 17 Jun 2021 00:23:19 GMT, David Holmes wrote: Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Add comment about optimized entry frames only being generated on x86_64

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible

On 17/06/2021 8:50 pm, Alan Bateman wrote: On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes wrote: There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible

On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex > by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in > the whole JDK codebase. Class loading order is different to class initialization

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible

On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang wrote: > After JDK-8265518(#3615), it's possible to replace all variants of checkIndex > by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in > the whole JDK codebase. I skimmed through all these and the changes seem fine in

Re: [jdk17] RFR: 8268717: Upstream: 8268673: Stack walk across optimized entry frame on fresh native thread fails

On Wed, 16 Jun 2021 11:19:37 GMT, Jorn Vernee wrote: > Upstream a critical fix from the panama-foreign repo. > > See the prior review thread here: > https://github.com/openjdk/panama-foreign/pull/558 > > Testing: tier 1-2, local run of run-test-jdk_foreign. Hi Jorn, Seems okay but I have

Re: Windows aarch64 (build debug) constantly fails

On 11/06/2021 4:27 pm, Jaikiran Pai wrote: Hello David, On 11/06/21 11:41 am, David Holmes wrote: Hi, On 10/06/2021 8:58 pm, Сергей Цыпанов wrote: Hello, in the pipeline of my JDK fork the mentioned build step constantly fails even providing I modify only Java code I see this message

Re: Windows aarch64 (build debug) constantly fails

Hi, On 10/06/2021 8:58 pm, Сергей Цыпанов wrote: Hello, in the pipeline of my JDK fork the mentioned build step constantly fails even providing I modify only Java code I see this message in the log Compiling 2 files for BUILD_JVMTI_TOOLS LINK : fatal error LNK1104: cannot open file

Re: RFR: 8266791: Annotation property which is compiled as an array property but changed to a single element throws NullPointerException [v3]

On Wed, 9 Jun 2021 13:56:40 GMT, Rafael Winterhalter wrote: >> During annotation parsing, the parser assumes that a declared property is of >> an array type if the parsed annotation property is defined as an array. In >> this case, the component type is `null`, and a `NullPointerException` is

Re: RFR: 8267630: Start of release updates for JDK 18 [v6]

On Tue, 8 Jun 2021 17:58:43 GMT, Joe Darcy wrote: >> 8267630: Start of release updates for JDK 18 > > 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

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v6]

On Tue, 8 Jun 2021 16:53:38 GMT, Henry Jen wrote: >> …d on macOS >> >> This patch simply round up the specified stack size to multiple of the >> system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On >> MacOS, before the fix, running with

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5]

On 8/06/2021 11:40 pm, Thomas Stuefe wrote: On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote: …d on macOS This patch simply round up the specified stack size to multiple of the system page size. Test is trivial, simply run java with -Xss option against following code. On MacOS, before the

Re: RFR: 8268349: Provide more detail in JEP 411 warning messages

On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either > enabled at startup or installed at runtime. There are a number of hotspot tests that will trigger this warning, so please ensure they work correctly with the

Re: RFR: 8268227: java/foreign/TestUpcall.java still times out

On 8/06/2021 5:23 am, Daniel D.Daugherty wrote: On Fri, 4 Jun 2021 10:53:42 GMT, Maurizio Cimadamore wrote: Turns out that adding more timeout is a lost cause here. The root cause of the slowdown when running the test in debug build is: https://bugs.openjdk.java.net/browse/JDK-8266074

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5]

On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote: >> …d on macOS >> >> This patch simply round up the specified stack size to multiple of the >> system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On >> MacOS, before the fix, running with

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v5]

On Mon, 7 Jun 2021 03:22:18 GMT, Henry Jen wrote: > while some other Posix system might as explained in the man page What manpage? The POSIX specification for this does not allow for EINVAL being returned due to alignment issues. That is an extra constraint imposed by macOS and which makes

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS [v4]

On Sat, 5 Jun 2021 01:48:21 GMT, Henry Jen wrote: >> …d on macOS >> >> This patch simply round up the specified stack size to multiple of the >> system page size. >> >> Test is trivial, simply run java with -Xss option against following code. On >> MacOS, before the fix, running with

Re: RFR: 8195129: System.load() fails to load from unicode paths [v3]

On Fri, 4 Jun 2021 14:00:25 GMT, Maxim Kartashev wrote: >> Not an expert by my understanding is that the VM only deals with modified >> UTF-8, as does JNI. So the incoming string should be modified-UTF8 IMO and >> then converted to UTF16. >> >> That said, this is shared code being modified

Re: RFR: 8195129: System.load() fails to load from unicode paths [v3]

On Thu, 3 Jun 2021 17:48:59 GMT, Naoto Sato wrote: >> Right; I changed the code in NativeLibraries.c to pass down true UTF-8 >> instead of "modified UTF-8". Please, take a look. > > I am not sure we can pass non `modified UTF-8` through `JVM_LoadLibrary()`. > Probably some VM folks can

Re: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested

Hi Peter, On 3/06/2021 6:52 pm, Peter Levart wrote: On Thu, 3 Jun 2021 07:31:14 GMT, David Holmes wrote: The code is confusing because it gives no indication that it is aware that runtime invisible annotations could be present: /** * Parses the annotations described by the specified byte

Re: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested

On 3/06/2021 4:49 pm, Peter Levart wrote: On Wed, 2 Jun 2021 22:44:10 GMT, David Holmes wrote: I think this is not deliberate. Since `rawAnnotations` may end up having any of the following: - `RuntimeVisibleAnnotations` (when there were just `RUNTIME` annotation usages compiled

Re: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested

On 3/06/2021 2:54 am, Joe Darcy wrote: If the reflection runtime doesn't implement the semantics of -XX+PreserveAllAnnotations, I suggest deprecating/obsoleting/etc. that option now. I have to agree with Joe now. I mistakenly thought the raw annotation stream was exposed to some parts of

Re: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested

On 3/06/2021 1:38 am, Peter Levart wrote: On Wed, 2 Jun 2021 13:24:10 GMT, David Holmes wrote: Sorry now I see what happens. We aren't combining two arrays of annotations we're concatenating two streams of byes, each of which represents a set of annotations, starting with the length

Re: RFR: JDK-8268147: need to update reference to testng module for jtreg6

On Wed, 2 Jun 2021 22:22:22 GMT, Jonathan Gibbons wrote: > Please review a test fix to refer to the new name of the TestNG module. Looks good and trivial. Thanks, David - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4325

Re: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested

On 3/06/2021 12:39 am, Peter Levart wrote: On Wed, 2 Jun 2021 05:59:05 GMT, David Holmes wrote: Sorry Jaroslav but I don't really see this test as a basic functional test of the PreserveAllAnnotations flag. There is no need for any dynamic retention mode switch. All you need as I've said

Re: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested

Never mind ... On 2/06/2021 10:47 pm, David Holmes wrote: On 2/06/2021 10:17 pm, Peter Levart wrote: On Wed, 2 Jun 2021 11:40:13 GMT, Peter Levart wrote: ...hm, it seems that mere presence of any RUNTIME annotation that was RUNTIME already at the use compile time somehow affects -XX

Re: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested

On 2/06/2021 10:17 pm, Peter Levart wrote: On Wed, 2 Jun 2021 11:40:13 GMT, Peter Levart wrote: ...hm, it seems that mere presence of any RUNTIME annotation that was RUNTIME already at the use compile time somehow affects -XX:+PreserveAllAnnotations option so that now RUNTIME annotations

Re: RFR: JDK-8267936: PreserveAllAnnotations option isn't tested

On 2/06/2021 3:47 pm, Jaroslav Tulach wrote: On Tue, 1 Jun 2021 09:30:40 GMT, Jaroslav Tulach wrote: There doesn't seem to be much support for the complete changes in #4245. To get at least something useful from that endeavor I have extracted the test for existing behavior of

Re: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code

On 1/06/2021 4:20 am, Peter Levart wrote: On Mon, 31 May 2021 12:37:55 GMT, David Holmes wrote: That reads backwards to me. +PreserveAllAnnotations means that CLASS retention annotations are retained by the VM not just RUNTIME ones. So in that sense it might be a migration aid if moving from

Re: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2]

On 31/05/2021 8:29 pm, Peter Levart wrote: On Sun, 30 May 2021 20:06:49 GMT, Jaroslav Tulach wrote: My use-case relates to [@JavaScriptBody](https://bits.netbeans.org/html+java/1.7.1/net/java/html/js/package-summary.html) annotation used for Java/JavaScript interop. Originally all existing

Re: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code

On 31/05/2021 4:11 pm, Jaroslav Tulach wrote: On Sun, 30 May 2021 23:03:55 GMT, David Holmes wrote: But we should add in some tests. Right, I was surprised by missing tests as well. I've just created a _"standalone"_ commit 0f689ea that adds such test and also shows th

Re: RFR: 8266310: deadlock while loading the JNI code [v6]

On Thu, 27 May 2021 14:31:59 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the >> two lock objects - a lock object associated with the class being loaded, and >> the ClassLoader.loadedLibraryNames hash map, locked during the native >>

Re: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code

On 31/05/2021 4:44 am, Alan Bateman wrote: On Fri, 28 May 2021 12:56:39 GMT, Jaroslav Tulach wrote: This PR exposes runtime invisible annotations via `Class.getAnnotation` when `-XX:+PreserveAllAnnotations` option is passed to the JVM. Existing `-XX:+PreserveAllAnnotations` option can be

Re: RFR: JDK-8267936: PreserveAllAnnotations option doesn't expose the annotation to Java code [v2]

On Sun, 30 May 2021 19:56:52 GMT, Jaroslav Tulach wrote: >> This PR exposes runtime invisible annotations via `Class.getAnnotation` when >> `-XX:+PreserveAllAnnotations` option is passed to the JVM. >> >> Existing `-XX:+PreserveAllAnnotations` option can be very useful for code >> that needs

Re: RFR: 8236569: -Xss not multiple of 4K does not work for the main thread on macOS

On Fri, 28 May 2021 21:55:24 GMT, Henry Jen wrote: > …d on macOS > > This patch simply round up the specified stack size to multiple of the system > page size. > > Test is trivial, simply run java with -Xss option against following code. On > MacOS, before the fix, running with `-Xss159k`

Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]

On Thu, 27 May 2021 16:28:14 GMT, Maxim Kartashev wrote: >> src/hotspot/os/windows/os_windows.cpp line 1541: >> >>> 1539: void * os::dll_load(const char *utf8_name, char *ebuf, int ebuflen) { >>> 1540: LPWSTR utf16_name = NULL; >>> 1541: errno_t err = convert_UTF8_to_UTF16(utf8_name,

Re: RFR: 8267893: Improve EFH do get native/mixed stack traces for cores and live processes

On Thu, 27 May 2021 22:05:55 GMT, Leonid Mesnik wrote: > EFH is improved to process cores and get mixed stack traces with jhsdb and > native stack traces with gdb/lldb. It might be useful because hs_err doesn't > contain info about all threads, sometimes it is even not generated. Hi Leonid,

Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]

On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. >> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() >> or dlopen()) consume strings also in UTF8. On Windows, however, the >>

Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]

On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev wrote: >> Character strings within JVM are produced and consumed in several formats. >> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf() >> or dlopen()) consume strings also in UTF8. On Windows, however, the >>

Re: RFR: 8195129: System.load() fails to load from unicode paths [v2]

On 27/05/2021 6:59 am, Gerard Ziemski wrote: On Tue, 25 May 2021 09:45:34 GMT, Maxim Kartashev wrote: I tried verifying the test on **macOS** by running: `jtreg -nr -va -jdk:./build/macosx-x86_64-server-fastdebug/images/jdk test/hotspot/jtreg/runtime/jni/loadLibraryUnicode` and I get:

Re: RFR: 8266310: deadlock while loading the JNI code [v5]

On Fri, 21 May 2021 15:49:09 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the >> two lock objects - a lock object associated with the class being loaded, and >> the ClassLoader.loadedLibraryNames hash map, locked during the native >>

Re: RFR: 8266310: deadlock while loading the JNI code [v5]

On 25/05/2021 7:53 am, Aleksei Voitylov wrote: On Mon, 24 May 2021 06:24:15 GMT, David Holmes wrote: Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: fix whitespace src/java.base/share/classes/jdk/internal/loader

Re: RFR: 8266310: deadlock while loading the JNI code [v5]

On Fri, 21 May 2021 15:49:09 GMT, Aleksei Voitylov wrote: >> Please review this PR which fixes the deadlock in ClassLoader between the >> two lock objects - a lock object associated with the class being loaded, and >> the ClassLoader.loadedLibraryNames hash map, locked during the native >>

Re: RFR: 8266310: deadlock while loading the JNI code [v2]

vid - Regards, Peter On 5/20/21 12:31 AM, David Holmes wrote: On 20/05/2021 2:29 am, Aleksei Voitylov wrote: On Wed, 19 May 2021 16:21:41 GMT, Aleksei Voitylov wrote: Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associa

Re: RFR: 8266310: deadlock while loading the JNI code [v2]

NativeLibrary.load() to prevent any thread from locking while another thread loads a library. Before the update, there could be a class loading lock held by a parallel capable class loader, which can deadlock with the library loading lock. As proposed by David Holmes, the library loading lock

Re: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote: > Please review the test changes for [JEP > 411](https://openjdk.java.net/jeps/411). > > With JEP 411 and the default value of `-Djava.security.manager` becoming > `disallow`, tests calling `System.setSecurityManager()` need >

Re: RFR: 8266310: deadlock while loading the JNI code

On 14/05/2021 7:20 am, Mandy Chung wrote: On 5/13/21 6:05 AM, David Holmes wrote: Not every problem has a solution :) If JNI_OnLoad has to execute atomically with respect to loading a library then there will always be a deadlock potential. The only complete solution would not hold a lock

Re: RFR: 8266310: deadlock while loading the JNI code

Hi Aleksei, On 13/05/2021 9:54 pm, Aleksei Voitylov wrote: Hi David, On 12/05/2021 10:56, David Holmes wrote: Hi Aleksei, On 11/05/2021 11:19 pm, Aleksei Voitylov wrote: Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass [v4]

On Wed, 12 May 2021 16:10:24 GMT, Harold Seigel wrote: >> Please review this large change to remove Unsafe::defineAnonymousClass(). >> The change removes dAC relevant code and changes a lot of tests. Many of >> the changed tests need renaming. I hope to do this in a follow up RFE. >> Some

Re: RFR: 8266310: deadlock while loading the JNI code

Hi Aleksei, On 11/05/2021 11:19 pm, Aleksei Voitylov wrote: Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 08:46:15 GMT, Vyom Tewari wrote: > Original fix was intended to Linux specific. Current Fix will not impact > other platforms. Your original fix failed to be Linux specific, so given you never actually tested it on other platforms you don't know whether another part of the

Re: RFR: JDK-8266797: Fix for 8266610 breaks the build on macos

On Mon, 10 May 2021 06:34:36 GMT, Vyom Tewari wrote: > this change will include the below headers files to Linux only. > #include > #include Hi Vyom, That fixes the include file problem but as this was obviously not tested on non-Linux have you checked that the rest of the fix for

Re: RFR: 8266610: Method RandomAccessFile#length() returns 0 for block devices on linux. [v2]

On Mon, 10 May 2021 03:48:43 GMT, Vyom Tewari wrote: >>> Could required os = linux added for >>> test/jdk/java/nio/channels/FileChannel/BlockDeviceSize.java? As it is >>> decribed only run as linux. >> >> Yes, good idea. Also maybe we can see about changing it to avoid the >> dependency on

Re: Expected behavior for annotation property with duplicate value definition

return that value and there is nothing at all to tell it that anything might have been amiss in the original classfile. David - Best regards, Rafael Am Mi., 5. Mai 2021 um 11:55 Uhr schrieb David Holmes mailto:david.hol...@oracle.com>>: Hi Rafael, On 5/05/2021 6:

Re: Expected behavior for annotation property with duplicate value definition

Hi Rafael, On 5/05/2021 6:53 pm, Rafael Winterhalter wrote: Hello, I was wondering if the current OpenJDK behavior should yield an exception or if it is accidental and if so, if it should be altered to avoid surprising behavior. If an annotation: @interface Sample { String v(); } is added

Re: RFR: 8266173: -Wmaybe-uninitialized happens in jni_util.c

On Wed, 28 Apr 2021 01:20:24 GMT, Yasumasa Suenaga wrote: > We can see compiler warnings in jni_util.c as following on GCC 11. `buf` > should be initialized. Seems ok. src/java.base/share/native/libjava/jni_util.c line 465: > 463: { > 464: int len = (int)strlen(str); > 465: jchar

Re: jpackage bugs

Hi Michael, On 17/04/2021 10:57 am, Michael Hall wrote: Is there anyway to get a simple/test reference type application available that could be used in reproducing bugs? I had two I think potentially serious bugs that were basically not addressed for problems in reproducing. JDK-8263156 :

Re: 8252827: Caching Integer.toString just like Integer.valueOf

On 17/04/2021 4:54 am, Raffaello Giulietti wrote: I guess the reporter meant to limit the cache range similarly to the one used for valueOf(). I have no clue about the benefit/cost ratio for the proposed String cache. It really depends on usage, workload, etc. One can easily imagine both

Re: RFR: 8260517: implement Sealed Classes as a standard feature in Java [v2]

On Fri, 16 Apr 2021 02:11:10 GMT, Vicente Romero wrote: >> Please review this PR that intents to make sealed classes a final feature in >> Java. This PR contains compiler and VM changes. In line with similar PRs, >> which has made preview features final, this one is mostly removing preview >>

Re: RFR: 8265173: [test] divert spurious log output away from stream under test in ProcessBuilder Basic test

On Wed, 14 Apr 2021 14:08:50 GMT, Roger Riggs wrote: > The most recent intermittent failure showed that the error occurred during VM > initialization. > Only the tty output was diverted, but not log output. > Add diversion of log output as well tty output. > > Add `-Xlog:all=warning:stderr`

Re: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related >> to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module — the `jaotc` tool >> - `src/hotspot/share/aot` — loads AoT compiled code into VM for

Re: RFR: 8166727: javac crashed: [jimage.dll+0x1942] ImageStrings::find+0x28

On 4/04/2021 12:02 am, Jim Laskey wrote: Is it in bad form to declare a #define CLOSE_JIMAGE 0 ? Still dead code. This is a core-libs style call anyway. Cheers, David  On Apr 3, 2021, at 9:49 AM, David Holmes wrote: On 2/04/2021 5:34 pm, Alan Bateman wrote: On Thu, 1 Apr 2021 18:48

Re: RFR: 8166727: javac crashed: [jimage.dll+0x1942] ImageStrings::find+0x28

On 2/04/2021 5:34 pm, Alan Bateman wrote: On Thu, 1 Apr 2021 18:48:15 GMT, Jim Laskey wrote: src/java.base/share/native/libjimage/imageFile.cpp line 219: 217: // WARNING: Should never close the jimage file. 218: // Threads may still be running at shutdown. 219: #if 0 Are you

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