gt;
> *Testing*
> - [x] Container tests on Linux x86_64 cgv1 and cgv2
> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with
> swapaccount=0
> - [ ] GHA in progress
>
> Thoughts?
Severin Gehwolf has updated the pull request with a new target base due to a
mer
On Thu, 19 Jan 2023 17:24:57 GMT, Severin Gehwolf wrote:
>> Please review this refactoring of a container test. It now uses WhiteBox to
>> retrieve the host values it asserts for. In terms of functionality this is
>> basically a no-op except for the now more precise asserti
On Thu, 19 Jan 2023 17:24:57 GMT, Severin Gehwolf wrote:
>> Please review this refactoring of a container test. It now uses WhiteBox to
>> retrieve the host values it asserts for. In terms of functionality this is
>> basically a no-op except for the now more precise asserti
gt;
> *Testing*
> - [x] Container tests on Linux x86_64 cgv1 and cgv2
> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with
> swapaccount=0
> - [x] GHA in progress
>
> Thoughts?
Severin Gehwolf has updated the pull request incrementally with one additi
gt;
> *Testing*
> - [x] Container tests on Linux x86_64 cgv1 and cgv2
> - [x] Container tests on Linux x86_64 cgv1 and cgv2 on systems with
> swapaccount=0
> - [x] GHA in progress
>
> Thoughts?
Severin Gehwolf has updated the pull request incrementally with one additi
On Tue, 24 Jan 2023 08:48:13 GMT, Matthias Baesken 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 conta
On Thu, 19 Jan 2023 13:57:57 GMT, Severin Gehwolf wrote:
> Please review this refactoring of a container test. It now uses WhiteBox to
> retrieve the host values it asserts for. In terms of functionality this is
> basically a no-op except for the now more precise assertion on sys
Please review these test changes which implement automatic testing of container
resource updates without JVM restart. Note that this merely tests container
detection code handling this case. It doesn't do anything special for the JVM
itself, though it might make sense to add some sanity checks s
der to make them cooperate. Note that the
> new test needs `podman` version `4.3.0` and better (`4.5` is current).
>
> Testing:
> - [ ] GHA (still running)
> - [x] Linux x86_64 container tests on cg v1 and cg v2 system
> - [x] Newly added tests on Linux x86_64 cg v1 and cg
On Tue, 23 May 2023 09:04:11 GMT, Severin Gehwolf wrote:
>> Please review these test changes which implement automatic testing of
>> container resource updates without JVM restart. Note that this merely tests
>> container detection code handling this case. It doesn
On Thu, 1 Jun 2023 02:16:12 GMT, David Holmes wrote:
>> Anyone willing to review this?
>
> @jerboaa I can't really review the tests themselves but will run through our
> CI to see if they cause any problems. If not then they should be okay to add.
Thanks @dholmes-ora for running them through yo
On Mon, 22 May 2023 16:40:40 GMT, Severin Gehwolf wrote:
> Please review these test changes which implement automatic testing of
> container resource updates without JVM restart. Note that this merely tests
> container detection code handling this case. It doesn't do anything
On Tue, 23 May 2023 09:04:11 GMT, Severin Gehwolf wrote:
>> Please review these test changes which implement automatic testing of
>> container resource updates without JVM restart. Note that this merely tests
>> container detection code handling this case. It doesn
On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf 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 id
On Thu, 9 Jun 2022 19:19:44 GMT, Jayashree Huttanagoudar
wrote:
> This PR is to address :
> https://bugs.openjdk.org/browse/JDK-8135292?jql=labels%20%3D%20starter-bug
> Verified the build before and after the patch. Also below tests are run:
> Before Patch:
>
> $ make test TEST="jtreg:test/hot
On Fri, 10 Jun 2022 09:21:09 GMT, Jayashree Huttanagoudar
wrote:
> I didn't get much about what is jcheck !
When you click on the `Details` link you'll see:
- OCA signatory status must be verified
- Too few reviewers with at least role reviewer found (have 0, need at least 1)
Think of it a
On Tue, 21 Jun 2022 07:57:37 GMT, Jayashree Huttanagoudar
wrote:
> how to handle the scenarios where if something needs to be changed in the
> commit message or changes in any files that I realize after pushing and
> raising a PR ?
You don't need to change the commit messages. Once reviewed,
On Wed, 22 Jun 2022 14:44:02 GMT, Jayashree Huttanagoudar
wrote:
> ```
> $ git add
> $ git commit --amend --no-edit
>```
The `git commit --amend` changes the current commit. Don't use `--amend` and it
should be fine.
-
PR: https://git.openjdk.org/jdk/pull/9112
On Wed, 22 Jun 2022 14:08:41 GMT, Jayashree Huttanagoudar
wrote:
>> This PR is to address :
>> https://bugs.openjdk.org/browse/JDK-8135292?jql=labels%20%3D%20starter-bug
>> Verified the build before and after the patch. Also below tests are run:
>> Before Patch:
>>
>> $ make test TEST="jtreg:t
On Wed, 6 Jul 2022 03:52:30 GMT, xpbob wrote:
>> Container configuration information is useful for troubleshooting
>> problems,Exposing information in MBeans is ideal for monitoring, jConsole,
>> and other scenarios.
>> Results the following
>> .
PR: https://git.openjdk.org/jdk/pull/11199
On Thu, 17 Nov 2022 06:28:37 GMT, Poison wrote:
> As the title says, add the volatile modifier.
Please enable testing for your fork.
-
PR: https://git.openjdk.org/jdk/pull/11199
On Thu, 17 Nov 2022 09:43:39 GMT, Poison wrote:
>> As the title says, add the volatile modifier.
>
> Poison has updated the pull request incrementally with one additional commit
> since the last revision:
>
> 8297173: usageTicks and totalTicks should be volatile
@tianshuang If you /integrate
Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part of
the
JDK's Metrics API. The primary motivating factor is that it allows one to use
the
JDK's version of `Metrics` in GraalVM. See the bug for details as to why this is
needed.
Testing:
- [x] GraalVM builds with/withou
On Thu, 24 Aug 2023 13:37:36 GMT, Alan Bateman wrote:
> Something fishy here, is this working around a bug in GraaVM native image or
> why does this change need to be in JDK?
I've now realized that the bug had an incorrect statement in the description.
The cycle happens due to the `Runtime.get
On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman wrote:
> In this case, it seems a bit fragile to do it in CgroupUtil as it should be
> allowed to use any of the file system APIs to access cgroups or proc files.
In theory, yes. It should be able to use any file system APIs. Practically, it
doesn
On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman wrote:
>>> Something fishy here, is this working around a bug in GraaVM native image
>>> or why does this change need to be in JDK?
>>
>> I've now realized that the bug had an incorrect statement in the
>> description. The cycle happens due to the
On Thu, 24 Aug 2023 13:16:16 GMT, Severin Gehwolf wrote:
> Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part
> of the
> JDK's Metrics API. The primary motivating factor is that it allows one to use
> the
> JDK's version of `Metrics` in
On Mon, 28 Aug 2023 15:29:32 GMT, Alan Bateman wrote:
> > @AlanBateman Is there anything else you need me to do? If so, please let me
> > know. Thanks!
>
> I don't think the JDK is the right place to workaround this issue. Also, we
> really need to get back re-implementing FileInputStream and
On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan wrote:
> 8323640: [TESTBUG]testMemoryFailCount in
> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
> OOM killed
`1k` increments for a total of `512k` times seems overkill. Are you sure that's
needed to make the test pa
On Tue, 23 Jan 2024 01:58:40 GMT, sendaoYan wrote:
>> 8323640: [TESTBUG]testMemoryFailCount in
>> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail
>> because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional
> commit since the last rev
On Tue, 23 Jan 2024 13:04:43 GMT, sendaoYan wrote:
>> 8323640: [TESTBUG]testMemoryFailCount in
>> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail
>> because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional
> commit since the last rev
On Tue, 30 Jan 2024 10:57:09 GMT, Sebastian Lövdahl wrote:
> I have poked around in the JDK sources but not found any tests related to
> this. Is there some prior art to look at?
Please run container tests, which do some jcmd testing across containers (host
system runs `jcmd` and containers ha
On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian Lövdahl wrote:
> 8307977: jcmd and jstack broken for target processes running with elevated
> capabilities
`test/hotspot/jtreg/serviceability` tests would also be worth running.
-
PR Comment: https://git.openjdk.org/jdk/pull/17628#issuec
On Tue, 30 Jan 2024 13:57:43 GMT, Severin Gehwolf wrote:
>> 8307977: jcmd and jstack broken for target processes running with elevated
>> capabilities
>
> `test/hotspot/jtreg/serviceability` tests would also be worth running.
> Hi @jerboaa, thanks a lot for the hints! The
On Tue, 30 Jan 2024 10:47:22 GMT, Sebastian Lövdahl wrote:
> 8307977: jcmd and jstack broken for target processes running with elevated
> capabilities
This looks good to me, but would like for somebody from the serviceability
group to look at this as well. @plummercj perhaps?
> _Mailing list
On Fri, 9 Feb 2024 18:40:04 GMT, Sebastian Lövdahl wrote:
> One more question, can I do anything to help getting this backported to e.g.
> 21 and 17?
First, I suggest to wait a few weeks in order to see if there are any follow-up
bugs which show up in testing in mainline. Then start backportin
Please review this enhancement to the container detection code which allows it
to figure out whether the JVM is actually running inside a container (`podman`,
`docker`, `crio`), or with some other means that enforces memory/cpu limits by
means of the cgroup filesystem. If neither of those condit
On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf wrote:
> Please review this enhancement to the container detection code which allows
> it to figure out whether the JVM is actually running inside a container
> (`podman`, `docker`, `crio`), or with some other means that enforces
>
On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf wrote:
> Please review this enhancement to the container detection code which allows
> it to figure out whether the JVM is actually running inside a container
> (`podman`, `docker`, `crio`), or with some other means that enforces
>
rrent situation of
> claiming a containerized system being present when it's actually just a
> regular Linux system.
>
> Testing:
>
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including
> gtes
On Tue, 16 Apr 2024 14:40:46 GMT, Jan Kratochvil
wrote:
> IMHO `is_containerized()` is OK to return `false` even when running in a
> container but with no limitations set.
The idea here is to use this property to tune OpenJDK for in-container,
specifically k8s, use. In such a setup it's custo
On Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil
wrote:
>>> IMHO `is_containerized()` is OK to return `false` even when running in a
>>> container but with no limitations set.
>>
>> The idea here is to use this property to tune OpenJDK for in-container,
>> specifically k8s, use. In such a set
On Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil
wrote:
> Could not we rename `is_containerized()` to `use_container_limit()` ? As that
> is the current only purpose of `is_containerized()`.
I'm not sure. There is value to have `is_containerized()` like it would behave
after this patch. Speci
On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that e
On Tue, 16 Apr 2024 18:10:08 GMT, Thomas Stuefe wrote:
>> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 351:
>>
>>> 349: //
>>> 350: // We collect the read only mount option in the cgroup infos so as
>>> to have that
>>> 351: // info ready when determining is_containerized().
On Tue, 16 Apr 2024 18:16:33 GMT, Thomas Stuefe 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 conta
On Tue, 16 Apr 2024 18:21:29 GMT, Thomas Stuefe wrote:
> Why return here?
Because it's not useful to see containerized settings (other than the cg
version in use) after this patch. The JVM won't use them (uses the physical
settings instead). Why would you want to show the settings?
--
rrent situation of
> claiming a containerized system being present when it's actually just a
> regular Linux system.
>
> Testing:
>
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including
> gtes
On Mon, 22 Apr 2024 13:56:23 GMT, Jan Kratochvil
wrote:
> Anyway in this patch one could unify naming across variables/parameters, the
> same value is called `_is_ro`, `is_read_only`, `ro_opt`, `read_only`, `ro`.
I've tried to unify the naming a bit. Thanks for the review!
-
PR C
On Fri, 3 May 2024 15:58:11 GMT, Severin Gehwolf wrote:
>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 375:
>>
>>> 373: if (!c.isContainerized()) {
>>> 374: ostream.println(INDENT + "System not containerized.");
On Fri, 2024-05-31 at 14:44 +0200, Maksim Zuev wrote:
> Dear Sir/Madam,
>
> I encountered a problem while debugging the code. I am attaching the
> reproducer to this email in the Main.java file.
>
> When running it with the debugger without stepping, the application
> runs in less than a second
On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie wrote:
> The original way of building static libraries in the JDK was to use the
> configure argument --enable-static-build, which set the value of the make
> variable STATIC_BUILD. (Note that this is not the same as the source code
> defini
On Fri, 3 May 2024 16:05:30 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that e
rrent situation of
> claiming a containerized system being present when it's actually just a
> regular Linux system.
>
> Testing:
>
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including
> gtests)
&
On Fri, 7 Jun 2024 12:59:26 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that e
rrent situation of
> claiming a containerized system being present when it's actually just a
> regular Linux system.
>
> Testing:
>
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including
> gtests)
&
rrent situation of
> claiming a containerized system being present when it's actually just a
> regular Linux system.
>
> Testing:
>
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including
> gtest
On Tue, 16 Apr 2024 18:25:52 GMT, Thomas Stuefe 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 conta
On Tue, 25 Jun 2024 13:39:07 GMT, Jan Kratochvil
wrote:
> Currently this patch conflicts a lot with #19085
> (jerboaa:jdk-8331560-cgroup-controller-delegation).
Yes, I'll resolve it one way or another depending on which one goes in first.
-
PR Comment: https://git.openjdk.org/jdk
rrent situation of
> claiming a containerized system being present when it's actually just a
> regular Linux system.
>
> Testing:
>
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including
> gtests)
&
On Thu, 20 Jun 2024 17:37:05 GMT, Thomas Stuefe wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove problem listing of PlainRead which is reworked here
>
> src/hotspot/os/linux/
On Tue, 25 Jun 2024 13:54:46 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that e
On Tue, 25 Jun 2024 13:54:46 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that e
rrent situation of
> claiming a containerized system being present when it's actually just a
> regular Linux system.
>
> Testing:
>
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including
> gtests)
&
On Thu, 27 Jun 2024 18:40:09 GMT, Larry Cable wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 17 commits:
>>
>> - Refactor mount info matching to helper function
>> -
On Fri, 28 Jun 2024 15:41:48 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that e
On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf wrote:
> Please review this enhancement to the container detection code which allows
> it to figure out whether the JVM is actually running inside a container
> (`podman`, `docker`, `crio`), or with some other means that enforces
>
On Fri, 28 Jun 2024 15:41:48 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that e
On Thu, 4 Jul 2024 12:57:09 GMT, Thomas Stuefe wrote:
> The new System.map facility fails its tests when the JVM is using ZGC. The
> facility is working fine, but the test checks for the java heap to appear as
> committed non-shared memory segment, but on ZGC we reserve the memory as
> shared
On Fri, 5 Jul 2024 08:53:30 GMT, Thomas Stuefe wrote:
>> The new System.map facility fails its tests when the JVM is using ZGC. The
>> facility is working fine, but the test checks for the java heap to appear as
>> committed non-shared memory segment, but on ZGC we reserve the memory as
>> sha
Trivial comment only change in a test. Please review!
Thanks!
-
Commit messages:
- 8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file
Changes: https://git.openjdk.org/jdk/pull/20051/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20051&range=00
Issue:
On Fri, 5 Jul 2024 10:56:37 GMT, Thomas Stuefe wrote:
>> The new System.map facility fails its tests when the JVM is using ZGC. The
>> facility is working fine, but the test checks for the java heap to appear as
>> committed non-shared memory segment, but on ZGC we reserve the memory as
>> sha
On Fri, 5 Jul 2024 11:14:10 GMT, Severin Gehwolf wrote:
> Trivial comment only change in a test. Please review!
>
> Thanks!
Thanks for the review!
-
PR Comment: https://git.openjdk.org/jdk/pull/20051#issuecomment-2210765310
On Fri, 5 Jul 2024 11:14:10 GMT, Severin Gehwolf wrote:
> Trivial comment only change in a test. Please review!
>
> Thanks!
This pull request has now been integrated.
Changeset: ff49f677
Author: Severin Gehwolf
URL:
https://git.openjdk.org/j
Please review this simple test fix to exclude the test from being run on an
Alpine Linux system. Apparently default Alpine Linux systems don't have cgroups
set up by default the way other distros do. More info on the bug. I propose to
not run the test on musl systems.
-
Commit mess
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info
On Mon, 8 Jul 2024 14:26:29 GMT, Matthias Baesken wrote:
> Hi Severin, sure ! I put it into our build/test setup .
Thanks!
-
PR Comment: https://git.openjdk.org/jdk/pull/20076#issuecomment-2214368557
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info
On Mon, 8 Jul 2024 14:19:21 GMT, Severin Gehwolf wrote:
> Please review this simple test fix to exclude the test from being run on an
> Alpine Linux system. Apparently default Alpine Linux systems don't have
> cgroups set up by default the way other distros do. More info
On Mon, 22 Jul 2024 16:56:00 GMT, Severin Gehwolf wrote:
> Please review this fix for cgroups-based metrics reporting in the
> `jdk.internal.platform` package. This fix is supposed to address wrong
> reporting of certain limits if the limits aren't set at the leaf nodes.
>
Please review this fix for cgroups-based metrics reporting in the
`jdk.internal.platform` package. This fix is supposed to address wrong
reporting of certain limits if the limits aren't set at the leaf nodes.
For example, on cg v2, the memory limit interface file is `memory.max`.
Consider a cgr
333446). This
> patch adds a test using that framework among some simpler unit tests.
>
> Thoughts?
>
> Testing:
>
> - [x] GHA
> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
> - [x] Some manual testing using systemd slices
Severin Gehwolf has updated
333446). This
> patch adds a test using that framework among some simpler unit tests.
>
> Thoughts?
>
> Testing:
>
> - [x] GHA
> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
> - [x] Some manual testing using systemd slices
Severin Gehwolf has updated t
1 - 100 of 192 matches
Mail list logo
