Hi,
Here is a patch addressing JDK-6425769. The issue is that the JMX agent
binds to the wildcard address by default, preventing users to use
system properties for JMX agents on multi-homed hosts. Given a host
with local network interfaces, 192.168.0.1 and 192.168.0.2 say, it's
impossible to start
> changing the existing one (adding SslRmiServerSocketFactory public
> constructors) so compatibility review process will have to be
> involved.
OK. What exactly is there for me to do? I'm not familiar with this
process. Note that the intent would be to get this backported
oking for a sponsor and a hotspot/servicability-dev
reviewer. Could somebody maintaining javax.rmi.ssl have a look at this
as well? Thank you!
Cheers,
Severin
On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote:
> On 2.11.2015 19:06, Severin Gehwolf wrote:
> > Hi,
> >
>
On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote:
> Hi,
>
> Updated webrev with jtreg test in Java:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/
> bug: https://bugs.openjdk.java.net/browse/JDK-6425769
>
> I believe this updated webrev addre
k.java.net/browse/JDK-6425769
webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/
Thanks,
Severin
On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote:
> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote:
> > Hi,
> >
> > Up
On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote:
> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote:
> > Hi,
> >
> > Updated webrev with jtreg test in Java:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/
> > bug: https://bugs.op
Hi Jaroslav,
On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote:
> On 1.12.2015 11:17, Severin Gehwolf wrote:
> > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote:
> > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote:
> > > > Hi,
> &
On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote:
> Hi Jaroslav,
>
> On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote:
> > On 1.12.2015 11:17, Severin Gehwolf wrote:
> > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote:
> > > &g
On Wed, 2015-12-09 at 14:58 +0100, Jaroslav Bachorik wrote:
> On 9.12.2015 14:55, Severin Gehwolf wrote:
> > On Tue, 2015-12-01 at 14:19 +0100, Severin Gehwolf wrote:
> > > Hi Jaroslav,
> > >
> > > On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote:
On Tue, 2015-12-22 at 17:50 +0100, Jaroslav Bachorik wrote:
> Please, review this trivial test change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8145982
> Webrev: http://cr.openjdk.java.net/~jbachorik/8145982/webrev.00
>
> The test calls System.exit(0) in case when it is not applicable
Hi,
On Wed, 2016-01-13 at 10:51 -0800, serguei.spit...@oracle.com wrote:
> On 1/13/16 03:16, Jaroslav Bachorik wrote:
> > On 12.1.2016 12:55, serguei.spit...@oracle.com wrote:
> > > On 1/12/16 03:49, Jaroslav Bachorik wrote:
> > > > On 12.1.2016 11:47, serguei.spit...@oracle.com wrote:
> > > > > O
Hi,
On Fri, 2016-01-15 at 09:50 +0100, Jaroslav Bachorik wrote:
> > Sorry for being late in the game with this.
> >
> > +private static List getAddressesForLocalHost() {
> > +
> > try {
> > -addrs = InetAddress.getAllByName("localhost");
> > -} catch (UnknownHost
On Fri, 2016-01-15 at 10:28 +0100, Jaroslav Bachorik wrote:
> On 15.1.2016 10:24, Severin Gehwolf wrote:
> > Hi,
> >
> > On Fri, 2016-01-15 at 09:50 +0100, Jaroslav Bachorik wrote:
> > > > Sorry for being late in the game with this.
> >
Hi,
Could somebody please review and sponsor this small 8u bugfix? This bug
has been introduced with the January 2016 CPU fixes (JDK-8130710) and
I've not seen this code in JDK 9 (yet?). Hence, posting this here.
Bug: https://bugs.openjdk.java.net/browse/JDK-8147857
webrev: http://cr.openjdk.java
Thanks, Jaroslav. Any JDK 8 reviewer willing to have a look at this?
Thanks,
Severin
On Thu, 2016-01-21 at 12:01 +0100, Jaroslav Bachorik wrote:
> On 21.1.2016 11:30, Severin Gehwolf wrote:
> > Hi,
> >
> > Could somebody please review and sponsor this small 8u bugfix?
On Thu, 2016-01-21 at 18:03 +0100, Daniel Fuchs wrote:
> On 21/01/16 15:20, Severin Gehwolf wrote:
> > Thanks, Jaroslav. Any JDK 8 reviewer willing to have a look at this?
>
> Looks good to me Severin.
Thank you, Daniel!
Cheers,
Severin
> best regards,
>
> -
Hi Daniil,
On Wed, 2019-07-17 at 18:26 -0700, Daniil Titov wrote:
> Hi Chris,
>
> Yes, I added output.reportDiagnosticSummary() in webrev-01, but removed it
> In webrev-02, and later restored it in webrev-03.
>
> When the test runs of retries output.getExitValue() is set to 1
> (COMMUNICATION_
On Wed, 2019-12-04 at 08:32 -0500, Bob Vandette wrote:
> You can try to use containerMetrics.getPerCpuUsage() instead of
> containerMetrics.getEffectiveCpuSetCpus().
> The length of the array returned is the number of host cpus. Maybe Severin
> can confirm if this true in cgroupv2 as
> well.
If
This patch adds some explicit capacity for local refs. New regression test
fails prior and passes after the patch.
Thoughts?
-
Commit messages:
- 8258836: JNI local refs exceed capacity getDiagnosticCommandInfo
Changes: https://git.openjdk.java.net/jdk/pull/2130/files
Webrev: http
On Mon, 18 Jan 2021 23:06:07 GMT, David Holmes 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 contai
> This patch adds some explicit capacity for local refs. New regression test
> fails prior and passes after the patch.
>
> 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
On Tue, 19 Jan 2021 09:41:27 GMT, Aleksey Shipilev 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 contai
On Mon, 18 Jan 2021 14:10:56 GMT, Severin Gehwolf wrote:
> This patch adds some explicit capacity for local refs. New regression test
> fails prior and passes after the patch.
>
> Thoughts?
Thanks for the review! More thoughts?
-
PR: https://git.openjdk.java.net/jdk/pull/2130
> This patch adds some explicit capacity for local refs. New regression test
> fails prior and passes after the patch.
>
> Thoughts?
Severin Gehwolf has updated the pull request incrementally with one additional
commit since the last revision:
Actually assign the variable r
> This patch adds some explicit capacity for local refs. New regression test
> fails prior and passes after the patch.
>
> 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
On Tue, 19 Jan 2021 19:55:22 GMT, Chris Plummer 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 contai
> This patch adds some explicit capacity for local refs. New regression test
> fails prior and passes after the patch.
>
> Thoughts?
Severin Gehwolf has updated the pull request incrementally with two additional
commits since the last revision:
- Improve popping of local frames
On Thu, 21 Jan 2021 09:06:00 GMT, Aleksey Shipilev 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 Wed, 20 Jan 2021 21:20:43 GMT, Chris Plummer 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, 21 Jan 2021 20:46:12 GMT, Chris Plummer wrote:
> Getting close:
>
> * Line 188 where there is a JNU_ThrowOutOfMemoryError needs a
> PopLocalFrame before it.
> * Copyrights need updating
Should be fixed now. Thoughts?
-
PR: https://git.openjdk.java.net/jdk/pull/213
> This patch adds some explicit capacity for local refs. New regression test
> fails prior and passes after the patch.
>
> 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
On Thu, 21 Jan 2021 20:46:12 GMT, Chris Plummer wrote:
>> Severin Gehwolf has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Improve popping of local frames in the error case
>> - Make HOTSPOT_DIAGNOSTIC
On Fri, 22 Jan 2021 20:18:39 GMT, Chris Plummer 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 cont
On Mon, 18 Jan 2021 14:10:56 GMT, Severin Gehwolf wrote:
> This patch adds some explicit capacity for local refs. New regression test
> fails prior and passes after the patch.
>
> Thoughts?
This pull request has now been integrated.
Changeset: af155fc0
Author:Severin
On Tue, 13 Apr 2021 06:55:20 GMT, Yasumasa Suenaga wrote:
>> I got -1.0 from both CpuLoad and SystemCpuLoad in OperatingSystem MXBean
>> when I run the application on Fedora 33 x64 which is installed cgroups V2.
>>
>>  may return 1.0 in a container, even though
> the CPU load is obviously below 100%.
>
> We created a 5-core container and run 4 "while (true)" loops in the
> container. OperatingSystemImpl.getCpuLoad() returne
On Thu, 6 May 2021 12:36:09 GMT, Severin Gehwolf wrote:
>>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in
>>> that case.
>>
>> Yes, flag `PreferContainerQuotaForCPUCount` is [true by
>> default](https://github.com/openjdk/jd
On Thu, 6 May 2021 16:31:57 GMT, Argha C
wrote:
>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in
>> that case.
>
>> @argha-c The proposed fix is within the `quota > 0` condition. I.e. this is
>> code only run when CPU quotas, _not_ shares are in effect. In docker/pod
On Tue, 11 May 2021 14:57:32 GMT, Hao Tang
wrote:
>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though
>> the CPU load is obviously below 100%.
>>
>> We created a 5-core container and run 4 "while (true)" loops in the
>> container. OperatingSystemImpl.getCpuLoad() re
On Tue, 11 May 2021 15:48:43 GMT, Hao Tang
wrote:
>>> Thanks for linking that. It sounds reasonable to me to prefer `quota` in
>>> that case.
>>
>> Yes, flag `PreferContainerQuotaForCPUCount` is [true by
>> default](https://github.com/openjdk/jdk/blob/739769c8/src/hotspot/os/linux/globals_lin
On Tue, 25 May 2021 06:25:23 GMT, Hao Tang
wrote:
>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though
>> the CPU load is obviously below 100%.
>>
>> We created a 5-core container and run 4 "while (true)" loops in the
>> container. OperatingSystemImpl.getCpuLoad() re
On Tue, 25 May 2021 06:25:23 GMT, Hao Tang
wrote:
>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though
>> the CPU load is obviously below 100%.
>>
>> We created a 5-core container and run 4 "while (true)" loops in the
>> container. OperatingSystemImpl.getCpuLoad() re
On Tue, 25 May 2021 09:53:02 GMT, Severin Gehwolf wrote:
>> Hao Tang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix compile errors on MacOS
>
> Bumping number of required reviewers to 2 as I'm a c
On Tue, 25 May 2021 21:46:27 GMT, Hao Tang
wrote:
>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though
>> the CPU load is obviously below 100%.
>>
>> We created a 5-core container and run 4 "while (true)" loops in the
>> container. OperatingSystemImpl.getCpuLoad() re
On Tue, 25 May 2021 21:46:27 GMT, Hao Tang
wrote:
>> OperatingSystemImpl.getCpuLoad() may return 1.0 in a container, even though
>> the CPU load is obviously below 100%.
>>
>> We created a 5-core container and run 4 "while (true)" loops in the
>> container. OperatingSystemImpl.getCpuLoad() re
On Thu, 27 May 2021 00:47:23 GMT, Yasumasa Suenaga wrote:
> I haven't followed yet all of discussions in this review, but I concern this
> PR changes the meaning of `getCpuLoad()`.
Does it? Here is the javadoc:
https://docs.oracle.com/en/java/javase/16/docs/api/jdk.management/com/sun/management
On Thu, 27 May 2021 08:37:11 GMT, Hao Tang
wrote:
>> I haven't followed yet all of discussions in this review, but I concern this
>> PR changes the meaning of `getCpuLoad()`.
>>
>> `getCpuLoad()` has been based on total time since the start of the
>> container, but after this PR, it is based
Please review this trivial patch. Stubs should return `-1` for `jlong` rather
than `-1.0` (`double`) on aix/macosx.
Thoughts?
-
Commit messages:
- 8268103: JNI functions incorrectly return a double after JDK-8265836
Changes: https://git.openjdk.java.net/jdk/pull/4300/files
Webre
On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf wrote:
> Please review this trivial patch. Stubs should return `-1` for `jlong`
> rather than `-1.0` (`double`) on aix/macosx.
>
> Thoughts?
Thanks for the reviews!
-
PR: https://git.openjdk.java.net/jdk/pull/4300
On Wed, 2 Jun 2021 08:58:06 GMT, Severin Gehwolf wrote:
> Please review this trivial patch. Stubs should return `-1` for `jlong`
> rather than `-1.0` (`double`) on aix/macosx.
>
> Thoughts?
This pull request has now been integrated.
Changeset: 2963c9e6
Author:Severin
On Sun, 6 Jun 2021 14:47:31 GMT, UncleNine
wrote:
> If the /proc/stat mount point is changed in container environment, the while
> loop may lead to 100% cpu usage.
In what way have you observed /proc/stat being changed which manifests in 100%
cpu usage?
-
PR: https://git.openjdk
On Tue, 8 Jun 2021 16:43:14 GMT, UncleNine
wrote:
>> In my case, it happened in the container environment.
>> the /proc filesystem of the container is provided by lxcfs, but a lxcfs bug
>> may make the /proc/stat mount point change, then the file descriptor is
>> different and fgetc functio
On Wed, 9 Jun 2021 14:45:35 GMT, UncleNine
wrote:
>> If the /proc/stat mount point is changed in container environment, the while
>> loop may lead to 100% cpu usage.
>
> UncleNine has refreshed the contents of this pull request, and previous
> commits have been removed. The incremental views w
On Thu, 10 Jun 2021 12:28:37 GMT, UncleNine
wrote:
>> If the /proc/stat mount point is changed in container environment, the while
>> loop may lead to 100% cpu usage.
>
> UncleNine has refreshed the contents of this pull request, and previous
> commits have been removed. The incremental views
On Wed, 7 Jul 2021 07:55:10 GMT, xpbob
wrote:
>> …ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit
> since the last revision:
>
> remove empty line
This patch seems fine in principle, but I don't like the duplication. Right
now,
On Wed, 7 Jul 2021 07:50:51 GMT, Yasumasa Suenaga wrote:
> In HotSpot, CPU usage for JVM would be calculated at `get_jvm_tickes()` in
> os_perf_linux.cpp . It refers `/proc/self/stat` - should we refer it in same
> way?
>
> I discussed about similar issue in #4299 , then we came to an agreemen
On Wed, 7 Jul 2021 08:31:22 GMT, Severin Gehwolf wrote:
> This patch seems fine in principle [...]
Let me revise this. It looks like imposing CPU limits via cpuset-cpus would go
down a path which won't have this fixed with the current patch.
-
PR: https://git.openjdk.java
On Thu, 8 Jul 2021 02:51:09 GMT, xpbob
wrote:
>> …ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit
> since the last revision:
>
> remove whitespace
Thanks for the update. `getProcessCpuLoad()` and `getCpuLoad()` looks way too
sim
On Mon, 12 Jul 2021 03:46:23 GMT, xpbob
wrote:
> > Thanks for the update. `getProcessCpuLoad()` and `getCpuLoad()` looks way
> > too similar to me. Is there a way to make them more generic and do the
> > process vs. system paths as needed? I think there is.
>
> use getCpuLoadWithTarget for pr
On Tue, 13 Jul 2021 05:19:25 GMT, xpbob
wrote:
>> …ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Set 1.0 for cpu set max
https://github.com/jerboaa/jdk/actions/runs/1026610314 is a pre-integration
On Tue, 13 Jul 2021 05:19:25 GMT, xpbob
wrote:
>> …ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Set 1.0 for cpu set max
Except for the missing comments in the new code blocks this looks good to m
On Wed, 14 Jul 2021 04:00:39 GMT, xpbob
wrote:
>> …ocess cpu usage in containers
>
> xpbob has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Add comments
Still looks good.
-
Marked as reviewed by sgehwolf (Reviewer).
PR: htt
On Wed, 30 Mar 2022 06:20:19 GMT, xpbob wrote:
>> ```
>>long hostTicks = getHostTotalCpuTicks0();
>> int totalCPUs = getHostOnlineCpuCount0();
>> int containerCPUs = getAvailableProcessors();
>> // scale the total host load t
On Wed, 30 Mar 2022 09:17:03 GMT, Kevin Walls wrote:
> Hi, Could the bug description be updated to state what the problem is, and
> under what circumstances is there a problem?
+1
-
PR: https://git.openjdk.java.net/jdk/pull/8028
On Wed, 30 Mar 2022 09:49:47 GMT, xpbob wrote:
>> src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java
>> line 96:
>>
>>> 94: int containerCPUs = getAvailableProcessors();
>>> 95: // scale the total host load to the actual containe
On Wed, 30 Mar 2022 11:02:18 GMT, xpbob wrote:
>> ```
>>long hostTicks = getHostTotalCpuTicks0();
>> int totalCPUs = getHostOnlineCpuCount0();
>> int containerCPUs = getAvailableProcessors();
>> // scale the total host load t
67 matches
Mail list logo
