Re: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0 [v3]

2022-04-26 Thread Harold Seigel
On Mon, 25 Apr 2022 14:26:17 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8284642. The fix was tested by running >> Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux >> x64. Additionally, the modified test and the test in t

Integrated: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0

2022-04-26 Thread Harold Seigel
On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8284642. The fix was tested by running > Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux > x64. Additionally, the modified test and the test in the bug report

Re: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0 [v2]

2022-04-25 Thread Harold Seigel
On Fri, 22 Apr 2022 18:14:27 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8284642. The fix was tested by running >> Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux >> x64. Additionally, the modified test and the test in t

Re: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0 [v3]

2022-04-25 Thread Harold Seigel
> Please review this small fix for JDK-8284642. The fix was tested by running > Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux > x64. Additionally, the modified test and the test in the bug report were run > locally. > > Thanks, Harold Harold

Re: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0 [v2]

2022-04-22 Thread Harold Seigel
> Please review this small fix for JDK-8284642. The fix was tested by running > Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux > x64. Additionally, the modified test and the test in the bug report were run > locally. > > Thanks, Harold Harold

Re: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0

2022-04-22 Thread Harold Seigel
On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8284642. The fix was tested by running > Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux > x64. Additionally, the modified test and the test in the bug report

Re: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0

2022-04-21 Thread Harold Seigel
On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8284642. The fix was tested by running > Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux > x64. Additionally, the modified test and the test in the bug report

RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0

2022-04-13 Thread Harold Seigel
Please review this small fix for JDK-8284642. The fix was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64. Additionally, the modified test and the test in the bug report were run locally. Thanks, Harold - Commit messages: - 8284

RFR: 8277481: Obsolete seldom used CDS flags

2021-12-10 Thread Harold Seigel
Please review this change to obsolete deprecated CDS options UseSharedSpaces, RequireSharedSpaces, DynamicDumpSharedSpaces, and DumpSharedSpaces. The change was tested by running Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64 and Windows x64. The use of UseShare

Re: RFR: 8275735: [linux] Remove deprecated Metrics api (kernel memory limit)

2021-10-28 Thread Harold Seigel
On Thu, 28 Oct 2021 13:03:56 GMT, Severin Gehwolf wrote: > Please review this change to remove some API which no longer works as > expected as recent OCI runtimes start to drop support for `--kernel-memory` > switch. See the bug for references. This part of the API is not present in > hotspot

Re: RFR: 8272614: Unused parameters in MethodHandleNatives linking methods

2021-10-20 Thread Harold Seigel
On Tue, 19 Oct 2021 17:12:16 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272614 to remove the unused indexInCP > argument to linkCallSite() and linkDynamicConstant(). The fix was tested > with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-6 on

Integrated: 8272614: Unused parameters in MethodHandleNatives linking methods

2021-10-20 Thread Harold Seigel
On Tue, 19 Oct 2021 17:12:16 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272614 to remove the unused indexInCP > argument to linkCallSite() and linkDynamicConstant(). The fix was tested > with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-6 on

RFR: 8272614: Unused parameters in MethodHandleNatives linking methods

2021-10-19 Thread Harold Seigel
Please review this small fix for JDK-8272614 to remove the unused indexInCP argument to linkCallSite() and linkDynamicConstant(). The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-6 on Linux x64. Thanks, Harold - Commit messages: - 8272614:

Re: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon [v4]

2021-08-18 Thread Harold Seigel
On Wed, 18 Aug 2021 13:04:46 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8272124. The fix puts a limit of 3 >> when splitting self cgroup lines by ':' so that Cgroup paths won't get >> truncated if they contain embedded ':'

Integrated: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon

2021-08-18 Thread Harold Seigel
On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272124. The fix puts a limit of 3 when > splitting self cgroup lines by ':' so that Cgroup paths won't get truncated > if they contain embedded ':'s. For

Re: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon [v4]

2021-08-18 Thread Harold Seigel
n a /proc/self/cgroup file will now result in a > Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 > and Linux aarch64. > > Thanks, Harold Harold Seigel has updated the p

Re: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when cgroup path contains colon [v3]

2021-08-18 Thread Harold Seigel
On Wed, 18 Aug 2021 12:25:45 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8272124. The fix puts a limit of 3 >> when splitting self cgroup lines by ':' so that Cgroup paths won't get >> truncated if they contain embedded ':'

Re: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon [v2]

2021-08-18 Thread Harold Seigel
On Tue, 17 Aug 2021 17:39:49 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8272124. The fix puts a limit of 3 >> when splitting self cgroup lines by ':' so that Cgroup paths won't get >> truncated if they contain embedded ':'

Re: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon [v3]

2021-08-18 Thread Harold Seigel
n a /proc/self/cgroup file will now result in a > Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 > and Linux aarch64. > > Thanks, Harold Harold Seigel has updated the p

Re: RFR: 8272398: Update DockerTestUtils.buildJdkDockerImage() [v2]

2021-08-17 Thread Harold Seigel
On Tue, 17 Aug 2021 14:58:48 GMT, Mikhailo Seledtsov wrote: >> Please review this change that updates the buildJdkDockerImage() test >> library API. >> >> This work originated while working on "8195809: [TESTBUG] jps and jcmd -l >> support for containers is not tested". >> The initial intent

Re: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon

2021-08-17 Thread Harold Seigel
On Mon, 16 Aug 2021 17:25:57 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8272124. The fix puts a limit of 3 when > splitting self cgroup lines by ':' so that Cgroup paths won't get truncated > if they contain embedded ':'s. For

Re: RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon [v2]

2021-08-17 Thread Harold Seigel
n a /proc/self/cgroup file will now result in a > Cgroup path of "/user.sli:ce" instead of "/user.sli". > > The fix was tested with Mach5 tiers 1 and 2, and Mach5 tiers 3-5 on Linux x64 > and Linux aarch64. > > Thanks, Harold Harold Seigel has updated the p

RFR: 8272124: Cgroup v1 initialization causes NullPointerException when path contains colon

2021-08-16 Thread Harold Seigel
Please review this small fix for JDK-8272124. The fix puts a limit of 3 when splitting self cgroup lines by ':' so that Cgroup paths won't get truncated if they contain embedded ':'s. For example, an entry of "11:memory:/user.sli:ce" in a /proc/self/cgroup file will now result in a Cgroup path

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v4]

2021-05-19 Thread Harold Seigel
On Tue, 18 May 2021 23:01:05 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 403 >> (https://openjdk.java.net/jeps/403). >> Alan Bateman is the original author of almost all of it. Passes tiers 1-3 >> on >> {linux,macos,windows}-x64 and {linux,macos}-aarch64. > > Mark Re

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals

2021-05-13 Thread Harold Seigel
On Thu, 13 May 2021 17:14:36 GMT, Mark Reinhold wrote: > Please review this implementation of JEP 403 > (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. src/hotspot/share/

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

2021-05-13 Thread Harold Seigel
On Thu, 13 May 2021 12:31:44 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

Integrated: 8243287: Removal of Unsafe::defineAnonymousClass

2021-05-13 Thread Harold Seigel
On Tue, 11 May 2021 12:50:31 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.

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

2021-05-13 Thread Harold Seigel
On Thu, 13 May 2021 07:19:03 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix Weak hidden comment > > src/hotspot/share/oops/constantPool.hpp line 493:

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

2021-05-13 Thread Harold Seigel
On Wed, 12 May 2021 22:30:30 GMT, Mandy Chung wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> test changes and small fixes > > src/hotspot/share/classfile/classLoaderData.cpp

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

2021-05-13 Thread Harold Seigel
sses, others were deleted because > either similar hidden classes tests already exist or they tested dAC specific > functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, > and Mach5 tiers 3-7 on Linux x64. > >

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

2021-05-12 Thread Harold Seigel
On Tue, 11 May 2021 17:07:35 GMT, Ioi Lam wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix GetModuleTest.java > > src/hotspot/share/oops/instanceMirrorKlass.inline.hpp line 65

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

2021-05-12 Thread Harold Seigel
On Tue, 11 May 2021 20:49:46 GMT, Mandy Chung wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix GetModuleTest.java > > src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/sr

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

2021-05-12 Thread Harold Seigel
On Tue, 11 May 2021 14:13:49 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

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

2021-05-12 Thread Harold Seigel
sses, others were deleted because > either similar hidden classes tests already exist or they tested dAC specific > functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, > and Mach5 tiers 3-7 on Linux x64. > >

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

2021-05-11 Thread Harold Seigel
On Tue, 11 May 2021 13:41:53 GMT, Alan Bateman wrote: >> test/jdk/java/lang/Class/GetModuleTest.java line 42: >> >>> 40: import static org.testng.Assert.*; >>> 41: >>> 42: public class GetModuleTest { >> >> testGetModuleOnVMAnonymousClass is the only test here that uses ASM so you >> can remo

Re: RFR: 8243287: Removal of Unsafe::defineAnonymousClass

2021-05-11 Thread Harold Seigel
classes by comparing the name to see if it contains a slash, especially tests, but which don’t say “anonymous”. Did you do a search for these idioms too, which are now dead tests? Sent from my iPad On May 11, 2021, at 8:59 AM, Harold Seigel wrote: Please review this large change to remove

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

2021-05-11 Thread Harold Seigel
sses, others were deleted because > either similar hidden classes tests already exist or they tested dAC specific > functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, > and Mach5 tiers 3-7 on Linux x64. > >

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

2021-05-11 Thread Harold Seigel
sses, others were deleted because > either similar hidden classes tests already exist or they tested dAC specific > functionality, such as host classes. > > This change was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, > and Mach5 tiers 3-7 on Linux x64. > >

RFR: 8243287: Removal of Unsafe::defineAnonymousClass

2021-05-11 Thread Harold Seigel
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 of the tests were modified to use hidden classes, others were deleted

Re: RFR: 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64

2021-04-13 Thread Harold Seigel
On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt wrote: > Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a > tier1 test) until JDK-8262897 is fixed. Looks good and trivial. Harold - Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java

Re: RFR: 8262379: Add regression test for JDK-8257746

2021-03-01 Thread Harold Seigel
On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf wrote: > Fails prior the patch of JDK-8257746, passes after. As expected. > > Thoughts? The new tests looks good. Thanks for adding it. Harold - Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull

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

2021-02-11 Thread Harold Seigel
On Tue, 9 Feb 2021 13:31:25 GMT, Severin Gehwolf wrote: >> This is an enhancement which solves two issues: >> >> 1. Multiple reads of relevant cgroup interface files. Now interface files >> are only read once per file (just like Hotspot). >> 2. Proxies creation of the impl specific subsystem vi

Re: RFR: 8261604: ProblemList jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java

2021-02-11 Thread Harold Seigel
On Thu, 11 Feb 2021 17:55:13 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList > jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java > in order to reduce noise in the JDK17 CI. Looks good and trivial. Thanks, Harold - Marked as reviewed by hseigel (Reviewer). PR: h

Re: RFR: 8257746: Regression introduced with JDK-8250984 - memory might be null in some machines

2021-01-28 Thread Harold Seigel
On Wed, 27 Jan 2021 21:10:16 GMT, Poonam Bajaj wrote: > Please review this simple change that adds null checks for memory in > CgroupV1Subsystem.java. > > Problem: After the backport of JDK-8250984, there are places where > memory.isSwapEnabled() is called. For example: > > public long g

Re: [jdk16] RFR: 8257596: Clarify trusted final fields for record classes [v2]

2020-12-11 Thread Harold Seigel
On Fri, 11 Dec 2020 19:29:09 GMT, Mandy Chung wrote: >> This is a follow-up on JDK-8255342 that removes non-specified JVM checks on >> classes with RecordComponents attributes. >> >> See the discussion at >> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html >

Re: [jdk16] RFR: 8257596: Clarify trusted final fields for record classes

2020-12-11 Thread Harold Seigel
On Fri, 11 Dec 2020 17:58:33 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on > classes with RecordComponents attributes. > > See the discussion at > https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-December/002670.html > > T

Re: RFR: 8253797: [cgroups v2] Account for the fact that swap accounting is disabled on some systems

2020-12-10 Thread Harold Seigel
On Mon, 7 Dec 2020 17:48:01 GMT, Severin Gehwolf wrote: > This has been implemented for cgroups v1 with > [JDK-8250984](https://bugs.openjdk.java.net/browse/JDK-8250984) but was > lacking some tooling support for cgroups v2. With podman 2.2.0 release this > could now be implemented (and tested

Re: RFR: 8257596: Clarify trusted final fields for record classes

2020-12-10 Thread Harold Seigel
On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on > classes with `RecordComponents` attributes. That introduces a regression in > `InstanceKlass::is_record` that returns true on a non-record class which has > `Rec

Re: RFR: 8257596: Clarify trusted final fields for record classes

2020-12-10 Thread Harold Seigel
On Tue, 8 Dec 2020 22:52:37 GMT, Mandy Chung wrote: > This is a follow-up on JDK-8255342 that removes non-specified JVM checks on > classes with `RecordComponents` attributes. That introduces a regression in > `InstanceKlass::is_record` that returns true on a non-record class which has > `Rec

Integrated: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended

2020-12-09 Thread Harold Seigel
On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel wrote: > Please review this fix for JDK-8256867. This change no longer throws a > ClassFormatError exception when loading a class whose PermittedSubclasses > attribute is empty (contains no classes). Instead, the class is treated as a

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3]

2020-12-08 Thread Harold Seigel
On Tue, 8 Dec 2020 18:24:21 GMT, Mandy Chung wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8256867: Classes with empty PermittedSubclasses attribute cannot be >> extended &g

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v3]

2020-12-08 Thread Harold Seigel
h5 tiers 1-2 on Linux, MacOS, and Windows, and > tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8256867: Classes with empty PermittedSubclasses attribute cannot be extend

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2]

2020-12-08 Thread Harold Seigel
On Tue, 8 Dec 2020 14:37:52 GMT, Chris Hegarty wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8256867: Classes with empty PermittedSubclasses attribute cannot be >> extended > &

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2]

2020-12-08 Thread Harold Seigel
On Tue, 8 Dec 2020 09:30:59 GMT, Chris Hegarty wrote: >> src/java.base/share/classes/java/lang/Class.java line 4396: >> >>> 4394: * is unspecified. If this {@code Class} object represents a >>> primitive type, >>> 4395: * {@code void}, an array type, or a class or interface that is >

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2]

2020-12-08 Thread Harold Seigel
On Tue, 8 Dec 2020 00:09:34 GMT, Mandy Chung wrote: >> src/hotspot/share/prims/jvm.cpp line 2130: >> >>> 2128: JvmtiVMObjectAllocEventCollector oam; >>> 2129: Array* subclasses = ik->permitted_subclasses(); >>> 2130: int length = subclasses == NULL ? 0 : subclasses->length(); >> >>

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended [v2]

2020-12-08 Thread Harold Seigel
h5 tiers 1-2 on Linux, MacOS, and Windows, and > tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8256867: Classes with empty PermittedSubclasses attribute cannot be extend

Re: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended

2020-12-07 Thread Harold Seigel
On Mon, 7 Dec 2020 21:18:45 GMT, Joe Darcy wrote: >> Please review this fix for JDK-8256867. This change no longer throws a >> ClassFormatError exception when loading a class whose PermittedSubclasses >> attribute is empty (contains no classes). Instead, the class is treated as >> a sealed c

RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot be extended

2020-12-07 Thread Harold Seigel
Please review this fix for JDK-8256867. This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes). Instead, the class is treated as a sealed class which cannot be extended nor implemented. This new behavio

Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal

2020-12-07 Thread Harold Seigel
On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote: > Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100). > > Development has been broken into 5 tasks, each with its own JBS issue: > - Deprecate wrapper class constructors for removal (rriggs) > - Revise "value-based class"

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

2020-12-02 Thread Harold Seigel
On Tue, 1 Dec 2020 23:16:45 GMT, Mandy Chung wrote: >> This pull request replaces https://github.com/openjdk/jdk/pull/1227. >> >> From the original PR: >> >>> Please review the code for the second iteration of sealed classes. In this >>> iteration we are: >>> >>> * Enhancing narrowing ref

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

2020-11-30 Thread Harold Seigel
On Mon, 30 Nov 2020 19:44:52 GMT, Mandy Chung wrote: >> Jan Lahoda has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 12 commits: >> >> - Improving getPermittedSubclasses javadoc. >> - Merge branch 'master' into JDK-8246778 >> - M

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

2020-11-23 Thread Harold Seigel
Hi David, Thanks for looking at this. The intent was for method Class.permittedSubclasses() to be implemented similarly to Class.getNestMembers().  Are you suggesting that a security manager check be added to permittedSubclasses() similar to the security manager check in getNestMembers()? T

Re: RFR: 8255787: Tag container tests that use cGroups with cgroups keyword

2020-11-12 Thread Harold Seigel
On Wed, 11 Nov 2020 00:27:59 GMT, Serguei Spitsyn wrote: >> Please review this small change to add a cgroups keyword to tests that use >> cgroups. The fix was tested by running Mach5 container tests. > > Hi Harold, > > The fix looks good. > > Thanks, > Serguei Thanks Serguei! Harold ---

Integrated: 8255787: Tag container tests that use cGroups with cgroups keyword

2020-11-12 Thread Harold Seigel
On Tue, 10 Nov 2020 21:24:25 GMT, Harold Seigel wrote: > Please review this small change to add a cgroups keyword to tests that use > cgroups. The fix was tested by running Mach5 container tests. This pull request has now been integrated. Changeset: 4df8abc2 Author:Harold Seige

RFR: 8255787: Tag container tests that use cGroups with cgroups keyword

2020-11-10 Thread Harold Seigel
Please review this small change to add a cgroups keyword to tests that use cgroups. The fix was tested by running Mach5 container tests. - Commit messages: - 8255787: Tag container tests that use cGroups with cgroups keyword Changes: https://git.openjdk.java.net/jdk/pull/1148/file

Re: RFR: 8238263: Create at-requires mechanism for containers [v2]

2020-10-26 Thread Harold Seigel
On Mon, 26 Oct 2020 20:24:35 GMT, Igor Ignatyev wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8238263: Create at-requires mechanism for containers > > LGTM, modulo my earlier comme

Integrated: 8238263: Create at-requires mechanism for containers

2020-10-26 Thread Harold Seigel
On Fri, 23 Oct 2020 18:44:54 GMT, Harold Seigel wrote: > Please review this change to add an @requires mechanism called > "jdk.containerized" to help mark tests that are incompatible with containers. > Users would add "@requires jdk.containerized != true" to the i

Re: RFR: 8238263: Create at-requires mechanism for containers

2020-10-26 Thread Harold Seigel
On Mon, 26 Oct 2020 14:25:14 GMT, Igor Ignatyev wrote: >> Defining an environment variable works when running JTReg from the command >> line. But, mach5 does not pass environment variable settings to its JTReg >> test runs. Some mach5 special command args would still be needed. > >> Defining

Re: RFR: 8238263: Create at-requires mechanism for containers [v2]

2020-10-26 Thread Harold Seigel
OPTIONS=-Djdk.containerized=true" or "bash > jib.sh mach5 -- remote-build-and-test ... --test-make-args > JTREG=OPTIONS=-Djdk.containerized=true" to exclude those tests when testing > with containers. Harold Seigel has updated the pull request incrementally with one addi

Re: RFR: 8238263: Create at-requires mechanism for containers

2020-10-26 Thread Harold Seigel
On Fri, 23 Oct 2020 20:08:01 GMT, Igor Ignatyev wrote: >>> I think it depends on whether the tests will be permanently or temporarily >>> excluded from running with containers. I thought this mechanism would be to >>> permanently exclude the tests. That's why I used `@requires`. >> >> I see, i

Re: RFR: 8238263: Create at-requires mechanism for containers

2020-10-23 Thread Harold Seigel
On Fri, 23 Oct 2020 19:17:40 GMT, Igor Ignatyev wrote: >> Please review this change to add an @requires mechanism called >> "jdk.containerized" to help mark tests that are incompatible with >> containers. Users would add "@requires jdk.containerized != true" to the >> incompatible tests and t

Re: RFR: 8238263: Create at-requires mechanism for containers

2020-10-23 Thread Harold Seigel
this option based on an environment variable so we don’t have to remember the cryptic command line sequence. It’s too bad we can’t automatically detect that we are running in a container. Bob. On Oct 23, 2020, at 2:50 PM, Harold Seigel wrote: Please review this change to add an @requires mech

RFR: 8238263: Create at-requires mechanism for containers

2020-10-23 Thread Harold Seigel
Please review this change to add an @requires mechanism called "jdk.containerized" to help mark tests that are incompatible with containers. Users would add "@requires jdk.containerized != true" to the incompatible tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash jib

RFR: 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o…

2020-09-22 Thread Harold Seigel
Please review this small change to remove "--memory 200m" option from TestUseContainerSupport.java. This can cause test failures on systems where swap accounting is disabled. - Commit messages: - 8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capa

Re: RFR: JDK-8225056 VM support for sealed classes

2020-06-01 Thread Harold Seigel
Hi David, Thanks for reviewing the latest changes. I'll create the follow on RFE's once the sealed classes code is in mainline. Harold On 5/31/2020 9:34 PM, David Holmes wrote: Hi Harold, On 1/06/2020 8:57 am, Harold Seigel wrote: Thanks for the comments. Here's version 3

Re: RFR: JDK-8225056 VM support for sealed classes

2020-05-31 Thread Harold Seigel
sealed classes API's in Class.java. Thanks, Harold On 5/28/2020 8:30 PM, David Holmes wrote: Hi Harold, Sorry Mandy's comment raised a couple of issues ... On 29/05/2020 7:12 am, Mandy Chung wrote: Hi Harold, On 5/27/20 1:35 PM, Harold Seigel wrote: Incremental webrev:

Re: RFR: JDK-8225056 VM support for sealed classes

2020-05-28 Thread Harold Seigel
Hi Mandy, The entries in the PermittedSubclasses attribute are constant pool ConstantClass_info entries.  These names get validated by the VM in this code in ClassFileParser::parse_constant_pool():   for (index = 1; index < length; index++) {     const jbyte tag = cp->tag_at(index).va

Re: RFR: JDK-8225056 VM support for sealed classes

2020-05-27 Thread Harold Seigel
.  And added appropriate testing. * Method Class.permittedSubtypes() was changed. See also inline comments. On 5/24/2020 10:28 PM, David Holmes wrote: Hi Harold, On 22/05/2020 4:33 am, Harold Seigel wrote: Hi David, Thanks for looking at this!  Please review this new webrev:     http

Re: RFR: JDK-8225056 VM support for sealed classes

2020-05-22 Thread Harold Seigel
Thanks Lois! I'll add the two ResourceMarks before the changes get pushed. Harold On 5/22/2020 11:07 AM, Lois Foltan wrote: On 5/21/2020 2:33 PM, Harold Seigel wrote: Hi David, Thanks for looking at this!  Please review this new webrev:    http://cr.openjdk.java.net/~hseigel/webr

Re: RFR: JDK-8225056 VM support for sealed classes

2020-05-21 Thread Harold Seigel
Hi Mandy, Thanks for the suggestions.  They have been incorporated in the revised webrev. http://cr.openjdk.java.net/~hseigel/webrev.01/webrev/ Harold On 5/20/2020 1:05 PM, Mandy Chung wrote: Hi Vicente, On 5/20/20 8:40 AM, Vicente Romero wrote: Hi David, src/java.base/share/classes/

Re: RFR: JDK-8225056 VM support for sealed classes

2020-05-21 Thread Harold Seigel
I've looked at all files and mainly have some style nits in various places. But there are some more significant items below. On 14/05/2020 7:09 am, Harold Seigel wrote: Hi, Please review this patch for JVM and Core-libs support for the JEP 360 Sealed Classes preview feature.

Re: RFR: JDK-8225056 VM support for sealed classes

2020-05-20 Thread Harold Seigel
t should be done under one bug id. Overall this looks good. I've looked at all files and mainly have some style nits in various places. But there are some more significant items below. On 14/05/2020 7:09 am, Harold Seigel wrote: Hi, Please review this patch for JVM and Core-libs s

Re: RFR: JDK-8225056 VM support for sealed classes

2020-05-19 Thread Harold Seigel
d at all files and mainly have some style nits in various places. But there are some more significant items below. On 14/05/2020 7:09 am, Harold Seigel wrote: Hi, Please review this patch for JVM and Core-libs support for the JEP 360 Sealed Classes preview feature.  Code changes include the

Re: RFR: JDK-8225056 VM support for sealed classes

2020-05-19 Thread Harold Seigel
the RFRs across different areas, but it should be done under one bug id. Overall this looks good. I've looked at all files and mainly have some style nits in various places. But there are some more significant items below. On 14/05/2020 7:09 am, Harold Seigel wrote: Hi, Please review thi

RFR: JDK-8225056 VM support for sealed classes

2020-05-13 Thread Harold Seigel
Hi, Please review this patch for JVM and Core-libs support for the JEP 360 Sealed Classes preview feature.  Code changes include the following: * Processing of the new PermittedSubclasses attribute to enforce that a class or interface, whose super is a sealed class or interface, must be

Re: RFR 8235359: Simplify method Class.getRecordComponents()

2019-12-05 Thread Harold Seigel
Thanks Mandy! Harold On 12/5/2019 1:59 PM, Mandy Chung wrote: Looks good. Mandy On 12/5/19 6:36 AM, Harold Seigel wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. Open Webrev

Re: RFR 8235359: Simplify method Class.getRecordComponents()

2019-12-05 Thread Harold Seigel
Thanks Vicente! Harold On 12/5/2019 11:44 AM, Vicente Romero wrote: looks good, Vicente On 12/5/19 9:36 AM, Harold Seigel wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. Open

Re: RFR 8235359: Simplify method Class.getRecordComponents()

2019-12-05 Thread Harold Seigel
Thanks Lois and Chris! Harold On 12/5/2019 9:56 AM, Chris Hegarty wrote: On 5 Dec 2019, at 14:36, Harold Seigel <mailto:harold.sei...@oracle.com>> wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordCompone

Re: RFR 8235359: Simplify method Class.getRecordComponents()

2019-12-05 Thread Harold Seigel
Thanks Fred! Harold On 12/5/2019 9:50 AM, Frederic Parain wrote: Looks good to me. Fred On Dec 5, 2019, at 09:36, Harold Seigel wrote: Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent

RFR 8235359: Simplify method Class.getRecordComponents()

2019-12-05 Thread Harold Seigel
Hi, Please review this small change to simplify Class.getRecordComponents() by changing the return type of getRecordComponents0() to RecordComponent[]. Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.html JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8235359 T

Re: RFR 8184289: Obsolete -XX:+UnsyncloadClass and -XX:+MustCallLoadClassInternal options

2018-02-12 Thread harold seigel
ed case 3 and renumbered, so old references to case 4 -> case 3 ,and old references to case 5 become case 4: So - line 786, “Case 4” -> “case 3” thanks, Karen On Feb 12, 2018, at 11:13 AM, harold seigel <mailto:harold.sei...@oracle.com>> wrote: Hi Alan, Thanks for looking a

Re: RFR 8184289: Obsolete -XX:+UnsyncloadClass and -XX:+MustCallLoadClassInternal options

2018-02-12 Thread harold seigel
Hi Alan, Thanks for looking at this. Harold On 2/12/2018 2:52 AM, Alan Bateman wrote: On 12/02/2018 06:54, David Holmes wrote: Hi Harold, Adding core-libs-dev so they are aware of the ClassLoader change. Thanks, that part is okay and good to see this going away. -Alan

Re: RFR 8165634: Support multiple --add-module options on the command line

2016-09-09 Thread harold seigel
Thanks Lois, for the review. Harold On 9/8/2016 1:12 PM, Lois Foltan wrote: On 9/8/2016 9:23 AM, harold seigel wrote: Hi, Please review this fix for JDK-8165634. The fix changes the --add-modules option from being a 'last one wins' option to a cumulative one. With this

Re: RFR 8165634: Support multiple --add-module options on the command line

2016-09-09 Thread harold seigel
les=java.base -version”? Thanks for also reviewing the JDK changes. The core-libs reviewers asked that the support for duplicate --add-exports and --add-reads be removed from this webrev. (See next revision.) Duplicate --add-modules are allowed. cheers On Sep 8, 2016, at 8:23 AM, harold sei

RFR 8165634: Support multiple --add-module options on the command line

2016-09-08 Thread harold seigel
Hi, Please review this fix for JDK-8165634. The fix changes the --add-modules option from being a 'last one wins' option to a cumulative one. With this change, if multiple --add-modules options are specified, the VM accumulates all the options' values, instead of ignoring all but the last o

Re: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class

2016-09-02 Thread harold seigel
On 9/2/2016 4:17 PM, fo...@univ-mlv.fr wrote: - Mail original - De: "harold seigel" À: "Remi Forax" Cc: "Alan Bateman" , "Hotspot dev runtime" , core-libs-dev@openjdk.java.net Envoyé: Vendredi 2 Septembre 2016 20:32:55 Objet: Re: RFR 8058

Re: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class

2016-09-02 Thread harold seigel
arold, disallowing array classes as host classes seems unrelated and knowing that jdk 10 or 11 will certainly add default methods to arrays, we will want to have anonymous classes with arrays as host class in order to acts as bridges/mixins. regards, Rémi - Mail original - De: "harold

Re: RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class

2016-09-02 Thread harold seigel
Thanks Alan. I'll go ahead and make that change. Harold On 9/2/2016 10:43 AM, Alan Bateman wrote: On 02/09/2016 14:02, harold seigel wrote: Hi, Please review this new fix for JDK-8058575. This fix requires that a VM anonymous class be in either the same package as its host class o

RFR 8058575: IllegalAccessError trying to access package-private class from VM anonymous class

2016-09-02 Thread harold seigel
Hi, Please review this new fix for JDK-8058575. This fix requires that a VM anonymous class be in either the same package as its host class or be in the unnamed package. If the anonymous class is in the unnamed package then this fix puts it into its host class's package, ensuring that the a

Re: RFR(XS) 8148785: Update class file version to 53 for JDK-9

2016-02-03 Thread harold seigel
Hi Alan, Thanks for looking at the change. I'll drop the comment before checking it in. Harold On 2/3/2016 9:32 AM, Alan Bateman wrote: On 03/02/2016 14:12, harold seigel wrote: Hi Aleksey, Thanks for the review. The plan is to first change the runtime to accept version 53 file

  1   2   >