Re: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths [v4]

2023-09-21 Thread Alan Bateman
On Thu, 21 Sep 2023 00:46:45 GMT, Brian Burkhalter wrote: > Support for `isAbsolute` was added. Okay, this looks better but I'm still concerned about other potential inconsistencies. Can you try out getParent with different input to see if any issues come up related to the prefix length.

Re: RFR: 8316540: StoreReproducibilityTest fails on some locales [v2]

2023-09-21 Thread Alan Bateman
On Wed, 20 Sep 2023 16:12:36 GMT, Naoto Sato wrote: >> Fixing a test case that fails in some time zones. Making sure the test is >> run in `UTC` zone will fix the issue. Confirmed the fix by manually setting >> machine's time zone to Europe/Dublin. > > Naoto Sato has updated the pull request

Re: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths [v3]

2023-09-20 Thread Alan Bateman
On Wed, 20 Sep 2023 18:47:33 GMT, Brian Burkhalter wrote: > > File::isAbsolute, it looks like it will return true for input like > > `\\\?\\foo` but it will be treated by toAbsolutePath as a relative path. > > Right on: Ideally the prefix would be removed at the front door, meaning when

Re: RFR: 8315869: UseHeavyMonitors not used [v2]

2023-09-20 Thread Alan Bateman
On Wed, 20 Sep 2023 18:00:40 GMT, Coleen Phillimore wrote: >> Please review this trivial change to remove the UseHeavyMonitors develop >> option, in favor of the now non-experimental LockingMode=LM_MONITOR (0) >> option. Tested with tier1 locally. > > Coleen Phillimore has updated the pull

Re: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths [v3]

2023-09-20 Thread Alan Bateman
On Wed, 20 Sep 2023 18:10:17 GMT, Brian Burkhalter wrote: >> In the Windows implementation of java.io.File.getCanonicalPath, strip any >> long path or UNC prefix before canonicalizing the remainder of the pathname. > > Brian Burkhalter has updated the pull request incrementally with one >

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v6]

2023-09-20 Thread Alan Bateman
On Wed, 20 Sep 2023 11:21:51 GMT, Daniel Fuchs wrote: > Thanks Tim. Should 8308995 be listed in the `@bug` clause of these two tests? I don't think so as these tests are just used to check that changes haven't broken anything. - PR Comment:

Re: RFR: 8316000: File.setExecutable silently fails if file does not exist [v3]

2023-09-20 Thread Alan Bateman
On Tue, 19 Sep 2023 22:48:20 GMT, Brian Burkhalter wrote: >> On Windows, do not return `true` from the `java.io.File` methods >> `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the >> file does not exist. > > Brian Burkhalter has updated the pull request incrementally

Re: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths [v2]

2023-09-20 Thread Alan Bateman
On Wed, 20 Sep 2023 02:14:48 GMT, Brian Burkhalter wrote: > It could be that if after stripping the `\\\?\` prefix the result is relative > or drive-relative, then it should first be resolved in the same way before > proceeding. Right, which is why the one-arg WinNTFileSystem.resolve may be

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v3]

2023-09-19 Thread Alan Bateman
On Thu, 10 Aug 2023 17:21:31 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a "jmodless" jlink mode to the JDK. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >> install might not come with the packaged modules (directory `jmods`). This >>

Re: Should we build jrt-fs.jar again with the "Build JDK" ?

2023-09-19 Thread Alan Bateman
On 18/09/2023 14:51, Andrew Leonard wrote: Thanks for the clarification Alan. To ensure the reproducibility of the whole JDK image regardless of the specific bootjdk used, would it make sense once the "Build JDK" has been built, we re-build jrt-fs.jar again using the "Build JDK" ? Thus

Integrated: 8312498: Thread::getState and JVM TI GetThreadState should return TIMED_WAITING virtual thread is timed parked

2023-09-19 Thread Alan Bateman
On Fri, 21 Jul 2023 18:01:45 GMT, Alan Bateman wrote: > Thread::getState is an API for monitoring and management purposes to report > the thread state. If a virtual thread is parked with LockSupport.parkNanos, > its state is reported as WAITING when it should be TIMED_WAITIN

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]

2023-09-19 Thread Alan Bateman
On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote: >>> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling >>> https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event >>> generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, >>> event

Re: RFR: 8312498: Thread::getState and JVM TI GetThreadState should return TIMED_WAITING virtual thread is timed parked [v4]

2023-09-19 Thread Alan Bateman
ange is straight-forward with additional state for > timed-parking/parked/pinned. The existing virtual/ThreadAPI.java test is > expanded to this scenario. A new test is added for JVM TI GetThreadState to > test waiting/timed-waited cases (including pinned) as test coverage seems > pat

Re: RFR: 8316433: net.dll should delay load winhttp.dll

2023-09-19 Thread Alan Bateman
On Mon, 18 Sep 2023 17:30:25 GMT, Daniel Jeliński wrote: > WinHTTP functions are only used when an application: > - uses DefaultProxySelector to resolve proxies, and > - is run with -Djava.net.useSystemProxies=true > > In all other cases, loading winhttp.dll is a waste of resources. > >

Re: RFR: 8312498: Thread::getState and JVM TI GetThreadState should return TIMED_WAITING virtual thread is timed parked [v3]

2023-09-17 Thread Alan Bateman
On Mon, 18 Sep 2023 01:44:10 GMT, David Holmes wrote: > Surely that is not a specified exported thread state though ?? Why would we > care about PINNED (timed or otherwise) in the current context? There are internal states and then mappings to the thread states defined by the APIs

Re: RFR: 8316000: File.setExecutable silently fails if file does not exist

2023-09-15 Thread Alan Bateman
On Thu, 14 Sep 2023 18:03:48 GMT, Brian Burkhalter wrote: > If this code does not interact with ACL-based security, then it's not clear > to me that there's anything to be done here. Right, these methods were created with POSIX file permissions in mind. On the surface, the only result it can

Integrated: 8316160: Remove sun.misc.Unsafe.{shouldBeInitialized,ensureClassInitialized}

2023-09-15 Thread Alan Bateman
On Wed, 13 Sep 2023 09:50:35 GMT, Alan Bateman wrote: > Unsafe.{shouldBeInitialized,ensureClassInitialized} are deprecated for > removal since JDK 15. It's time to remove them. > Lookup.ensureInitialized(Class) was added in Java 15 as a standard API to > ensure that an acce

Re: Should we build jrt-fs.jar again with the "Build JDK" ?

2023-09-15 Thread Alan Bateman
On 15/09/2023 09:09, Andrew Leonard wrote: Hi, jrt-fs.jar is the only jar that is not built (or re-built) with the "Build JDK", and I was wondering why? The JAR file contains the "jrt" file system provider for the runtime.  IDE or other tools running on JDK 8/11/etc. need to be able to

Re: RFR: 8312498: Thread::getState and JVM TI GetThreadState should return TIMED_WAITING virtual thread is timed parked [v3]

2023-09-15 Thread Alan Bateman
On Fri, 15 Sep 2023 00:36:10 GMT, David Holmes wrote: > What is TIMED PINNING? LockSupport.parkNanos when the carrier can't be released due to monitor or native frame. - PR Review Comment: https://git.openjdk.org/jdk/pull/14978#discussion_r1326860516

Re: RFR: 8312498: Thread::getState and JVM TI GetThreadState should return TIMED_WAITING virtual thread is timed parked [v3]

2023-09-14 Thread Alan Bateman
On Thu, 27 Jul 2023 01:54:58 GMT, Serguei Spitsyn wrote: > Looks good. > Thanks, > Serguei Thanks Serguei. I had to pause this to work on other things. When I sync'ed up the branch I found I had to update recently introduced test jvmti/vthread/VThreadEventTest/VThreadEventTest.java as it was

Re: RFR: 8312498: Thread::getState and JVM TI GetThreadState should return TIMED_WAITING virtual thread is timed parked [v3]

2023-09-14 Thread Alan Bateman
On Wed, 26 Jul 2023 12:18:02 GMT, David Holmes wrote: > Yes but TIMED and SUSPENDED are not alike. I assume SUSPENDED is a > stand-alone bit because you can be in various states and suspended at the > same time. But TIMED isn't like that. The SUSPENDED bit can only be set when the virtual

Re: RFR: 8312498: Thread::getState and JVM TI GetThreadState should return TIMED_WAITING virtual thread is timed parked [v3]

2023-09-14 Thread Alan Bateman
ange is straight-forward with additional state for > timed-parking/parked/pinned. The existing virtual/ThreadAPI.java test is > expanded to this scenario. A new test is added for JVM TI GetThreadState to > test waiting/timed-waited cases (including pinned) as test coverage seems > pat

RFR: 8316160: Remove sun.misc.Unsafe.{shouldBeInitialized,ensureClassInitialized}

2023-09-14 Thread Alan Bateman
Unsafe.{shouldBeInitialized,ensureClassInitialized} are deprecated for removal since JDK 15. It's time to remove them. Lookup.ensureInitialized(Class) was added in Java 15 as a standard API to ensure that an accessible class is initialized. A search of 175973022 classes in 484751 artifacts

Re: RFR: 8312498: Thread::getState and JVM TI GetThreadState should return TIMED_WAITING virtual thread is timed parked [v2]

2023-09-12 Thread Alan Bateman
raight-forward, it's just additional bit to indicate that the > parking/parked/pinned states are timed. The existing virtual/ThreadAPI.java > test is expanded to this scenario. A new test is added for JVM TI > GetThreadState to test waiting/timed-waited cases (including pinned) as test > c

Integrated: 8315938: Deprecate for removal Unsafe methods that have standard APIs for many releases

2023-09-12 Thread Alan Bateman
On Fri, 8 Sep 2023 15:54:05 GMT, Alan Bateman wrote: > There are several methods defined by sun.misc.Unsafe that have standard API > equivalents for many years and releases. The change proposed here is to > deprecate, for removal, the park, unpark, getLoadAverage, loadFence, >

Re: RFR: 8316000: File.setExecutable silently fails if file does not exist

2023-09-12 Thread Alan Bateman
On Tue, 12 Sep 2023 01:36:34 GMT, Brian Burkhalter wrote: >> On Windows, do not return `true` from the `java.io.File` methods >> `setReadable(boolean, boolean)` and `setExecutable(boolean, boolean)` if the >> file does not exist. > > src/java.base/windows/native/libjava/WinNTFileSystem_md.c

Re: RFR: 8315938: Deprecate for removal Unsafe methods that have standard APIs for many releases

2023-09-11 Thread Alan Bateman
On Mon, 11 Sep 2023 06:31:33 GMT, Per Minborg wrote: > Currently, all deprecated methods of `Unsafe` are at the end of the file. Are you looking at the internal Unsafe, rather than sun.misc.Unsafe? This PR is sun.misc.Unsafe only. Previous deprecation didn't re-order the methods. With

Integrated: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

2023-09-10 Thread Alan Bateman
On Wed, 30 Aug 2023 13:56:42 GMT, Alan Bateman wrote: > In the virtual thread implementation, thread identity switches to the carrier > before freezing and switches back to the virtual thread after thawing. This > was a forced move due to issues getting JVMTI to work with virtua

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v2]

2023-09-09 Thread Alan Bateman
On Wed, 6 Sep 2023 05:01:38 GMT, Serguei Spitsyn wrote: > The fix looks okay to me. From JVMTI point of view this transition is hidden, > so no inconsistency can be observed. However, I wonder if the > AsyncGetStackTraces may have similar issue as the JFR had. Unfortunately we > do not have

Re: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths [v2]

2023-09-09 Thread Alan Bateman
On Fri, 8 Sep 2023 01:07:17 GMT, Brian Burkhalter wrote: >> In the Windows implementation of java.io.File.getCanonicalPath, strip any >> long path or UNC prefix before canonicalizing the remainder of the pathname. > > Brian Burkhalter has updated the pull request incrementally with one >

Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2]

2023-09-09 Thread Alan Bateman
On Fri, 8 Sep 2023 18:45:02 GMT, Brent Christian wrote: > I would also like to see what a FileChannel implementation looks like. Am I > right that this would allow the `prefs` native library to be removed entirely? Yes. FileChannel.open can be called with the file permissions to atomically set

RFR: 8315938: Deprecate for removal Unsafe methods that have standard APIs for many releases

2023-09-08 Thread Alan Bateman
There are several methods defined by sun.misc.Unsafe that have standard API equivalents for many years and releases. The change proposed here is to deprecate, for removal, the park, unpark, getLoadAverage, loadFence, storeFence, and fullFence methods. Code using these methods should move to

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v4]

2023-09-08 Thread Alan Bateman
JFR thread sampler to skip sampling when > it samples during a transition. > > Testing: tier1-5 Alan Bateman 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 reque

Re: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths [v2]

2023-09-08 Thread Alan Bateman
On Fri, 8 Sep 2023 01:07:17 GMT, Brian Burkhalter wrote: >> In the Windows implementation of java.io.File.getCanonicalPath, strip any >> long path or UNC prefix before canonicalizing the remainder of the pathname. > > Brian Burkhalter has updated the pull request incrementally with one >

Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2]

2023-09-08 Thread Alan Bateman
On Fri, 8 Sep 2023 07:44:21 GMT, Matthias Baesken wrote: > We could do this mid-term in some follow up action. It shouldn't be hard to try it. If it works out then it would mean this old crufty code goes away and the JDK is in a better place. If it doesn't work out then the a plan B would be

Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2]

2023-09-08 Thread Alan Bateman
On Mon, 4 Sep 2023 11:57:47 GMT, Matthias Baesken wrote: >>> Hi Alan , Your assumption 'I assume the use of System.getProperty is >>> problematic when running with a SM.' is most likely correct. >> >> You'll need to test with a SM that denies reading the system property to be >> sure. There

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v33]

2023-09-07 Thread Alan Bateman
On Thu, 31 Aug 2023 21:31:40 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays.

Re: RFR: 8287843: File::getCanonicalFile doesn't work for \?\C:\ style paths DOS device paths

2023-09-07 Thread Alan Bateman
On Wed, 6 Sep 2023 21:38:39 GMT, Brian Burkhalter wrote: > In the Windows implementation of java.io.File.getCanonicalPath, strip any > long path or UNC prefix before canonicalizing the remainder of the pathname. Would it be possible to summarise how this behaves when File just presents this

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]

2023-09-07 Thread Alan Bateman
On Wed, 6 Sep 2023 15:55:21 GMT, Tim Prinzing wrote: > I think it's useful if trying to trace the calls (i.e. set to 0ms). > Apparently the security manager was being used for that by some. The SM isn't called once connected so I don't think anyone could have every done that. Yes, you could

Re: Question on why sun.management MBeans are not exported?

2023-09-06 Thread Alan Bateman
On 06/09/2023 16:17, Volker Simonis wrote: : I'm familiar with JEP 260. But wouldn't you agree that an "encapsulated" monitoring API is an oxymoron? A monitoring API is by design intended for external usage and completely useless to the platform itself. There's no single usage of the

Re: RFR: 8267174: Many test files have the wrong Copyright header

2023-09-06 Thread Alan Bateman
On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer wrote: > > I wonder if this is the right thing to do for the hprof files. I believe > > they originated from some hprof tools that we no longer ship. 3rd parties > > might choose to integrate them into their own tools. > > Do you think I should

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v3]

2023-09-06 Thread Alan Bateman
JFR thread sampler to skip sampling when > it samples during a transition. > > Testing: tier1-5 Alan Bateman 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 requ

Re: Question on why sun.management MBeans are not exported?

2023-09-06 Thread Alan Bateman
On 06/09/2023 14:02, Volker Simonis wrote: : I wonder why "sun.management" was encapsulated in the first place? I understand that it is not an "officially supported" API, but I find it still quite useful. sun.management.* is JDK internal so not something for code outside the JDK to use

Re: RFR: JDK-8315706: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java real fix for failure on AIX

2023-09-06 Thread Alan Bateman
On Wed, 6 Sep 2023 08:18:45 GMT, JoKern65 wrote: > After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , > the following test started to fail on AIX : > com/sun/tools/attach/warnings/DynamicLoadWarningTest.java; > The problem was described in >

Re: RFR: 8267174: Many test files have the wrong Copyright header

2023-09-06 Thread Alan Bateman
On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons wrote: > One has to wonder about the `**/*_OLD.java` files, but that would be a > different cleanup The IBM double byte charsets were re-implemented in JDK 7. I think the old implementations moved to the test tree so it could be used to test

Re: RFR: 8233160: Add java.vendor.url.bug to list of recognized standard system properties

2023-09-04 Thread Alan Bateman
On Fri, 1 Sep 2023 14:59:19 GMT, Jaikiran Pai wrote: > I asked for Mark's and Joe's inputs on this in the linked JBS issue > https://bugs.openjdk.org/browse/JDK-8233160. Mark has suggested that we keep > this `java.vendor.url.bug` system property non-optional and also not to add > any

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v2]

2023-09-04 Thread Alan Bateman
On Fri, 1 Sep 2023 11:32:45 GMT, Markus Grönlund wrote: >> Thanks. One other thing that I see when more testing with generational ZGC >> is that ZPageAllocator::alloc_page will record an event and this can happen >> during a mount transition. So I think JfrStackTrace::record also needs to >>

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing [v2]

2023-09-04 Thread Alan Bateman
JFR thread sampler to skip sampling when > it samples during a transition. > > Testing: tier1-5 Alan Bateman 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 reque

Re: RFR: 8306632: Add a JDK Property for specifying DTD support

2023-09-02 Thread Alan Bateman
On Fri, 28 Jul 2023 18:41:48 GMT, Joe Wang wrote: > Add a JDK Impl specific property 'jdk.xml.dtd.support' for applications to > specify how DTDs are handled. This property is uniformly supported across the > JDK XML libraries. It complements, rather than replaces, the existing > properties

Re: RFR: 8315558: Undocumented exceptions in java.text.StringCharacterIterator

2023-09-02 Thread Alan Bateman
On Fri, 1 Sep 2023 23:12:28 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315558) > which is a conformance change to document some exceptions in the > specification of java.text.StringCharacterIterator. @justin-curtis-lu You are correct that it

Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2]

2023-09-01 Thread Alan Bateman
On Fri, 1 Sep 2023 13:10:19 GMT, Matthias Baesken wrote: > Hi Alan , Your assumption 'I assume the use of System.getProperty is > problematic when running with a SM.' is most likely correct. You'll need to test with a SM that denies reading the system property to be sure. There are classes in

Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock. [v2]

2023-09-01 Thread Alan Bateman
On Fri, 1 Sep 2023 12:36:28 GMT, Matthias Baesken wrote: >> We run into some BackingStoreException: Couldn't get file lock. e.g. here : >> >> [JShell] Exception in thread "main" java.lang.IllegalStateException: >> java.util.prefs.BackingStoreException: Couldn't get file lock. >> [JShell] at

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

2023-09-01 Thread Alan Bateman
On Fri, 1 Sep 2023 10:47:25 GMT, Markus Grönlund wrote: >> Just to add that Patricio suggested today to run the stress tests with >> -Xint and that does lead to triggering the assert quickly when the thread is >> sampled in native. There are several native methods that are >>

Re: RFR: 8315004: Runtime.halt() debug logging

2023-09-01 Thread Alan Bateman
On Fri, 25 Aug 2023 09:49:20 GMT, Alan Bateman wrote: >> I want to add a log output similar to JDK-8301627 to Runtime.halt(). >> To avoid double logging of Runtime.exit(), add a flag to indicate whether >> logging was done, and fix it so that logging is done only once. >&

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v9]

2023-09-01 Thread Alan Bateman
On Thu, 31 Aug 2023 17:09:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v9]

2023-09-01 Thread Alan Bateman
On Thu, 31 Aug 2023 14:29:41 GMT, iaroslavski wrote: > Alan, you mentioned that DualPivotQuicksort will need detailed review. Can we > go ahead and start reviewing? Laurent checked performance, JMH results look > fine. As before, I think the main question with this change is whether adding

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

2023-08-31 Thread Alan Bateman
On Thu, 31 Aug 2023 17:31:34 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 415: >> >>> 413: } else { >>> 414: assert(NATIVE_SAMPLE == type, "invariant"); >>> 415: if (thread_state_in_native(thread) && >>>

Re: RFR: 8313983: jmod create --target-platform should replace existing ModuleTarget attribute

2023-08-31 Thread Alan Bateman
On Thu, 31 Aug 2023 12:13:40 GMT, Adam Sotona wrote: > ModuleTarget and ModuleResolution attributes were flagged as 'allow multiple' > in the Classfile API. > This patch removed the flags and allows at most one instance of each > attribute. > > Please review. > > Thanks, > Adam Thanks for

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

2023-08-31 Thread Alan Bateman
On Thu, 31 Aug 2023 10:38:32 GMT, Markus Grönlund wrote: >> In the virtual thread implementation, thread identity switches to the >> carrier before freezing and switches back to the virtual thread after >> thawing. This was a forced move due to issues getting JVMTI to work with >> virtual

Re: RFR: 8233160: Add java.vendor.url.bug to list of recognized standard system properties

2023-08-31 Thread Alan Bateman
On Thu, 31 Aug 2023 06:53:45 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address > https://bugs.openjdk.org/browse/JDK-8233160? > > It has been noted in https://bugs.openjdk.org/browse/JDK-8232753 that: > >> The java.vendor.url.bug property has been

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8]

2023-08-31 Thread Alan Bateman
On Wed, 30 Aug 2023 16:29:31 GMT, Mandy Chung wrote: > Indeed, Set.of factory methods are easy to use. I'm okay with taking it out. It would be easy to add in the future if needed, say if more options were introduced and the common case requires 2 or more options. - PR Comment:

RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

2023-08-31 Thread Alan Bateman
In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the

Re: RFR: 8315097: Rename createJavaProcessBuilder [v3]

2023-08-31 Thread Alan Bateman
On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson wrote: > I wouldn't be opposed to a change that: > > * Keeps the `createJavaProcessBuilder` name > * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts` > * Renames `executeTestJvm` to `executeJavaPrependTestOpts` > * Removes

Re: RFR: 8315413: Remove special filtering of Continuation.yield0 in StackWalker

2023-08-31 Thread Alan Bateman
On Wed, 30 Aug 2023 20:57:43 GMT, Mandy Chung wrote: > Loom added a special filtering of Continuation.yield0 in stack walker. After > the initial implementation, JDK-8304919 marks the yielding and entering > methods with `@Hidden` and hidden frames are filtered by stack walker by > default.

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8]

2023-08-30 Thread Alan Bateman
On Wed, 30 Aug 2023 15:03:27 GMT, Daniel Fuchs wrote: >> Mandy Chung has updated the pull request incrementally with three additional >> commits since the last revision: >> >> - update mode to be int rather than long >> - update tests >> - Review feedback on javadoc > >

Re: RFR: JDK-8314194: Reusing CyclicBarrier, it should be possible to change the barrierCommand

2023-08-30 Thread Alan Bateman
On Wed, 30 Aug 2023 12:02:12 GMT, chenggwang wrote: > Hi Can anyone help me to review this PR @sormuras @asotona or any other > reviewer? I think you first need to make a case for changing the CyclicBarrier API as opposed to dealing with the phases in your BarrierAction or using the Phaser

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]

2023-08-30 Thread Alan Bateman
On Wed, 30 Aug 2023 00:37:26 GMT, Srinivas Vamsi Parasa wrote: > Hi Vladimir, Just verified that the test/jdk/java/util/Arrays/Sorting.java is > triggering the intrinsic without additional flags Just to add that Sorting.java has short and long run modes. The default when running with jtreg

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v8]

2023-08-30 Thread Alan Bateman
On Tue, 29 Aug 2023 20:51:56 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per

Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]

2023-08-29 Thread Alan Bateman
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays.

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v3]

2023-08-29 Thread Alan Bateman
On Tue, 29 Aug 2023 12:35:19 GMT, Severin Gehwolf wrote: > @AlanBateman Gentle ping. On my list, it's a lot to get through and a number of aspects to this that I think will require refinement and discussion. - PR Comment:

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7]

2023-08-29 Thread Alan Bateman
On Tue, 29 Aug 2023 16:59:22 GMT, Daniel Fuchs wrote: >> how about "s/filtering/excluding"? > > Yes - that's better. The example use filter so it might be better to have the text use the same word, up to you, I think "filtering out known implementation classes" works too. - PR

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v7]

2023-08-29 Thread Alan Bateman
On Tue, 29 Aug 2023 00:16:40 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per

Re: RFR: 8315117: Update Zlib Data Compression Library to Version 1.3

2023-08-29 Thread Alan Bateman
On Mon, 28 Aug 2023 16:31:06 GMT, Lance Andersen wrote: > Hi all, > > Please review this PR which updates zlib from 1.2.13 to 1.3 in openJDK > > The [Zlib Data Compression Library](https://github.com/madler/zlib ) has > released Zlib 1.3 on August 18, 2023. > > There are a [small number of

Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock.

2023-08-29 Thread Alan Bateman
On Mon, 28 Aug 2023 07:28:48 GMT, Matthias Baesken wrote: > Hi Alan , when adding the test group sun/tools/jhsdb in TEST.root to the > exclusiveAccess.dirs , I cannot see the error any more. So it seems your > suggestions is correct . My command was actually wondering why we didn't have a

Re: RFR: 8315117: Update Zlib Data Compression Library to Version 1.3

2023-08-28 Thread Alan Bateman
On Mon, 28 Aug 2023 17:15:36 GMT, Lance Andersen wrote: > It was a clean copy(which I have been able to do as of zlib 1.2.13). Sorry I > should have mentioned this in the PR request That's okay, I just wanted to check to be sure that the ChangeLog_java (renamed adler32.c -> zadler32.c, crc32c

Re: RFR: 8315117: Update Zlib Data Compression Library to Version 1.3

2023-08-28 Thread Alan Bateman
On Mon, 28 Aug 2023 16:31:06 GMT, Lance Andersen wrote: > Hi all, > > Please review this PR which updates zlib from 1.2.13 to 1.3 in openJDK > > The [Zlib Data Compression Library](https://github.com/madler/zlib ) has > released Zlib 1.3 on August 18, 2023. > > There are a [small number of

Re: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes issues in GraalVM

2023-08-28 Thread Alan Bateman
On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman wrote: >>> Something fishy here, is this working around a bug in GraaVM native image >>> or why does this change need to be in JDK? >> >> I've now realized that the bug had an incorrect statement in the >>

Re: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v6]

2023-08-28 Thread Alan Bateman
On Fri, 25 Aug 2023 07:04:50 GMT, Vladimir Petko wrote: >> 8314491: Linux: jexec launched via PATH fails to find java > > Vladimir Petko 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

Re: yield return based on Coroutines

2023-08-28 Thread Alan Bateman
This looks fun! It's probably best to bring this to loom-dev. In its archives you'll find several discussions about generators as several people have been interested in that topic. Even when thread confined, the main concern has been that exotic control flow yields leads to surprising

Re: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load operations done by the JDK codebase

2023-08-26 Thread Alan Bateman
On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken wrote: > yes this is of course AIX specific. However I found something that might be > similar on Windows, there we have in case of successful LoadLibrary in > os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not >

Re: CFV: New Core Libraries Group Member: Michael McMahon

2023-08-26 Thread Alan Bateman
Vote: yes

Re: CFV: New Core Libraries Group Member: Lance Andersen

2023-08-26 Thread Alan Bateman
Vote: yes

Re: CFV: New Core Libraries Group Member: Daniel Fuchs

2023-08-26 Thread Alan Bateman
Vote: yes

Re: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes issues in GraalVM

2023-08-25 Thread Alan Bateman
On Thu, 24 Aug 2023 14:39:18 GMT, Severin Gehwolf wrote: > I've now realized that the bug had an incorrect statement in the description. > The cycle happens due to the `Runtime.getRuntime().maxMemory()` > implementation in GraalVM to use JDK `Metrics`, since the `ByteBuffer` [code > relies on

Re: RFR: 8315004: Runtime.halt() debug logging

2023-08-25 Thread Alan Bateman
On Fri, 25 Aug 2023 09:37:47 GMT, Masanori Yano wrote: > I want to add a log output similar to JDK-8301627 to Runtime.halt(). > To avoid double logging of Runtime.exit(), add a flag to indicate whether > logging was done, and fix it so that logging is done only once. > Could someone please

Integrated: 8314759: VirtualThread.parkNanos timeout adjustment when pinned should be replaced

2023-08-24 Thread Alan Bateman
On Wed, 23 Aug 2023 16:41:23 GMT, Alan Bateman wrote: > If yielding fails due to the pinning then VirtualThread.parkNanos parks on > the carrier thread with the remaining time. The calculation of the remaining > time needs to be replaced so that it obviously uses the differenc

Re: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes issues in GraalVM

2023-08-24 Thread Alan Bateman
On Thu, 24 Aug 2023 13:16:16 GMT, Severin Gehwolf wrote: > Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part > of the > JDK's Metrics API. The primary motivating factor is that it allows one to use > the > JDK's version of `Metrics` in GraalVM. See the bug for

Re: RFR: 8314759: VirtualThread.parkNanos timeout adjustment when pinned should be replaced

2023-08-24 Thread Alan Bateman
On Thu, 24 Aug 2023 11:55:20 GMT, Daniel Fuchs wrote: > Although... what happens if parkOnCarrierThread is called with a negative > value (as that could happen here)? Not an issue, nothing has changed there. - PR Comment:

RFR: 8314759: VirtualThread.parkNanos timeout adjustment when pinned should be replaced

2023-08-24 Thread Alan Bateman
If yielding fails due to the pinning then VirtualThread.parkNanos parks on the carrier thread with the remaining time. The calculation of the remaining time needs to be replaced so that it obviously uses the difference between the start and end time in the calculation. The current code isn't

Re: RFR: 4799358: BufferOutputStream.write() should immediately throw IOExcept on closed stream [v2]

2023-08-24 Thread Alan Bateman
On Thu, 24 Aug 2023 04:24:21 GMT, Vyom Tewari wrote: > I am unable to understand how proposed change breaks longstanding > behavior(what behavior). With current implementation if the underline stream > is closed ‘BufferedOutputStream.write’ will throw IOException when the > internal buffer is

Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock.

2023-08-23 Thread Alan Bateman
On Wed, 23 Aug 2023 13:02:37 GMT, Matthias Baesken wrote: > This might be the case, but it is a separate issue. This issue is about > improving the BackingStoreException . Normally I would not even touch the > prefs C code, but converting the errno int into something more 'nice' has to > be

Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock.

2023-08-23 Thread Alan Bateman
On Tue, 22 Aug 2023 07:48:46 GMT, Matthias Baesken wrote: > Hi Alan, should we maybe add this ? If so in this change on in another one ? I don't have a strong opinion on this, I was just surprised to see these tests run concurrently given the history of issues. - PR Comment:

Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock.

2023-08-23 Thread Alan Bateman
On Wed, 23 Aug 2023 12:46:28 GMT, Matthias Baesken wrote: > Hi Alan, should this be done similar to what is done here , using strerror + > strdup and throwing an exception with the generated error message ? >

Re: RFR: 4799358: BufferOutputStream.write() should immediately throw IOExcept on closed stream

2023-08-23 Thread Alan Bateman
On Mon, 21 Aug 2023 15:05:29 GMT, Alan Bateman wrote: > I thought of this ,but i was not 100% sure. I will create CSR first. It's probably a bit premature to create the CSR as there is no agreement here on the API change. I think it would be better to drop this part and focus on the behav

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]

2023-08-22 Thread Alan Bateman
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote: >> The socket read/write JFR events currently use instrumentation of java.base >> code using templates in the jdk.jfr modules. This results in some java.base >> code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]

2023-08-22 Thread Alan Bateman
On Tue, 27 Jun 2023 18:29:45 GMT, Tim Prinzing wrote: >> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408: >> >>> 406: @Override >>> 407: public int read(ByteBuffer buf) throws IOException { >>> 408: if (!SocketReadEvent.enabled()) { >> >> The read/write

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v3]

2023-08-22 Thread Alan Bateman
On Wed, 28 Jun 2023 06:09:14 GMT, Alan Bateman wrote: >> Tim Prinzing has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains ten commits: >> >> - remove unused SOCKET_READ and SOCKET_WRITE configurations. &g

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]

2023-08-22 Thread Alan Bateman
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote: >> The socket read/write JFR events currently use instrumentation of java.base >> code using templates in the jdk.jfr modules. This results in some java.base >> code residing in the jdk.jfr module which is undesirable. >> >> JDK19 added

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events

2023-08-22 Thread Alan Bateman
On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin wrote: > An exception event will be emitted. The event is disabled by default, but > there is ongoing work on a throttling mechanism, so it can be always-on. Good, I think the exception cases are probably the most interesting for this area when it

Re: RFR: 8308995: Update Network IO JFR events to be static mirror events [v4]

2023-08-22 Thread Alan Bateman
On Wed, 2 Aug 2023 20:09:39 GMT, Alan Bateman wrote: > https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling > https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event > generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocki

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