Re: RFR: 8350041: Skip test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static JDK [v3]

On Fri, 21 Feb 2025 19:04:31 GMT, Jiangli Zhou wrote: >> Please review the fix to make >> `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: >> >> - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and >> `JNU_NewStringPlatform` dynamically >> - Remove `#include "jni

Re: RFR: 8326447: jpackage creates Windows installers that cannot be signed [v2]

On Sat, 22 Feb 2025 04:10:17 GMT, Alexander Matveev wrote: > maybe bug in our embed code The code has been the same since the first release of jpackage. > do we know when it was introduced and figure out root cause Quote from the bug description: > JDK 21.0.2 (Temurin) > > A DESCRIPTION OF T

Re: RFR: 8326447: jpackage creates Windows installers that cannot be signed [v2]

On Sat, 22 Feb 2025 02:32:29 GMT, Alexey Semenyuk wrote: > Do you have a better idea? Can we sign `msiwrapper.exe` which does not have any embedded msi? `jmod.exe` can be used to extract it from `resources`. If it works maybe bug in our embed code. If it does not work do we know when it was in

Re: RFR: 8349959: Test CR6740048.java passes unexpectedly missing CR6740048.xsd

On Thu, 20 Feb 2025 17:32:06 GMT, Joe Wang wrote: >> Hi all, >> >> Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes >> unexpectedly when missing the depentdent file >> test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a >> NULL check after call

Integrated: 8349959: Test CR6740048.java passes unexpectedly missing CR6740048.xsd

On Fri, 14 Feb 2025 07:44:26 GMT, SendaoYan wrote: > Hi all, > > Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes > unexpectedly when missing the depentdent file > test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a > NULL check after call `get

Re: RFR: 8326447: jpackage creates Windows installers that cannot be signed [v2]

On Sat, 22 Feb 2025 02:21:14 GMT, Alexander Matveev wrote: > Can we add test which will use SignTool to sign produced .exe installer? What would be the action if the test fails? - PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2675957416

Re: RFR: 8326447: jpackage creates Windows installers that cannot be signed [v2]

On Sat, 22 Feb 2025 02:17:32 GMT, Alexander Matveev wrote: > Should user just take it from another JDK which works? Yes > It does not look like a solution to this issue. Do you have a better idea? - PR Comment: https://git.openjdk.org/jdk/pull/23732#issuecomment-2675954065

Re: RFR: 8326447: jpackage creates Windows installers that cannot be signed [v2]

On Sat, 22 Feb 2025 01:05:45 GMT, Alexey Semenyuk wrote: >> Support the use of a custom msi wrapper executable when building an exe >> installer. >> >> Put `installer.exe` file in the resource directory and jpackage will use it >> instead of the default `msiwrapper.exe` resource for exe instal

Re: RFR: 8326447: jpackage creates Windows installers that cannot be signed [v2]

On Sat, 22 Feb 2025 01:05:45 GMT, Alexey Semenyuk wrote: >> Support the use of a custom msi wrapper executable when building an exe >> installer. >> >> Put `installer.exe` file in the resource directory and jpackage will use it >> instead of the default `msiwrapper.exe` resource for exe instal

Re: RFR: 8326447: jpackage creates Windows installers that cannot be signed [v2]

On Sat, 22 Feb 2025 01:05:45 GMT, Alexey Semenyuk wrote: >> Support the use of a custom msi wrapper executable when building an exe >> installer. >> >> Put `installer.exe` file in the resource directory and jpackage will use it >> instead of the default `msiwrapper.exe` resource for exe instal

Re: RFR: 8326447: jpackage creates Windows installers that cannot be signed [v2]

> Support the use of a custom msi wrapper executable when building an exe > installer. > > Put `installer.exe` file in the resource directory and jpackage will use it > instead of the default `msiwrapper.exe` resource for exe installer. > > To test this feature created a test that builds exe in

RFR: 8326447: jpackage creates Windows installers that cannot be signed

Support the use of a custom msi wrapper executable when building an exe installer. Put `installer.exe` file in the resource directory and jpackage will use it instead of the default `msiwrapper.exe` resource for exe installer. To test this feature created a test that builds exe installer with a

Re: Integrated: 8344011: Remove usage of security manager from Class and reflective APIs

Perfect. Thank you so much Alan. James R. Perkins Principal Software Engineer Red Hat On Thu, Feb 20, 2025 at 10:44 PM Alan Bateman wrote: > On 21/02/2025 01:08, James Perkins wrote: > > Please forgive me if this is the wrong medium to rep

Re: RFR: 8350118: Simplify the layout access VarHandle [v2]

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote: >> Simplify the layout access var handles to be direct in some common cases. >> Also made `VarHandle::isAccessModeSupported` report if an access mode is >> supported for a VH. >> >> Reduces the instructions to execute this code in a simple ma

Re: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v9]

On Fri, 21 Feb 2025 19:00:32 GMT, Brian Burkhalter wrote: >> Modify the implementation of `java.io.File` so that it correctly handles the >> empty path `""`. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 8024695: Add

Re: RFR: 8350118: Simplify the layout access VarHandle [v2]

On Fri, 21 Feb 2025 22:11:01 GMT, Maurizio Cimadamore wrote: >> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review remarks, dates, some more simplifications > > src/java.base/share/classes/jdk/internal/foreign/Utils.java

Re: RFR: 8350118: Simplify the layout access VarHandle [v2]

On Fri, 21 Feb 2025 20:14:19 GMT, Chen Liang wrote: >> Simplify the layout access var handles to be direct in some common cases. >> Also made `VarHandle::isAccessModeSupported` report if an access mode is >> supported for a VH. >> >> Reduces the instructions to execute this code in a simple ma

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (a

Re: RFR: 8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native [v5]

On Fri, 21 Feb 2025 14:01:20 GMT, Chen Liang wrote: >> I don't use the field directly because the field is a short and getModifiers >> makes it into Modifier. > > Indeed, even though this checks for the specific bit so widening has no > effect, it is better to be cautious here. > I don't use t

Integrated: 8349759: Add unit test for CertificateBuilder and SimpleOCSPServer test utilities

On Tue, 11 Feb 2025 17:50:45 GMT, Jamil Nimeh wrote: > This fix makes some minor changes to the internals of the > `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break > when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS > works better now with thes

Re: RFR: 8350118: Simplify the layout access VarHandle [v2]

On Fri, 21 Feb 2025 14:43:31 GMT, Maurizio Cimadamore wrote: >> I have disabled them with #, and the status is confirmed by test for access >> modes. I kept the infra to make future reenabling easy. > >> I have disabled them with #, and the status is confirmed by test for access >> modes. I ke

Re: RFR: 8350118: Simplify the layout access VarHandle [v2]

> Simplify the layout access var handles to be direct in some common cases. > Also made `VarHandle::isAccessModeSupported` report if an access mode is > supported for a VH. > > Reduces the instructions to execute this code in a simple main by 47%: > > long[] arr = new long[8]; > var ms = Memory

Re: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11]

On Thu, 20 Feb 2025 17:32:54 GMT, Sergey Chernyshev wrote: >> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java >> line 73: >> >>> 71: break; >>> 72: } >>> 73: cgp

Re: RFR: 8349759: Add unit test for CertificateBuilder and SimpleOCSPServer test utilities [v4]

On Thu, 20 Feb 2025 01:12:46 GMT, Jamil Nimeh wrote: >> This fix makes some minor changes to the internals of the >> `CertificateBuilder` and `SimpleOCSPServer` test classes. They would break >> when ML-DSA was selected as key and signing algorithms. Also RSASSA-PSS >> works better now with

Re: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v11]

On Mon, 17 Feb 2025 11:28:38 GMT, Severin Gehwolf wrote: >> Sergey Chernyshev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> added details in the log message > > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 60:

Re: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v14]

> Cgroup V1 subsustem fails to initialize mounted controllers properly in > certain cases, that may lead to controllers left undetected/inactive. We > observed the behavior in CloudFoundry deployments, it affects also host > systems. > > The relevant /proc/self/mountinfo line is > > > 2207 21

Re: RFR: 8350041: Make libstringPlatformChars support static JDK [v3]

> Please review the fix to make > `java/lang/String/nativeEncoding/StringPlatformChars.java` jtreg test: > > - Lookup `JNU_GetStringPlatformChars`, `JNU_ClassString` and > `JNU_NewStringPlatform` dynamically > - Remove `#include "jni_util.h"` and don't link `libstringPlatformChars.so` > with `

Re: RFR: 8350041: Skip test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static JDK

On Fri, 21 Feb 2025 06:57:05 GMT, Alan Bateman wrote: > > Updated to skipping > > `java/lang/String/nativeEncoding/StringPlatformChars.java` on static JDK. > > Thanks. If you can bump the copyright header date then I think we are done > with this one. Done, thanks! - PR Comment:

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 18:34:48 GMT, Maurizio Cimadamore wrote: >> We have two caches, one in `ValueLayouts` and another in `Utils`. Should we >> remove both? > > I'm not convinced about the one in ValueLayouts *e.g. where this comment was > added) -- if you agree that the other cache should alre

Re: New candidate JEP: 502: Stable Values (Preview)

Hi David, thanks for reaching out -- answser inline below On 21/02/2025 16:34, David Gregory wrote: While we started working on this for MH/VH-related use cases (for instance, FFM's jextract will be a big user of stable values), we also realized that this abstraction is actually quite useful in

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 16:04:57 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template >> line 77: >> >>> 75: } >>> 76: >>> 77: @ForceInline >> >> Question: can this and the `offset` method go in the >> `VarHandleSegmentViewBa

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (a

Re: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v8]

> Modify the implementation of `java.io.File` so that it correctly handles the > empty path `""`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8024695: Check only that space is positive - Changes: - all: https:

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

On Fri, 21 Feb 2025 12:52:10 GMT, Doug Lea wrote: >> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3537: >> >>> 3535: * pool is {@link #shutdownNow}, or is {@link #shutdown} when >>> 3536: * otherwise quiescent and {@link #cancelDelayedTasksOnShutdown} >>> 353

Re: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v7]

On Fri, 21 Feb 2025 17:16:16 GMT, Brian Burkhalter wrote: >> My comment is about the tests getTotalSpace/getFreeSpace/getUsableSpace as >> they check that the results are close to the FIleStore equivalent. My >> concern is how stable this is with other tests running in other agent VMs as >> th

Re: RFR: 8349959: Test CR6740048.java passes unexpectedly missing CR6740048.xsd [v2]

On Fri, 21 Feb 2025 01:38:34 GMT, SendaoYan wrote: >> Hi all, >> >> Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes >> unexpectedly when missing the depentdent file >> test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a >> NULL check after cal

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (a

Re: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v7]

On Fri, 21 Feb 2025 17:14:24 GMT, Alan Bateman wrote: >> I don't recall asserting any relationship between the allocated and free >> space. Initially I had this simply checking that each returned space value >> was positive. Do you think that that is enough? > > My comment is about the tests ge

Re: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v7]

On Fri, 21 Feb 2025 17:03:36 GMT, Brian Burkhalter wrote: >> test/jdk/java/io/File/EmptyPath.java line 121: >> >>> 119: assertTrue(actual > 0); >>> 120: long ds = Math.abs(expected - actual); >>> 121: assertTrue((double)ds/expected < 0.05); >> >> Are you conf

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (a

Re: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v6]

On Fri, 21 Feb 2025 07:42:32 GMT, Alan Bateman wrote: >> So changed in a3b7977. > > Thanks, that is better replace for this. In time it may be a good candidate > to be a stable value. It was a bad idea in the first place that I put that in `File` itself. I also thought of this being a stable v

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (a

Re: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v7]

On Fri, 21 Feb 2025 07:41:35 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains eight commits: >> >> - 8024695: Move getCWD to holder; remove Order from test >> - Merge >> - 8024695: Ex

Re: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v7]

On Fri, 21 Feb 2025 11:10:43 GMT, Daniel Fuchs wrote: > Looks like the [description of the > PR](https://github.com/openjdk/jdk/pull/22821#issue-2749006501) should be > updated now You are correct, thanks: I have updated it. Note that I still need to change the CSR similarly. > src/java.base

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (a

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (a

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (a

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

On Fri, 21 Feb 2025 13:16:10 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (a

Re: New candidate JEP: 502: Stable Values (Preview)

While we started working on this for MH/VH-related use cases (for instance, FFM's jextract will be a big user of stable values), we also realized that this abstraction is actually quite useful in other cases too. This is really exciting! Stable values open the door to some really exciting lan

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 10:12:45 GMT, Maurizio Cimadamore wrote: >> Simplify the layout access var handles to be direct in some common cases. >> Also made `VarHandle::isAccessModeSupported` report if an access mode is >> supported for a VH. >> >> Reduces the instructions to execute this code in a

Re: RFR: 8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native [v6]

On Wed, 19 Feb 2025 14:21:47 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvm.cpp line 1262: >> >>> 1260: JVM_END >>> 1261: >>> 1262: JVM_ENTRY(jboolean, JVM_IsArrayClass(JNIEnv *env, jclass cls)) >> >> Where are the changes to jvm.h? > > Good catch, I also removed JVM_GetProtectio

Re: RFR: 8350334: Add final keywords to FFM methods

On Wed, 19 Feb 2025 14:23:04 GMT, Per Minborg wrote: > This PR proposes to add the `final` keyword to some classes and methods in > order to assist compiler devirtualization (e.g. in Graal native image). > > Passes `make test TEST=jdk_foreign` I have no objection with this -- but I do think th

Re: RFR: 8349653: Clarify the docs for MemorySegment::reinterpret

On Wed, 19 Feb 2025 09:14:03 GMT, Per Minborg wrote: > This PR proposes to clarify the documentation for two of the > `MemorySegment::reinterpret` overloads. Looks good! - Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23688#pullrequestr

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 13:53:47 GMT, Chen Liang wrote: >> src/java.base/share/classes/jdk/internal/foreign/Utils.java line 77: >> >>> 75: >>> 76: private static MethodHandle computeFilterHandle(int index) { >>> 77: MethodHandles.Lookup lookup = MethodHandles.lookup(); >> >> please bre

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 13:49:51 GMT, Chen Liang wrote: > I have disabled them with #, and the status is confirmed by test for access > modes. I kept the infra to make future reenabling easy. Doh - I missed the `#` -- maybe add few more to make that more explicit? (I agree with the approach) >> s

Re: RFR: 8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native [v5]

On Fri, 21 Feb 2025 12:27:56 GMT, Coleen Phillimore wrote: >> You are right, using the field directly is indeed better. > > I don't use the field directly because the field is a short and getModifiers > makes it into Modifier. Indeed, even though this checks for the specific bit so widening has

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 09:59:27 GMT, Maurizio Cimadamore wrote: >> Simplify the layout access var handles to be direct in some common cases. >> Also made `VarHandle::isAccessModeSupported` report if an access mode is >> supported for a VH. >> >> Reduces the instructions to execute this code in a

Re: RFR: 8319447: Improve performance of delayed task handling

On Thu, 20 Feb 2025 22:35:07 GMT, Sunmisc Unsafe wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottlen

Re: RFR: 8319447: Improve performance of delayed task handling [v2]

> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) > > The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is > both ill-suited for many (if not most) of its applications, and is a > performance bottleneck (as seen especially in Loom and CompletableFuture > usages

Re: RFR: 8319447: Improve performance of delayed task handling

On Thu, 20 Feb 2025 15:28:28 GMT, Alan Bateman wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottlenec

Re: RFR: 8319447: Improve performance of delayed task handling

On Thu, 20 Feb 2025 17:27:44 GMT, Alan Bateman wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottlenec

Re: RFR: 8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native [v5]

On Thu, 20 Feb 2025 23:38:34 GMT, Chen Liang wrote: >> Coleen Phillimore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix whitespace > > You are right, using the field directly is indeed better. I don't use the field directly because

Re: RFR: 8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native [v6]

> Class.isInterface() can check modifier flags, Class.isArray() can check > whether component mirror is non-null and Class.isPrimitive() needs a new > final transient boolean in java.lang.Class that the JVM code initializes. > Tested with tier1-4 and performance tests. Coleen Phillimore has upda

Re: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v4]

On Fri, 21 Feb 2025 10:41:25 GMT, Daniel Fuchs wrote: >> David Beaumont has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Updating code and tests according to feedback and discussions. > > src/java.logging/share/classes/java/util/logging/F

Re: RFR: 8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native [v5]

On Thu, 20 Feb 2025 20:19:15 GMT, Coleen Phillimore wrote: >> Class.isInterface() can check modifier flags, Class.isArray() can check >> whether component mirror is non-null and Class.isPrimitive() needs a new >> final transient boolean in java.lang.Class that the JVM code initializes. >> Teste

Re: RFR: 8024695: new File("").exists() returns false whereas it is the current working directory [v7]

On Thu, 20 Feb 2025 22:20:04 GMT, Brian Burkhalter wrote: >> Update the specification of `java.io.File.exists()` to match its behavior, >> which seems correct in the context of how the empty abstract pathname is >> documented elsewhere in the class. > > Brian Burkhalter has updated the pull req

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang wrote: > Simplify the layout access var handles to be direct in some common cases. > Also made `VarHandle::isAccessModeSupported` report if an access mode is > supported for a VH. > > Reduces the instructions to execute this code in a simple main by

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 11:05:30 GMT, Maurizio Cimadamore wrote: > Overall, this is a great cleanup and consolidation of the memory segment VH > code. I left various comments -- but this is already in a great shape. Thanks! It would be useful to run some micro benchmarks before/after -- especially

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang wrote: > Simplify the layout access var handles to be direct in some common cases. > Also made `VarHandle::isAccessModeSupported` report if an access mode is > supported for a VH. > > Reduces the instructions to execute this code in a simple main by

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang wrote: > Simplify the layout access var handles to be direct in some common cases. > Also made `VarHandle::isAccessModeSupported` report if an access mode is > supported for a VH. > > Reduces the instructions to execute this code in a simple main by

Re: RFR: 8349206: j.u.l.Handler classes create deadlock risk via synchronized publish() method [v4]

On Thu, 20 Feb 2025 17:38:21 GMT, David Beaumont wrote: >> 8349206: j.u.l.Handler classes create deadlock risk via synchronized >> publish() method. >> >> 1. Remove synchronization of calls to publish() in Handlers in >> java.util.logging package. >> 2. Add explanatory comments to various affe

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang wrote: > Simplify the layout access var handles to be direct in some common cases. > Also made `VarHandle::isAccessModeSupported` report if an access mode is > supported for a VH. > > Reduces the instructions to execute this code in a simple main by

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang wrote: > Simplify the layout access var handles to be direct in some common cases. > Also made `VarHandle::isAccessModeSupported` report if an access mode is > supported for a VH. > > Reduces the instructions to execute this code in a simple main by

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang wrote: > Simplify the layout access var handles to be direct in some common cases. > Also made `VarHandle::isAccessModeSupported` report if an access mode is > supported for a VH. > > Reduces the instructions to execute this code in a simple main by

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang wrote: > Simplify the layout access var handles to be direct in some common cases. > Also made `VarHandle::isAccessModeSupported` report if an access mode is > supported for a VH. > > Reduces the instructions to execute this code in a simple main by

Re: RFR: 8350118: Simplify the layout access VarHandle

On Fri, 21 Feb 2025 00:01:36 GMT, Chen Liang wrote: > Simplify the layout access var handles to be direct in some common cases. > Also made `VarHandle::isAccessModeSupported` report if an access mode is > supported for a VH. > > Reduces the instructions to execute this code in a simple main by

Re: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v11]

On Thu, 20 Feb 2025 11:00:59 GMT, Galder Zamarreño wrote: > Re: https://github.com/openjdk/jdk/pull/20098#issuecomment-2671144644 - I was > trying to think what could be causing this. Maybe it is an issue with probabilities? Do you know at what point (if at all) the `MinI` node appears/disappe

Re: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v12]

On Thu, 20 Feb 2025 06:50:07 GMT, Galder Zamarreño wrote: > The interesting thing is intReductionSimpleMin @ 100%. We see a regression > there but I didn't observe it with the perfasm run. So, this could be due to > variance in the application of cmov or not? I don't see the error / variance i

Re: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v11]

On Thu, 20 Feb 2025 11:00:59 GMT, Galder Zamarreño wrote: > So, if those int scalar regressions were not a problem when int min/max > intrinsic was added, I would expect the same to apply to long. Do you know when they were added? If that was a long time ago, we might not have noticed back the