RFR (M) 8023041: The CDS classlist needs to be updated for JDK 8

2013-11-13 Thread harold seigel
Hi, Please review this fix, submitted by Ekaterina Pavlova, to update the CDS classlist files for JDK 8. The classlist files were generated using the process described in jdk/make/tools/sharing/README.txt. In addition, a checksum was included. The open webrev is at:

Re: RFR (M) 8023041: The CDS classlist needs to be updated for JDK 8

2013-11-14 Thread harold seigel
Hi Alan, Thank you for the review. Harold On 11/13/2013 10:04 AM, Alan Bateman wrote: On 13/11/2013 14:55, harold seigel wrote: Hi, Please review this fix, submitted by Ekaterina Pavlova, to update the CDS classlist files for JDK 8. The classlist files were generated using the process

RFR 8022259 MakeClasslist tool is buggy and its README is out of date.

2013-08-09 Thread harold seigel
Hi, Please review this small fix for bug 8022259. This change fixes a bug in the MakeClasslist tool and updates its README.txt file. webrev: http://cr.openjdk.java.net/~hseigel/bug_8022259/ http://cr.openjdk.java.net/%7Ehseigel/bug_8022259/ bug:

Re: RFR 8022259 MakeClasslist tool is buggy and its README is out of date.

2013-08-12 Thread harold seigel
is used. I plan to file a bug stating that the classlists need to be updated for JDK 8 and assign it to release engineering. Thanks, Harold On 8/12/2013 4:46 AM, Alan Bateman wrote: On 07/08/2013 20:51, harold seigel wrote: Hi, Please review this small fix for bug 8022259. This change fixes

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

2016-02-03 Thread harold seigel
Hi, Please review this small change to fix bug 8148785. The fix bumps the class file version to 53 for JDK-9. Open webrevs: http://cr.openjdk.java.net/~hseigel/bug_8148785.jdk/ http://cr.openjdk.java.net/~hseigel/bug_8148785.hs/ JBS Bug:

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 files

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

2016-02-03 Thread harold seigel
Thanks, Harold On 2/3/2016 8:36 AM, Aleksey Shipilev wrote: On 02/03/2016 04:16 PM, harold seigel wrote: Open webrevs: http://cr.openjdk.java.net/~hseigel/bug_8148785.jdk/ http://cr.openjdk.java.net/~hseigel/bug_8148785.hs/ +1 JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8

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

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

2016-09-02 Thread harold seigel
, 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 s

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" <harold.sei...@oracle.com> À: "Remi Forax" <fo...@univ-mlv.fr> Cc: "Alan Bateman" <alan.bate...@oracle.com>, "Hotspot dev runtime&qu

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

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

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

2016-09-09 Thread harold seigel
ava.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 seig

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 change

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 8184289: Obsolete -XX:+UnsyncloadClass and -XX:+MustCallLoadClassInternal options

2018-02-12 Thread harold seigel
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 <harold.sei...@oracle.com <mailto:harold.sei...@oracle.com>> wrote: Hi Alan,

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

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

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 getRecordCo

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

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

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

2020-05-19 Thread Harold Seigel
iles 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 followi

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

2020-05-19 Thread Harold Seigel
oss 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 this patch for JVM a

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

2020-05-20 Thread Harold Seigel
uld 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 support for

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/webrev.01

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,

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

2020-05-21 Thread Harold Seigel
ave 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 following:   * P

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

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-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 =

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

2020-05-31 Thread Harold Seigel
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: http://cr.openjdk.java.net/~hseigel

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 of the JDK

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

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 mechanism

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

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"

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,

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 a

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: 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"

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

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

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 [v3]

2020-12-08 Thread Harold Seigel
h Mach5 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 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 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
h Mach5 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 [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: 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()?

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: 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 >

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 >

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

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

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

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

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

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:

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

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

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 li

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 R

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: 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.

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. > >

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

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. > >

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

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-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 [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 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: 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: 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

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:

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:

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:

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

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 ':'s. For example, an entry

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 example, an entry of >

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

2021-08-17 Thread Harold Seigel
p 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 pull request incrementally

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 example, an entry of >

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

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

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

2021-08-18 Thread Harold Seigel
p 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 pull request incrementally

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 ':'s. For example, an entry

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

2021-08-18 Thread Harold Seigel
p 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 pull request incrementally

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 ':'s. For example, an entry

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:

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

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

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

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

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: -

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

  1   2   >