Re: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v3]

2022-06-13 Thread Severin Gehwolf
On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf wrote: >> Please review this cleanup change in the cgroup subsystem which used to use >> hard-coded stack allocated >> buffers for concatenating strings in memory. We can use `stringStream` >> instead which doesn't h

Re: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v2]

2022-06-08 Thread Severin Gehwolf
On Wed, 8 Jun 2022 08:25:21 GMT, Severin Gehwolf wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54: >> >>> 52: } else { >>> 53: char *p = strstr(cgroup_path, _root); >>> 54: if (p != NULL && p == cgroup_pa

Re: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v3]

2022-06-08 Thread Severin Gehwolf
e verified also pass before the stringStream > change > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Remove fix for substring match - Changes: - all: https://git.openjdk.java.net/jdk/pull/8969/files -

Re: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v2]

2022-06-08 Thread Severin Gehwolf
On Wed, 8 Jun 2022 07:13:30 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains six addi

Re: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v2]

2022-06-07 Thread Severin Gehwolf
e verified also pass before the stringStream > change > > Thoughts? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional comm

Re: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code

2022-06-07 Thread Severin Gehwolf
On Wed, 1 Jun 2022 09:18:38 GMT, Severin Gehwolf wrote: > Please review this cleanup change in the cgroup subsystem which used to use > hard-coded stack allocated > buffers for concatenating strings in memory. We can use `stringStream` > instead which doesn't have the issue >

Integrated: 8287663 Add a regression test for JDK-8287073

2022-06-07 Thread Severin Gehwolf
On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf wrote: > This adds a regression test for a recent fix (JDK-8287073). I've restructured > the linux specific JDK code to call a separate static function to enable this > test. It'll help future tests too. > > Testing: > - [

Re: RFR: 8287663 Add a regression test for JDK-8287073

2022-06-07 Thread Severin Gehwolf
On Tue, 7 Jun 2022 04:17:44 GMT, Ioi Lam wrote: > > We should try to consolidate these test cases to improve maintainability. > > I filed [JDK-8287185](https://bugs.openjdk.org/browse/JDK-8287185) Agreed. Thanks for the review @iklam - PR:

RFR: 8287663 Add a regression test for JDK-8287073

2022-06-02 Thread Severin Gehwolf
This adds a regression test for a recent fix (JDK-8287073). I've restructured the linux specific JDK code to call a separate static function to enable this test. It'll help future tests too. Testing: - [x] Container tests continue to pass + GHA - [x] New regression test fails prior the code fix

RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code

2022-06-01 Thread Severin Gehwolf
Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue of hard-coding maximum lengths (and related checks) and makes the code, thus, easier

Re: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v3]

2022-05-25 Thread Severin Gehwolf
On Wed, 25 May 2022 15:51:04 GMT, Ioi Lam wrote: >> This PR fixes a bug found on an Ubuntu host that's mostly running with >> cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 >> mode. >> >> The container support code in the VM and JDK checks if we have >>

Re: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v3]

2022-05-25 Thread Severin Gehwolf
On Wed, 25 May 2022 08:40:48 GMT, Severin Gehwolf wrote: >> If you don't like the `default:` coding style, how about this: >> >> >> switch (info.getName()) { >> // Only the following controllers are important to Java. All >> // other contr

Re: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v2]

2022-05-25 Thread Severin Gehwolf
On Tue, 24 May 2022 19:49:35 GMT, Ioi Lam wrote: >> My bad. How about `Intentional incomplete switch. There are ...`? Anyway, >> why is the empty `default` case needed other than for the comment? > > To me, the `default:` switch is a clear indication that "everything else > comes here". So you

Re: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v2]

2022-05-24 Thread Severin Gehwolf
On Tue, 24 May 2022 16:09:54 GMT, Ioi Lam wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java >> line 155: >> >>> 153: // There are some controllers (such as freezer) that >>> Java doesn't >>> 154: // care about. Just ignore

Re: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller [v2]

2022-05-24 Thread Severin Gehwolf
On Tue, 24 May 2022 16:15:03 GMT, Ioi Lam wrote: >> This PR fixes a bug found on an Ubuntu host that's mostly running with >> cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 >> mode. >> >> The container support code in the VM and JDK checks if we have >>

Re: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller

2022-05-24 Thread Severin Gehwolf
On Mon, 23 May 2022 22:11:47 GMT, Ioi Lam wrote: > This PR fixes a bug found on an Ubuntu host that's mostly running with > cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode. > > The container support code in the VM and JDK checks if we have simultaneously >

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]

2022-05-23 Thread Severin Gehwolf
On Mon, 23 May 2022 09:24:19 GMT, Severin Gehwolf wrote: >> Also, I think the current PR could produce the wrong answer, if systemd is >> indeed running inside the container, and we have: >> >> >> "/user.slice/user-1000.slice/session-50.scope",// r

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]

2022-05-23 Thread Severin Gehwolf
On Thu, 19 May 2022 20:18:50 GMT, Ioi Lam wrote: >> I am wondering if the problem is this: >> >> We have systemd running on the host, and a different copy of systemd that >> runs inside the container. >> >> - They both set up `/user.slice/user-1000.slice/session-??.scope` within >> their own

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]

2022-05-19 Thread Severin Gehwolf
On Thu, 19 May 2022 05:58:31 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Refactor hotspot gtest >> - Separate into function. Fix comment. > > src/hotspot/

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]

2022-05-19 Thread Severin Gehwolf
On Thu, 19 May 2022 06:00:06 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Refactor hotspot gtest >> - Separate into function. Fix comment. > > src/hotspot/

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]

2022-05-19 Thread Severin Gehwolf
On Thu, 19 May 2022 05:53:19 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Refactor hotspot gtest >> - Separate into function. Fix comment. > > src/hotspot/

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2]

2022-05-19 Thread Severin Gehwolf
On Thu, 19 May 2022 07:02:13 GMT, Thomas Stuefe wrote: >> I'm not convinced the extra function makes the code more readable, but here >> it is. I can revert back if this is too much. > > @jerboaa Feel free to go back to your original variant. This was only a > proposal. understood.

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2]

2022-05-18 Thread Severin Gehwolf
On Tue, 17 May 2022 06:18:25 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Use stringStream to simplify controller path assembly > > src/hotspot/os/linux/cgrou

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2]

2022-05-18 Thread Severin Gehwolf
On Wed, 18 May 2022 18:09:54 GMT, Severin Gehwolf wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92: >> >>> 90: } >>> 91: ss.print_raw(_root, last_matching_slash_pos); >>> 92: _path = os::strdup(ss.base()

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3]

2022-05-18 Thread Severin Gehwolf
quot;haystack" > `cgroup_path` (not the other way round). > > Testing: > - [x] Added unit tests > - [x] GHA > - [x] Container tests on cgroups v1 Linux. Continue to pass Severin Gehwolf has updated the pull request incrementally with two additional commits since the las

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2]

2022-05-17 Thread Severin Gehwolf
On Tue, 17 May 2022 07:14:34 GMT, Thomas Stuefe wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92: >> >>> 90: } >>> 91: ss.print_raw(_root, last_matching_slash_pos); >>> 92: _path = os::strdup(ss.base()); >> >> Do you mean `Find the longest common

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2]

2022-05-17 Thread Severin Gehwolf
On Tue, 17 May 2022 05:55:47 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Use stringStream to simplify controller path assembly > > test/hotspot/gtest/runtime/tes

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2]

2022-05-12 Thread Severin Gehwolf
On Thu, 12 May 2022 15:58:57 GMT, Severin Gehwolf wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 113: >> >>> 111: } >>> 112: buf[MAXPATHLEN-1] = '\0'; >>> 113: _path = os::strdup(buf); >>

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v2]

2022-05-12 Thread Severin Gehwolf
quot;haystack" > `cgroup_path` (not the other way round). > > Testing: > - [x] Added unit tests > - [x] GHA > - [x] Container tests on cgroups v1 Linux. Continue to pass Severin Gehwolf has updated the pull request incrementally with one additional commit since the la

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems

2022-05-12 Thread Severin Gehwolf
On Thu, 12 May 2022 14:00:44 GMT, Thomas Stuefe wrote: >> Please review this change to the cgroup v1 subsystem which makes it more >> resilient on some of the stranger systems. Unfortunately, I wasn't able to >> re-create a similar system as the reporter. The idea of using the longest >>

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v18]

2022-05-12 Thread Severin Gehwolf
On Thu, 12 May 2022 13:46:11 GMT, xpbob wrote: >> set memory.swappiness to 0,swap space will not be used >> determine the value of memory.swappiness >> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt >> >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >>

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v17]

2022-05-12 Thread Severin Gehwolf
On Thu, 12 May 2022 13:32:03 GMT, xpbob wrote: >> set memory.swappiness to 0,swap space will not be used >> determine the value of memory.swappiness >> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt >> >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >>

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v16]

2022-05-12 Thread Severin Gehwolf
On Thu, 12 May 2022 09:50:39 GMT, xpbob wrote: >> set memory.swappiness to 0,swap space will not be used >> determine the value of memory.swappiness >> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt >> >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >>

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems

2022-05-12 Thread Severin Gehwolf
On Thu, 12 May 2022 06:13:47 GMT, Ioi Lam wrote: > I just started to look at the code so just one comment for now. Sure, thanks for the review! - PR: https://git.openjdk.java.net/jdk/pull/8629

Re: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems

2022-05-12 Thread Severin Gehwolf
On Thu, 12 May 2022 06:11:03 GMT, Ioi Lam wrote: >> Please review this change to the cgroup v1 subsystem which makes it more >> resilient on some of the stranger systems. Unfortunately, I wasn't able to >> re-create a similar system as the reporter. The idea of using the longest >> substring

Re: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked

2022-05-11 Thread Severin Gehwolf
On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote: > I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to > the state previous to JDK-8160768, where an authentication failure stops from > trying other LDAP servers with the same credentials [1]. After JDK-8160768 we >

RFR: 8286212: Cgroup v1 initialization causes NPE on some systems

2022-05-10 Thread Severin Gehwolf
Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v15]

2022-05-04 Thread Severin Gehwolf
On Wed, 4 May 2022 01:37:27 GMT, xpbob wrote: >> set memory.swappiness to 0,swap space will not be used >> determine the value of memory.swappiness >> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt >> >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >>

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v14]

2022-05-03 Thread Severin Gehwolf
On Tue, 3 May 2022 13:38:07 GMT, xpbob wrote: >> set memory.swappiness to 0,swap space will not be used >> determine the value of memory.swappiness >> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt >> >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >>

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v12]

2022-05-03 Thread Severin Gehwolf
On Tue, 3 May 2022 09:21:11 GMT, xpbob wrote: >> set memory.swappiness to 0,swap space will not be used >> determine the value of memory.swappiness >> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt >> >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >>

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v6]

2022-04-27 Thread Severin Gehwolf
On Wed, 27 Apr 2022 10:34:33 GMT, xpbob wrote: >> set memory.swappiness to 0,swap space will not be used >> determine the value of memory.swappiness >> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt >> >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >>

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v6]

2022-04-27 Thread Severin Gehwolf
On Wed, 27 Apr 2022 14:24:50 GMT, Severin Gehwolf wrote: >> xpbob has updated the pull request incrementally with one additional commit >> since the last revision: >> >> revert file > > test/hotspot/jtreg/containers/docker/TestMisc.java line 60: > >>

Re: RFR: 8284950: CgroupV1 detection code should consider memory.swappiness [v2]

2022-04-20 Thread Severin Gehwolf
On Wed, 20 Apr 2022 18:18:25 GMT, xpbob wrote: >> set memory.swappiness to 0,swap space will not be used >> determine the value of memory.swappiness >> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt >> >> >> Memory Limit: 50.00M >> Memory Soft Limit: Unlimited >>

Re: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize [v2]

2022-03-23 Thread Severin Gehwolf
On Wed, 23 Mar 2022 09:27:07 GMT, Severin Gehwolf wrote: >> Please review this container test improvement. The test in question only >> makes sense iff the total swap space size as reported by the container aware >> OperatingSystemMXBean is `0`. If that's not the case, t

Integrated: 8283279: [Testbug] Improve TestGetSwapSpaceSize

2022-03-23 Thread Severin Gehwolf
On Thu, 17 Mar 2022 13:40:53 GMT, Severin Gehwolf wrote: > Please review this container test improvement. The test in question only > makes sense iff the total swap space size as reported by the container aware > OperatingSystemMXBean is `0`. If that's not the case, then somet

Re: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize [v2]

2022-03-23 Thread Severin Gehwolf
On Wed, 23 Mar 2022 03:06:00 GMT, Jie Fu wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains three addi

Re: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize [v2]

2022-03-23 Thread Severin Gehwolf
ses with > the fix, and fails without. Tested the test on cgroups v1 and cgroups v2. Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contain

Re: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize

2022-03-21 Thread Severin Gehwolf
On Thu, 17 Mar 2022 13:40:53 GMT, Severin Gehwolf wrote: > Please review this container test improvement. The test in question only > makes sense iff the total swap space size as reported by the container aware > OperatingSystemMXBean is `0`. If that's not the case, then somet

RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize

2022-03-17 Thread Severin Gehwolf
Please review this container test improvement. The test in question only makes sense iff the total swap space size as reported by the container aware OperatingSystemMXBean is `0`. If that's not the case, then something else might be amiss, e.g. OperatingSystemMXBean reporting the host swap

Re: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked

2022-03-11 Thread Severin Gehwolf
On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote: > I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to > the state previous to JDK-8160768, where an authentication failure stops from > trying other LDAP servers with the same credentials [1]. After JDK-8160768 we >

Re: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked

2022-02-08 Thread Severin Gehwolf
On Thu, 16 Dec 2021 01:23:11 GMT, Martin Balao wrote: >> Hi @AlekseiEfimov >> >> Can you please review the CSR [1]? >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8276959 > >> @martinuy This pull request has been inactive for more than 4 weeks and will

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

2021-11-02 Thread Severin Gehwolf
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

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

2021-10-28 Thread Severin Gehwolf
On Thu, 28 Oct 2021 14:04:15 GMT, Harold Seigel wrote: > The changes look good. Thanks for doing this. Harold Thanks for the review! - PR: https://git.openjdk.java.net/jdk/pull/6156

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

2021-10-28 Thread Severin Gehwolf
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 code. Testing: Container tests (cgroup v1) on Linux x86_64 (all

Integrated: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

2021-09-30 Thread Severin Gehwolf
On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf wrote: > Please review this test fix to work around a podman issue[1]. `podman` > expects for the "unlimited" option of `--pids-limit` to be `0` whereas > `docker` wants `-1`. See the JBS bug for details. Thoughts? >

Re: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

2021-09-29 Thread Severin Gehwolf
On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf wrote: > Please review this test fix to work around a podman issue[1]. `podman` > expects for the "unlimited" option of `--pids-limit` to be `0` whereas > `docker` wants `-1`. See the JBS bug for details. Thoughts? >

RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

2021-09-29 Thread Severin Gehwolf
Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts? Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and

Re: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v3]

2021-09-21 Thread Severin Gehwolf
On Mon, 20 Sep 2021 18:17:29 GMT, Lance Andersen wrote: >> Hi all, >> >> Please review this patch which addresses the issue where Zip FS will throw a >> UOE instead of returning null when Files.getFileAttributeView() is invoked >> and the view not supported. >> >> Mach5 tiers1 - tier3 are

Re: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported

2021-09-20 Thread Severin Gehwolf
On Sun, 19 Sep 2021 15:34:44 GMT, Lance Andersen wrote: > Hi all, > > Please review this patch which addresses the issue where Zip FS will throw a > UOE instead of returning null when Files.getFileAttributeView() is invoked > and the view not supported. > > Mach5 tiers1 - tier3 are clean.

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v4]

2021-09-15 Thread Severin Gehwolf
On Wed, 15 Sep 2021 07:46:34 GMT, Matthias Baesken wrote: >> https://bugs.openjdk.java.net/browse/JDK-8266490 >> extended the OSContainer API in order to also support the pids controller of >> cgroups. However only pids.max output was added with 8266490. >> There is a second parameter

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3]

2021-09-14 Thread Severin Gehwolf
On Tue, 14 Sep 2021 17:25:05 GMT, Ioi Lam wrote: > Maybe it should be "any_integer"? +1 - PR: https://git.openjdk.java.net/jdk/pull/5437

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v3]

2021-09-14 Thread Severin Gehwolf
On Tue, 14 Sep 2021 14:27:36 GMT, Matthias Baesken wrote: >> https://bugs.openjdk.java.net/browse/JDK-8266490 >> extended the OSContainer API in order to also support the pids controller of >> cgroups. However only pids.max output was added with 8266490. >> There is a second parameter

Re: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"

2021-09-14 Thread Severin Gehwolf
On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote: > Currently, the build system defaults the libjvm.so location to "server". > This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We > need to see if moving the libjvm.so to a proper location breaks anything. > >

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current [v2]

2021-09-10 Thread Severin Gehwolf
On Fri, 10 Sep 2021 11:07:52 GMT, Matthias Baesken wrote: >> https://bugs.openjdk.java.net/browse/JDK-8266490 >> extended the OSContainer API in order to also support the pids controller of >> cgroups. However only pids.max output was added with 8266490. >> There is a second parameter

Re: RFR: JDK-8273526: Extend the OSContainer API pids controller with pids.current

2021-09-09 Thread Severin Gehwolf
On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken wrote: > https://bugs.openjdk.java.net/browse/JDK-8266490 > extended the OSContainer API in order to also support the pids controller of > cgroups. However only pids.max output was added with 8266490. > There is a second parameter pids.current ,

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

2021-08-18 Thread Severin Gehwolf
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 of >>

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

2021-08-18 Thread Severin Gehwolf
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 of >>

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

2021-08-18 Thread Severin Gehwolf
On Tue, 17 Aug 2021 17:46:29 GMT, Severin Gehwolf wrote: >> Harold Seigel has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add test case, comments, and other small changes > > test/jd

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

2021-08-17 Thread Severin Gehwolf
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 of >>

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

2021-08-17 Thread Severin Gehwolf
On Tue, 17 Aug 2021 09:07:17 GMT, Severin Gehwolf 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 path contains colon

2021-08-17 Thread Severin Gehwolf
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: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v8]

2021-08-06 Thread Severin Gehwolf
On Thu, 5 Aug 2021 11:21:59 GMT, Matthias Baesken wrote: >> Hello, please review this PR; it extend the OSContainer API in order to also >> support the pids controller of cgroups. >> >> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", >> "memory" on some older Linux

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6]

2021-08-05 Thread Severin Gehwolf
On Thu, 5 Aug 2021 11:19:17 GMT, Matthias Baesken wrote: >>> What do you think about accepting, when setting -1/unlimited, a high limit >>> number like 20.000+ as well (and and a comment that on some setups >>> unlimited means just "high number" but not unlimited? >> >> This seems most

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6]

2021-08-02 Thread Severin Gehwolf
On Tue, 27 Jul 2021 10:25:22 GMT, Matthias Baesken wrote: > What do you think about accepting, when setting -1/unlimited, a high limit > number like 20.000+ as well (and and a comment that on some setups unlimited > means just "high number" but not unlimited? This seems most reasonable. I'd

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6]

2021-07-23 Thread Severin Gehwolf
On Fri, 23 Jul 2021 12:28:47 GMT, Severin Gehwolf wrote: > Could this be some setting configured on your box that is picked up as an > additional limit ? Possibly. Not sure where to look, though. - PR: https://git.openjdk.java.net/jdk/pull/4518

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6]

2021-07-23 Thread Severin Gehwolf
On Fri, 23 Jul 2021 11:02:13 GMT, Matthias Baesken wrote: > > No, I don't know what to do about it. All I can see it comes back with a > > pids limit of `38019` when set to `-1`. It does seem like a bug or an > > intentional setting so as to avoid fork bombs. > > Very strange indeed, I have

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v6]

2021-07-23 Thread Severin Gehwolf
On Fri, 23 Jul 2021 06:49:15 GMT, Matthias Baesken wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Minor adjustments, handling of Unlimited > >> @MBaesken Thanks. We need a solution for [#4518 >>

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v5]

2021-07-22 Thread Severin Gehwolf
On Thu, 22 Jul 2021 12:15:03 GMT, Matthias Baesken wrote: >> Matthias Baesken has updated the pull request with a new target base due to >> a merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains five additional

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v4]

2021-07-15 Thread Severin Gehwolf
On Thu, 15 Jul 2021 13:09:54 GMT, Matthias Baesken wrote: >> Hello, please review this PR; it extend the OSContainer API in order to also >> support the pids controller of cgroups. >> >> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", >> "memory" on some older Linux

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v2]

2021-07-09 Thread Severin Gehwolf
On Fri, 9 Jul 2021 11:35:34 GMT, Matthias Baesken wrote: > > This looks pretty good now. Looking forward to seeing container tests for > > this new code. > > Hi Severin , I did some adjustments following your suggestions. > I added docker based test coding for testing pids-limit (with limits

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v2]

2021-06-29 Thread Severin Gehwolf
On Wed, 23 Jun 2021 13:37:59 GMT, Matthias Baesken wrote: >> Hello, please review this PR; it extend the OSContainer API in order to also >> support the pids controller of cgroups. >> >> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", >> "memory" on some older Linux

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups [v2]

2021-06-23 Thread Severin Gehwolf
On Wed, 23 Jun 2021 13:38:58 GMT, Matthias Baesken wrote: > But I think that the testing needs to be enhanced (e.g. with some added > docker tests?). Do you have some good suggestions > where I could look at existing (docker?) tests and adjust those for the new > pids.max ? Have a look at

Re: RFR: JDK-8266490: Extend the OSContainer API to support the pids controller of cgroups

2021-06-17 Thread Severin Gehwolf
On Thu, 17 Jun 2021 12:27:25 GMT, Matthias Baesken wrote: > Hello, please review this PR; it extend the OSContainer API in order to also > support the pids controller of cgroups. > > I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", > "memory" on some older Linux

Re: RFR: 8203359: Container level resources events [v13]

2021-05-19 Thread Severin Gehwolf
On Wed, 19 May 2021 15:23:55 GMT, Jaroslav Bachorik wrote: >> With this change it becomes possible to surface various cgroup level metrics >> (available via `jdk.internal.platform.Metrics`) as JFR events. >> >> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is >>

Re: RFR: 8203359: Container level resources events [v11]

2021-05-19 Thread Severin Gehwolf
On Mon, 3 May 2021 13:16:06 GMT, Jaroslav Bachorik wrote: >> With this change it becomes possible to surface various cgroup level metrics >> (available via `jdk.internal.platform.Metrics`) as JFR events. >> >> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is >>

Re: RFR: 8203359: Container level resources events [v9]

2021-04-27 Thread Severin Gehwolf
On Thu, 22 Apr 2021 15:08:59 GMT, Jaroslav Bachorik wrote: >> I wonder if something similar to below could be added to >> jdk.jfr.internal.Utils: >> >> private static Metrics[] metrics; >> public static Metrics getMetrics() { >> if (metrics == null) { >> metrics =

Re: RFR: 8203359: Container level resources events [v10]

2021-04-27 Thread Severin Gehwolf
On Thu, 22 Apr 2021 16:00:32 GMT, Jaroslav Bachorik wrote: >> With this change it becomes possible to surface various cgroup level metrics >> (available via `jdk.internal.platform.Metrics`) as JFR events. >> >> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is >>

Re: RFR: 8203359: Container level resources events [v9]

2021-04-27 Thread Severin Gehwolf
On Thu, 22 Apr 2021 15:08:59 GMT, Jaroslav Bachorik wrote: >> I wonder if something similar to below could be added to >> jdk.jfr.internal.Utils: >> >> private static Metrics[] metrics; >> public static Metrics getMetrics() { >> if (metrics == null) { >> metrics =

Re: RFR: 8203359: Container level resources events [v8]

2021-04-14 Thread Severin Gehwolf
On Wed, 14 Apr 2021 12:03:12 GMT, Jaroslav Bachorik wrote: >> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerMemoryUsageEvent.java line >> 46: >> >>> 44: public final class ContainerMemoryUsageEvent extends AbstractJDKEvent { >>> 45: @Label("Memory Pressure") >>> 46:

Re: RFR: 8203359: Container level resources events

2021-03-26 Thread Severin Gehwolf
On Thu, 25 Mar 2021 23:28:18 GMT, Erik Gahlin wrote: > Does each getter call result in parsing /proc, or do things aggregated over > several calls or hooks? >From the looks of it the event emitting code uses `Metrics.java` interface for >retrieving the info. Each call to a method exposed by

Re: RFR: 8203359: Container level resources events

2021-03-24 Thread Severin Gehwolf
On Mon, 22 Mar 2021 15:57:12 GMT, Jaroslav Bachorik wrote: > With this change it becomes possible to surface various cgroup level metrics > (available via `jdk.internal.platform.Metrics`) as JFR events. > > Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is > turned

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

2021-03-01 Thread Severin Gehwolf
On Mon, 1 Mar 2021 14:33:06 GMT, Harold Seigel wrote: >> Fails prior the patch of JDK-8257746, passes after. As expected. >> >> Thoughts? > > The new tests looks good. Thanks for adding it. > > Harold Thanks for the review @hseigel! - PR:

Integrated: 8262379: Add regression test for JDK-8257746

2021-03-01 Thread Severin Gehwolf
On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf wrote: > Fails prior the patch of JDK-8257746, passes after. As expected. > > Thoughts? This pull request has now been integrated. Changeset: 4c9adce2 Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit

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

2021-03-01 Thread Severin Gehwolf
On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf wrote: > Fails prior the patch of JDK-8257746, passes after. As expected. > > Thoughts? @poonamparhar @hseigel Could you please take a look? It's just a simple regression test for the JDK-8257746 NPE regression. -

RFR: 8262379: Add regression test for JDK-8257746

2021-02-25 Thread Severin Gehwolf
Fails prior the patch of JDK-8257746, passes after. As expected. Thoughts? - Commit messages: - 8262379: Add regression test for JDK-8257746 Changes: https://git.openjdk.java.net/jdk/pull/2725/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2725=00 Issue:

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

2021-02-24 Thread Severin Gehwolf
On Wed, 24 Feb 2021 17:37:13 GMT, Severin Gehwolf wrote: >> Marked as reviewed by andrew (Reviewer). > > @gnu-andrew Thanks for the review! I'll retest and then integrate. Tests look good on my end. Also this check passed all Linux tests (it's a no-op everywhere else): https:

Integrated: 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection

2021-02-24 Thread Severin Gehwolf
On Mon, 23 Nov 2020 15:46:56 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 specifi

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

2021-02-24 Thread Severin Gehwolf
On Wed, 24 Feb 2021 16:24:32 GMT, Andrew John Hughes wrote: >> Severin Gehwolf has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add comment to parsing logic of /proc/self/cgroup > > Marked as reviewed by a

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

2021-02-24 Thread Severin Gehwolf
> and, thus, more cases can be tested that way without having access to these > specific systems. For example, proper regression tests for JDK-8217766 and > JDK-8253435 have been added now with this in place. > > * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container t

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

2021-02-12 Thread Severin Gehwolf
On Fri, 12 Feb 2021 10:19:03 GMT, Severin Gehwolf wrote: >> Hi Severin, >> Thanks for doing this! Sorry for taking so long to review this change. The >> change looks good. Before pushing it, could you add a comment explaining >> what the code in lines 185-194 of Cgr

  1   2   3   >