Re: A Bug about the JVM Attach mechanism

On 21/06/2019 11:57 am, Peter Levart wrote: Hi David, On 6/21/19 5:57 PM, David Holmes wrote: Hi Peter, On 21/06/2019 7:55 am, Peter Levart wrote: As far as I know, cron jobs that cleanup /tmp typically remove files that have not been modified for a while. On Fedora for example, there is a

Re: RFR 8215523: jstat reports incorrect values for OU for CMS GC

Hi Poonam, The fix looks Okay from the Serviceability point of view. Thanks, Serguei On 6/21/19 13:30, Poonam Parhar wrote: Updating the subject line with the updated bug synopsis. And also, much thanks to

Re: (13) RFR (S): 8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events

Thanks, Alex! Serguei On 6/21/19 17:51, Alex Menkov wrote: LGTM --alex On 06/21/2019 16:48, serguei.spit...@oracle.com wrote: Please, review a test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8226595 Webrev:

Re: (13) RFR (S): 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed

Thanks a lot! Serguei On 6/21/19 17:34, Alex Menkov wrote: Looks good to me too. --alex On 06/21/2019 11:38, serguei.spit...@oracle.com wrote: Hi Dan, On 6/21/19 06:44, Daniel D. Daugherty wrote: On 6/21/19 1:24 AM, serguei.spit...@oracle.com wrote: Please, review the test bug fix for:

Re: (13) RFR (S): 8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events

LGTM --alex On 06/21/2019 16:48, serguei.spit...@oracle.com wrote: Please, review a test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8226595 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226595-mon-events-correction.1/ Summary:   The recent fix of

Re: (13) RFR (S): 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed

Looks good to me too. --alex On 06/21/2019 11:38, serguei.spit...@oracle.com wrote: Hi Dan, On 6/21/19 06:44, Daniel D. Daugherty wrote: On 6/21/19 1:24 AM, serguei.spit...@oracle.com wrote: Please, review the test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8224555 Webrev:

(13) RFR (S): 8226595: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java still fails due to wrong number of MonitorContendedEntered events

Please, review a test bug fix for:   https://bugs.openjdk.java.net/browse/JDK-8226595 Webrev:   http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226595-mon-events-correction.1/ Summary:   The recent fix of

Re: A Bug about the JVM Attach mechanism

On 6/21/19 12:14 PM, Peter Levart wrote: On 6/21/19 8:38 PM, Chris Plummer wrote: On 6/21/19 8:57 AM, David Holmes wrote: Hi Peter, On 21/06/2019 7:55 am, Peter Levart wrote: As far as I know, cron jobs that cleanup /tmp typically remove files that have not been modified for a while. On

Re: RFR 8215523: jstat reports incorrect values for OU for CMS GC

Updating the subject line with the updated bug synopsis. And also, much thanks to Thomas Schatzl for his remarkable help in tweaking and refining this fix. regards, Poonam On 6/21/19 12:21 PM, Poonam Parhar wrote: Hello, Please review the changes for the fix of: Bug 8215523

Re: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][]

Hi, Egor On 6/20/19 8:49 AM, Alan Bateman wrote: On 20/06/2019 15:49, Egor Ushakov wrote: any news on https://bugs.openjdk.java.net/browse/JDK-8212117? I do not see any activity on this :( > cc'ing Brent as he has picked up this issue. I think we want to fix this and David has a patch in

RFR 8215523: Request for clarification in unexpected OU decrease with CMS GC

Hello, Please review the changes for the fix of: Bug 8215523 : jstat reports incorrect values for OU for CMS GC Webrev: http://cr.openjdk.java.net/~poonam/8215523/webrev.00/ Problem: With CMS, at certain points, 'OU' (Old usage) values

Re: A Bug about the JVM Attach mechanism

On 6/21/19 8:38 PM, Chris Plummer wrote: On 6/21/19 8:57 AM, David Holmes wrote: Hi Peter, On 21/06/2019 7:55 am, Peter Levart wrote: As far as I know, cron jobs that cleanup /tmp typically remove files that have not been modified for a while. On Fedora for example, there is a systemd timer

Re: RFR XS,docs,13 JDK-8226593 Fix HTML in com/sun/jdi/doc-files/signature.html

Hi Jon, It looks good to me. Thanks, Serguei On 6/21/19 11:58, Jonathan Gibbons wrote: Please review a fix for an accessibility issue reported by Axe in src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html The issue is a conflict between an explicit `role="main">...``  specified

Re: RFR XS,docs,13 JDK-8226593 Fix HTML in com/sun/jdi/doc-files/signature.html

+1 > On Jun 21, 2019, at 2:58 PM, Jonathan Gibbons > wrote: > > Please review a fix for an accessibility issue reported by Axe in > src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html > > The issue is a conflict between an explicit `...`` > specified in the file and the automatic

RFR XS,docs,13 JDK-8226593 Fix HTML in com/sun/jdi/doc-files/signature.html

Please review a fix for an accessibility issue reported by Axe in src/jdk.jdi/share/classes/com/sun/jdi/doc-files/signature.html The issue is a conflict between an explicit `role="main">...``  specified in the file and the automatic `` added by javadoc.  The fix is just to remove the ``

Re: A Bug about the JVM Attach mechanism

Hi David, On 6/21/19 5:57 PM, David Holmes wrote: Hi Peter, On 21/06/2019 7:55 am, Peter Levart wrote: As far as I know, cron jobs that cleanup /tmp typically remove files that have not been modified for a while. On Fedora for example, there is a systemd timer that triggers once per day

Re: Slow class loading when running JVM in debug mode

You might also want to have a look at: JDK:8214892: Delayed starting of debugging via jcmd This should allow you to defer initialization of the debug agent (and the creation of the loaded classes cache) until you turn on debugging using the jcmd

Re: A Bug about the JVM Attach mechanism

On 6/21/19 8:57 AM, David Holmes wrote: Hi Peter, On 21/06/2019 7:55 am, Peter Levart wrote: As far as I know, cron jobs that cleanup /tmp typically remove files that have not been modified for a while. On Fedora for example, there is a systemd timer that triggers once per day and executes

Re: (13) RFR (S): 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed

Hi Dan, On 6/21/19 06:44, Daniel D. Daugherty wrote: On 6/21/19 1:24 AM, serguei.spit...@oracle.com wrote: Please, review the test bug fix for:   https://bugs.openjdk.java.net/browse/JDK-8224555 Webrev:

Re: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout

I don't think so, the stack trace for JDK-8226367 shows the different problem. Best regards, Daniil On 6/21/19, 10:02 AM, "Gary Adams" wrote: Any chance this will also fix JDK-8226367 ? On 6/20/19, 10:39 PM, Chris Plummer wrote: > Thanks for looking into this. > >

Re: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout

Any chance this will also fix JDK-8226367 ? On 6/20/19, 10:39 PM, Chris Plummer wrote: Thanks for looking into this. Chris On 6/20/19 6:42 PM, Daniil Titov wrote: Thank you, Chris and Serguei, for reviewing this change. I did more testing with a test program on Linux that repeats

Re: A Bug about the JVM Attach mechanism

Hi Peter, On 21/06/2019 7:55 am, Peter Levart wrote: As far as I know, cron jobs that cleanup /tmp typically remove files that have not been modified for a while. On Fedora for example, there is a systemd timer that triggers once per day and executes systemd-tmpfiles which manages volatile

Re: A Bug about the JVM Attach mechanism

As far as I know, cron jobs that cleanup /tmp typically remove files that have not been modified for a while. On Fedora for example, there is a systemd timer that triggers once per day and executes systemd-tmpfiles which manages volatile and temporary files and directories. The configuration

Re: OperatingSystemMXBean unaware of container memory limits

Thanks! Cheers, Mario On Fri 21. Jun 2019 at 15:54, Bob Vandette wrote: > Here you go. > > https://bugs.openjdk.java.net/browse/JDK-8226575 > > Thanks, > Bob. > > On Jun 21, 2019, at 9:08 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Fri, 2019-06-21 at 08:56 -0400, Bob Vandette wrote: > > On

Re: A Bug about the JVM Attach mechanism

On 2019/06/21 22:51, David Holmes wrote: Hi Yasumasa, On 21/06/2019 5:12 am, Yasumasa Suenaga wrote: Hi, Can we fix this issue like this webrev?    http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal/ I'm not clear how this addresses the issue with deleting the file? The file still

Re: OperatingSystemMXBean unaware of container memory limits

Here you go. https://bugs.openjdk.java.net/browse/JDK-8226575 Thanks, Bob. > On Jun 21, 2019, at 9:08 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Fri, 2019-06-21 at 08:56 -0400, Bob Vandette wrote: >>> On Jun 21, 2019, at 4:22 AM, Severin

Re: A Bug about the JVM Attach mechanism

Hi Yasumasa, On 21/06/2019 5:12 am, Yasumasa Suenaga wrote: Hi, Can we fix this issue like this webrev?   http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal/ I'm not clear how this addresses the issue with deleting the file? The file still has to exist IIUC for the mechanism to

Re: (13) RFR (S): 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed

On 6/21/19 1:24 AM, serguei.spit...@oracle.com wrote: Please, review the test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8224555 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8224555-mon-events2-test.1/

Re: OperatingSystemMXBean unaware of container memory limits

> On Jun 21, 2019, at 4:22 AM, Severin Gehwolf wrote: > > Hi Bob, > > On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: >> Hi Andrew, >> >> I am aware of the limitations of the OperatingSystemMXBean and was >> hoping to address these limitations during the implementation of >>

Re: OperatingSystemMXBean unaware of container memory limits

> On Jun 21, 2019, at 6:06 AM, Mario Torre > wrote: > > The way I understood the bug report is a two fold approach, i.e. fix the os > bean and *possibly* add a container one or extend it to add more data. Correct. We could file a separate bug to just correct the OS Bean but I was hoping to

Re: OperatingSystemMXBean unaware of container memory limits

I agree with you Mario. When I originally designed the jdk.internal.platform.Metrics API, I was considering providing both a Host and Container Metrics implementation. The problem is that the primary goal of containers is to provide isolation (hiding access to the host) and it would be very

Re: OperatingSystemMXBean unaware of container memory limits

Hi Kirk, I think I understand what you mean, however then the OS Bean should be consistent regarding CPU information as well. I think I remember why this was fixed the way it is now was because of incorrect behavior during GC configuration, or something along those lines, so I guess we would

Re: A Bug about the JVM Attach mechanism

Hi, Can we fix this issue like this webrev? http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal/ I could reproduce this issue with ConcAttachTest.java in it on my laptop. (Fedora 30 x64 on Hyper-V guest: Core i3-8145U x 2vcpu) If we need to fix based on current implementation, I think

Re: OperatingSystemMXBean unaware of container memory limits

Hi Mario, I don’t believe the MBean returns the wrong information. Is it not that the calls by-pass the container? Would it not be more appropriate to add a container aware mean? From a tooling perspective it’s a mistake to completely seal the JVM away from the hardware as it makes certain

Re: Slow class loading when running JVM in debug mode

Will have a look, thanks for advices! On 21-Jun-19 00:42, Chris Plummer wrote: With respect to the specific issue brought up in https://youtrack.jetbrains.com/issue/JBR-1611: "If we look into the code, we'll see that whenever a new class is loaded and an event about it is delivered, when a

Re: OperatingSystemMXBean unaware of container memory limits

The way I understood the bug report is a two fold approach, i.e. fix the os bean and *possibly* add a container one or extend it to add more data. I agree with you and Andrew that the current OS Bean returns wrong information, this should be fixed in any case I think. Bob, do you have some

Re: OperatingSystemMXBean unaware of container memory limits

Hi Bob, On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: > Hi Andrew, > > I am aware of the limitations of the OperatingSystemMXBean and was > hoping to address these limitations during the implementation of > https://bugs.openjdk.java.net/browse/JDK-8199944. > > It would be helpful if